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.
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.
> > 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.
b) In the 3DDRP (aplpication's user process) everything except XLib has either
direct or indirect access to the DRM Lib in the 3DDRP.
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.
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?
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.
Liam
----
it depends
N2S:
hw / sw accel. * (in)direct Rendering explane dif's.
_______________________________________________________________
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
