José Fonseca wrote: > > 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.
Actually groups of begin/end pairs. The pipeline is run in response to either the VB filling up, or a statechange. > 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. Yep. > 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. Yes. The tdfx driver does this, it's a pain to do generically, so I forked the template for that driver. Whether it's saved effort in the longrun is questionable, as there have been bugs that I've had to fix twice... > 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. That's the point of creating the vertices. > 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. Indeed, if the chip expects something quite different to the d3d vertices, you will certainly want to look at this. In the meantime, it may be simplest to go with a 'normal-looking' _vb.c and do some extra stuff in the triangle/line/point functions. The ffb and glint drivers are a bit like this, I think. > 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.) Or do the d3d-to-mach64 vertex translation in the kernel? Or is this exactly what you are suggesting??? > 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. Correct again. Keith _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
