Bug 28294 - [r300g] Unigine Sanctuary v2.2: black glitches
Summary: [r300g] Unigine Sanctuary v2.2: black glitches
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/r300 (show other bugs)
Version: git
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL: http://unigine.com/download/
Whiteboard:
Keywords:
Depends on: 29722
Blocks:
  Show dependency treegraph
 
Reported: 2010-05-28 00:05 UTC by Pavel Ondračka
Modified: 2010-10-30 22:36 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
terminal output (384.52 KB, text/plain)
2010-05-28 00:05 UTC, Pavel Ondračka
Details
screenshot (24.85 KB, image/png)
2010-05-28 00:06 UTC, Pavel Ondračka
Details
output with RADEON_DEBUG="fp" (387.08 KB, application/x-bzip2)
2010-05-31 23:41 UTC, Pavel Ondračka
Details
screenshot with libtxc_dxtn.so (109.27 KB, image/jpeg)
2010-06-09 02:01 UTC, Pavel Ondračka
Details
terminal output with libtxc_dxtn.so (279.51 KB, text/plain)
2010-06-09 02:01 UTC, Pavel Ondračka
Details
output with RADEON_DEBUG="fp" , mesa: 1dc573a881f5b1413d156b64f5fdd0a57825c02a (526.41 KB, application/x-7z-compressed)
2010-06-13 02:17 UTC, Pavel Ondračka
Details
output with RADEON_DEBUG="fp", mesa:0e6d7ce0178d65787e3e10f56638c2f0a88296f1 (487.98 KB, application/x-bzip2)
2010-07-03 01:02 UTC, Pavel Ondračka
Details
screenshot with current mesa master (249.04 KB, image/jpeg)
2010-07-03 01:04 UTC, Pavel Ondračka
Details
screenshot with mesa:697d666d7860b3bdced32ca7fde9dea38f67da15 (188.72 KB, image/jpeg)
2010-07-03 01:08 UTC, Pavel Ondračka
Details
screenshot with NVIDIA proprietary driver (140.72 KB, image/jpeg)
2010-07-03 01:10 UTC, Pavel Ondračka
Details
Implement KILP opcode patch (4.48 KB, patch)
2010-07-05 13:26 UTC, Tom Stellard
Details | Splinter Review
output with KILP patch (526.24 KB, application/x-bzip2)
2010-07-05 14:23 UTC, Pavel Ondračka
Details
output with RADEON_DEBUG="fp" , mesa: 5c2f01bbb076af8b8ae6e1803d95a9ae678c2d1c (404.23 KB, application/x-bzip2)
2010-08-04 01:20 UTC, Pavel Ondračka
Details
screenshot just before 9021c56a5738815777f27c39b63637b5975270c6 (156.51 KB, image/jpeg)
2010-09-17 02:36 UTC, Pavel Ondračka
Details
screenshot with mesa 9021c56a5738815777f27c39b63637b5975270c6 (244.32 KB, image/jpeg)
2010-09-17 02:38 UTC, Pavel Ondračka
Details
screenshot with current mesa git ( dab2a7660a407364a33337327743b56ea9701d9b) (253.73 KB, image/jpeg)
2010-09-17 02:39 UTC, Pavel Ondračka
Details
screenshot (187.99 KB, image/jpeg)
2010-09-27 15:53 UTC, Pavel Ondračka
Details
screenshot with RADEON_DEBUG=noopt + only register allocation done in prog_optimize.c (96.02 KB, image/jpeg)
2010-09-27 16:34 UTC, Pavel Ondračka
Details
screenshot with RADEON_DEBUG=noopt + everything done in prog_optimize.c (131.48 KB, image/jpeg)
2010-09-27 16:35 UTC, Pavel Ondračka
Details
screenshot with mesa dd2499b484b34e7efb8800f57c915c2f62ab1db4 (884.67 KB, image/png)
2010-10-22 10:25 UTC, Pavel Ondračka
Details
output of RADEON_DEBUG=fp,vp,pstat (143.21 KB, application/x-bzip2)
2010-10-23 00:17 UTC, Pavel Ondračka
Details
output with RADEON_DEBUG=noopt,fp,vp,pstat (130.04 KB, application/x-bzip2)
2010-10-23 03:35 UTC, Pavel Ondračka
Details
Proposed Fix (4.73 KB, patch)
2010-10-29 16:55 UTC, Tom Stellard
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Pavel Ondračka 2010-05-28 00:05:38 UTC
Created attachment 35899 [details]
terminal output

