On Fri, Oct 5, 2012 at 4:40 PM, Keith Packard <[email protected]> wrote: > Dave Airlie <[email protected]> writes: > >> However this means that pDrawable->pScreen will be a protocol >> screen and the drivers will want to access the GPU screen. > > Hrm. Sure would be nice if the drawables visible to the driver were also > GPU objects?
I considered this, but really drawables are generally a protocol object, in a lot of cases a Window which really has no interesting properties to a GPU. So while I'd like to keep dual copies of these like I plan for GCs and Pictures, I don't think it really makes sense, pixmaps are all we really care about. Its further complicated by the fact that driver accel archs create their own objects and we want the shared code to just work in both cases (and keep an interface for old style pre-gpu capable drivers). So since ajax has convinced me for GCs and Pictures that I really want per-GPU versions, I was think of adding a pScreen to Picture and to a few interfaces like GetImage need changes, but much reduced. >> So I'm left with two ideas on how to fix this (one ugly, one tedious): > >> a) introduce pDrawable->pCurrentGPU which is a screen ptr for the >> currently rendering gpu on the drawable, the driver then uses this to >> get its current screenptr back, instead of using pDrawable->pScreen. > > Could pScreen be the GPU object and we fix the rest of the server to use > pProtocolScreen instead? Would that be easier to transition in the > future to GPU-specific drawables objects (or, ideally, only pixmaps)? Yeah I started considering that locally and it mightn't suck too much. It would probably mean we need to decide where in the code shuold be accessing pScreen and where shuold be accessing pProtocolScreen, I'm guessing it'll be somewhere in damage where I get bitten. > >> b) add pScreen to all the driver facing APIs, (GCOps, Picture ops, >> lots of ScreenRec). > > Yuck. Yeah 100% agree on yuck and don't think its an option anymore. Dave. _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
