Smitty wrote:
>
> Howzit Jens?
>
> 3 Parts to this email.
>
> 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...
> 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 :-)
> > > I've attached the latest WIP of control_flow.png to help show this.
> > I did *not* receive an attachment.
> But you've seen it now...
>
> > > RM = Resource Management
> > > or = 1 of these 2 paths are followed
> > > & = both of these 2 paths are followed
> > > 2D = 2D commands & data
> > > 3D = 3D commands & data
> > >
> > > lines in columns indicate individual paths while,
> > > lines not in columns are agregations of paths.
> > >
> > > eg's in my bit of exploded ascii art and the X Server.
> > >
> > > This becomes somewhat of an issue when you have multiple line entering
> > > and leaving a box, so if the lines should match up and don't or vice
> > > versa - let me know.
> >
> > I'll probably understand this question better after I see your WIP.
> Yup it's all part of the same question.
>
> 3.)
> > > DRMLib whats the differnce between the one in the X Server and the
> > > one in the 3DDRP? They both talk to Kernel & SAREA (SHM & IOCTL).
> >
> > Functionally they are identical, i.e. the same source code. The only
> > distinction, and it's not critical to the diagram, is the DRMLib used in
> > the X Server needs to be a dynamically loaded X module. The one used by
> > the 3D client driver is statically linked into the 3D client driver's
> > shared library.
> >
> > Hmmm, thinking about this some more, I wonder if the staticly linked
> > DRMLib will be a problem if we ever try to support direct rendering to
> > multiple heads. If each head required a different driver, then the drm
> > symbols would colide. Sorry, just thinking out loud...
>
> Assumptions:
>
> a) The DRM Lib in the X Server gets its inputs from the RM path which comes
> via the X Transport between it and the 3DDRP.
right.
> b) In the 3DDRP (aplpication's user process) everything except XLib has either
> direct or indirect access to the DRM Lib in the 3DDRP.
right.
> c) Now by looking at XLib in the 2D only Program and in the 3DIRP it is not
> concerned with the RM path / the DRM Lib in the X Server.
right.
> Would it not be better (simpler / faster) to do resource management via the
> DRM Lib in the 3DDRP than via the DRM Lib in the X Server?
We need access to X Server internal data structures that the kernel
doesn't have.
> Whether it would or whether it would not and why would be useful, I think it
> is a reasonable question even though it has assumptions.
I'll take you back to the e-mails I sent earlier on this thread.
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.
-- /\
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?source=osdntextlink
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
