A number of patches worked on for Haiku OS back for Mesa 20.x were freshened up and with some extra tweaking and code cleaning those patches have now been merged for Mesa 21.0. This includes factoring out a lot of the OpenGL legacy dispatch code and a lot of cleanups around the Softpipe driver handling.
With Mesa 21.0-devel as of today, it’s at least enough where Mesa Git can now be built on Haiku OS and yield working OpenGL rendering with the LLVMpipe software.
Neat, and a testament to Haiku being in a far better state than many people seem to think.
Can anyone in the know say what this means for Haiku?
If the link is correct basically this?
https://docs.mesa3d.org/drivers/llvmpipe.html
it’s been years since i did OpenGl and I have zero clue where things are at now and even less of a clue about Haiku and OpenGL. Getting a modern implementation running on Haiku has to be a good thing and lay the foundation for hardware drivers?
Hello! Nothing really.
Haiku has had LLVMPipe rendering support for 5+ years. Our upsteam mesa support has just been slowly breaking. The patches submitted are a bunch of cleanup and repairs to the code which I got upstreamed in 2014-2016.
tldr; this really isn’t news… just us catching up upstreaming patches which have existed outside of Mesa in our ports system for a few years now.
With that said, the patches do rework a lot of our rendering dispatch code… so it is an “improvement”, just not earth shattering
From the article I got the imrpession Haiku’s OpenGL was lacking. the fact it’s simply maintenance isn’t news as you say. Irritating it was needed though, I suppose.
This is kind of ironic, given that BeOS multimedia demos were based on well it executed OpenGL applications.
BeOS’s big OpenGL support early on is a blessing and a curse.
A lot of the BeOS OpenGL API’s were written around the “ideal” OpenGL stack… of the time.
our libGL.so loads “renderer plugins” which were independent things designed to be released by hardware vendors.
So, AMD would release a simple self contained BeOS “Radeon HD Renderer” which would be placed into add-ons/opengl/ by the user and connect to generic hooks in the video card driver.
Obviously that isn’t the direction the industry went 🙂 The API/ABI between mesa’s GLX dispatch code and renderers isn’t stable / well defined… so our libGL.so had to keep being updated with the shifting internal calls in Mesa. (this isn’t Mesa’s fault btw.. a lot of this shift was pushed by proprietary drivers wanting “full control of the stack”)
Eventually I was able to merge our libGL.so (aka the “OpenGL Kit”) into mesa (named “hgl”) pulling it out of Haiku’s source tree. This put the unstable API/ABI portion purely within Mesa’s codebase making it easier to keep track of breakages.
It’s actually a bit funny watching AMD move back to their proprietary OpenGL renderer using the open source drivers in the Linux kernel… they’re technically simplifying and re-aligning to the original “ideal” design.
Windows OpenGL ICD mechanism is good and it sounds like Haiku previously used a similar approach? I get the sense this is the Linix tail wagging the dog again on codebases (like Wayland and IHV drivers hence Nvidia footdragging)? imho the ICD mechanism is good so if AMD are moving back to this it’s a good thing. If this is what is happening a stable driver interface and extention mechnisms give IHVs freedoom to focus on their end and add new features without having to wait for architecture APIs to play catch up.
Nice! Good work, folks!
Give me the OpenGLs!!!