As we all know HW GPU support is quite unlikely in the near future. As we also all new Mesa is stuck in a horribly aged state (OGL 3.0). How feasible would it be to get newer Mesa included in Haiku? Performance is not the key problem here but more that OGL 3.0 is the breaking point where OGL switched from the old context system to the new context system (Core/Compatibility). Besides the 3.0 implementation of Mesa is faulty beyond repair… U_U
Actually, Mesa on Haiku_x64 supports OpenGL 3.3 core profile pretty well (all my GL projects are core profile). There is minor issue with SRGB colour spaces, otherwise its usable.
1 Like
The current mesa port is 17.1.10 released in september 2017. Update would be possible, but presumably involves some bug-hunting in the GL code/subsystem/etc.
I just asked since the MESA on Haiku reports “OGL 3.0”. You can force it to “3.3” using the environment parameter but the result is buggy as hell. I could not get anything useful working using 3.3 core profile.
I did not debug this a lot but chances are MESA has broken float texture targets or more likely reports something working which is broken. This mis-render can only happen if color/depth rendering is “not” deterministic, which OpenGL actually requires or MESA does not do clearing correctly. This version of MESA is not so good and newer ones have better implementation of OpenGL conformity.
It depends on which release @dragon is running.
- 32-bit gcc2 - Mesa 7.x, gcc7 secondary arch (setarch x86) - Mesa 17.x
- 64-bit gcc7 - Mesa 17.x as others have mentioned.
We’re a bit limited on the gcc2 version of Haiku at Mesa 7.9.2 since later Mesa code will not build. We pretty much crammed all of the backports of bug fixes we could into it… but new features are a no-go.
In on the up to date beta1 release. That’s 64-bit gcc7 unless there is magic going on?
Check the about window.
1 Like
No one should be using gcc2 for new software at this point anyways. gcc2 Mesa runs BeOS software fine, and that’s all we expect from it.
Here it is. As long as I do not see something wrong this never ever is GCC2. So can we agree we are using the same MESA or have you any other idea?
EDIT: I checked again the logs. MESA is reported as 17.1.10 . On my GenToo machine it’s 18.x . On my Ubuntu Test Machine it’s also 18.x (GenToo is a bit higher). 17.1.10 “should” support OpenGL 4.5 but Haiku MESA clearly reports 3.0 and that something is wrong.
EDIT: I forced now 4.5 as this is what MESA 17.1.0 should be able to do at best. Shader compilation fails with the note that GLSL 3.3 is the highest supported version. That would mean Haiku MESA should support 3.3 but it reports 3.0 . This is one huge mess.
I checked this out a bit more by making my engine dump intermediary render buffer images to see where MESA fails. It’s clearly a depth buffer clear problem since the debug buffer of the last frame leaks over to the one of the next frame. Maybe I can figure out what exactly MESA is messing up but it’s a defined blocker bug (depth clearing is just vital to be correct for any serious 3D app).
Known issue(s). Do this for testing within your terminal environment:
MESA_GL_VERSION_OVERRIDE=3.3FC (I use 4.5COMPAT for my own use)
Mesa 18.2.6 requires changes to the HGL driver code. In avoidance of overloading the core dev team, just
bug report on the current Mesa 17.x build with your findings.
Didn’t know about the GLSL override. Unfortunately this is not working too. My game engine goes by OpenGL spec to get the most out of GPUs. In particular OpenGL >3.0 requires that GLSL version matches OpenGL version. Your trick there fixes this problem but shows others. If an extension is reported by GL but not “core” in GLSL of the respective level you have to “#require” the extension in the shader. For example MESA reports ARB_shader_storage_buffer_object to be present but this extension is core since 4.6 not 4.5 hence in GLSL you are required to “#require” this extension. Yet MESA fails if you do this with override.
EDIT:
I disabled now the offending extension in my engine using the disabling mechanism for broken drivers. It runs nows with 4.5 override but the bug is the same: depth buffer is not cleared although glClearBufferfv() is called.
If you can upgrade and have the time to do so please upgrade to 18.x or at least 17.2.x . 17.1.x is just too much of a buggy mess to get working correctly (and it is deprecated already).
― sorry for interruption, but what that “deprecated” means here?
Quote from the MESA website:
September 25, 2017
Mesa 17.1.10 is released. This is a bug-fix release.
NOTE: It is anticipated that 17.1.10 will be the final release in the 17.1 series. Users of 17.1 are encouraged to migrate to the 17.2 series in order to obtain future fixes.
Since then no 17.1.x releases have been done so this seems to be to the word.
No. What’s going on is that LLVMpipe (the software rendering backend) only supports OpenGL 3.3 at best. The hardware backends for Intel and AMD cards support up to 4.5. So you are trying to force the software backend to handle an API level it does not support, so of course you are getting errors.
If you stop trying to ask Mesa to do things it doesn’t support, then you’ll probably run into fewer bugs…
No. What’s going on is that LLVMpipe (the software rendering backend) only supports OpenGL 3.3 at best. The hardware backends for Intel and AMD cards support up to 4.5. So you are trying to force the software backend to handle an API level it does not support, so of course you are getting errors.
If you stop trying to ask Mesa to do things it doesn’t support, then you’ll probably run into fewer bugs…
May I remind you that I started testing with “3.3” (screenshot above) and I get “the exact same problems”? No need to try to double-post-lecture me here like this.
What “exact same problems”? I see you claiming that Mesa has broken float texture targets or the like, but I have not seen any behavior like this before. Have you tested Mesa LLVMpipe on Linux and see if it has the same bugs? If so, then it is definitely Mesa’s fault and not Haiku’s.
I’m finding the exact opposite issue in my endeavors. Playing with Godot, it complains about using GLSL3.30. It seems to want 3.00 or older. Bleeding edge isn’t always the leading edge. I understand the need for progress, but what’s wrong with using what currently works?
OGL transfered to a new (and much better to develop and maintain) Core system since 3.x . This system is more normed with clearer rules what is available and working. Especially it gives access to a large arsenal of extensions/features which really put performance into anything you do if the platform supports it. It solved the annoying issue with Context Creation. It also added a properly defined backwards compatibility mode. There’s simply no reason to stick to OGL 2.x unless your software is old aged and stagnating or you like causing troubles where there is no need to. OGL 3.x IS better in any regard than 2.x, from development all the way to the final usage. And less problems for developers and end users is for me the biggest gain in all this.