Smitty wrote:
>
> Jens
>
> > These are good questions. I'm copying dri-devel so they can reach a
> > wider audience.
> My diagrams when finished are going to have an explanation of the paths
> from the Prog's to the Hardware to promote understanding.
>
> > > > Well, this is really I higher level diagram for non-technical types. We
> > > > are just showing that 3D data bypasses the typical X protocol path.
> > > OK but you'll note that the direct rendering program also uses X protocol
> > > path just (but for 2D not 3D).
> >
> > Right. Xlib commands still go the normal, indirect, route.
> Xlib being 2D commands. I will be asking about the paths within the Apps
> (well the 3D Direct rendering at least).
>
> It appears that DRILib (& by extension OpenGL Library), GLX Lib, & Xlib
> all send stuff (2D stuff only?) to Protocol encode, but te poster I am
> working from needs to be updated with your comments and your ascii art
> & mine (below). Once that is done I'lll ask about that.
>
> > Then you might want to study the basic X Server internals. Look at the
> > xc/programs/Xserver/dix directory. It contains interesting files like
> > dispatch.c which parses the standard 2D commands. There is also GLX
> > dispatch handling in the GLX module xc/programs/Xserver/GL/glx
> Anything ending in .c is not so useful as I have never done C.
> Had a look -pretty colours <g>.
>
> I am happy with the level of detail that the data_flow.png has reached
> it is somewhat more than data_flow.jpg but not too much. It is for the
> lay person to look at and understand, if I can understand it without
> knowing C then when they look at it and read the covering text they
> should understand it too.
>
> > That's right 2D and 3D indirect use the same transport stream between
> > the client and the server. It's not until the protocol is decoded in
> > the X Server and handed off to the GLX decode that they diverge.
> Ahh this confirms what I thought at the bottom of this email (I read it
> backwards).
>
> > > > DRI Resource Mgmt commands flow:
> > > >
> > > > Protocol Decode
> > > > DRI
> > > > DRM Driver (Not show, but should be where Kernel DRI Module is)
> > > Confused.
> > > DRI what?
> >
> > For direct rendering we don't send 3D data to the X Server. However, we
> > still need to work with the X Server to synchronize and manage
> > resources.
> So for the first prog. X Transport has 2D commands and resource management.
>
> > If you look at xc/programs/Xserver/GL/dri you will see the
> > DRI extension's dispatch loop. A good example here is registering a
> > window as being used by a direct rendering 3D driver. Doing this
> > notifies the X Server that the 3D driver needs to know if the window is
> > moved or it's clip list changes.
> I've had a quick look but I'll take your word on it.
>
> > > Kernel DRI Module dont see that, what colour is it?
> >
> > It is the light red box marked "DRI Module" inside the large blue box
> > marked "Kernel". Resource sharing information is passed down to this
> > module from both the X Server and the 3D client driver.
> Ah yes my ascii art below, I thought so but I was under the impression
> that we were in the X Server still.
>
> > The DRM library
> > is used to communicate with this module. It can be found at
> > xc/programs/Xserver/hw/xfree86/os-support
> Ah yes I can see DRMLib both in the prog. and in the X Server
> communicating with the Kernel.
>
> > > Where does it go from there?
> >
> > Since this usually isn't actual 3D data (triangles, state changes,
> > etc). Propegating the resource management information across the 3D
> > client, the X Server and the kernel level driver is usually enough.
> That question is now defunct knowin what you were refering to no longer confused.
>
> But then what is the MMIO & DMA to the Graphics Hardware doing,
> is this resource management?
Very little resource management at this level. It's the primary path
for passing the actual rendering commands to the hardware. Some drivers
use Memory Mapped Input Output (MMIO) exclusively. Others utilize
Direct Memory Access transfers initiated by the graphics hardware. Some
drivers utilize both methods.
> > Sew buttons :-) Just trying to give an accurate view of the current
> > module layout.
> Not: So what? (generaly rude)
> So as in: Like so? (my diagram below -not rude)
> >
> > > +------------------+
> > > | +--------+|
> > > | KERNEL | DRM ||
> > > | | Driver ||
> > > | +-|----|-+|
> > > +----------|----|--+
> > > | |
> > > MMIO DMA
> > > | |
> > > V V
> > > +-------------------+
> > > | Graphics Hardware |
> > > +-------------------+
> > >
> > > Is the DRM Driver Red?
> >
> > Yes, should be dark red.
>
> > I should have said "Dark Red" for Device Specific Modules. I honestly
> > don't remember what the light red boxes are suppossed to represent.
> OK
>
> > This is essentially correct, with one clarification. You'll notice in
> > my diagram for data_flow.jpg, there is only one "transport" arrow for
> > the indirect rendering application to talk to the X Server. This is
> > because the 3D commands share the same protocol stream that is
> > established for 2D.
> Understood, a branch occurs within Protocl Decode with the 2D going
> to DIX & then XAA and the 3D going to GLX & then to Mesa and then both
> paths merge in the DDX Driver.
That's correct. This path would change if/when we support hardware
accelerated *indirect* rendering.
> > Also, there is only one arrow at the bottom of the
> > X Server where 2D data flows to the hardware. That's because the server
> > is single threaded and handles one request at a time.
> I'm not a/on Xpert but that was going to be one of my questions.
>
> Thanks I think I've got it now (updated version attached).
>
> I'll make it more clear in the final version using different sized arrows
> and colors etc.
>
> But onto the control_poster now, expect a .png of that sometime.
I see it. I'll respond to that next.
-- /\
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
