| Summary: | texture corruption in r600/r600g when using DRI2, no texture corruption in r600 with dri1 | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | William Pitcock <nenolod> |
| Component: | Drivers/DRI/R600 | Assignee: | Default DRI bug account <dri-devel> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | 7.10 | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
dmesg
glxinfo actual dmesg (copy and paste fail) Xorg.0.log |
||
|
Description
William Pitcock
2011-05-23 01:58:30 UTC
it seems that attachment sizes are limited. see http://nenolod.net/~nenolod/radeon-dri2-gltexture-corruption.png for an example of what i am seeing. i think this is due to incomplete writes to the card or perhaps an off-by-one of some kind. oh, i forgot to mention, this is on a dual radeon hd 4870 setup. Please attach your xorg log, dmesg output, and glxinfo output. Judging by the screenshot this may be a duplicate of bug 33824. The logout effect in KWin uses automatically generated mipmaps + LOD bias to blur all windows except the dialog in the center of the screenshot. Does the problem go away if you set ColorTiling to False in your xorg.conf file? This is most likely _no_ duplicate, since tiling still has to be force on with an envvar. And I don't see this happening from the explanations in the initial post. re: color tiling, i believe it is disabled by default, but i will try and see if that is the problem. i will also get dmesg / Xorg logs when i switch back over to DRI2. Created attachment 47086 [details]
dmesg
Created attachment 47087 [details]
glxinfo
Created attachment 47088 [details]
actual dmesg (copy and paste fail)
Created attachment 47089 [details]
Xorg.0.log
glxinfo, dmesg and xorg log have been attached. KMS color tiling is disabled. color tiling is also disabled without KMS. enabling color tiling on DRI1 does not trigger the bug. Could be a mipmap generation issue then. Is it still broken with r600g from upstream Git master? i don't know, and my concern is mostly with the non-gallium driver right now. i can test the gallium driver, but i need the normal driver to work as i have 32-bit applications i am running in a debian chroot. thusly, i do not really use the gallium driver yet... i only tested it to see if it did the same thing, which it does. the result is not the same everytime you trigger that kwin effect though; sometimes i get part of a console framebuffer (e.g. radeondrmfb). so would it make more sense for me to test non-gallium driver first? (In reply to comment #13) > i don't know, and my concern is mostly with the non-gallium driver right now. > > i can test the gallium driver, but i need the normal driver to work as i have > 32-bit applications i am running in a debian chroot. thusly, i do not really > use the gallium driver yet... i only tested it to see if it did the same thing, > which it does. > > the result is not the same everytime you trigger that kwin effect though; > sometimes i get part of a console framebuffer (e.g. radeondrmfb). > > so would it make more sense for me to test non-gallium driver first? No one is really working on the non gallium driver any more, so it's not likely to get much more attention. (In reply to comment #14) > (In reply to comment #13) > > i don't know, and my concern is mostly with the non-gallium driver right now. > > > > i can test the gallium driver, but i need the normal driver to work as i have > > 32-bit applications i am running in a debian chroot. thusly, i do not really > > use the gallium driver yet... i only tested it to see if it did the same thing, > > which it does. > > > > the result is not the same everytime you trigger that kwin effect though; > > sometimes i get part of a console framebuffer (e.g. radeondrmfb). > > > > so would it make more sense for me to test non-gallium driver first? > > No one is really working on the non gallium driver any more, so it's not likely > to get much more attention. well, i will try and see if r600g git master solves the problem. unfortunately, i think this means i'm screwed when it comes to running proprietary apps in chroots. (In reply to comment #15) > (In reply to comment #14) > > (In reply to comment #13) > > > i don't know, and my concern is mostly with the non-gallium driver right now. > > > > > > i can test the gallium driver, but i need the normal driver to work as i have > > > 32-bit applications i am running in a debian chroot. thusly, i do not really > > > use the gallium driver yet... i only tested it to see if it did the same thing, > > > which it does. > > > > > > the result is not the same everytime you trigger that kwin effect though; > > > sometimes i get part of a console framebuffer (e.g. radeondrmfb). > > > > > > so would it make more sense for me to test non-gallium driver first? > > > > No one is really working on the non gallium driver any more, so it's not likely > > to get much more attention. > > well, i will try and see if r600g git master solves the problem. > unfortunately, i think this means i'm screwed when it comes to running > proprietary apps in chroots. hi William, did you have any chance to test r600g git master in the mean time? The classic r600 driver has been abandoned long ago. It was replaced by the Gallium driver r600g. If you have issues with r600g please file a new bug report with component Drivers/Gallium/r600 Thanks. |
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.