Mesa 24.3 Code Branched, Mesa 25.0 Enters Development

[phoronix]

Phoronix: Mesa 24.3 Code Branched, Mesa 25.0 Enters Development

Mesa 24.3 feature development is now over and Mesa 25.0 has entered development with Mesa Git...

https://www.phoronix.com/news/Mesa-24.3-Branched

[pinguinpc]

See nice

[rmfx]

I think zink should fork gallium at this point and make its own tailored version of it to go the next mile.

[QwertyChouskie]

I think zink should fork gallium at this point and make its own tailored version of it to go the next mile.

Why? What makes Mesa great is the code sharing; improvements to one driver often improve all of them. A fork would kill that benefit for no good reason.

[rmfx]

Why? What makes Mesa great is the code sharing; improvements to one driver often improve all of them. A fork would kill that benefit for no good reason.

Zink is limited or slowed down by many “any native driver needs can fit” design in the gallium interfaces.

Since I am a believer that soon, having other GL drivers than Zink will not be useful anymore, because Zink will provide the best overall GL driver with much less maintenance burden than per vendor native drivers, Zink should get extra care and having Zink tailored dependencies from now on.

Over the years:
-GPUs without Vulkan support become very rare
-GPUs become more and more performant (making Zink's few percents perf drop more and more invisible)
-The softwares stuck with GL support are old enough that they are running at very high fps count anyway, even with low 80 percents perf compared to native drivers, they are well above 150fps in most cases.
-concentrating futur efforts on Vulkan drivers / Zink only, would make up for the (LOW) non-native performance impact, by far anyway.

[the-burrito-triangle]

Zink is limited or slowed down by many “any native driver needs can fit” design in the gallium interfaces.

Since I am a believer that soon, having other GL drivers than Zink will not be useful anymore, because Zink will provide the best overall GL driver with much less maintenance burden than per vendor native drivers, Zink should get extra care and having Zink tailored dependencies from now on.
[...]

I don't know why you want to push Zink so hard... It has performed worse than native GL in every test case I've thrown at it. Even something as simple as Warcraft III (2003 version, use wine "Frozen Throne.exe" -opengl) GL outperforms all other options (DXVK, Wine-Nine, WineD3D). In fact, in all my testing (PCSX2, DuckStation, DXVK, etc) using GL is faster and consumes less power draw from my GPUs: RX 7600 and Xe (Tigerlake-LP GT1, 96EUs). For any game that isn't native Vulkan, using Vulkan over GL is pointless. Even Wine-Nine + Gallium Nine works better than DXVK in my testing. So yeah, native GL isn't going anywhere and can often have more than 2x the performance of Zink at lower power draw (which translates to lower fan noise). The only practical use case for Zink currently is shitty ARM devices that have abysmal GPU support on Linux and possibly for NVK and Honycrisp so they can focus on writing/improving their Vulkan drivers.

I'm all for Vulkan, but actual benchmarks favor GL with old games on Wine (either native GL or D3D9 through Gallium Nine). It's possible that D3D10 and up favor DXVK, but I haven't done much testing with new games at the moment. Testing with emulators like Citra, PCSX2, DuckStation and so on, show native GL is still more performant on my hardware.

Case in point:

https://gitlab.freedesktop.org/mesa/mesa/-/issues/12063

[the-burrito-triangle]

And to further my point: RadeonSI allows for adjusting anisotropic filtering (AMD_TEX_ANISO=16), Gallium allows for a simple HUD (e.g., GALLIUM_HUD=fps) and has post processing antialiasing (pp_jimenezmlaa=16 or pp_jimenezmlaa_color=16). Zink has none of this capability yet (that I am aware of), so GL still has its uses. And while one can use vkBasalt to force some of this capability via Vulkan layers, it isn't a part of Mesa and requires more work to setup.

[hamishmb]

It's interesting that OpenGL still outperforms Vulkan for you, and uses less power. I'd just naively assumed that more focus was on optimizing Vulkan drivers so they'd perform better, but I guess not.

[rmfx]

I don't know why you want to push Zink so hard... It has performed worse than native GL in every test case I've thrown at it. Even something as simple as Warcraft III (2003 version, use wine "Frozen Throne.exe" -opengl) GL outperforms all other options (DXVK, Wine-Nine, WineD3D). In fact, in all my testing (PCSX2, DuckStation, DXVK, etc) using GL is faster and consumes less power draw from my GPUs: RX 7600 and Xe (Tigerlake-LP GT1, 96EUs). For any game that isn't native Vulkan, using Vulkan over GL is pointless. Even Wine-Nine + Gallium Nine works better than DXVK in my testing. So yeah, native GL isn't going anywhere and can often have more than 2x the performance of Zink at lower power draw (which translates to lower fan noise). The only practical use case for Zink currently is shitty ARM devices that have abysmal GPU support on Linux and possibly for NVK and Honycrisp so they can focus on writing/improving their Vulkan drivers.

I'm all for Vulkan, but actual benchmarks favor GL with old games on Wine (either native GL or D3D9 through Gallium Nine). It's possible that D3D10 and up favor DXVK, but I haven't done much testing with new games at the moment. Testing with emulators like Citra, PCSX2, DuckStation and so on, show native GL is still more performant on my hardware.

Case in point:

https://gitlab.freedesktop.org/mesa/mesa/-/issues/12063

Because I think it’s a waste of time and efforts to support 10+ native vendor locked drivers instead of just one unified driver that runs 80 to 120 percent as fast at least (for now), with fewer bugs.
I think that efforts should be spent on modern Vulkan drivers primarily and on making Zink the final unified implementation of opengl.
Zink solution for running opengl is very elegant because it’s universal and because it has the potential of shrinking the mesa codebase too.