I noticed ARB_half_float_vertex support in mesa this morning which is needed for Unigine. I gave it a try and it finally starts. However almost everything is black except for fires from torches (screenshot attached). Terminal is full of mesa user errors and there are some missing opcodes like:

r300: Unknown TGSI/RC opcode: KILP
r300: Unknown TGSI/RC opcode: BGNLOOP
r300: Unknown TGSI/RC opcode: BRK
r300: Unknown TGSI/RC opcode: ENDLOOP
r300 FP: Compiler Error:
r500_fragprog_emit.c::translate_rgb_op(): translate_rgb_op(1): unknown opcode

Using a dummy shader instead.
If there's an 'unknown opcode' message, please file a bug report and attach this log.
r300 VP: Compiler error:
Unknown opcode 32
Using a dummy shader instead.
If there's an 'unknown opcode' message, please file a bug report and attach this log.

Probably more than one problem. However this is a big improvement indeed. This may be the first time Unigine actually tries to render something with open source drivers :-)

01:00.0 VGA compatible controller: ATI Technologies Inc M56P [Radeon Mobility X1600]
Comment 1 Pavel Ondračka 2010-05-28 00:06:40 UTC
Created attachment 35900 [details]
screenshot
Comment 2 Pavel Ondračka 2010-05-28 00:40:22 UTC
Sorry I didn't noticed, few days ago Unigine updated Sanctuary benchmark to 2.3 and they dropped support for r500 cards :-( I have still the 2.2 version (terminal output and screenshot are from 2.2 version) and it probably can be download somewhere, but I'm not sure if it is worth it to fix bugs in r300g for engine which doesn't officially support this cards. Leaving this open for now, maybe some r300g developer can have a look at this.
Comment 3 Tom Stellard 2010-05-31 22:03:40 UTC
I am working on some changes to the r300g driver that might fix this bug.  However, I probably won't be finished for a few months.  It would be helpful if you could run the program with the environment variable RADEON_DEBUG="fp" and then post the output.
Comment 4 Pavel Ondračka 2010-05-31 23:41:15 UTC
Created attachment 35982 [details]
output with RADEON_DEBUG="fp"
Comment 5 Pavel Ondračka 2010-06-09 02:01:01 UTC
Created attachment 36173 [details]
screenshot with libtxc_dxtn.so

