I am newcomer to the vertex and fragment shader programming paradigm. I am currently exploring them using an ATI Radeon 9800 Pro 128Mb under the Windows XP operating system environment. I have a number of general questions that I think a more experienced programmer can answer quickly:
Is there a single unified ARB ASM instruction set? That is, one which both Nvidia and ATI cards can compile/understand using GL_ARB_vertex_program and GL_ARB_fragment_program extensions?
Whatever the answer to question 1, where can I find a list/table that summarize ARB/ATI/NVidia instruction and variable sets? In the case that a unified ARB ASM instruction set does not exist I’d be more interested in the ATI instruction set, however, I have not been able to find such a list/table in the developer section at ATI.com. I’d also be interested in seeing such a list/table for Nvidia cards just to contrast and compare with ATI.
When using multiple textures in a fragment program, do I need to use the glActiveTextureARB() command to bind textures before making the call to run the fragment program? Or do I simply
do glBindTexture() however many times needed in a row to enumerate my textures in that order?
What is the difference between glProgramEnvParameter4fARB and glProgramLocalParameter4fARB? What exactly constitutes an environment parameter vs a local parameter? Is one for passing integer data and another floating point?
What is the status of floating point usage inside vertex and fragment programs? I always hear directx touting support for a 128bit floating point format. Do Opengl ARB program extensions support this implicitly or must it be enabled explicitly? What can/does it support in regards to internal fp computation?
Are textures values accessed inside a fragment program integers? Does the GL_ARB_texture_float extensions allow texture values to be accessed as floating points? If so, at what precision? I’d like to play around with this extension but I do not know the function(s) associated with it so that I can retrieve them using wglGetProcAddress.
I realize there are number of high-level languages for shaders CG,GLSL and what not, however, I really want to know more about the ASM instructions the GPU is executing. Information regarding this seems to be at best ambiguous - even at websites like www.gpgpu.org. I have yet to see a straightforward checklist/comparison sheet stating what GL ARB programs can do vs their DirectX counterparts of just in general.
There is a general lack of understanding in terms of your thinking on “assembly shaders”.
The first thing you should know is that they are not executed as-is by any GPU. They are compiled and optimized just like a higher-level language. The difference is that they are simpler and lower-level. As such, no assembly language gives you an idea as to what the GPU is doing internally; it can only tell you the sequence of operations that the GPU will perform. Much like a higher-level language.
Secondly, floating-point use is defined by the spec for the particular extension. ARB_fragment_program requires, effectively 24-bit floats or better per component. NV_fragment_program allows the user to specify the precision of each variable. (fp32, fp16, or 10-bit fixed-point).
In general, you can assume that any ARB extension has relatively wide support. This means ARB_vertex_program and ARB_fragment_program too.
However, do note that these extensions are likely “dead-ends”. You will likely never see ARB_vertex_program_2, even though hardware can do more than ARB_vertex_program lets it. The reason for this is because the ARB has moved to glslang as the principle shading language. If you want to use features in the future, this is the language to learn.
There is only one ARB instruction set of vertex/fragment programs. Look at the extension specs. Nvidia allows some(a lot) extra Nvidia specific asm instructions if you use an option flag.
You need to use glActiveTextureARB to set the imaging unit( note that there are more imaging units than texture units) and then bind the texture to that unit. When using fragment programs you do not need to call glEnable with the texture type.
Environment variables can be shared between multiple programs. (ie load once and all programs that use those variables will be updated) Local varaibles are just local to that program.
As Koval said above: Each component in vertex programs is 32 bit (x4 components =128bit) and in fragment programs it can vary. (ATI 24 bit, NV 16/32 bit)
I don’t think there is a official “ARB” float format yet but the ATI_texture_float format is now starting to be supported on nvidia cards (earlier nvidia cards had a seperate more restrictive extension) It supports 32/16 bit floats per component. Read about it here: http://oss.sgi.com/projects/ogl-sample/registry/ATI/texture_float.txt
See Koval’s comment above. (asm in this case is not “real” asm)
ARB_fragment_program ~ D3D ps2.0 so there should be nothing significant that one can do that the other cannot.
ARB_vertex_program ~ D3D vs1.1 so there are a lot of things like branching that is missing (ie against vs2.0) So you need to use ARB_vertex_shader(GLSL) to get access to this functionality.
Re the integer/float distinction, OpenGL has always treated colors and texture samples as if they are floats, even when they were still integers. You can see this in the old ARB_texture_env_combine specs. This is an extension that was purely targetted at integer hardware, but still it assumes numeric range from 0.0 to 1.0 for all color components.
Of course we have “real” floating point hardware now, but the paradigm didn’t change.
If you sample an integer component texture in ARB_fragment_program, the target register will contain a floating point value in the range [0…1].
Floating point textures may produce samples exceeding that range.
Originally posted by Korval:
[b]There is a general lack of understanding in terms of your thinking on “assembly shaders”.
The first thing you should know is that they are not executed as-is by any GPU. They are compiled and optimized just like a higher-level language. The difference is that they are simpler and lower-level. As such, no assembly language gives you an idea as to what the GPU is doing internally; it can only tell you the sequence of operations that the GPU will perform. Much like a higher-level language.
Secondly, floating-point use is defined by the spec for the particular extension. ARB_fragment_program requires, effectively 24-bit floats or better per component. NV_fragment_program allows the user to specify the precision of each variable. (fp32, fp16, or 10-bit fixed-point).
In general, you can assume that any ARB extension has relatively wide support. This means ARB_vertex_program and ARB_fragment_program too.
However, do note that these extensions are likely “dead-ends”. You will likely never see ARB_vertex_program_2, even though hardware can do more than ARB_vertex_program lets it. The reason for this is because the ARB has moved to glslang as the principle shading language. If you want to use features in the future, this is the language to learn.[/b]
Pretty much all the GL extensions are based on the original core :
1 part in 10^5, ~17 bit mantissa so 24 bit may not or may not be enough. I’m not sure what 24 bit float should be, but this is a ATI thing and they haven’t defined it.
I was thinking that there would not be ARB_vertex_program_2 or ARB_fargment_program_2 but NVidia’s extended it (look at NV40 extensions) and I heard at least once from one of them it will be extended.
I was thinking that there would not be ARB_vertex_program_2 or ARB_fargment_program_2 but NVidia’s extended it (look at NV40 extensions) and I heard at least once from one of them it will be extended.
this actually makes some sense. if nvidia wants cg to remain a viable option for gl profiles, it will have to provide for some kind of standardized interface. if developers are forced into nv specific profiles, cg becomes less attractive.