José Fonseca wrote:
>
> 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..?
Sorry, we covered a lot of things at once. Let me simplify...
1) We loosen security requirements for 3D drivers. This will allow far
less data copying, memory mapping/unmapping and system calls. Many
modern graphics chips can have their data managed completely in a user
space AGP ring buffer removing the need to call the kernel module at
all. The primary limitation that has kept us from persuing these
implementations so far have been security holes with AGP blits.
2) We implement HW acclerated indirect rendering for those processes
that don't have the permissions to use the new optimized drivers. Most
of the fancy architecture discusssions we had here are related to making
indirect rendering faster...and could be done as a follow on to basic HW
accelerated indirect rendering. The first and easiest way to implement
this is to make the X server use our direct rendering drivers.
I'm not really advocating going to a different model at all. Rather,
I'm just advocating moving more of the kernel side validation we're
currently doing, back into the 3D driver.
> PS: It would be nice to discuss these issues in tonight's meeting.
I guess that's starting now.
It's at irc.openproject.net #dri-devel for those interested in joing
in...
-- /\
Jens Owen / \/\ _
[EMAIL PROTECTED] / \ \ \ Steamboat Springs, Colorado
_______________________________________________________________
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
