On Fri, Apr 04, 2003 at 10:23:21PM +0100, Keith Whitwell wrote:
The optimization of the vertex api has yeilded huge improvements. Even with the runtime-codegenerated versions of these functions in the radeon/r200 driver, they *still* dominate viewperf profile runs - meaning that *all other optimizations* are a waste of time for viewperf, because 60% of your time is being spent in the vertex api functions.
I was underestimating its importance then...
Nowadays, vertex arrays are the path to use if you really care about performance, of course, but a lot of apps still use the regular per-vertex GL functions.
Except for applications that already exist and use the vertex apis -- of which there are many.
And vertex arrays aren't the fastpath any more, but things like ARB_vertex_array_object or NV_vertex_array_range.
Now that you mention vertex array, for that, the producer would be different, but the consumer would be the same.
For developing a driver, it's not necessary to touch the tnl code at all - even hardware t&l drivers can quite happily plug into the existing mechanisms and get OK performance.
For now I'll be also plugging in the C++ classes into into the existent
T&L code, but in the future I may want to change the way the software
T&L interfaces with the [hardware] rasterizers, since the current
interface makes it difficult to reuse vertices when outputing tri- or
quad-strips, i.e., you keep sending the same vertices over and over
again, even if they are the same betweeen consecutive triangles.
Honestly, that's just not true. You can hook these routines out in a bunch of different ways.
Look at t_context.h - the tnl_device_driver struct. In here there's two table sof function pointers 'PrimTabVerts' and 'PrimTabElts' which hand off whole transformed, clipped primitives - tristrips, quadstrips, polygons, etc. - to the driver. Hook these functions out and you can send the vertices to hardware however you like.
Also look at tnl_dd/t_dd_dmatmp.h, as used in mga/mgarender.c and elsewhere -- this is an even more direct route to hardware and is very useful if you have a card that understands tristrips, etc. It probably isn't much use for a mach64, though.
Clipped triangles are more difficult to handle, we currently call tnl->Driver.Render.PrimTabElts[GL_POLYGON] for each clipped primitive. If you can think of a better solution & code it up, I'd be interested to see it. It would be interesting to see some other approaches, but I think this one actually ends up not being too bad.
Keith
-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
