Announcement

Collapse
No announcement yet.

AMD's R600 GPU LLVM Back-End To Be Renamed

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

  • AMD's R600 GPU LLVM Back-End To Be Renamed

    Phoronix: AMD's R600 GPU LLVM Back-End To Be Renamed

    AMD's "R600" LLVM back-end is likely to be renamed for LLVM 3.6...

    http://www.phoronix.com/vr.php?view=MTc1NDk

  • #2
    What about the R300?

    The intent to change R600 to AMDGPU bacause it supports all AMD GPUs from R600 up, but wouldn't that be confusing for owners of old GPUs? The last time I used a AMD GPU the driver required was the R300 (which supports GPUS from R300 up to R500), will they also reaname this one (to something like AMDGPULEGACY)? And what about the really really old radeon (supporting r100) and r200 drivers?

    Comment


    • #3
      I'm allergic to LEGACY

      Comment


      • #4
        Originally posted by faustop View Post
        The intent to change R600 to AMDGPU bacause it supports all AMD GPUs from R600 up, but wouldn't that be confusing for owners of old GPUs? The last time I used a AMD GPU the driver required was the R300 (which supports GPUS from R300 up to R500), will they also reaname this one (to something like AMDGPULEGACY)? And what about the really really old radeon (supporting r100) and r200 drivers?
        llvm doesn't support r300 or any older GPUs. Support for those older asics is implemented directly in the 3D driver; there is no dependency on llvm.

        Comment


        • #5
          To be clear: This is a change in the name of the llvm backend, the mesa drivers will still be called r300, r600, etc..

          Comment


          • #6
            Question time:
            Why does AMD have so many different FOSS drivers? Intel and Nouveau drivers manage to support most (not "legacy", but several years worth) of their cards in a single driver no? As an example, the newest Intel driver still supports my crappy Core2Duo integrated graphics from 6 years ago.

            Is there not an effort to bring r600 support to the latest RadeonSi code? I understand r300 and lower being left out (as that can be considered legacy) but r600 could use some love.
            And even if you don't bring ALL of the r600 cards, surely you could bring the newer half or more, then possibly push the older half (or less) down to the r300 driver or something (or move the r300 driver up to r600 and just straight out rename it to ReadeonLegacy)

            It's probably that I'm being an idiot here, I'd just like a clear explanation :P

            Comment


            • #7
              Originally posted by Daktyl198 View Post
              Question time:
              Why does AMD have so many different FOSS drivers? Intel and Nouveau drivers manage to support most (not "legacy", but several years worth) of their cards in a single driver no? As an example, the newest Intel driver still supports my crappy Core2Duo integrated graphics from 6 years ago.

              Is there not an effort to bring r600 support to the latest RadeonSi code? I understand r300 and lower being left out (as that can be considered legacy) but r600 could use some love.
              And even if you don't bring ALL of the r600 cards, surely you could bring the newer half or more, then possibly push the older half (or less) down to the r300 driver or something (or move the r300 driver up to r600 and just straight out rename it to ReadeonLegacy)

              It's probably that I'm being an idiot here, I'd just like a clear explanation :P
              Big changes in micro architectures.

              R300-R500 - ?
              R600 - TeraScale 1, 2 and 3
              SI and Rx 200 - GCN 1.0 and 1.1

              (someone correct me if I'm wrong).
              Last edited by Krejzi; 08-04-2014, 03:47 PM.

              Comment


              • #8
                Originally posted by Daktyl198 View Post
                Question time:
                Why does AMD have so many different FOSS drivers? Intel and Nouveau drivers manage to support most (not "legacy", but several years worth) of their cards in a single driver no? As an example, the newest Intel driver still supports my crappy Core2Duo integrated graphics from 6 years ago.

                Is there not an effort to bring r600 support to the latest RadeonSi code? I understand r300 and lower being left out (as that can be considered legacy) but r600 could use some love.
                And even if you don't bring ALL of the r600 cards, surely you could bring the newer half or more, then possibly push the older half (or less) down to the r300 driver or something (or move the r300 driver up to r600 and just straight out rename it to ReadeonLegacy)

                It's probably that I'm being an idiot here, I'd just like a clear explanation :P
                Guess it comes down to how similar the cards are. Big changes in hardware need big changes in software, much more so if you want to efficiently use the hardware. At some point its not wise to have a common driver, since changes in the common code could adversely affect some of the cards (quite some testing effort).
                I believe some of the OS drivers simply dont have the resources to have multiple tailored codebases, so while it kinda works everywhere (?) its very "basic" in functionality (I am certainly sure Nouveau fits this description cause it doesnt works at all for my GT240 or GT760, no idea about the intel driver).

                A bit more ontopic, just call the older stuff ATIGPU ? =)

                Comment


                • #9
                  Originally posted by Daktyl198 View Post
                  Question time:
                  Why does AMD have so many different FOSS drivers? Intel and Nouveau drivers manage to support most (not "legacy", but several years worth) of their cards in a single driver no? As an example, the newest Intel driver still supports my crappy Core2Duo integrated graphics from 6 years ago.

                  Is there not an effort to bring r600 support to the latest RadeonSi code? I understand r300 and lower being left out (as that can be considered legacy) but r600 could use some love.
                  And even if you don't bring ALL of the r600 cards, surely you could bring the newer half or more, then possibly push the older half (or less) down to the r300 driver or something (or move the r300 driver up to r600 and just straight out rename it to ReadeonLegacy)

                  It's probably that I'm being an idiot here, I'd just like a clear explanation :P
                  Intel prefering a single driver while AMD having multiple doesn't mean much.

                  I still have got an old Intel IGP here, with OpenGL 2.1 and no H.264 acceleration on Linux. And I doubt there will be much work put into it, given how ancient the hardware already is. Intel guys have to prioritize too, even when they have more resources than AMD.

                  Comment


                  • #10
                    Intel also have separated mesa drivers i915 and i965, but kernel driver is very vary it is i915 for all .

                    Very confusing .

                    Comment


                    • #11
                      Originally posted by Daktyl198 View Post
                      Question time:
                      Why does AMD have so many different FOSS drivers? Intel and Nouveau drivers manage to support most (not "legacy", but several years worth) of their cards in a single driver no? As an example, the newest Intel driver still supports my crappy Core2Duo integrated graphics from 6 years ago.

                      Is there not an effort to bring r600 support to the latest RadeonSi code? I understand r300 and lower being left out (as that can be considered legacy) but r600 could use some love.
                      And even if you don't bring ALL of the r600 cards, surely you could bring the newer half or more, then possibly push the older half (or less) down to the r300 driver or something (or move the r300 driver up to r600 and just straight out rename it to ReadeonLegacy)

                      It's probably that I'm being an idiot here, I'd just like a clear explanation :P
                      is simply more efficient because AMD architectures has changed dramatically over the years and those changes aren't reusable in the drivers, so in resume each driver represent a extreme architecture change(r500 -- r300, VLIW4-5 -- r600, GCN1.x RadeonSI). Intel on the other hand hasn't changed that dramatically over the years(it seems), so for now they can keep one driver for all revisions.

                      Btw r600 is not that far behind RadeonSI, the problem is that not all the hardware in that(VLIW4 & 5) generations can handle OpenGL 4.+ and i understand there are hardware bugs delaying the feature parity with RadeonSI, in resume OpenGL4+ features land first in RadeonSI because the hardware make it lot easier but for old hardware some workaround are needed depending on the hardware and obviously introduces delays.

                      but don't get confused R600 and RadeonSI share a LOOOOT of code internally as long as is possible

                      r300 hardware support is done beyond bug fixing, that hardware can't support anything beyond what already r300 has to offer.

                      Comment


                      • #12
                        Originally posted by Daktyl198 View Post
                        Question time:
                        Why does AMD have so many different FOSS drivers? Intel and Nouveau drivers manage to support most (not "legacy", but several years worth) of their cards in a single driver no? As an example, the newest Intel driver still supports my crappy Core2Duo integrated graphics from 6 years ago.

                        Is there not an effort to bring r600 support to the latest RadeonSi code? I understand r300 and lower being left out (as that can be considered legacy) but r600 could use some love.
                        And even if you don't bring ALL of the r600 cards, surely you could bring the newer half or more, then possibly push the older half (or less) down to the r300 driver or something (or move the r300 driver up to r600 and just straight out rename it to ReadeonLegacy)

                        It's probably that I'm being an idiot here, I'd just like a clear explanation :P
                        Both Intel (i915, and i965) and Nouveau (classic mesa nouveau, and gallium nouveau) have several drivers as well depending on how old the hw is. Most of the code is shared internally where applicable anyway, so the actual driver binaries are largely meaningless. Also, it only makes sense to share code where it's applicable.

                        Regarding the i965 driver supporting your 6 year old IGP, the r600 driver support 6-8 year old hw as well. The radeon/r200/r300 drivers support cards that are more like 10-15 years old. They don't really have much in common with newer hardware so there's not much that can be shared.

                        I'm not sure I understand your comment about bringing r600 up to the level of radeonsi. r600 and radeonsi are prettty much at feature parity at this point. Most of the applicable code is shared between them already.

                        Comment


                        • #13
                          It's funny because LLVM actually suggested that they rename it back when they wanted to main line it. AMD's argument then was that they consistently name there different back ends after the first supported generation of chips.

                          Comment


                          • #14
                            Originally posted by jrch2k8 View Post

                            r300 hardware support is done beyond bug fixing, that hardware can't support anything beyond what already r300 has to offer.
                            Drivers supports what developers decide to support, never exactly all off what hardware can support is supported .

                            I was impresed with fglrx when i saw GL_ATI_fragment_shader, GL_ATI_envmap _bumpmap... still works fine on Kabini . Blob drivers seems like never has removals of features because "no one use this and that", "it is maintance burden, so lets remove it", "we will remove or not implement this, because it is obsolete and newer is better"... .

                            Even if miracle happen and AMD decide to open fglrx - developers can just scream at that . And of course remove something .

                            -------

                            Just my 2 cents - house is better to be clean, but users like all possible features at hands
                            Last edited by dungeon; 08-04-2014, 04:59 PM.

                            Comment


                            • #15
                              Originally posted by dungeon View Post
                              Drivers supports what developers decide to support, never exactly all off what hardware can support is supported .

                              I was impresed with fglrx when i saw GL_ATI_fragment_shader, GL_ATI_envmap _bumpmap... still works fine on Kabini . Blob drivers seems like never has removals of features because "no one use this and that", "it is maintance burden, so lets remove it", "we will remove or not implement this, because it is obsolete and newer is better"... .

                              Even if miracle happen and AMD decide to open fglrx - developers can just scream at that . And of course remove something .

                              -------

                              Just my 2 cents - house is better to be clean, but users like all possible features at hands
                              Well, r300 era hardware just don't have the silicon to support more than it already does and even if it has silicon so support certain additional features they should not be exposed by the driver since is not compliant with the rest of the specification.

                              about additional old extensions, i personally consider they should be removed or at least blocked into legacy contexts to make sure developers are forced to pick more efficient methods instead of relying in old crust and pollute the drivers regardless of the vendor, this is exactly one of the reasons that make FGLRX a white whale of millions of LoC that need months to fix even the simplest of details.(specially true with the CAD lazy ass fucker developers)

                              Comment

                              Working...
                              X