Valve's Open-Source Driver Developers Revise Their RADV "Secure Compile" Feature

[phoronix]

Phoronix: Valve's Open-Source Driver Developers Revise Their RADV "Secure Compile" Feature

Last month Valve's open-source Linux GPU driver developers introduced a "secure compile" feature to the Radeon Vulkan driver to do just as the name implies and making use of SECCOMP filters for enforcing the security aspect. They have now revised this implementation in order to provide faster shader compile times...

http://www.phoronix.com/scan.php?page=news_item&px=RADV-Faster-Secure-Compile

[ssokolow]

What does it say about the world that, when I first read that headline, I was worried that "RADV Secure Compile" might somehow be reliated to the kind of "security" that ensures that decoding BluRay and re-encoding to HDCP happens in the Intel Management Engine or the AMD PSP where you and your OS can't see the decrypted frames?

[Guest]

What does it say about the world that, when I first read that headline, I was worried that "RADV Secure Compile" might somehow be reliated to the kind of "security" that ensures that decoding BluRay and re-encoding to HDCP happens in the Intel Management Engine or the AMD PSP where you and your OS can't see the decrypted frames?

That was my first thought too, when I read the previous article.

[kpedersen]

I still think the idea of providing shaders as binary blobs is a bit sad. Does it really take *that* long to compile them? Especially since they should be loaded / compiled as needed rather than all on the first load. Put it this way, OpenGL GLSL shader compilation has never really been a big reason for increased load times.

Whilst I am sure that the game making industry likes the idea (because they are a little bit immature when it comes to sharing toys), it is a bit silly. Also do these companies really feel that *all* of their shaders are absolutely top secret proprietary information that absolutely no other developer could put together in an evening?

I am also in two minds which is the most future proof. Obviously GLSL script can become deprecated (i.e key words like uniforms, varying, gl_FragColor, etc..) but so can certain constructs in bytecode and certainly what that bytecode calls into (just try to run a Java 1.x bytecode on a modern VM and you'll see what I mean). At least with script it can be munged / transpiled to keep up-to-date. I think it will be harder for bytecode. Compatibility interpreters will be needed instead.

[aufkrawall]

I still think the idea of providing shaders as binary blobs is a bit sad. Does it really take *that* long to compile them? Especially since they should be loaded / compiled as needed rather than all on the first load.

With API wrappers, this means that there is stutter. This is not acceptable.

[kpedersen]

Yeah I can see that API wrappers do not usually have information about or concept of "load time" so could be an issue.
Though surely loading a binary blob from disk will also provide stutter?
Either that or many API wrappers still need to provide programmable pipelines meaning that the shader needs to be generated / transpiled dynamically anyway so a binary blob is no longer useful anyway?

Could it not be loaded and compiled on a separate thread (this is after all one of the biggest bonuses of Vulkan) and then used once fully constructed?
Minus the "real" thread, this is the approach we do for WebGL / Emscripten because web browsers cannot block whilst loading the file. Yes we have a few frames where the object can be drawn with the "basic" shader rather than the final one.

[aufkrawall]

Though surely loading a binary blob from disk will also provide stutter?

It really helps to eliminate stutter entirely in many cases, also Windows drivers do it since many games don't manage it properly even with D3D11. Well, AMD unfortunately has no on-disk cache for the compiler of their proprietary Vulkan driver, while Nvidia does.

[zanny]

Does it really take *that* long to compile them?

Its the same argument for compiled vs interpreted CPU code, or at least LLVM Intermediary or JVM Bytecode vs Javascript files.

Getting shaders as close to their final form as possible is valuable, and even if you can see shaders in their original glsl textual form under OpenGL doesn't mean you can do what you want with them - they are still the IP of the creator. The only marginal utility in that was making your own changes to... GLSL shaders? It seems pretty niche.

[ssokolow]

Its the same argument for compiled vs interpreted CPU code, or at least LLVM Intermediary or JVM Bytecode vs Javascript files.

Getting shaders as close to their final form as possible is valuable, and even if you can see shaders in their original glsl textual form under OpenGL doesn't mean you can do what you want with them - they are still the IP of the creator. The only marginal utility in that was making your own changes to... GLSL shaders? It seems pretty niche.

Devil's Advocate: "Could be useful for modders"