Roland Scheidegger wrote: > 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).
Currently, the vbo-builder code will translate all immeidate mode (glVertex/glColor/etc) calls to floats, but the types of arrays are preserved. In future, someone could add support for ubyte and other types to the immediate/display list code, and maybe some of the vtxfmt assembly optimizations (once cleaned up). But for the meantime, you only get ubyte/ushort/whatever on the vertex array paths. I imagine I'll have to add some options for drivers (and the swtnl paths) that really need floats. > 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... Well, in fact this new code can copy directly to gart as well, because (depending on the driver) the VBO can/should be sitting in the gart when it is mapped by the vbo_builder code to fill with vertices... Keith ------------------------------------------------------------------------- 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
