Created attachment 35900 [details]
screenshot
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. 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. Created attachment 35982 [details]
output with RADEON_DEBUG="fp"
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.
Created attachment 36174 [details]
terminal output with libtxc_dxtn.so
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 :-( (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. (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 :-( 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. 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. Do you have a torrent or a download link for version 2.2 of this demo? (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 Can you try again using the current git master branch and post the output of RADEON_DEBUG="fp". Created attachment 36238 [details]
output with RADEON_DEBUG="fp" , mesa: 1dc573a881f5b1413d156b64f5fdd0a57825c02a
Can you try again with the current git master branch? You should see less errors now. 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.
Created attachment 36703 [details]
screenshot with current mesa master
Created attachment 36704 [details]
screenshot with mesa:697d666d7860b3bdced32ca7fde9dea38f67da15
This is when I stopped bisecting, half screen have shadows and another half have not.
Created attachment 36705 [details]
screenshot with NVIDIA proprietary driver
And for reference attaching also screenshot how it should look.
Hi, can you try again with the attached patch. Created attachment 36765 [details] [review] Implement KILP opcode patch 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.
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.
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. 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. Created attachment 38756 [details]
screenshot just before 9021c56a5738815777f27c39b63637b5975270c6
Created attachment 38757 [details]
screenshot with mesa 9021c56a5738815777f27c39b63637b5975270c6
Created attachment 38758 [details]
screenshot with current mesa git ( dab2a7660a407364a33337327743b56ea9701d9b)
(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 (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. 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.
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.
(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 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. Created attachment 38997 [details]
screenshot with RADEON_DEBUG=noopt + everything done in prog_optimize.c
(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 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. 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. 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? 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. (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. Created attachment 39648 [details]
output with RADEON_DEBUG=noopt,fp,vp,pstat
Can you try again with the latest version of mesa from git? (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. 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 (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. If you disable the register allocation, you must enable the dumb register allocation instead. Otherwise nearly nothing will work. (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. 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; (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. Created attachment 39891 [details] [review] Proposed Fix Does this patch help? (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. 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.
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]