Quote:Original post by swiftcoder
As for protecting your shaders, the question is still "why?".

Protection of intellectual property. Obscuring something, so to delay the competition (even by a few months). The alternative are software patents. I prefer the former solution.

Quote:Original post by swiftcoder
Commercial companies don't bother protecting their shaders

Not yet. But as technology advances, almost all of the innovative IP in graphics programming will be in the shaders. Everything else is just supporting framework. This IP needs to be protected.

Quote:Original post by swiftcoder
- they even publish academic papers on all the shader techniques they develop -

It is getting increasingly common that such papers come attached to a SW patent, unfortunately. But that's the way things go if current graphics APIs essentially force you to open source your shader code, even though you possibly invested millions into the R&D behind those shaders. Publishing a paper about a technology is fine. But you don't want to supply your competition with a finished, ultra-optimized shader they can readily plug into their competing product (after the obligatory modify-it-a-little-to-avoid-copyright-violation). There is still a rather big distinction between theory and an actually working implementation. Publishing the former is good for innovation and evolution of graphics technology. But giving away for free the latter is just dumb.

I am a very big proponent of binary blobs. It is a major problem that OGL still doesn't have those. In fact, I would propose to go even further, by using encrypted shaders with GPU on-dye decryption. This will take out all these interceptors out there.

Quote:Original post by Yann L
In fact, I would propose to go even further, by using encrypted shaders with GPU on-dye decryption. This will take out all these interceptors out there.

Meh - how long till the decryption is cracked? DRM has never worked, and will never work as long as content is present on the end-user's computer/physical media.

Even if nobody breaks the decryption expressly for the purpose of reverse engineering shaders, eventually the WINE guys will need to provide decryption in software, or, you know, the MESA guys, the Apple Software renderer, etc.

Quote:Original post by snoutmate
That's false dichotomy, even if there was 100% effective way how to obscure the code, software patents would still bloom as they are powerfull, generalized and get law enforcement on your side.

You do realize that SW patents are very expensive, notoriously hard to enforce (and even unenforceable in many jurisdictions), and relatively easy to circumvent ? In fact, SW patents are far from being first choice for smaller companies. Many would rather not use them. However, if you don't have any other choice in order to protect your IP, then you just have to go that way. Certainly shader source is only a small part of this process, but it is getting more and more important, at least in the graphics sector.

Quote:
Like we haven't enough compatibility problems already

There is no reason why such a system would create compatibility problems. It's a question about vendors deciding on a standard. D3D has binary blobs (although no encryption). No compatibility issues.

Quote:
Meh - how long till the decryption is cracked? DRM has never worked, and will never work as long as content is present on the end-user's computer/physical media.

Not that easily. The decryption key pool is only present on the GPU dye, nowhere else. Each vendor registers a certificate with the GPU manufacturer, and receives a secret key to encrypt their shaders. The decryption is then done directly in the GPU core. Of course, this has some technical issues still unresolved (the shader would have to be precompiled in GPU-specific ASM before encryption, or the GPU would need to translate a standard intermediate ASM), but nothing impossible.

Quote:
Even if nobody breaks the decryption expressly for the purpose of reverse engineering shaders, eventually the WINE guys will need to provide decryption in software, or, you know, the MESA guys, the Apple Software renderer, etc.

Encryption would be entirely optional. 'Trusted' software with encryption would simply refuse to run on software renderers. It wouldn't even affect open source drivers, since it would be a hardware feature, without key-holding requirements for the driver.

But that's already going quite far. Utopia aside, I would already be very happy with simple precompiled shaders under OpenGL. Obfuscation for one, cutting down on compilation cost, etc.

Quote:Original post by Yann L
Not that easily. The decryption key pool is only present on the GPU dye, nowhere else. Each vendor registers a certificate with the GPU manufacturer, and receives a secret key to encrypt their shaders. The decryption is then done directly in the GPU core.

That almost sounds the methods used by the motion picture industry to "protect" their content. Not huge fan of this, to be honest.

Quote:Original post by Yann L
The decryption key pool is only present on the GPU dye, nowhere else. Each vendor registers a certificate with the GPU manufacturer, and receives a secret key to encrypt their shaders. The decryption is then done directly in the GPU core. Of course, this has some technical issues still unresolved (the shader would have to be precompiled in GPU-specific ASM before encryption, or the GPU would need to translate a standard intermediate ASM), but nothing impossible.

To be honest, this doesn't sound that different to the various DRM approaches attempted for DVD and Blueray (and the game console equivalents) - and we all know how well those worked out...

Quote:Encryption would be entirely optional. 'Trusted' software with encryption would simply refuse to run on software renderers. It wouldn't even affect open source drivers, since it would be a hardware feature, without key-holding requirements for the driver.

That sounds akin to those programs that reboot your computer when you try and attach a debugger - the intent may be to protect IP, but the end result is that you sell me a potentially broken program, which I have no way to debug or patch. And given the number of games that do ship broken (and I am not even counting DRM fiascos such as StarForce), I prefer that the manufacturers not have the option of *hiding* what is broken.

Quote:Original post by zedz
encryption aint gonna happen (within 10 years at least)

Agreed. One can dream, though... ;)

Binary blobs, however, are probably going to happen in the nearer future. And they have advantages beyond the obfuscation.

Quote:Original post by swiftcoder
To be honest, this doesn't sound that different to the various DRM approaches attempted for DVD and Blueray (and the game console equivalents) - and we all know how well those worked out...

There is a major difference here. Usually, DRM measures try to combat piracy. The system discussed above is only trying to combat reverse engineering. Another important difference is the key holding policy. Almost all DRM encoded media attacks were carried out on software players, which obviously had to hold the decryption keys. The system I propose would entirely function in HW. In order to extract the decryption keys, one would have to RE the GPU itself, which is insanely expensive and complicated (or you need an insider at the GPU manufacturer, or hack the central registry servers, etc). Certainly not uncrackable, but much better than sending plain text high level shader code to the driver, which is an invitation to copy'n'paste.

Quote:Original post by swiftcoder
That sounds akin to those programs that reboot your computer when you try and attach a debugger - the intent may be to protect IP, but the end result is that you sell me a potentially broken program, which I have no way to debug or patch. And given the number of games that do ship broken (and I am not even counting DRM fiascos such as StarForce), I prefer that the manufacturers not have the option of *hiding* what is broken.

Well, there's quite a difference from encrypting shader sources to something like Starforce. The proposed system does in no way restrict any of your rights, or even gets in your way. It doesn't install any drivers, root kits, or whatever other crap. It's just a way to send encrypted data to a piece of hardware. It's really simple, actually: your IDE compiles the shaders and encrypts them with the secret key you got with your certificate. You ship these binary shaders. The client takes the shader, sends your certificate GUID to the GPU (which internally selects the corresponding asymmetrical decryption key from it's ROM-based pool), and you send the binary shaders. The GPU decrypts them, possibly translates them, and caches them in VRAM. Done.

Quote:Original post by swiftcoder
but the end result is that you sell me a potentially broken program, which I have no way to debug or patch.

That's illegal anyway (at least in the US). And there's no reason such a system would 'break' in any other ways than those already well known - ie. simple software bugs. These happen with or without encryption. In fact, the encryption being transparent to the developer, it's very unlikely to be a point of failure.