iam wondering about accepted opcodes for the radeon families using the unextended extensions ARB_vertex_program and ARB_fragment_program.
Both low level assembly extensions and the GPU Shader Analyzer offline compiler accept opcodes not defined in these extensions. In general opcodes introduced by NV extensions like NV_vertex_program2 and so on. But current drivers accept these NV owned opcodes without an explicit OPTION target to this extensions, but not all opcodes or all combinations.
For example the compiler accepts in the vertex language WITHOUT an OPTION to NV_vertex_program3:
ADDC_SAT <- condition code update and saturation in ARB_vertex_program?
TEX_SAT <- texture lookups with saturation in the vertex language?
But for example the compiler accepts not:
ADDC (LT.x) R0, R1, R1; <- destination writemask depending on condition not supported
The same thing is for fragment programs. Example: programs can read from fragment.facing registers
Why is this so?
ARB-Assembly programs can use opcodes from the greens without using its option?
Furthermore there is no NV extension found in the extension string to explain this behavior.
is there a several ATI/AMD extension to extend the crossplattform ARB_vertex_program and ARB_fragment_program opcodes?
Recent Radeon drivers do indeed support some of the additional opcodes defined by the NV_vertex_program and NV_fragment_program extensions (and their successors). However, we do not support every last instruction in any of these extensions, and so can't claim to support the extensions themselves. The support is primarily there to allow illegal applications that use the instructions without checking for or enabling the extensions to run correctly. We consider the assembly extensions to be a legacy feature that should not be used in new applications. New development should be done in GLSL.