On Thu, 10 Jun 2010 19:50:29 -0700, Jamey Sharp <[email protected]> wrote:
> I guess I'd need to run the test suite on a Xinerama server, and > probably need to ensure that windows that XTS creates span two > screens. Or something? I'm not sure how to even hit these cases, > especially in XTS. Yeah. It will be easier to arrange if you've got a tiny screen on each card... > In my opinion it would be better to arrange that GC ops never need to > unwrap ValidateGC than to continue with the current double-unwrapping > mess. With a more structured graphics operation layering architecture, each layer could manipulate their presence in the chain without needing to do that in the middle of a call sequence. > I think it's easy enough to ensure that every ValidateGC call > inside a GC op is on a scratch GC, although setting up the scratch GC > efficiently might be harder. I have part of a patch written that does > this, just copying all elements of the real GC into the scratch GC. No, as you can see, many of the layers just need to see the operation as it passes along, potentially modifying some of the parameters. Creating a scratch GC for that purpose doesn't seem sensible. Besides, a scratch GC created there will have the whole rendering stack to drill through, it won't be operating on top of the underlying layer at all. > The current scheme is crazy. We call ValidateGC because we want the > ops updated for whatever is suitable for our hardware--but in the > cases where double-unwrapping matters, AFAICT we're guaranteed to get > an mi version of all ops. That's surely not desirable, and I'm not > even convinced it's correct! I don't understand this at all. > One reason I'd like to move ValidateGC in particular to the ScreenRec > is that several CreateGC wrappers exist solely to set up a ValidateGC > wrapper, and those always use the same implementation of ValidateGC > regardless of any parameters in the GC. If you can set the ValidateGC > wrapper on the screen in the first place, the currently piles of code > just look silly. Frankly, I wouldn't mind asserting that each rendering layer never change the functions that implement operations within that layer. I think I've managed that in the layers I've written, like kaa (-> exa -> uxa) and fb. Wrapping any other layers in suitable run-time switches should be quite easy. The whole notion of pre-computing the appropriate rendering function just doesn't make a lot of sense given the overhead of running a single protocol request through our current rendering stack. Once you have this invariant property, you can bundle all of the operations into a single structure and place a linked list of those in the screen rec. You don't 'unwrap', you just pass the pointer along with the operation so that the wrapping functions just follow that chain as they call down the stack. > The other reason is I'm hoping to kill the PanoramiXRes structure and > have a single GC/Drawable/Colormap/etc. object allocated for each > protocol-visible XID. I don't know exactly what that would look like > (I can sketch pieces if anyone's curious), but I think it's easier to > get there with as little screen-dependent data in each object as > possible. Yup, the GC should just contain the protocol data from the application, and if we have multiple video cards, then they can each place private data on the same GC in separate storage. > I guess GCOps are worth keeping inside the GC, assuming > somebody cares about hardware acceleration for those ops, but I can't > see any reason for GCFuncs to live there. I disagree -- run-time selection of the appropriate function is less error-prone and easier to develop, with little or no performance impact. > I can send along my patch to move DestroyGC to ScreenRec if you'd like > to base a callback-chain patch on that. I'll be busy working on 1.9 through august at this point, but I encourage you to keep poking at these ideas in the meantime. -- [email protected]
pgpL7ZbJWGdUm.pgp
Description: PGP signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
