[EMAIL PROTECTED] wrote:
>
> Hello Jens:
>
> I am working on porting an OpenGL driver from windows to Linux.
> I find your message (03 Jun.) in dri-devel is great helpful to me.
> But I still have some questions:
>
> >DRI Resource Mgmt commands flow:
> > Protocol Decode
> > DRI
> > DRM Driver (Not show, but should be where Kernel DRI Module is)
>
> 1. Your said DRI can not do direct rendering by GLX pass, so
> through Xserver we can not do direct rendering now. Then,
> How we show add dri support to DDX driver? And what can
> the DRI extension and the DRI aware DDX driver do for 3D
> rendering now?
The DRI module in the X Server (xc/programs/Xserver/GL/dri/dri.c) and
the dri components of the DDX drivers (usually found in
xc/programs/Xserver/hw/xfree86/drivers/<driver_name>/<chipset_name>_dri.c
are for resource management.
Here's an example:
When the 3D client knows which window it will be doing direct
rendering to, it calls DRICreateDrawable, so the X Server knows which
window to track for the client. The client then calls
DRIGetDrawableInfo to get the initial window offset and cliplist. Then,
whenever the Xserver modifies the window cliplist or location it bumps a
clipstamp in shared memory which notifies the 3D client that it needs to
get new information. When the 3D client is ready to render again, it
will first call DRIGetDrawableInfo, again, to get the updated cliplist
and window offset.
The point of this example, is that the 3D client bypasses the X Server
for transfering 3D commands to the hardware, but it still includes the X
Server for managing resources (tracking window clip and location in this
example).
Check out the DRI X Server module source for a more complete list of
resource information that flows thrue the X Server.
> >DRI Resource Mgmt commands flow:
> > Protocol Decode
> > DRI
> > DRM Driver (Not show, but should be where Kernel DRI Module is)
> 2. Your had explain the DRI resource management commands flow in Xserver,
> Could your explain the flow in Xclient?
The client side driver can utilize the resource management wherever it
needs. I find that most of the resource calls are associated with
context management, probably because we don't know which drawable we'll
use until a context is bound with a drawable. Consequently, there isn't
a single place in the driver where you will find all resource
management. However, you can search the client side GLX code and client
side 3D drivers for DRI and DRM calls to catch the various places
resource management is done.
Here's a continuation of the window tracking example above specific to
the Mesa based Radeon driver:
The GLX client side module's glxMakeContextCurrent ends up calling
DRICreateDrawable to notify the X Server a window needs to be tracked.
When the radeon driver notices another context has accessed the
hardware, it ends up calling radeonGetLock, which in turn eventually
calls both the Kernel level DRM module and the X Server's DRI module.
The DRM entry point is drmGetLock to get the hardware lock from the
kernel (after another context has held the lock). The DRI entry point
is XF86DRIGetDrawableInfo to get the updated window offset and cliplist
information from the X Server.
> Thank you very much for your kind help!
Yue, we wish you the best on your port.
Regards,
Jens
-- /\
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
