On 2002.05.27 16:28 Jens Owen wrote: > ... > > If we do get some type of indirect rendering path working quicker, then > perhaps we could tighten up these defaults so that the usage model > required explicit administrative permision to a user before being > allowed access to direct rendering. > > However, after going to all this trouble of making a decent level of > fall back performance, I would then want to push the performance envelop > for those processes that did meet the criteria for access to direct > rendering resources, and soften the security requirements for just those > processes. This could possible be users that have been given explicit > permission and the X server itself (doing HW accellerated indirect > rendering). > > There would really be three prongs of attach for this approach: > > 1) Audit the current DRI security model and confirm that it is strong > enough to be used to prevent non authorized users from gaining access to > the DRI mechanisms. Work with distros to tighten up the usage model > (and possible the DRI security mechanism itself) so only explicit > desktop users are allowed access to the DRI. > > 2) Develop a device independent indirect rendering module that plugs > into the X server to utilize our 3D drivers. After getting some HW > accel working, look at speeding up this path by utilizing Chormium-like > technologies and/or shared memory for high level data. > > 3) Transition the direct rendering drivers to take full advantage of > their user space DMA capabilities. > > The is a large amount of work, but something we should consider if step > 1 can be achieved to the kernel teams satisfaction. It is even possible > the direct path could be obsoleted over the long term as step 2 becomes > more and more streamlined. > > ...
Jens, if I understood correctly, basically you're suggesting having the OpenGL state machine on the X server process context, and therefore the GL drivers too, and most of the data (textures, display lists). So there would be no layering between the DMA buffer construction and its submition - as boths things would be carried by the GL drivers. This means that we would have a single driver model instead of 3. But the GLX protocol isn't good for this, is it? Hence the need for shared memory for big data. Am I getting the right picture, or am I way off..? José Fonseca PS: It would be nice to discuss these issues in tonight's meeting. _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel