> > 1.) MK II: > > _ > > \ > > +-----------------------------------------+ | > > | X11/OpenGL Based Application | | > > | (Using 3D Direct Rendering) | | > > +-----------------------------------------+ | > > | | | > > V V | > > +----------------------+ +------------+ | > > | OpenGL Library | | XLib | | > > +----------------------+ +------------+ | > > | | | | | > > | | V | | Application > > | | +---------+ | |-- User > > | | | GLXLib | | | Process > > | | +---------+ | | > > V | | | | | > > +-------------+ V V | | | > > | OpenGL | +--------+ | | | > > | Renderer | | DRILib | | | | > > +-------------+ +--------+ | | | > > | | | | | | | > > | V V V V V | > > | +---------+ +-----------------+ | > > | | DRM Lib | | Protocol Encode | | > > | +---------+ +-----------------+ | > > | | | | _/ > > V V V V > > MMIO IOCTL SHM X Transport > > > > > > > I would say in the most common case (single thread, single 3D context) > > > there is only one arrow between the application and a combined > > > Xlib/OpenGL box. This single arrow can be thought of as the primary > > > system:display.screen connection, to use X11 DISPLAY semanitics. > > Which is the equivilent to the top two arrows in this diagram. > > OpenGL Lib & XLib are just shown seperately. > > Okay, but this is another example of where the number of arrows is just > plain confusing... ^^^^^^^^ nice play on words. First I want to get all the facts then I'll make it less plain and less confusing.
It'll also be less confusing when I implement the alignment i was carry on about earlier. > > 2.) > > > > One thing that I would like to be able to show is, when you have one line > > > > going into a box and two lines coming from it, is a branch occuring or is > > > > it an either or situation. ie a choice is made and only one path is taken. > > > > > > It depends. There are a large number of actual entry points in each of > > > this libraries. Some entry points may never pass data along. Others > > > may use one or both of the paths. > > Doesn't it just. > > But it worked out ok for the X Server internals so I'd like to do it here. > > The X Server case is a very cut and try case, and even it isn't really > implemented that way. All I'm trying to convey here is arrows can't > tell the whole story, so we can't put an exact definition on what an > arrow really means. Consequently, I can't give you detailed and precise > feedback on how to make the arrows and boxes should look. > > So, use your judgement as to which looks prettier :-) It's an abstraction, it'll never mirror reality perfectly. I'm going to be doing some reading, if that resolves it I wont have to bother you about this again 3.) > We need access to X Server internal data structures that the kernel > doesn't have. So the X Server cant handle its resources independantly, it must co-operate / co-ordinate with DRI? ie X Server talks to kernel on its own, what does it do when there is no DRI? > I believe the resource management example we looked at was window offset > and cliplist. Window cliplists are controlled and updated by the X > Server. Every time a window is moved, the X Server recomputes clip > lists for all affected windows. The 3DDRP has to get this information > from the X Server somehow. OK this could be a gross oversimplification but if I understand correctly there are two RM paths, one for 3D (3DDRP DRM Lib) and one one for 2D (X Server DRM Lib). Liam ---- it depends _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
