[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=76564

--- Comment #50 from jeroen <jeroenk61 at hotmail.com> ---
(In reply to comment #47)
> (In reply to comment #41)
> > (In reply to comment #40)
> > > If you set "sync playback to display" in XBMC, an inaccurate clock has no
> > > impact on dropped or skipped frames. Suppose you only have a 24Hz mode and
> > > play material which is 23.976. It would slightly speed up playback: every
> > > vblank interval a frame is rendered.
> > > If you observe skipped frames, the render thread may have been blocked too
> > > long or a vertical retrace was missed.
> >  
> > Hello FernetMenta,
> > 
> > Thanks for commenting, as you are one of the experts on this subject in XBMC.
> > 
> > "sync playback to display" is definately enabled on my system and still I am
> > seeing skipped or missed frames depending on if the clock is too slow or too
> > fast, respectively.
> > Also, the patches from Christian already proved that a clock that is closer
> > to the television display clock DOES have an influence on skipping/missing
> > frames. If the clock had no impact there wouldn't be a problem in the first
> > place.
> > 
> > The posted xrandr logs also show my television does have a 23.976 mode.
> 
> Again, a wrong speed does NOT have direct influence on dropped or skipped
> frames. If you see a some kind of relationship you have to look for the
> missing piece.

Okay, but some more information would be helpful. This way the bug report
becomes more constructive in finding the root cause. It would help me (and
perhaps others) to find the missing piece if it clear how radeon OSS and XBMC
work in respect to the vblank timing etc.

For example the XBMC wiki is not very thorough on what the
missing/skipping/dropping really means. Therefore, I already read a lot of
threads on the XBMC forum. In
http://forum.xbmc.org/showthread.php?tid=178173&pid=1551907#pid1551907 you
state that skipping MAY be caused by refresh rate problems.

So what I got together in terms of definitions in XMBC:
- Skipping: The renderer is late
- Dropping: The decoder is late
- Missing: A vblank interrupt was missed

If the 'sync to display' option is on in XBMC the video pixels clock is master
and I guess it then uses the vblank interrupt generated by the OSS driver.
These interrupts are generated using the same clock settings that were used to
set the PLL parameters. Why are there then ever skips reported, because the
renderer cannot be late as it is the master and just puts a frame out for each
vblank interrupt? or do I misunderstand something?
Are missed vblanks reported by the OSS driver to XBMC or does XBMC keep some
shadow adminstration to see if vblank interrupts arrive at the expected time?

In my opinion there were a lot of bad comments on fgrlx, but atleast it got the
core rendering of frames done without stuttering. The XVBA part was not that
ideal though.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140402/f1c0b0dc/attachment.html>