With the release of NV_vertex_program_2, I would like to submit for discussion the notion that vertex programs may be dead.
What I mean by that is that they are feature-complete. They already have exp, log, sin, cos, etc. They’ve got loops and conditional branches too. Really, the only improvents to be had are either performance enhancements or more registers/opcodes (input, output, temporary, or constant).
Actually, now that I think about it, there is one, rather frightening, more thing a VP can have: Direct Memory Access. I don’t like this idea, personally, as it seems to violate some basic ideas about what vertex programs should, and should not, do. I, personally, feel that vertex programs should be given a specific set of data to operate on.
Instead, I would propose the following: rather than giving vertex programs free reign at memory, let’s create a new type of program: the command program.
The command program is given pointers to the various arrays (with strides and so forth), and is given a pointer to indices. It may also be given pointers to other information (at the user’s control). The command program has bound to it one (or possibly more, but that would be even harder to implement in hardware) vertex programs that it can call to send verts along the pipe. When it calls a vertex program, it gives it a pointer to what may well be a register file that contains the constant registers. As arguements, it sends per-vertex attributes. It is important to note that the command program, also, has direct control over how the system handles the vertex data (strips, fans, lists, etc).
A standard command program will loop over the number of indices for the primative type, run a vertex program on the data for each index, and finish. A more complex command program may be given a displacement map and start tesselating the vertex data. It could perform NURBS tesselation in hardware. A command program could even pick matrices out of a large set for skinning purposes.
In order for command programs to be useful, they must be both powerful and reasonably fast. It will have to be able to have a temporary memory buffer, so that it can properly play with vertex data. But, aside from this, it gives the user the ability to tinker with vertex data and create new polys while still not making vertex programs do something that they probably shouldn’t be involved in.