Radeon EXA's Composite acceleration is broken on my M6 for repeat pictures. This behavior was originally shown to me by a simple demo from frederikh. It's testable with "rendercheck -t repeat" from git. This is with DRI, CVS from 2006-04-25 or later. It's not clear how longstanding this is.
Eric, was this due to the issues with new repeat types that you fixed in EXA recently?
No, the bug I fixed was with the extended repeat flags, while the demo and the rendercheck test were only using RepeatNormal.
*** Bug 8134 has been marked as a duplicate of this bug. ***
Hmm. It looks like RadeonComposite() doesn't normalize the texture coordinates for POT textures. Shouldn't it?
Created attachment 6900 [details] [review] Always use normalized texture coordinates Does this patch make a difference?
Created attachment 6909 [details] [review] Always use normalized texture coordinates, take two Missed a file...
*** Bug 7420 has been marked as a duplicate of this bug. ***
Just tested the patch (on R100 with EXA) and it doesn't fix the issue from bug 8134. It even makes some other operations have garbled graphics that weren't before, though I didn't investigate further.
Created attachment 6944 [details] [review] Also attempt to catch cases where width and pitch are incompatible for repeat Can you try this one?
Looks better, but not perfect - I'm missing the icons for applications in the Gnome Workspace Switcher. And it's really slow (gnome-terminal and xchat both take 2-3 seconds to redraw).
Created attachment 6973 [details] [review] Stick to denormalized coords for R100
(In reply to comment #10) > Looks better, but not perfect - I'm missing the icons for applications in the > Gnome Workspace Switcher. Hmm, please try the new patch, which returns to using denormalized coords for R100. I'm not seeing any issues with normalized coords with R200 though. > And it's really slow (gnome-terminal and xchat both take 2-3 seconds to redraw). I suspect that's due to migration of the window pixmap between system and video memory due to the software fallback for the repeat that can't be accelerated. The exa-damagetrack branch might help somewhat with that, or EXA could be enhanced to handle this smarter than falling back to software directly.
Should be fixed in git, please reopen if you still see this issue with that.
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.