Results 1 to 7 of 7

Thread: DRI2 Video Support Still Being Planned

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

    Default DRI2 Video Support Still Being Planned

    Phoronix: DRI2 Video Support Still Being Planned

    Rob Clark of Texas Instruments talked more at XDC2012 about his plans for "DRI2 Video" support...

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

  2. #2
    Join Date
    Jan 2009
    Posts
    1,495

    Default

    Quote Originally Posted by phoronix View Post
    Phoronix: DRI2 Video Support Still Being Planned

    Rob Clark of Texas Instruments talked more at XDC2012 about his plans for "DRI2 Video" support...

    http://www.phoronix.com/vr.php?view=MTE5MTM
    So, the big win is tear-free playback? Don't we already have that when we use a GL surface as output?

  3. #3
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,329

    Default

    I understand the main benefit is zero-copy. Tear-free was already possible a decade ago using the video overlay.

  4. #4
    Join Date
    Jan 2010
    Posts
    368

    Default

    Another problem with Linux is the lack of a modern standard API for video presentation. Xv is old, and it shows in many ways. We have VDPAU, but that is not supported on all chipsets.

  5. #5
    Join Date
    Jan 2009
    Posts
    1,495

    Default

    Quote Originally Posted by curaga View Post
    I understand the main benefit is zero-copy. Tear-free was already possible a decade ago using the video overlay.
    Someone needs to tell my desktop that.
    So, the use of swapbuffers implies zero copy? I thought it was simply about switchng out the front buffer. If you are running a conpositor it seems like you would still need to copy that swapped buffer.

  6. #6
    Join Date
    Jul 2008
    Posts
    914

    Default

    does that reduce cpu usage in video playback... yesterday I tried because of that wayland in quantal but here (radeon) no pointer did appear

  7. #7
    Join Date
    Jul 2009
    Posts
    291

    Default

    Yep, it reduces CPU usage and latency pretty greatly, by eliminating a couple of huge stalls. In the best case, you can have the overlay scan directly out of the buffer the DSP decoded into, which saves you two copies (in and out of the SHM area). This helps hugely with 1080p especially.

    Using overlays rather than GL still helps you a lot because the overlays typically have much higher-quality scaling, filtering and colourspace conversion. They're pretty crucial in mobile because the you expend a great deal more power using the GPU for that.

Posting Permissions

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