Announcement

Collapse
No announcement yet.

TGSI On-Disk Shader Cache For Mesa: Caching Comes To R600g/RadeonSI

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

  • TGSI On-Disk Shader Cache For Mesa: Caching Comes To R600g/RadeonSI

    Phoronix: GLSL IR & TGSI On-Disk Shader Cache For Mesa Patches

    Timothy Arceri of Collabora has sent out his latest patches to Mesa in regards to the ongoing work for shader caches. The 40 patches published over night do benefit RadeonSI and R600g...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    i wonder what is causing the stalls

    Comment


    • #3
      Is the shader cache for Intel available in mesa-git? If so, how may I enable it?

      Comment


      • #4
        Originally posted by boxie View Post
        i wonder what is causing the stalls
        If I understood it correctly, he was talking about his TGSI cache implementation, and the IR representation still needs to be compiled to hardware specific binaries. So you get rid of actually parsing the shader code and the "top layer" of the shader compilation (to IR), but the lower part still has to be done.
        I guess you can compare it to SPIRV->hardware specific binaries, the most low-level stuff needs compiling, but you get rid of most of the "text parsing".

        When the RadeonSI specific back-end is merged, the driver can load those binaries directly into memory (based on some checksum I assume, for security and stability), and the rest of the compilation overhead goes away (apart from having to read data from disk).

        Correct me if I'm wrong.

        Comment


        • #5
          Originally posted by mastercoms View Post
          Is the shader cache for Intel available in mesa-git? If so, how may I enable it?
          No, the patches just posted for review, they didn't land in main repo yet.

          Comment


          • #6
            Originally posted by Hi-Angel View Post
            No, the patches just posted for review, they didn't land in main repo yet.
            And most of them are still the same GLSL patches he's been posting for a while - as in, they still need someone appropriate to review them and it doesn't seem like anyone is really anxious to do so.

            Comment


            • #7
              Originally posted by smitty3268 View Post

              And most of them are still the same GLSL patches he's been posting for a while - as in, they still need someone appropriate to review them and it doesn't seem like anyone is really anxious to do so.
              It will land eventually, with or without reviews. FWIW, the big nine-patchset posted on ML in December nobody did even bother to review before pushing.

              Comment


              • #8
                Originally posted by Hi-Angel View Post
                It will land eventually, with or without reviews. FWIW, the big nine-patchset posted on ML in December nobody did even bother to review before pushing.
                It doesn't quite work like that, Axel maintains the Gallium Nine stuff and as the maintainer he can apply patches without review - mostly because there's no one else that cares from a developer perspective

                In the case of the shader cache Timothy isn't the i965 or TGSI maintainer and these are parts of the codebase that people care deeply about, so the patches will need to be reviewed and intel will need to put it through their internal testing too to make sure there are no regressions

                As this is a huge piece of work it'll take time - look how long it look for the Intel FP64 patches to land and Intel actually paid for that work to be done

                Comment


                • #9
                  Originally posted by FireBurn View Post
                  As this is a huge piece of work it'll take time - look how long it look for the Intel FP64 patches to land and Intel actually paid for that work to be done
                  Yeah, I'm actually curious if this really the best cooperative development model, because I also see how long it often takes to review big patch-sets, to the point that the developer, instead of moving on, have to constantly rebase the patch-set as it gets reviewed. It really slows everything down.

                  Comment


                  • #10
                    Originally posted by Hi-Angel View Post
                    Yeah, I'm actually curious if this really the best cooperative development model, because I also see how long it often takes to review big patch-sets, to the point that the developer, instead of moving on, have to constantly rebase the patch-set as it gets reviewed. It really slows everything down.
                    There have been other structural and implementation changes based on feedback and now the TGSI stuff, also some of the cleanup patches have already been upstreamed

                    Code:
                    V7:
                    - support for SSO added.
                    - rebased/reworked on top of my work to rework the gl structs, many previous
                     hack and work arounds removed. Fallback support is now much cleaner and
                     less hacky.
                    - Added fallback support for programs that use FragData bindings.
                    - Fixed off by 1 bug with attribute binding fallback as the
                     string_to_uint_map hash table offsets everything by 1 which we didn't allow
                     for.
                    - Lots of other clean-ups and improvements.
                    
                    V6:
                    - rewrote a bunch of the i965 shader cache functions to reduce
                     duplication.
                    - fixed some i965 bugs that only happen when falling back to a full
                     recompile when a cache object is deemed invalid (created with different
                     mesa version).
                    - added env var to more easily debug bugs as described in previous dot
                     point.
                    - Store all pointers as uint64_t.
                    
                    V5:
                    - added support for caching shaders with transform feedback
                     enabled by the in shader xfb qualifiers now ARB_enhanced_layouts
                     is enabled.
                    - rebased on last 3 months of Mesa changes
                    
                    V4:
                    - lots of reworking patches to remove code churn should be much nicer now
                    - fixed fallback when shader has been detached
                    - fixed a couple of bugs with UBOs
                    - no more printfs, debug info is behind an environment var
                    - various cleanups, tweaks and fixes
                    
                    V3:
                    - add support for geometry and tessellation stages
                    - cache clip planes
                    - reserve parameter storage before restoring list
                    - stop losing  buffer blocks on cache fallback
                    - lots of little fixes I cant remember
                    
                    V2:
                    - rebased on master
                    - add support for encoding doubles
                    - renamed skip_cache params to is_cache_fallback, and fix related bug
                     when  disabling shader cache for xfb.

                    Comment

                    Working...
                    X