[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 #39 from jeroen <jeroenk61 at hotmail.com> ---
(In reply to comment #37)
> Created attachment 96604 [details] [review]
> Possible fix v3
> 
> Please try this one, it's a complete rewrite of finding the right PLL
> numbers.

No problem Peter I was already compiling it manually for the previous tests.

I just tested the patch using OpenElec 4.
50fps:     14850, pll dividers - fb: 29.7 ref: 4, post 5
23.976fps: 7417, pll dividers - fb: 741.7 ref: 100, post 10
59.94fps:  14835, pll dividers - fb: 296.7 ref: 25, post 8

50fps is spot on and no frames are dropped. The dividers are optimal.

23.976fps is better, but I still count on average a skipped frame every 28sec.
Since the skipped frames are not at a regular interval I took the average.
Sometimes a frame is skipped after 10sec, but it sometimes also takes 40
seconds.
When a frame is skipped I see the fps in XBMC drop to around 22.98fps.
What I do not understand is why it is still so often as the error in the clock
would suggest a drop every ~9min.

59.94fps is also much better. Here XBMC reports a missed frame maybe every
minute or so.

This patch is definately an improvement, but it still not as good as fgrlx
which could play for many minutes without every dropping/skipping/missing
frames.

Perhaps since Peter is apparently also following this thread could give some
insight in the synchronisation in XBMC?
I have the idea the sync behaves differently in OE4 compared to OE3. For
example in OE3, the player (P) in the codec info overlay never had the field
skipped, only dropped?
Is the VBlank moment in XBMC derived from the pixel clock from the radeon or
the pixel clock the TV is expecting?

Could it be that as the phase between the two pixel clocks is becoming to big,
that this is solved/handled differently between fgrlx and OSS radeon?

-- 
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/20140330/eb0c17c3/attachment.html>