| Summary: | [r600c] shadowtex demo doesn't work on rs780 | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Andrew Randrianasulu <randrik> |
| Component: | Drivers/DRI/R600 | Assignee: | 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 |
||
Created attachment 30842 [details]
glxinfo -l
Created attachment 32444 [details]
shadowtex corruption
(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. 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). 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). 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 (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? (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. 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? 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. (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. 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) ? for r600c some corruption still here. (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. (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. (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. 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 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.
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.