Page 7 of 8 FirstFirst ... 5678 LastLast
Results 61 to 70 of 72

Thread: Will AMD's XvBA Beat Out NVIDIA's VDPAU?

  1. #61
    Join Date
    Aug 2007
    Posts
    6,627

    Default

    Well usable is hard to say. It seems only embedded device manufacturers got the needed headers to write apps which support xvba - and the funny one who made those benchmark tests to annoy people because HE can use it but nobody else. If you would get a precompiled binary you could use it, but how to get it?

  2. #62
    Join Date
    Oct 2007
    Location
    Under a rock
    Posts
    60

    Default

    Finally though it looks like AMD may be prepared to launch XvBA formally this summer. - Michael Larabel
    US definition of Summer: Begins June 21, summer solstice, and ends with the autumnal equinox on September 22.

    Time left in Summer -- 73 days (inl. weekends)

  3. #63
    Join Date
    Mar 2009
    Posts
    68

    Wink The boy the cried wolf?

    Hi all and Monkey King,

    I really do hope that ATI/AMD do finally enable ther world klass video decodes on the HD4xxx cards. Getting what one paid for is always a good thang! :-)

    By the end of the USA summer, would be a year later, but better later than never.

    To many of these "coming up real soon now," articles, followed by the big nada, does tend to reinforce the notion, that we are all listening to, "the boy who cried wolf...." I do hope that is not the case. But I have been wrong b4.

    Crossez fingerz. :-)

    GreekGeek.

  4. #64
    Join Date
    Jan 2007
    Posts
    459

    Default

    hmm did this news go over everyones heads then?, wasnt the real news here that
    there is apparently now a working "UVD" ASIC hardware codebase in the hands of (i assume thats you gbeauche ?) Gwenolé Beauchesne that previously wrote the VA-API support for MPlayer / FFmpeg and even a VDPAU back-end for VA-API. (along with SheepShaver, and adapted many just-in-time (JIT) translation techniques lets not forget ) we may get to use the ATI "UVD" hardware decoding and frame accurate editing in some form if it makes it to the likes of FFMPEG patchs and at some point soon, FINALLY ?

    why are you already arguing the API points when you cant even currently use or code for the "UVD" hardware right now without Bridgman's help and Gwenolé's currently usable codebases....

    rememeber way back in january 8th 2009 Bridgmen said:

    Quote:
    Bridgmen said:"we are going to look into opening up UVD, I just can't make any commitments until we have actually gone through the investigation and it won't be quick. We have 6xx/7xx 3d code out now, so IMO the next priority should be basic power management. "


    popper said:thats a shame, we are looking at months at the very least then!


    Quote:
    Bridgeman said:For open source, yes, but I expect fglrx will have it sooner.
    Last edited by popper; 07-17-2009 at 08:42 PM.

  5. #65
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,458

    Default

    You didn't miss anything. We didn't make a public announcement because the current implementation is not something we can make available other than in embedded applications under NDA. When we have an implementation which can be made publicly available, trust me you'll know about it

  6. #66
    Join Date
    Feb 2008
    Posts
    36

    Default

    Quote Originally Posted by mukiex View Post
    All things considered, however, I wonder if we're better off putting VA-API on top of VDPAU instead of the other way around. VDPAU already works on Mplayer, FFMPEG, VLC, and XBMC patch-free, and it's somewhat of an open standard. Making Ati's, Intel's, and S3's chips play along means we won't have to wait for patch updates for all the major video playback programs.
    Supporting both would be awesome!

    VAAPI on top of VDPAU, and VDPAU on top of VAAPI would both show which API has the least overhead and could in the long term help improve both these APIs, ...while short term it would allow all software that support VDPAU today use VAAPI through VDPAU, and the all software that support VAAPI today use VDPAU through VAAPI.

    Best for the media player software developers however would be if we someday get an API that not only word on Linux/UNIX or Windows, but an API that would also work on Windows and Mac OS X, ...kind of like the concept behind the Gallium 3D device driver framework.

    If I have to pick today though I choose VDPAU because its closest to DXVA (Microsoft's DirectX Video Acceleration API for Windows) so its more 'portable' for the media player software developers than VAAPI.

    PS! In any case, I too hope to see publicly released ATI/AMD GPU acceleration library/drivers for video decoding on Linux soon and XBMC Media Center implementation for it.
    http://xbmc.org


  7. #67
    Join Date
    Aug 2007
    Posts
    153

    Default

    Quote Originally Posted by Gamester17 View Post
    Supporting both would be awesome!
    Yes.

    VAAPI on top of VDPAU, and VDPAU on top of VAAPI would both show which API has the least overhead and could in the long term help improve both these APIs, ...while short term it would allow all software that support VDPAU today use VAAPI through VDPAU, and the all software that support VAAPI today use VDPAU through VAAPI.
    No. That is just more overhead and more silliness.

    Best for the media player software developers however would be if we someday get an API that not only word on Linux/UNIX or Windows, but an API that would also work on Windows and Mac OS X, ...kind of like the concept behind the Gallium 3D device driver framework.
    The entire point of Gallium is to not need to have universal APIs. Instead, you have frontends for each OS and windowing system, and a single driver in the backend.

    Additionally, the media player guys don't get any breaks if the video decoding API is universal; they still have to have GUI stuff broken out. (Well, except for VLC because they use Wx, but you're not talking about VLC.)

    If I have to pick today though I choose VDPAU because its closest to DXVA (Microsoft's DirectX Video Acceleration API for Windows) so its more 'portable' for the media player software developers than VAAPI.
    VDPAU is for Unix-likes only.

    PS! In any case, I too hope to see publicly released ATI/AMD GPU acceleration library/drivers for video decoding on Linux soon and XBMC Media Center implementation for it.
    http://xbmc.org
    Meh. They still don't understand how to write proper GL/GLX code; I'm not optimistic about their Radeon compatibility...

    http://bugs.freedesktop.org/show_bug.cgi?id=21145
    http://xbmc.org/trac/ticket/6382

  8. #68
    Join Date
    Jul 2009
    Posts
    24

    Default

    Quote Originally Posted by MostAwesomeDude View Post
    (Well, except for VLC because they use Wx, but you're not talking about VLC.)
    http://xbmc.org/trac/ticket/6382
    VLC uses Qt4. wxWidgets GUI was deprecated circa 0.9.0.

  9. #69
    Join Date
    Feb 2008
    Posts
    36

    Default

    Quote Originally Posted by MostAwesomeDude View Post
    VDPAU is for Unix-likes only.
    I know, I was refering to that NVIDIA basically got the idea for VDPAU by reverse-engineering the concept behind the DXVA design

    Quote Originally Posted by MostAwesomeDude View Post
    Meh. They still don't understand how to write proper GL/GLX code; I'm not optimistic about their Radeon compatibility...
    Watch out, even though I coded none of XBMC GL/GLX code myself I might still take that as an personal insult,

    ...just kidding, but I am the one who has been on Team-XBMC the longest, hehe http://xbmc.org/about/team/

    This is totally off-topic but know that it not really a bug in XBMC. You see XBMC GUI rendering engine requires proper OpenGL 3D with GLSL and ARB shaders support, something that the any (open source drivers other than Intel) does not provide as of yet, and it should be noted that this minimum requirement is for the GUI and not for the video playback renderer, ...later we might even raise this minimum requirement for XBMC from OpenGL version 1.3 (as today) to OpenGL version 2.1 in order to support even more eye candy with GUI skinning.

    http://xbmc.org/about/vision/
    Last but not least, be beautiful to look at, after all, we hope you will be using it a lot!

  10. #70
    Join Date
    Aug 2007
    Posts
    153

    Default

    Quote Originally Posted by Gamester17 View Post
    Watch out, even though I coded none of XBMC GL/GLX code myself I might still take that as an personal insult,

    ...just kidding, but I am the one who has been on Team-XBMC the longest, hehe http://xbmc.org/about/team/

    This is totally off-topic but know that it not really a bug in XBMC. You see XBMC GUI rendering engine requires proper OpenGL 3D with GLSL and ARB shaders support, something that the any (open source drivers other than Intel) does not provide as of yet, and it should be noted that this minimum requirement is for the GUI and not for the video playback renderer, ...later we might even raise this minimum requirement for XBMC from OpenGL version 1.3 (as today) to OpenGL version 2.1 in order to support even more eye candy with GUI skinning.

    http://xbmc.org/about/vision/
    No slight meant.

    The bug's in XBMC's GLX setup, and it could be fixed with a bit of code inspection. Maybe I'll fix it someday. Has nothing to do with shaders.

    Actually, somebody should really change the GL setup too so that it falls back to ARB programs if available (which do work in current Mesa) and to properly detect GL extensions. Unless I'm out-of-date and somebody's already done it, of course.

Posting Permissions

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