Announcement

Collapse
No announcement yet.

In Road To OpenCL, R600g LLVM Back-End Arrives

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

  • #16
    I'm not sure I understand the need for all these abstractions... I thought the whole point of gallium was to make a single abstraction so that others wouldnt be required? Shouldnt it just be clover >> tgsi >> gpu, if run on the gpu, or clover >> llvm >> cpu, if run on the cpu?

    Also would performing all these redundant translations effectively hurt end performance.... doesnt translating from this to that to these to those hurt performance? also assuming that one IR is less capable than another, (thinking of opengl) wouldnt you lose capability during one or more of these translations?
    Last edited by duby229; 12-11-2011, 12:40 AM.

    Comment


    • #17
      Originally posted by bridgman View Post
      I'll check that with our legal folks. The license doesn't seem to conflict with the portion of the definition you quoted, but there's a section further down the definition text which says that reminding licensees about the need to comply with export control law is OK but adding restrictions directly is not.

      The license text on the AMDIL bits appears to reference the current US export laws and qualifies the restriction based on the type of content (ie basically saying "if the US export control laws restrict it then you can't export...", not sure whether that qualifies or not since the restriction only applies to "restricted" content and the definition of restricted presumably comes from the current BIS regs.
      how it works to make the code structure of AMDIL compatible with Gallium3D?

      a simple rewrite? or a automate translating tool? or a chance in Galium3D ?

      how is this possible in the past the official point was its not possible to use fglrx/catalyst source code in the galium3D driver.

      or is this only true for graphic stuff?

      Comment


      • #18
        Originally posted by Qaridarium View Post
        how is this possible in the past the official point was its not possible to use fglrx/catalyst source code in the galium3D driver.
        AMD IL is not an big secret and if you want you can implement it http://developer.amd.com/sdks/amdapp...ication_v2.pdf

        Comment


        • #19
          Originally posted by AnonymousCoward View Post
          I don't get all this hype about OpenCL. I'm sure that there are some specialized niche applications making use of OpenCL but as a consumer I'd rather see AMD devoting some manpower to finally get video decoding working on the open drivers.
          given the year+ of stated legal review to be put in place to finally open up the UVD decode block for linux use that never seems to actually happen, and the fact that they cant even be bothered to compile and release the OpenCL OpenVideo driver for Linux video decode library that apparently relies on that closed UVD code block, and has existed for the windows SDK for a full year....

          then you have as much chance (aka almost nil) of them doing that video decoding work now, as the so called HD 7000 Series ,the latest and greatest GCN (Graphics Card Next, got to love those PR innovators and their names to sell it to the masses) architecture has of actually dumping that closed Obsolete and dead UVD block and actually replacing it with a real open Linux usable hardware assisted video decode and actual Video ENCODE with SW patches within another 3 years, unlike the Intel and ARM/NEON cores that have that hardware encode/decode block capability right now, and perhaps far more importantly, are actively sending GIT patches to the FFMPEG/AVCONV developers etc. to make use of these HA blocks today.
          Last edited by popper; 12-11-2011, 07:35 AM.

          Comment


          • #20
            Originally posted by duby229 View Post
            I'm not sure I understand the need for all these abstractions... I thought the whole point of gallium was to make a single abstraction so that others wouldnt be required? Shouldnt it just be clover >> tgsi >> gpu, if run on the gpu, or clover >> llvm >> cpu, if run on the cpu??
            I think that is pretty much the plan, although our current thinking is clover >> llvm >> gpu for compute without using tgsi. The glsl ir >> tgsi >> llvm >> gpu path is just for testing right now but I think we'll use it for initial GCN support as well.

            Originally posted by duby229 View Post
            Also would performing all these redundant translations effectively hurt end performance.... doesnt translating from this to that to these to those hurt performance? also assuming that one IR is less capable than another, (thinking of opengl) wouldnt you lose capability during one or more of these translations?
            The translations tend to be pretty cheap compared to the processing that is done with the translated results. IIRC the only translations in the production stack are GLSL IR>>Mesa IR for older graphics drivers and GLSL IR>>TGSI for Gallium3D drivers. If LLVM works out OK for GCN we'll probably keep the GLSL IR>>TGSI>>LLVM IR>>GPU path until the next round of serious discussions about IR. If no consensus forms and it turns out the TGSI>>LLVM IR translation is expensive then I guess it would make sense to generate LLVM IR directly from GLSL IR up in the common Mesa code, so the graphics path for GCN would be glsl ir >> llvm ir >> gpu.

            Comment


            • #21
              Originally posted by Qaridarium View Post
              how it works to make the code structure of AMDIL compatible with Gallium3D? a simple rewrite? or a automate translating tool? or a chance in Gallium3D ?
              It's just another IR, so I guess we could add entry points / options to the Gallium3D API so that AMD IL could be accepted, but it's not something we are looking at today.

              Originally posted by Qaridarium View Post
              how is this possible in the past the official point was its not possible to use fglrx/catalyst source code in the galium3D driver. or is this only true for graphic stuff?
              In this case the Catalyst compute stack uses LLVM and we're pushing our LLVM changes back wherever possible. Originally the changes were just going to go to the LLVM project but in this case Tom found them useful as a basis for OpenCL / GCN support.

              Normally the flow would be :

              - OpenCL team pushes code back to the LLVM project
              - open source graphics developers pick up changes from the LLVM project, either indirectly (as Mesa picks up new LLVM versions) or directly

              In this case the code was pushed to LLVM and Mesa simultaneously, and consistent with our "30 seconds after approval" habit the code got into a Mesa branch before it hit the LLVM mailing list

              Comment


              • #22
                popper, I've responded to these statements a few times in the past, guess once more won't hurt.

                Originally posted by popper View Post
                given the year+ of stated legal review to be put in place to finally open up the UVD decode block for linux use that never seems to actually happen,
                - it's not just legal review, it's technical review related to DRM risk among other things
                - the time-consuming part is not the review, it's what happens when the outcome from the review is "no" and you have to find new approaches & repeat

                Originally posted by popper View Post
                and the fact that they cant even be bothered to compile and release the OpenCL OpenVideo driver for Linux video decode library that apparently relies on that closed UVD code block, and has existed for the windows SDK for a full year....
                - it's not a question of recompiling, the code has to be *written* for Linux; as you know Windows has its own video framework which is not available under Linux

                Comment


                • #23
                  is this problem to include DRM as closed-source plugin for drivers/players ?

                  Comment


                  • #24
                    This is getting off topic for an LLVM thread but quick answer is that a binary plug-in for an open source driver doesn't give enough protection to make any real difference -- either something is safe enough to release source code or it's not safe enough to release as a plug-in to an otherwise open driver. It seemed like an attractive idea at first but I haven't seen binary plug-ins used for a few years now.
                    Last edited by bridgman; 12-11-2011, 02:06 PM.

                    Comment


                    • #25
                      Originally posted by bridgman View Post
                      This is getting off topic for an LLVM thread but quick answer is that a binary plug-in for an open source driver doesn't give enough protection to make any real difference -- either something is safe enough to release source code or it's not safe enough to release as a plug-in to an otherwise open driver. It seemed like an attractive idea at first but I haven't seen binary plug-ins used for a few years now.
                      A bit OT, but I'm also of the opinion that binary plugins to an OSS application effectively taints the application. If the OSS code is GPLd then the binary plugin is a gpl violation in my opinion... Perfect example, binary linux drivers...

                      I know many people who disagree with me mightily, but I also know many people who agree with me mightily. And being a linux community, I'd argue there are more people who agree with me....
                      Last edited by duby229; 12-11-2011, 10:48 PM.

                      Comment


                      • #26
                        Originally posted by duby229 View Post
                        A bit OT, but I'm also of the opinion that binary plugins to an OSS application effectively taints the application. If the OSS code is GPLd then the binary plugin is a gpl violation in my opinion... Perfect example, binary linux drivers...

                        I know many people who disagree with me mightily, but I also know many people who agree with me mightily. And being a linux community, I'd argue there are more people who agree with me....
                        a) People want to get their job done fast and efficiently

                        b) People don't care if the software kills baby kittens everytime they hit the space button if it gets the job done

                        c) The rest is bullshit by people whom job has all the OS tools they need

                        And the perfect example for this is graphic cards. Anyone that wants 100% performance and features uses the blobs.

                        Comment


                        • #27
                          You mean: they use Windows.

                          Because Windows drivers are still better than Linux blobs.

                          So if you're using blobs on Linux, you are making sacrifices too. The only question is where you make them: security, performance, ease of maintenance, reliability, integration with your desktop, power consumption, your ethical standards, Digital Restriction Management, etc.

                          For many people, FLOSS drivers under Linux provide the best environment.

                          Comment


                          • #28
                            i like open drivers for gpu, more than fglrx, but cant even play quake live on open drivers on radeon 4850.. that suck hard wine cant open even starcraft/pharaoh good with no fglrx. thes are very old games with even no 3d, but still work very very slow, or dont work at all.

                            now another restriction, and another

                            in future open drivers will only show desktop consume max power, but give you good system integration [and bad svideo output]

                            thats not that we are fighting for. I can use binary plugins, need to use it for HP 1020 printers is this any violation? not for me, i need hardware to work. its only plugin you can manualy install [accept to install] same as audio/video codecs. some of them are close source and we still use it. iam not gpl purist i just need pc working.

                            Comment


                            • #29
                              Hrm, I remember playing QuakeLive on my HD 4550 just fine a couple of years ago.

                              Is it a framerate issue, or does it refuse to start?

                              Comment


                              • #30
                                Originally posted by pingufunkybeat View Post
                                You mean: they use Windows.

                                Because Windows drivers are still better than Linux blobs.

                                So if you're using blobs on Linux, you are making sacrifices too. The only question is where you make them: security, performance, ease of maintenance, reliability, integration with your desktop, power consumption, your ethical standards, Digital Restriction Management, etc.

                                For many people, FLOSS drivers under Linux provide the best environment.
                                Whatever gets the job done

                                In some cases its windows in others linux in others mac or whatever

                                Comment

                                Working...
                                X