Created attachment 21094 [details] xorg.conf Configuration File I am running the latest code from git. Playing any full screen video results in approximately the right 1/4 of the screen being filled with junk and a large triangle in the bottom right corner. The video also appears to be squashed into the remaining 3/4 of the screen. This is a problem at 1920x1080, 1920x1200 and 1600x1200 but NOT at 1360x768, where everything plays fine.
Created attachment 21095 [details] Photo of the problem
(In reply to comment #0) > Created an attachment (id=21094) [details] > xorg.conf Configuration File > > I am running the latest code from git. Playing any full screen video results > in approximately the right 1/4 of the screen being filled with junk and a large > triangle in the bottom right corner. This doesn't look like junk to me, rather appears like what you'd get if you'd do clamp_to_edge texturing with the texture coords supposed to be at the corners somewhere else. > The video also appears to be squashed into the remaining 3/4 of the screen. Which fits the previous explanation. > This is a problem at 1920x1080, > 1920x1200 and 1600x1200 but NOT at 1360x768, where everything plays fine. As a guess, I'd blame the big tri rather than quad approach in xv changes to avoid tearing (though I'm still unsure if that's really needed - it didn't seem to be for me and apparently Alex but for others). Not sure what's the problem though, maybe it exceeds some hardware limits somewhere.
(In reply to comment #2) > As a guess, I'd blame the big tri rather than quad approach in xv changes to > avoid tearing (though I'm still unsure if that's really needed - it didn't seem > to be for me and apparently Alex but for others). Not sure what's the problem > though, maybe it exceeds some hardware limits somewhere. Hi Roland, It does indeed seem to be related to the tearing fixes made recently. If I roll back the driver to git of 20081003 (f9826a56) then the 1/4-screen problem disappears and I can play the video in 1920x1080 -- but obviously with the tearing those patches are designed to fix! George
Are you using a compositing manager?
(In reply to comment #4) > Are you using a compositing manager? > I'm running xfce4 / xfwm (with Composite set to Disabled in xorg.conf).
Is it possible clipping somehow is an issue here? I'm not sure what the SC_CLIP regs actually really do, but if they clip geometry current setup wouldn't allow for a 3840 pixel wide tri (which is what is required for 1920 width) - not for r300 at least.
Created attachment 21110 [details] [review] clipping fix With that in mind, does this patch fix it for you?
(In reply to comment #7) > Created an attachment (id=21110) [details] > clipping fix > > With that in mind, does this patch fix it for you? > Hi Alex, Thanks again for all your efforts on these drivers. Unfortunately, this patch doesn't fix the problem for me. I am still seeing the same artifact on the video at 1920x1080 and 1600x1200. Kind regards, George
To me it looks rather like the vertex coordinates are off (as you can see the triangle edge on the bottom right). Maybe something like an arithmetic rounding/overflow problem somewhere?
We are hitting guardband limits on r3xx/r4xx, so we can't use a clipped triangle above certain sizes. Suggestion from hw guys is to use point sprites.
(In reply to comment #10) > We are hitting guardband limits on r3xx/r4xx, so we can't use a clipped > triangle above certain sizes. Suggestion from hw guys is to use point sprites. Interesting, the docs just say set to 1.0 (which is what the driver does) for no guard band and don't mention a a limit. So what's the limit? Also, are point sprites actually rasterized differently to quads?
(In reply to comment #11) > Interesting, the docs just say set to 1.0 (which is what the driver does) for > no guard band and don't mention a a limit. So what's the limit? 2880 > Also, are point sprites actually rasterized differently to quads? > So I'm told. I haven't tried them yet.
This should be fixed.
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.