I'm thinking about releasing a bunch of GPGPU functions as a framework using OpenGL ES 2.0 for iOS devices.
When capturing an OpenGL ES frame in XCode, I can see the code of the shaders being used. Is there a way to avoid this from happening? I've tried deleting and detaching the shaders with glDeleteShader and glDetachShader after linking the OpenGL ES program, but the code is still captured.
I'm not looking for a bullet proof option (which probably doesn't exist), just something that makes getting to the code a bit more difficult than just pressing a button.
Thank you.
The debugger has to capture input from calls to glShaderSource, the actual shader source is never stored in VRAM after compilation. I cannot think of any way to overcome this problem directly. Calling glShaderSourceis required because OpenGL ES does not support precompiled shader binaries.
I would recommend obfuscating the original shader code, perhaps using compile time macros, or even a script to scramble variable names etc (be carful of attribs and uniforms as they affect linkage to app code).
Here is a tool used for obfuscation/minimization of shader code. I believe it is built for WebGL so it may not work perfectly. http://glslunit.appspot.com/compiler.html
Related
I have not found any definitive answers to this, so decided to ask here. Is there really no way to save and load compiled webgl shaders? It seems a waste to compile the shaders every time someone loads the page, when all you would have to do is compile the shaders once, save it to a file, then load the compiled shader object, as you would HLSL (I know it's not GLSL, but i'm still a little new to OpenGL).
So, if possible, how can i save and load a compiled shader in webgl?
There really is no way, and imho thats a good thing. It would pose a security issue(feeding arbitrary bytecode to the GPU) in addition to that when drivers are updated the precompiled shaders are potentially missing new optimizations or just break.
when all you would have to do is compile the shaders once, save it to a file, then load the compiled shader object, as you would HLSL
OpenGL(and its derivatives) does not support loading pre-compiled shaders the same way DirectX does:
Program binary formats are not intended to be transmitted. It is not reasonable to expect different hardware vendors to accept the same binary formats. It is not reasonable to expect different hardware from the same vendor to accept the same binary formats.
https://www.opengl.org/wiki/Shader_Compilation#Binary_limitations
There seems to be no intermediate format like SPIR-V in OpenGL so you would need to compile the shaders on the target platform introducing a whole lot of additional concerns with users changing their graphics cards / employing a hybrid graphics solution, storage limitations on the client(5 MB using localstorage) and the possibility of abusing it to fingerprint the hardware.
Topic is pretty much the question. I have OpenGL-based game with a lot of shaders. What I wanna do is convert it to Metal, so it can gain some perfomance from conversion, but I also want to have old devices support. Is it possible?
I dont know for sure if that works but
You could check which iOS device is used
Detect the specific iPhone/iPod touch model
And than execute the metal Code or the OpenGL es Code
Have a look at MetalGL. It is an implementation of OpenGL ES that runs on Metal. You write your app in OpenGL ES, and if Metal is available on the device, MetalGL will run the OpenGL ES code on Metal automatically, including shader conversion. If Metal is not available on the device, MetalGL will run the native OpenGL ES engine.
Depending on the nature of your app bottlenecks, your app may be more performant when running on Metal, and MetalGL can help you understand if and how your app will benefit from Metal, without you having to rewrite your app in Metal.
Full disclosure...I work on the MetalGL development team.
Yes it is possible. I do it in a released game.
To test for Metal support on a device call:
// this returns NULL if the device does not support Metal
Class metalAvailable = NSClassFromString(#"CAMetalLayer");
Then take separate paths in your code to either initialise your Metal renderer or your OpenGL ES renderer. It's all pretty easy.
I have been trying to see what is happening in my shader at run time. But I have been unable to find a way to log the contents of shader variables to the console. I know the shader runs on the GPU so logging is bound to be more complicated. If Possible? How do I log from a shader?
It's not possible to log from a shader. If trying to debug, you just have to use the color output to tell what's going on.
Take a look at the glm library. You can use to write your shader code in C++, and use your tools of choice to debug it. It doesn't cover everything in OpenGL, but it is very easy to use and will give you a very good idea of what's going on in your shader.
I am developing a large game that streams in level data (including shaders) as you move through the game world. I do not want to have hitches in my frame rate as shaders are compiled/linked or on the first time they are used.
I have my shader compilation and linking working on a separate thread with its own open-gl context. But I have not been able to get the prewarming of the shaders to work on the separate thread (so that there is no performance hit when the shader is first used).
Prewarming is really not mentioned anywhere in the iOS or OpenGL docs. It is however mentioned in the OpenGL ES Analyzer (one of the instruments available when profiling from xcode). In this tool I get a "Shader Compiled Outside of Prewarming Phase" warning each time something is rendered with a shader that has not been used to render something before. The "Extended detail" says this:
"OpenGL ES Analyzer detected a shader compilation that is not part of an initial prewarming phase. Shader compilation can be a time consuming operation. To avoid them, prewarm all shaders used for rendering. To do this, make a prewarming passwhen your application launches and execute a drawing call with each of the shader programs to be used, using any gl state settings the shader program will be used in conjunction with. States such as blending, color mask, logic ops, multisamping, texture formats, and point primitive state can all affect shader compilation."
The term "compilation" is a little confusing here. The vertex and fragment shaders have already been compiled and the program has been linked. But the first time something is rendered with a given OpenGL state it does some more work on the shader to optimize it for that state I guess.
I have code to pre-warm the shaders by rendering a zero sized triangle before it's first use.
If I compile, link and pre-warm the shaders on the main thread with the same Open GL context as the normal rendering then it works. However if I do it on the background thread with its separate Open GL context it does not work (it still gets the Analyzer warning on first use).
So... it could be that prewarming a shader on a separate context has no effect on other contexts. Or it could be that I don't have all the same state set up the separate context. There is a lot of potential Open GL state that might need to be set up. I'm using an offscreen render buffer on the background thread so that could be considered part of the state.
Has anyone succeeded in getting prewarming working on a background thread?
To be honest with you I was quite ignorant on this matter until yesterday though I have been working on my engine optimization for a while. So, first of all, thank you for the tip :).
I have studied since then the shader warming topic and I have not found much around.
I have found a mention the official AMD documentation in a document titled "ATI OpenGL Programming and Optimization Guide":
http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=6&ved=0CEoQFjAF&url=http%3A%2F%2Fdeveloper.amd.com%2Fmedia%2Fgpu_assets%2FATI_OpenGL_Programming_and_Optimization_Guide.pdf&ei=3HIeT_-jKYbf8AOx3o3BDg&usg=AFQjCNFProzLiXf5Aqqs4jZ2jOb4x0pssg&sig2=6YV7SVA97EFglXv_SX5weg
This is an excerpt of which refers to the warming of the shaders:
Quote:
While the R500 natively supports flow control in the fragment shading unit, the R300 and R400
asics does not. Static flow control for the R300 and R400 is emulated by the driver compiling out
unused conditionals and unrolling loops based on the set constants. Even though the R500 asics family
natively support flow control, the driver will still attempt to compile out static flow conditions enabling
it to reorganize shader instructions for better instruction scheduling. The driver will also try to cache
away the compiled shader for a specific static flow condition set in anticipation for its reuse. So when
writing a fragment program that uses static flow control, it is recommended to “warm” the shader cache
by rendering a dummy triangle on the very first frame that uses the common static conditional
permutations relevant for the life of the shader.
The best explanation I have found around is the following:
http://fgiesen.wordpress.com/2011/07/01/a-trip-through-the-graphics-pipeline-2011-part-1/
Quote:
Incidentally, this is also the reason why you’ll often see a delay the first time you use a new shader or resource; a lot of the creation/compilation work is deferred by the driver and only executed when it’s actually necessary (you wouldn’t believe how much unused crap some apps create!). Graphics programmers know the other side of the story – if you want to make sure something is actually created (as opposed to just having memory reserved), you need to issue a dummy draw call that uses it to “warm it up”. Ugly and annoying, but this has been the case since I first started using 3D hardware in 1999 – meaning, it’s pretty much a fact of life by this point, so get used to it. :)
In this presentation, it is mentioned how the cryteck engined performed it on the far cry engine though it is mostly related to DirectX.
http://www.powershow.com/view/11f2b1-MzUxN/Far_Cry_and_DirectX_flash_ppt_presentation
I hope these links help in some way.
Is the format of compiled pixel and vertex shader object files as produced by fxc.exe documented anywhere either officially or unofficially?
I'd like to be able to read the constant name to register assignments from the shader files. I know that the effects framework in D3DX can do this, but I need to avoid using D3DX as it may not be installed on user's machines and I don't need it for anything else so I want to avoid them having to run the directx update.
If the effects framework can do it, then so can I if I can find out the file format but I can' seem to find it documented anywhere.
(this is for use in directx9)
From MSDN:
Asm Shader Reference (Windows)
Shader Binary Format
The bitwise layout of the shader instruction stream is defined in D3d9types.h. If you want to design your own shader compiler or construction tools and you want more information about the shader token stream, refer to the Direct3D 9 Driver Development Kit (DDK).
So you can either look through 'D3d9type.h' and try to figure it out that way (had a quick look and could see the enums/types you should need, but not how its structured), or download the DDK and read the official documentation.
Some more info can be found here: Direct3D Shader Codes (expand the tree on the left hand side of the screen to get all the info).
Microsoft deliberately keep this information away from you. As you are using DirectX 9 its relatively easy to backward engineer the format though. If you write a simple piece of shader assembly you can check out what he compiled code returned at the other side is. By making modifications to the assembler you can see how they byte code changes. You will start to see patterns in how registers are handled and where the instruction is encoded. You can thus, slowly but surely, work out the byte code. It won't be too quick though!
Microsoft has put the format specification online here: Direct3D Shader Codes.
It refers to constants by name, however (eg. D3DSIO_DCL), so you'll likely still need the Windows DDK to get any use out of it.