Linus Torvalds wrote: > > On Mon, 27 May 2002, Jens Owen wrote: > >>This is an education for me, too. Thanks for the info. Any idea how >>heavy IOCTL's are on a P4? >> > > Much heavier. For some yet unexplained reason, a P4 takes about 1us to do > a simple system call. That's on a 1.8GHz system, so it basically implies > that a P4 takes 1800 cycles to do a "int 0x80 + iret", which is just > ludicrous. A 1.2Gz athlon does the same in 0.2us, ie around 250 cycles > (the 200+ cycles also matches a pentium reasonably well, so it's really > the P4 that stands out here).
This is remarkable. I thought things were getting better, not worse. ... > >>You bet--and the real issue we're constantly swimming up stream against >>is "security" in open source. Most hardware vendors design the hardware >>for closed source drivers and don't put many (or sometimes any) time >>into making sure their hardware is optimized for performance *and* >>security. >> > > I realize this, and I feel for you. It's nasty. > > I don't know what the answer is. It _might_ even be something like a > bi-modal system: > > - apps by default get the traditional GLX behaviour: the X server does > all the 3D for them. No DRI. > > - there is some mechanism to tell which apps are trusted, and trusted > apps get direct hw access and just aren't secure. > > I actually think that if the abstraction level is just high enough, DRI > shouldn't matter in theory. Shared memory areas with X for the high-level > data (to avoid the copies for things like the obviously huge texture > data). I like this because it offers a way out, although I would keep the direct, secure approach to 3d we currently have for the other clients. Indirect rendering is pretty painful... However: The applications that most people would want to 'trust' are things like quake or other closed source games, which makes the situation a little murkier. >>From a game standpoint, think "quake engine". The actual game doesn't need > to tell the GX engine everything over and over again all the time. It > tells it the basic stuff once, and then it just says "render me". You > don't need DRI for sending the "render me" command, you need DRI because > you send each vertex separately. You could view the static geometry of quake levels as a single display list and ask for the whole thing to be rendered each frame. However, the reality of the quake type games is anything but - huge amounts of effort have gone into the process of figuring out (as quickly as possible) what minimal amount of work can be done to render the visible portion of the level at each frame. Quake generates very dynamic data from quite a static environment in the name of performance... > In that kind of high-level abstraction, the X client-server model should > still work fine. In fact, it should work especially well on small-scale > SMP (which seems inevitable). Games are free to partition themselves in other ways that help smp but keep their ability for a tight binding with the display system -- for example the physics (rigid body simulation) subsytem is a big and growing consumer of cpu and is quite easily seperated out from the graphics engine. AI is also a target for its own thread. > Are people thinkin gabout the "next stage", when 2D just doesn't exist any > more except as a high-level abstraction on top of a 3D model? Where the X > server actually gets to render the world view, and the application doesn't > need to (or want to) know about things like level-of-detail? Yes, but there are a few steps between here and there, and there have been a few differences of opinion along the way. It would have been possible to get a lot of the X render extension via a client library emitting GL calls, for example. Keith _______________________________________________________________ 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
