In the Composite setup, if we are doing a DRI2 copy onto the front
buffer, we are fully cognizant that the copy will not go onto the
unredirected Windows of another Client. So we can preserve the shadow
CRTC mapping for those Clients, and prevent ping-ponging between CRTC
modes.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we have relaxed the pitch restriction between front/back buffers when
swapping, we need to make sure that any change is also reported back
along with the change in front/back names.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In case we receive quick successive calls to DRI2GetBuffers on the same
Window, we need to check that the private exists before dereferencing
it.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the Pixmap for a Window is changed (i.e. Composite
redirection/unredirection), we also need to decouple any associated DRI2
front buffer for the Pixmap (e.g. used for single CRTC flipping).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The crtc flip (for when the kernel can't do a pageflip) made the mistake
of setting the shadow buffer to the scanout - nullifying the effect of
the TearFree.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When we AddTraps to a low resolution bitmap, we need to fallback as we
don't wrap it with a GPU pixmap.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If Xinerama is enabled, than RandR12 will be silently disabled. Be
careful not to dereference the rrScrPiv when it doesn't exist.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87207
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Fixes regression from
commit 0aa2edbd29
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Wed Nov 5 11:56:20 2014 +0000
Remove defunct glamor support
where the wrong branch of pixmap exchange upon SwapBuffers was kept when
removing the glamor paths.
Reported-by: Rui Matos
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>
The bspec recommends preventing the hardware from going to sleep around
a WAIT_FOR_EVENT, and tells us to use disable sleep bit in PSMI control
to accomplish this.
References: https://bugs.freedesktop.org/show_bug.cgi?id=62373
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In ZaphodHeads, we may reuse the same select read flags and attempt to
read from a blocking drm fd multiple times. However, if we clear the
read flags after first exhausting the fd, we shouldn't then block on
subsequent heads.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
For very large scale factors, it is possible for the current calculation
to underflow and try negative tile sizes.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Along a couple of paths, we either do not care about the notification
(i.e. during suspend) or do it explicitly. There we should mark the work
as done.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Let's be sure the mode has been established before we attempt to apply
it to a CRTC - just in case the kernel tries to use the invalid mode and
blows up.
References: https://bugs.freedesktop.org/show_bug.cgi?id=86679
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The previous commits prevent us from using the BLT if the destination
address is misaligned. Honour that restriction when creating buffers as
well, so that they are always usuable by the BLT.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Before we use the BLT for core acceleration, double check that we can.
This should catch the case where we attempt to operate on SHM pixmaps
which do not meet the restrictions.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
With bit 4 set in address, the gen8 blitter fails and blits errorneously
into the cacheline preceeding the destination and similarly when reading from
the source, corrupting memory.
v2: Update the destination base offset pattern as revealed
by igt/tests/gem_userptr_blits/destination-bo-align
v3: Check base address as well
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79053
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: xunx.fang@intel.com [v2]
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
The documentation warns of potential GPU hangs if we emit more than 4
pipecontrol flushes without a CS stall. This is highly unlikely given
how frequently we must inject stalls into the pipeline, but force a
stall just in case!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we clip the points when converting them into GPU boxes, check that we
have something to draw before submitting the commands.
Reported-by: Ian Gay <gay@sfu.ca>
References: https://bugs.freedesktop.org/show_bug.cgi?id=86075
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This is more important in the multiple stage operations like glyph
rendering where we do not want to initiate an operation on the GPU only
then to fallback due to an incompatible destination.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The number of ports we provide for Xv textured video is arbitrary. The
main cost is reservation of a number of XIDs and preallocation of a
block of memory. Whatever value we pick, someone will always want
more...
References: https://bugs.freedesktop.org/show_bug.cgi?id=85974
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The debug code wants to print the batch and the aux buffers. To do so,
it needs to bypass the assertions on the lifetime of the buffers.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we have a linear buffer, we can request the kernel mmap it directly
with write-combining without having to pin it into the GTT. This allows
us to efficiently upload very large buffers, and can avoid the dreaded
aperture thrashing.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Handle a potential SIGBUS due to kernel bugs when prefaulting the
scanout surface.
References: https://bugs.freedesktop.org/show_bug.cgi?id=85959
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Using dispatch mask cause hangs waiting PS Done on some cases like bug #83207,
with larger screen or when scaling it.
Also mesa uses VMask instead of Dmask for 3DSTATE_PS because in some cases
they were getting incorrect derivatives for subspans.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83207
Cc: Timo Aaltonen <tjaalton@ubuntu.com>
Cc: Gary Wang <gary.c.wang@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Tested-by: Timo Aaltonen <tjaalton@ubuntu.com>
gen8 sets the instancing bit relative to the vertex element, but we were
clearing it for the vertex buffer. As the maximum number of vertex
elements is fixed, just clear them all when emitting our header. Note
that VF_SGVS is not sufficient by itself to disable all side-effects of
instancing.
Thanks to Kenneth Graunke for pointing out the change from vertex buffer
to vertex element of the instancing enable bit.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84958
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>