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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Comment # 57 on bug 76564 from
(In reply to comment #50)

> 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?
> 

Almost correct. At the application level we don't see interrupts. We just
render the frames. We only can render one frame per vblank interval. Decoding
should be fasted than rendering, hence the queue of ready frames fills and
frames wait for being picked up. At this point (when the render thread comes
by) we check the timestamp attached to the frame. If the time has already
passed and there is more than a single frame in the queue, the next frame is
skipped. Means the render thread is late by minimum frametime 41ms when running
at 23.976.

So even if we run at wrong speed, the render thread should not get that late.


You are receiving this mail because:
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux