| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
If the source is only being exported for reading, we can skip adding it
to the flush list only to perform a no-op.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
If we export a surface over DRI2/DRI3, we have to use explicit tiling
via the kernel. :(
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
We use the flags for deciding how to operate on the GPU bo, so we should
set them!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
The decision has been made that DRI3/intel shall continue with DRI2-style
implicit fencing for synchronisation between X and clients using pixmaps
as texture sources. (The other way around uses explicit fencing!)
References: https://bugs.freedesktop.org/show_bug.cgi?id=81551
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Beware the barbarians at the gate, who invade and steal your ScrnInfoPtr
and its Entity from underneath you. In some configurations, we lose
access to the struct intel_device stored on the Entity after
initialisation, causing havoc. Workaround this by storing the
intel_device that we open in our driverPrivate.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
It is far easily to pass the PixmapPtr into the function and have it
pluck out the width and height than do so in all callers.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
