Since I still haven't gathered the means to make some external debugging on the mesa-0-0-3-branch I've chosen to invest my time in better understand the logic of a mesa driver, especially the *_vb.c and *_tris.c files. I would appreciate if someone reviewed these notes and correct me when I'm wrong.
The work starts on t_pipeline.c were a driver configurable pipeline is run for each begin/end pair. The pipeline stages operate on context variables (suchs as vertices coord, colors, normals, textures coords, etc), applying the necessary operations in a OpenGL pipeline (such as coord transformation, lighting, etc.). The last stage - rendering -, calls BuildVertices in _vb.c which applies the viewport transformation, perpective divide, data type convertion and packs the vertex data in the context (in the arrays tnl->vb->*Ptr->data) into a driver dependent buffer with just the information relevent for the current OpenGL state (e.g., with/without texture, fog, etc). The template t_dd_vbtmp.h does this into a D3D alike vertex structure format. For instance, if we needed to premultiply the textures coordinates, as it is done in mach64-0-0-2-branch, we will need to make a costumized version of t_dd_vbtmp.h for that effect, or change it and supply a configuration parameter to control that behavior. This buffer is then used to render the primitives in _tris.c. This vertex data is intended to be copied almost verbatim into DMA buffers, with a header command, in most chips with DMA. But in the case of Mach64, were the commands are interleaved with each of the vertex data elements, it will be necessary to use a different structure of *Vertex to do the same, and probably to come up with a rather different implementation of t_dd_vbtmp.h as well. To do that in a secure manner, these commands should be either verified or even written by the DRM. A good way to do this would be have a template in the DRM for generating a set of functions for each of those generated by t_dd_vbtmp.h. (If this idea is viable, while DMA is not enabled in the DRM, this could be initialy implemented with a pseudo DMA software alike approach, as Leif suggested, and we could could guarantee security from the start.) All this mechanism is controlled with function pointers in the context which are rechosen whenever the OpenGL state changes enough. These functions pointers can also be overwritten with those in the sw_* modules to fallback to software rendering. José Fonseca _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
