| Summary: | [r300g] loop unrolling fails (was: Savage 2 : characters are not rendered + another corruptions) | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Pavel Ondračka <pavel.ondracka> |
| Component: | Drivers/DRI/r300 | Assignee: | Default DRI bug account <dri-devel> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | sa |
| Version: | git | Keywords: | NEEDINFO |
| Hardware: | Other | ||
| OS: | All | ||
| URL: | http://www.savage2.com/en/download.php | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
full terminal output
screenshot RADEON_DEBUG=vp log RADEON_DEBUG=vp log with patch from 29363 RADEON_DEBUG=vp log with vs-if-loop.patch Screenshot of oversized character Reduce the number of loop iterations Screenshot of smearing in menu RADEON_DEBUG=vp output with mesa 79088746a231d361232fc87ab4d578b08c7ce2a7 |
||
|
Description
Pavel Ondračka
2010-06-13 02:58:24 UTC
Created attachment 36243 [details]
screenshot
I forgot to mention, all game graphic settings are set to lowest possible. With current mesa git compiler error looks different: r300 VP: Compiler error: Ran out of temporary registers Using a dummy shader instead. If there's an 'unknown opcode' message, please file a bug report and attach this log. However rendering problems still remain. FWIW: the problem with the white top of the screen is the same on Intel with the i965 driver, so it's probably a general problem with Mesa. (In reply to comment #4) > FWIW: the problem with the white top of the screen is the same on Intel with > the i965 driver, so it's probably a general problem with Mesa. Maybe this bug needs splitting, or is there already bug opened about this problem with i965 driver? However I'm not sure if this is the same issue, I think the DRI and gallium drivers use different codepaths? (In reply to comment #5) > Maybe this bug needs splitting, or is there already bug opened about this > problem with i965 driver? > However I'm not sure if this is the same issue, I think the DRI and gallium > drivers use different codepaths? Well, there's bug 27028, a general bug for getting Savage 2 running on Intel (at the moment it's only possible by increasing the loop unrolling limits). Can you try again with the latest git code and post the output with RADEON_DEBUG=vp Created attachment 37624 [details] RADEON_DEBUG=vp log (In reply to comment #7) > Can you try again with the latest git code and post the output with > RADEON_DEBUG=vp Sure! Attaching a gzipped log. This patch: https://bugs.freedesktop.org/attachment.cgi?id=37644 from bug 29363 should help with this bug too. Created attachment 37647 [details] RADEON_DEBUG=vp log with patch from 29363 (In reply to comment #9) > This patch: https://bugs.freedesktop.org/attachment.cgi?id=37644 from bug 29363 > should help with this bug too. There's not much of a difference visually, it might actually be a little worse with this patch. Not sure if that's much to go on though. I'm also getting a lot of "Out of hw temporaries" warnings. Attaching a new log with RADEON_DEBUG=vp if that's of any use. Can you try this patch https://bugs.freedesktop.org/attachment.cgi?id=37755 from bug 29363 and post the output of RADEON_DEBUG=vp. Created attachment 37759 [details]
RADEON_DEBUG=vp log with vs-if-loop.patch
Characters are being rendered now with your patch, but they are completely wrong, I would say they are too big and there are many another problems.
Created attachment 37768 [details] Screenshot of oversized character I added a screenshot of the character, if that's helpful. The slowdown mentioned in bug 29363 is also present in this game, but I guess that might be secondary issue. The bug with the character might be something general in Mesa, and not in r300g since it's almost the same in i965. With latest mesa git problem with top half of the screen being white is fixed, however characters are still corrupted, this is even worse than before glsl2 merge. As Sven Arvidsson said this may be a more generic problem, see similar problems described in bug 27028. However I suspect r300 compiler to also have some troubles because of the big slowdown introduced with Tom Stellards vertex shader loops patches. Can you point to the vertex shader loops patches which cause problems for you? Does reverting them help? (In reply to comment #13) > Created an attachment (id=37768) [details] > Screenshot of oversized character > > I added a screenshot of the character, if that's helpful. > > The slowdown mentioned in bug 29363 is also present in this game, but I guess > that might be secondary issue. The performance decrease you are seeing is because the correct vertex shaders are being used now instead of dummy shaders. (In reply to comment #17) > The performance decrease you are seeing is because the correct vertex shaders > are being used now instead of dummy shaders. I should add that there are still some optimizations that can be done with vertex shader loops, but I can't really predict how much these optimizations will improve performance. (In reply to comment #17) > (In reply to comment #13) > > Created an attachment (id=37768) [details] [details] > > Screenshot of oversized character > > > > I added a screenshot of the character, if that's helpful. > > > > The slowdown mentioned in bug 29363 is also present in this game, but I guess > > that might be secondary issue. > > The performance decrease you are seeing is because the correct vertex shaders > are being used now instead of dummy shaders. OK this explains everything, except that at this point the vertex shaders are not correct... do you need any more logs? However there is probably no rush to fix this, since the game wont be playable anyway, unless the possible optimization speedup is really huge :-( With latest git master (commit b5c07b9226d8e7de78f6367b5799b39caf820ef3) I only get a black background and a mouse cursor. As for performance, it is much much slower than on my Intel IGP, slow enough that you need to wait for the mouse cursor to move, so something seems to be wrong. That doesn't sound good. Is there anything in dmesg? Perhaps you are just being successfully recovered from a hard lockup every frame. No, nothing in dmesg. And just to clarify, it's only the game that's black, X is unaffected. I'll see if I can figure out where it broke, as it was working at least a little bit better before. Dunno why, but the black screen was caused by libtxc_dxtn, removing it made the problem go away. Anyway, some more observations about the performance problem: * It's not CPU-related, the game is only using about 60-70% on my system, so shouldn't be a problem. * If run the game in a window, all other graphics related operations (such as moving windows) slows to a crawl. * There's no significant difference in performance if I set all video options in the game to their lowest setting. Another game (from the same developers) that's having the same problem, is Heroes of Newerth. http://www.heroesofnewerth.com/download.php (Sorry for the bug spam) The performance problem I'm having seems to be a result of the glsl2 merge, and not from the vs loops. So I guess that's a different problem than what Pavel have described. (In reply to comment #20) > With latest git master (commit b5c07b9226d8e7de78f6367b5799b39caf820ef3) I only > get a black background and a mouse cursor. > > As for performance, it is much much slower than on my Intel IGP, slow enough > that you need to wait for the mouse cursor to move, so something seems to be > wrong. Is the rendering correct on Intel hardware? If the rendering isn't correct anywhere, then the performance issues are irrelevant. The performance will change, one way or the other, when the correctness is fixed. (In reply to comment #25) > Is the rendering correct on Intel hardware? If the rendering isn't correct > anywhere, then the performance issues are irrelevant. The performance will > change, one way or the other, when the correctness is fixed. No, it isn't correct on i965 either. Last word was that it was a bug in the preprocessor, see bug 27028. (In reply to comment #26) > (In reply to comment #25) > > Is the rendering correct on Intel hardware? If the rendering isn't correct > > anywhere, then the performance issues are irrelevant. The performance will > > change, one way or the other, when the correctness is fixed. > > No, it isn't correct on i965 either. Last word was that it was a bug in the > preprocessor, see bug 27028. The preprocessor test mentioned in that bug seems to work correctly now. I believe that one is fixed. (In reply to comment #24) > (Sorry for the bug spam) > > The performance problem I'm having seems to be a result of the glsl2 merge, and > not from the vs loops. So I guess that's a different problem than what Pavel > have described. Hm, I don't really get this, I thought you also suffered from the slowdown problem with vs loops patches long before glsl2 was merged (as indicated in comment 13)? Never mind, I'll repeat my bisecting later today, maybe I did something wrong last time. Created attachment 38306 [details] [review] Reduce the number of loop iterations Does this patch impact performance at all? (In reply to comment #29) > Created an attachment (id=38306) [details] > Reduce the number of loop iterations > > Does this patch impact performance at all? No noticeable difference with you patch. BTW I did repeat bisecting and it again showed commit c298bab60ea63882f34825a35cbc60f662783e64 as the one introducing this slowness. So indeed your analysis in comment 17 looks right. I wasn't able to bisect any further slowdown with glsl2 merge which Sven mentioned in comment 24. However we might have different setups because for example I don't have any troubles with libtxc_dxtn.so (In reply to comment #29) > Created an attachment (id=38306) [details] > Reduce the number of loop iterations > > Does this patch impact performance at all? No noticeable difference here either. I did notice a few compile errors though: r300 FP: Compiler Error: Fragment program does not support relative addressing of source operands. Using a dummy shader instead And I'm getting these errors: radeon: The kernel rejected CS, see dmesg for more information. dmesg: [340535.918564] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream ! [340536.199125] [drm:r100_cs_track_check] *ERROR* [drm] Buffer too small for color buffer 0 (need 4194304 have 3145728) ! [340536.199129] [drm:r100_cs_track_check] *ERROR* [drm] color buffer 0 (1024 4 0 1024) This behaviour is the same with or without the patch. Interesting, the game seems to be rendering fine when llvmpipe is used. (In reply to comment #31) > (In reply to comment #29) > > Created an attachment (id=38306) [details] [details] > > Reduce the number of loop iterations > > > > Does this patch impact performance at all? > > No noticeable difference here either. > > I did notice a few compile errors though: > r300 FP: Compiler Error: > Fragment program does not support relative addressing of source operands. > Using a dummy shader instead This may be fixed now that loop unrolling is merged. Can you retest? Created attachment 38409 [details] Screenshot of smearing in menu (In reply to comment #33) > > This may be fixed now that loop unrolling is merged. Can you retest? It is if not fixed, at least a whole lot better now! :) Fixed: * The model in the menu and the player character is rendered correctly as far as I can tell. * The horrible slowdown is gone. Remaining problems are: * "Smearing" in the menu (see screenshot for a better explanation) probably because I'm still getting "radeon: The kernel rejected CS, see dmesg for more information." errors logged in the terminal. * Ingame, all textures seems to be white, not sure if this is related to my problems with S3TC or something else. So the GLSL side of things seems to have been taken care of! Can you repost the output of RADEON_DEBUG=vp with the latest git version? I want to see what the shaders look like with loop unrolling. Created attachment 38421 [details]
RADEON_DEBUG=vp output with mesa 79088746a231d361232fc87ab4d578b08c7ce2a7
This is with latest mesa and graphic settings set to lowest possible (no glitches with lowest settings).
(In reply to comment #36) > > This is with latest mesa and graphic settings set to lowest possible (no > glitches with lowest settings). Good catch, it's seems to be working well on lowest settings here too! Maybe we should consider this bug done and file new reports for the remaining issues? (In reply to comment #37) > (In reply to comment #36) > > > > This is with latest mesa and graphic settings set to lowest possible (no > > glitches with lowest settings). > > Good catch, it's seems to be working well on lowest settings here too! > > Maybe we should consider this bug done and file new reports for the remaining > issues? OK, closing, we spammed this report too much already. File new bugs if you want. I'm not interested in higher settings since the game isn't fast enough to be playable even with lowest settings here with my RV530 :-( Remaining issue filed as bug 30036. |
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.