Keith Packard wrote:
> We had a big display-list vs immediate-mode war around 1990 and immediate
> mode won. It's just a lot easier to send the whole frame worth of
> polygons each time than to try an edit display lists. Of course, this
> particular battle was framed by the "scientific visualization" trend of
> that era where each frame was generated from a completely new set of data.
> In that context, stored mode graphics lose pretty badly.
If you're referring to the OpenGL vs PEX war, there was more than
technical issues weighing in...there was the reality that Microsoft
*was* willing to support OpenGL. That made OpenGL a better cross
platform choice. Kind of ironic, but predictable that Microsoft is now
trying to sink OpenGL...but that's a thread for another group.
> However, given our experience with shared memory transport for images, and
> given the tremendous differential between CPU and bus speeds these days, it
> might make some sense to revisit the current 3D architecture. A system
> where the shared memory commands are validated by a user-level X server and
> passed to the graphics engine with only a small kernel level helper for DMA
> would allow for a greater possible level of security than the current DRI
> model does today.
I wouldn't say we're laking in security today, we've in good shape now.
> This would also provide for accelerated 3D graphics for remote
> applications, something that DRI doesn't support today, and which would
> take some significant work to enable.
In relative scale, getting HW acceleration for direct rendering is
*much* smaller than the more aggressive architectural changes we're
discussing. Let's just keep that in perspective. It might be a less
aggressive first step to get the missing module(s) for HW acclerated
indirect rendering going, then move to these types of more aggressive
indirect methods.
> I would hope that it could also
> provide a significantly easier configuration environment; getting 3D
> running with the DRI is still a significant feat for the average Linux
> user.
Hmm. I would have agreed a year ago, but most of the distributions
appear to have a good handle on making this just happen...when there is
driver support.
> The question is whether this would impact performance at all; we're
> talking a process<->process context switch instead of process<->kernel
> for each chunk of data. However, we'd eliminate the current DRI overhead
> when running multiple 3D applications, and we'd be able to take better
> advantage of SMP systems.
>
> One trick would be to have the X server avoid
> reading much of the command buffer; much of that would make SMP
> performance significantly worse.
The performance path I'd like to push hardest in the short term in
direct rendering completely within the user space context. Your
suggestions for optimizing an indirect path are great. That path would
become much more critical than today as general purpose processes that
would no longer have access to the *faster* direct path.
-- /\
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
