Page 1 of 2 12 LastLast
Results 1 to 10 of 18

Thread: DRI2 Sync + Swap Extensions Near Reality

  1. #1
    Join Date
    Jan 2007
    Posts
    15,138

    Default DRI2 Sync + Swap Extensions Near Reality

    Phoronix: DRI2 Sync + Swap Extensions Near Reality

    When running a modern Linux graphics driver stack in a composited environment there is a lot less tearing -- particularly with regard to video playback, but OpenGL applications too -- now than there was in the past, but there is still room for improvement. One of the ways to improve this is by properly controlling the display of buffers with how often the swaps occur and to sync them with the monitor's refresh rate or the rate at which the compositor is running...

    http://www.phoronix.com/vr.php?view=NzY1Ng

  2. #2
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,798

    Default

    Quote Originally Posted by phoronix View Post
    When running a modern Linux graphics driver stack in a composited environment there is a lot less tearing [...] now than there was in the past
    Orly? Xgl, which is old was running flawlessly without tearing

  3. #3
    Join Date
    Jun 2008
    Posts
    11

    Default

    Cool, could this fix the performance issues with textured video playback with the kms ati drivers?

  4. #4
    Join Date
    May 2008
    Posts
    598

    Default

    Is tearing and flicker the same?

  5. #5
    Join Date
    Oct 2007
    Location
    Under the bridge
    Posts
    2,146

    Default

    Quote Originally Posted by Louise View Post
    Is tearing and flicker the same?
    No.

    Simply put, tearing occurs when the back-to-front buffer swap happens out of sync with the monitor's refresh rate. This means that the scanout starts before the front buffer is completely refreshed, which results in the monitor displaying both old and new data at the same time. The "tear" is a (usually) horizontal line at the point where the split between old and new data lies. VSync takes care of this artifact - unfortunately, vsync is not easy to implement under AIGLX using the current infrastructure, hence this work.

    Flicker is the artifact that occurs when using direct rendering (DRI1) on a composited environment. The compositor normally redirects all rendering to an off-screen area to perform composition, before spitting the result back to screen. However, DRI1 is oblivious to this procedure and renders directly on screen, overwriting the compositor's output (flicker!) DRI2 solves this issue.

  6. #6
    Join Date
    Jun 2008
    Posts
    167

    Default

    Quote Originally Posted by RealNC View Post
    Orly? Xgl, which is old was running flawlessly without tearing
    Yes, because, AFAIK (I'm no expert at all), Xgl was a whole reimplementation of X protocol over OpenGL. A drawback was that you weren't able to run any OpenGL thing inside Xgl itself, which is not funny in any way.

    BTW, is antialiasing possible with ATI open drivers? I'd like to see smooth edges on my cube!

  7. #7
    Join Date
    Nov 2007
    Location
    Die trolls, die!
    Posts
    525

    Default

    Thanks Jesse!

  8. #8
    Join Date
    Sep 2006
    Posts
    71

    Default

    This kind of thing is what I've been waiting for in Linux Desktop graphics for a decade. Go Go Go!!

  9. #9
    Join Date
    May 2008
    Posts
    598

    Default

    Quote Originally Posted by BlackStar View Post
    No.

    Simply put, tearing occurs when the back-to-front buffer swap happens out of sync with the monitor's refresh rate. This means that the scanout starts before the front buffer is completely refreshed, which results in the monitor displaying both old and new data at the same time. The "tear" is a (usually) horizontal line at the point where the split between old and new data lies. VSync takes care of this artifact - unfortunately, vsync is not easy to implement under AIGLX using the current infrastructure, hence this work.

    Flicker is the artifact that occurs when using direct rendering (DRI1) on a composited environment. The compositor normally redirects all rendering to an off-screen area to perform composition, before spitting the result back to screen. However, DRI1 is oblivious to this procedure and renders directly on screen, overwriting the compositor's output (flicker!) DRI2 solves this issue.
    In that case, I have a lot of tearing

    Where in the OSS ATi graphics driver stack does VSync belong? DRI2?
    Last edited by Louise; 10-31-2009 at 12:16 PM.

  10. #10
    Join Date
    Oct 2007
    Posts
    1,286

    Default

    Where in the OSS ATi graphics driver stack does VSync belong? DRI2?
    I think vsync might need support for interrupts, which the open-source ATI drivers lack (because of lack of documentation).

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •