Page 1 of 4 123 ... LastLast
Results 1 to 10 of 33

Thread: Three Priorities For Open-Source Radeon Graphics

  1. #1
    Join Date
    Jan 2007
    Posts
    14,554

    Default Three Priorities For Open-Source Radeon Graphics

    Phoronix: Three Priorities For Open-Source Radeon Graphics

    While we still haven't been able to deliver any Radeon HD 7000 series Linux benchmarks, we do know what are AMD's three priority projects right now for their open-source Radeon Linux driver stack...

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

  2. #2
    Join Date
    Jul 2009
    Posts
    250

    Default

    how about VDPAU? why focus on UVD?

  3. #3
    Join Date
    May 2011
    Posts
    353

    Default

    UVD is an engine on the graphics card while VDPAU is an API to let programs use it. These are two very different things which shouldn't be confused. You need the card's UVD to be supported before VDPAU will ever work as good as in nVidia's implementation.

  4. #4
    Join Date
    Jul 2009
    Posts
    250

    Default

    i thought that VDPAU uses the 3D engine, while UVD was a engine itself...
    but if you say that it wont work without UVD...
    i really thought that VDPAU can be used on r300g driven cards..

  5. #5
    Join Date
    Jan 2011
    Posts
    100

    Default

    Quote Originally Posted by jakubo View Post
    i thought that VDPAU uses the 3D engine, while UVD was a engine itself...
    but if you say that it wont work without UVD...
    i really thought that VDPAU can be used on r300g driven cards..
    Oh no, as I understand all this theoretically you could implement (expose)vdpau using the 3d engine of the radeon cards. If they are going to do that and if it would be worthwile is something I don't know.

  6. #6
    Join Date
    Oct 2009
    Posts
    2,081

    Default

    Quote Originally Posted by jakubo View Post
    i thought that VDPAU uses the 3D engine, while UVD was a engine itself...
    but if you say that it wont work without UVD...
    i really thought that VDPAU can be used on r300g driven cards..
    VDPAU: "Video Decode and Presentation API for Unix". This is nothing more or less than NVIDIA'S (i.e. evil/hostile) SOFTWARE INTERFACE to their hardware video decoder, which they call "PureVideo".

    NVIDIA calls their implementation by the name "PureVideo".
    AMD calls their implementation by the name "Unified Video Decoder" (aka "UVD").

    I.e., UVD ~= PureVideo
    (~= means "approximately equivalent")

  7. #7
    Join Date
    Oct 2009
    Posts
    60

    Default

    I only care about Video Acceleration. While it works flawlessly under Windows, up to the point where one can easily watch hardware-accelerated YouTube HD videos on even the weakest AMD APU, it is still a huge pain under Linux. There are VDPAU, VA-API and whatnot, every single player has to be patched to use them, every driver exposes a different API, and the open-source drivers don't expose any or offer just half the codecs or it doesn't work. Just today I installed a GT 210 in an HTPC running Ubuntu. I had to manually install VDPAU, libva and smplayer to get acceleration working. All other combinations and players (vlc, xine etc.) didn't work. Great. Sometimes i just wish we had a port of DirectShow.

  8. #8
    Join Date
    Dec 2009
    Posts
    338

    Default

    Let's try to clear the confusion here!

    UVD is indeed the equivalent of PureVideo. There purpose is just to decode video, hence they are special function hardware and extremely efficient.

    VDPAU and XvBA are APIs which are mainly meant to take advantage of the above decoders.
    This means that they can be implemented even on CPUs but most probably it would not be efficient at all.
    The consequence is that either of them could be implemented in a Gallium3D state tracker and any gallium drivers, including r300g, could make use of them.
    So yes, the idea is that the VDPAU state tracker tries to create an implementation of said API over gallium. It currently supports r300g, r600g and nouveau.

    Now it should be obvious that UVD is not needed for VDPAU on any hardware.
    The shortcoming of the Gallium3D state tracker is that it uses the shaders, hence it cannot be as efficient as the UVD would be. This is the main reason why guys at AMD are still battling to provide some sort of support despite the serious legal challenges.

    Hope it clarifies a few bits. If I made mistakes hopefully bridgman & co. will fix me.

  9. #9
    Join Date
    May 2010
    Posts
    684

    Default

    I wish they'd make power management a bigger priority. Thats the reason I got a new laptop with intel graphics to replace my old laptop that had an hd2600 mobility. Using the OSS drivers on that thing raped my battery life and caused very high temps compared to catalyst, even when I set it to low profile. And on low profile performance wasn't very good for compositing. Dynpm hardly even worked, screen flickered every time it switched clocks. Power management is a total mess right now for those drivers.

    This new laptop has less powerful integrated intel graphics, but compositing seems smoother, and I get good temps and battery life. Both catalyst and the oss drivers were too problematic for me in linux to keep using ATI. Catalyst has gotten better, and did give me decent temps, but the fact that it is so broken with gnome-shell was a deal breaker for me.
    Last edited by bwat47; 01-12-2012 at 11:30 AM.

  10. #10
    Join Date
    Jan 2009
    Posts
    515

    Default

    +1

    I wish powermanagement were better.

Posting Permissions

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