Created attachment 138105 [details] Screenshot MSAA is broken on Vulkan with SI card (Pitcairn) causing graphical artefacts. All MSAA modes are affected. OpenGL works. The same code works on Windows with AMD's driver and on Nvidia GPU with their proprietary drivers. No warnings from Vulkan validation layers. Broken versions are 17.3.6 (Debian package), 18.0.0rc4 (likewise) and master fcf267ba087dd00c48ceaf9277424dac079f9319 (self-built, with LLVM 6.0). Kernel is 4.14.17 from Debian testing. The test program is here: https://github.com/turol/smaaDemo Use command line parameters "-m msaa -q 8" to get directly to the broken effect. #103999 is possibly related but I'm using RGBA8srgb instead of RG32F.
Created attachment 138106 [details] vulkaninfo output
Created attachment 138107 [details] dmesg output
Created attachment 138108 [details] vktrace trace
As discussed on #dri-devel, the example application contains several layout issues such as 1) using UNDEFINED as the source layout for the vkCmdResolveImage. 2) using UNDEFINED as the initial layout for the second renderpass when you want to preserve contents. These caused issues with MSAA on a Vega. I am not completely certain that fixing these will fix SI. Please fix these and then take a look in renderdoc on where it is going wrong. If you still suspect the driver after that we can take another look.
I recommend you file a bug against the validation layers as at least the first of the two comments Bas made should be invalid. The second is valid but does not do what you want.
Looks like there's already a validation layer issue about this: https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/issues/1656. I added my report there. The bad layouts were caused by a bug in the program where it failed to correctly track the current layout. I fixed this but the artifacts still occur so reopening. If debugging in RenderDoc you can pass "--trace" command line parameter and smaaDemo will set readable names for the various objects. Whether this helps or not is of course up to preference.
Created attachment 138130 [details] vktrace trace from the fixed app
Looks like this might have been my bug after all. I was specifying subpass dependencies with separate VkSubpassDependency for color and depthstencil attachments but the same srcSubPass and dstSubPass. The idea was that the driver would be able to use finer-grained barriers if it wanted. The other drivers treated these as union of dependencies, radv was only taking the last one and missing some color writes. ORing everything together makes this work. In case my explanation was unclear here is the fix: https://github.com/turol/smaaDemo/commit/34a79f076ebab7a661d8705c4adcb2d5b3258281 The Vulkan spec doesn't seem clear on whether this is allowed or not. I think in theory it would be useful to specify for example that depth test/write can proceed differently from color write.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.