Bug 24818

Summary: [r600c] shadowtex demo doesn't work on rs780
Product: Mesa Reporter: Andrew Randrianasulu <randrik>
Component: Drivers/DRI/R600Assignee: Default DRI bug account <dri-devel>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: medium CC: edwin+bugs, hramrach
Version: git   
Hardware: x86 (IA32)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments: glxinfo -l
shadowtex corruption

Description Andrew Randrianasulu 2009-10-30 09:12:36 UTC
Using mesa git (commit 5f7d5d3ea3932ef6028b21bb22d8d28dbdd9fa9f - r600: use AUTO_INDEX for draw - saves cmd buffer space ) and this video hardware

01:05.0 VGA compatible controller: ATI Technologies Inc Radeon 3100 Graphics (prog-if 00 [VGA controller])
        Subsystem: ASUSTeK Computer Inc. Device 82ee
        Flags: bus master, fast devsel, latency 0, IRQ 18
        Memory at d0000000 (32-bit, prefetchable) [size=256M]
        I/O ports at d000 [size=256]
        Memory at fbef0000 (32-bit, non-prefetchable) [size=64K]
        Memory at fbd00000 (32-bit, non-prefetchable) [size=1M]
        Expansion ROM at <unassigned> [disabled]
        Capabilities: [50] Power Management version 3
        Capabilities: [a0] MSI: Mask- 64bit+ Count=1/1 Enable-
        Kernel driver in use: radeon
        Kernel modules: radeon

i see only black screen as  output. I can resize application window,  it will print some lines like

Rendering 256 x 256 depth texture                                            
Rendering 512 x 512 depth texture                                            
Rendering 512 x 512 depth texture

