OpenGL Shader Cache Support For RadeonSI Is Making Progress

[xpris]

Well the on-disk shader cache was originally only hooked up for i965. Now it's getting hooked up for radeonsi. I was just wondering if anyone was going to bother with doing the same for r600.

I have the same question about disk cache for r600/

[asfalatus]

not so much, ... with shader cache min fps is much higher and no big fps drops when hundreds of shaders are created at the same time.

I think this IS much actually. In online FPS games serious FPS drop can cost you "life", cause loss, etc... Also for single player games, lags are disturbing and smooth gaming experience will provide better overall enjoyment especially if you don't have much time for playing.

So I really appreciate this initiative (as I appreciate every good will to do something for overall improvement in oss).

[smitty3268]

Any plans for r600 as well?

The patches I saw looked like they hooked into TGSI, so that would probably work on all Gallium drivers.

Of course, I imagine there will probably be some further integration to actually store the compiled binaries (i assume? or maybe not) so that would take some further more driver specific code, but it's probably pretty simple at that point.

[pal666]

for pts every run is the first, so with disk cache stable +2-3 fps

i.e. this is irrelevant for real usage

[pal666]

I was thinking it's in the part of Mesa shared between all drivers, and is transparent for them.

each driver has its own shader compier

[pal666]

In online FPS games serious FPS drop can cost you "life", cause loss, etc...

do warmup run and your problem is solved

[Kraut]

I was going to make a comment on how this shouldn't have much performance gain, if any at all. Then I came to learn that some games compile shaders in the middle of their game, which is a major problem in OpenGL. Why do people do this?

Two reasons.

Many do not want to touch multi threading with OpenGL because it can be messy. Even if for just shader compiling its realatively easy.
The compiling should happen on a seperate thread by the driver anyway. So it is more about the gl context that gets the signal back when the shader is "ready" to be used. With OpenGLs sync object design you would polute your main render thread if you use sync objects that could take so long. (They would block all subsequently sync object from signaling)
So you need a secondary shared context to initiate compiling and have its own sync objects. Otherwise you only could wait a guessed periode of time and hope that it was long enough to get that shader ready.

Second the driver does not have all the information when you "compile" it. It also needs other states like transparency enabled/disabled... etc, that are only available on first use.

Without stuff in the sahder cache the non oss drivers create a "fast and dirty" shader on first use to be ready as soon as possible and in the background create more optimized versions and then switch them out. Mesa does not use this technic.

[rycodge]

Is this coming to AMDGPU as well? Playing Rocket League with an RX480 can get pretty annoying when the menus hang the entire game for 3,5, even 10+ seconds at a time under the Unreal Engine.

[geearf]

Is this coming to AMDGPU as well? Playing Rocket League with an RX480 can get pretty annoying when the menus hang the entire game for 3,5, even 10+ seconds at a time under the Unreal Engine.

amdgpu is a kernel module, this is for mesa: Two orthogonal projects.

[smitty3268]

Is this coming to AMDGPU as well? Playing Rocket League with an RX480 can get pretty annoying when the menus hang the entire game for 3,5, even 10+ seconds at a time under the Unreal Engine.

In case geearf wasn't clear enough, your GPU is running on the radeonsi driver.