[Bug 18542] [PATCH] Textured Video (XV) tearing.

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Mon Nov 24 05:34:46 PST 2008


http://bugs.freedesktop.org/show_bug.cgi?id=18542





--- Comment #20 from Pierre Ossman <drzeus-bugzilla at drzeus.cx>  2008-11-24 05:34:46 PST ---
(In reply to comment #19)
> (In reply to comment #17)
> > That's strange as I no longer see this. Maybe could even be dependent on the
> > hardware?
> 
> Yeah, as of R300 the 3D engine no longer seems to provide any primitive that
> allows rendering a rectangle top to bottom in one pass. So the 'large triangle
> plus scissor' trick would be needed.

How difficult is this? Could I, who have no insight into the R300 3D engine,
pull it off in an afternoon, or is it a matter of first spending a week
learning the hardware?

> 
> As for the VLINE wait, the way it should be done I think is:
> 
> * Set up the CRTC_GUI_TRIG_VLINE register to start at the top vertical line
> rendered to and end at the bottom line rendered to (these may need to be
> converted/clipped to the CRTC active vertical range etc.) and set the
> CRTC_GUI_TRIG_VLINE_INV bit. The register reference suggests that the
> CRTC_GUI_TRIG_VLINE_STALL bit may also need to be set due to the below.
> * Write WAIT_CRTC_VLINE (not *_RE_* or *_FE_*) to WAIT_UNTIL immediately before
> emitting the 3D primitive. This write should stall the CP while scanout is
> within the specified range.
> 

Those bits are for the legacy CRTC control. Is there an equivalent STALL bit
for AtomBIOS, and if so, which bit is it?

> Note that the waiting should only be done if the window isn't redirected, i.e.
> if the destination pixmap is the screen pixmap.
> 

Ths wait helper already has this check (and requires the relevant pixmap as an
argument). There is also the problem of mplayer getting tossed offscreen when
composite is active, but that's another issue (which also should probably be
solved in mplayer).


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


More information about the xorg-driver-ati mailing list