This has to do with the move to OpenGL 3.x +. Right now, those variables are synthesized and immediate mode style code generates shaders to run rather than the older fixed function pipeline. So even if your card supports OpenGL 1.x, 2.x, and 3.x, calling immediate mode GL (ie, glRotate/Translate/Scale, glBegin/end, glLoadMatrix, glLoadIdentity (this list goes on and on)), all gets translated into a shader and cached. That takes a slight speed hit, and brings over-head to state validation.
Generic attributes etc mean you must handle the model view * projection matrix to clipping space conversions yourself in the shader, and pass in any older supplied attributes like normal, color, etc, as well as calculate all translation matrices that you need manually either in the CPU and uploading as an attribute or on the GPU in a shader, depending on what makes sense.
This supposedly gives speed ups (assuming you do other things as well), and also grants OpenGL ES 2.0 compatibility in really the most loosest meaning of compatibility. Your shaders may/may not work depending on the number of instructions, and not all of the extensions you would leverage are there, etc.
In short, don't worry too much about it until OS X remove any fixed function pipeline functionality from the OS, or if you as an app developer reall yneed an extra 1 to 5% of performance from your app after you have exhausted all other options. I do not expect OS X to loose fixed function in the next 10 years :)
This is more or less one of the last optimization stages one ought to do in GL, as there are many many more important things to optimize before you get "here".
In short, don't worry, its mostly for OpenGL ES 2.0 folks. And it is a royal pain in the ass either way, and would require a huge re-arcitecting to QC's GL pipeline, where more obvious optimizations could grant much larger performance boosts, ie: graph evaluation etc.
Thanks for that very informative and thorough feedback.
I had hoped it was little or nothing, apart from the iPhone / iPad embedded systems shader stuff that would be affected, though the note about fixed-function built in variables suggests that the entire Mac OS would appreciate our not using them.
Quote:
not recommended for use on Mac OS X. For example, instead of using gl_ModelViewProjectionMatrix, create your own modelViewProjectionMatrix variable
Having said all that, there's lots of documentation out there about 'rolling your own' model/view/projection matrices, and simple translation and rotation isn't too tricky to achieve. I made a little JavaScript a while back to create 4x4 3D translation and rotation matrices for a shader I was working on, and it was simpler than I'd thought it would be, in the end. As I understand it, projection matrices are a little more tricky, but there's a standard formula for perspective projection that's used most of the time, so that's not too hard in practice, either.
This has to do with the move to OpenGL 3.x +. Right now, those variables are synthesized and immediate mode style code generates shaders to run rather than the older fixed function pipeline. So even if your card supports OpenGL 1.x, 2.x, and 3.x, calling immediate mode GL (ie, glRotate/Translate/Scale, glBegin/end, glLoadMatrix, glLoadIdentity (this list goes on and on)), all gets translated into a shader and cached. That takes a slight speed hit, and brings over-head to state validation.
Generic attributes etc mean you must handle the model view * projection matrix to clipping space conversions yourself in the shader, and pass in any older supplied attributes like normal, color, etc, as well as calculate all translation matrices that you need manually either in the CPU and uploading as an attribute or on the GPU in a shader, depending on what makes sense.
This supposedly gives speed ups (assuming you do other things as well), and also grants OpenGL ES 2.0 compatibility in really the most loosest meaning of compatibility. Your shaders may/may not work depending on the number of instructions, and not all of the extensions you would leverage are there, etc.
In short, don't worry too much about it until OS X remove any fixed function pipeline functionality from the OS, or if you as an app developer reall yneed an extra 1 to 5% of performance from your app after you have exhausted all other options. I do not expect OS X to loose fixed function in the next 10 years :)
This is more or less one of the last optimization stages one ought to do in GL, as there are many many more important things to optimize before you get "here".
In short, don't worry, its mostly for OpenGL ES 2.0 folks. And it is a royal pain in the ass either way, and would require a huge re-arcitecting to QC's GL pipeline, where more obvious optimizations could grant much larger performance boosts, ie: graph evaluation etc.
Thanks for that very informative and thorough feedback.
I had hoped it was little or nothing, apart from the iPhone / iPad embedded systems shader stuff that would be affected, though the note about fixed-function built in variables suggests that the entire Mac OS would appreciate our not using them.
I am now reassured.
Having said all that, there's lots of documentation out there about 'rolling your own' model/view/projection matrices, and simple translation and rotation isn't too tricky to achieve. I made a little JavaScript a while back to create 4x4 3D translation and rotation matrices for a shader I was working on, and it was simpler than I'd thought it would be, in the end. As I understand it, projection matrices are a little more tricky, but there's a standard formula for perspective projection that's used most of the time, so that's not too hard in practice, either.
a|x
Yea, the math is not so bad, its re-architecting all of your pipeline and dependance on immediate mode :\