hi, i get texture corruption as seen in the attached screenshot when using dri2. when running more 3D intensive applications (like say, etracer), the texture corruption increases resulting in some graphics primitives not being rendered. this does not happen with DRI1, with DRI1, there is no corruption and all primitives are rendered as expected. this is on linux 2.6.38.6 with alpine patches, mesa 7.10.2 and xorg 1.10 with xf86-video-ati 6.14.1, libdrm 2.4.25 and uclibc 0.9.32-rc3 (also with alpine patches). there are some bugs that look similar to what i am seeing, but they are all marked RESOLVED, and none of them mention DRI2.
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.