On Mon, Dec 16, 2002 at 08:09:28PM +0000, Keith Whitwell wrote: > José Fonseca wrote: [...] > What's important to see is that buffers are three things: > 1) a memory management system > 2) a hardware synchronization device > 3) a mechanism for submitting commands to hardware > > These functions can be separated.
Exactly. Assembling all those functions in a single opaque one-size-fits-all engine as so far will never fit the wide [and always evolving] range of 3D hardware. > We've already separated the third function more or less in the newer > drivers. > > >Unfortunately, this trick won't work for Mach64 since [due to security > >reasons] it will need to have two DMA buffers pools with the same size: > >one private and another for general client usage. > > Are these both actual dma buffers in the strong sense - are they both > accessed by the card's dma mechanisms? In Mach64 both buffers pools will be DMA buffers in the strong sense: one pool is kept privately for vertex buffers (which are actually generic commands and can the compromise system security), and the other pool is mapped into the client space (just for raw data such as textures and eventually xvideo frames). > > > >My suggestion is twofold: > > > >1) Provide a set of DRM APIs for PCI DMA buffers allocation. No > >assumption about the buffer management is made and that is entirely left > >to the DRM driver (which is free to put some in a linked list, map them > >or whatever). In Linux they basically would be just a very thin wrapper > >around pci_*_consistent routines. > > Is there an existing linux interface to these routines that could be used > instead of adding code to the drm module? Linus and Alan already addressed this question. I just would like to share that when me and Leif began to work on the Mach64 DMA, we actually started by using the pci_*_consistent routines for stuff like ring buffers, since they so easy to use and don't involve coding simultaneously on the DRM and on the 2D driver. It was only when I was trying to address the security issue and remove their use completely [to promote OS-independence] that I stumbled with the shortcomings of the current DMA engine! > >2) Have the current AGP allocation and memory mapping APIs available for > >internal drive usage, instead of just an IOCTL interface for X usage. > > I don't understand what you're suggesting by this. As I was looking for an example to give you I noticed that most of the DRM AGP APIs in drm_agpsupport.h are just thin wrappers to the Linux AGP API so that suggestion actually doesn't apply to AGP, but if you see drm_bufs.h, all the APIs have an IOCTL-alike interface, but it would be useful to access them internally from within DRM_IOCTL_DMA. > >Note that this can be made without breaking the existing source code, > >just by adding new APIs, and as all drivers move to this scheme, the > >old APIs would be removed or turned into NOP's for backward > >compatability. > > Backward compatiblity means that old X servers and old 3d clients work > with new versions of the kernel modules -- this means that you can't > really remove API's... But I guess you can turn them into noops as long > as things like DRM_IOCTL_DMA still work as expected... I see. José Fonseca __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com ------------------------------------------------------- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
