Otherwise we end up cloning the scanout only to leave it dangling if the
client copies the from the front-buffer and then writes to it.
Reported-by: Nick Bowler <nbowler@draconx.ca>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64675
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Once cloned, we do not want to use inplace operations and instead force
a copy. However, if we do not relinquish the hints when copying across
the bo, then those hints become stale and lead to corruption.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Since the extended use of move_area_to_gpu for partial migration of
render sources, we exposed the lack of handling of upload caches along
that path.
Reported-by: Zdenek Kabelac <zkabelac@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Only upload the portion of the pixmap being used for this rendering
operation, as outside of that may remain undefined and to be written by
the client before a future operation.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we skip the migration, we need to avoid using the unitialiased
region. There is no bad consequence as both branches of the if are
no-ops, but it does silence the static checkers and should make the
predicate cheaper.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Probe for i830_dri.so and, if it exists, use that driver in preference
to i915_dri.so for DRI (i.e. GL clients). This was suggested in the
context of distributions supplying i915g as the main DRI driver for
gen3, in which case we need to provide a separate DRI driver for gen2.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we try to release the framebuffers whilst not DRM_MASTER, the
operation will fail and we will leak the buffers. So do not bother
during the normal expiration to clean the scanout cache if vt switched
away.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
sna_video_hwmc.c: In function 'create_context':
sna_video_hwmc.c:95: warning: assignment from incompatible pointer type
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
There is a workaround that says the first RENDER command following use of
the BLT should be a non-pipelined command. To be safe, emit a MI_FLUSH
before setting up the invariants.
Bugzilla: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1168066
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
One particular buffer type is quite cunning and simultaneously sets both
CPU/GPU as all damaged (the upload buffer) so be aware when making bold
assertions.
Reported-by: Jiri Slaby <jirislaby@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Each of the overlay, sprite and textured video can support XvMC
passthrough, so we need to setup an XvMC adaptor for each of our Xv
adaptors.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Whilst we are not DRM master, not only is another server in control of
the outputs and responding to the udev event, we ourselves cannot
change modes and just cause contention upon the DRM device. Instead
inform userspace of the change as soon as we are DRM master again and
back in control.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The passthrough is actually a generic, albeit private, mechanism that
anything can use to pass along a GEM handle for use with Xv.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The condition that we have a mapped GPU bo iff priv->cpu is only true if
we have a GPU bo at the time of using the CPU -- if we create the GPU bo
during move_to_gpu, then that assertion is bogus.
Reported-by: Jiri Slaby <jirislaby@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Since we started discarding the flush flags on cached bo (in order to
prevent DRI flush states leaking), we failed to preserve the flush flag
for large bo (which uses it to keep batches trim and other hints).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
My overzealous reading of the bspec lead me to the conclusion that the
MI_LOAD_SCANLINES command was only available on the blitter ring. This
is false, thankfully, and allows us to do vsync'ed Xv.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
According to the opengl glx_sync_control spec, the Unadjusted System Time
(or UST) is a 64-bit monotonically increasing counter that is available
throughout the system:
http://www.opengl.org/registry/specs/OML/glx_sync_control.txt
Therefore, sending 0, even in this corner case, is out of spec. However,
we cannot just return FALSE here as that triggers a BadDrawable error to
be sent, and as is often the case mishandled, to the client. This results
in a certain compositor terminating, for example.
As an alternative we can use the monotonic system timestamp which in
theory should also be monotonic with the previous and subsequent vblank
times.
Based on a patch by Daniel Kurtz.
Reported-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When we are replacing a bo with fresh data, we can drop pending
operations to it and thereby reduce the complexity of the replacement.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson