4 ms·

Well yeah, the GL calls are actually different on different machines right? Isn't that the absolute first consideration when deciding if you should dynamically

Well yeah, the GL calls are actually different on different machines right? Isn't that the absolute first consideration when deciding if you should dynamically link?

flohofwoe 5y ago
I'd rather expect that the 'user-facing' GL implementation (GL2.x, GL3.x, ...) is identical and can be statically linked, and that only the graphics driver layer differs between machines (which would be similar to an executable which links the C library statically, which in turn talks to the operating system through syscalls). But to be fair, dynamically linked GL wouldn't be a problem, if this wouldn't also pull in a dynamically linked glibc (it always comes back to glibc unfortunately).
- creshal 5y ago
  Isn't this the point of libglvnd?
- cesarb 5y ago
  > I'd rather expect that the 'user-facing' GL implementation (GL2.x, GL3.x, ...) is identical and can be statically linked, and that only the graphics driver layer differs between machines (which would be similar to an executable which links the C library statically, which in turn talks to the operating system through syscalls). The problem is that the "graphics driver layer" (except a small amount of security-sensitive pieces) runs in user space, in the same process which is doing the OpenGL/Vulkan/Metal/etc calls. The way modern graphics hardware works is that the application writes a very complex and hardware-dependent set of command buffers, which are then submitted to the hardware, and only this final submission goes through the kernel (for security reasons). If the application had to call the kernel for each and every step of the creation of the command buffers, it would kill the performance.
simias 5y ago
That's normally what kernel abstractions are for, but unfortunately for various historical reasons graphics API often bypass the kernel in part or in full. There's also the problem that graphics are often very performance-sensitive so costly abstractions may not be desirable.

Well yeah, the GL calls are actually different on different machines right? Isn't that the absolute first consideration when deciding if you should dynamically link?

flohofwoe 5y ago

I'd rather expect that the 'user-facing' GL implementation (GL2.x, GL3.x, ...) is identical and can be statically linked, and that only the graphics driver layer differs between machines (which would be similar to an executable which links the C library statically, which in turn talks to the operating system through syscalls). But to be fair, dynamically linked GL wouldn't be a problem, if this wouldn't also pull in a dynamically linked glibc (it always comes back to glibc unfortunately).

creshal 5y ago
Isn't this the point of libglvnd?
cesarb 5y ago
> I'd rather expect that the 'user-facing' GL implementation (GL2.x, GL3.x, ...) is identical and can be statically linked, and that only the graphics driver layer differs between machines (which would be similar to an executable which links the C library statically, which in turn talks to the operating system through syscalls). The problem is that the "graphics driver layer" (except a small amount of security-sensitive pieces) runs in user space, in the same process which is doing the OpenGL/Vulkan/Metal/etc calls. The way modern graphics hardware works is that the application writes a very complex and hardware-dependent set of command buffers, which are then submitted to the hardware, and only this final submission goes through the kernel (for security reasons). If the application had to call the kernel for each and every step of the creation of the command buffers, it would kill the performance.

simias 5y ago

That's normally what kernel abstractions are for, but unfortunately for various historical reasons graphics API often bypass the kernel in part or in full. There's also the problem that graphics are often very performance-sensitive so costly abstractions may not be desirable.