|Summary:||Some textures now rendered as completely black after register allocator rewrite.|
|Product:||Mesa||Reporter:||Chris Rankin <rankincj>|
|Component:||Drivers/Gallium/r300||Assignee:||Default DRI bug account <dri-devel>|
|Status:||RESOLVED FIXED||QA Contact:|
|i915 platform:||i915 features:|
FP debug output
Output of RADEON_DEBUG=nohiz,fp
Output of RADEON_DEBUG=nohiz,fp
Description Chris Rankin 2011-05-01 15:35:48 UTC
Running World of Warcraft on my M66GL (RV530), and some textures are now rendered as completely black. However, my RV350 is unaffected. git bisect says: fe622bac0c1b5b9f2a9fcf9f35b51232a06bea42 is the first bad commit commit fe622bac0c1b5b9f2a9fcf9f35b51232a06bea42 Author: Tom Stellard <firstname.lastname@example.org> Date: Tue Jan 11 00:05:08 2011 -0800 r300/compiler: Rewrite register allocator The new allocator uses ra and does swizzle packing. Also, a data structure (struct rc_variable) and associated functions have been added for generating UD and DU chains. :040000 040000 545a13a6577705511d30b471d6901237e793679c f27924a4a5a40bab284ea7c03facab6c69875fb9 M src The following error messages are written to the output log: r300 FP: Compiler Error: Rewrite of inst 10 failed Can't allocate source for Inst 13 src_type=1 new_index=2 new_mask=1 Using a dummy shader instead. r300 FP: Compiler Error: Rewrite of inst 14 failed Can't allocate source for Inst 17 src_type=1 new_index=2 new_mask=1 Using a dummy shader instead.
Comment 1 Tom Stellard 2011-05-01 17:22:17 UTC
Can you run the program with RADEON_DEBUG=fp and post the output.
Comment 2 Chris Rankin 2011-05-02 06:04:46 UTC
Created attachment 46250 [details] FP debug output Strictly speaking, this output is from RADEON_DEBUG=nohiz,fp because HiZ is also broken with M66GL chips at the moment.
Comment 3 Tom Stellard 2011-05-04 00:28:04 UTC
(In reply to comment #2) > Created an attachment (id=46250) [details] > FP debug output > > Strictly speaking, this output is from RADEON_DEBUG=nohiz,fp because HiZ is > also broken with M66GL chips at the moment. I'm working on a proper fix for this. In the mean time, running with RADEON_DEBUG=noopt should fix the problem.
Comment 4 Chris Rankin 2011-05-05 13:14:55 UTC
(In reply to comment #3) > In the mean time, running with RADEON_DEBUG=noopt should fix the problem. Indeed it does, thanks.
Comment 5 Tom Stellard 2011-05-15 22:01:41 UTC
Created attachment 46753 [details] [review] Verbose patch The patch will give me some extra debug info. Can you apply it and post the output of RADEON_DEBUG=fp.
Comment 6 Chris Rankin 2011-05-16 16:33:46 UTC
Created attachment 46786 [details] Output of RADEON_DEBUG=nohiz,fp (In reply to comment #5) > The patch will give me some extra debug info. Can you apply it and post the > output of RADEON_DEBUG=fp. As requested.
Comment 7 Tom Stellard 2011-05-17 00:59:25 UTC
Created attachment 46792 [details] [review] Possible Fix Can you try this patch. If it doesn't fix the issue, can you post the output of RADEON_DEBUG=fp again.
Comment 8 Chris Rankin 2011-05-17 10:14:40 UTC
Created attachment 46833 [details] Output of RADEON_DEBUG=nohiz,fp (In reply to comment #7) > Can you try this patch? That seems to have fixed it, thanks. I've attached the RADEON_DEBUG output anyway, so that you can check that it did what you were expecting.
Comment 9 Tom Stellard 2011-05-17 19:18:57 UTC
Fixed in git by commit 217cd216eac65983004ca77a9e49dbfad1b720b6.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.