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.
----- Original Message ----
> From: Younes M <younes.m@...>
> To: dri-devel@...
> 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.
> Dri-devel mailing list