This is Fail.
First patch to libdrm, and I've borked it up.
Noticed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
... and if asked to open a bo by the same global name, return a fresh
reference to the previously allocated buffer.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The nvc0 gallium drivers passes NULL here to indicate to the memory manager
that a buffer is being used, but without creating an actual reloc.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
gen4+ hardware doesn't use fences for GPU access and the older kernel
doesn't expect userspace to make such a mistake. So don't.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=32190
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
For relaxed fencing the object may only consume the small set of active
pages, but still requires a fence region once bound into the aperture.
This is the size we need to use when computing the maximum possible
aperture space that could be used by a single batchbuffer and so avoid
hitting ENOSPC.
Reported-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
It makes sure that GPU object destruction is executed in order with
respect to the previous FIFO commands.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Acked-by: Ben Skeggs <bskeggs@redhat.com>
Both the consumers of this API (sync objects and client throttling)
were expecting this behavior. The kernel used to actually behave the
desired (but incorrect) way for us anyway, but that got fixed a while
back.
If bufmgr.bo_mrb_exec is not set, drm_intel_bo_mrb_exec returns ENODEV
even though drm_intel_gem_bo_mrb_exec2 will work fine for the RENDER ring.
Fixes xf86-video-intel after commit 'add BLT ring support' (5bed685f76)
with kernels without BSD or BLT ring support (2.6.34 and before).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31443
Signed-off-by: Albert Damen <albrt@gmx.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The intent of these was to catch mismatched map/unmap. What it
actually did was check whether there was ever a mapping of that type
(including in a previous life of the buffer through the userland BO
cache), not whether they were mismatched. We don't even actually want
to catch mismatched map/unmap, unless we also do refcounting, since at
one point Mesa would do map/map/use/unmap/unmap. Just remove this
code instead.
nouveau_bo_unmap called the CPU_FINI IOCTL even if it was a NOSYNC
mapping. It caused no harmful effects (actually CPU_FINI is a no-op on
recent enough kernels) besides the precious CPU cycles being wasted.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
The kernel has always allowed userspace to underallocate objects
supplied for fencing. However, the kernel only allocated the object size
for the fence in the GTT and so caused tiling corruption. More recently
the kernel does allocate the full fence region in the GTT for an
under-sized object and so advertises that clients may finally make use
of this feature. The biggest benefit is for texture-heavy GL games on
i945 such as World of Padman which go from needing over 1GiB of RAM to
play to fitting in the GTT!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As the higher layers check the error return from libdrm-intel and
are supposed to handle the error (and print their own warning in
extremis) the voluminous output on stderr is just noise and a hazard in
its own right.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Dave Airlie
Ben Skeggs
Kristian Høgsberg
Matt Turner
Chris Wilson
Daniel Vetter
Benjamin Franzke
nobled
Marek Olšák
Francisco Jerez
Eric Anholt
Albert Damen
Adam Jackson
Carl Worth