[mythtv] [mythtv-commits] mythtv commit: r26314 - in trunk/mythtv by markk

[Mark Spieth]

  On 9/19/2010 2:08 PM, Mark Kendall wrote:
> On 15 September 2010 05:19, Mark Spieth<mark at digivation.com.au>  wrote:
>>   On 9/14/2010 5:39 PM, mythtv at cvs.mythtv.org wrote:
>>>   Disable OpenGL vsync.
>>>
>>> This has not worked since the OSD merge and despite trying a number of
>>> different approaches, I've utterly failed to fix it. I suspect it is due
>>> to some interaction with the Qt rendering subsystem, though that doesn't
>>> explain why it would fail when using the Qt painter as well as the
>>> OpenGL version.
>> markk,
>>
>> could you explain what is not working in openglsync?
>> seems fine to me but I ma using a few patches from #7964.
>> is it while osd is displayed? (again LGTM)
> Hi Mark
>
> The one consistent symptom I've seen across NVidia, Intel and ATI
> linux systems is that the display is not physically synced to the
> vertical retrace and hence you still get tearing. No errors are
> reported - it just doesn't work. On one system with an older intel
> integrated GPU, the sync calls returned without delay and broke
> playback. On other systems (mainly ATI and newer intel GPUs), X vomits
> error messages at an impressive rate.
>
> The latter error messages are, I'm sure, related to the particular
> implementation of the OpenGL vsync code in trunk - it uses a pixmap as
> the 'device' to sync to. While this is almost certainly not the
> correct approach, I have tried probably a dozen other implementations
> and none of these have fixed it either.
>
> As mentioned in the commit, I was however reasonably comfortable
> disabling it at this point as I'm pretty confident that 99% of people
> simply do not need it. It shouldn't be needed on any non-linux build,
> any linux system with an nvidia gpu, intel systems use drm and xvideo
> sync to vblank (which is, as far as I'm concerned about the only
> supportable playback option on intel). I haven't checked ATI for a
> while - mostly because working with ATI/AMD cards is so painful:)
>
> Out of interest, what video renderer and video card combination are you using?
I use a 8400GS on both my systems. 1 32 bit (i3 530) and 1 64 bit (AMD).
video renderer is xv-blit on both. both on nvidia 256.53. everything is 
rock solid except the odd blackness (<5 secs) on the amd system above 
nvidia 169.12 driver which I suspect is temp related above 72C as I have 
case fan low and cpu fan controlled (mostly off).

cant comment on the other graphics platforms though, but will test with 
drm and xvideo alternatives.

The AMD MB has an ATI/AMD graphics on board but at the time, the driver 
wasn't too good so I got the cheapest good nvidia card without a fan.

the only think I currently see is rapid flashing (white) on displaying 
the playbackbox list of programs.

It was my understanding that the vsync stuff just controls the 
frame/field generation and its XV that controls the toggling of the 
double buffer (assuming XV is in use). the videoout->Show() controls the 
flip. naturally if the thread gets preempted or suspended between vsync 
calc and the flip, then all bets are off.
true I have only tested with my nvidia cards and only 1 type, but with 
the smoothsync mods, the timing is so close to exact and consistent that 
I cant fault it. however if the system gets a bit busy, then you see 
jumps but still no *tearing*.

The best way is to schedule the flip of the page buffer ahead of time of 
course. I havent delved into this much though (yet). however you still 
need some sort of feedback to control the video frame/field feed rate 
and still minimize processing of unnecessary frames. I'm sure you know 
this too.

another issue I currently see with recent changes is my play to end 
patch no longer has the desired effect, and it stops about 1.5 secs from 
the end.

as you would expect, Im leaving glsync on for now for me until I find a 
good alternative that works.

cheers
mark