[g200-dev]XFree86 3.9.15 and the DRI (fwd)

Tomasz Kłoczko kloczek w rudy.mif.pg.gda.pl
Pon, 19 Lip 1999, 10:04:43 CEST


Chyba będzie troche osób zainteresowanych tym listem więc robię fwd.

---------- Forwarded message ----------
Date: Sun, 18 Jul 1999 23:40:33 -0400 (EDT)
From: Kevin E. Martin <kevin w precisioninsight.com>
To: g200-dev w lists.openprojects.net
Subject: [g200-dev]XFree86 3.9.15 and the DRI

Very shortly a source code release of the pre-4.0 XFree86 development
tree will be released to the public for testing.  It will be called
3.9.15 and is considered a "work in progress" snapshot.  It has many new
features and enhancements.  Included among these new features is the DRI
(Direct Rendering Infrastructure) which is explained in more detail
below.  For more information on the XFree86 release plans, see:

    http://www.xfree86.org/releaseplans.html

Jeff Hartmann and Stephen Crowley are already working on porting the
G200 work to the DRI, and with this source release, I encourage others
to join the effort.  Please send e-mail to the list if you are
interested in helping.

To help with this effort, PI has allowed me to spend some of my work
time advising and helping Jeff, Stephen and others who are interested.
To get the ball rolling, several people have asked for an overview of
the DRI and how it works, so I'll begin with these.  In the next one,
I'll describe what is needed on the X server side to initialize the DRI
and kernel drivers.

Kevin

=====================================================================

Overview
--------

Before beginning the overview, there are other documents that can help
explain what Direct Rendering is and why it is a Good Thing[tm].  For a
list of the documents that we have made available see our web site:

    http://www.precisioninsight.com/piinsights.html

In the first document, the high-level design document we have links to
several reference papers from SGI regarding direct rendering.  I highly
recommend that you review these.

1. The basic components

The DRI is an infrastructure to allow multiple 3D clients to direct
render to the graphics device.  There are three main parts of the
design: the direct rendering client, the X server and a kernel module.

The basic idea is that for the client to render at full speed, it needs
to be able to send graphics commands directly from it's address space to
the graphics device (via DMA buffers and/or MMIO).  It also needs to
have direct access to the frame buffer for software fallbacks, which
implement paths that are not directly handled by the graphics device.

The X server handles window management (e.g., window placement, moves,
resizes, etc.), graphics device initialization and DRI initialization.
It passes window information (e.g., its position, if it is obscured, if
it was recently moved or resized, etc.) to the client through a shared
memory segment called the SAREA.

The kernel module handles DMA buffer management, moderates synchronized
access to the graphics device, and enforces the DRI security policies.
Since the majority of the currently available 3D graphics devices use
DMA to transfer commands and/or textures to the screen, we based our
infrastructure on a DMA model (Note: the infrastructure was designed to
allow it to be easily extended for MMIO based devices).  The X server
tells the kernel module to allocate a certain number of DMA buffers of a
given size, and the kernel then manages these DMA buffers.  The kernel
module also dispatches the DMA buffers to the graphics device, receives
interrupts from the graphics device (e.g., for DMA completion), and
handles context switching between different streams of DMA buffers.

2. Steady-state behavior

After the graphics device, DRI and client have all been initialized, the
client has been authenticated to the kernel, and a window and graphics
context have been created and bound together, the client enters a steady
state.  The sequence of events that occur during normal steady state
operation for the client are as follows.  I assume that all rendering
request can be handled via DMA, and a DMA buffer has been requested from
the kernel and is available.

- As rendering requests are received by the direct-rendering device
  specific driver, they are translated into device-specific commands and
  placed into a DMA buffer.
- When a buffer is full, the kernel is notified (via an ioctl) that the
  DMA buffer is ready to be sent to the graphics device.
- The client requests an empty DMA buffer (or buffers) from the kernel,
  and once granted, the process starts again.

For the kernel, when it receives a DMA buffer from a client, it checks
to see if the graphics device is busy.  If it is idle, the kernel sends
the buffer to the graphics device; otherwise, the buffer is placed on a
queue (and will be sent to the graphics device once the graphics device
has space available for it).  Note: this scenario assumes that the
client's current GLXContext is the one that is currently instantiated in
the graphics device.  If it is not, then the kernel must switch from the
currently instantiated context to the client's current GLXContext by
saving the old state and restoring the client's state.  This happens via
a call to the X server or directly by the kernel module.

Unfortunately, not all rendering can be done via hardware accelerated
paths and when this happens, a software fallback is needed.  Usually,
the software fallback will either directly draw to the frame buffer or
access some MMIO registers.  During this time, the client needs two
things.  First, it needs exclusive access to the hardware.  This is
accomplished by grabbing the hardware device lock.  Second, it needs to
maintain sequentiality of the OpenGL commands.  For this to happen, all
the DMA buffers currently being processed by the graphics device, all
buffers in the kernel queues for the current context, and any partially
filled DMA buffers in the client need to be processed by the graphics
device, before the software fallback can begin.  This can be done by
sending any partially filled DMA buffer to the kernel, and then
requesting that the kernel process all of the buffers it has before
returning to the client.  After these two tasks are complete, the
software fallback routine then renders what it needs to.  Once it
completes, the hardware device lock is released and a new DMA buffer (or
buffers) are requested from the kernel (if necessary).

3. Initialization and Finalization

To keep the size of this message (relatively ;-) short, I'll save the
initialization and finalization discussion for other messages.

4. Source code

When the sources are released, you can find the DRI, GLX and Mesa source
code in several places:

  * xc/lib/GL -- the client-side sources
     .../dri  -- the device-independent client-side DRI extension
                 sources
     .../glx  -- the GLX extension protocol encoding routines (from SGI) 
     .../mesa -- Mesa sources (based on a very early snapshot of the
                 Mesa-3.1 CVS tree)
     .../mesa/src/drv -- place for hardware accel drivers

  * xc/programs/Xserver/GL -- the X server-side sources
     .../dri  -- the device-independent server-side DRI extension
                 sources
     .../glx  -- the GLX extension protocol decoding routines (from SGI) 
     .../mesa -- the server-side Mesa build tree (for software-only
                 indirect rendering)

  * xc/programs/Xserver/hw/xfree86/drivers
       -- the X server device dependent drivers (ddx drivers)

  * xc/programs/Xserver/hw/xfree86/os-support/linux/drm
       -- the kernel module for Linux

To demonstrate the capabilities of the DRI, we implemented a minimal 3D
driver for the GMX2000 (which is a very high level card that implements
most of OpenGL in hardware).  The sources for the client-side driver are
in xc/lib/GL/mesa/src/drv/gamma.  The sources for the device-dependent X
server-side driver are in xc/programs/Xserver/hw/xfree86/drivers/glint.

Since there are multiple devices that can/will support direct rendering,
there is a mechanism to dynamically load the device-dependent direct
rendering code.  Two examples are available: the gamma driver for the
GMX2000 and an example software-only driver based on Mesa.  The gamma
driver implements the subset of OpenGL required to run Quake 2.  The
software-only driver only implements XMesaSwapBuffers (see xmesa1.c in
.../mesa/src/X), but it is a good starting point for a direct rendering
driver based on Mesa.


In the next message, I'll go into more detail about initializing the X
server side of the DRI including the ddx driver and the kernel module.


_______________________________________________
G200-dev maillist  -  G200-dev w lists.openprojects.net
http://lists.openprojects.net/mailman/listinfo/g200-dev



Więcej informacji o liście dyskusyjnej pld-devel-pl