R600g "Soft" FP64 Shows Signs Of Life, Enabling Older GPUs To Have OpenGL 4 In 2018

[orome]

I disagree. Only reason for sw fp64 are conformance with OpenGL 4.whateveritwas. You're not expected to use it ever

You can disagree as much as you want. If you were not supposed to use it you wouldn't need conformant implementation. You can force enable the extension (and higher GL version) even now.

[coder]

...

Thanks for working on this, mate. I recently needed OpenGL 4.3 on a Barts Pro, but the official drivers are no longer supported on my distro. I ended up getting a Polaris, but I still have the VLIW5 card and might use it in something else. It's still a worthwhile card, at least specs-wise, and should hold its own against current entry-level dGPUs.

[leipero]

duby229 Well, we can conclude what is the problem simply by testing GNU/Linux native application genymotion (Android layer for VirtualBox) on radeonsi (any "GCN" GPU) where default OpenGL profile is 4.x, while wine could be completely different problem as you pointed out. Gallium nine actually renders everything corectly with 4.xCOMPAT profile, it's wine D3D translation to OpenGL where that screenshot comes from, but both wine D3D and gallium nine do crash with 4.x core profile, just to clarify things.

[artivision]

Not everyone has a xeon, radv at least on lower CPUs seems to win out,

But apart from Cayman I doubt a Vulkan driver would be worth it.

Dave.

If you mean versus OpenGL, i say OGL shouldn't be existed at all, you could easily drop it tomorrow morning. If you mean versus Gallium, i say that Gallium must be replaced not because it's bad but because its not unified. I actually mean that Vulkan is a unified intermediate system for all possible state trackers, graphical and computation. Basically i only believe in future Vulkan and today's D3D for gaming, guess where D3D11 is faster on Linux.

[pal666]

AMD hw usually has between 1/16 to 1/64 fp64 performance in HW.

i am not aware of amd hw with either 1/64 or 1/32, but i am aware of amd hw with 1/4, 1/5 and 1/8

[duby229]

Yes, I know from eariler posts, but as I said, if someone who have "GCN" GPU that have 4.x enabled by default can run genymotion (native GNU/Linux application) it clearly shows the problem in r600 drivers.

As for wine, maybe what you are talking about have something to do with this:

https://imgur.com/M6tYy6j

This is when 4.xCOMPAT profile is forced, while with core profile it does crash of course as I said before, interestingly enough, when 4.xCOMPAT profile is forced and gallium nine is enabled, those artifact do not exist (picture is as it is supposed to be), but it also crashes with core profile.

This is ofc. tested with latest mesa-git as of today (17.4.0_devel.99282.8ff8c82630).

It's pretty common for gallium nine to work when wine doesn't. That's not an r600g problem, gallium nine has better compatibility than wine. It has for a long time now. But that is a separate problem.

As far as I can tell you are experiencing at least 3 separate problems. 1: Wine crashes when using it's default DX implementation, it may render correctly if the crash bug gets solved. 2: Wine with gallium nine renders incorrectly, that's probably a gallium nine bug handling something non-standard incorrectly. 3: The app implements compat profiles when only nVidia's driver on linux supports it, so mesa needs an override or the app itself needs fixed.

EDIT: In all probability each of those problems most likely boil down to non-standard use of various graphics API's. So really in the end it's the app that needs fixed.

[leipero]

As already said, it implements a compatibility profile, which mesa will never support. The only option is to contact them and try to explain why compatibility profiles will never be supported. That way they can fix their own code.

Yes, I know from eariler posts, but as I said, if someone who have "GCN" GPU that have 4.x enabled by default can run genymotion (native GNU/Linux application) it clearly shows the problem in r600 drivers.

As for wine, maybe what you are talking about have something to do with this:

https://imgur.com/M6tYy6j

This is when 4.xCOMPAT profile is forced, while with core profile it does crash of course as I said before, interestingly enough, when 4.xCOMPAT profile is forced and gallium nine is enabled, those artifact do not exist (picture is as it is supposed to be), but it also crashes with core profile.

This is ofc. tested with latest mesa-git as of today (17.4.0_devel.99282.8ff8c82630).

[RussianNeuroMancer]

Thanks for working on r600g, Dave
There is still users of this hardware who will continue to use in coming years, so your work is very appreciated.

If you find time for this, please look into couple of r600g issues:

https://bugs.freedesktop.org/show_bug.cgi?id=103900

https://bugs.freedesktop.org/show_bug.cgi?id=100953

Not everyone has a xeon, radv at least on lower CPUs seems to win out,
But apart from Cayman I doubt a Vulkan driver would be worth it.
Dave.

I guess it also could be useful for DXVK project, so maybe worth not only on Cayman.

[mczak]

fp64 was also supported if the hw supported it. Unfortunately, older hw does not support it, hence the software emulation. The same holds for tessellation. No support on older hw, but maybe software emu possible.

You want fp64 because the chips could otherwise do GL 4.5, but without it are restricted to GL 3.3, and noone (at least as far as games are concerned) is using fp64 anyway.
But you don't want to emulate tessellation, and besides it wouldn't help much since there's other stuff you'd have to emulate for GL 4.0 anyway on r600/r700. Bit manipulation instructions (certainly doable just slow), the interpolateAt instructions, probably lots more stuff I forgot about.

[mczak]

AMD's hardware isn't that bad with FP64. From my research, most mid range or higher GCN models are 1/32 at the worst, but most are better.

Unless I'm mistaken, I don't think there's any amd gpu where the fp64 rate is lower than 1/16. Only select few can do better in hw and from the consumer cards even fewer can do better (I think the only consumer cards which can do 1/8 are those based on hawaii where the chip could do 1/2), so for most practical purposes it's pretty much always 1/16.
(nvidia otoh had 1/24 on kepler and 1/32 for everything maxwell/pascal on the consumer side.)