blog: Add post about revamped opengl kit

[kallisti5]

No description provided.

[kallisti5]

Don't merge this one yet. It needs technical review by @X547 and maybe some future looking statements?

[waddlesplash]

we should wait until the new Mesa is merged and this model actually used.

[X547]

Was BGLRenderer a part of BeOS? I am not detailed of BeOS OpenGL Kit history. If so, does it mean that BeOS OpenGL drivers binaries works with Haiku gcc2? Anybody tried?

Probably not relevant today, just curious. BGLRenderer can be added to glvnd if really needed.

[pulkomandy]

No, it is not from BeOS. The only API in BeOS R5 is BGLView: https://github.com/jscipione/r5headers/blob/master/headers/be/opengl/GLView.h

There were extra things in Dano/BeOS R6 for full-screen OpenGL bypassing app_server, some games use that: https://github.com/CodeforEvolution/BeOSDanoHeaders/blob/master/headers/be/opengl/DirectGLWindow.h

I think there was something in Zeta as well, not sure if the same as Dano or yet another variant.

In any case, BGLRenderer was introduced a lot later, IIRC when we allowed to switch between swrast and llvmpipe. On BeOS, the way to switch between different renderers was a lot simpler: just replace the whole libGL with a different one. Several were available, I know of at least:

• The one provided by BeOS (software rendering)
• A software rendering implementation based on TinyGL (still available in haikuports)
• Rudolfc's experimental 3D acceleration for NVidia GeForce cards, based on UtahGLX

As long as they implement the same BGLView public API, apps will happily switch from one to another.

[pulkomandy]

Also I don't understand how these changes to the API really change anything in relation to 3D acceleration. Maybe I'm misssing something, but I don't think the way BGLView communicates with Mesa is so important for 3D acceleration? That would happen more on the "other side" of Mesa where it talks with drivers?

So really the main change here is:

• When we wrote our initial Mesa port, the only interface Mesa had was glx which is tied to X11
• So we added our own interface next to that, called HGL, because we don't do X11
• Since then Mesa has gotten a new interface called EGL, which is not related to X11 and designed to be more easily pluggable to other APIs
• Conclusion: we can remove a lot of Haiku-specific code in Mesa and instead use EGL to interface with it.

Then there is, as far as I understand, a separate part of the work with libglvnd to allow switching between different providers of OpenGL. This used to be possible in previous iterations:

• In BeOS: just replace the whole libGL. Simple, but requires everyone to provide a separate BGLView implementation, so ABI changes are hard if many providers are doing it
• In Haiku before swrast/llvmpipe dynamic switching: libGL provided by Haiku with BGLView implemented in Haiku source repository, linking with Mesa sourcecode (vendored by Haiku)
• In Haiku after swrats/llvmpipe dynamic switching: BGLRenderer provides an extra abstraction layer, but remains a bit specific to Mesa. BGLView moved from Haiku repository to upstream Mesa, although they were not so happy about it and encouraged to use one of the other existing APIs if possible
• In this new solution: libglvnd is used to select different implementations. It also implements BGLView for all of them.

[X547]

Also I don't understand how these changes to the API really change anything in relation to 3D acceleration. Maybe I'm misssing something, but I don't think the way BGLView communicates with Mesa is so important for 3D acceleration?

EGL is not really required for 3D acceleration, but it gives some benefits such as EGLImage API for exporting/importing GPU buffers between applications, implicit sync primitives, some precise OpenGL context options etc.. BGLView API is very limited, it do not provide proper multiple OpenGL contexts support, API/context creation options etc. So advanced OpenGL applications are better to use EGL (maybe wrapped with SDL, GLFW etc.), while simple applications may continue to use BGLView.

It also allow to use more OpenGL drivers implementations such as Nvidia proprietary driver (Nvidia mostly need only rebuild driver for Haiku, Haiku windowing integration can be done on Haiku side via Nvidia windowing system add-on API (https://github.com/NVIDIA/eglexternalplatform)).

Then there is, as far as I understand, a separate part of the work with libglvnd to allow switching between different providers of OpenGL.

It also allows to use multiple OpenGL drivers in the same process at the same time.