Announcement

Collapse
No announcement yet.

LunarG Proposes A Shader And Kernel Compiler Stack

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

  • LunarG Proposes A Shader And Kernel Compiler Stack

    Phoronix: LunarG Proposes A Shader And Kernel Compiler Stack

    LunarG, the consulting company providing professional services for Mesa / Gallium3D that's led by Jens Owens, the founder of Tungsten Graphics, is beginning to commence work on a new project: LunarGLASS. Last year, LunarG wanted to provided better Linux graphics documentation, but this new LunarGLASS initiative is much more ambitious and it's about providing a complete shader and kernel compiler stack...

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

  • #2
    Does it bring OpenGL 4.1 to Mesa?

    Does it magically make Intel/Radeon/Nouveau open source drivers faster than they are today?

    If none of this, who wants/needs it?

    Comment


    • #3
      Originally posted by birdie View Post
      Does it bring OpenGL 4.1 to Mesa?

      Does it magically make Intel/Radeon/Nouveau open source drivers faster than they are today?

      If none of this, who wants/needs it?
      that's a poor attitude, not everything has to have an immediate benefit, y'know.

      Comment


      • #4
        I'd be interested to see some driver devs comment on this. Thus far I've mostly heard comments that LLVM isn't really that useful in GPU drivers and this thing seems to lean heavily towards LLVM front.

        Comment


        • #5
          Originally posted by birdie View Post
          Does it bring OpenGL 4.1 to Mesa?
          It helps.

          Does it magically make Intel/Radeon/Nouveau open source drivers faster than they are today?
          Yes, as it will make the compiled shaders run faster, which is where all the graphics computation is happening in modern apps.

          Comment


          • #6
            Any plans to optimize the Gallium3d on Radeon (R500)? If so, what is the time frame?

            Comment


            • #7
              Will this eliminate the vast amount of translations in gallium (between mesa ir, tgsi and god knows what else)?

              If yes, then I think we all would like to have this.

              Comment


              • #8
                Originally posted by HokTar View Post
                Will this eliminate the vast amount of translations in gallium (between mesa ir, tgsi and god knows what else)?

                If yes, then I think we all would like to have this.
                According to the proposal, in the short term it will add extra translations (it will hook itself in between the existing GLSL2 IR and TGSI/classic MESA IR). Then, after it's proven itself, all those extra layers could drop away when drivers create backends directly into the new stack rather than relying on TGSI.

                Comment


                • #9
                  So it's basicaly "Hey let's test if this is hella fast", while maintaining compatibility with Gallium and TGSI, and when it's faster it will repace the TGSI IR with itself (as soon as drivers decide not to eat TGSI but this new Glass IR...)

                  Seriously... why the hell not?

                  Comment


                  • #10
                    Originally posted by V!NCENT View Post
                    So it's basicaly "Hey let's test if this is hella fast", while maintaining compatibility with Gallium and TGSI, and when it's faster it will repace the TGSI IR with itself (as soon as drivers decide not to eat TGSI but this new Glass IR...)

                    Seriously... why the hell not?
                    yep, but real issue probably is "will gallium, intel/ati\amd/nouveau developers do it solely or LunarG people ?"

                    because, if former - it will take up precious time in which they could be implementing OpenGL 3.3 and stabilising & optimising current code.
                    if later - it will be sweet: guys will do initial work on their branch, test it and merge it if it succeed.

                    Comment


                    • #11
                      The challenge here is that it's not a question of "code both and see which runs best", the question is whether the benefits (from being able to leverage ongoing work by the llvm community) will outweigh the costs (from replacing the current GPU-centric-ish IRs with an arguably CPU-centric IR plus GPU extensions and GPU-aware middleware) over time.

                      It's a very timely question, but even an initial implementation is only likely to demonstrate that llvm IR can work "OK" with GPUs. The big argument in favor of this proposal is that CPUs and GPUs are becoming more alike over time. I hadn't really thought of GPU architecture in terms of AoS or SoA, so I'll probably have to read the proposal a few times to get those terms mapped onto SIMD and superscalar/VLIW

                      Keith W summed the situation up pretty well :

                      So basically I think it's necessary to figure out what would
                      constitute evidence that LLVM is capable of doing the job, and make
                      getting to that point a priority.

                      If it can't be done, we'll find out quickly, if it can then we can
                      stop debating whether or not it's possible.

                      Comment


                      • #12
                        Originally posted by bridgman View Post
                        The challenge here is that it's not a question of "code both and see which runs best", the question is whether the benefits (from being able to leverage ongoing work by the llvm community) will outweigh the costs (from replacing the current GPU-centric-ish IRs with an arguably CPU-centric IR plus GPU extensions and GPU-aware middleware) over time.

                        It's a very timely question, but even an initial implementation is only likely to demonstrate that llvm IR can work "OK" with GPUs. The big argument in favor of this proposal is that CPUs and GPUs are becoming more alike over time. I hadn't really thought of GPU architecture in terms of AoS or SoA, so I'll probably have to read the proposal a few times to get those terms mapped onto SIMD and superscalar/VLIW

                        Keith W summed the situation up pretty well :
                        Another question is:
                        Is this stack model more scalable than current mesa design?

                        We FOSS end users also want ATI and nouveau 3d accel at commercial levels (Leaving aside the time needed to make the driver, of course).

                        Comment


                        • #13
                          I don't think there's much difference in terms of inherent scalability - the discussion is primarily about the shader processing part of the graphics pipe, which I don't *think* is a significant performance bottleneck today anyways.

                          The best analogy I can come up with is that there are a few different lines of people disappearing off into the distance, and the question is which line is going to move faster over the next few years... bearing in mind that it costs a year or so every time we change lines...

                          Comment


                          • #14
                            As for performance, there are a lot more low hanging fruit than an optimized compiler at this point (at least for the open source radeon driver). Things like surface tiling, pageflipping, fast clears, and Z related features (HiZ, etc.) will provide much larger performance gains than optimizing the instructions sent to the shader. An optimized shader compiler is like going from -O0 to -O1 or -02 in gcc.

                            Comment


                            • #15
                              Originally posted by agd5f View Post
                              As for performance, there are a lot more low hanging fruit than an optimized compiler at this point (at least for the open source radeon driver). Things like surface tiling, pageflipping, fast clears, and Z related features (HiZ, etc.) will provide much larger performance gains than optimizing the instructions sent to the shader. An optimized shader compiler is like going from -O0 to -O1 or -02 in gcc.
                              the analogy is almost correct, but the scope is not. going from -O0 to -O2 is not realy that visible, because the usual process does a lot of things.

                              it's more like going from standard fpu to an sse3 optimised path. since the shaders usualy run massively paralel on a lot of pixels, shaving off s few instructions in optimisation does have significant impact on the overall performance.

                              what I like in the proposal is the universal shader compiler that seems to be the future goal. this means it will look exactly like gcc (with all the benefits of switching architectures with compiler options and not having to recode the whole shader). of course with some HW limitations :-)

                              Comment

                              Working...
                              X