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) */
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:
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
_______________________________________________
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