Today I installed libtxc_dxtn.so and nice surprise, Unigine sanctuary now works fine, almost everything is rendered now. However there is still some corruption (some black lines at walls and above windows). New log and screenshot attached.
Comment 6 Pavel Ondračka 2010-06-09 02:01:43 UTC
Created attachment 36174 [details]
terminal output with libtxc_dxtn.so
Comment 7 Alberto 2010-06-09 04:52:53 UTC
Hi, I'm also interested in this bug. In my opinion, the fact that Unigine dropped support for r500 is irrelevant. In fact, as they still support Geforce 7000 series (and thus OpenGL 2.x), it shouldn't change much to free drivers. Has anyone tried version 2.3 on r500? (I would do it myself but I've only r600 at the moment)
Another thought: libtxc_dxtn.so is not part of mesa as it implements patented technologies. So until software patents exist, I suspect it will always need to be installed separately :-(
Comment 8 Pavel Ondračka 2010-06-09 05:17:07 UTC
(In reply to comment #7)
> Has anyone tried version 2.3 on r500? (I would do it myself but I've only r600
> at the moment)

Yes, I did try and it doesn't start because it checks for GL_ARB_half_float_pixel which is not supported.
Comment 9 Alberto 2010-06-09 05:42:31 UTC
(In reply to comment #8)
> (In reply to comment #7)
> > Has anyone tried version 2.3 on r500? (I would do it myself but I've only r600
> > at the moment)
> 
> Yes, I did try and it doesn't start because it checks for
> GL_ARB_half_float_pixel which is not supported.

Interesting. At http://dri.freedesktop.org/wiki/MissingFunctionality GL_ARB_half_float_pixel is listed as needed by OpenGL 3.0, while at http://www.opengl.org/registry/specs/ARB/half_float_pixel.txt it is said that «This extension is written against the OpenGL 2.0 Specification but will work with the OpenGL 1.5 Specification.» It also seems that it started out as an NVIDIA only extension (NV_half_float), so probably NVIDIA provides it internally with NV_half_float, while ATI needs OpenGL 3. We're unlucky :-(
Comment 10 Pavel Ondračka 2010-06-09 05:56:00 UTC
Don't know, however this discussion probably doesn't belong to this bug. Lets wait what Marek or Corbin can say about this extension. If GL_ARB_half_float_pixel can be implemented I'll open a new bug about it.
Comment 11 Marek Olšák 2010-06-09 06:02:51 UTC
r300 hardware does support this extension, it's just a matter of time till we add it. The extension is totally useless without float textures (ARB_texture_float) so these must come first. However float textures are said to be covered by patents, that's why nobody has implemented them so far.
Comment 12 Tom Stellard 2010-06-09 09:40:35 UTC
Do you have a torrent or a download link for version 2.2 of this demo?
Comment 13 Pavel Ondračka 2010-06-09 12:29:39 UTC
(In reply to comment #12)
> Do you have a torrent or a download link for version 2.2 of this demo?

Sorry, the only link I found is for the Unigine Tropics benchmark, but it should be quite similar to Sanctuary (looking at the log, there are the same missing opcodes and user errors), except that it renders only black screen. Another possibility could be to write to Unigine developers and ask ;-) Or I can email it to you.

http://www.fileshack.com/file.x/15517/Unigine+%27Tropics%27+Benchmark+Version+1.2+-+Linux
Comment 14 Tom Stellard 2010-06-12 23:18:31 UTC
Can you try again using the current git master branch and post the output of RADEON_DEBUG="fp".
Comment 15 Pavel Ondračka 2010-06-13 02:17:56 UTC
Created attachment 36238 [details]
output with RADEON_DEBUG="fp" , mesa: 1dc573a881f5b1413d156b64f5fdd0a57825c02a
Comment 16 Tom Stellard 2010-07-02 20:04:47 UTC
Can you try again with the current git master branch?  You should see less errors now.
Comment 17 Pavel Ondračka 2010-07-03 01:02:31 UTC
Created attachment 36702 [details]
output with RADEON_DEBUG="fp", mesa:0e6d7ce0178d65787e3e10f56638c2f0a88296f1

I'm sorry to report this, but with latest git master, it looks worse then before. Whole scene is overbright, (the are no shadows). I was interested which commit caused this change, so I did git bisect but when I was at "r300/compiler: Handle loops in deadcode analysis" I wasn't sure if it is bad or good so I stopped. I'm attaching screenshots and new log.
Comment 18 Pavel Ondračka 2010-07-03 01:04:54 UTC
Created attachment 36703 [details]
screenshot with current mesa master
Comment 19 Pavel Ondračka 2010-07-03 01:08:22 UTC
Created attachment 36704 [details]
screenshot with mesa:697d666d7860b3bdced32ca7fde9dea38f67da15

This is when I stopped bisecting, half screen have shadows and another half have not.
Comment 20 Pavel Ondračka 2010-07-03 01:10:35 UTC
Created attachment 36705 [details]
screenshot with NVIDIA proprietary driver

And for reference attaching also screenshot how it should look.
Comment 21 Tom Stellard 2010-07-05 13:25:09 UTC
Hi, can you try again with the attached patch.
Comment 22 Tom Stellard 2010-07-05 13:26:02 UTC
Created attachment 36765 [details] [review]
Implement KILP opcode patch
Comment 23 Pavel Ondračka 2010-07-05 14:23:55 UTC
Created attachment 36771 [details]
output with KILP patch

Your patch works fine here, the whole top part of wall with another line of windows which was black before is now rendered correctly. There are still some problems like shadows missing and those black glitches especially around bottom windows. However very good job so far.
Comment 24 Pavel Ondračka 2010-08-04 01:20:23 UTC
Created attachment 37566 [details]
output with RADEON_DEBUG="fp" , mesa: 5c2f01bbb076af8b8ae6e1803d95a9ae678c2d1c

With latest mesa master shadows are now working correctly, the only remaining issue are those black lines around windows and statues.
Comment 25 Sven Arvidsson 2010-08-04 06:11:23 UTC
Terminal output contains a lot of these error messages:

 OpenGL error: invalid value
 OpenGL error: invalid framebuffer operation
 GLFrameBuffer::check_status(): incomplete attachment

It's nothing new, just something worth mentioning.

I'm not really sure if I'm allowed to redistribute the benchmark, but I could probably put up a torrent if anybody is interested.
Comment 26 Pavel Ondračka 2010-09-17 02:35:21 UTC
Here is status with latest mesa (and lowest settings):
- shadows are broken, they were quite good before glsl2 merge (at least with shaders quality high), I thought they were broken because of glsl2 merge but I did some quick testing and now it seems they were partially broken before it by 
commit 9021c56a5738815777f27c39b63637b5975270c6
Author: Benjamin Segovia <benjamin.segovia@intel.com>
Date:   Fri Aug 13 10:36:47 2010 -0600

    mesa: more/better program optimizations
    
    This is the patch from Benjamin's Aug 11, 2010 email with minor fixes
    (such as moving declarations before code)
    
    Signed-off-by: Brian Paul <brianp@vmware.com>

And then glsl2 merge did the rest. Note that with shaders quality set to low it didn't ever worked, just with high.

- those black glitches are gone (they are now only present when parallax mapping is turned on), they may be related to the shadows, see screenshots

- menus are broken hard, its almost imposible to change any settings.

Maybe this bug needs some splitting? Any logs needed?  I'll attach screenshots.
Comment 27 Pavel Ondračka 2010-09-17 02:36:37 UTC
Created attachment 38756 [details]
screenshot just before 9021c56a5738815777f27c39b63637b5975270c6
Comment 28 Pavel Ondračka 2010-09-17 02:38:12 UTC
Created attachment 38757 [details]
screenshot with mesa 9021c56a5738815777f27c39b63637b5975270c6
Comment 29 Pavel Ondračka 2010-09-17 02:39:42 UTC
Created attachment 38758 [details]
screenshot with current mesa git (	dab2a7660a407364a33337327743b56ea9701d9b)
Comment 30 Benjamin Segovia 2010-09-27 13:27:22 UTC
(In reply to comment #29)
> Created an attachment (id=38758) [details]
> screenshot with current mesa git (    dab2a7660a407364a33337327743b56ea9701d9b)

Hello,

Problem is that I cannot test r300g. One bug was outstanding in my merge. It was solved few hours after glsl2 merge. So:
1/ One bug or more in the mesa program optimizations could cause that bug
2/ One bug or more in glsl2 could cause it
3/ Both

Could you comment the body of function _mesa_optimize_program in src/mesa/program/prog_optimize.c (this is the last function of the source file)? This will deactivate my commit.

Just to see if there is something wrong with glsl2 merge first.

Cheers,
Ben
Comment 31 Pavel Ondračka 2010-09-27 15:09:51 UTC
(In reply to comment #30)
> (In reply to comment #29)
> > Created an attachment (id=38758) [details] [details]
> > screenshot with current mesa git (    dab2a7660a407364a33337327743b56ea9701d9b)
> 
> Hello,
> 
> Problem is that I cannot test r300g. One bug was outstanding in my merge. It
> was solved few hours after glsl2 merge. So:
> 1/ One bug or more in the mesa program optimizations could cause that bug
> 2/ One bug or more in glsl2 could cause it
> 3/ Both
> 
> Could you comment the body of function _mesa_optimize_program in
> src/mesa/program/prog_optimize.c (this is the last function of the source
> file)? This will deactivate my commit.
> 
> Just to see if there is something wrong with glsl2 merge first.
> 
> Cheers,
> Ben

Hi, I did comment out the body of _mesa_optimize_program and I'm now hiting this assertion "Sanctuary: program/program.c:879: _mesa_find_used_registers: Assertion `inst->DstReg.Index < usedSize' failed.", this is with shaders quality high, with low there is no change (starts but no shadows). 
I've found out that I can make shadows work when I start it with RADEON_DEBUG=noopt, which if I understand it correctly disables all optimizations.
Comment 32 Benjamin Segovia 2010-09-27 15:28:53 UTC
Ok, the number of registers may be too high, so optimizing is required to lower that number.

1/ To mesa developpers: do you know which part of mesa is disabled when RADEON_DEBUG=noopt is setup? Does it only modify radeon backend?
In that case, this is a backend problem not a glsl2 or prog_optimize.c bug.

2/ We may try to workaround the assert you hit. You may do the following thing in _mesa_optimize_program. As below, comments the lines I commented. This will disable optimizations while maintaining register reallocation:

#if 0
_mesa_remove_extra_move_use(program);
      if (_mesa_remove_dead_code_global(program))
         any_change = GL_TRUE;
      if (_mesa_remove_extra_moves(program))
         any_change = GL_TRUE;
      if (_mesa_remove_dead_code_local(program))
         any_change = GL_TRUE;
#endif
      _mesa_reallocate_registers(program);

Thanks for help. You are awesomely reactive :)

Ben


(In reply to comment #31)
> (In reply to comment #30)
> > (In reply to comment #29)
> > > Created an attachment (id=38758) [details] [details] [details]
> > > screenshot with current mesa git (    dab2a7660a407364a33337327743b56ea9701d9b)
> > 
> > Hello,
> > 
> > Problem is that I cannot test r300g. One bug was outstanding in my merge. It
> > was solved few hours after glsl2 merge. So:
> > 1/ One bug or more in the mesa program optimizations could cause that bug
> > 2/ One bug or more in glsl2 could cause it
> > 3/ Both
> > 
> > Could you comment the body of function _mesa_optimize_program in
> > src/mesa/program/prog_optimize.c (this is the last function of the source
> > file)? This will deactivate my commit.
> > 
> > Just to see if there is something wrong with glsl2 merge first.
> > 
> > Cheers,
> > Ben
> 
> Hi, I did comment out the body of _mesa_optimize_program and I'm now hiting
> this assertion "Sanctuary: program/program.c:879: _mesa_find_used_registers:
> Assertion `inst->DstReg.Index < usedSize' failed.", this is with shaders
> quality high, with low there is no change (starts but no shadows). 
> I've found out that I can make shadows work when I start it with
> RADEON_DEBUG=noopt, which if I understand it correctly disables all
> optimizations.

(In reply to comment #31)
> (In reply to comment #30)
> > (In reply to comment #29)
> > > Created an attachment (id=38758) [details] [details] [details]
> > > screenshot with current mesa git (    dab2a7660a407364a33337327743b56ea9701d9b)
> > 
> > Hello,
> > 
> > Problem is that I cannot test r300g. One bug was outstanding in my merge. It
> > was solved few hours after glsl2 merge. So:
> > 1/ One bug or more in the mesa program optimizations could cause that bug
> > 2/ One bug or more in glsl2 could cause it
> > 3/ Both
> > 
> > Could you comment the body of function _mesa_optimize_program in
> > src/mesa/program/prog_optimize.c (this is the last function of the source
> > file)? This will deactivate my commit.
> > 
> > Just to see if there is something wrong with glsl2 merge first.
> > 
> > Cheers,
> > Ben
> 
> Hi, I did comment out the body of _mesa_optimize_program and I'm now hiting
> this assertion "Sanctuary: program/program.c:879: _mesa_find_used_registers:
> Assertion `inst->DstReg.Index < usedSize' failed.", this is with shaders
> quality high, with low there is no change (starts but no shadows). 
> I've found out that I can make shadows work when I start it with
> RADEON_DEBUG=noopt, which if I understand it correctly disables all
> optimizations.

(In reply to comment #31)
> (In reply to comment #30)
> > (In reply to comment #29)
> > > Created an attachment (id=38758) [details] [details] [details]
> > > screenshot with current mesa git (    dab2a7660a407364a33337327743b56ea9701d9b)
> > 
> > Hello,
> > 
> > Problem is that I cannot test r300g. One bug was outstanding in my merge. It
> > was solved few hours after glsl2 merge. So:
> > 1/ One bug or more in the mesa program optimizations could cause that bug
> > 2/ One bug or more in glsl2 could cause it
> > 3/ Both
> > 
> > Could you comment the body of function _mesa_optimize_program in
> > src/mesa/program/prog_optimize.c (this is the last function of the source
> > file)? This will deactivate my commit.
> > 
> > Just to see if there is something wrong with glsl2 merge first.
> > 
> > Cheers,
> > Ben
> 
> Hi, I did comment out the body of _mesa_optimize_program and I'm now hiting
> this assertion "Sanctuary: program/program.c:879: _mesa_find_used_registers:
> Assertion `inst->DstReg.Index < usedSize' failed.", this is with shaders
> quality high, with low there is no change (starts but no shadows). 
> I've found out that I can make shadows work when I start it with
> RADEON_DEBUG=noopt, which if I understand it correctly disables all
> optimizations.
Comment 33 Pavel Ondračka 2010-09-27 15:53:33 UTC
Created attachment 38995 [details]
screenshot

Now with only part of _mesa_optimize_program commented out it is a little bit better (see screenshot). There are first signs of shadows but only in the bottom part of scene.
Regarding number 2, check description of commit     cfc461fca6ad5656f58c48803d13052537063316.
Comment 34 Benjamin Segovia 2010-09-27 16:08:52 UTC
(In reply to comment #33)
> Created an attachment (id=38995) [details]
> screenshot
> 
> Now with only part of _mesa_optimize_program commented out it is a little bit
> better (see screenshot). There are first signs of shadows but only in the
> bottom part of scene.
> Regarding number 2, check description of commit    
> cfc461fca6ad5656f58c48803d13052537063316.

Did you turn off/on optimizations with RADEON_DEBUG? We could try:
1/ RADEON_DEBUG=noopt + only register allocation done in prog_optimize.c
2/ RADEON_DEBUG="" + only register allocation done in prog_optimize.c
3/ RADEON_DEBUG=noopt + everything done in prog_optimize.c
Comment 35 Pavel Ondračka 2010-09-27 16:34:55 UTC
Created attachment 38996 [details]
screenshot with RADEON_DEBUG=noopt + only register allocation done in prog_optimize.c

RADEON_DEBUG was previously turned off. 
So here we go:
1/ shadows are present (scene is dark) but there aren't any lights from windows. (screenshot attached)
2/ some shadows present but broken (comment 33 + screenshot there)
3/ shadows working fine, however some surfaces have strange colors (screenshot will be in next comment)

To me it seems there are at least two different bugs here.
Comment 36 Pavel Ondračka 2010-09-27 16:35:32 UTC
Created attachment 38997 [details]
screenshot with RADEON_DEBUG=noopt + everything done in prog_optimize.c
Comment 37 Benjamin Segovia 2010-09-27 17:03:08 UTC
(In reply to comment #36)
> Created an attachment (id=38997) [details]
> screenshot with RADEON_DEBUG=noopt + everything done in prog_optimize.c

To me, it sounds like:
1/ There is for sure a bug in either glsl2 or radeon backend since deactivating optimizations still leads to bugs
2/ There may be a bug in prog_optimize.c but it it not sure since everything is broken

I cannot look at it right now. I have to install a proper 32 bit Linux. Then, I could look if at least I got something with the classic intel driver.

One other possibity is to deactivate optimizations one by one in both glsl2 and r300 backend with prog_optimize unactivated to track down the bug 1/ without any possible bug 2/

Cheers,
Ben
Comment 38 Marek Olšák 2010-09-27 20:40:24 UTC
Removing my email from CC, I am following dri-devel instead.

BTW I've just found and fixed a few bugs in the r300/compiler. Please test.
Comment 39 Pavel Ondračka 2010-10-22 10:25:26 UTC
Created attachment 39633 [details]
screenshot with mesa dd2499b484b34e7efb8800f57c915c2f62ab1db4

With latest mesa this is much better, shadows are now working correctly except for one area which is still missing shadows, screenshot attached.

BTW commit which caused this change is
9d2ab6cb00e72fd8b53d0f97578758504b49ee23
Author: Tom Stellard <tstellar@gmail.com>
Date:   Sun Oct 10 12:39:00 2010 -0700

    r300/compiler: Add a new function for more efficient dataflow analysis
    
    rc_get_readers_normal() supplies a list of readers for a given
    instruction.  This function is now being used by the copy propagate
    optimization and will eventually be used by most other optimization
    passes as well.
Comment 40 Tom Stellard 2010-10-22 16:30:09 UTC
Does running with RADEON_DEBUG=noopt fix this bug?
If it does, can you post the output of RADEON_DEBUG=fp,vp,pstat?
If it doesn't, can you post the output of RADEON_DEBUG=noopt,fp,vp,pstat?
Comment 41 Pavel Ondračka 2010-10-23 00:17:18 UTC
Created attachment 39645 [details]
output of RADEON_DEBUG=fp,vp,pstat

(In reply to comment #40)
> Does running with RADEON_DEBUG=noopt fix this bug?
> If it does, can you post the output of RADEON_DEBUG=fp,vp,pstat?

Yes, running with noopt fixes it.
Comment 42 Tom Stellard 2010-10-23 00:49:23 UTC
(In reply to comment #41)
> Created an attachment (id=39645) [details]
> output of RADEON_DEBUG=fp,vp,pstat
> 
> (In reply to comment #40)
> > Does running with RADEON_DEBUG=noopt fix this bug?
> > If it does, can you post the output of RADEON_DEBUG=fp,vp,pstat?
> 
> Yes, running with noopt fixes it.

I should have thought of this before, but can you post the output of RADEON_DEBUG=noopt,fp,vp,pstat just so I can compare the two?
Thanks.
Comment 43 Pavel Ondračka 2010-10-23 03:35:14 UTC
Created attachment 39648 [details]
output with RADEON_DEBUG=noopt,fp,vp,pstat
Comment 44 Tom Stellard 2010-10-27 23:56:00 UTC
Can you try again with the latest version of mesa from git?
Comment 45 Pavel Ondračka 2010-10-28 02:52:38 UTC
(In reply to comment #44)
> Can you try again with the latest version of mesa from git?

No visible change with latest mesa from git.
Comment 46 Tom Stellard 2010-10-28 10:42:30 UTC
In src/mesa/dri/drivers/r300/compiler/r3xx_fragprog.c around line 120, there is a list of compiler passes.  Three of these passes(deadcode, dataflow optimize, and register allocation) are disabled when running with RADEON_DEBUG=noopt.  You could try commenting out these passes one a time to see which one is causing the bug.  When you are testing this way _don't_ use RADEON_DEBUG=noopt
Comment 47 Pavel Ondračka 2010-10-28 11:32:04 UTC
(In reply to comment #46)
> In src/mesa/dri/drivers/r300/compiler/r3xx_fragprog.c around line 120, there is
> a list of compiler passes.  Three of these passes(deadcode, dataflow optimize,
> and register allocation) are disabled when running with RADEON_DEBUG=noopt. 
> You could try commenting out these passes one a time to see which one is
> causing the bug.  When you are testing this way _don't_ use RADEON_DEBUG=noopt

deadcode pass commented out - no change
dataflow optimize pass commented out - shadows are ok
register allocation commented out - corruption everywhere (are you sure this is disabled with RADEON_DEBUG=noopt?)

So it looks like the bug is caused by dataflow optimize pass.
Comment 48 Marek Olšák 2010-10-28 11:39:17 UTC
If you disable the register allocation, you must enable the dumb register allocation instead. Otherwise nearly nothing will work.
Comment 49 Pavel Ondračka 2010-10-28 12:03:21 UTC
(In reply to comment #48)
> If you disable the register allocation, you must enable the dumb register
> allocation instead. Otherwise nearly nothing will work.

Thanks, this did the trick, however bug is still present as expected.
Comment 50 Tom Stellard 2010-10-28 18:37:32 UTC
In radeon_optimize.c starting at line 660, there are three optimization functions: constant_folding, peephole, and copy_propagate.  You could try commenting these out one at a time to see which one is causing the problem.  Note: when you comment out the peephole function make sure to comment out the continue statement below it, like this:

//if(peephole(c, cur))
//     continue;
Comment 51 Pavel Ondračka 2010-10-29 00:55:52 UTC
(In reply to comment #50)
> In radeon_optimize.c starting at line 660, there are three optimization
> functions: constant_folding, peephole, and copy_propagate.  You could try
> commenting these out one at a time to see which one is causing the problem. 

Commenting out constant folding have no effect, commenting out either peephole or copy_propagate fixes this.
Comment 52 Tom Stellard 2010-10-29 16:55:26 UTC
Created attachment 39891 [details] [review]
Proposed Fix

Does this patch help?
Comment 53 Pavel Ondračka 2010-10-30 00:17:39 UTC
(In reply to comment #52)
> Created an attachment (id=39891) [details]
> Proposed Fix
> 
> Does this patch help?

Great, with your patch shadows works fine with all different settings. Thanks Tom, you did amazing job with r300 compiler in the last few months. :-)
This bug can be closed when your patch is commited to master. I'll open a new bugs for remaining issues.
Comment 54 Tom Stellard 2010-10-30 22:36:21 UTC
Thanks for all you help testing.

This bug is fixed by commit a15cf3cd0b21d593033a3abd2b1788de292001bd


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.