On Sat, Mar 02, 2002 at 03:40:02PM +0000, José Fonseca wrote: > 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.
In the (mesa-4-branch) radeon driver the vertices built up are built up directly into a dma buffer, it's not copied again. The security side is because the actual command(s) sent to the card that says 'here are a load of vertices at offset 0xnnnnnnn' are put into the ring (i.e just different part of the agp space) by the drm. So the hardware interprets whatever junk a client puts in there as vertices, rather than as commands to blit etc. The stuff that's copied/created (all the BEGIN_RING() etc) copy from system mem (you don't want to copy from uncached agp using the cpu, bar some amazing fastpath optimisation that has a fallback path where you may copy the odd vertex) > 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. Maybe, but if the card sees xxMb of agp/pci space the vertices (or texture for uploading, etc) is just an offset from all 3 points of view (the client, the kernel, the hardware), the 'buffer' idea is really conceptual to share the space between clients. You should be able to just build up what the hardware wants to see in the pipeline and say 'there it is..' > 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 Look at Keith's CmdBuf thing in the tcl branch. -- Michael. _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel