Hey there, I'm currently facing an issue testing my code on a RadeonVII. My Adrenaline version is 22.5.2
Basically, there are certain shader computations that are wrongly memoized/cached at workgroup level (8x8 pixel blocks). (The application uses a Vulkan 1.1 context.) The following shader snippet is used during runtime to check whether or not a certain combined 2D_ARRAY sampler has more than 1 layers. If so, it is considered a 'terrain texture'.
For greater context, the combined sampler is fetched out of a variable count descriptor set (depending on an instance ID associated with a fragment):
Please note that InstID is evaluated per fragment (this is all in a fragment shader -- attached at the bottom of the post):
However, this value is seemingly only evaluated and cached per 8x8 block resulting in artifacts at runtime:
This is the expected output (using a temporary workaround):
I created a short-circuit in shader code to try and isolate the issue using the following snippet (outputs white for terrain, black for all else):
The issue is visible more clearly. Here is the wrong output:
And here is the expected output (with a workaround):
Please note that I hope to not rely on the workaround (which is to check if alpha on layer 1 is zero)
as something very similar to this issue pops up in other passes that I have not covered in this post. It oddly seems pervasive.(EDIT: Fixed this separate issue via using nonuniformEXT() in all necessary places). Additionally, I do not see issues like this when testing the build on any of my nVidia cards (2080 Ti, 2060 OC or the 1050Ti).
I've uploaded the above test builds isolating the issue:
(Release build): http://www.toomuchvoltage.com/highomega_boolean_wgp_issue.zip
(Debug build): http://www.toomuchvoltage.com/highomega_boolean_wgp_issue_debugbin.zip
I'm also attaching the shader code creating the above for closer examination as well:
Your examination of this is highly appreciated.
With much thanks,
In addition, I would like to post the other instance where such a caching issue seems to appear. This is basically from another pass that is supposed to combine irradiance caching with other values. I've once again short-circuited the shader to highlight the issue: Incorrect output (RadeonVII) (note the distant staircase artifacts highlighted in red): Expected output (rendered on a GTX 1050Ti): I have not been able to fully isolate the origin of this artifact. However, the full shader code can be found here: http://www.toomuchvoltage.com/modulate.frag I can provide a separate build for this upon request. Thanks again, Baktash.
EDIT: This issue has been resolved. Explicitly sized sampler arrays were accessed without nonuniformEXT(). The original issue still persists however.
Interesting. I've seen that exact type of weird "edge aliasing" around the player weapon when playing The Cycle:Frontier. Usually when moving from light to dark (or vice versa) areas. Can't provide any precise reproduction method, but it's consistently something I notice while playing the game. MSI 6800XT, AMD Adrenalin v22.5.1.
also there are a lot of posts about how the AMD driver just renders 3d things into a 2d texture on openGL
this never got fixed either, maybe the same thing?
Hey everybody, as much as I appreciate the conversation I kindly ask that we wait for feedback from AMD.
A lot of the issues you're posting are -- I'm afraid -- unrelated. The issue I've posted is strictly in the fragment stage. A lot of what you're posting has in one way or another something to do with the vertex processing stage.
EDIT: I'm not sure if this is the right place to post these. If not, please kindly direct me towards the right sub-community. Appreciated!
Hey everyone, I believe we now have a greater degree of certainty regarding this being a driver issue.
The Radeon GPU Analyzer produced this compiled shader code using a simplified version of the fragment shader provided.
It is apparent that nonuniformEXT() is not taking effect on the textureSize() call thus resulting in undefined behavior on Radeon drivers.
As can be witnessed from above, the image_get_resinfo instruction reads out of register v0 to determine image dimensions. However, v0 itself is loaded only from the first lane (which is possibly shared among the entire workgroup). Consulting the following article, it appears that nonuniformEXT() is simply not taking effect:
You may do better posting on one of the 'Communities > Developers' forums.
That will exclude random/unrelated issues ?
Yes to whitelisting, why, do you have a problem with that. Seems the sensible option to me if i was a Dev. with your card.
You have a much wider range of options with replies from other Dev. gurus ?
Just trying to possibly point you in the right direction. You can link this thread and they may move it to the appropriate section.
Have you started a discussion https://community.amd.com/t5/newcomers-start-here/bd-p/newcomer-forum
I don't see one on your profile ?