Age | Commit message (Collapse) | Author |
|
LogF doesn't support the 0x-prefix instruction.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
We assert that damage is valid as we delete the Pixmap, and so we cannot
assert that the Pixmap is still valid itself.
Reported-by: Jiri Slaby <jirislaby@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Print out the pixmap number and the damage extents for when the
assertion fails.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
If we already have a buffer that represents the data on the GPU, we can
simply use that when we need to promote the pixmap onto the GPU.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
After relaxing some of the rules on when to discard the upload proxies,
we also need to relax some of the complementary asserts.
Reported-by: Zdenek Kabelac <zkabelac@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Eeek, when not using LinearFramebuffer we still want to create the GPU
bo: s/,/;/
Reported-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
This option should only be used for compatibility. Previously this was
done at a high level, this changes it to enforce the tiling as we apply
the CRTC.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
One day, we will move the width/height/bpp to the bo itself...
Reported-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
If we are not actually accessing the memory through the pointer, we do
not care if it not currently coherent.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
0 != (void *)0
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Since we now prefer CPU detiling, exactly when we want active/inactive
buffers is a little more complex - and we also need to take into account
when we want to use the CPU bo as a render target.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Fixes regression from
commit 961139f5878572ebea268a0bbf47caf05af9093f [2.99.912]
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Fri May 30 09:45:15 2014 +0100
sna: Use manual detiling for downloads
Reported-by: Harald Judt <h.judt@gmx.at>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80560
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
We don't really want to rendering into SHM pixmaps except for copying
back due to the strict serialisation requirements.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
We now distinguish gpu_dirty whilst the bo is not flushed within a batch
and needs_flush for when it is dirty and still busy.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
When allocating a scratch pixmap, we do so in the expectation that
rendering on the GPU is always preferrable, so even allocate a small
linear bo.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Now that we are more eager to transfer to the GPU bo if we expect
rendering to the CPU bo to be either slow or risk potential corruption,
we can find ourselves in a recursive loop when we also decide not to
create the GPU bo. Prevent that by explicitly creating the GPU bo if
desired.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
This seems slightly weird, as there is nothing to indicate that this
would generate incorrect results only for snoopable bo. But no many of
flushes make my pnv box happy, so adjust the placement logic to move the
blending operation away from the snoopable target. This is sensible for
reasons of avoiding snoops from the render pipeline anyway.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80253
Reported-and-tested-by: Matti Hämäläinen <ccr@tnsp.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Pass around const to suppress a few compiler warnings.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
As this may be mapped by the Xserver using a read-only SHM segment, we
are forced to treat it always as read-only. And this being X, that it is
using a SHM segment is opaque to the driver. Fantastic middlelayer.
This was incorrectly removed in
commit e680e54eab6ffa72e5e1eb6cc0e3fe4b235b06a1
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Wed Jun 11 10:48:26 2014 +0100
sna: Ignore setting read-only for temporary userptr maps
Also let's not forget the ShmPutImage -> CopyArea path.
Reported-by: Christoph Haag <haagch.christoph@googlemail.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=78411
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
As this may be mapped by the Xserver using a read-only SHM segment, we
are forced to treat it always as read-only. And this being X, that it is
using a SHM segment is opaque to the driver. Fantastic middlelayer.
This was incorrectly removed in
commit e680e54eab6ffa72e5e1eb6cc0e3fe4b235b06a1
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Wed Jun 11 10:48:26 2014 +0100
sna: Ignore setting read-only for temporary userptr maps
Reported-by: Christoph Haag <haagch.christoph@googlemail.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=78411
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
References: https://bugs.freedesktop.org/show_bug.cgi?id=80033
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
The kernel can quite happily send a SIGBUS whenever we read from an bo
(due to oom), so catch it and handle it.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Instead track what we explicitly want to discard for the next operation,
so that we don't have to copy back the whole buffer if we have to
replace the shadow and intend to overwrite it all.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Not checking DAMAGE_IS_ALL() correctly leads to an assertion failure.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Fixes regression from
commit 62aaf2ff4f8597067cf387865707baa00ed9a123
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Wed Jun 18 18:41:15 2014 +0100
sna: Skip redundant copies when already cloned
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
References: https://bugs.freedesktop.org/show_bug.cgi?id=77436
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
If the region we are blitting is either narrow or short, we may be able
to construct a tiling pattern out of a large pixmap.
In the process, spot a regression due to
commit 542aeca6e67fc64f9133ca3e27ac8eca28af6d25
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Tue Jun 17 12:26:30 2014 +0100
sna: Tweak creation 8x8 tiled patterns
which copied too much from the source line.
References: https://bugs.freedesktop.org/show_bug.cgi?id=79888
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
kgem_bo_upload_image was open-coded, so replace it with a call to the
common function
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|