Announcement

Collapse
No announcement yet.

It's Getting Close Whether The OpenGL On-Disk Shader Cache Will Happen For Mesa 17.0

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

  • cj.wijtmans
    replied
    Originally posted by pal666 View Post
    that is because you are nonseniscal. not every time you play, but every time you run an app. i will happily wait minutes, then play hours with two times higher fps due to multithreaded driver. i don't care how much faster i can start game if it is nonplayable due to low fps.
    it wont impact your performance... first of all files are cached in memory by kernel. not sure if they keeping the memory cache is even worth it.

    Leave a comment:


  • pal666
    replied
    Originally posted by SaucyJack View Post
    That makes zero sense. The point of an on disk cache is to get the shader to memory faster without needing to spend minutes compiling every time you play.
    that is because you are nonseniscal. not every time you play, but every time you run an app. i will happily wait minutes, then play hours with two times higher fps due to multithreaded driver. i don't care how much faster i can start game if it is nonplayable due to low fps.

    Leave a comment:


  • SaucyJack
    replied
    Originally posted by pal666 View Post
    it will have zero benefit when you already have compiled shader in memory
    That makes zero sense. The point of an on disk cache is to get the shader to memory faster without needing to spend minutes compiling every time you play.

    Leave a comment:


  • pal666
    replied
    Originally posted by SaucyJack View Post
    I strongly suspect an on disk shader cache would take far less time to implement and have a large immediate benefit.
    it will have zero benefit when you already have compiled shader in memory

    Leave a comment:


  • pal666
    replied
    Originally posted by dungeon View Post
    They are both so called performance enhancement features
    on-disk cache is only enhancement for first shader loading on non-first run of executable. for all other shader loadings it brings no performance enhancements. it could save you some time per application run, multithreaded driver could make unplayable game playable

    Leave a comment:


  • dungeon
    replied
    Originally posted by pal666 View Post
    number one is multithreaded driver.
    Both are number one as both are needed according to what blob drivers do for years Of course both are not GL specification requirement same as performance is not any requirement too

    They are both so called performance enhancement features, so we are free to even invent something else there... but i am not sure what is that something better
    Last edited by dungeon; 12 January 2017, 05:47 AM.

    Leave a comment:


  • geearf
    replied
    Originally posted by shmerl View Post
    Even better, why can't games take care of caching itself?
    They can.
    I am curious about the pros and cons of drivers vs applications doing that work.


    Aside from that I got curious, we already got in-memory shader cache, and isn't it the first major step to in disk cache? It seems like serializing the memory to disk with a few ids for the driver and game should be fairly easy, why is that not the case?

    Originally posted by smitty3268 View Post

    They can, except not on Mesa because it will just report the binaries as invalidated each time.

    That was the way Mesa devs were able to quickly add support for GL 4.1 (and GL_ARB_get_program_binary) without actually doing the work of figuring out how to cache compiled shaders. The new work to automatically cache shaders is fairly trivial compared to the underlying work here enabling the loading and storing of shaders at all, whether by an automatic cache or by manual GL calls from the game.
    well maybe that's what I was missing

    Leave a comment:


  • smitty3268
    replied
    Originally posted by shmerl View Post

    Some games do that. Even better, why can't games take care of caching itself? They can cache compiled shaders for given GPU, and skip compilation, if next time the same GPU is used.
    They can, except not on Mesa because it will just report the binaries as invalidated each time.

    That was the way Mesa devs were able to quickly add support for GL 4.1 (and GL_ARB_get_program_binary) without actually doing the work of figuring out how to cache compiled shaders. The new work to automatically cache shaders is fairly trivial compared to the underlying work here enabling the loading and storing of shaders at all, whether by an automatic cache or by manual GL calls from the game.

    Leave a comment:


  • shmerl
    replied
    Originally posted by geearf View Post

    Technically you could store the uncompiled shaders and compile them on loading instead of in-game, like Cemu does.
    It wouldn't shorten the loading time, quite the opposite, but it removes stuttering in-game.
    Some games do that. Even better, why can't games take care of caching itself? They can cache compiled shaders for given GPU, and skip compilation, if next time the same GPU is used.

    Leave a comment:


  • geearf
    replied
    Originally posted by shmerl View Post

    This doesn't make sense. The whole point of cache is to store the compiled result. Each GPU has its own architecture, so compiled shaders are specific to the GPU. They are not compatible with each other. That's the whole point of shaders being in the intermediary format, and at the same time running on different hardware with different machine instructions. They are compiled for each GPU! But you can cache them if you are on the same hardware. So your idea isn't feasible.
    Technically you could store the uncompiled shaders and compile them on loading instead of in-game, like Cemu does.
    It wouldn't shorten the loading time, quite the opposite, but it removes stuttering in-game.

    Leave a comment:

Working...
X