splitting drawable and screens

[Dave Airlie]

On Fri, Oct 5, 2012 at 4:40 PM, Keith Packard <keithp at keithp.com> wrote:
> Dave Airlie <airlied at gmail.com> 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.