Expose primitive ordered pixel shaders

[Degerz]

According to the Vega ISA documentation, this feature uses the SOPP scalar microcode format. Currently, this feature is only exposed in AMD's D3D12 drivers as "rasterizer ordered views" so I'd like to see a mirror equivalent supported in Vulkan as well known as VK_EXT_fragment_shader_interlock.

We need this feature to emulate a certain PowerVR GPU for our use case and particularly we want the fragmentShaderPixelInterlock feature exposed from the extension so can your team enable this for the Vulkan drivers ? (Bonus if the team can also get fragmentShaderSampleInterlock exposed too) Also if you are working on this extension can we also get an estimate of when a driver will be released to support the extension/feature ?

[Degerz]

Can I get a response from the team ?

[jinjianrong]

Our stance is that we don’t want to implement it. It messes with subpasses and is not the right formulation

[Degerz]

What exactly do you mean by "not the right formulation" ? Is this extension somehow the wrong abstraction to map to this feature inside the hardware ?

If so, is there a better way to expose it like a potential framebuffer fetch extension ? (I don't think AMD HW supports multiple render targets so things could get sketchy)

How is the interlocks extension different compared to your "primitive ordered pixel shaders" ? Because we badly need this extension or something similar to a framebuffer fetch.

[Degerz]

How would you like to proceed with this ?

Can we at least get a vendor extension from AMD exposing this directly if your team doesn't like how interlocks are specified or would you prefer to close this issue if you have no intention of exposing similar functionality in Vulkan ?

I am requesting this because there's arguably a stronger case to have ROV-like functionality exposed in Vulkan rather than in D3D12 because there's a higher interest from open source projects in using it than AAA game engine developers.

[oscarbg]

@Degerz @jinjianrong it's sad to see AMD has no plans to support this extension on AMD Vulkan driver even now that VK_EXT_fragment_shader_interlock is a de facto "standard" by the fact that is supported by all other vendors (NV &Intel) and all other OSes (Windows & Linux):
you can see on Windows is supported on "recent" NV (>=Maxwell) & Intel GPUs (>=gen9 Skylake):
https://vulkan.gpuinfo.org/listdevices.php?platform=windows&extension=VK_EXT_fragment_shader_interlock
similarly on Linux supported on NV&Intel:
https://vulkan.gpuinfo.org/listdevices.php?platform=linux&extension=VK_EXT_fragment_shader_interlock

heck even since Metal2.0 on MacOS we have support for exact same feature.. on Vega cards on Imac Pro we get "RasterOrderGroupsSupported"..

adding more use cases:
should be useful for VKD3D project for supp. D3D12 "rasterizer ordered views" in case any D3D12 games use it..

well in fact, Xenia emulator D3D12 backend uses ROV feature for better emulation of Xbox EDRAM hardware.. also Xenia is working towards adding Linux support:
xenia-project/xenia#1430
and has a more immature Vulkan backend that Linux backend would use..
Xenia VK backend could take advantage of VK_EXT_fragment_shader_interlock for better/faster emulation of Xbox hardware..
so joining @Triang3l to discussion in case it wants to discuss further..

EDIT:
even it could be supported on MacOS MoltenVK Vulkan driver so I asked for it:
KhronosGroup/MoltenVK#630

[Degerz]

@oscarbg Good idea to get more people interested in this functionality, I think I'll do the same as well! While you're at it, can you go request other AMD engineers like @Anteru on twitter to show that the community wants this functionality as well on AMD HW on Vulkan.

cc @tadanokojin @hrydgard @pent0

The above have actively expressed interest and/or already using functionality similar to shader interlock in their projects. One of their main motivations to using Vulkan is getting access to modern GPU features like interlock so we'd prefer it from AMD if we didn't have to move over to platform specific APIs like Metal or D3D12 to be able to use this feature!

Vulkan subpasses are possibly not powerful enough for their purposes. I don't care if AMD doesn't ever expose VK_EXT_fragment_shader_interlock but please at least give another viable alternative for their sake even if it is an AMD specific extension!

[pent0]

I just want to do programmable blending. If you guys can provide another primitives it would also be ok, but this is best. Texture barrier (for opengl) is what I am using but not the fastest path really (also for vulkan if appliable). I dont really know how you guys would do it though

[ryao]

How would you like to proceed with this ?

Here is my suggestion. Use the extension and tell users to switch to either Intel or Nvidia graphics hardware because AMD refuses to support the extension and cite this issue. Watch AMD backpedal on this very quickly after an executive hears about the situation.

Also, ask the RADV developers to implement support so that Windows users who want to use software that depends on it have the option of switching to Linux for it.

[Triang3l]

From the passes point of view, what's different in this from regular image/buffer stores?

[Degerz]

@ryao Seems like an unlikely scenario that it would reach to the very high echelons in the company and I don't know if mesa developers are all that interested since I haven't seen any patches related to this issue ...

@Triang3l Here are some insights from Sascha. Along with the stated limitations, I do not think that Vulkan subpasses are capable of handling self-intersecting draws just like OpenGL's texture barrier.

[RussianNeuroMancer]

Seems like an unlikely scenario that it would reach to the very high echelons in the company

News article on Phoronix could help with this a bit.

[ryao]

@ryao Seems like an unlikely scenario that it would reach to the very high echelons in the company and I don't know if mesa developers are all that interested since I haven't seen any patches related to this issue ...

All that you need is for end users to start telling each other that AMD graphics hardware is not friendly to emulators after they start asking why it doesn’t work on AMD graphics hardware. It will reach the upper echelons when they are trying to figure out why they did not meet their sales projections.

As for the mesa developers, they might not know that this extension has any use cases. I was under the impression that those working on RADV were volunteers, so if you don’t ask them about it, they seem less likely to implement it.

[Degerz]

@ryao TBH, I feel it is more constructive for developers like @pent0 to just express their desire to expose this feature and just list out their use cases instead ...

At the end of the day, advanced system emulation doesn't even account for the fraction of AMD's customers and the emulation community is already aware that AMD has a checkered history with them so the leading hardware vendor is already favoured over there.

I'd prefer it if we can show that their driver manager's position is out of touch with the community's position because unlike with higher ups such as executives there's no guarantee that they'd understand this issue or that they'd be specialists regarding GPU drivers to help us out.

[pent0]

I love you guys. I know you can do it however the hard it's. Go go go! We all want this feature.

Also programmable blending is not what emulators want also, it's also what many game developers desired to achieve nice and godly effect on their game, which fixed blending can not do. I can't bring an example for PC but here is an example one doing on Metal IOS.

Programmable shader pipeline has been here for 15 years, so programmable blending should be too. Its the defacto nowadays.(I copy this quote from this article).

I am really bad at wordings hehe, I just express what many people want. Reconsider please :)

[jarrard]

Who exactly does this affect anyway? just PowerVR GPU users? if so I can understand why AMD doesn't want to dedicated valuable development time to this endeavour. Nothing is stopping the community adding it themselves thanks to OPEN-SOURCE drivers!