Bug 28860

Log was too large to attach, so here it is instead:
http://whiz.se/temp/yofrankie-fp.log.gz

dmesg output:

[30481.511833] [drm:r100_cs_track_check] *ERROR* [drm] Buffer too small for color buffer 0 (need 1310720 have 1228800) !
[30481.511837] [drm:r100_cs_track_check] *ERROR* [drm] color buffer 0 (640 4 0 512)
[30481.511839] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
[30481.858013] [drm:r100_cs_track_check] *ERROR* [drm] Buffer too small for color buffer 0 (need 1310720 have 1228800) !
[30481.858017] [drm:r100_cs_track_check] *ERROR* [drm] color buffer 0 (640 4 0 512)
[30481.858019] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !

(In reply to comment #0)
> yofrankie-linux-i386.bin: state_tracker/st_mesa_to_tgsi.c:181: dst_register:
> Assertion `t->outputMapping[index] <
> (sizeof(t->outputs)/sizeof(*(t->outputs)))' failed.

This looks similar to bug 28169, should be fixed with commit 6e83420ee0ccb2228fab0f86a6e8bf8a6aefe57a

Created attachment 36701 [details]
Backtrace of crash

(In reply to comment #3)
> 
> This looks similar to bug 28169, should be fixed with commit
> 6e83420ee0ccb2228fab0f86a6e8bf8a6aefe57a

Still crashes with the same assertion failure. I'm attaching a backtrace.

Created attachment 36892 [details]
Yo Frankie screenshot

Now using git master 61a26cdfdc9c75a83c0d362c973d5436fe077be4 it no longer crashes, but the game does look kinda trippy ;-)

Can you post the output with RADEON_DEBUG=fp from the most recent git version.

(In reply to comment #6)
> Can you post the output with RADEON_DEBUG=fp from the most recent git version.

Sure, here's a new log from git master 8a8e311d8c3c60982d101826a4aa013672730e6c
http://whiz.se/temp/yofrankie-fp.log.gz

Created attachment 36940 [details]
Failing shaders

I pulled 1 of the 3 failing shaders from the error log.  If you have some familiarity with assembly code, you can look through the log and try to find optimization opportunities that would reduce the number of instructions we need to emit.  This would be very helpful. I would recommend looking at the code after the dataflow passes, because at this point most of our optimizations have already been done.  If you are unsure of what the instructions do, their definitions are in this file: src/mesa/drivers/dri/r300/compiler/radeon_opcodes.h

(In reply to comment #8)
> 
> I pulled 1 of the 3 failing shaders from the error log.  If you have some
> familiarity with assembly code, you can look through the log and try to find
> optimization opportunities that would reduce the number of instructions we need
> to emit.  This would be very helpful. I would recommend looking at the code
> after the dataflow passes, because at this point most of our optimizations have
> already been done.  If you are unsure of what the instructions do, their
> definitions are in this file:
> src/mesa/drivers/dri/r300/compiler/radeon_opcodes.h

Thanks for having a look at the bug! Unfortunately I don't think I can be of much help, this sounds like something well above my meager skills.

Created attachment 37010 [details] [review]
Hacked together presubtract support

Can you try again with this patch applied to master and post the output with RADEON_DEBUG=fp.  Also, if you notice anything new that this patch breaks, let me know.

Created attachment 37050 [details]
Yo Frankie screenshot

Awesome, thanks for taking an interest!

It's still not working correctly, I'm attaching a new screenshot. I'm also getting these errors now:

 radeon: The kernel rejected CS, see dmesg for more information.

 Jul 14 21:28:43 zoe kernel: [21717.383601] [drm:r100_cs_track_check] *ERROR* [drm] Buffer too small for color buffer 0 (need 1310720 have 1228800) !
 Jul 14 21:28:43 zoe kernel: [21717.383605] [drm:r100_cs_track_check] *ERROR* [drm] color buffer 0 (640 4 0 512)
 Jul 14 21:28:43 zoe kernel: [21717.383607] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !

The log file at http://whiz.se/temp/yofrankie-fp.log.gz has been updated.

If you revert 8c836f7f740c6f74511c727c7bed0680ddba9974, do those messages go away?

(In reply to comment #12)
> If you revert 8c836f7f740c6f74511c727c7bed0680ddba9974, do those messages go
> away?

No, no difference.

Can you try again with the latest git version and post the output of RADEON_DEBUG=fp.

*** Bug 29683 has been marked as a duplicate of this bug. ***

Created attachment 38035 [details]
Log produced with RADEON_DEBUG=fp

There you go. Created with a RV505 (Radeon X1550) with the latest git (as of commit 0eac4b8740d4434037677166f2339e894d4ebac4 "evergreen : initial support driver code.")

The situation with yo frankie has improved somewhat with the most recent builds; my guess is that commit a35faa6a41eb8a240f8e6086853653e9a21e75bd helped, since it reduced considerably the number of instructions generated by the IR generator

Created attachment 38425 [details]
Improved screenshot

This screenshot shows the status as of september 4

Created attachment 38426 [details]
Improved log with RADEON_DEBUG=fp

This log was too long to attach; I'll upload it in two parts; just join them with "cat" in order to obtain a bzip2-compressed text file

Created attachment 38427 [details]
Improved log with RADEON_DEBUG=fp, part 2

"cat" it with part 1 to obtain yofrankie-debug-fp-improved.txt.bz2

Can you try again with the presub-rebase-v2 branch from git://anongit.freedesktop.org/~tstellar/mesa and post the output of RADEON_DEBUG=fp and a screenshot.

To test this branch from your mesa git directory do:

git fetch git://anongit.freedesktop.org/~tstellar/mesa presub-rebase-v2:presub-rebase-v2

git checkout presub-rebase-v2

Then configure and build like normal.

Created attachment 38549 [details]
Screenshot with presub

(In reply to comment #21)
> Can you try again with the presub-rebase-v2 branch from
> git://anongit.freedesktop.org/~tstellar/mesa and post the output of
> RADEON_DEBUG=fp and a screenshot.
> 

I'm attaching a new screenshot, log is too big to attach so it's available here:
http://www.whiz.se/temp/log.gz

Created attachment 38568 [details]
Screenshot with the "presub" branch

Your branch seems to improve some things (the tree trunk now looks OK) and break others (the water and the main character look wrong); in any case, I'll keep your branch on speed dial if you need me to test anything.

Created attachment 38569 [details]
Log generated with RADEON_DEBUG=fp, part 1

Created attachment 38570 [details]
38569: Log generated with "presub" branch and RADEON_DEBUG=fp, part 2

join with part 1 to get yofrankie-presub.txt.bz2

Is this still an issue with current mesa git?

(In reply to comment #26)
> Is this still an issue with current mesa git?

The game segfaults with current git. I'll try to bisect and file a new bug for this regression.

(In reply to comment #26)
> Is this still an issue with current mesa git?

As of commit c1928c7f1065876345d00477eac5558f4cf85158, I still get incorrect rendering; I'll attach a screenshot

Created attachment 40301 [details]
Status as of commit c1928c7f1065876345d00477eac5558f4cf85158

Can you try this again with the latest git master?

(In reply to comment #30)
> Can you try this again with the latest git master?

A dramatic improvement! Now it is almost completely correct; the only misrenderings I can see (I'll attach a screenshot) are:

1) you can see the triangle edges in the main character, and
2) his shadow is completely black (should show the ground texture, only darker).

And I still get the "too many instructions" errors:

r300 FP: Compiler Error:
emit_tex: Too many instructionsUsing a dummy shader instead.
r300 FP: Compiler Error:
r500_fragprog_emit.c::emit_paired(): emit_alu: Too many instructions
Using a dummy shader instead.
r300 FP: Compiler Error:
r500_fragprog_emit.c::emit_paired(): emit_alu: Too many instructions
Using a dummy shader instead.

Don't know if they have to do with this remaining misrenderings, tho.

Plus, it takes two full minutes to compile the shaders before starting the
game; but that's an optimization problem, not of functionality.

But, all in all, the game works almost perfectly now. I think we are almost ready to close this bug.

Created attachment 40483 [details]
With Tom Stellard's most recent patches

Compare with https://bugs.freedesktop.org/attachment.cgi?id=38000, the correct rendering

1) I guess the reason the shadow is black is we don't implement GL_ARB_shadow_ambient. With the driver which can render the shadow correctly, try to set this environment variable:

MESA_EXTENSION_OVERRIDE=-GL_ARB_shadow_ambient

to temporarily disable GL_ARB_shadow_ambient, and see if the shadow becomes black.

2) I know of the wireframe issue, it's been bugging me since ever. It can be seen e.g. in ETQW on the water and in Nexuiz with GLSL enabled. I think it only shows up on R500.

(In reply to comment #33)
> 1) I guess the reason the shadow is black is we don't implement
> GL_ARB_shadow_ambient. With the driver which can render the shadow correctly,
> try to set this environment variable:
> 
> MESA_EXTENSION_OVERRIDE=-GL_ARB_shadow_ambient
> 
> to temporarily disable GL_ARB_shadow_ambient, and see if the shadow becomes
> black.

The driver that renders correctly is the proprietary one, which doesn't use Mesa variables.


> 2) I know of the wireframe issue, it's been bugging me since ever. It can be
> seen e.g. in ETQW on the water and in Nexuiz with GLSL enabled. I think it only
> shows up on R500.

I can also see it in the water in sauerbraten (although it is almost
imperceptible there); You can count on me to debug/test that.

(In reply to comment #27)
> 
> The game segfaults with current git. I'll try to bisect and file a new bug for
> this regression.

Bug 31907 has been filed for this, in case anyone else has the same problem.

(In reply to comment #34)
> (In reply to comment #33)
> > 1) I guess the reason the shadow is black is we don't implement
> > GL_ARB_shadow_ambient. With the driver which can render the shadow correctly,
> > try to set this environment variable:
> > 
> > MESA_EXTENSION_OVERRIDE=-GL_ARB_shadow_ambient
> > 
> > to temporarily disable GL_ARB_shadow_ambient, and see if the shadow becomes
> > black.
> 
> The driver that renders correctly is the proprietary one, which doesn't use
> Mesa variables.

OK then, let's assume it's because GL_ARB_shadow_ambient is missing, therefore it's not a bug, it's a feature.

> > 2) I know of the wireframe issue, it's been bugging me since ever. It can be
> > seen e.g. in ETQW on the water and in Nexuiz with GLSL enabled. I think it only
> > shows up on R500.
> 
> I can also see it in the water in sauerbraten (although it is almost
> imperceptible there); You can count on me to debug/test that.

I'd like to have a separate bug for this issue, though it's not like I know how to fix it.

Since there is no other reported misrendering related to this bug, I am closing it.