Announcement

Collapse
No announcement yet.

The R600g Driver May Soon Be Working, But Lacks A Compiler

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

  • The R600g Driver May Soon Be Working, But Lacks A Compiler

    Phoronix: The R600g Driver May Soon Be Working, But Lacks A Compiler

    Just days ago we reported on the lack of progress with the ATI R600g driver that intends to provide Gallium3D support for ATI Radeon HD 2000/3000/4000 series graphics cards, but fortunately today there has been some activity in the Mesa Git repository for this open-source driver and a statement issued by the lead developer (Jerome Glisse) about its progress and he also has shared a TODO list...

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

  • #2
    The "classic" r600 Mesa driver does not support S3TC textures.

    Some games (*cough WoW*) will crash unless the driver can advertise S3TC texture extensions, but the r600c driver doesn't seem to handle S3TC textures at all yet. The patent-encumbered libtxc_dxtn.so module doesn't appear to be needed for WoW though.

    So the r300c isn't really an option in my case at all.

    Comment


    • #3
      I mean't that the r600c isn't an option, of course.

      Originally posted by chrisr View Post
      So the r300c isn't really an option in my case at all.
      And for the record, the "administrator" who has specified that I can only edit a post for that single first minute after posting it is an idiot who needs to be shot.

      Comment


      • #4
        Let's hope that r600c shader compiler offers some speed-up for hacking together the shader compiler for r600g. (unless I've understood wrong, something similar was done for r300 drivers originally)

        Comment


        • #5
          Originally posted by chrisr View Post
          Some games (*cough WoW*) will crash unless the driver can advertise S3TC texture extensions, but the r600c driver doesn't seem to handle S3TC textures at all yet. The patent-encumbered libtxc_dxtn.so module doesn't appear to be needed for WoW though.
          In my last WoW test all render correct but there is somewhere an sw fallback an an bug in the driver ( if you enter OG the game crash ) and i dont have installed this libary

          Comment


          • #6
            I understand what compilers are, but where I'm a bit lost right now is what the state of all the compilers in the graphic stack as it??? Over the years someone has suggested them, started them, dropped them, and there have been a bunch of articles lately talking about compilers for different purposes and stacks, and the response seems to be "yay! compilers!" and it really isn't clear what tactical versus strategic role they are playing.

            Off the top of my head I can think of
            + LLVM based compiler for Gallium3D to generate a faster software OpenGL rendering
            + LLVM compiling of Gallium3D IR code to optimize it before compiling it (using LLVM) into
            + Custom compilers for Shaders and Geometry for OpenGL for various drivers (being put into Mesa directly, or into Mesa or Gallium3D drivers (separately).
            + But why are we writing custom compilers anyway??? If it's for Gallium3D then would there be a common Shader/Geometry compiler for OpenGL in the OpenGL state tracker (common to all drivers). If it's a shader/geometry compiler for the hardware then shouldn't there be some common LLVM-IR based compiler that is fairly common and generic at the bottom of the stack (ie... only writing the hardware translation layer for LLVM /// recognizing there are possibly shortcomings in LLVM for GPU usage that perhaps have only been solved in commercial code bases)

            I guess it's this - everyone's writing a compiler yet we are we not moving towards a common-driver code base that eliminates as much 'custom' as possible???


            Could someone clarify the places for compilers in the graphic stack... I understand what a compiler is... it just seems every day someone is writing yet another compiler for some purpose at different places in the stack

            Comment


            • #7
              Most of the drivers use two compiler stages - one common, and one hardware-specific.

              The first compiler is implemented in common mesa code, and translates from application shader code to Mesa IR (classic) or TGSI (Gallium3D). Last time I looked the compiler always generated Mesa IR then the Gallium3D glue converted Mesa IR to TGSI before passing to a Gallium3D driver. I'm don't remember if the same compiler is used for assembly and GLSL shaders or if the compilers are different. Intel devs have been working on an improved version of this common compiler - that's the GLSL2 work you have seen mentioned here.

              The second compiler is implemented in each individual hardware driver, and goes from Mesa IR / TGSI to the appropriate instruction set for the target GPU. In the case of r300c/r300g the same compiler is used, by virtue of having the Gallium3D driver convert from TGSI back to Mesa IR before passing to the compiler.

              The shader compiler in r300c/r300g might be called a "real" compiler in the sense that it performs a number of optimization operations on the program before starting to generate code. The shader compiler in the r600 driver is simpler, essentially working on one application shader program instruction at a time, however the nature of the r600-and-higher hardware (variable length instruction words with up to 5 ALU operations per instruction) combined with the relatively high incidence of vector instructions in the shader programs means that the performance impact of a simpler compiler isn't as bad as you might expect.

              Usage of LLVM has been discussed in a number of places in the stack (including the hardware-specific shader compiler) but AFAIK right now it is only being used when running shader programs on the CPU, ie logically it is part of the "hardware driver for the CPU" aka softpipe. I forget where it actually lives in the source tree.

              I believe Ian (Intel) mentioned the possibility of having their new GLSL2 compiler also generate hardware-level instructions in the future, which would essentially skip over the Mesa IR representation and go straight to hardware. Not sure of the details there but presumably there are some additional optimization possibilities to be had.

              Comment


              • #8
                Intermediate code representations currently follow this scheme:

                Code:
                GLSL2 IR ---> Mesa IR ---> TGSI (Gallium) IR ---> Hardware-friendly IR
                There are lots of IRs in Mesa, indeed. The following scheme depicts various optimizers:

                Code:
                GLSL2 compiler and optimizer --+
                                               +---> Mesa IR optimizer ->-+
                ARB_fp/vp parser --------------+                          |
                                                                          |
                                                                          |
                R300 hw-specific optimizer <---+                          |
                                               |                          |
                R600 hw-specific optimizer <---+                          |
                                               +----<----- TGSI <---------+
                NV50 hw-specific optimizer <---+
                                               |
                LLVM for software drivers <----+
                Everybody has a different idea about where optimizations should be done. Gallium people would prefer to have a TGSI optimizer (that one is being worked on), while others (Intel) optimize in GLSL IR and Mesa IR.

                Comment


                • #9
                  How about using fglrx's compiler?

                  Comment


                  • #10
                    We actually use a similar model in the proprietary drivers - all of the API-specific programs are compiled down to a standard intermediate representation called "il" by the API-specific driver, then a common shader compiler turns the il code into a hardware program optimized for the specific GPU.

                    For anyone interested, the "il" spec is available on the stream docco page at :

                    http://developer.amd.com/gpu/ATIStre...mentation.aspx

                    We might be able to provide the shader compiler as an optional blob, but since the il is different from mesa IR or TGSI there would be another translation stage required.

                    I don't think it's worth doing at this point though - AFAIK the hardware efficiency of the shader compiler is about #73 on the list of performance bottlenecks

                    Comment


                    • #11
                      You don't need the libtxc_dtnx library

                      Originally posted by Nille View Post
                      In my last WoW test all render correct but there is somewhere an sw fallback an an bug in the driver ( if you enter OG the game crash ) and i dont have installed this libary
                      Use driconf to tell Mesa to advertise the S3TC extensions without it. WoW won't crash so long as the extensions are there, but you'll get a black screen until S3TC textures are at least partially supported.

                      Comment


                      • #12
                        Originally posted by bridgman View Post
                        I don't think it's worth doing at this point though - AFAIK the hardware efficiency of the shader compiler is about #73 on the list of performance bottlenecks
                        Where may said list be read?

                        I think it would be a good thing for would-be devs to see where to optimize.

                        Comment


                        • #13
                          Let's just hope that all these compilers do not have many bugs I can imagine with so many compilers there's a lot of potential for introducing bugs.

                          Comment


                          • #14
                            Originally posted by curaga View Post
                            Where may said list be read?

                            I think it would be a good thing for would-be devs to see where to optimize.
                            I haven't seen an actual list, although I suspect most of the devs would point to the same general area of the stack if asked (state management/command submission, synchronization/flushing, memory management).

                            Mostly the nasty areas that are hard to make reliable and easy to break.

                            Comment


                            • #15
                              Originally posted by bridgman View Post
                              Most of the drivers use two compiler stages - one common, and one hardware-specific...
                              Thanks bridgman and marek for clarifying.

                              I'm amused at the extra translations back and forth between Mesa/TGSI but I suppose this is allows maximum code re-use/sharing between classic and gallium3d until the new stack is more fully in place and can be re-factored/cleaned up.

                              Comment

                              Working...
                              X