Superposition Shows How Far RadeonSI Gallium3D Has Evolved vs. AMDGPU-PRO

[phoronix]

Phoronix: Superposition Shows How Far RadeonSI Gallium3D Has Evolved vs. AMDGPU-PRO

Comparing the hybrid AMDGPU-PRO proprietary Linux driver to the RadeonSI Gallium3D open-source driver stack with the newly-released OpenGL 4.5-using Unigine Superposition has shown how far the open-source driver stack has come...

http://www.phoronix.com/scan.php?pag...s-PRO-RadeonSI

[Melcar]

Oh, I'm using a rx480 with the latest oibaf.

[Melcar]

Update. Managed to get my session fixed. It appears that full screen mode messes with display settings (despite running it at my native resolution). Running the benchmark in window mode is the only way I can get it to work.
Benchmark runs no problem, even at max settings. My vram is not properly detected (it says I only have 2gb when my card has 8gb).

[Melcar]

Okay, help please. Tried to run this and now my monitor complains about unsupported timings. Keyboard is still responsive, but the monitor is just black. Reboot did not solve it. The benchmark seems to have messed with something and now I can't log on to my session.

[dungeon]

Well it is initial release in the wild, they will probably do some point fix after accumilating enough issues... Because no matter how much you test an app, upon release somebody will for sure have an issue especially on Linux since things rolls and diversity of distros and their libs are on its greatest

But yeah Qt throwing most of these messages

Payed Advanced and Pro versions as i see have command line and automation, so that might be not affected by Qt versions incompatabilites... Michael probably running that one

[bug77]

He, he, it works perfect on Debian 8 with FGLRX... total clean, does not throw anything in console like seems it was tested right there

On Ubuntu 16.04 using AMDGPU-PRO also works fine, with these ssl messages in console and slightly problematic with resoltion changes... someone need to make xorg.conf with resolutions missing i guess then should be fine... same for AMDGPU-FREE probably.

Only on Debian 9 might be a prob since there is that ssl transition with two versions flawing around once 9 released it would have only one so it is non issue.

Otherwise it is probably just nvidia driver issue or some user specific misconfig of it or something maybe like Unity's WM-specific weirdness i guess that cusa123 have

edit: yeah, complied on Debian 7 likely or some derivative

Eh, since Unigine is mostly about professional apps, I wouldn't be surprised if they only tested RHEL, stable Debian and maybe Ubuntu LTS before calling it a day.
I have Qt on my suspects list, because the first thing Superposition breaks is my primary monitor (becomes disabled). Going into the control panel, I can re-enable it no problem. Messiest benchmark I've ever seen. Or maybe it's just bad luck, I don't know.

[dungeon]

It simply seems to be broken on Debian (and family) atm.

He, he, it works perfect on Debian 8 with FGLRX... total clean, does not throw anything in console like seems it was tested right there

On Ubuntu 16.04 using AMDGPU-PRO also works fine, with these ssl messages in console and slightly problematic with resoltion changes... someone need to make xorg.conf with resolutions missing i guess then should be fine... same for AMDGPU-FREE probably.

Only on Debian 9 might be a prob since there is that ssl transition with two versions flawing around once 9 released it would have only one so it is non issue.

Otherwise it is probably just nvidia driver issue or some user specific misconfig of it or something maybe like Unity's WM-specific weirdness i guess that cusa123 have

edit: yeah, complied on Debian 7 likely or some derivative

GCC: (Debian 4.7.2-5) 4.7.2

Maybe older SteamOS since glibc 2.15+

[smitty3268]

What makes you think that? Gallium3D was intended exactly to support multilple "WinSys", including Windows. That the Windows support is not complete or fully functional is mainly due to lack of interested developers AFAIK. AMD could switch to using the Gallium3D driver for Windows instead, but they would also have to write state-trackers for the recent Direct3D versions since more than d3d9 would be needed, and Direct3D12 is probably too low-level for Gallium3D, like Vulkan.

In an ideal world that would happen, but I can't see AMD throwing out all their legacy code and investing in bringing the Windows WinSys up to scratch, and adding compatibility profiles to Mesa, especially with Vulkan and d3d12 here now. I suppose it could be possible if they focused their proprietary efforts on Vulkan/d3d12 and use Gallium3D for legacy OpenGL/Direct3D and older Windows versions. Maybe.

The gallium code isn't the problem.

It's the million+ lines of linux kernel DRM code that won't work on windows, and the hardware drivers in Mesa rely on that.

In other words, you'd have to rewrite all the gallium driver winsys code to call into the existing (proprietary) windows kernel drivers, or you'd have to port half the linux kernel into windows.

That's a non-trivial amount of work, and then on top of that you'd have to write DX state trackers from scratch, and no doubt have to deal with years of development time before you worked through all the performance regressions compared to their current mature drivers.

And what for? Not sure what the point of all that extra effort would be, in the end. They already have decently high performance DX drivers on windows, and nobody cares about OpenGL performance there. They just have to avoid regressions on that side.

[s_j_newbury]

why don't you enable your brain and understand that mesa does not work on windows?

What makes you think that? Gallium3D was intended exactly to support multilple "WinSys", including Windows. That the Windows support is not complete or fully functional is mainly due to lack of interested developers AFAIK. AMD could switch to using the Gallium3D driver for Windows instead, but they would also have to write state-trackers for the recent Direct3D versions since more than d3d9 would be needed, and Direct3D12 is probably too low-level for Gallium3D, like Vulkan.

In an ideal world that would happen, but I can't see AMD throwing out all their legacy code and investing in bringing the Windows WinSys up to scratch, and adding compatibility profiles to Mesa, especially with Vulkan and d3d12 here now. I suppose it could be possible if they focused their proprietary efforts on Vulkan/d3d12 and use Gallium3D for legacy OpenGL/Direct3D and older Windows versions. Maybe.

[bug77]

Ubuntu 16.04 , Uruguay, I don't think I want to call.

It simply seems to be broken on Debian (and family) atm.