Keith Whitwell wrote: > I've just created a branch to house some experiments to do with > integrating the i965 driver a little better with core Mesa. > > In particular, the i965 driver houses a cloned version of the vertex > building code from the tnl module. My particular plan is to eliminate > both copies of this code and recreate it in a new location where it is > separate from both the tnl module and the drivers. In this new > incarnation the code will have a single purpose - to build and manage > VBO's containing vertices passed to mesa whether through the > intermediate api, as vertex arrays, display lists or even directly as > VBO's. The "vbo_builder" module will keep track of these VBO's and make > a single callback I'm calling "DrawPrimitives" which passes a list of > primitives, a list of active arrays (all within VBO's) and possibly an > index buffer. The driver's task is simply to upload (if necessary) > those VBO's and draw the primitives. > > The tnl/ module in turn has been stripped of its display list building > and immediate api, and will have a single new entrypoint, also called > DrawPrimitives which matches the callback above exactly. > > Also as a result, the nasty array_cache thing can go away forever. > > This will (once merged) have a few effects on other drivers. The vtxfmt > code in a couple of drivers (r200, r300) starts to look redundant - the > assembly optimizations there could be cleaned up and pulled into > vbo_builder. The radeon_vtxfmt_a.c needs a bit more investigation, but > hopefully can be adapted to work well with the vbo building code. > > Ultimately what this should mean is that we end up with just a single > way of building vertices across all drivers, both software and hardware > tnl, and falling back to swtnl in a hardware driver should be as simple > as calling the tnl module's DrawPrimitive() command directly from the > driver. This sounds like something really useful. Personally, I always considered the vtxfmt code of radeon/r200 as something which should rather not exist - yes it's somewhat faster than "normal" tnl (if you're lucky enough to not hit a fallback), but the maintenance cost imho is just not worth it. Consequently, when adding new features to the r200 driver requiring changes to how vertices are submitted (like fogcoord) I rather added fallbacks to vtxfmt than making it actually work there. Even then, it's prone to errors, from time to time odd bugs turn up which need to be fixed (I'm talking about things like http://sourceforge.net/mailarchive/forum.php?thread_id=30457327&forum_id=6511). OpenGL's allowance of using all the different vertex specification functions within the same primitive (texcoord functions with 1, 2, 3, 4 floats/ubytes/doubles and what not for instance) makes this complicated enough that you don't want to duplicate the code needed for it. That said, what I missed from the tnl vertex building code was the ability to specify what vertex format the hardware would accept and consequently avoid unnecessary conversions - specifically, apps specifying colors with ubytes got it all converted to floats, so you have both the conversion cost, and need to upload larger vertices (actually, the radeon driver for a long time converted it even back to ubyte), which definitely makes a measurable difference (when using vertex arrays at least). The r300 radeon_vtxfmt_a code avoids this (for vertex arrays, when you know that all vertices have the same format), it would be nice if this could be kept - though I guess nowadays when using vertex programs more data is probably specified as floats anyway, and when apps are using ARB_vbo the performance impact should be lower (though the data will of course still use 4 times as much memory). The only drawback I can see right now to the current vtxfmt code of the radeons is that it potentially can't quite be as fast (with immediate mode), since the current vtxfmt code can copy the data directly to gart space. That seems a really small price to pay...
Roland ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Mesa3d-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
