Announcement

Collapse
No announcement yet.

AMD Releases Open-Source UVD Video Support

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

  • I didnt mean any offense of course. I was just stating the obvious. You of all people know better then just about anyone else that some people will complain no matter what. Personally I think the driver is kicking ass. I'm very happy with it. But power management was more important than the priority it was given. I'd like to think that if it was implemented earlier there would have been a lot fewer complaints. There would have been complaints about this that or the other, but I don't think it would have been equal to the volume of complaints about power management.

    EDIT: And I'm not assigning blame. It isnt your fault of course. I don't think anybody could have anticipated this situation wthout prior experience. In addition the legal review process is obviously flawed and that isnt any of the developers fault either.
    Last edited by duby229; 04-05-2013, 12:28 AM.

    Comment


    • Originally posted by duby229 View Post
      But power management was more important than the priority it was given.
      Again, what did we prioritize before this round of power management that we shouldn't have ? Your choices are basically display and 3D. Remember that we started the review efforts on PM before we started work on UVD and well over a year before starting things like DMA.

      Originally posted by duby229 View Post
      I'd like to think that if it was implemented earlier there would have been a lot fewer complaints. There would have been complaints about this that or the other, but I don't think it would have been equal to the volume of complaints about power management.
      This is probably true, although our governments provide a pretty good lesson that choosing decisions which minimize complaints at each step does not usually lead to the best overall decisions. It is possible that we should have sequenced power management before doing much with 3D acceleration on 6xx and higher, although there's a *really* good chance the program would have been declared a failure and shut down if we had gone with that approach. Hard to say.

      Originally posted by duby229 View Post
      EDIT: And I'm not assigning blame. It isnt your fault of course. I don't think anybody could have anticipated this situation wthout prior experience.
      It actually is my fault, in the sense that I managed the team, I set the priorities, and I didn't push our developers to improve the driver-based PM (with full knowledge that it was dead-end work). That was really the only option we didn't take, but remember that Alex had already done quite a bit of work on power management to get it to its current state.

      It certainly would have been nice if we had started this round of PM hardware review in 2010 rather than 2011, but we only had two developers and part of my time so given all the other things going on I don't see how we could have done that without dropping something bigger in the process.

      Originally posted by duby229 View Post
      In addition the legal review process is obviously flawed and that isnt any of the developers fault either.
      I'm not sure the legal review process is flawed (and for the bazillionth time it's primarily a technical review ) as much as it accurately reveals the current state of things... AFAIK no SOC vendor really designs their hardware to be fully open source compatible from the start, so it takes a lot of years (and sometimes some HW redesign) before all of the major blocks can be exposed.

      We started supporting open source drivers early (back in '99 IIRC) but stopped when we acquired FireGL and their proprietary Linux driver, and didn't re-start the effort until 2007. That may seem like a long time to you, but vendors which have been working with open source drivers for a lot longer only finished exposing their major blocks in the last couple of years and if anything we're moving a bit faster than our competitors there. I know that doesn't help, but it probably is worth understanding anyways.
      Last edited by bridgman; 04-05-2013, 01:32 AM.

      Comment


      • Originally posted by bridgman View Post
        Again, what did we prioritize before this round of power management that we shouldn't have ?
        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.

        Comment


        • 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.

          Comment


          • 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.

            Comment


            • 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".

              Comment


              • 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.

                Comment


                • 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; 04-05-2013, 05:44 AM.

                  Comment


                  • 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.

                    Comment


                    • 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???

                      Comment


                      • 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; 04-05-2013, 07:58 AM.

                        Comment


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

                          Comment


                          • 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.

                            Comment


                            • Thanks for the effort guys. It's really appreciated.
                              Cheers!

                              Comment


                              • Originally posted by artivision View Post
                                Anyway thanks for the UVD support, but GPUs are all about gaming.
                                Of course, the HD3200 in my laptop is all about gaming. The HD4200 on many mainboards with RS880 chipset also. As are the low-spec videocards, like the HD54XX or 64XX. You must be kidding.

                                Anyways, thanks for that, AMD! If you now get PM to work properly I could switch my laptop to the radeon driver without overheating and I won't have to use the legacy drivers anymore, so that I can keep up again with Slackware -current on that machine.

                                Comment

                                Working...
                                X