Announcement
Collapse
No announcement yet.
Superposition Shows How Far RadeonSI Gallium3D Has Evolved vs. AMDGPU-PRO
Collapse
X
-
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).
Leave a comment:
-
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.
Leave a comment:
-
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 oneLast edited by dungeon; 13 April 2017, 04:30 PM.
Leave a comment:
-
Originally posted by dungeon View Post
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-FREEprobably.
Only on Debian 9 might be a prob since there is that ssl transition with two versions flawing aroundonce 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
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.
Leave a comment:
-
Originally posted by bug77 View PostIt simply seems to be broken on Debian (and family) atm.
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-FREEprobably.
Only on Debian 9 might be a prob since there is that ssl transition with two versions flawing aroundonce 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.2Last edited by dungeon; 13 April 2017, 04:07 PM.
Leave a comment:
-
Originally posted by s_j_newbury View Post
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.
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.Last edited by smitty3268; 13 April 2017, 02:49 PM.
- 1 like
Leave a comment:
-
Originally posted by pal666 View Postwhy don't you enable your brain and understand that mesa does not work on windows?
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.
- 1 like
Leave a comment:
-
http://subirimagen.me/uploads/20170412202811.png
Only the icon and nothing more if you run via terminal. Nothing of windows only the icon.
Gtx 970 sc / drivers 381.09 / 378 and 375.
Leave a comment:
Leave a comment: