Announcement

Collapse
No announcement yet.

Intel's Mesa On-Disk Shader Cache Maturing, Radeon Devs Not Yet Convinced

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

  • #11
    Originally posted by duby229 View Post

    Thanks for explaining it better. There are a few games I played where I felt something that could be called stuttering, but I had assumed (perhaps wrongly) that it was the game engine bottlenecking on loading in-game content from disk. It's usually evident by the disk LED thrashing at the moment of the stutter. I'm not convinced a shader cache can help those micro-freezes.
    You are correct, Shader compilation is just one of possible bottlenecks causing "stuttering" or slow game/map/level loads in games, it's by no means some kind of magical bullet that will make problems go away. If you have enough ram you might be able to solve "slow hdd" problem by manually preloading game files into OS page cache, either by some simple preload tools or good old quick and dirty hack (find /path/to/game/folder -type f -exec cat '{}' &>/dev/null \; ). This literally reads every file in game directory and throws read content into dev null while feeding OS page cache (so subsequent reads won't be performed from hdd but from unused memory). As the RAM fills up page cache residing in unused memory gets sacrificed however.

    Comment


    • #12
      Originally posted by tpruzina View Post
      As the RAM fills up page cache residing in unused memory gets sacrificed however.
      you could use folder2ram https://github.com/bobafetthotmail/folder2ram script to turn the game folder to a ramdisk (tmpfs) instead (does some trickery with bind mounts so you can sync back the modified data from the tmpfs to the storage easily and at any time).

      Of course you would need the RAM to fit that, so you will probably have to choose only the folders with the most important parts of the game if it is an AAA that takes up 50 GB of disk space and you don't have a server with 256GB of registered ram under your desk.

      Comment


      • #13
        I've only just got a card (RX 480) where you would notice this sort of thing, as opposed to the overall crappy performance drowning it out, so this is a new issue for me. I have The Talos Principle set to Ultra and it's smooth after looking around a bit but you always get that initial stutter, which sours the experience. I wouldn't mind a few seconds extra load time if it meant it would be smooth afterwards.

        Comment


        • #14
          Originally posted by starshipeleven View Post
          you could use folder2ram https://github.com/bobafetthotmail/folder2ram script to turn the game folder to a ramdisk (tmpfs) instead (does some trickery with bind mounts so you can sync back the modified data from the tmpfs to the storage easily and at any time).

          Of course you would need the RAM to fit that, so you will probably have to choose only the folders with the most important parts of the game if it is an AAA that takes up 50 GB of disk space and you don't have a server with 256GB of registered ram under your desk.
          Yeah, I created a runlevel for openrc that does something similar. I can start the runlevel when I want to play and stop it when I'm done. (With individual scripts for each game I play.)
          Last edited by duby229; 13 July 2016, 09:59 AM.

          Comment


          • #15
            Originally posted by duby229 View Post
            I'm still leery about touching storage. If it takes longer to compile a shader than it does to read it from disk, then it can help.. But I'm not convinced that'll happen every time. I think it needs to be extremely concious of overall latency and be very selective.
            only case where it would definitely benefit is if they would be read at start from one big file if gpu is the same at next time you run the game which would reduce every concurrent game start.

            while game is running on-disk simply makes no sense due to the fact that memory limit really is no problem nowadays where difference between having them cached on disk or in memory is astronomical

            Comment


            • #16
              Originally posted by schmidtbag View Post
              I personally see no harm in this, but, it should be optional. For some devices, particularly ones with SoCs, some users might not have storage they're willing to spare, or might not have storage that's fast enough to benefit from this. Furthermore, how does the cleanup work? If the cache is permanent, that data will add up quickly over time, but if it's too short-lived then it doesn't really benefit users that much.
              Well shader compilation is CPU operation, so this remove need that CPU does it every time - so this approach is to do it once then read from it Both slow hdd or ssd benefit from this, so regardless of that.

              Personally, I'm much more interested in Marek's approach of making it multi-threading.
              That would improve things too and will be slower then on disk cache, but faster on first time of course....

              So fastest and the best would be - to have both of those playing together
              Last edited by dungeon; 13 July 2016, 10:00 AM.

              Comment


              • #17
                Originally posted by starshipeleven View Post
                you could use folder2ram https://github.com/bobafetthotmail/folder2ram script to turn the game folder to a ramdisk (tmpfs) instead (does some trickery with bind mounts so you can sync back the modified data from the tmpfs to the storage easily and at any time).
                Of course you would need the RAM to fit that, so you will probably have to choose only the folders with the most important parts of the game if it is an AAA that takes up 50 GB of disk space and you don't have a server with 256GB of registered ram under your desk.
                I wrote a simple program/library years ago that hooks open syscall and logs it into file so it can be "replayed" via readahead syscall on execution, feel free to try it:
                Simple preload tool. Contribute to tpruzina/spreload development by creating an account on GitHub.


                Personally don't play any 50GB games though, I have trouble filling up 16GiB of memory that I've got in my current box (except when running VM with windows+visual studio+IDA).

                Comment


                • #18
                  Originally posted by justmy2cents View Post

                  only case where it would definitely benefit is if they would be read at start from one big file if gpu is the same at next time you run the game which would reduce every concurrent game start.

                  while game is running on-disk simply makes no sense due to the fact that memory limit really is no problem nowadays where difference between having them cached on disk or in memory is astronomical
                  I think at least in theory, the linux file cache should handle that automatically? Once a file is read it should be cached to ram on the fly right?

                  Comment


                  • #19
                    Originally posted by duby229 View Post
                    I'm still leery about touching storage.
                    there is secret patented technology called page cache

                    Comment


                    • #20
                      Originally posted by dungeon View Post
                      Try Borderlans 2 if you have it - i think that is worse example, that stutter and has CPU bottleneck.
                      it has no stutter, it's just cpu-bound

                      Comment

                      Working...
                      X