There is no public API to do this, but I encourage you to file an
Apple radar bug as an Enhancement Request to provide this level of
detail. Knowing how many native instructions a GLSL shader truly
takes would be very helpful in performance tuning. Alternatively,
extending ARB_fragment_program and ARB_vertex_program to take
advantage of the native hardware capabilities (such as the NV_*
extensions already do) would be just as (or more) advantageous, in my
opinion.
The argument against this approach is that GLSL is the way of the
future. Unless or until there is a way to upload pre-compiled
shaders to the driver, this is very expensive for any dynamically
generated shaders. The other part of the argument is that no matter
how high or low-level the shader that you throw at the drivers, the
driver itself will still need to recompile the shader into a native
bytecode format. So, a compilation of sorts will need to take place
regardless.
Right now, on some relatively recent Apple hardware, you are fairly
limited as to how complex a GLSL shader can be before it drops into
software rendering. For small numbers of vertices, this may not be
that big of a deal. But, as soon as you start throwing a lot of
vertices at the hardware, or if you make the shader exceptionally
complex, your performance will suffer tremendously. Shaders that
work natively on certain drivers will not execute natively on
others. You can query this at runtime by calling CGLGetParameter()
for kCGLCPGPUVertexProcessing or kCGLCPGPUFragmentProcessing. That's
basically your only metric on Mac OS in terms of shader performance
right now. "Is this executing natively or via software rendering?"
On Oct 24, 2007, at 7:16 PM, Stefan Dösinger wrote:
Hello,
My application is using a big number of machine generated GLSL
code, cross
compiled from d3d shader assembler. Because it makes my life much
easier, the
produced glsl does some things which are obviously ineffective,
like calling
empty functions or assigning values to never read varyings. A lot
of things
which shouldn't be too hard for the GLSL compiler to optimize at
compile time
or link time.
I am looking for a way to check the code after it has been
optimized by the
glsl implementation. On the Linux Nvidia driver there is a way to
read the
produced ARB asm code. Is there something similar on the Mac? I am not
looking for a specific code format, anything that is in some way human
readable is fine(pseudo-glsl, arb asm or a dialect of it, a code tree,
whatever). I'd like to see which of my inefficient constructs are
optimized
away as they are supposed to be, and which aren't.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Mac-opengl mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/mac-opengl/jason%
40transgaming.com
This email sent to email@hidden
Jason Green
Developer, TransGaming, Inc.
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Mac-opengl mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/mac-opengl/email@hidden
