Dumping ObjectCode from Shaders??

[DieselGL]

Hello peoples!

Maybe this is a dump question, but is there a way to dumb the compiled glsl-object-code?? I could not find anything about this in the net or in this forums.
Wouldn't be that an increase of speed?? I mean everytime I load a glsl-pair, I have to check everything. Is there no smarter way? The next reason for this technique is that I can keep my shader files outside an archive and nobody can read it. Well, people still could steal it, but its some way of codehiding.
But my main concerne is speed.

Thanks in advance.
rya.

[V-man]

No, but his was discussed in the extension spec and on these forums. It would almost certainly increase speed. The object code would have to be a generic binary format for the program which the driver would then optimize.

If you are worried about people stealing your code, then encrypt it (obfuscate).

[kingjosh]

DieselGL Said: But my main concerne is speed.
V-man Said: It would almost certainly increase speed. The object code would have to be a generic binary format for the program which the driver would then optimize.

The driver can optimize the GLSL code, as it is sent straight to the driver. If your concern is speed, I believe as GLSL compilers improve you'll see an increase in the effectiveness of optimizations. It would make no sense to create another low level language that is standardized (and thus likely not 1 to 1 with the hardware itself).

[ZbuffeR]

The idea of storing/reusing precompiled GLSL code seem useful to me : with a lot a shaders to compile, application startup is slow. And whatever optimizations are done in drivers, it will be to enhance execution time, not really compile time.

Once compiled, one can imagine a glGetCompiledGLSL(&pointer) to retrieve a "black box" hardware-dependent compiled shader.

Then you can store it on disk, and when this shader is needed again just glSetCompiledGLSL(&pointer). This time the driver has just to make a quick check to be sure that this machine code is valid for the hardware, and upload it.

Of course this will not help obfuscate your shader (maybe if you precompile for each target hardware .. ok ok forget it).

[PkK]

> Once compiled, one can imagine a
> glGetCompiledGLSL(&pointer) to retrieve a "black
> box" hardware-dependent compiled shader.

This is what GL_OES_shader binary does.
The extension is not in the extension registry but in the appendix of the OpenGL ES 2.0 specification.

[ZbuffeR]

OES shader binary

Overview This extension adds the ability to load pre-compiled shader binaries instead of using the shader compiler to compile shader sources. This allows OpenGL ES 2.0 implementations to not require a shader compiler which can be a significant savings in the memory footprint required on a handheld device.

...snip...

the link stage in the OpenGL ES implementation and can be quite expensive in terms of number of CPU cycles required and the additional memory footprint required by the OpenGL ES implementation

Issues

1.

Should a GetShaderBinary call be supported? No.

RESOLUTION:

The following reasons were given for not supporting GetShaderBinary: - a lot of complexity in managing associated state with a read-back binary - use case for get binary not that strong - decided to get more experience with ES 2.0 before implementing get binary.

too bad, it was almost there ...
TkK, thanks for the info anyway.

[PkK]

Well even if that GetShaderBinary would be supported it wouldn't be of much use for your purpose: OpenGL ES 2 require only OES_shader_source or OES_shader_binary to be supported, so with OES_shader_binary only you can't supply a shader source. But the existence of OES_shader_binary means that there will be offline compilers. So you could have precompiled shaders for the most common hardware platforms.

[V-man]

Originally posted by ZbuffeR:
Once compiled, one can imagine a glGetCompiledGLSL(&pointer) to retrieve a "black box" hardware-dependent compiled shader.

You would need to identify the hw everytime your program runs. Most IHVs are turned off by this whole issue.

It would be better to have a generic binary like the one supported by Direct3D. vsa.exe and psa.exe are command line compilers just for this purpose.

I would prefer the glGetCompiledGLSL idea as that would give the most benifit.

[Jan]

No, you wouldn't need to detect the hardware everytime.

I would do it this way: Ship the app without precompiled shaders. When the app runs, send the shader to the hw, get the compiled binary, store it on disk. The next time you run the app, check, wether the binary is available, already, and send that instead. If the hw complains, just send the original shader.

This way you get
1) Faster load times, after a shader has been used once.
2) Binaries that fit the hw, even if the driver changes and the binary has to change, too, you get an error, you send the original shader and get the up-to-date binary, which you store on disk.
3) Complete hw/file-format/whatever-independency, because you only GET the stuff from the driver, you are not supposed to be able to work with that stuff yourself.

I don't see any reason, why that would be so hard to implement. Every driver has its own internal format it translates the shader to, it's the simple idea to give this string back and to accept strings in this format.

And i don't see a reason why we would need a specific generic byte-code, as is the intention of the previously mentioned extension. Sure, every hw is different, so forcing drivers to accept a unified format, which might be far from hw-friendly, is really a stupid idea. Also, you can't put in "optimizations" in a generic format, because those optimizations might be highly hw-dependent.

So, by simply returning the parsed/optimized code, which is done for ONE card (not ONE vendor, but it can even be card-dependent), an application can be able to speed up shader-compilation drastically, with only a few lines of code, and it should be completely fool-proof.

Jan.

[ZbuffeR]

Thanks Jan for making it crystal clear, it is exactly what I meant.