When cs allocation fails in radv_create_cmd_buffer,
radv_destroy_cmd_buffer is called before returning
VK_ERROR_OUT_OF_HOST_MEMORY. At that point, the upload list is not
initalized yet, so SIGSEGV will occur when trying to iterate through the
upload bo list. Initialize the upload list earlier to avoid this.
Signed-off-by: Benjamin Cheng <ben@bcheng.me>
Reviewed-by: Tatsuyuki Ishi <ishitatsuyuki@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22016>
this improves handling for barriers that originate from a write in the
unordered cmdbuf, adding tracking to resources to better determine access
in the unordered cmdbuf and then utilizing that to generate a single split
memory barrier added at the end of the unordered cmdbuf for all the buffers
written to on that cmdbuf
the next step will be to also merge the read access down onto the end-of-cmdbuf
barrier so that all stream upload-type functionality becomes a single barrier
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22027>
there's no way to link up image layouts between the unordered cmdbuf
and the main one, so if an op is promoted to unordered after an image
is used as a descriptor, the layout will be broken
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22027>
previously the unordered access flags would be set before the deferred
barrier was added, which would guarantee no descriptor barriers could
be deferred and thus terminate renderpasses any time a new descriptor
was bound that was both an image and needed a layout change
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22027>
if this scenario occurs:
* bind fb on ctx A
* draw
* flush + change context to B
* read fb on ctx B
* delete ctx A
then a dead batch write will be left on the fb bo
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22027>
the only "safe" rp ends are:
* set_framebuffer_state (new rp)
* flush_resource (present)
* flush (end of rp)
any other rp end needs its rp info sanitized to avoid e.g., reapplying clears
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22027>
bitCount is still special in that our lowering would try to demote its arg
based on the precision of its output, and it shouldn't do that. But the
other special cases now have appropriate qualifiers on them at the IR
level.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21666>
The signature should dictate the precision of the temp we store into.
This ends up ignored by lower_precision for now, which always rewrites it
so as to handle custom lowering of builtin precision..
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21666>
It's what the spec says to do. This will may help us avoid special-casing
these functions if we ever lower precision after builtin inlining.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21666>
These have precision qualifiers defined in the spec, in which case we
should emit them them while generating builtin signatures and code. We've
been special-casing them in GLSL lower_precision, but now we can just rely
on the precision qualifier of the builtin if non-NONE.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21666>
This pattern is the core of the webgl conformance failure, I think. And,
I think actually lower_precision was doing the right thing, just the
conformance test going through ANGLE was screwing up.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21666>
No need to generate a temp in this case. Cleanup I noticed while looking
at lower_precision behavior (and I've included a testcase to sanity check
that things work out).
This causes a tiny amount of scheduling change on freedreno:
total instructions in shared programs: 11010012 -> 11010012 (0.00%)
instructions in affected programs: 147 -> 147 (0.00%)
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21666>
No need to expose extra padding or CCS data to the client map. Now that
we have the data, we can also make the BindBufferMemory asserts a bit
more accurate.
Reviewed-by: Iván Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22031>
Indeed, the unbind function is not called which could lead
to an unbalanced refcount state for the "drawable" object.
For instance, with "piglit/bin/glx-fbo-binding -auto"
while setting GALLIUM_REFCNT_LOG=refcnt.log.
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22024>
Erik Faye-Lund
Samuel Pitoiset
Benjamin Cheng
Mike Blumenkrantz
Emma Anholt
Faith Ekstrand
Patrick Lerda
Lang Yu
Konstantin Seurer