On Sat, Jun 05, 2004 at 12:41:33PM +0200, Michel Dänzer wrote: > On Sat, 2004-06-05 at 12:21 +0300, Ville Syrjälä wrote: > > On Sat, Jun 05, 2004 at 03:09:54AM -0400, Patrick McFarland wrote: > > > > > > expose 2D and 3D hardware acceleration > > > functions, allow applications (DirectFB, xservers) to query the > > > available acceleration methods, > > > > I disagree. > > > > This part of the kernel should be as dumb as possible. I think the best > > interface would be simply one accepting almost complete DMA buffers. The > > only thing missing from these buffers would be real memory addresses. > > I'm not sure about that; pseudo-command buffers that the DRM parses and > generates the actual DMA buffers from on the fly might be better for > security and/or performance reasons.
Quite possible. Though I'm not totally convinced of the performace argument since the kernel would then have to build all of the buffers from scratch. With real buffers we could just check which register the value is for and if there are no problems with that register the value could be passed as is. And one major problem with pseudo buffers is that they should not impose any nasty limits on what we can do. So the design would have to be good from the start. > > The client should just use a surface id (handed out by the memory allocator) > > instead of a real address. The kernel would then check if the client is > > allowed to use those surfaces and replace the ids with real addresses. The > > kernel should also check the buffers for other dangerous stuff. > > Seconded. > > I wonder if we can reasonably get there in a backwards compatible way... I think the current DRM interface could be moved on top of the new one. Maybe as a separate compatibility module... -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ ------------------------------------------------------- This SF.Net email is sponsored by the new InstallShield X. >From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
