Announcement

Collapse
No announcement yet.

AMD Releases Open-Source UVD Video Support

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

  • #91
    Originally posted by Veerappan View Post
    Technically yes, but it's not quite the same as the UVD2 in the r7xx discrete chips. At the moment it's not working.

    Comment


    • #92
      Originally posted by Veerappan View Post
      AFAIK there are enough differences that the code which works on other UVD2 implementations doesn't work yet on the UVD in the IGPs. I believe Christian posted about this earlier in the thread.

      Comment


      • #93
        Originally posted by [Knuckles] View Post
        Had to be said!

        Good job
        Would be nice to get UVD1 on my X1300.
        Thanks that made my day.

        Comment


        • #94
          Originally posted by droidhacker View Post
          That's absurd. The open source drivers are very close to the blobs. You're way behind the times.

          Also, there's no such thing as "twenty times slower". "times" means multiply. You can't multiply "slowness".
          I think that the previous poster is referring to the fact that the Llano (and maybe Trinity) APUs default to a low power state in the VBIOS, whereas the AMD Desktop cards default to a high power state. In order to get full performance out of Llano/Trinity, you need to set the power profile to high, or you need to set the power method to dynpm.

          Comment


          • #95
            Originally posted by Veerappan View Post
            I think that the previous poster is referring to the fact that the Llano (and maybe Trinity) APUs default to a low power state in the VBIOS, whereas the AMD Desktop cards default to a high power state. In order to get full performance out of Llano/Trinity, you need to set the power profile to high, or you need to set the power method to dynpm.
            No, that's not it. Setting the profile or enabling dynpm will do nothing, because the driver simply does not allow higher clocks. There is no way to get the full clock working on mobile APUs without hacks.

            Comment


            • #96
              Originally posted by brent View Post
              No, that's not it. Setting the profile or enabling dynpm will do nothing, because the driver simply does not allow higher clocks. There is no way to get the full clock working on mobile APUs without hacks.
              Good to know. I've got a llano (3-core, maybe A6-3500) in my HTPC, but since I'm not using it for heavy 3d, I've never really investigated the clock speed/performance issue.

              Comment


              • #97
                Originally posted by bridgman View Post
                AFAIK there are enough differences that the code which works on other UVD2 implementations doesn't work yet on the UVD in the IGPs. I believe Christian posted about this earlier in the thread.
                Yeah, I hadn't finished reading the thread yet. Now I'm all caught up

                Hopefully he figures the differences out. I've got a Radeon 6850, A6-3500, HD4200, and an HD3200 in various systems at home. The HD3200 is in a file-server, but the rest of them could end up doing video decoding duties at any time in the future, and the A6-3500 spends an average of 2 hours a night playing back recorded HD TV episodes.

                Comment


                • #98
                  Joining the "Thank you AMD" chorus!

                  Comment


                  • #99
                    Serious Sam works on r600g same as on Catalyst at least for my humble 5730M. (Bad in both cases :P)

                    Comment


                    • Originally posted by artivision View Post
                      I really try hard to understand what you say.

                      1) Rasterizers inside GPU drivers are unified (as vendors say). They can execute shaders and draw graphics from multiple shader languages, with a simple front end, plus a compiler target back-end in order for a compiler to terget the GPU.

                      2) When i say SSE4.2 or AVX, i mean at least 6-insructions processors with 7 - 9.5 drystone(dmips/mhz) single thread.

                      3) Are you a programmer? Have you even try to compile GLSL_source to GLSL_bytecode and then to GLSL_machinery_code. It takes 2-15 minutes for simple shader programs, the most of it to the first half. Now add the HLSL_bytecode to GLSL_source and then you have it. The problem isn't to the dead corners. The only possibility here is to write some sub-extensions for OpenGL extensions that will compile D3D cases. Something like sub-compiler that will target open and closed GLSL compilers inside GPU driver, and this sub-compiler will be LLVM friendly.

                      4) MS has already lose court fight for HLSL implementation. We only ask that an MS-D3D(via Wine) can see the GPU directly, without translations.
                      1.) ofc the GPU internally can execute any form of shaders as long as it use supported by the hardware opcodes
                      2.) well my point is no game uses sse 4.2/AVX this days[maybe unreal4 but not sure yet] and the single thread performance is very relative after all most games bottlenecks are on the bandwith/GPU side more than the CPU and in some others the CPU do affect the max framerate but normally the FPS is high enough to not care, so this days for most games the CPU point is moot unless you wanna break a Bench record or play with multimonitors in 3D[which neither is properly supported in linux yet]
                      3.) i am and those timings are insanely high you probably have a huge time eater in your code unrelated to the to hlsl-glsl
                      4.) again my point the wine performance is close enough but wine is already exploring an option to have an external hlsl compiler especially for DX10/11 http://wiki.winehq.org/HLSLCompiler but again the current wine implementation for Dx9 can handle very well very taxing games like crysis 2 in very high settings fluid enough for me not to care.
                      5.) handle the gpu directly is probably not a good idea at all

                      here you can see how wine shaders work http://wiki.winehq.org/DirectX-Shaders

                      Comment


                      • Originally posted by droidhacker View Post
                        At least not once the koolaid has been consumed, as you obviously have.
                        In my country, there is no coolaid. So, if I prove you wrong, that would mean you are the one on "coolaid", so lets remove your pink glasses for good.
                        First of all, please study this thread.
                        Particularly, study later post where one user confirms how bad opensource driver performs on A8, confirming my expectations.


                        AMD APUs on opensource driver are 20 times slower, so slow that hardware-level slower Intel wipes floor with them.

                        This is the best fair result I can come up with:
                        http://openbenchmarking.org/result/1...AR-1208249SU89

                        AMD side can be improved - if you can find A8/A10 running 1920x1080, kernel 3.5 or any later radeon driver - POST.

                        Originally posted by droidhacker View Post
                        Why would anybody possibly want to use catalyst??? Radeon performs close (and in some cases *ahead*) of catalyst, and supports everything that catalyst does.
                        Because 99% of AMD radeon supporters are catalyst consumers. In that case - better straight go nvidia, proprietary too, performed good for ages.
                        So much for opensource.

                        But no, many AMD users use AMD just because they love two half broken drivers and consider this state of permanent breakage to be optimal [Link].
                        Ok, but lets compare fairly - opensource vs opensource, should we? Radeon vs Intel on according hardware.
                        By the way, its nearly IMPOSSIBLE to find A8/A10 APU on opensource radeon on openbenchmarking, 99% results are fglrx
                        Donīt believe me - try!


                        Originally posted by droidhacker View Post
                        Are you possibly confusing AMD with nvidia??? I choose AMD ***because of open source***.
                        No, I am not confusing anything. I choose NOT AMD, because open source is Intel and AMD is closed source.
                        Opensource AMD is inofficial, on not full documentation, inadequate support, inadequate performance.
                        This opensource is not far from nvidia, where documentation is added and few developers are present.

                        That said, I try to use only opensource. But only if its adequate in terms of software and RnD power.
                        Right now, it is not adequate. But I do appreciate what is happening today with one of AMD drivers.

                        Originally posted by droidhacker View Post
                        Ok, so you want to REALLY MURDERFY intel then? LOL.
                        As an argument to "AMD should hire 20-30 more opensource developers, which Intel already has" - yes, they can try.
                        "MURDERFY" - thats LOL.

                        Originally posted by droidhacker View Post
                        That would be helpful, but you can control power consumption quite easily already.
                        On Intel its automatic. As it should be, no?

                        Originally posted by droidhacker View Post
                        ... uh, right. That poor 3D performance that is already WAY WAY better than intel, and "right up there" with nvidia blobs?
                        Answered by link above. Performance is below Intel.

                        Originally posted by droidhacker View Post
                        AMD is basically ahead of intel in ALL of your "wants".
                        I purchased already 3 Intel systems to run with opensource driver. They run bug-free, cool, out of the box and have good 3D. Like it should be, no, amd-fan?
                        Hope this answers "ahead" and "in ALL my wants".

                        Originally posted by droidhacker View Post
                        If you are an opensource supporter, buy AMD. AMD open source stuff actually works. Too bad you drank the koolaid.
                        Prove it then.
                        If you have AMD machine, do tests: Lightsmark, Xonotic (High) and OpenArena 0.8.8. Profile: 1920x1080.
                        Post profile result the result here so we can compare it to profile above, that covers HD2000,2500, 3000 and 4000.

                        Can use any kernel you want - I recommend 13.04, updated, with xorg-edgers, or oibaf, or stock - at your will. Because its fast and reliable result.

                        I have access to two Intel machines with specified configuration, one HD2000, other is HD3000.
                        I can test too and submit profile to compare to your configuration.

                        Comment


                        • Thanks for the great feedback!

                          I'd just like to say thanks for all the positive feedback. It's great to know that our work is appreciated.

                          And a big thanks to John Bridgman and all the folks at AMD who helped out. You know who you are.

                          Tim

                          Comment


                          • Has anyone had a chance to test with E series APUs?

                            Comment


                            • Yes. twriter Thanks for getting this code out. You guys have done a fantastic job. If you guys keep up the good work it won't be long until we have all the features a desktop gpu driver should have.

                              Comment


                              • Originally posted by chrisr View Post
                                OK, there must be a DRM-related compromise somewhere in here. Does this mean that the HDMI connector will not and cannot initiate HDCP with this driver?
                                There's no support for commonly used DRM / content protection techniques. So yes, no HDCP.

                                Tim

                                Comment

                                Working...
                                X