Page 4 of 9 FirstFirst ... 23456 ... LastLast
Results 31 to 40 of 82

Thread: ATI, please release an Open UVD API

  1. #31
    Join Date
    Dec 2009
    Posts
    338

    Default

    Quote Originally Posted by Qaridarium View Post
    right now bridgman and os team work an an shader based solution for the os driver.. thats a big deal!
    Any source of this?

    I would be really happy but honestly I don't think this is the case. Bridgman only said that they will try their best to be able to give out documentation for uvd for _future_ generation cards. And there is a big difference.

    Probably our best chance is Veerappen who wants to write a vp8 decoder in opencl. However, we don't even have a working opencl state tracker at the moment...

  2. #32
    Join Date
    Oct 2009
    Posts
    2,118

    Default

    Quote Originally Posted by HokTar View Post
    Any source of this?

    I would be really happy but honestly I don't think this is the case. Bridgman only said that they will try their best to be able to give out documentation for uvd for _future_ generation cards. And there is a big difference.

    Probably our best chance is Veerappen who wants to write a vp8 decoder in opencl. However, we don't even have a working opencl state tracker at the moment...
    Bridgman did make some remarks to that effect as I recall. I'm not going to bother looking it up and posting a link since it was on this forum -- you can search for it yourself.

    As I understand it, it is an integrated unit, using both shaders as well as some proprietary logic. Fact though, is that many of the older cards did lack the "UVD" unit, and instead did some of the work on the CPU, still with the heavy lifting on the shaders.

    BOTH ARGUMENTS ARE RIGHT AND BOTH ARGUMENTS ARE WRONG. It is somewhere in between!

  3. #33
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,464

    Default

    Quote Originally Posted by HokTar View Post
    Any source of this? (bridgman & team working on shader based decode)
    Didn't come from me

    A few things :

    - UVD *does* do the decoding work (without using shaders), but it *also* participates in DRM

    - everything *after* decode is done on shaders... colour space conversion, scaling, filtering, other post processing etc...

    - haven't had time / remembered to find out how r600 handles video but believe it runs decode on CPU then uses same post-processing on shaders

    - we are still working towards an XvBA API release for fglrx, schedule TBD but hopefully soon

    - I'm still saying "don't assume we will be able to release UVD programming info" but we are still going to investigate whether it can be done... we've worked through enough of the higher priority tasks that I think investigation will happen in the next ~6 months or so

    - key point is that spending time investigating UVD programming info release means that time is not being spent on releasing other info/code and that other info has much higher probability of success... we might spend a few man-years of effort investigating UVD and conclude that we can't release anything, but the time would still be gone and other potential good things would not get done in the meantime

    - UVD only accelerates specific formats so for things like Theora and VP8 you're still going to want shader-based decode IMO...

    - I still think the best plan is to implement an XvMC-ish state tracker over Gallium3D (but designed for modern video formats, not MPEG2) then modify ffmpeg/libavcodec and others to use that state tracker for MC and deblock filtering... you could do more (IDCT etc.. ) on shaders in principle but IMO you're better off avoiding having to push data back from GPU to CPU so best approach is to pick a point in the decode pipe where everything *after* that point can be done efficiently on shaders...

    - IIRC the only sticky part with modern video formats and that approach was inter-prediction... probably do-able but haven't had time to work out the details

    EDIT - I haven't complained about the 1 minute edit limit for a while, so consider it complained-about

  4. #34
    Join Date
    Nov 2009
    Posts
    328

    Default

    From wikipedia, seems pretty correct:

    UVD/UVD+

    Decoding of H.264/AVC, and VC-1 video codecs entirely in hardware. However, video post-processing is passed to the shaders. MPEG-2 decoding is not performed within UVD, but in the shader processors.

    UVD 2 (ati HD4000)

    Full bitstream decoding of H.264/MPEG-4 AVC, VC-1, as well as MPEG2 video streams, and in addition it also supports dual video stream decoding and Picture-in-Picture mode. This makes UVD2 full BD-Live compliant.

    UVD 2.2 (ati HD4000 and HD5000)

    The UVD 2.2 features a re-designed local memory interface and enhances the compatibility with MPEG2/H.264/VC-1 videos.


    Briefing, on cards with UVD chip:

    -Decoding of H.264 and VC-1 doesn't use shaders.
    -Decoding of MPEG2 use shaders on UVD/UVD+, on UVD2 don't use shaders.
    -Post processing is done on shaders.

  5. #35
    Join Date
    Oct 2007
    Posts
    285

    Default

    Quote Originally Posted by bridgman View Post
    Didn't come from me

    A few things :

    - UVD *does* do the decoding work (without using shaders), but it *also* participates in DRM

    - everything *after* decode is done on shaders... colour space conversion, scaling, filtering, other post processing etc...

    - haven't had time / remembered to find out how r600 handles video but believe it runs decode on CPU then uses same post-processing on shaders

    - we are still working towards an XvBA API release for fglrx, schedule TBD but hopefully soon

    - I'm still saying "don't assume we will be able to release UVD programming info" but we are still going to investigate whether it can be done... we've worked through enough of the higher priority tasks that I think investigation will happen in the next ~6 months or so

    - key point is that spending time investigating UVD programming info release means that time is not being spent on releasing other info/code and that other info has much higher probability of success... we might spend a few man-years of effort investigating UVD and conclude that we can't release anything, but the time would still be gone and other potential good things would not get done in the meantime
    You say that, but i don't believe it. I'm sure the people working on fglrx are working their ass off but lets get realistic. We always have to wait months to get up to date support for the latest stable XServer (the 1.9 version is officially not supported yet but a leaked 10.10 driver is usable enough). The OpenGL performance is close to horrible and is so for months if not years. The point i'm making here is that the fglrz driver is in development for quite some time now but real big and needed improvements are still not found in the release notes. (to name one: Fully working OpenGL 4.0 support.. not even asking 4.1 yet).

    So for the users it seems like not much changes from release to release only small bugs seem to get fixed. If you look at it that way (and how else can i look at it as a user?) then it would be way more beneficial for the users to let you investigate the XvBA API possibilities rather then fixing minor things again since the current fglrx driver state is not optimal but usable for probably all users. What we, the users, need most right now is working accelerated video decoding and i thing that if you put 2 people on it for one week you can have it all sorted out very fast. Then another week to make the API and release it. Things don't need to go as dogslow as they are going now.

    Quote Originally Posted by bridgman
    - UVD only accelerates specific formats so for things like Theora and VP8 you're still going to want shader-based decode IMO...

    - I still think the best plan is to implement an XvMC-ish state tracker over Gallium3D (but designed for modern video formats, not MPEG2) then modify ffmpeg/libavcodec and others to use that state tracker for MC and deblock filtering... you could do more (IDCT etc.. ) on shaders in principle but IMO you're better off avoiding having to push data back from GPU to CPU so best approach is to pick a point in the decode pipe where everything *after* that point can be done efficiently on shaders...

    - IIRC the only sticky part with modern video formats and that approach was inter-prediction... probably do-able but haven't had time to work out the details

    EDIT - I haven't complained about the 1 minute edit limit for a while, so consider it complained-about
    Gallium is far fetched since you guys still release fglrx drivers and there is no fully working gallium driver for current cards that is on par with fglrx.

  6. #36
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,464

    Default

    Quote Originally Posted by markg85 View Post
    You say that, but i don't believe it. I'm sure the people working on fglrx are working their ass off but lets get realistic. We always have to wait months to get up to date support for the latest stable XServer (the 1.9 version is officially not supported yet but a leaked 10.10 driver is usable enough). The OpenGL performance is close to horrible and is so for months if not years. The point i'm making here is that the fglrz driver is in development for quite some time now but real big and needed improvements are still not found in the release notes. (to name one: Fully working OpenGL 4.0 support.. not even asking 4.1 yet).
    OK, I lost you here. I talked about three things -- how the *current* drivers work, status of XvBA API release, and options for the open source drivers. How can you say "you don't believe me" then rant about fglrx ? What do you not believe ?

    Quote Originally Posted by markg85 View Post
    So for the users it seems like not much changes from release to release only small bugs seem to get fixed. If you look at it that way (and how else can i look at it as a user?) then it would be way more beneficial for the users to let you investigate the XvBA API possibilities rather then fixing minor things again since the current fglrx driver state is not optimal but usable for probably all users. What we, the users, need most right now is working accelerated video decoding and i thing that if you put 2 people on it for one week you can have it all sorted out very fast. Then another week to make the API and release it. Things don't need to go as dogslow as they are going now.
    I don't really know how to respond to this. If you believe it should only take a week to design an API, implement the associated driver code, run through all the threat/risk analyses to have confidence that releasing the API will not put our DRM implementation on other OSes at risk then there is probably some disconnect in terms of the work required.

    Quote Originally Posted by markg85 View Post
    Gallium is far fetched since you guys still release fglrx drivers and there is no fully working gallium driver for current cards that is on par with fglrx.
    Again, I don't understand this at all. There is no external API equivalent to Gallium3D in fglrx, although it does roughly correspond to the internal "hwl" layer in the fglrx OpenGL driver. I think you may be comparing *Mesa* to the fglrx OpenGL driver, not Gallium3D.

    The Gallium3D driver needs to be sufficiently complete to be able to create and load surfaces, run shaders, and do something with the results.

  7. #37
    Join Date
    Oct 2007
    Posts
    285

    Default

    Quote Originally Posted by bridgman View Post
    OK, I lost you here. I talked about three things -- how the *current* drivers work, status of XvBA API release, and options for the open source drivers. How can you say "you don't believe me" then rant about fglrx ? What do you not believe ?



    I don't really know how to respond to this. If you believe it should only take a week to design an API, implement the associated driver code, run through all the threat/risk analyses to have confidence that releasing the API will not put our DRM implementation on other OSes at risk then there is probably some disconnect in terms of the work required.



    Again, I don't understand this at all. There is no external API equivalent to Gallium3D in fglrx, although it does roughly correspond to the internal "hwl" layer in the fglrx OpenGL driver. I think you may be comparing *Mesa* to the fglrx OpenGL driver, not Gallium3D.

    The Gallium3D driver needs to be sufficiently complete to be able to create and load surfaces, run shaders, and do something with the results.
    Let me put it in numbers then.
    1 person works 40 hours a week and you put 2 people on it. That's 80 working hours in total for one week.

    Yes, i say you can figure out if it's all legal to release XvBA documentation in that time. If it's not possible then it's because of bureaucracy. The time is enough to find it out.

    Yes i also say that if you add another week you can make an API for it as well and release it. 80 hours is a long time for working non-stop on one thing and i know (from my little experience) that most of the work happens in the first few hours and the vast majority of the time is refining your creation.

    If you want it it can happen! I agree that it's optimistic in time and perhaps even tight but not impossible if you just PUT those 2 employees on it full time for 2 weeks in total.

    Note: i do expect those employees have in depth knowledge of the fglrx driver so they know very well where to be to make a public API.


    And i wasn't ranting on fglrx (yet). Just stating my obbservations and facts.

    i wish i had leadership over the fglrx driver then i would certainly give this a try! but then again if i had i would tell all people working on fglrx to drop it and work on gallium instead.

  8. #38
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,464

    Default

    OK, let me try one more time. The release path for XvBA API has nothing to do with fglrx, it is entirely related to protecting the DRM implementation on the drivers for *other* OSes. Knowledge of fglrx is almost totally irrelevent.

    You didn't answer my question about why "you don't believe" my earlier comments :
    - UVD *does* do the decoding work (without using shaders), but it *also* participates in DRM

    - everything *after* decode is done on shaders... colour space conversion, scaling, filtering, other post processing etc...

    - haven't had time / remembered to find out how r600 handles video but believe it runs decode on CPU then uses same post-processing on shaders

    - we are still working towards an XvBA API release for fglrx, schedule TBD but hopefully soon

    - I'm still saying "don't assume we will be able to release UVD programming info" but we are still going to investigate whether it can be done... we've worked through enough of the higher priority tasks that I think investigation will happen in the next ~6 months or so

    - key point is that spending time investigating UVD programming info release means that time is not being spent on releasing other info/code and that other info has much higher probability of success... we might spend a few man-years of effort investigating UVD and conclude that we can't release anything, but the time would still be gone and other potential good things would not get done in the meantime

  9. #39
    Join Date
    Oct 2007
    Posts
    285

    Default

    Quote Originally Posted by bridgman View Post
    OK, let me try one more time. The release path for XvBA API has nothing to do with fglrx, it is entirely related to protecting the DRM implementation on the drivers for *other* OSes. Knowledge of fglrx is almost totally irrelevent.

    You didn't answer my question about why "you don't believe" my earlier comments :
    Right, first one little mistake. The part i didn't believe is:

    Quote Originally Posted by bridgman View Post
    - I'm still saying "don't assume we will be able to release UVD programming info" but we are still going to investigate whether it can be done... we've worked through enough of the higher priority tasks that I think investigation will happen in the next ~6 months or so

    - key point is that spending time investigating UVD programming info release means that time is not being spent on releasing other info/code and that other info has much higher probability of success... we might spend a few man-years of effort investigating UVD and conclude that we can't release anything, but the time would still be gone and other potential good things would not get done in the meantime
    and i replied on that part with:
    You say that, but i don't believe it. I'm sure the people working on fglrx are working their ass off but lets get realistic. We always have to wait months to get up to date support for the latest stable XServer (the 1.9 version is officially not supported yet but a leaked 10.10 driver is usable enough). The OpenGL performance is close to horrible and is so for months if not years. The point i'm making here is that the fglrz driver is in development for quite some time now but real big and needed improvements are still not found in the release notes. (to name one: Fully working OpenGL 4.0 support.. not even asking 4.1 yet).

    So for the users it seems like not much changes from release to release only small bugs seem to get fixed. If you look at it that way (and how else can i look at it as a user?) then it would be way more beneficial for the users to let you investigate the XvBA API possibilities rather then fixing minor things again since the current fglrx driver state is not optimal but usable for probably all users. What we, the users, need most right now is working accelerated video decoding and i thing that if you put 2 people on it for one week you can have it all sorted out very fast. Then another week to make the API and release it. Things don't need to go as dogslow as they are going now.
    In the list you said i quoted a little to much but can't edit it due to the 1 minute edit linux..

  10. #40
    Join Date
    Oct 2007
    Posts
    285

    Default

    big typo.
    i meant:

    In the list you said i quoted a little to much but can't edit it due to the 1 minute edit limit..

Posting Permissions

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