On Sat, 2004-06-05 at 14:09 +0300, Ville SyrjÃlà wrote: > 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.
True, but OTOH, to be secure, we might have to check against any potentially harmful register value combinations, unmap the buffer from user space before checking and submitting it to the hardware, ... It's not obvious to me which variant would perform better. IIRC this has been discussed extensively for mach64, has a conclusion been reached there yet? > 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. I think the cmdbuf interface used by the Radeon drivers should be extensible enough? > > > 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... Interesting idea. -- Earthling Michel DÃnzer | Debian (powerpc), X and DRI developer Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer ------------------------------------------------------- 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
