Announcement

Collapse
No announcement yet.

AMD Releases Open-Source UVD Video Support

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

  • r_a_trip
    replied
    You sure?

    Originally posted by artivision View Post
    Anyway thanks for the UVD support, but GPUs are all about gaming.
    My HTPC begs to differ. I'd love to be able to accelerate x264 in XBMC with UVD.

    Leave a comment:


  • artivision
    replied
    Anyway thanks for the UVD support, but GPUs are all about gaming.

    Leave a comment:


  • artivision
    replied
    Originally posted by jrch2k8 View Post
    1.)"s it possible for any compiler in the earth to be OS-specific?" yes, if both all oses run on the same architecture any compiler do the job since the IR and the final ASM/Nmemonic is for the same hardware but for example linux/solaris run on sparc but windows don't, so you dont have the OS support or way to make a compiler that support sparc since the final ASM/Nemonic are specific for sparc and wont run on anything beside linux/solaris, hence making the compiler use specific kernel routines on those OSes[Posix] too, hence is not possible to compile this compiler on windows or run the result compiled binary on windows, hence OS dependant.

    2.) You say i can't implement just only the HLSL compiler to Wine?

    a.) you can but the result should be able to be interpreted by OpenGL since you don't have an DirectX driver and a compiler is lower than the wine DirectX layer and wine translate to opengl anyway
    b.) you can use specific IR like AMDIR/nVIR/TGSI/Etc. but then you have to manually handle how the context will interpret and link the shader to a GL object inside the framebuffer since again you don't have a DirectX driver
    c.) make a DirectX driver yourself, patch wine and add the compiler to the driver


    1) That i don't want: Make an OpenGL based D3D_compiler, or translate D3D to OGL. When you try to represent HLSL to GLSL, many times "word to word" its impossible. That's why we call it emulation. So something that in HLSL needs 100flops to give result, translated or compiled to GLSL needs 120+flops, so its inefficient.

    2) That i want: Vendors to give an HLSL front-end for their IL. So if i write an HLSL compiler will not be OGL based =inefficient, plus 10 times the work. For the IL its a front-end that is missing, but for a compiler the same thing is actually a back-end. A simple job is to write some Wine code and make MS_D3D to work with Wine (WineD3D work on Windows), then point the back-end extracted form the Windows driver(using Winetricks) to crate IL code, and all that inside a Wine Session. Its far less work than anything else.
    Last edited by artivision; 05 April 2013, 07:58 AM.

    Leave a comment:


  • xgt001
    replied
    when are the PM bits coming!

    first of thanks a lot AMD for releasing UVD code. now that this is open source will catalyst will also switch to vdpau?? and how can I try the open uvd code on my system? by latest development snapshot from git with mesa branch?? and looks like AMD is also ready with next round of PM .. when are you releasing it???

    Leave a comment:


  • artivision
    replied
    Originally posted by bridgman View Post
    Yes, two drivers. Not sure of current names but something like atidxx32.dll and atioglxx.dll...

    What do you mean by FX ?



    By FX i mean anything that looks like a shader program, but is inside a GPU driver instead of a game, like a filter for example.

    As for the driver, i thing that the synthesizer is not related to any API. That's why compilers target AMD_IL, because that A.I. machine unifies code from different compilers to a more ASIC form.

    Leave a comment:


  • hal2k1
    replied
    Originally posted by Hugh View Post
    If you publish specs, you might be endangering some trade secret. You certainly cannot endanger a copyright or a patent. We agree that trademarks aren't on the table.

    Your comment suggests to me that you are not talking enough with your lawyers. That surprises me since I picture you (or your predecessors) talking to them for half a dozen years.

    I'm also quite surprised at how long the "declassifying" process is taking. It has been over five years since the direction was announced. New chips have been released and sunsetted in that time. I know: I bought several in anticipation of open source drivers. The video card I'm using while I type this is an example: this HD 3600 has UVD1 and so is too old; I did buy it expecting more complete open source support.

    The sad thing is that in that five years, Intel has reached sufficient performance for video that it becomes the obvious choice. I bought a few cute Brazos systems but even the closed source drivers have made the experience disappointing. Stupid little things like not keeping up with the kernel, something caused by not being "in-tree".
    This is another comment with which I agree entirely. Programming specs in and of themselves are not IP, but I suppose they might possibly reveal some trade secret (some aspect of hardware design), but I really cannot see how.

    So now here is a second poster who has been able to express things better than I. I'm beginning to think that I might need to take a course on better communication skills, or something.

    PS: when I say programming specs are not IP, I should point out that AMD can have copyright over the programming spec documents. This would mean that no other party would have the right to duplicate AMDs programming specification documents and sell these document copies for monetary consideration without first getting permission from AMD to do so. It would not mean, however, that AMD would have any other rights over the information within these documents. After all, when AMD sells hardware to customers, said customers are actually supposed to be able to use that hardware however they please, including writing and running open source programs utilising that hardware.
    Last edited by hal2k1; 05 April 2013, 05:44 AM.

    Leave a comment:


  • log0
    replied
    TBH I find this whole GPU hardware interfaces IP completely surreal.

    Think of the following fictional case. AMD relesases a new CPU with some new and awesome Cool'n'Quiet bits, but requires you to use a driver to be able to use it. In addition the CPU will have a some badass simd block, but instead of being accessible through an instruction set extension you have to use a driver again.

    Because of the IP protection and stuff, you know.

    Leave a comment:


  • Hugh
    replied
    Originally posted by bridgman View Post
    The obvious issue here is that programming specifications can never be totally separated from IP, unless the hardware was designed with some kind of isolation layer to separate the programming from the operation, so effectively the community *is* asking AMD to release IP. This was the case for all hardware blocks... power management is no different.



    Header files and hardware design are sufficiently different that I don't think you can apply a "header file" ruling to hardware.

    I don't understand why you can't see how programming specifications could reveal information about protected IP, whether it be copyright, patent or trade secret (or any of the other mechanisms which aren't usually relevent to open source driver support).
    If you publish specs, you might be endangering some trade secret. You certainly cannot endanger a copyright or a patent. We agree that trademarks aren't on the table.

    Your comment suggests to me that you are not talking enough with your lawyers. That surprises me since I picture you (or your predecessors) talking to them for half a dozen years.

    I'm also quite surprised at how long the "declassifying" process is taking. It has been over five years since the direction was announced. New chips have been released and sunsetted in that time. I know: I bought several in anticipation of open source drivers. The video card I'm using while I type this is an example: this HD 3600 has UVD1 and so is too old; I did buy it expecting more complete open source support.

    The sad thing is that in that five years, Intel has reached sufficient performance for video that it becomes the obvious choice. I bought a few cute Brazos systems but even the closed source drivers have made the experience disappointing. Stupid little things like not keeping up with the kernel, something caused by not being "in-tree".

    Leave a comment:


  • sandy8925
    replied
    Yes! Finally! Awesome job AMD!

    This is awesome news! Video acceleration through the dedicated hardware video decoders on the graphics card exposed in the open source drivers through VDPAU. What I've dreamed about for a pretty long time. Keep up the good work AMD, I'm glad that you are providing documentation and development effort for improving the open source driver.

    Leave a comment:


  • hal2k1
    replied
    Originally posted by smitty3268 View Post
    I think the real issue here is that it's hard to understand why PM is so hard to release. I think most people understand that DRM issues complicate things when it comes to UVD, or HDMI/audio stuff, even if they don't like the fact that it does.

    But PM seems so basic/simple. Especially when we've had developers on here who've seen the code or specs under NDA and tell us that there's absolutely nothing in them that every other hardware vendor isn't already doing.

    That said, I'm sure there are a lot of issues holding it up. It's just not obvious what they would be to the average user, hence the frustration.

    Thanks again for the great work in getting UVD out. I'm now convinced that AMD's open source effort will work out in the long run, and it's just going to get better from here.
    I guess this was what I was trying to say, but expressed far better.

    I would just like to re-iterate here on the last paragraph above. I managed to express my frustration that the seemingly simple feature (in terms of sensitivity to revealing IP anway) of power management seems to have been an extraordinarily long time in coming, but I failed to mention appreciation for and the congratulations due to the AMD team for getting UVD out, which I would have thought would have been the far more problematic area.

    It was very remiss of me, so once again let me say great work on the UVD front. Let us all hope that the power management work can follow not too far behind, as that release would be a win-win for all concerned.

    Leave a comment:

Working...
X