historically zink has been bound to 4 gfx batches and then a separate compute batch
was added. this is not ideal for a number of reasons, the primary one being that if
an application performs 5 glFlush commands, the fifth one will force a gpu stall
this patch aims to do the following, all of which are necessarily done in the same patch
because they can't be added incrementally and still have the same function:
* rewrite batch tracking for resources/views/queries/descriptors/...
|originally this was done with a single uint32_t as a bitmask, but that becomes cumbersome
to track as batch counts increase, not to mention it becomes doubly-annoying
when factoring in separate compute batches with their own ids. zink_batch_usage gives
us separate tracking for gfx and compute batches along with a standardized api for
managing usage
* flatten batch objects to a gfx batch and a compute batch
|these are separate queues, so we can use an enum to choose between an array[2] of
all batch-related objects
* switch to monotonic batch ids with batch "states"
|with the flattened queues, we can just use monotonic uints to represent batch ids,
thus freeing us from constantly using bitfield operations here and also enabling
batch counts to scale dynamically by allocating/caching "states" that represent a batch
for a given queue
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9547>
this race condition between destroying ubo backing memory in lavapipe and
performing descriptor updates can be triggered from more than just queries,
so forcing the update just before the Problem Area seems like the best way to
permanently resolve the issue
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9711>
This adds a HAVE_COMPRESSION macro, which is undefined if neither zlib
nor zstd are present, and is used to no-op compress.h/c. This also has
a side effect of fixing SCons, since it won't define this macro.
Fixes: d7ecbd5bf8 ("util: create some standalone compression helpers")
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9689>
This is the race condition: thread 1 check reference count of resource
and then find out out it's zero and then it begin to destroy it. Around
the same time, thread 2 gets the lock and get the resource from the hash
table and plan to use it. Then this resource gets destroyed while it's
still in use.
Signed-off-by: Lepton Wu <lepton@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9701>
The client-side implementation of this operates entirely in terms of the
GL and X client APIs. There's nothing DRI-specific about it, evidenced
by apple and windows using it unchanged. Save a little code size by
handling the direct/indirect difference directly.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9690>
valgrind returns exit code 126 if it can't write to the file passed to
--log-file. Hopefully it'll be the same for any other invalid valgrind
command line parameters or internal errors as well.
Using a different exit code (31) for this was hiding the fact that the
valgrind test wasn't actually working.
v2:
* Use exit code 126; can't treat any non-0 exit code as failure because
glcpp is expected to exit with non-0 for some of the input we feed it
Reviewed-by: Dylan Baker <dylan.c.baker@intel.com> # v1
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9528>
Use pipes for direct communication between child & parent process.
Using tempfiles sometimes resulted in hitting the meson timeout if there
was high filesystem pressure (I saw a single unlink system call take as
long as 4 seconds; attempts to re-use a single tempfile just shifted the
delays to truncate/close systems calls).
As a bonus, this gets the valgrind test actually working as intended.
It wasn't working because the tempfile passed to --log-file didn't exist
(due to the earlier os.close(fd)?).
v2:
* Wrap .read() in "with open()" (Dylan Baker)
Reviewed-by: Dylan Baker <dylan.c.baker@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9528>
valgrind flagged members of gl_ctx->Extensions being used uninitialized:
==23417== Conditional jump or move depends on uninitialised value(s)
==23417== at 0x112642: _glcpp_parser_handle_version_declaration.part.0 (glcpp-parse.y:2493)
==23417== by 0x11A515: glcpp_lex_update_state_per_token (glcpp-lex.l:132)
==23417== by 0x11A515: glcpp_lex (glcpp-lex.l:547)
==23417== by 0x114D46: glcpp_parser_lex (glcpp-parse.y:2302)
==23417== by 0x114D46: glcpp_parser_parse (glcpp-parse.c:1871)
==23417== by 0x11ADC6: glcpp_preprocess (pp.c:238)
==23417== by 0x111384: main (glcpp.c:174)
==23417== Uninitialised value was created by a stack allocation
==23417== at 0x111295: main (glcpp.c:136)
Reviewed-by: Dylan Baker <dylan.c.baker@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9528>
llvmpipe has some crazy dependency ordering with constant buffers that
I don't want to mess with, so instead this ensures that descriptors are
always updated as early in the command stream as possible, avoiding any
use-after-free scenarios which might result from lavapipe freeing memory
in a still-bound descriptor that's pending an update
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9692>
Mike Blumenkrantz