I have seen the Vulkan screenshots from X512, but it seems - at least for me - his attempt goes much deeper, and AFAIK you don’t yet use all of his patches (but correct me if I am wrong), so my question: is this Vulkan support you mentioned useful / usable on Haiku, or it is just built in, but impossible to interact with it on Haiku? The question is explicitly about the mesa bump, not else, not more, not less. Please give a simple and clear answer, thank you.
1 Like
- Blender --version
Blender 2.93.5
Works great with newer Mesa…
20 Likes
I tried to test the package but literally nothing works. I did a full update (a few minutes ago) and I get the package version mentioned above (Mesa 21.2.3).
I tried running GLInfo which shows me wrong values like GL version 3.1 . When I quit GLInfo it crashes.
Then I tried running my game engine mesa still incorrectly reports “GL Version 3.1” and launch fails. Forcing version to 4.6 works as with previous versions of Mesa.
then I tried installing blender to test. Blender package (2.79b-23) can not be installed since a dependency package is missing (problem 1: nothing provides lib:libopencolorio>=1.1.1 needed by blender-2.79b-23). I wonder… where is the newer Blender package?
I’m quite unlucky I guess.
EDIT: I updated to 1.6 of my game engine. In there I have a vulkan test but it failed loading. I guess this package does not contain a vulkan loader library. Had been a try.
1 Like
GLInfo crashing is a known issue, I have no idea why mesa was updated before this was fixed…
Opengl 3.1 is to be expected, I think, llvmpipe only exposes to support opengl 3.3, and it is the only software renderer we have
Blender beeing uninstallable is unrelated to the mesa package beeing updated
I updated opencolorio a while back, but didn’t revbump the one for Blender, maybe with the new mesa packages it should work better?
GLInfo crashes due to double deletion of an object:
https://git.haiku-os.org/haiku/tree/src/tests/kits/opengl/glinfo/CapabilitiesView.cpp#n116
https://git.haiku-os.org/haiku/tree/src/tests/kits/opengl/glinfo/CapabilitiesView.cpp#n117
But the columns are also deleted when the BColumnListView is deleted:
https://git.haiku-os.org/haiku/tree/src/kits/interface/ColumnListView.cpp#n772
Removing lines 116 and 117 will fix the problem.
PS: I don’t understand why it didn’t crash before
6 Likes
Please patch this for haiku beta3 too, then. since it will now most likely also get the newer mesa via updates, and thus crash in the same way.
2 Likes
Which is quite a problem. Without forcing a version Mesa hard-sticks to 3.1 and initialization fails. You can not query 4.6 type extensions although supported by Mesa. By using the version hack you can query the extensions supported by Mesa.
I mean what use is it to have Mesa updated to 4.6 support level if it hard-locks to 3.1 failing all above?
I don’t see the problem, if we don’t have proper support for opengl 4.6 either way why does it matter whether it claims to support it?
Because the basic idea behind extensions is that you can get features albeit the implementation does not support the full spec containing the extension. If a system supports only core 4.0 but exposes extensions from core 4.6 then you can use them. 3.1 is quite “limited” and many common extensions Mesa would support but without version hack it flat out denies all.
Granted, without proper HW support that’s not that much of an issue since you can not get up to speed anyways but it might be something to keep in mind when heading for beta3.
Dragon - Otherwise, no visible rendering issues at all for you? No further issues with Mesa?
Vulkan for Haiku support:
- The Vulkan ICD (driver/loader/etc) - is a work-in-progress (X512).
- The Vulkan 1.2 SDK for Haiku - Haiku package with libs (x86/x86_64), docs, and VLK 1.2.195 headers. I put this together awhile ago.
Some software apps will set their own GUI/terminal environment to a OpenGL 4.6 / GLSL 4.6 compatibility profile (or lower) for proper extension availability - so the default Mesa environment setup is not an issue.
Usually, drivers don’t want to send GL/CL/VLK commands to hardware devices not supporting certain extensions/core profile… etc, etc…
Yes, it looks like the over bright rendering is gone. Enabling shadows and GI is not fast (as to be expected) but the result seems now to be correct.
It is true some software tries to create high level contexts going down in version until it succeeds. That’s though not how the system is designed to be used.
AMD does it correct in my opinion. You request the minimum core profile you can work with and the driver gives you the highest core profile supported with all extensions beyond to be queried. That’s what Drag[en]gine is doing.
nVidia does it not so cool. It gives you exactly the minimum core context requested with extensions beyond to query. Why is this bad? You have no idea what the highest supported core context is. By doing it the nVidia way you are left guessing around while AMD does it smart and avoids the need for guessing.
Unfortunately some drivers like Intel give you also a broken minimum context from which it is hard (or impossible) to query extensions. Mesa under Haiku is unfortunately similar to these broken drivers.
I can try adding the guess-me-down approach for compatible profiles but I want in my game engine to use “core” profiles if possible since compatibility contexts have more liberty at implementing functionality which can haunt you suddenly. Maybe a config switch to enable compatibility mode could be done. Not sure about this. Haiku is the one system I have the biggest issues on in terms of context selection.
EDIT: Concerning Vulkan, are these packages merged into haikuports? Maybe I missed them.
The SDK I worked on is a separate Haiku package. There are extra tools like vulkaninfo.
Agree with you on the various driver methods/issues.
Maybe I can add libvulkan.so based on Vulkan-Loader to HaikuPorts soon. It is already working and it is independent from drivers such as Llvmpipe, but need adding Haiku WSI extensions in the future.
6 Likes
Would be interesting. Right now I have only a headless vulkan test implementation in my game engine. Basically with the idea to get RTX support OpenGL will most probably never obtain. So it supports compute shaders at the time being with raytracing shaders coming next.
1 Like
I tried to revive both OIIO and OCIO to the prior version (on x86_64), OCIO is ok and can be installed, you can install Blender but it will complain about the OIIO version missing, no matter how I tried (been busy with it for 2 days), I can’t get the previous (2.0.12) version to build anymore … 
Speed-Dreams crashes at exit with this new Mesa.
See
As mentioned in that issue, it works ok with the old Mesa 17 and also with Mesa 21 from LOTE.
Did something from LOTE not make it into this new Mesa ?
2 Likes
dragengine testing update:
- Bumped to Mesa 22.1.2 on Haiku hrev56198. Built OK.
- Bumped to dragengine v1.12-current.
We can update to Mesa 22.1.2 on Haiku. Can focus on bugfixing now…
4 Likes
is that with hw accel ?