As it turns out, the wait is required as the driver expects for
rendering to be quiesced on exit. This can trigger channel failures,
which in turn trigger recovery. This can fail and destroy the whole
system.
Fixes: 28a781323f ("nouveau: change fence destruction logic on screen destroy")
References: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4223
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8867>
Otherwise the delete yells at us that there's still work pending. This
isn't an actual problem, but annoying to see each time.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8462>
With the drm shim, we can't actually wait for the hardware to do
anything. But why wait for it at all? We just need to make sure to
execute all the work and clean up any resources. Add a helper to do
that.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8406>
No point in having the extra argument considering that it's effectively
unused since the function was introduced.
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Force the fence to get kicked off, which won't actually wait for its
completion, but any additional work will be put onto a fresh list.
This fixes crashes in teximage-colors --benchmark with too many active
maps.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
The act of ensuring that there is space can cause a flush to happen,
which will emit the current screen fence. If that is the fence we're
trying to wait on, then it will have been emitted as a result of doing
the PUSH_SPACE. Don't attempt to emit it a second time.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Fixes: 8053c9208f (nouveau: avoid emitting new fences unnecessarily)
Cc: mesa-stable@lists.freedesktop.org
Right now we emit on every kick, but this is only necessary if something
will ever be able to observe that the fence completed. If there are no
refs, leave the fence alone and emit it another day.
This also happens to work around an issue for the kick handler -- a kick
can be a result of e.g. nouveau_bo_wait or explicit kick, or it can be
due to lack of space in the pushbuf. We want the emit to happen in the
current batch, so we want there to always be enough space. However an
explicit kick could take the reserved space for the implicitly-triggered
kick's fence emission if it happened right after. With the new mechanism,
hopefully there's no way to cause two fences to be emitted into the same
reserved space.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Fixes: 47d11990b (nouveau: make sure there's always room to emit a fence)
Cc: mesa-stable@lists.freedesktop.org
Deleting a buffer does not flush the command stream. Make sure that we
wait for the copies to finish before deleting the temporary bo.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: mesa-stable@lists.freedesktop.org
Tested-by: Marcin Ślusarz <marcin.slusarz@gmail.com>
The linked list in gallium is pretty much the kernel list and we would like
to have a C-based linked list for all of mesa. Let's not duplicate and
just steal the gallium one.
Acked-by: Connor Abbott <cwabbott0@gmail.com>
Reviewed-by: Rob Clark <robclark@freedesktop.org>
nouveau_fence_update does real work unconditionally. Avoid doing that if
the fence we're checking on has already been signalled.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
This fixes a memory leak in some situations. Also avoids emitting an
extra fence if the kick handler does the call to nouveau_fence_next
itself.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "9.2 10.0" <mesa-stable@lists.freedesktop.org>
The previous commit introduced extra words, breaking the formatting.
This text transformation was done automatically via the following shell
command:
$ git grep 'THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY' | sed 's/:.*$//' | xargs -I {} sh -c 'vim -e -s {} < vimscript
where 'vimscript' is a file containing:
/THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY/;/\*\// !fmt -w 78 -p ' * '
:wq
Reviewed-by: Brian Paul <brianp@vmware.com>
This brings the license text in line with the MIT License as published
on the Open Source Initiative website:
http://opensource.org/licenses/mit-license.php
Generated automatically be the following shell command:
$ git grep 'THE AUTHORS BE LIABLE' | sed 's/:.*$//g' | xargs -I '{}' \
sed -i 's/THE AUTHORS/THE AUTHORS OR COPYRIGHT HOLDERS/' {}
This introduces some wrapping issues, to be fixed in the next commit.
Reviewed-by: Brian Paul <brianp@vmware.com>
If there is not enough space in pushbuffer for fence emission
(nouveau_fence_emit -> nv50_screen_fence_emit -> MARK_RING),
the pushbuffer is flushed, which through flush_notify ->
nv50_default_flush_notify -> nouveau_fence_update marks currently
emitting fence as flushed. But actual emission is done after this mark.
So later when there is a need to wait on this fence and pushbuffer
was not flushed in between, fence wait will never finish causing
application to hang.
To fix this, introduce new fence state between AVAILABLE and EMITTED,
set it before emission and handle it everywhere.
Additionally obtain fence sequence numbers after possible flush in
MARK_RING, because we want to emit fences in correct order.
Reviewed-by: Christoph Bumiller <e0425955@student.tuwien.ac.at>
Note: This is a candidate for the 7.11 branch.
Fence emission can flush the push buffer, which through flush_notify
unreferences recently emitted fence. If ref count is increased after
fence emission, unreference deletes the fence, which causes SIGSEGV.
Backtrace:
nouveau_fence_del
nouveau_fence_ref
nouveau_fence_next
nouveau_pushbuf_flush
MARK_RING
nv50_screen_fence_emit
nouveau_fence_emit
nv50_flush
This bug manifested as an assertion failure in nouveau_fence.c, because
SIGSEGV handler tried to shutdown the application and used messed up
fence.
This issue was reported by Maxim Levitsky.
Note: This is a candidate for the 7.11 branch.
Modified from original to remove chipset-specific code, and to be decoupled
from the mm present in said drivers.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Emma Anholt
Yonggang Luo
Ilia Mirkin
Timothy Arceri
Nicolai Hähnle
Emil Velikov
Samuel Pitoiset
Jason Ekstrand
Kenneth Graunke
Christoph Bumiller
Francisco Jerez
Marcin Slusarz
Ben Skeggs