internal screen concept

Dave Airlie airlied at gmail.com
Mon Mar 21 17:27:13 PDT 2011


So I've been trying to work out how to add GPU offload support to the
X server in some sort of useful fashion.

Currently the prototype, just creates two screens, one for each GPU,
and does some DRI2 magic to make the front buffer shared.

However this leads to a lot of uglies on the protocol end, since you
have 2 protocol screens, and lots of things start trying to do bad
things with them.

But we really do need DIX level screens as EXA and DRI2 rely on having
one, and we need EXA/DRI2 for the offload driver to work.

My first solution involves throwing the XFree86 DDX out and starting
again, but this didn't seem like it would be acceptable.

So I tried two methods quickly,

a) add concept of internal screen to ScreenRec and ScrnInfoRec, add
new value  screenInfo.numProtocolScreens, add lots
of if (screenInfo.screens[i].internalScreen) continue to places where
the protocol meets the screen info struct, and we want to skip
internal screens.
Also return numProtocolScreens for number roots etc., add a call into
the DIX to set a screen to internal state.

b) split screenInfo.screens into screenInfo.screens and
screenInfo.internalScreens, add a new AddInternalScreen interface, the
XFree86 DDX
then picks one or the other. This ran into the problem that the
XFree86 DDX mostly assume that the index into screenInfo.numScreens is
equal
to the index into xf86Screens, and that knowledge is baked into the
code in lots of places. Also lots of code gets called from ScreenInit,
before pScrn->pScreen is setup, so we can't always just blindly
derference that value.

Now I could go and split xf86Screens as well, but that gets into the
rewriting territory where I'd need to add a new probe ABI, since the
code
works by calling DDX->driver Probe->DDX PCI code->DDX add screen,
later on DIX add screen.

Anyways before I waste another few days I thought I'd throw it out
there to see if anyone else has an idea or clue.

Dave.


More information about the xorg-devel mailing list