From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon@freedesktop.org Subject: [Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations Date: Thu, 03 Apr 2014 16:59:59 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0238772214==" Return-path: Received: from culpepper.freedesktop.org (unknown [131.252.210.165]) by gabe.freedesktop.org (Postfix) with ESMTP id 855716E35B for ; Thu, 3 Apr 2014 09:59:59 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============0238772214== Content-Type: multipart/alternative; boundary="1396544399.Df5a3A02.30952"; charset="us-ascii" --1396544399.Df5a3A02.30952 Date: Thu, 3 Apr 2014 16:59:59 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" https://bugs.freedesktop.org/show_bug.cgi?id=76564 --- Comment #57 from Rainer Hochecker --- (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: You are the assignee for the bug. --1396544399.Df5a3A02.30952 Date: Thu, 3 Apr 2014 16:59:59 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8"

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:
  • You are the assignee for the bug.
--1396544399.Df5a3A02.30952-- --===============0238772214== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel --===============0238772214==--