Jump to content
  • Advertisement
Sign in to follow this  
Martin Perry

C++ Embeding shader source to code or use external file

Recommended Posts

I am shipping my app. I am facing the issue of shaders and their representation. Should I embed shaders to code directly or use external file and load them via "fopen"?

For the first approach - in binary

1) faster load time

2) shaders are "less easy to copy" (but only for beginners, the text is visible in hex binary)

Against the first approach - in binary

1) Larger binary - more memory needed

2) Shader is basically loaded only once at startup

 

--

For the second approach - external file

1) Easier shader update - just edit file, no rebuild needed

2) Smaller binary - less memory needed

3) Unified Virtual File System - load everything with one logic

Against the scond approach - external file

1) Slower load (especially on mobile devices, where files are in resource - unpacking them may be slow)

 

What are your thought? For me, I am more inclined to the second approach - extrenal file, but maybe I am missing something?

 

Edited by Martin Perry

Share this post


Link to post
Share on other sites
Advertisement

In the professional world shaders are one of many assets, and shaders are in their own files.

When built for shipping shaders get processed and bundled together with all the other assets, meaning they are small pieces of a very large file.

I thought it was unexpected that you mention slow load on mobile devices. Are you working on a mobile game?

Share this post


Link to post
Share on other sites

Not a mobile game, but a mobile/desktop OpenGL app. On older devices, when shaders are inside assets (on Android) unpack and load takes longer time.

Edited by Martin Perry

Share this post


Link to post
Share on other sites

I did both of what you described while I added "normal" shaders to a resource package, I also added them to code as plain text for some little build in feature (Debug-Drawing in GL).

I would recommend to ship them as external resource because packages could be maintained easier, you otherwise would need to rebuild your source when changing a shader and that may propably take longer compile times, also for bigger projects, your assembly file will be less in size as when you add the shader source to code.

Yes, GLSL takes a "relative" long time to compile because it is plain text so your devices graphics chip needs first to get all the text transferred before it is able to split, tokenize and parse it before it is able to translate the source into a GPU ready assembly program. You could not do anything very straight forward here because GLSL takes plain text source but you could cache shaders as binary output on disk and reuse it if possible. This is a lot faster because anything is already processed but the binary is platform and vendor dependent so you wont be able to ship that without a guarantee to work.

Access time is also something you should optimize. Make your assets a package and align that to the disk cache so you will reduce I/O-Buffer usage. In C++ you are also able to reserve page memory for your files (Memory Mapped Files) using CreateFileMapping on Windows and mmap on Linux/Unix (Android is Unix). This will enable your program to tell the OS to load a specific part of the file into a memory page (thats why you should align/padd your file) and increase access time by several milliseconds. You could also access two or more files (as long as they fit into the "chunks" you loaded) at once, even in an asynchronous multithreaded way. (This are the tricks that AAA games use on console)

Share this post


Link to post
Share on other sites

Presently I compile my shaders (HLSL) straight to a header file and include them in my projects. The additional compile time is negligible (in my case), with the entire project taking eight seconds to build an exe.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!