-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brian Paul wrote: > Keith Whitwell wrote: >> >> FWIW, I think the distinction between fragment programs and vertex >> programs isn't particularly helpful for us - analysis and optimization >> tools should probably be written to the union of the two languages. >> I'd like to see the type-distinction between them disappear inside Mesa.
I've thought some about that as well. I decided to limit the scope of their project for a couple reasons. The main reason is that we *need* faster vertex programs /yesterday/. The other reason is that I wanted to avoid having to deal with textures. GL_NV_vertex_program3 adds support for vertex-textures, but implementations can export the extension *and* have 0 vertex texture unit (just like with GLSL). > I've been looking into that a little as well. I may be checking in some > code changes to gradually steer toward that. > > One thing that needs some consideration is the manner in which program > inputs, results and parameters are all managed. > > 1. Where does a vertex/fragment program get the input attributes from? > We want to execute the program on batches of vertices/fragments at a > time so a base/stride pair for each attribute would be most flexible. Agreed. There's quite a bit of code in Mesa to massage the incoming vertex data into the format that the TNL code wants. I would *very* much like to see this go away. I suspect the right answer is to do the last stage of compilation when the program is actually invoked (at least for programs running on the host CPU). At that point we can build the data fetches, based on the array type / size / stride, into the compiled program. As a side note, that can allow certain optimizations if, for example, all the incoming vertex data is 2f instead of 4f. > 2. Same thing for program outputs/results. > > 3. There are local program parameters, global program parameters, GL > state reference parameters, named user parameters, constants and > temporaries. In a software environment, we could keep all those in one > contiguous array to simplify things. But for some hardware, that might > not be practical. If would be nice to accomodate both h/w and s/w needs > at once. > > Right now, we've unfortunately got three different software program > executors: the original vertex program executor (shader/nvvertexec.c), > the newer TNL executor (tnl/t_vb_arbprogram.c) and the fragment executor > (swrast/s_nvfragprog.c). It sure would be nice to merge them into one > coherent system. > > Finally, we should also spend some time considering the OpenGL shading > language and if/how that might impact the features needed in a new, > unified program executor. I haven't done a huge amount of research on that. I believe that if the back-end can support GL_NV_vertex_program3 and GL_NV_fragment_program2, then it can also support GLSL. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDaQmGX1gOwKyEAw8RAgpkAJ9LQU3RoC7TTauWlWnwhAGYFOpzwACfeAMk Kwpv90ZykjNEcwAClPeo7Rw= =c6GI -----END PGP SIGNATURE----- ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Mesa3d-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
