Created attachment 38673 [details] Screenshot on medium setting In the game Heroes of Newerth, turning the setting "Shader Quality" to medium or high results in corrupt rendering of water. This seems to be a regression from the glsl2 merge, but it seems fine on llvmpipe, so I'm guessing the bug is specific to r300g. I _think_ it's possible to reproduce this bug without buying the game, by only registering and then either starting a practice game or running the tutorial. If not, I'll see about getting some trial invites. The rest of the effects in the game seems to be working fine. System environment: -- system architecture: 32-bit -- Linux distribution: Debian unstable -- GPU: RV570 -- Model: Asus EAX1950Pro 256MB -- Display connector: DVI -- xf86-video-ati: e9928fe036e9382fd7bc353f3f05531445f08977 -- xserver: 1.8.99.904 (1.9.0 RC 5) -- mesa: 6f839eb631511925505093be4d0509ac14f5675b -- drm: 23287f05cf2443ddf9e028e29beb5bd30979c6cf -- kernel: 2.6.35.4
Created attachment 38674 [details] Screenshot on high
Can you try it again with RADEON_DEBUG=noopt. If this fixes it, can you post the output with RADEON_DEBUG=noopt,fp,vp _and_ RADEON_DEBUG=fp,vp. If this doesn't fix it, can you post the output with RADEON_DEBUG=noopt,fp,vp
Created attachment 38934 [details] RADEON_DEBUG=noopt,fp,vp log (In reply to comment #2) > Can you try it again with RADEON_DEBUG=noopt. If this fixes it, can you post > the output with RADEON_DEBUG=noopt,fp,vp _and_ RADEON_DEBUG=fp,vp. If this > doesn't fix it, can you post the output with RADEON_DEBUG=noopt,fp,vp Hmm... I get a different result with noopt, the corruption is less noticeable, mostly in the borders around the water, but the actual visual effect seems to be missing. I'm attaching a log with RADEON_DEBUG=noopt,fp,vp
Created attachment 38935 [details] Screenshot with noopt - settings on medium
Does running with RADEON_DEBUG=noopt and RADEON_NO_TCL=1 help?
(In reply to comment #5) > Does running with RADEON_DEBUG=noopt and RADEON_NO_TCL=1 help? No difference with or without setting RADEON_NO_TCL as far as I can see.
Created attachment 39059 [details] [review] Possible fix Does this patch make any difference?
(In reply to comment #7) > Created an attachment (id=39059) [details] > Possible fix > > Does this patch make any difference? This patch with noopt seems to be the best result yet. I made a bunch of screenshots, comparing llvmpipe with master, master+noopt, the patch, and the patch+noopt: http://www.flickr.com/photos/whizse/
(In reply to comment #8) > > I made a bunch of screenshots, comparing llvmpipe with master, master+noopt, > the patch, and the patch+noopt: http://www.flickr.com/photos/whizse/ Thanks, this was helpful. Can you post the output of RADEON_DEBUG=fp on master with both medium and high settings. Also, is there any chance that this is a regression that can be bisected?
Created attachment 39078 [details] RADEON_DEBUG=fp with medium settings
Created attachment 39079 [details] RADEON_DEBUG=fp with high settings
(In reply to comment #9) > Thanks, this was helpful. Can you post the output of RADEON_DEBUG=fp on master > with both medium and high settings. Done > Also, is there any chance that this is a regression that can be bisected? The regression happened right after the glsl2 merge. I don't think it's possible to pinpoint it down any further.
Can you try this again with the latest version of mesa from git?
(In reply to comment #13) > Can you try this again with the latest version of mesa from git? No change I'm afraid.
Can you try this again with the latest git master?
(In reply to comment #15) > Can you try this again with the latest git master? The problem remains (corrupt rendering with medium and high) but seems to be slightly different now. I have uploaded new screenshots: high: http://www.flickr.com/photos/whizse/5201781578/ medium: http://www.flickr.com/photos/whizse/5201187031/ all previous screenshots are here, for comparison: http://www.flickr.com/photos/whizse/ I also noticed this error message: r300: ERROR: FS input generic 17 unassigned, not enough hardware slots. Let me know if you need new debug dumps or screenshots with noopt.
Is this still an issue with current Mesa master?
(In reply to comment #17) > Is this still an issue with current Mesa master? Yes, this is still an issue with the latest Mesa master.
Just retried this, no change with git master 6ed0f2ac112d22278cf051c2cee9c2199a9025ea
(In reply to comment #16) > I also noticed this error message: > r300: ERROR: FS input generic 17 unassigned, not enough hardware slots. > Since this error now reports that this isn't a bug, is there any point in keeping this bug open?
I don't think so. We can't fix the error, we can only suppress printing it. If there is any issue unrelated to the error, let's keep this report open (is there any?), otherwise I'd close it.
(In reply to comment #21) > I don't think so. We can't fix the error, we can only suppress printing it. If > there is any issue unrelated to the error, let's keep this report open (is > there any?), otherwise I'd close it. There's still a problem with rendering issues when shader quality is set to anything higher than "Low". I was just wondering if this is related to the hardware limitation (the "FS input generic 17 unassigned" warning) rather than bug?
It could be. That FS input may contain random values because it's uninitialized, potentially leading to pixels being influenced by it, resulting in sort of random corruption. It depends on the shader and how much the input contributes to the final pixel color.
This seems to be fixed in the latest mesa git, however I didn't test all the different settings mentioned in Comment 16. Sven can you confirm this is indeed fixed?
(In reply to comment #24) > This seems to be fixed in the latest mesa git, however I didn't test all the > different settings mentioned in Comment 16. Sven can you confirm this is > indeed fixed? I will probably not have time to test this in the foreseeable future, so unless someone else can, I don't mind if the bug is closed.
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.