<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Rendering errors when running dolphin-emu with Vulkan backend, radv (Super Smash Bros. Melee)" href="https://bugs.freedesktop.org/show_bug.cgi?id=103852#c9">Comment # 9</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Rendering errors when running dolphin-emu with Vulkan backend, radv (Super Smash Bros. Melee)" href="https://bugs.freedesktop.org/show_bug.cgi?id=103852">bug 103852</a> from <a class="email" href="mailto:t_arceri@yahoo.com.au" title="Timothy Arceri <t_arceri@yahoo.com.au>"> Timothy Arceri</a> <pre>(In reply to Ben Clapp from <a href="show_bug.cgi?id=103852#c8">comment #8</a>) > Today I spent a number of hours looking at the background rendering errors > in RenderDoc. > > The vertex shader outputs some vertices that have two vertex colors, > colors_0 and colors_1. (Only colors_0 is relevant here) > > The fragment shader does a bunch of fiddling around with colors_0, a lot of > unnecessary conversions and re-assignments that effectively do nothing, and > ultimately the colors_0 value is passed to rastemp and tevin_d. > Some more fiddling around and, in the case of the areas of the screen where > there are rendering errors, the value of colors_0/rastemp/tevin_d ("tevin" > means "TEV input", referring to the Gamecube/Wii's Texture EnVironment > hardware) becomes the color value written to the framebuffer. > > The problem is not in the vertex shader, nor is it in the fragment shader. > For some reason, the value of colors_0 coming out of the vertex shader is > correct, but the value of colors_0 in the fragment shader is inverted! So > blue will appear yellow, black while appear white, etc... > > This seems to be a driver bug after all, and so I did try to spend some time > looking into radv's code to try and see if I could figure out a fix. > The issue might lie in radv_pipeline.c, I would think it probably has > something to do with the inter-stage varying colors_0 not getting filled or > interpreted correctly. > > I've done lots of OpenGL and Vulkan programming, but I have little > experience with the driver side of things, so while it might be interesting > to talk a bit with the radv devs and learn a thing or two, I'm not sure how > much further I can go in terms of looking into this on my own without > assistance. > Do you think you could get a dump of the NIR and LLVM IR for the shaders in question and attach it here? You can use the following environment var to dump the shaders: RADV_DEBUG=shaders You also might be able to catch the attention of some devs if you jump on the freenode #radeon IRC channel.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>