Depends on the CPU. Note, every card supports vertex shaders (just
like every card supports software TCL). Not every card supports
fragment shaders. In the end if a card has hardware vertex program
support it will likely (I say likely as there are missing cases
right now) try to run the shader in hardware (in our testing of a
random set of about 1000 shaders about 93% can run hardware, this
is looking at vertex and fragment shaders). If the shader can't
run in hardware or the card does not have hardware vertex program
support then it will do software vertex processing. For the
fragment side if a card supports fragment programs we will try to
run fragment shaders in hardware. If the shader can't run in
hardware we will fall back to software (which in this case is
likely not very desirable and likely too slow for real time apps).
There are lots of things that can knock a shader off hardware....
- non-constant loops
- too many instructions, variables (temps) or uniforms (params),
all of which vary by hardware
- destination indirect array addressing (in some cases)
- noise
- differencing functions on anything but NVIDIA 6600+ class hardware
and a number of other strange cases...
So what is one to do?
- First test on the hardware you expect to run. This is critical.
Up until now we have had extensions that the presence in the
extension string completely defines whether the extension is fully
supported or not. Now with GLSL and FBO the level of support in
hardware and the performance varies GPU to GPU and CPU to CPU. So
you MUST test on your target platform when using these extensions.
Assuming good performance on every future GPU which exports GLSL is
not likely a good plan.
- Second we have provided an API in 10.4.3 to determine, given the
current state, where the processing will take place (or is taking
place). This call does a state validation (which is not free) and
indicates whether the processing is occurring on the GPU or not.
Here is the API...
To be used with CGLGetParameter (from the new CGLTypes.h)...
kCGLCPGPUVertexProcessing = 310, /* 1 param. Currently
processing vertices with GPU (get) */
kCGLCPGPUFragmentProcessing = 311 /* 1 param. Currently
processing fragments with GPU (get) */
Example...
CGLGetParameter (CGLGetCurrentContext(),
kCGLCPGPUVertexProcessing, &vertexGPUProcessing);
CGLGetParameter (CGLGetCurrentContext(),
kCGLCPGPUFragmentProcessing, &fragmentGPUProcessing);
This works at anytime and is applicable to more than just GLSL but
is most useful there.
- Third, I have a GLSL editor/test app which i will be releasing as
sample code shortly. It is a document based Cocoa app that allows
you to write and edit shaders, see the uniforms and attributes (as
reported by the API), set uniforms interactively, control the
target renderer and understand where the processing is taking
place. Since it is sample code you guys can do what you want with
it, add more complicated models or combinations of shaders. This
should be done very shortly (just need to clean it up for external
release).
Geoff Stahl
3D Graphics Architecture
Apple
On Nov 15, 2005, at 11:36 AM, Ken Drycksback wrote:
According to the info, every card supports GLSL. Is this really
true? Is the GLSL support on the low end cards useful for
practical game use or is it very slow?
Thanks,
Ken
On Nov 10, 2005, at 11:12 PM, Alex Eddy wrote:
On May 4, 2005, at 8:45 AM, Alex Eddy wrote:
On Apr 29, 2005, at 12:06 PM, Dennis Piatkowski wrote:
However, looking at the most excellent OGL renderer resource
http://homepage.mac.com/arekkusu/bugs/GLInfo.html
I've updated that page for Tiger. Hope y'all find it useful.
Updated again today for 10.4.3 and new GPUs. Enjoy!
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Mac-opengl mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
