There are three components that you'll need:
- state tracker -- which is API dependent
- hw driver -- HW dependent (softpipe is an example), which implements the
p_context.h interface.
- winsys -- which is dependent on API, HW, OS, etc.
The winsys is basically the glue that holds it all together. The intention is
for it to be as small as possible and over time we'll improve the concept
help make it smaller still.
In Mesa/Gallium/DRI drivers, the winsys is the only component with an overall
view of the structure of the driver, all the other components see only one
aspect of it, but the Winsys is what puts all the pieces together, and provides
the glue/services code to make it all work.
At minimum, the winsys will implement the interface in p_winsys.h, which
provides surface/buffer management functions to both the state tracker and
hardware driver. In addition, the HW drivers each propose a command submission
interface which is specific to the particular piece of hardware. As the winsys
currently implements both these interfaces, it by definition becomes hardware
specific -- though internally there is usually a separation between these
pieces.
Regarding the AUB stuff in the Xlib winsys, yes you can ignore that. It's a
hack to get a simulator running without hardware - at some point I'll try and
restructure things to make that clearer.
What I'm guessing you want to know is how to break things down in your proposed
state tracker. The overriding principle is to put as little in the winsys as
possible. At first, it's clear that anything in p_winsys.h must be done in the
winsys, similarly for whatever functionality the hw driver requests in it's
backend interface - eg softpipe/sp_winsys.h.
Beyond that, the winsys needs to implement some sort of 'create_screen' and
'create_context' functionality, but would ideally hand off as much as possible
after that to shared code in the state tracker or HW driver.
What's missing to some extent from the gallium interfaces is a fully-developed
device/screen/global entity. Much of the work so far has been around the
per-context entity (pipe_context), but the per-screen component that does
surface management, etc, has been less well developed. That will change over
time, but for the moment there's more of it in the winsys than I'd like.
Keith
- Original Message
From: Younes M [EMAIL PROTECTED]
To: dri-devel@lists.sourceforge.net
Sent: Wednesday, April 16, 2008 6:47:48 PM
Subject: Writing a state tracker for Gallium3D/SoftPipe
I'm trying to get up and running writing a state tracker for libXvMC
using SoftPipe, but looking at the Mesa src a few things are unclear
to me.
Looking at root/src/gallium/winsys/xlib I can't quite figure out where
Mesa ends and where Gallium starts. It's my understanding that the
winsys creates the pipe_context that I need, but is there a generic X
winsys driver? The xm_* sources where softpipe_create() is eventually
called (in xm_winsys.c) look very tied to Mesa, even though they
appear to be in a generic directory, so do all state trackers have to
implement something similar to use SoftPipe? Is this also the case for
using hw drivers? Looking at the the aub src files and the dri
directory it looks like that stuff is tied to the hw and does not have
to be provided for each state tracker.
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
