This reverts commit d2106384be.
Breaks compiz (but not mutter/gnome-shell) on gen6. Not sure if this is
not seem deep interaction issue with multiple clients sharing the GPU or
just with compiz, but for now we have to revert and suffer the inane
performance hit. It looks suspiciously like another deferred damage
issue...
Bugzilla: 51a27e88b073cff229fff4362cb6ac22835c4044
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Rather than just creating and submitting a batch that simply contains a
flush in order to periodically ensure that rendering reaches the
scanout, we can simply ask the kernel whether the scanout is busy. The
kernel will then submit a flush on our behalf if it is dirty, which
takes advantage of the kernel's dirty state tracking.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The kernel will emit any required flushes between the dri client and the
ddx, and we do not rely on the MI_FLUSH here for scanout.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reduce the number of relocations emitted by only emitting one relocation
per vertex element per vertex buffer.
References: https://bugs.freedesktop.org/show_bug.cgi?id=35733
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We have seen GPU hangs with:
batchbuffer at 0x0f9b4000:
0x0f9b4000: 0x09000000: MI_LOAD_SCAN_LINES_INCL
0x0f9b4004: 0x00000300: dword 1
0x0f9b4008: 0x09000000: MI_LOAD_SCAN_LINES_INCL
0x0f9b400c: 0x00000300: dword 1
0x0f9b4010: 0x01820000: MI_WAIT_FOR_EVENT
0x0f9b4014: HEAD 0x02000006: MI_FLUSH
on a 1366x768 display. That according to the specs an invalid command
for the pipe.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35576
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
A tile on gen2 has a size of 2kb, stride of 128 bytes and 16 rows.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If adding either the frame or client resources fails, we need to clean
up afterwards properly.
First, add_frame_event needs to internally clean up after itself by
undoing any partial execution. Second, the callers need to look at the
return value and free the swap/flip info structure when necessary.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Julien Cristau <jcristau@debian.org>
A modest boost to throughput and reduction in CPU overhead from
not flushing the batch on every transition from BLT to RENDER.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As the frame_event is about to be freed, there's no point in cleaning
up references to the drawable and client.
Signed-off-by: Keith Packard <keithp@keithp.com>
A pending swap or flip holds references to drawables and clients which
become invalid when destroyed. Add suitable resources to the database
to track those lifetimes and clean up the pending data structure then.
Later, when the pending swap or flip occurs, handle a missing drawable
by just discarding the flip or swap. Handle a missing client by not
sending an event or reply.
Signed-off-by: Keith Packard <keithp@keithp.com>
Instead of using void * for all of the flip_info and swap_info
pointers, just make the underlying structure a public data type and
use that.
Signed-off-by: Keith Packard <keithp@keithp.com>
In the case of a singular clip box and rendering onto the front buffer
larger than 2048, the clip extents were being ignored. Here we can
simply reduce the size of the indirect pixmap to the clip extents.
Reported-by: Michael Chang <mchang@novell.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35346
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Keith Packard pointed out a loophole that could cause the DDX to end up
with a tiled scanout even if the user required a linear framebuffer;
that is by using page-flipping we could replace the scanout pixmap with
another of our choosing, and not necessarily tiled.
Close that loophole by only allowing an exchange of buffers between
identical tiling modes. For the common case, this is fine since they
will indeed be allocated with the same tiling. For the linear
framebuffer case with mesa using a tiled pixmap, we force it to blit
onto the scanout instead.
Reported-by: Keith Packard <keith.packard@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
So that you can indeed allocate a linear framebuffer if you so desire
without breaking mesa.
Adds:
Section "Driver"
Option "LinearFramebuffer" "False|True" # default false
EndSection
to xorg.conf
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
I have no clue as to how such an alien drawable reached us, but we have
the evidence of a segfault to say it can happen.
Reported-by: Bernie Innocenti <bernie@codewiz.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34787
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Certain error situations can result in the following printed to
Xorg.0.log at a high enough rate to make log file size a problem.
(WW) intel(0): I830DRI2GetMSC:1062 get vblank counter failed: Invalid argument
(WW) intel(0): I830DRI2ScheduleWaitMSC:1118 get vblank counter failed: Invalid argument
Following in the tradition of commit 0ad6d6e1, limit the warnings to be
output 5 times, then quell the remainder.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34322
Ref.: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/710594
Signed-off-by: Bryce Harrington <bryce@canonical.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Since, with GPU-on-package, it's hard to talk about a model number for
a specific chipset like 855GM, just use the platform names.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the render operation requires a temporary source Picture and the
operation is large, larger than the maximum permitted bo, then we will
fail to allocate the bo. In this case, we need to fallback and perform
the operation on the CPU rather than dereference a NULL bo.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34399
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
WRONG.
The hardware was never limited to 0x1000000 and the kernel can quite
rightly place objects above that limit. Specifying such had no relation
to reality, so why did we do it? TWICE!
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34017
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
uxa_acquire_solid returns NULL under OOM. Thus the value of solid
must be checked before dereferencing it in the uxa_get_offscreen()
call.
Signed-off-by: Bryce Harrington <bryce@canonical.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The region is used to paint onto the backing pixmap (and thus
translated) prior to being passed to the damage layer (wrt to the
drawable). So the local translation needs to be undone first.
Identified by Christopher James Halse Rogers.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=33650
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The actual code was removed in 5f64122551, where the get_surface_status
driver callback was dropped. Just return Success if there were no issues
with the parameter.
Get rid of the following with CFLAGS="-Wall -Werror":
| CC intel_xvmc.lo
| cc1: warnings being treated as errors
| intel_xvmc.c: In function ‘XvMCSyncSurface’:
| intel_xvmc.c:677: error: ‘ret’ may be used uninitialized in this function
| intel_xvmc.c:672: note: ‘ret’ was declared here
Signed-off-by: Cyril Brulebois <kibi@debian.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Both exported XvMCPutSlice/XvMCPutSlice2 functions have a prototype with a
parameter whose signedness differs from the one in the put_slice/put_slice2
functions they call. Make it unsigned through a cast.
Get rid of this accordingly with CFLAGS="-Wall -Werror":
| CC intel_xvmc.lo
| cc1: warnings being treated as errors
| intel_xvmc.c: In function ‘XvMCSyncSurface’:
| intel_xvmc.c:677: error: ‘ret’ may be used uninitialized in this function
| intel_xvmc.c:672: note: ‘ret’ was declared here
Signed-off-by: Cyril Brulebois <kibi@debian.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Get rid of those accordingly with CFLAGS="-Wall -Werror":
| CC i915_xvmc.lo
| cc1: warnings being treated as errors
| i915_xvmc.c: In function ‘i915_mc_one_time_state_emit’:
| i915_xvmc.c:369: error: suggest parentheses around arithmetic in operand of ‘|’
| i915_xvmc.c:374: error: suggest parentheses around arithmetic in operand of ‘|’
| i915_xvmc.c:379: error: suggest parentheses around arithmetic in operand of ‘|’
| i915_xvmc.c: In function ‘i915_mc_load_indirect_render_emit’:
| i915_xvmc.c:708: error: suggest parentheses around arithmetic in operand of ‘|’
| i915_xvmc.c:713: error: suggest parentheses around arithmetic in operand of ‘|’
Signed-off-by: Cyril Brulebois <kibi@debian.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Get rid of the following with CFLAGS="-Wall -Werror":
| CC intel_xvmc_dump.lo
| cc1: warnings being treated as errors
| intel_xvmc_dump.c: In function ‘intel_xvmc_dump_open’:
| intel_xvmc_dump.c:41: error: suggest parentheses around assignment used as truth value
Signed-off-by: Cyril Brulebois <kibi@debian.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
With '--disable-debug' we define NDEBUG and so disable the asserts, that
is we continue to default to compiling asserts into the code.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The screen resources are recreated when the screen is rotated as well,
without being finalized. In this case, we do not need to reconstuct the
cache (or if we did, we would need to tear it down first).
Reported-by: Till Matthiesen <entropy@everymail.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=33412
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Daniel Vetter
Chris Wilson
Keith Packard
Bryce Harrington
Adam Jackson
Javier Jardón
Cyril Brulebois
Xiang, Haihao