Ogre Forums

I added a new option to cache the binary representation of shaders (microcode).
The code is committed to the trunk.
You can cache shaders in d3d9, d3d11 and in opengl if you have the 4.1 driver (I don't - my laptop doesn't have 4.1 driver ).
I didn't add this option to gles 2.0 - but it can be added by using GL_OES_get_program_binary, I guess there it can help the most - because it runs on platforms that compiles more slowly. I don't have the development environment to write the code for it.

The idea is to save a cache before you release the product or at the first run on the client computer - and from then on use the cache to load shaders without compiling them.

If you want to save shaders to the cache:
* Before the resource load call GpuProgramManager::getSingleton().setSaveMicrocodesToCache(true);
* When you want to save the cache to a file call - GpuProgramManager::getSingleton().saveMicrocodeCache(...);

When you want to use the cache:
* Before the resource load call - GpuProgramManager::getSingleton().loadMicrocodeCache(...);

First of all: Sounds great!

I guess that you did not just develop that out of interest, but because you see a need for it. So do you have any stats / rough values how much startup time that saves compared to compiling? I personally would have never thought that the shader would be a bottleneck, but instead I would have first thought of loading the textures and meshes. But again I never used that many and complex shaders in my projects. So I am quite curios to get a rough estimation.

Thats great!
Its nice that you streamlined this feature i think it were only available on d3d9 RS system before.(to save the microcode)
Would it make sense to relax the caching strategy from RTSS (i mean last year Nir calculated a hash over the generated shader source and checked if the hash + ".ext" already generated in the cache folder). So RTSS could generate(compile) the micro code save it to disk and make the simple cache checking (just hash + ".ext" which would be the name of the compiled shader).

spacegaier wrote:...I guess that you did not just develop that out of interest, but because you see a need for it. So do you have any stats / rough values how much startup time that saves compared to compiling? ....

@spacegaier: Well - I did develop that out of interest. I am doing all sort of research development just for fun, I didn't know if this will help or not, but if a feature to do this was just added to gl 4.1, I guess they didn't do that for nothing.
No clue about startup time but I didn't see any noticeable improvement in the sample browsers loading time, but I didn't really check it.
If I will time it - I will post here.

@Wolfmanfx: Worth a try.

How does this interact with CG?

It caches the CG compile results. Meaning it also saves the CG compile time.

Sounds useful, I'll give it a try when I'm done implementing deferred shading

I am sure this will be useful - some complicated shader can take more than a minute to compile although they are not mine. I read about it from Sinbad's blog and you can also google for it.

Found it: http://www.stevestreeting.com/2008/03/2 ... -the-pain/

So this actually seems to be an issue with complex shader. Good to know and I will remeber that, once I am able to handle that level of shader complexity .

I switched from HLSL to CG to bring down compile times -- HLSL was taking about 100x longer than CG for the same targets and approximately the same source language. However now the shaders are complex enough and there are enough permutations that it takes about 15-30 seconds on startup time so yes, cacheing them would be useful.

I just added GLES2 support. Couldn't test it - the required functions don't exist on any of the windows emulations (AMD, PowerVR and "Mali Developer").

It's supported on Tegra 2, I'll try it out tonight.

This is great feature, especially on low end machines or for dedicated platforms (Consoles etc.)
I'll take a look and see if and how to combine with the RTSS.

masterfalcon wrote:It's supported on Tegra 2, I'll try it out tonight.

It is? I just dumped the extension list from the driver that's in the L4T package off the NVIDIA site, and I'm not seeing anything about GL_OES_get_program_binary...

GL_NV_platform_binary GL_OES_rgb8_rgba8 GL_OES_fbo_render_mipmap GL_NV_depth_nonlinear GL_NV_draw_path GL_OES_EGL_image GL_OES_vertex_half_float GL_NV_framebuffer_vertex_attrib_array GL_NV_coverage_sample GL_OES_mapbuffer GL_ARB_draw_buffers GL_EXT_Cg_shader GL_EXT_packed_float GL_OES_texture_half_float GL_OES_texture_float GL_EXT_texture_array GL_OES_compressed_ETC1_RGB8_texture GL_EXT_texture_compression_latc GL_EXT_texture_compression_dxt1 GL_EXT_texture_compression_s3tc GL_EXT_texture_filter_anisotropic GL_NV_get_tex_image GL_NV_read_buffer GL_NV_shader_framebuffer_fetch GL_NV_fbo_color_attachments GL_EXT_bgra GL_EXT_texture_format_BGRA8888 GL_NV_unpack_subimage

Well, seems that some Android Devices has it.
BTW: I just cleaned the GLES2 code - I fixed it so that shaders will not compile if they are in the cache.

Yeah, I was mistaken. It supports shader binaries, not program binaries.

I found a computer with GL 3.3 - meaning it has GL_ARB_get_program_binary.
I tested and fixed some issues and now I can say for sure - this is working also for GL.
GLES2 and GL are very similar - so even if I can't test on GLES2 - I think that if I have any issues with GLES2 - they are very small.
All the code is committed to the trunk.

I added code snippets to the sample browser - look for ENABLE_SHADERS_CACHE in the code.
Latest code in the trunk.

I changed the code so the microcode cache memory is allocated by the GpuProgramManager - else there are crashes on release if you dynamically link OGRE.
Committed to the trunk.

I tested this feature some more, I think we can say it is done.

Nice work, Assaf. Much appreciated.

Mister Assaf Raman, thank you for your work. This has been a feature I thought OGRE should have.



Another thing would be to do the same to OGRE scripts. A finished product should in my opinion not be parsing scripts but reading binary files optimised for speed.


Thanks for your work! You must have put a lot of time into OGRE and it's very much appreciated.

reptor wrote:...
Another thing would be to do the same to OGRE scripts. A finished product should in my opinion not be parsing scripts but reading binary files optimised for speed.
...

I don't think this is a top priority for me for now, but I do agree with you.
I was thinking more in the lines of a general serialization engine, one that has different outputs - xml, binary and such.
Possibly Boost Serialization for ogre classes.

Reading text files is fine, even AAA games do it and have done for years. However I did develop my own material system since OGRE's was taking minutes when it should have taken seconds (early 2009).

sparkprime wrote:Reading text files is fine, even AAA games do it and have done for years. However I did develop my own material system since OGRE's was taking minutes when it should have taken seconds (early 2009).

Any more insight on this special material system of yours? Made me quite curious what your idea was in order to make it faster! And any chance to merge some changes back into Ogre core or is this not possible?