Dave Airlie airl...@gmail.com writes:
On Fri, Oct 5, 2012 at 12:53 PM, Keith Packard kei...@keithp.com wrote:
Maybe I should just all in and try and submit the full-on impedance
layer it just struck me it might be easier to start with something
that just pushes drawables as far down as
On Fri, Oct 5, 2012 at 12:53 PM, Keith Packard kei...@keithp.com wrote:
Dave Airlie airl...@gmail.com writes:
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.
Yeah, getting to the point
Dave Airlie airl...@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?
So I'm left with two ideas on how to fix this
On Fri, Oct 5, 2012 at 4:40 PM, Keith Packard kei...@keithp.com wrote:
Dave Airlie airl...@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
Dave Airlie airl...@gmail.com writes:
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.
Yeah, getting to the point where the only GPU visible objects are
pixmaps would be great; that's the
So I've been looking into gpu switching and having all driver screens
be GPU screens under a protocol screen.
Now the biggest problem I've hit so far is that we all use
pDrawable-pScreen to figure out what screen we are, however I'd like
to abstract things so that you can get drawables from a