Announcement

Collapse
No announcement yet.

LunarG Proposes A Shader And Kernel Compiler Stack

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

  • #16
    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.
    So how many of those have been implemented so far?
    I think tiling is coming for r600g (arlied is working on it), Z is not yet implemented in any ways.
    Pageflipping might be in the kernel already.
    I have no idea about fast clears.

    Are there plans to do these in the foreseeable future?

    By the way, this new compiler won't happen in the near future, so by the time it is done radeon might very well be at the point where this will be the biggest bottleneck...

    I also think that there will be an intermediate solution here. Just like old ati and nvidia chips are not suitable for gallium drivers I think some cards will have this unified compilers while older ones will have to live with what they already have.

    Just my not-very-insightful opinion...

    Comment


    • #17
      GPGPU

      After reading the Mesa-dev thread, it seems this is also targeted for general purpose computing on shaders and making it "easy". Getting mindshare off the GPUs to coprocessors. I'd very much like to see GNU Radio FIR filter blocks implemented on the GPU

      Comment


      • #18
        OK so this is a two step thing. First step is just planting it there in the stack and leaving driver devs to their business. No problem, right?

        Later on with newer GPU's, driver devs can target the Glass IR from the get go instead. Still no problem, right?

        Comment


        • #19
          Originally posted by HokTar View Post
          So how many of those have been implemented so far?
          I think tiling is coming for r600g (arlied is working on it), Z is not yet implemented in any ways.
          Pageflipping might be in the kernel already.
          I have no idea about fast clears.
          r300g already supports these features on r3xx-r5xx hardware, so support just needs to be added to r600g. Most of these new features will happen in the gallium driver as it is much easier to add these features there.

          Initial drm tiling support was added in 2.6.36 and to mesa and the ddx, but that just enabled 1D tiling for render targets. Textures are still not tiled and you get larger performance gains with 2D tiling. Dave is working on tiling support now in r600g. Jerome and I have written a few patches to implement pageflipping support, but nothing is upstream yet. Fast clears and HiZ, etc., are not implemented yet.

          Comment


          • #20
            But there is a problem in this sweet transition; namely state trackers... =x

            Or do state trackers simply cut the layer between device A and B?

            Comment


            • #21
              I believe state trackers would need to be modified to emit "upper LLVM IR" rather than TGSI, in the same way that drivers would need to be modified to consume "lower LLVM IR" rather than TGSI. I imagine a common TGSI-to-upper-LLVM-IR conversion routine shared across state trackers could be used during initial development and testing

              Comment

              Working...
              X