New shatter development tree

Colin Guthrie gmane at
Tue Nov 11 02:53:53 PST 2008

Adam Jackson wrote:
> The primary motivation is working around coordinate limits, yes.  The
> idea is that if you have two CRTCs that can each scan 2k wide, right now
> that implies a total width limit of 2k, because we force them both to
> point to the same physically contiguous allocation.  If you could
> somehow break apart the root window's pixmap, such that rendering to the
> left half went to one piece and rendering to the right half went to the
> other, then you could point one CRTC at each and be happy.
> Thus, "shatter", to break into pieces (which I'll jargonize as "shards"
> from here on in).
> Internally to the server we more or less assume that all pixmaps (and by
> extension, all windows) have a single allocation of pixels behind them.
> You can fix this if you're careful, by creating some pixmaps with _no_
> direct storage, attaching a bunch of shard pixmaps to them, and
> intercepting rendering to the virtual pixmap and re-dispatching it
> against the shards, translating as appropriate.  This works best when
> you enforce a strict separation in your internal data structures between
> the thing you're drawing on and the way in which you're drawing -
> between the Drawable and the GC - because you need the ability to create
> ephemeral rendering contexts but long-lived surfaces.  This requires a
> bit of contortion to work in the face of Render and Xv, but it looks
> doable.  Finally, extending this to DRI requires also shattering the
> back buffer allocations and replaying display lists against each.  Right
> now I'm just working on the 2d parts, but 3d is definitely in the plan.
> This is all not dissimilar to the Xinerama problem, where you have
> multiple GPUs that you want to dispatch rendering against.  Eventually I
> do want to see the xinerama and shatter machinery merged, probably by
> having one super ScreenRec that dispatches its shard rendering against
> other ScreenRecs (as opposed to, say, RANDR shattering, where the shards
> and the virtual are attached to the same ScreenRec).  So there's some
> application to the switchable GPU machines too, since in principle the
> xinerama layer need not dispatch against _both_ shards.
> More technical details:

Sounds great!! Good luck. I'll be a happy tester here :)



Colin Guthrie

Day Job:
   Tribalogic Limited []
Open Source:
   Mandriva Linux Contributor []
   PulseAudio Hacker []
   Trac Hacker []

More information about the xorg mailing list