AMD Planning For Launch-Day Vega Open-Source & AMDGPU-PRO Support

[smitty3268]

I also heard that Doom on OpenGL required compatibility profiles. It's unreasonable to expect everyone is going to update their (usually proprietary) software that works fine on every other driver stack.

The NVidia and AMD proprietary drivers on windows and linux are the ONLY ones that have compat profile support. Every other driver stack does not (including those drivers on Macs).

For Doom, it seems like using the Vulkan backend would be preferable anyway.

Dying Light is indeed a problem, but I think it's the only one I actually know about. Most other games don't actually need the compat profile, they just haven't been updated to request a core profile and that can be hacked around using app profiles.

[dungeon]

FWIW, MacOS does not support compatibility profiles either.

MacOS also decide to be stuck with GL 4.1, decide to not do support Vulkan, etc...

So i think that nobody care what they do or not do there with GL/VK points... they decide many things not to do or not to support at all, MacOS even from just Linux POV these days does not deserve to be mentioned even from the scope of any recent open API compatability

[dungeon]

The NVidia and AMD proprietary drivers on windows and linux are the ONLY ones that have compat profile support.

Hm, that is interesting to claim... but how Intel's GPUs on Windows run this Doom via OpenGL if it does not have compat GL? Random YT video for example, but there are more:

So not sure if Intel also do compat on Windows or Doom might have some different fallback GL path also or driver push some hack to run it, etc...

[boltronics]

Dying Light is indeed a problem, but I think it's the only one I actually know about. Most other games don't actually need the compat profile, they just haven't been updated to request a core profile and that can be hacked around using app profiles.

Dead Island suffers from the same problem.

[boltronics]

Not to nitpick, but I think you mean "works fine on two driver stacks (NVidia and AMD proprietary) and doesn't work on any of the others" ?

Well yes, but do you really want the AMDGPU free software stack to only be comparable to anything but those two proprietary driver stacks? When it comes to high performance gaming on x86, I don't think other drivers are of any real significance.

[bridgman]

Well yes, but do you really want the AMDGPU free software stack to only be comparable to anything but those two proprietary driver stacks? When it comes to high performance gaming on x86, I don't think other drivers are of any real significance.

The all-open stack needs to meet its requirements - it doesn't need to "be comparable to some other stack" just because the other stack exists. Just because historically only a couple of proprietary drivers have decent performance doesn't mean all future stacks need to be made in their image. Supporting compatibility profiles hurts performance if anything, not helps.

If the goal was to completely replace the proprietary driver (for workstation applications) then it would need to support compatibility profiles for a while, but we already have the proprietary driver for that. We have what, one or two existing games that require compatibility profiles out of several hundred ? Future games are being developed against Mesa more than they are against the proprietary driver, so AFAICS we have to find a solution for those two (or one) games and that's it.

[boltronics]

Nobody's computing background is such that all games have worked without any problems. Simply use other games and.there are many FPS games to choose from. Many other types of games like Tomb Raider and Prince of Persia series are fun to play and almost every game do work with wine-staging csmt enabled, see winehq. Rocket League is a new cool Linux game too, works fine with Mesa and RX460.

That would be fine if Valve forced the game publishers to advertise that the game works on AMD *only* with the AMDGPU Pro or fglrx drivers - and even then would simply serve to imply to AMD customers that the free software stack is inferior and shouldn't be used. To the best of my knowledge, there is no such advertising requirement on Steam.

[boltronics]

The all-open stack needs to meet its requirements - it doesn't need to "be comparable to some other stack" just because the other stack exists. Just because historically only a couple of proprietary drivers have decent performance doesn't mean all future stacks need to be made in their image. Supporting compatibility profiles hurts performance if anything, not helps.

If the goal was to completely replace the proprietary driver (for workstation applications) then it would need to support compatibility profiles for a while, but we already have the proprietary driver for that. We have what, one or two existing games that require compatibility profiles out of several hundred ? Future games are being developed against Mesa more than they are against the proprietary driver, so AFAICS we have to find a solution for those two (or one) games and that's it.

That's fair. If a solution can be found for the applications which end users of those cards are expected to be able to run (although I'm not sure what that would be), it would make no practical difference to me if legacy compatibility profiles are supported by Mesa or not. Today there are two native AAA games (that I know of), and a number of Bathesda games that fail under Wine (and probably a fair few other games that I don't know about).

Wine itself is also a problem because it relies on compatibility profiles for d3d11->OpenGL, although I believe they are looking into removing the requirement eventually.

[bridgman]

Wine itself is also a problem because it relies on compatibility profiles for d3d11->OpenGL, although I believe they are looking into removing the requirement eventually.

OK, didn't realize that - my impression had been that using an environment variable to "fake" compatibility profile was sufficient.

Are you sure Wine actually uses a mix of new and deprecated features, or does it just ask for a compatibility profile ? I found the statement about requiring compatibility profiles for now...

- Since the support for OpenGL core contexts in WineD3D is not
complete enough yet, Direct3D 10 and 11 need to be supported in a legacy context / the compatibility profile, which means that they currently don't work on Mesa.

https://www.winehq.org/announce/1.8

... but I also found examples where override via environment variable seemed to be enough:

Use MESA_GL_VERSION_OVERRIDE=4.1COMPAT for wine MESA_GL_VERSION_OVERRIDE=4.1COMPAT wine ./Dx11_GAME.exe

http://www.gearsongallium.com/?p=2875

[boltronics]

Sorry for the late response.

https://www.winehq.org/wwn/404#Direct3D%2011%20development

"An open issue with anything newer than Direct3D9 is that wined3d still depends on legacy OpenGL 2 features and many drivers do not expose some features necessary for d3d10/11 in legacy contexts. With the MaxVersionGL key set wined3d will request a core context, but certain blitting corner cases are still broken."

I know that Killing Floor 2 renders worse with the registry key and environment variable override on Mesa than AMDGPU Pro does currently.