[mythtv-users] Latest Intel Drivers and HD on G915 (works) and G965 (video tearing)

[Calin Brabandt]

> Calin Brabandt wrote:
>> I compiled the latest Intel graphics drivers from
>> www.intellinuxgraphics.org.  The modesetting is a
>> welcome addition to the drivers and my G915 board
>> seems to be working well on either my 720p DFP or
>> 1440x900 LCD VGA monitor.  There's still no XvMC in
>> the drivers, however.
>>
>> Unfortunately, my G965, unlike the G915,has a bad
case
>> of video tearing.  Mythfrontend -v playback reports
>> that both boards are using DRM sync and OpenGL sync
>> doesn't appear to work with the drivers.  I think
DRM
>> sync is close to working on the G965 but it's
sync'ing
>> in the wrong place.  With 1080i video, the video
tear
>> is always about 1/4 of the way down the  and
>> with 720p playback, it's about 1/8 of the way down.
>> Without DRM sync, Myth uses RTC sync and the
tearing
>> is all over the place on either board.  Using the
>> G915, and DRM sync, the video is correctly
>> synchronized with vblank and a pleasure to watch.

Doug Larrick wrote:
> I've noticed this problem on my G965 as well.  I am
able to use OpenGL
> vsync on my system, and it happens there as well.

> My understanding is that the G965 has no video
overlay hardware, and so
> does its drawing using a texture (3D hardware).  My
further
> understanding is it makes no attempt to sync to
vertical retrace
> internally.  That's OK; we don't need it to.

> Unfortunately there's not a whole lot to be done
from the MythTV side
> --
> we're told by DRM or OpenGL "OK, now, go!" and we
then display the
> video
> frame as quickly as we can.  My guess is that by the
time we get the
> vertical retrace there's not enough time for the
combined work that
> MythTV and the driver need to do -- either this work
is taking too
> long,
> or the signal is arriving late.

> The G965 driver is still under some fairly heavy
development, so
> there's
> hope to get this fixed.

> -Doug

Thanks for confirming this problem on the G965, Doug.

I was hoping it might be possible to hack in an
adjustable delay--either into the source code and/or
mythconverg, that would delay for the remaining
fraction of the refresh interval that's occurring
after the tear.  The tear is always in the same place,
given the same content, (1080i or 720p) so it seems
like a delay could position the video buffer refresh
in the correct place.  Of course, this hack might
result in some kind of video buffer overrun too.