Added - a cache of the binary representation of shaders
- Assaf Raman
- OGRE Team Member
- Posts: 3092
- Joined: Tue Apr 11, 2006 3:58 pm
- Location: TLV, Israel
- x 76
Added - a cache of the binary representation of shaders
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(...);
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(...);
Watch out for my OGRE related tweets here.
- spacegaier
- OGRE Team Member
- Posts: 4304
- Joined: Mon Feb 04, 2008 2:02 pm
- Location: Germany
- x 135
- Contact:
Re: Added - a cache of the binary representation of shaders
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.
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.
Ogre Admin [Admin, Dev, PR, Finance, Wiki, etc.] | BasicOgreFramework | AdvancedOgreFramework
Don't know what to do in your spare time? Help the Ogre wiki grow! Or squash a bug...
Don't know what to do in your spare time? Help the Ogre wiki grow! Or squash a bug...
- Wolfmanfx
- OGRE Team Member
- Posts: 1525
- Joined: Fri Feb 03, 2006 10:37 pm
- Location: Austria - Leoben
- x 99
- Contact:
Re: Added - a cache of the binary representation of shaders
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).
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).
- Assaf Raman
- OGRE Team Member
- Posts: 3092
- Joined: Tue Apr 11, 2006 3:58 pm
- Location: TLV, Israel
- x 76
Re: Added - a cache of the binary representation of shaders
@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.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? ....
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.
Watch out for my OGRE related tweets here.
- sparkprime
- Ogre Magi
- Posts: 1137
- Joined: Mon May 07, 2007 3:43 am
- Location: Ossining, New York
- x 13
- Contact:
Re: Added - a cache of the binary representation of shaders
How does this interact with CG?
- Assaf Raman
- OGRE Team Member
- Posts: 3092
- Joined: Tue Apr 11, 2006 3:58 pm
- Location: TLV, Israel
- x 76
Re: Added - a cache of the binary representation of shaders
It caches the CG compile results. Meaning it also saves the CG compile time.
Watch out for my OGRE related tweets here.
- sparkprime
- Ogre Magi
- Posts: 1137
- Joined: Mon May 07, 2007 3:43 am
- Location: Ossining, New York
- x 13
- Contact:
Re: Added - a cache of the binary representation of shaders
Sounds useful, I'll give it a try when I'm done implementing deferred shading
- syedhs
- Silver Sponsor
- Posts: 2703
- Joined: Mon Aug 29, 2005 3:24 pm
- Location: Kuala Lumpur, Malaysia
- x 51
Re: Added - a cache of the binary representation of shaders
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.
A willow deeply scarred, somebody's broken heart
And a washed-out dream
They follow the pattern of the wind, ya' see
Cause they got no place to be
That's why I'm starting with me
And a washed-out dream
They follow the pattern of the wind, ya' see
Cause they got no place to be
That's why I'm starting with me
- spacegaier
- OGRE Team Member
- Posts: 4304
- Joined: Mon Feb 04, 2008 2:02 pm
- Location: Germany
- x 135
- Contact:
Re: Added - a cache of the binary representation of shaders
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 .
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 .
Ogre Admin [Admin, Dev, PR, Finance, Wiki, etc.] | BasicOgreFramework | AdvancedOgreFramework
Don't know what to do in your spare time? Help the Ogre wiki grow! Or squash a bug...
Don't know what to do in your spare time? Help the Ogre wiki grow! Or squash a bug...
- sparkprime
- Ogre Magi
- Posts: 1137
- Joined: Mon May 07, 2007 3:43 am
- Location: Ossining, New York
- x 13
- Contact:
Re: Added - a cache of the binary representation of shaders
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.
- Assaf Raman
- OGRE Team Member
- Posts: 3092
- Joined: Tue Apr 11, 2006 3:58 pm
- Location: TLV, Israel
- x 76
Re: Added - a cache of the binary representation of shaders
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").
Watch out for my OGRE related tweets here.
- masterfalcon
- OGRE Team Member
- Posts: 4270
- Joined: Sun Feb 25, 2007 4:56 am
- Location: Bloomington, MN
- x 126
- Contact:
Re: Added - a cache of the binary representation of shaders
It's supported on Tegra 2, I'll try it out tonight.
- Nir Hasson
- OGRE Retired Team Member
- Posts: 363
- Joined: Wed Nov 05, 2008 4:40 pm
- Location: TLV - Israel
- x 2
- Contact:
Re: Added - a cache of the binary representation of shaders
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.
I'll take a look and see if and how to combine with the RTSS.
-
- Gnoblar
- Posts: 5
- Joined: Wed Oct 27, 2010 6:10 am
Re: Added - a cache of the binary representation of shaders
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...masterfalcon wrote:It's supported on Tegra 2, I'll try it out tonight.
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
- Assaf Raman
- OGRE Team Member
- Posts: 3092
- Joined: Tue Apr 11, 2006 3:58 pm
- Location: TLV, Israel
- x 76
Re: Added - a cache of the binary representation of shaders
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.
BTW: I just cleaned the GLES2 code - I fixed it so that shaders will not compile if they are in the cache.
Watch out for my OGRE related tweets here.
- masterfalcon
- OGRE Team Member
- Posts: 4270
- Joined: Sun Feb 25, 2007 4:56 am
- Location: Bloomington, MN
- x 126
- Contact:
Re: Added - a cache of the binary representation of shaders
Yeah, I was mistaken. It supports shader binaries, not program binaries.
- Assaf Raman
- OGRE Team Member
- Posts: 3092
- Joined: Tue Apr 11, 2006 3:58 pm
- Location: TLV, Israel
- x 76
Re: Added - a cache of the binary representation of shaders
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 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.
Watch out for my OGRE related tweets here.
- Assaf Raman
- OGRE Team Member
- Posts: 3092
- Joined: Tue Apr 11, 2006 3:58 pm
- Location: TLV, Israel
- x 76
Re: Added - a cache of the binary representation of shaders
I added code snippets to the sample browser - look for ENABLE_SHADERS_CACHE in the code.
Latest code in the trunk.
Latest code in the trunk.
Watch out for my OGRE related tweets here.
- Assaf Raman
- OGRE Team Member
- Posts: 3092
- Joined: Tue Apr 11, 2006 3:58 pm
- Location: TLV, Israel
- x 76
Re: Added - a cache of the binary representation of shaders
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.
Committed to the trunk.
Watch out for my OGRE related tweets here.
- Assaf Raman
- OGRE Team Member
- Posts: 3092
- Joined: Tue Apr 11, 2006 3:58 pm
- Location: TLV, Israel
- x 76
Re: Added - a cache of the binary representation of shaders
I tested this feature some more, I think we can say it is done.
Watch out for my OGRE related tweets here.
- Jabberwocky
- OGRE Moderator
- Posts: 2819
- Joined: Mon Mar 05, 2007 11:17 pm
- Location: Canada
- x 218
- Contact:
Re: Added - a cache of the binary representation of shaders
Nice work, Assaf. Much appreciated.
-
- Ogre Magi
- Posts: 1120
- Joined: Wed Nov 15, 2006 7:41 pm
- Location: Finland
- x 5
Re: Added - a cache of the binary representation of shaders
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.
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.
- Assaf Raman
- OGRE Team Member
- Posts: 3092
- Joined: Tue Apr 11, 2006 3:58 pm
- Location: TLV, Israel
- x 76
Re: Added - a cache of the binary representation of shaders
I don't think this is a top priority for me for now, but I do agree with you.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 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.
Watch out for my OGRE related tweets here.
- sparkprime
- Ogre Magi
- Posts: 1137
- Joined: Mon May 07, 2007 3:43 am
- Location: Ossining, New York
- x 13
- Contact:
Re: Added - a cache of the binary representation of shaders
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).
- spacegaier
- OGRE Team Member
- Posts: 4304
- Joined: Mon Feb 04, 2008 2:02 pm
- Location: Germany
- x 135
- Contact:
Re: Added - a cache of the binary representation of shaders
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?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).
Ogre Admin [Admin, Dev, PR, Finance, Wiki, etc.] | BasicOgreFramework | AdvancedOgreFramework
Don't know what to do in your spare time? Help the Ogre wiki grow! Or squash a bug...
Don't know what to do in your spare time? Help the Ogre wiki grow! Or squash a bug...