Presume that the non-pipelined drawrect is sufficient to serialise
operations to the render cache.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Otherwise it appears that the hardware will readback from memory
bypassing its render cache after a change of modes. There is probably a
lot more subtly to it than this, but this appears to be a good first
approximation.
Reported-by: Clemens Eisserer <linuxhippy@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51422
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Merge the device open in the main driver with the probing so that we can
open the path explicitly passed in by the PlatformProbe and keep that fd
around for the main driver and so avoid a later search.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
With Zaphod enabled, we will try to acquire/release the drmMaster
several times on each enter/leave VT. This obviously flags an error (and
drops the master too early), so track the number of references we still
hold for drmMaster.
References: https://bugs.freedesktop.org/show_bug.cgi?id=66041
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Sergio Callegari found a case in LibreOffice that copied cloned pixmaps
onto each other and then modified one of the pair. This was triggering
the hack put in to speed up firefox scrolling, unfortunately.
Reported-by: Sergio Callegari <sergio.callegari@gmail.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=65665
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This reverts commit cc08f6e0ef.
Prefer to keep the frontbuffer as tiled, and use an per-crtc pixmap in
case the frontbuffer is not suitable as the framebuffer.
gen4 has a restricted DSPSTRIDE limit for tiled surfaces lower than the
maximum supported size of the CRTC. So we need to double check
whether tiling the scanout is supported before attempting to allocate a
tiled scanout.
Reported-by: Paul Donohue <freedesktop-bugs@PaulSD.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65099
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In preparation for extending the kernel interface to be more explicit
about when we need to flush a direct write to the scanout.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Since the upload buffer is special in that it simultaneously exists on
both the CPU and GPU, we need to be extremely careful in marking the cpu
hint flag and asserting it. In particular, the new stricter assert was
firing in the CompositeTrapezoids fallback path.
Reported-by: Jiri Slaby <jirislaby@gmail.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=47597
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The clear hint is correctly updated when performing the move-to-gpu and
so it is being superfluously repeated by the callers.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tracking to track down where the CPU hint may be set to true but the
pixmap remain entirely damaged on the GPU.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Otherwise the sampler on Haswell will just read all zeros when trying to
playback a video.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65699
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the target bo is not bound when we start to emit the composite state
for the operation, we are screwed.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We enlarge the read back into to minimise the number of times we have to
migrate pixmap data. However, if we then enlarge the read so that it
overwrites CPU dirty data, then we can introduce corruption.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Rather than completely starve X from handling input events and raising
the spectre of miEQ overflow, stop throttling upon SIGINT. We will have
waited a small period of time (~100ms) for the GPU to catch up, and will
do so again in the near future. This also preserves the hang detection.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Similar to 7d91051c, but along the render path rather than CopyArea.
Makes the presumption that for the upload path the region is stored on
the CPU explicit.
References: https://bugs.freedesktop.org/show_bug.cgi?id=61628
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The code was being careful in making sure that only a BO with an
outstanding GPU write was being flushed. We need to relax that
assertion to allow us to call busy_ioctl after only GTT writes.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Makes the presumption that for the upload path the region is stored on
the CPU explicit.
References: https://bugs.freedesktop.org/show_bug.cgi?id=61628
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
A few places we were redundantly submitting the same bo, and in others
doing more work than necessary.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This allows us to more accurately track when the GTT is dirty. However,
the only danger is that we may prematurely flush the scanout and clear
the dirty bit and not preserve the flush timer.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Better would be to start passing in the sna_pixmap so that we can mark
the GTT as dirty in a single location, and only if we do indeed then do
a GTT update or pwrite.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Rather than reparsing the EDID each time we probe the modes, if the
property hasn't changed keep it.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This is a tidy up in preparation for a more controversial patch. In the
meantime, take advantage of information that remains static over the
lifetime of our connectors.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Since the call to the busy_ioctl is predicated on whether the bo needs
to be flushed by us, therefore when forcing the call to the busy_ioctl
to flush the GTT we need to mark it as requiring needs_flush.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson
Jonathan Gray