This is where the other debug_memory_* functions are declared, so let's
move it here for symmetry.
This allows us to drop an include of u_debug_gallium.h, which makes us
depend on gallium-headers in non-gallium code.
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3901>
This allows communicating that it wasn't possible to determine whether
the two file descriptors reference the same file description. When
that's the case, log a warning in the amdgpu winsys.
In turn, remove the corresponding debugging output from the fallback
os_same_file_description implementation. It depends on the caller if
false negatives are problematic or not.
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3879>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3879>
When os_memory_debug.h was promoted to src/util, this source-file on
which it depends on when the debug-flag is set on windows was left
out. So let's move this also.
It doesn't seem there's any way of triggering this issue right now, but
it seems better to correct this to avoid this from biting us in the ass
in the future.
Fixes: 88c4680b5a ("util: promote u_memory to src/util")
Reviewed-by: Dylan Baker <dylan@pnwbakers>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3844>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3844>
../src/util/blob.c:166:7: runtime error: null pointer passed as argument 2, which is declared to never be null
#0 0x7fe51bc315df in blob_write_bytes ../src/util/blob.c:166
#1 0x7fe51c7a7b9a in iris_disk_cache_store ../src/gallium/drivers/iris/iris_disk_cache.c:115
#2 0x7fe51c7f444d in iris_compile_fs ../src/gallium/drivers/iris/iris_program.c:1693
#3 0x7fe51c7fdcd9 in iris_create_fs_state ../src/gallium/drivers/iris/iris_program.c:2331
#4 0x7fe519e871a3 in st_create_fp_variant ../src/mesa/state_tracker/st_program.c:1275
#5 0x7fe519e89dd0 in st_get_fp_variant ../src/mesa/state_tracker/st_program.c:1435
#6 0x7fe519ed51e1 in st_update_fp ../src/mesa/state_tracker/st_atom_shader.c:163
#7 0x7fe519eb5d73 in st_validate_state ../src/mesa/state_tracker/st_atom.c:261
#8 0x7fe519e4e0bf in prepare_draw ../src/mesa/state_tracker/st_draw.c:132
#9 0x7fe519e4e76e in st_draw_vbo ../src/mesa/state_tracker/st_draw.c:184
#10 0x7fe51aca5245 in vbo_save_playback_vertex_list ../src/mesa/vbo/vbo_save_draw.c:215
#11 0x7fe51a25b1cc in ext_opcode_execute ../src/mesa/main/dlist.c:1126
#12 0x7fe51a2f8d58 in execute_list ../src/mesa/main/dlist.c:11830
#13 0x7fe51a34b2d0 in _mesa_CallList ../src/mesa/main/dlist.c:14267
Signed-off-by: Danylo Piliaiev <danylo.piliaiev@globallogic.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3825>
This reverts the functional part of commit
d17ff2f7f1, leaving the unit test for
mesa/pipe agreement on what's an array.
The issue is that the util_channel_desc.shift values on array formats are
not used for bit addressing in memory, they're bit addressing within a
word treating a pixel of the format as a native type, as seen by
llvmpipe's use of the values to do shifts (see
lp_build_unpack_arith_rgba_aos() for example). This means the values are
nonsensical for 3-byte RGB, but then llvmpipe doesn't expose those formats
so it works out.
I still want to clean up our big-endian format handling at some point, but
let's fix the s390x regression first, sort out our format unit tests in
CI, then be able to refactor with confidence.
Fixes: d17ff2f7f1 ("gallium: Fix big-endian addressing of non-bitmask array formats.")
Closes: #2472
Acked-by: Marek Olšák <marek.olsak@amd.com>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3721>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3721>
Using LLVM 8 for ppc64el and 7 for s390x (which hits some coroutine
related issues with LLVM 8).
There are some test failures we need to ignore for now. Also, the
timeout needs to be bumped from the default 30s for some tests, because
they can take longer under emulation.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3643>
Almost all users of the unpack functions don't have strides to plug in
(and many are only doing one pixel!), and this will help simplify
them.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2744>
Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/2464
Fixes: e62c3cf350 ("util/os_socket: Include unistd.h to fix build error")
Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Krzysztof Raszkowski <krzysztof.raszkowski@intel.com>
Fixes
In file included from ../src/util/os_socket.c:8:
../src/util/os_socket.h:26:1: error: unknown type name ‘ssize_t’; did you mean ‘size_t’?
ssize_t os_socket_recv(int socket, void *buffer, size_t length, int flags);
seen with gcc version 8.3.0 (Buildroot 2019.11) and uClibc 1.0.32.
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Fixes: ef5266ebd5 ("util/os_socket: Add socket related functions.")
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3659>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3659>
A few hash_table users roll their own integer hash functions which
call _mesa_hash_data to perform the hashing which ultimately calls
into XXH32 with a dynamic key length. When using small keys with a
constant size the hash rate can be greatly improved by inlining
XXH32 and providing it a constant key length, see:
https://fastcompression.blogspot.com/2018/03/xxhash-for-small-keys-impressive-power.html
Additionally, this patch removes calls to _mesa_key_hash_string and
makes them instead call _mesa_has_string directly, matching the new
integer hash functions.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3475>
For most key sizes, xxhash outperforms fnv1a's hash rate substantially (bug
2153). In particular, the V3D driver hashes multiple ~200 byte keys as part
of the shader cache lookup which can easily eat up 10-20% of the runtime on
the Raspberry Pi. Swapping over to xxhash drops this to ~1% of the runtime.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3475>
__size, in particular, makes this macro rather confusing to understand
how to use. Hopefully this comment saves future users the headache.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3499>
We currently initialize this float-array with double-literals. Some
compilers generate warnings for this, so let's switch these to
float-literals instead.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Setting up transitive conflicts between a full register and its two
half registers (eg r0.x and hr0.x and hr0.y) will make the half
registers conflict. They don't actually conflict and this prevents us
from using both at the same time.
Add and use a new ra helper that sets up transitive conflicts between
a register and its subregisters, except it carefully avoids the
subregister conflict.
Signed-off-by: Kristian H. Kristensen <hoegsberg@google.com>
Reviewed-by: Rob Clark <robdclark@chromium.org>
Two competing rules for defining u_format_table.c exists,
which is an error.
Additionally the more general rule lacks the inclusion of
format/u_format.csv.
Fixes: 882ca6dfb0 ("util: Move gallium's PIPE_FORMAT utils to /util/format/")
Signed-off-by: Robert Foss <robert.foss@collabora.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
This would've caught 8829f9ccb0 ("u_format: add ETC2 to
util_format_srgb/util_format_linear").
Suggested-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Fixes: 3c45c4bc44 ("util: Cope with the fact that formats in u_format.csv are not ordered.")
Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Add some missing vulkan formats to util/format, this solves all the missing
pipe format cases for the formats that turnip supports.
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3170>
macOS does not have pthread_getcpuclockid.
src/util/u_thread.h:156:4: error: implicit declaration of function 'pthread_getcpuclockid' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
pthread_getcpuclockid(thread, &cid);
^
Fixes: 4913215d14 ("util/u_thread: don't restrict u_thread_get_time_nano() to __linux__")
Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/2171
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Acked-by: Eric Engestrom <eric@engestrom.ch>
This makes simple_mtx_destroy set the counter to an invalid canary
value and then makes lock/unlock assert that the value is legal.
That way, calling lock/unlock after destroy will assert fail,
rather than deadlocking or potentially even working.
This has caught real deadlocks in dEQP multithreaded tests (in st/mesa
shader variant zombie list handling), which have since been fixed.
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
With 781a78 ("mesa: enable ARB_direct_state_access in compat for
GL3.1+), it's possible to have DSA with GL3.1+.
FTL creates a GL3.1 compat context, but fails the
_mesa_has_geometry_shaders(..) check in frame_buffer_texture.
Bump the compat version to pass the check.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Braces mismatch (flagged by CI, untested).
Fixes: 385d13f26d "util/atomic: Add a _return variant of p_atomic_add"
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This new function lets you request to remove a specific address range
from the allocator. It returns true on success and leaves the allocator
unmodified and returns false on failure. It doesn't need to return an
offset because, if it succeeds, the offset passed in is the allocated
offset.
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
pthread_getcpuclockid() and clock_gettime() are also available on at least
OpenBSD, FreeBSD, NetBSD, DragonFly, Cygwin.
Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
