Grover/Gallium Nine Support?

[michaeljhkim]

Considering the fact that there is a driver that would add native glide support for mesa, wouldn't it be purely better to use that as well? I mean, the code is done and useable. Just needed to be added to mesa, but was unfortunately rejected.

[lorn10]

Yes, that would be really an amazing thing to have native Glide support in SoftGPU via Mesa.

The same is true for Gallium Nine aka the native Direct3D9 API implementation in Mesa. :wink: As far I known QEMU has support for it. In comparison to WineD3D it is definitely faster, more accurate and even more stable. And unlike the Grover Project Gallium Nine is already part of Mesa since several years. :+1:

And by the way, the Grover merge request in Mesa was not rejected. It looks that its original author has simply no longer any time free to work on it. Ergo it is still in draft stage. More information about that project can be found at the original phoronix article.

[michaeljhkim]

Yes, that would be really an amazing thing to have native Glide support in SoftGPU via Mesa.

The same is true for Gallium Nine aka the native Direct3D9 API implementation in Mesa. 😉 As far I known QEMU has support for it. In comparison to WineD3D it is definitely faster, more accurate and even more stable. And unlike the Grover Project Gallium Nine is already part of Mesa since several years. 👍

And by the way, the Grover merge request in Mesa was not rejected. It looks that its original author has simply no longer any time free to work on it. Ergo it is still in draft stage. More information about that project can be found at the original phoronix article.

this is quite interesting to learn. In this case then, it appears that using gallium nine and grover would be far better than using wine libraries. Especially since it would both be native support in those cases.

[JHRobotics]

Hi, Glover doesn’t seem to me to be in some complete state – but I currently using mainline version of Mesa, so it can be merged relatively easily (question is Rust runtime on Windows 9x – this could be quite nightmare).

Nine is something different – I already created skeleton to implementation. In last months I heavily worked on GPU gen. 10 implementation and now I can focus to Nine. Plan is also route DDI calls directly to Nine – result will be native DirectX/DirectDraw implementation without wrappers. Driver side skeleton is already here. But I don't want to promise anything yet, it's possible that I'll “hit the wall” somewhere.

[lorn10]

Great news and nice to know that native Direct3D support will be available at some point! :tada:

By the way regarding the Grover project it looks that I was wrong and @michaeljhkim was right. Current state is that it got in some way a NAK which means that it will not land. :disappointed: I have asked regarding the actual situation and one of the Mesa devs gave an informative answer what Mesa can support and what not, I quote Karol Herbst from here:

there are three parts of to that:

usefulness: is having an upstream glide frontend actually useful or is it only done for the sake of it? Like does it allow any user to do something which they couldn't do otherwise? Is it giving any performance advantages? tldr: is it critical to have this inside mesa the way it is?

cost of maintenance: Are the potential benefits a good trade of for the increased maintenance burden as of today? Does it makes sense to add Rust abstraction layers just for this frontend?

viable alternatives: Does it really have to be a real gallium frontend or could it also be an external library simply layered on top of OpenGL/Vulkan?

The Nine frontend was a product of its time to bring up performant gaming to Linux, there was no viable alternative as the OpenGL translation layer in wine was generally significantly slower. d3d10 support in wine was very poor. These days we have d3d9 layering on vulkan being equally fast if not faster, so if anybody would propose a new frontend like Nine it might also get rejected due to the diminishing benefits. The only real reason to keep nine is that it does run d3d9 era games on d3d9 era GPUs not supporting Vulkan. But the question remains for how long it still makes sense to keep maintaining it.

So instead of closing this topic here it would perhaps make sense to rename it from Grover to Gallium Nine support. :thinking:

Edit: The discussion on Mesa around Grover made an interesting development. The mentioned NAK was not a general one. It was more related to the current implementation in Rust. So it looks that there may exist a chance that a Glide API Mesa implementation would be accepted but it has to be done most likely in C. :+1:

[michaeljhkim]

Great news and nice to know that native Direct3D support will be available at some point! 🎉

By the way regarding the Grover project it looks that I was wrong and @michaeljhkim was right. Current state is that it got in some way a NAK which means that it will not land. 😞 I have asked regarding the actual situation and one of the Mesa devs gave an informative answer what Mesa can support and what not, I quote Karol Herbst from here:

there are three parts of to that: usefulness: is having an upstream glide frontend actually useful or is it only done for the sake of it? Like does it allow any user to do something which they couldn't do otherwise? Is it giving any performance advantages? tldr: is it critical to have this inside mesa the way it is? cost of maintenance: Are the potential benefits a good trade of for the increased maintenance burden as of today? Does it makes sense to add Rust abstraction layers just for this frontend? viable alternatives: Does it really have to be a real gallium frontend or could it also be an external library simply layered on top of OpenGL/Vulkan? The Nine frontend was a product of its time to bring up performant gaming to Linux, there was no viable alternative as the OpenGL translation layer in wine was generally significantly slower. d3d10 support in wine was very poor. These days we have d3d9 layering on vulkan being equally fast if not faster, so if anybody would propose a new frontend like Nine it might also get rejected due to the diminishing benefits. The only real reason to keep nine is that it does run d3d9 era games on d3d9 era GPUs not supporting Vulkan. But the question remains for how long it still makes sense to keep maintaining it.

So instead of closing this topic here it would perhaps make sense to rename it from Grover to Gallium Nine support. 🤔

Edit: The discussion on Mesa around Grover made an interesting development. The mentioned NAK was not a general one. It was more related to the current implementation in Rust. So it looks that there may exist a chance that a Glide API Mesa implementation would be accepted but it has to be done most likely in C. 👍

I mean, the Grover code still exists for anyone to use freely, but I suppose re-writing things in C would be a major pain.

[lorn10]

Yes, a rewrite of Grover to C is most likely a huge amount of work. But I suppose that for this project here that would be a clear win because the implementation in SoftGPU would be far easier when it's C based instead of Rust.

[michaeljhkim]

Yes, a rewrite of Grover to C is most likely a huge amount of work. But I suppose that for this project here that would be a clear win because the implementation in SoftGPU would be far easier when it's C based instead of Rust.

the only problem now is to figure out who is going to do it? because it would be unfair to give another work load onto the author. Gah, if only there were more people interested in this project and had skills.

[lorn10]

This is true, - it looks that one main goal of the Grover MR was the idea to use Rust. So most likely a rewrite to C would be a project of its own. And when I compare it to Gallium Nine, then the whole context seems to be a different one because Gallium Nine is centrally focused on Gallium although its uses the old TGSI and not the newer NIR technique as base.

Whatever, one positive aspect is probably that the Glide API is far smaller than the Direct3D9 one. So the total amount of that work should be less. And, finally the Glide API is open-source and the way how it works is therefore better documented than Direct3D9 (which needed back then quite some reverse-engineering). There exist still the original SourceForge page as well as some minor updated forks at GitHub.

So yeah, this should be done but the question is who has the motivation for it. Maybe someone will come along the road and try this a second time but in a way that it can be accepted by the Mesa devs. :wink:

I assume that @linkmauve is no longer interested in that.

[Torinde]

Glad to see release 0.5 with Gallium Nine, thank you @JHRobotics!

Are you aware of Dd7to9? Seems to be a nice addition for SoftGPU, DirectDraw/Direct3D 1-7 to Direct3D 9 and many other features (resolution hack, etc.)

[JHRobotics]

@Torinde: Another DDraw/DX6/DX7 wrapper in not plan now, but I'm planning to add native D3D HAL support, but is long way to go...