[REVIEW] DMX2 DIX merge

Alex Deucher alexdeucher at gmail.com
Thu Jan 7 08:09:12 PST 2010


On Thu, Jan 7, 2010 at 11:02 AM, Keith Packard <keithp at keithp.com> wrote:
> On Thu, 07 Jan 2010 10:04:45 -0500, Adam Jackson <ajax at nwnk.net> wrote:
>
>> It doesn't _have_ to work that way, but that's what it looks like DMX2
>> does.
>
> Ok, so just something we should work on fixing then.
>
>> If we consider a non-transformative, non-GL compositor, then I think
>> it's pretty straightforward.  Pixmaps created relative to the root
>> window start life in system memory, and can then be lazily bound
>> whichever ScreenRec ends up needing them as a source image.
>
> I'm sure we could come up with magic to try and get the pixmaps to vram
> sooner, but guessing wrong means pulling data back from vram. Something
> as simple as a per-client hint might be OK though, where you guess that
> a pixmap will be used on the same card(s) as a recent window. Lots of
> possibilities here, we don't have to solve the problem right away at least.
>
>> Transformation makes this one degree harder; a RWP that fits on GPU 0 in
>> the X geometry may be displayed on GPU 1, so now it needs to cross
>> memory domains.  Not great.  Do you just evict the pixmap to host memory
>> for good when that happens?
>
> I'd like to avoid ever using host memory and instead manage objects that
> need to be used on multiple cards by replicating pixmaps, and having
> some way to de-replicate at appropriate times. That would avoid needing
> to try and make host memory shared across cards...
>
>> GL makes it one degree harder still, because now you have to figure out
>> how to implement TFP.  For indirect GLX, the server has to bind the
>> pixmap (on some GPU) to potentially any number of DRI textures on
>> arbitrary numbers of GPUs.  You can be lazy about it, of course, but if
>> you do so you're making the inherent TFP sync problems even worse;
>> presumably we want a TFP texture to have the same texels on all the GPUs
>> it's used on...
>
> At least with indirect GL it's possible to make it all work with a
> suitably large hammer. I don't even know if AIGLX ever worked under
> Xinerama though. Did it?
>
>> I'm not even really sure what "direct rendered GLX" means in the context
>> of Xinerama.  I can see a plausible definition if all the GPUs are of
>> similar enough programming family that they can be driven by the same
>> DRI driver logic (all R800, for example), but if you're heterogeneous...
>> Direct rendered TFP would still require getting the GEM handle for the
>> pixmap to cross DRM device boundaries, even if you're homogeneous.
>
> Yeah, I'd say that we should try to get AIGLX working and then consider
> whether we could make homogeneous direct rendering work sometime later.

Couldn't we use glxproxy in the short term?  IIRC, it worked under dmx.

Alex


More information about the xorg-devel mailing list