freenode/#lisp - IRC Chatlog
Search
11:05:58
jackdaniel
someone calls (open-connection whatever nil), I'm not sure if there is much moer to it given this scarce backtrace
11:08:24
jmercouris
we have this: https://gist.github.com/jmercouris/b98a3f3e24c47175aa09ea6010b9ef5e
11:10:35
jmercouris
so here is some more interesting stuff, I've used DBUS server/client ping/pong scripts I've written
11:11:04
jmercouris
echo $DBUS_LAUNCHD_SESSION_BUS_SOCKET -> /private/tmp/com.apple.launchd.3vLn74rWFQ/unix_domain_listener
11:11:36
jmercouris
can some of you Linux users please confirm if you have a value for $DBUS_SESSION_BUS_ADDRESS ?
11:35:33
mercourisj
so do you think this is something that belongs in CL D-Bus library, or should be handled by the user? if so, is there a better way?
12:37:55
jmercouris
is it basically only opengl when you want to have a cross-platform graphics lib?
12:39:58
jmercouris
I think the answer is basically just that, opengl or you'll have to maintain platform dependent bindings
12:41:47
|3b|
you need platform specific code to open windows for OpenGL or vulkan, and apple doesn't seem to want to support either
12:42:45
|3b|
(ms doesn't want to either, but let people write their own drivers so can't enforce it as well)
12:43:38
jmercouris
so if someone wanted a cross platform graphics library they would have to abstract these APIs somehow
12:43:40
aeth
jmercouris: Most of the graphics work seems to be on OpenGL paired with something like SDL (cl-opengl is essentially universal; cl-sdl2 is popular, but not universal)
12:44:11
aeth
jmercouris: The only real way to support macOS in the future is with moltenvk and Vulkan, but Vulkan isn't really a CL priority at the moment.
12:45:18
aeth
I mean, the way I see it is, if people just don't drop support for macOS altogether it'll basically be entirely through moltenvk going forward until Apple adopts Vulkan 10-15 years late.
12:46:05
|3b|
presumably opengl will continue to be supported by metal/vulkan wrappers even if vendors don't, like ANGLE does on dx
12:46:46
jmercouris
are you saying that people will write code that wraps opengl -> metal equivalent / vulkan equivalent calls?
12:46:46
|3b|
at some point there will probably be an opengl implementation with vulkan and/or metal backend
12:47:42
|3b|
probably not horrible, drivers are already doing lots of inefficient things for gl anyway :)
12:48:12
aeth
You're not going to be using an Apple computer for maximum performance here, anyway, so a little inefficiency is probably not an issue.
12:48:25
|3b|
biggest thing about the new apis (vulkan, dx12,metal) is just being a lot more explicit about what you are doing
12:49:16
|3b|
still the same hardware underneath, so no real fundamental differences in features, and the newer APIs match newer hardware better anywayy
12:49:54
|3b|
so if you need absolute peak performance, you should probably be looking at those, or at least using GL in a way that translates fairly well to them
12:52:24
jmercouris
I don't understand why they couldn't have just extended openGL to accomodate new features and versioned it up?
12:52:50
jmercouris
and it makes it way harder for any application developer to make anything cross-platform, though I suspect it is on purpose, and for financial reasons
12:53:36
|3b|
would have basically ended up with a whole new API sitting next to the existing one, just with a GL prefix instead of VK
12:53:57
ggole
It would be nice if they provided a library for running old GL code on top of the new approach
12:56:44
|3b|
and under the hood, it is probably pretty much just passing a table of function pointers directly to the app on any platform that isn't apple
12:56:53
pjb
jmercouris: I always reach the same conclusion: write it yourself, so you maximalize your happiness.
12:57:02
aeth
jmercouris: Remember, you're talking to a specialized computer that often is its own discrete piece of hardware.
12:57:08
|3b|
yeah, each hardware vendor implements all of opengl, which is another thing people don't like about it :/
12:57:38
ggole
The vendor's driver is in charge of things like compiling shader code to whatever internal machine code they use
12:57:49
|3b|
vulkan is supposed to be a lot easier for hardware vendors to implement, so theoretically they can get it closer to correct faster
12:58:08
jmercouris
that would explain perhaps why some games run better on some cards and crash on others?
12:58:53
ggole
It's worse than that, vendors do things like ship game-specific bug workarounds in their drivers
12:59:05
aeth
jmercouris: there's some forum post where someone explains what vendors do in game drivers
12:59:06
|3b|
sometimes its bugs in drivers for 1 hardwarre, sometimes drivers accept things they possibly shouldn't, and people dev for that and don't notice their code has bugs, and it breaks on stricter drrivers
12:59:12
jmercouris
I've heard the opposite being true as well, to sabotage games that don't use their APIs
12:59:48
|3b|
it's what happens when someone can't control the entire market and force them to do things like MS did with dx
12:59:49
aeth
jmercouris: essentially, there's these big, complicated, poorly-explained APIs and the engines and games use these APIs incorrectly, and instead of fixing the upstream, each vendor then rewrites things to make things work
13:00:21
jmercouris
and we all have to deal with this because there is not an OS level interface for performance reasons, basically?
13:00:26
aeth
jmercouris: imagine if GCC had a workaround for Firefox that detected it was compiling Firefox and did specific things just for Firefox
13:00:41
aeth
and then Clang would also do the same thing, and might have different performance characteristics...
13:00:56
aeth
I wouldn't be surprised if it went as far as some things having different big-O characteristics
13:01:08
jmercouris
this is possibly the worst thing I have ever heard about the state of hardware/software today
13:01:36
aeth
jmercouris: Remember, OpenGL is running a compiler, for GLSL. It's also probably doing some workarounds at the API level, too, probably.
13:01:59
|3b|
letting vendors control drivers at an abstract level like GL/vulkani does have the benefit that they can make huge changes to the underlying hardware over time, without worrying about running old binaries like xx86 does
13:03:11
|3b|
well, they run arbitrary code, so hard to say if it is "microcode" or just "code running on GPU" for any given bit of code :p
13:03:32
|3b|
probably something comparable to "microcode" though, just for flexibility, late bug fixes, etc
13:04:44
jmercouris
I wish we could just have a do-over with all of the knowledge we have, and make something better
13:05:41
aeth
jmercouris: Well, it's kind of informative as to the level of complexity here that we have open source CPUs at this point (and multiple architectural options, including POWER and RISC V), but no open source GPU. And Nvidia doesn't even have open source drivers for its current generation afaik.
13:05:56
|3b|
"here's a binary blob of 6 year old opengl es with lots of known bugs, that only works with some specific patched version of linux 3.15"
13:07:06
jmercouris
I think it also has to do probably with age, GPUs as a concept are muh newer than CPUs
13:09:26
|3b|
shka__: heh, checked and osx apparently supports gl 4.1 at best, which was released july 2010, so not just 'circa' 2010 gl:/
14:18:03
pjb
I would note that Tesla developped it's own "GPU" to implement its self-driving car AI…
14:28:16
Bike
if you pass encode-universal-time a year between 0 and 99, it gets an actual year by adding that to the current year mod 100, and then subtracting 100 if the result is more than fifty years in the future
14:29:54
zulu-inuoe
I agree they're a sin, but they're definitely fun. Oh. Wait you meant working with them