This is mostly the way things should go except… just send patches to Mesa that demonstrate that you understand they problem and have a potential fix… if they don’t like it they will tell you so and you can adapt the fixes and hone your undrestaning of the problem and now to make the code more maintainable.
Basically…less talking and more coding.
Reply to EDIT:
We had this already. With these settings Depth Buffer Clearing is not working which causes render artifacts due to last frame depth buffer tampering with current frame depth rendering.
I tried various different MESA_* overrides and the problem is the same. I can though not tell you what configuration causes the problem. Does apitrace build under haiku? This could help to create a re-producible case.
AFAIK. Use it or simpler debug options (MESA_DEBUG). I was testing a few things like Godot 3.1.1 and mesa demos:
I came across this in Mesa wiki (possibly outdated):
" Proe-05 test 1
This uses depth testing but there’s two problems:
If the chosen visual does not have a depth buffer, you’ll see the wireframe car model but it won’t be rendered correctly.
If (by luck) the chosen visual has a depth buffer, its initial contents will be undefined so you may or may not see parts of the model.
Interestingly, with NVIDIA’s driver most visuals happen to have a depth buffer and apparently the contents are initialized to 1.0 by default so this test just happens to work with their drivers.
Finally, even if a depth buffer was requested and the glClear(GL_COLOR_BUFFER_BIT) calls were changed to glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT) the problem still wouldn’t be fixed because GL_DEPTH_WRITEMASK=GL_FALSE when glClear is called so clearing the depth buffer would be a no-op anyway."
I’ll do more review later. There was a weird build bug in the Mesa 19.2.0 release, so I’ll skip it and migrate to Mesa current (just for my own testing).
As for your game engine, you mentioned it runs properly on Mesa 17.1.0 on Linux. This is hopeful as we
can focus on the 17.1.10 build and fix the known bugs there without migrating up (and introducing another issue).
UPDATE: Some progress was made today. Recent patches now reviewed by Mesa-dev. I’ll track any build or rendering issues through Mesa-dev.
int attribs[] = {
GLX_X_RENDERABLE, True,
GLX_DRAWABLE_TYPE, GLX_PBUFFER_BIT | GLX_WINDOW_BIT,
GLX_X_VISUAL_TYPE, GLX_TRUE_COLOR,
GLX_CONFIG_CAVEAT, GLX_NONE,
GLX_RENDER_TYPE, GLX_RGBA_BIT,
GLX_RED_SIZE, 8,
GLX_GREEN_SIZE, 8,
GLX_BLUE_SIZE, 8,
GLX_ALPHA_SIZE, 8,
GLX_DEPTH_SIZE, 24,
GLX_STENCIL_SIZE, 8,
GLX_DOUBLEBUFFER, True,
None };
glClear:
Actually I’m not using glClear. This is pre 3.x era stuff. I’m using the newer glClearBufferfv . For the clearing glDepthMask is GL_TRUE so this should be also not a problem.
It runs with 17.1.0 on Linux.
Well… “Sort of”. You see the reason I requested an update is that 17.1.0 is pre 3.x era. I “can” get it to run on such a system “if” the GPU underneath exposes the required oepngl extensions. This is not the case under Haiku with software mesa so things get complicated there. I would say on HW GPU supported systems with 17.1.0 you can get the engine up and running but with software mesa (as proven here) it seems at least 18.x is required.
MESA_DEBUG does not create a reproducible trace. For this I need apitrace. It is not in the haikuports, or have I overlooked it?
There wasn’t one for 32bit Haiku. Enabled it now, try again.
I’m 64bit, not 32bit.
EDIT: Found it. For some reason it did not show up where it should.
EDIT: EDIT: The package seems broken. If I try to run apitrace I get a libary not found error:
info: did not find ./wrappers/glxtrace.so
info: did not find ./…/lib/apitrace/wrappers/glxtrace.so
info: did not find /packages/apitrace-7.1-1/.self/lib/apitrace/wrappers/glxtrace.so
error: failed to find glxtrace.so wrapper (rerun with -v option for more details)
EDIT: EDIT: EDIT: The package content only has egltrace.so as wrapper. That’s interesting. Why is this?
Probably glxtrace is only enabled on X11 platform.
Most probably because of the glX* functions used to get OpenGL started. That would be patch-able to Haiku but I guess not with reasonable amount of effort.
Well yeah…then i’d be BGLTrace… or something.
Hello. Well, Mesa 19.1.7 and 19.2.0-rc4 built on Haiku R1B1. Awaiting Mesa 19.1.8/19.2.1 for next full build/testsuite review with Haiku patches integrated from approved upstream reviews (thanks , kallisti5).
I completed an entire build and testsuite review of Mesa 18.3.6 on Haiku R1B1. Only one test failed (seems very minor, test coding issue with GLSL compiler). Mesa API and llvmpipe passed all tests, So, looks good. Only focusing on any Haiku GL driver-centric fixes and visual rendering reviews now. 
NOTE: Debian Sid/Experimental is using Mesa 19.2.0 and FreeBSD 12.1-Beta2/current is at Mesa 18.3.2.
So, knuckle up. 
Huh? What does this mean?
In this context…no idea. Typically it would mean to get ready to fight… similar to put up your dukes.
Don’t mock, don’t you think he means “Buckle up”. Like fasten your seat belts.
Or “knuckle down”, which means to get to apply oneself earnestly.
Possibly… but B and K are not typical transpositions on the keyboard… unless perhaps we are talking to a colemak typist which places B and K in similar positions to B and N on QWERTY.
Also I type crazy stuff all the time…that is what the edit button is for. I still have no idea what cocobean is actually doing…
@dragon - Just to follow up… thanks to the hard work of X512 (aka X547) to port Mesa 19.3.3, we were able to pass the Mesa 8.4.0 demo testing on Haiku R1B1. 
I tested both the Mesa 19.3.3, Mesa 19.3.4, and Mesa 20.0.0 libraries and they passed 100% on Haiku with the new LLVM 9.0.1 compiler.
X512 is still working on a revised Haiku GL driver.
I’d like to revisit testing your program on Haiku once things are in place… and anyone else having previous issues with OpenGL development on Haiku.
As far as my testing goes (with the Minetest package in HaikuPorts), the current Mesa would not take up more than one core. Hope this gets improved…
That sounds good.
I’m currently preparing the game engine for the first public release which is somewhere 2-3 weeks from now. Once released you could either grab the sources and build on Haiku (either directly or using a receipt) or I can add a pre-build.
Personally though I would opt for using the receipt way because the game engine can be build in two flavors (in general): Self-Sustained or Distro-Optimized.
In self-sustained mode as many dependency libraries as possible are build in-tree making the build self-sustained.
In Disto-optimized mode as many dependency libraries as possible are linked against system provided ones to create a build which integrates well into common distribution patterns of distros.
I’ll certainly give this all a test when the mesa update is ready to fly.
Software graphics saturates memory bandwidth anyway… not the CPU itself.
