https://bugs.freedesktop.org/show_bug.cgi?id=28860

--- Comment #2 from Sven Arvidsson sa@whiz.se 2010-06-30 13:07:55 PDT --- 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 !

https://bugs.freedesktop.org/show_bug.cgi?id=28860

--- Comment #4 from Sven Arvidsson sa@whiz.se 2010-07-02 15:22:54 PDT --- Created an attachment (id=36701) --> (https://bugs.freedesktop.org/attachment.cgi?id=36701) 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.

https://bugs.freedesktop.org/show_bug.cgi?id=28860

Sven Arvidsson sa@whiz.se changed:

What |Removed |Added ---------------------------------------------------------------------------- Summary|[r300g] Yo Frankie crash: |[r300g] Yo Frankie - |assertion failure / Too |shaders not working: Too |many hardware temporaries |many instructions |used |

https://bugs.freedesktop.org/show_bug.cgi?id=28860

--- Comment #7 from Sven Arvidsson sa@whiz.se 2010-07-09 06:46:32 PDT --- (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

https://bugs.freedesktop.org/show_bug.cgi?id=28860

--- Comment #9 from Sven Arvidsson sa@whiz.se 2010-07-11 10:05:51 PDT --- (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.

https://bugs.freedesktop.org/show_bug.cgi?id=28860

Sven Arvidsson sa@whiz.se changed:

What |Removed |Added ---------------------------------------------------------------------------- Attachment #36892|0 |1 is obsolete| |

--- Comment #11 from Sven Arvidsson sa@whiz.se 2010-07-14 12:37:34 PDT --- Created an attachment (id=37050) --> (https://bugs.freedesktop.org/attachment.cgi?id=37050) 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.

https://bugs.freedesktop.org/show_bug.cgi?id=28860

--- Comment #13 from Sven Arvidsson sa@whiz.se 2010-07-15 04:58:11 PDT --- (In reply to comment #12)

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

No, no difference.

https://bugs.freedesktop.org/show_bug.cgi?id=28860

Tom Stellard tstellar@gmail.com changed:

What |Removed |Added ---------------------------------------------------------------------------- CC| |rubenf3000@gmail.com

--- Comment #15 from Tom Stellard tstellar@gmail.com 2010-08-20 06:55:03 PDT --- *** Bug 29683 has been marked as a duplicate of this bug. ***

https://bugs.freedesktop.org/show_bug.cgi?id=28860

--- Comment #17 from Rubén Fernández rubenf3000@gmail.com 2010-09-04 03:44:48 PDT --- 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

https://bugs.freedesktop.org/show_bug.cgi?id=28860

--- Comment #19 from Rubén Fernández rubenf3000@gmail.com 2010-09-04 03:47:40 PDT --- Created an attachment (id=38426) --> (https://bugs.freedesktop.org/attachment.cgi?id=38426) 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

https://bugs.freedesktop.org/show_bug.cgi?id=28860

--- Comment #21 from Tom Stellard tstellar@gmail.com 2010-09-07 22:23:35 PDT --- 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.

https://bugs.freedesktop.org/show_bug.cgi?id=28860

--- Comment #23 from Rubén Fernández rubenf3000@gmail.com 2010-09-08 15:56:04 PDT --- Created an attachment (id=38568) --> (https://bugs.freedesktop.org/attachment.cgi?id=38568) 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.

https://bugs.freedesktop.org/show_bug.cgi?id=28860

--- Comment #25 from Rubén Fernández rubenf3000@gmail.com 2010-09-08 15:58:39 PDT --- Created an attachment (id=38570) --> (https://bugs.freedesktop.org/attachment.cgi?id=38570) 38569: Log generated with "presub" branch and RADEON_DEBUG=fp, part 2

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

https://bugs.freedesktop.org/show_bug.cgi?id=28860

--- Comment #26 from Marek Olšák maraeo@gmail.com 2010-11-13 12:36:27 PST --- Is this still an issue with current mesa git?

https://bugs.freedesktop.org/show_bug.cgi?id=28860

--- Comment #28 from Rubén Fernández rubenf3000@gmail.com 2010-11-15 18:23:31 PST --- (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

https://bugs.freedesktop.org/show_bug.cgi?id=28860

--- Comment #30 from Tom Stellard tstellar@gmail.com 2010-11-21 21:50:15 PST --- Can you try this again with the latest git master?

https://bugs.freedesktop.org/show_bug.cgi?id=28860

--- Comment #32 from Rubén Fernández rubenf3000@gmail.com 2010-11-22 11:49:15 PST --- Created an attachment (id=40483) --> (https://bugs.freedesktop.org/attachment.cgi?id=40483) With Tom Stellard's most recent patches

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

https://bugs.freedesktop.org/show_bug.cgi?id=28860

--- Comment #34 from Rubén Fernández rubenf3000@gmail.com 2010-11-22 17:44:34 PST --- (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.

https://bugs.freedesktop.org/show_bug.cgi?id=28860

Marek Olšák maraeo@gmail.com changed:

What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED

--- Comment #36 from Marek Olšák maraeo@gmail.com 2010-11-24 16:03:21 PST --- (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.