I realize this is probably not the right forum to ask this, but I’m not sure where else to do it.
I have to write a set of GLSL ES fragment shaders which is supposed to make heavy use of specific operations. ADD, MADD and various trancendental ops, such as sin, cos, tan etc.
There’s supposed to be three different shaders, each one using only one of above said ops, and preferably as little as possible of other operations.
I have searched and searched but haven’t been able to find any kind of offline GLSL ES compiler which can provide me with assembler output, so I can’t really be sure what operations my shaders are doing. I can guess, but I can’t be sure. Does such a thing even exist? Can I use a normal GLSL-compiler (I think ATI has one wich can provide assembler output) and expect the ES-shader to use the same operations?
Edit: And a bonus question more related to these forums.
How come the extension GL_OES_depth_texture is supported in the PVRFrame (SGX 530 emulation) when it’s not supported on actual devices which uses the SGX 530 chip? For example the samsung i8910 HD.
polarpeder2009-12-22 14:19:49
this is a great question.
kind of like 'cc -S'
Each target platform as you alluded to would produce vastly differing opcodes, but the point is still valid.
This begs the question:
Can we writer shaders in assembly that is targeted very explicitly to one GPU?
One specific example is utilizing the 'multiply and accumulate' instrucions for digital filters
There is no way to know what instructions are used.
polarpeder wrote:
How come the extension GL_OES_depth_texture is supported in the PVRFrame (SGX 530 emulation) when it's not supported on actual devices which uses the SGX 530 chip? For example the samsung i8910 HD.
The extensions that are available on platforms are chosen and exposed by the platform vendor. I believe this extension is available on some other platforms and is certainly implemented in the chip and so this is why PVRVFrame exposes it.
As far as shader compilation: specific assembly instructions in a shader for another vendor's platform are unlikely to have more than a passing resemblance to those in a shader for a completely different graphics core (like SGX) - it'd be unlikely to be very useful for anything but the most crude optmisation, I'm afraid.
Using assembly shaders is not available through the APIs on mobile platforms so this is not something we support and currently, exposing the assembly instructions that our compiler produces is something we've chosen not to make available. However, using the PVRUniSCoEditor front-end does provide line-by-line counts of how many clock cycles a given shader will require to execute. Make the cycle count as low as possible for the most optimal shader.
We provide a reference compiler with PVRUniSCoEditor in the SDK. You can also point the editor to another offline compiler that may be provided by your platform's vendor for more accurate results.
