Here are some extensions which might be usefull in future OpenGL implementations:
Generic Matrices
Now there are only some limited matrices like modelview matrix. But if you want to use hardware-accelerated matrix operation for generic matrics you have to use texture matrices and that may cause errors. So it would be nice if there were gerenic matrices with hardware operation support and a stack for each matrix like modelview matrix.
Programmable Tesslator
I’ve just read in ARB meeting notes from Dec 2001 that there was the idea of a programmable tesslator. Are there any ideas of defining such extension? Maybe as an addition to OpenGL shading language?
What do you think about that? Any other ides os useful future non-vendor specific extensions?
BTW: When will ARB meeting notes from March 04 be posted?
By “generic matrices”, he’s refering to matrices that are not bound to fixed functionality. Just like there are generic array attributes that can be referred to by a vertex program/shader by a name, there would be some number of generic matrices that could be referred to in the same way.
However, I think that “hardware-accelerated matrix operations” are given far too much value. If you aren’t constructing a matrix array (which would require you to build them yourself), then you probably aren’t doing too many matrix operations. Also, there is no guarenteed (or, in some cases, likelihood) that the GL implementation is doing anything more than you could on the CPU.
As for the “Programmable Tesselator”, that functionality is too limitted. What you really want is a full-fledged programmable primitive processor. It’s job would be to take vertex array data and parameters and such, and construct each vertex. It would have the ability to walk a vertex array, vertex index array, etc. It’s output would be the input to the vertex program.
You get your tesselator functionality, but you also get lots of other stuff too.
There are C multi-platform matrix libraries. Many support all of the home PC’s of the Intel, AMD, and Apple varieties. Where possible hardware-specific optimization like SSE and Altivec are used.
I take tesselation as any process that takes input and spawns an unbounded number of triangles. This would be what Korval describes as a “full-fledged programmable primitive processor”. A sphere tesselator would take a description of a sphere (origin, radius) and generate a list of triangles. Most of the GLU primitives use tesselation to make geometry.
A programmable tesselator is a difficult problem. Vertex and fragment programs are relatively easy because they take a single input, and generate a single output(including a possible null output, like kill in fragment programs). An example tesselator program could start with a single triangle, and subdivide the triangle until each resultant triangle had an area of less than some threshold. Another example would take a 10x10 grid of points and generate a 9x9 grid of triangles.
I started on this problem about 2 years ago. I decided that the best way to do this was to add a CPU and let it be the programmable unit. To do this effectively, I made a structure description language, (basically a “C struct description”), and used it specify the input to the tessprogram. The tessprogram language was a subset of C, the subset allowed in a function implementation(the program was essentially a function that took the described C struct as a parameter). It incorporated two functions one to exit the tesselator early, and the other to add a triangle to the output. This was then sent to a inline-compiler, and a function was created, that was invoked when the program needed to run.
Yes, I know that there are many matrix libraries which are very fast using MMX, 3DNow, … But is quite hard and use them in GL. e.g. The Modelview matrix can easily be using by ARB_*_programs (using state.matrix.modelview) and by GLSL (using gl_ModelViewMatrix). But there are no generic matrices which can be used by both (execpt texture matrices of course). Ok, ARB_vertex_program defines program matrices but they cannot be use with GLSL and has a stack depth of 1 (in the most implementations).
@programmable tesslator
With Render to vertex array some problems can be solved but you mainly have to do 2 passes: one for the vertices (and vertex data) and one for the index array. The size of the vertex array is normally smaller than the size of the index array so there will be 2 passes which makes the whole thing a little bit complex.
I know that tesslator easly can be programmed in software but I think the main disadvantage doing that is that all vertex data have to be transfered to the graphic card. So you don’t take advantage of VBOs.
Of course a programmable tesslator is not easily defined and needs for some featrues which are very expensive to implement: loops, branching, recursive functions, …
But you won’t have all these problems (especially the data type problem) when you use general processor (I described my idea shortly at http://www.opengl.org/discussion_boards/ubb/Forum11/HTML/000011.html )
