Bug 29851 - [r300g] HyperZ on RS690 not work correctly
Summary: [r300g] HyperZ on RS690 not work correctly
Status: RESOLVED NOTABUG
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/r300 (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-08-28 02:45 UTC by David Heidelberg (okias)
Modified: 2011-02-28 03:34 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
glxgears.jpeg (2.18 KB, image/jpeg)
2010-08-28 02:45 UTC, David Heidelberg (okias)
Details
glxgears with hyperz on rv350, 2.6.36_rc3 (9.72 KB, image/png)
2010-09-01 17:10 UTC, Scott Moreau
Details
possible fix (42.08 KB, patch)
2011-01-24 20:57 UTC, Marek Olšák
Details | Splinter Review
possible fix 2 (47.30 KB, patch)
2011-01-25 07:48 UTC, Marek Olšák
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description David Heidelberg (okias) 2010-08-28 02:45:12 UTC
Created attachment 38235 [details]
glxgears.jpeg

Incoretly rendering.
Kernel: 2.6.36-rc2
Mesa/libdrm/ddx: git
xorg: 1.9.0

~ $ RADEON_HYPERZ=1 glxgears
radeon: Successfully grabbed chipset info from kernel!
radeon: DRM version: 2.6.0 ID: 0x791f GB: 1 Z: 1
radeon: GART size: 509 MB VRAM size: 128 MB
radeon: HyperZ: YES
couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable
Mesa: Mesa 7.9-devel DEBUG build Aug 28 2010 10:23:14
Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
293 frames in 5.0 seconds = 58.480 FPS

P.S. On screenshot is glxgears area, only small part fast blinking gear
Comment 1 Scott Moreau 2010-09-01 17:10:16 UTC
Created attachment 38374 [details]
glxgears with hyperz on rv350, 2.6.36_rc3

Setting Hyper-Z makes any 3D corrupted here as well on RV350, 2.6.36_rc3, x86/32bit.
Comment 2 Scott Moreau 2010-09-23 03:13:27 UTC
(In reply to comment #0)
> Created an attachment (id=38235) [details]
> glxgears.jpeg
> 
> Incoretly rendering.
> Kernel: 2.6.36-rc2
> Mesa/libdrm/ddx: git
> xorg: 1.9.0
> 
> ~ $ RADEON_HYPERZ=1 glxgears
> radeon: Successfully grabbed chipset info from kernel!
> radeon: DRM version: 2.6.0 ID: 0x791f GB: 1 Z: 1
> radeon: GART size: 509 MB VRAM size: 128 MB
> radeon: HyperZ: YES
> couldn't open libtxc_dxtn.so, software DXTn compression/decompression
> unavailable
> Mesa: Mesa 7.9-devel DEBUG build Aug 28 2010 10:23:14
> Mesa warning: couldn't open libtxc_dxtn.so, software DXTn
> compression/decompression unavailable
> Running synchronized to the vertical refresh.  The framerate should be
> approximately the same as the monitor refresh rate.
> 293 frames in 5.0 seconds = 58.480 FPS
> 
> P.S. On screenshot is glxgears area, only small part fast blinking gear

Does this make any difference? In mesa/src/gallium/drivers/r300/r300_state.c:770

-            int compress = r300->screen->caps.is_rv350 ? RV350_Z_COMPRESS_88 : R300_Z_COMPRESS_44;
+            int compress = R300_Z_COMPRESS_44;
Comment 3 David Heidelberg (okias) 2010-09-24 13:50:30 UTC
(In reply to comment #2)
> (In reply to comment #0)
> > Created an attachment (id=38235) [details] [details]
> > glxgears.jpeg
> > 
> > Incoretly rendering.
> > Kernel: 2.6.36-rc2
> > Mesa/libdrm/ddx: git
> > xorg: 1.9.0
> > 
> > ~ $ RADEON_HYPERZ=1 glxgears
> > radeon: Successfully grabbed chipset info from kernel!
> > radeon: DRM version: 2.6.0 ID: 0x791f GB: 1 Z: 1
> > radeon: GART size: 509 MB VRAM size: 128 MB
> > radeon: HyperZ: YES
> > couldn't open libtxc_dxtn.so, software DXTn compression/decompression
> > unavailable
> > Mesa: Mesa 7.9-devel DEBUG build Aug 28 2010 10:23:14
> > Mesa warning: couldn't open libtxc_dxtn.so, software DXTn
> > compression/decompression unavailable
> > Running synchronized to the vertical refresh.  The framerate should be
> > approximately the same as the monitor refresh rate.
> > 293 frames in 5.0 seconds = 58.480 FPS
> > 
> > P.S. On screenshot is glxgears area, only small part fast blinking gear
> 
> Does this make any difference? In
> mesa/src/gallium/drivers/r300/r300_state.c:770
> 
> -            int compress = r300->screen->caps.is_rv350 ? RV350_Z_COMPRESS_88 :
> R300_Z_COMPRESS_44;
> +            int compress = R300_Z_COMPRESS_44;

No, exactly same behavior
Comment 4 steckdenis 2010-09-27 02:12:38 UTC
Hello,

I also encounter this bug and investigated it. When I launch Neverball, the first frames are displayed ok. Then they slowly begin to disappear, each frame having less content that the previous.

I restarted Neverball and quickly clicked on the Play button, and I played the first level.

It seems that the Z buffer is not cleared between the frames. I can see the level when it comes nearer to me, but when I play it, it disappears. The only thing I can do is to tilt the ground as much as I can, to make it nearer to the camera.

I looked at the code, but didn't find when the Z buffer is cleared.

I use Linux 2.6.36-rc3, Mesa Git (2010-09-27), libdrm 2010-08-24, Xorg Server 1.9, xf86-video-ati 6.13.1, on a RS690 card (ATI Radeon X1270) with 128Mb of sideport memory.

I tried the proposed patch, but it didn't worked.
Comment 5 David Heidelberg (okias) 2010-09-27 02:16:43 UTC
(In reply to comment #4)
> Hello,
> 
> I also encounter this bug and investigated it. When I launch Neverball, the
> first frames are displayed ok. Then they slowly begin to disappear, each frame
> having less content that the previous.

I can confirm that (it's not perfectly visible on glxgears)
Comment 6 Dave Airlie 2010-12-24 12:48:28 UTC
can you please retest with mesa master?
Comment 7 David Heidelberg (okias) 2010-12-27 18:04:02 UTC
Nothing changed.
Comment 8 David Heidelberg (okias) 2011-01-23 14:19:32 UTC
Here is video with wrong behaviour http://www.megaupload.com/?d=XTEJV8LY [about 5MB]
Comment 9 Marek Olšák 2011-01-24 20:57:51 UTC
Created attachment 42432 [details] [review]
possible fix

Does the attached patch fix anything?
Comment 10 Pavel Ondračka 2011-01-25 06:08:49 UTC
Review of attachment 42432 [details] [review]:

This patch fixes HyperZ corruption in Unigine Sanctuary and Scorched3D for me (RV530) and decreases amount of corruption in Lightsmark. Also no regressions encountered so far with other games tested (HoN, SC2, War3, Osmos).
Comment 11 Marek Olšák 2011-01-25 07:48:52 UTC
Created attachment 42464 [details] [review]
possible fix 2

I've made a new patch. Could you give it a try?
Comment 12 David Heidelberg (okias) 2011-01-27 08:06:33 UTC
same behaviour :-(
Comment 13 Marek Olšák 2011-01-27 16:11:02 UTC
There are some new bug fixes in master. Please test.
Comment 14 David Heidelberg (okias) 2011-02-05 03:44:35 UTC
Now it look little different, not blinking lines, but more quads  (but really small)
Comment 15 Marek Olšák 2011-02-28 03:34:05 UTC
Commit d1dbbf7bf41959df489195d11eb50f8222d293d3 disables hyper-z on rs6xx+, it seems the hw can't do it.

Those who reported issues on other GPUs should file separate bugs.


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.