but whole window still stays black.
Comment 1 Andrew Randrianasulu 2009-10-30 09:14:05 UTC
Created attachment 30842 [details]
glxinfo -l
Comment 2 Andy Furniss 2010-01-04 12:53:12 UTC
Created attachment 32444 [details]
shadowtex corruption
Comment 3 Andy Furniss 2010-01-04 12:58:51 UTC
(In reply to comment #2)
> Created an attachment (id=32444) [details]
> shadowtex corruption
> 

I used to see black on shadowtex on an AGP rv670, but more recently I just get corruption. 

The corruption seems to depend on what is in memory and will vary as the window is resized to repeatedly cycle through the three texture sizes.
Comment 4 Rafał Miłecki 2010-01-04 13:08:50 UTC
I can confirm this using mesa master and RV620.

I've noticed that corruption is random as I restart shadowtex demo until some time. After starting it for example 10th time, corruption stops changing. So it indeed looks like using some random data from VRAM or something. After having "stable" corruption I've to reboot to get random corruptions again (for a few shadowtex restarts).
Comment 5 Török Edwin 2010-03-14 04:33:59 UTC
If I press 'o' repeatedly then the
GL_EQUAL, GL_NOTEQUAL, GL_ALWAYS, GL_NEVER modes don't show corruption, the others show the corruption.

Also if I look at the depth texture image with 'i' I see corruption, regardless of comparison mode.

Also if I set UseFBO to false, and set shadowtex to display the texture image first, then I get a blue rectangle, when I switch to 'm' or 'n' mode, I get corruption again, and when I switch back to 'i' its corrupt.

I tried to compile mesa with --enable-debug, and use RADEON_DEBUG=all, but it crashes at radeon_common.c:970, because state->cmd  is NULL (and if I make it skip when null, then no commands are dumped, since state->cmd is always NULL).
Comment 6 Török Edwin 2010-03-14 11:08:05 UTC
Also the piglit tests:
  texdepth, depth-tex-modes, depth-tex-compare
show random colors (sometimes it is "close" to the correct ones, sometimes completely wrong) each time they are started.

The piglit test depth-tex-modes-glsl says "pass" in -auto mode, but it too displays random colors (when run without -auto)! For example sometimes the top right block looks like this:
BP
BP

or like this
BB
BP

instead of this (with sw render):
PB
BP

Comment 7 Andy Furniss 2010-07-07 04:37:38 UTC
(In reply to comment #4)
> I can confirm this using mesa master and RV620.
> 
> I've noticed that corruption is random as I restart shadowtex demo until some
> time. After starting it for example 10th time, corruption stops changing. So it
> indeed looks like using some random data from VRAM or something. After having
> "stable" corruption I've to reboot to get random corruptions again (for a few
> shadowtex restarts).

Seems like there's been a further regression - probably in mesa master during the last few weeks. I now can't run this at all -

shadowtex: r700_assembler.c:6355: Process_Export: Assertion `starting_register_number >= pAsm->starting_export_register_number' failed.

Anyone else getting this?
Comment 8 Török Edwin 2010-07-29 09:49:40 UTC
(In reply to comment #7)
> (In reply to comment #4)
> > I can confirm this using mesa master and RV620.
> > 
> > I've noticed that corruption is random as I restart shadowtex demo until some
> > time. After starting it for example 10th time, corruption stops changing. So it
> > indeed looks like using some random data from VRAM or something. After having
> > "stable" corruption I've to reboot to get random corruptions again (for a few
> > shadowtex restarts).
> 
> Seems like there's been a further regression - probably in mesa master during
> the last few weeks. I now can't run this at all -
> 
> shadowtex: r700_assembler.c:6355: Process_Export: Assertion
> `starting_register_number >= pAsm->starting_export_register_number' failed.
> 
> Anyone else getting this?

The assert just got fixed by 9b3bf392e1af72d29afa0804260cac4d8ffe24e1.
Comment 9 Török Edwin 2010-08-29 02:03:16 UTC
Good news, r600g doesn't have this bug!
Just tested mesa git c48ae0b6eddc71831ea0ea480a0177523ae6ee76, and shadowtex looked fine.

Would it be possible/worth finding out what is r600c doing wrong by comparing (the GPU instructions) with r600g?
Comment 10 Alex Deucher 2010-08-29 14:22:07 UTC
Only D16 and D32 depth formats can be blitted from directly with Z compression disabled.  D24 and D24S8 formats require a special blit to a new buffer, and then you can use the new buffer as a texture source.  Unfortunately, this is kind of hard to deal with the way classic drivers are structured.
Comment 11 Andy Furniss 2010-11-18 04:43:04 UTC
(In reply to comment #9)
> Good news, r600g doesn't have this bug!
> Just tested mesa git c48ae0b6eddc71831ea0ea480a0177523ae6ee76, and shadowtex
> looked fine.

This has regressed with 600g now.

I can't point to a specific commit, but roughly it regressed at the time when 600g + tiling started to work with demos like readpix and pixeltest.
Comment 12 Andrew Randrianasulu 2011-02-01 00:06:34 UTC
r600g works fine again, with mesa master at commit 11bc8991e94e2fa6d461193a6aff47f8f94b7a47 (r600g: just change tile type when buffer is set to depth.) , with colortiling enabled. 

Kernel - 2.6.37 vanilla
ddx - 66eb81b62e5ae8e1d7bd44ed8a179e5ec1ca69af (UMS: Slightly improve xserver version check.)
libdrm - 550fe2ca3b29ad2191eab4fdfbed9ed21e25492d (intel: compile fix for previous commit after rebasing)
xserver - 1.9 branch up to 
089a510dc9511721817df63bf9a968a10b842198 (mi: Fix the debug message)

Should this bug stay open (for r600c) ?
Comment 13 Andrew Randrianasulu 2011-02-01 00:11:17 UTC
for r600c some corruption still here.
Comment 14 Andy Furniss 2011-02-01 04:24:29 UTC
(In reply to comment #12)
 
> Should this bug stay open (for r600c) ?

Maybe marked as won't fix due to comment #10.

FWIW it just started working again for me with 600g - but I am not sure if it's working properly as 600g and swrastg are the same and render solid shadows, but swrast shadows are not 100% solid on blue and red.
Comment 15 Michel Dänzer 2011-02-01 04:28:47 UTC
(In reply to comment #14)
> FWIW it just started working again for me with 600g - but I am not sure if it's
> working properly as 600g and swrastg are the same and render solid shadows, but
> swrast shadows are not 100% solid on blue and red.

The difference is due to Gallium drivers not supporting the GL_ARB_shadow_ambient extension.
Comment 16 Andy Furniss 2011-02-01 05:46:07 UTC
(In reply to comment #15)
> (In reply to comment #14)
> > FWIW it just started working again for me with 600g - but I am not sure if it's
> > working properly as 600g and swrastg are the same and render solid shadows, but
> > swrast shadows are not 100% solid on blue and red.
> 
> The difference is due to Gallium drivers not supporting the
> GL_ARB_shadow_ambient extension.

Ahh, thanks for the explanation.
Comment 17 Andre Maasikas 2011-02-01 07:10:26 UTC
btw should't be too hard for classic also
http://cgit.freedesktop.org/~andrem/mesa/log/?h=r600-depth
was working at one time.
It only does one way atm - so no texture->db copy
Comment 18 Jerome Glisse 2012-02-22 09:58:59 UTC
It's working with r600g. We no longer support r600c so closing.

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.