x1250 horizontal tearing problems

[Roland Scheidegger]

Alex Deucher wrote:
> On Thu, May 1, 2008 at 6:49 PM, Roland Scheidegger
> <sroland at tungstengraphics.com> wrote:
>> Michel Dänzer wrote:
>>  > On Wed, 2008-04-30 at 14:39 -0400, Alex Deucher wrote:
>>  >> On Wed, Apr 30, 2008 at 3:06 AM, Michel Dänzer
>>  >> <michel at tungstengraphics.com> wrote:
>>  >>> On Tue, 2008-04-29 at 16:52 -0400, Alex Deucher wrote:
>>  >>>  > On Tue, Apr 29, 2008 at 4:34 PM, Alex Rades <alerades at gmail.com> wrote:
>>  >>>  > > Hi,
>>  >>>  > > when playing videos (either in xv or plain x11) on my x1250, I always see
>>  >>>  > > horizontal (not diagonal, which are now fixed) tearing problems. They seem
>>  >>>  > > related to vertical sync problems. Do you have suggestions?
>>  >>>  >
>>  >>>  > We need sync to vblank support for textured video to properly deal
>>  >>>  > with that.  this untested hack may help, but it's not optimal:
>>  >>>  > http://www.botchco.com/alex/xorg/texvid_wait_vsync.diff
>>  >>>
>>  >>>  Good to see this getting tackled. Here's what I think is missing:
>>  >>>
>>  >>>       * Set up the CRTC*_GUI_TRIG_VLINE register such that it waits for
>>  >>>         scanout to be outside of the destination vertical range.
>>  >> yeah, makes sense.
>>  >>
>>  >>>       * Only wait if the window isn't redirected (backing pixmap is the
>>  >>>         screen pixmap)
>>  >> yeah, as you said, any rendering to the front buffer should wait for
>>  >> vblank.
>>  >
>>  > Technically not for vblank, but for scanout to be outside of the
>>  > affected vertical screen range.
>>  >
>>  >> I may play around with it a bit if I have time, but unfortunately, I
>>  >> seem to be unable to notice tearing generally.  Do you have any good
>>  >> tips or content that would make it easier to notice?
>>  >
>>  > Generally, I find it most noticeable with horizontal animation or with
>>  > large solid areas that continuously change colour.
>>  >
>>  >> The other issue is that the current IB scheme doesn't really lend
>>  >> itself to this.  Ideally we'd queue up everything and then pre-pend a
>>  >> wait_until vblank when we submit the IB.
>>  >
>>  > I don't think one wait per IB is sufficient anyway, as any given IB will
>>  > likely have both on- and offscreen operations. It could be tricky to
>>  > find a good granularity for the waits.
>>  > 
>>  >> Additionally, we have the issue of multiple crtcs for regular
>>  >> rendering as well. In that case, we really need shatter.
>>  >
>>  > Right, or again pick the CRTC with larger visibility and/or let the user
>>  > choose somehow.
>>
>>  Since nowadays everybody just uses 60Hz for almost all displays
>>  (LCD...), wouldn't it be possible to sync them? Looks to me like the
>>  avivo-based chips could do that (with the D1CRTC_TRIGA_CNTL and friends)
>>  or is my quick look wrong?
> 
> Probably.  if the mode was the same you could even use the same PLL for both.
Yes, but that's quite a limited scenario (same resolution etc.), and it
looks to me like the chip could be programmed to sync any two modes, as
long as they've got (almost) the same vertical refresh rate. Actually it
seems like you could tell it to sync even modes with different refresh
rate, but the result probably would be strange :-).

Roland