Announcement

Collapse
No announcement yet.

AMD's UVD2-based XvBA Finally Does Something On Linux

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • evolution
    replied
    Originally posted by bwat47 View Post
    Something really needs to happen to enable hardware acceleration on cards like the 2xxx series . Compared to windows linux is quite unusable when it comes to watching hd videos right now.

    I know its not like totally amd's fault or anything, as the whole situation for stuff like hardware acceleration in linux is kind of a mess in the first place.

    vdpau may not have as flexible of an api, but when it comes to getting support from stuff like video players, and flash it would definitely be the way to go. I don't see flash adding support for other api's besides vdpau anytime soon. And many linux players already support vdpau, getting va-api/xvba working is a lot more difficult.

    I am sure you know a lot more on the subject than I, however.
    Currently UVD1 seems also to not work on Windows 7 (at least for me). So far, my HD2600 isn't decoding videos by hardware anymore (at least in latest 5/6 month catalyst versions). I can confirm this using latest Catalyst Drivers (10.12) and enabling explicitly DxVA acceleration on WMP or in VLC (1.1.5).

    Cheers

    Leave a comment:


  • bridgman
    replied
    Originally posted by popper View Post
    but you cant get anyone inside to talk to you/us about even the potential timeline for this one required library
    For clarity, I only said that we don't publish driver plans so even if I *did* know it wouldn't make a difference.

    My job is on the open source side so I'm not normally involved with Catalyst development, except when there is some kind of crossover issue (eg co-existence between the drivers or installing Catalyst on a distro that defaults to KMS).

    Leave a comment:


  • popper
    replied
    yea i removed the devices with UVD1 option on windows OpenCL OVDECODE as clearly they will never be an OpenCL device option probably, the UVD2's could be though...

    Leave a comment:


  • popper
    replied
    Originally posted by bridgman View Post
    No, but we generally don't talk about future plans for Catalyst anyways.

    LOL So in effect gbeauche could today bump to his potential 0.8.x-series and probably easily implement it on the v2.3 SDK supplied OVDECODE_API On Windows, Today.

    and so all the windows OSS developers could then integrate that into FFmpeg,VLC etc, adding Yet one More video decode option to their growing OSS windows code base, But Linux today cant do even one fully working option for all (UVD1 through UVD3) AMD based cards due to known reported bug's/missing OVdecode, but you cant get anyone inside to talk to you/us about even the potential timeline for this one required library

    Leave a comment:


  • Armin
    replied
    Originally posted by popper
    LOL So in effect gbeauche could today bump to his potential 0.8.x-series and probably easily implement it on the v2.3 SDK supplied OVDECODE_API On Windows, perhaps even have UVD1 based cards work too, Today.

    and so all the windows OSS developers could then integrate that into FFmpeg,VLC etc, adding Yet one More video decode option to their growing OSS windows code base, But Linux today cant do even one fully working option for all (UVD1 through UVD3) AMD based cards due to known reported bug's/missing OVdecode
    WRONG: The AMD Stream SDK (as their runtime, AFAIK) only supports Radeon HD 4xxx and higher. So that is not really a way to go for people with an 2xxx or 3xxx, as I'm.

    If I understood the infos on the AMD homepage wronge and should be mistaken with this, I'm happy to be corrected.

    -Armin

    Leave a comment:


  • bwat47
    replied
    Darn 1 minute edit limits :/

    anyway. Any flash heavy website is also abysmal in performance compared to the hardware accelerated flash in windows. Just watching a flash video in linux really pegs my cpu and makes my laptop very hot.

    This is another example of how fragmentation in linux can really harm things. In windows there is one api. dxva. It is supported by ati and nvidia and in windows 7 will work great by default on most cards. In linux you have xv, xvmc, vdpau, va-api/xvba ect.. and nothing is truly standardized. If there was one api supported by nvidia and ati, video players and flash could target it and get the maximum amount of user satisfaction, rather than only subsets of users with the right cards/packages/driver/player.

    Leave a comment:


  • bwat47
    replied
    Originally posted by bridgman View Post
    I imagine implementing VDPAU on top of XvBA could be done (in the same way that gbeauche implemented VA-API over XvBA) but I don't know that anyone has looked at it. IIRC the VA-API spec has more API options which make it a better fit for implementing over another API.

    I haven't looked much at the practicalities of implementing a decode API over OpenCL. It's definitely possible, but I'm not sure how well the two APIs match (ie how well the resulting stack would perform). Implementing a decode API over Gallium3D seems like a better option based on the (very) limited amount of time I have had to look at the options.
    Something really needs to happen to enable hardware acceleration on cards like the 2xxx series . Compared to windows linux is quite unusable when it comes to watching hd videos right now.

    I know its not like totally amd's fault or anything, as the whole situation for stuff like hardware acceleration in linux is kind of a mess in the first place.

    vdpau may not have as flexible of an api, but when it comes to getting support from stuff like video players, and flash it would definitely be the way to go. I don't see flash adding support for other api's besides vdpau anytime soon. And many linux players already support vdpau, getting va-api/xvba working is a lot more difficult.

    I am sure you know a lot more on the subject than I, however.

    Leave a comment:


  • evolution
    replied
    Originally posted by eldar View Post
    But Gallium3D isn't what Catalyst uses, is it?
    Yes, it's true. Catalyst uses its own OpenGL implementation, not Gallium3D.

    Using Gallium3D would cause a huge regression in 3D performance for Catalyst users and OpenGL 3D features (currently has only full OpenGL 2.1 implementation, I think ).

    Cheers

    Leave a comment:


  • eldar
    replied
    But Gallium3D isn't what Catalyst uses, is it?

    Leave a comment:


  • bridgman
    replied
    I imagine implementing VDPAU on top of XvBA could be done (in the same way that gbeauche implemented VA-API over XvBA) but I don't know that anyone has looked at it. IIRC the VA-API spec has more API options which make it a better fit for implementing over another API.

    I haven't looked much at the practicalities of implementing a decode API over OpenCL. It's definitely possible, but I'm not sure how well the two APIs match (ie how well the resulting stack would perform). Implementing a decode API over Gallium3D seems like a better option based on the (very) limited amount of time I have had to look at the options.

    Leave a comment:

Working...
X