Michael wrote:
>
> 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.
There are three cases for hardware rendering:
- radeon_tcl.c -- (tcl-0-0-branch only) object-space vertices emitted
directly to dma.
- radeon_render.c -- clip-space vertices (with no clipped vertices) emitted
directly to dma after cliptesting.
- radeon_tris.c -- clip-space vertices emitted to temporary buffer, then
copied to dma as Jose describes.
The radeon_render.c case is an optimization and could be removed without
effecting the functionality of the driver.
> 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.
Yes, and there's something similar but not quite as flexible on the trunk
radeon driver. D3D vertices can be passed pretty easily to the kernel which
can massage them & emit them to hardware using whatever commands are
necessary.
Keith
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
