There are no similar macros in gtest. They do recommend pulling
another library (gmock) and use that, but having our own let us
control the output more precisely. Extracted the code from a similar
existing macro in blob_test.cpp, making changes to the output.
A check like
ASSERT_U8_ARRAY_EQUAL(expected_u8, result_u8, 32);
that fails will output
```
Expected 32 values to be equal but found 1 that differ:
expected_u8 values are:
[000] 29 44 00 00 44 60 cb 80 93 65 07 c0 08 00 40 29
[016] 03 81 00 00 5c a0 21 87 *b0 31 00 00 00 00 00 60
result_u8 values are:
[000] 29 44 00 00 44 60 cb 80 93 65 07 c0 08 00 40 29
[016] 03 81 00 00 5c a0 21 87 *af 31 00 00 00 00 00 60
```
and a check like
ASSERT_U64_ARRAY_EQUAL(expected_u64, result_u64, 4);
```
Expected 4 values to be equal but found 1 that differ:
expected_u64 values are:
[000] 80cb604400004429 29400008c0076593
[002] 8721a05c00008103 *60000000000031b0
result_u64 values are:
[000] 80cb604400004429 29400008c0076593
[002] 8721a05c00008103 *60000000000031af
```
Note the asterisk indicating wrong values.
The new header for extra macros is in src/gtest/include/ so it
doesn't get in the way when updating the real gtest headers that are
in src/gtest/include/gtest/.
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13672>
shader_stages_mask and others expect MESA_SHADER_* based values,
not PIPE_SHADER_*...
Without this the fragment shader wouldn't appear in the "Pipelines"
pane of RGP.
Fixes: c276bde34a ("radeonsi/sqtt: export shader code to RGP")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13696>
If you gonna view context of function parse_atomic_op,
then you gonna know that index for array (data_src)
can be unitialized. Imho this approach is cleaner
than doing stuff inside parse_atomic_op.
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12995>
A bit difficult to find what commit introduced the issue because of
all the renaming, but it was my bug :)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10015>
When a device has its first slice/subslice fused off, we can't use the
number of slices/subslices to iterate the mask array.
v2: Fix spelling (Marcin)
Use size_t for iterator (Marcin)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reported-by: Matt Roper <matthew.d.roper@intel.com>
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5601
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10015>
Rather than having 2 paths to set the slice/subslice/eu masks, reuse
the other internal functions. This simplifies finding bugs within this
code :
* If we have i915 query topology support, update_from_topology() is
called.
* If we don't have query topology support but we have getparam for
slice/subslice/EU, we generate a topology data and call
update_from_topology()
* If we have no kernel support to query any kind of topology, we
generate the values return by the kernel for slice/subslice/EU and
call update_from_masks() which in turns calls
update_from_topology()
v2: Fixup typo (Adam)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10015>
10c75ae4 moved handling of this state to the functions that
depend on ctx->_ImageTransferState.
So we can't depend on _NEW_PIXEL being set to call this function,
since it'll be always clear earlier by _mesa_update_state_locked.
Example sequence that would trigger the issue:
glPixelTransferi(...)
glClear(...)
glTexSubImage2D(...) <-- won't use the new value set by
glPixelTransferi because glClear caused
_NEW_PIXEL to be cleared.
_NEW_PIXEL itself is kept because st_update_pixel_transfer depends
on it.
Fixes: 10c75ae4 ("mesa: move _mesa_update_pixel out of _mesa_update_state")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5273
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13596>
../mesa-9999/src/gallium/drivers/llvmpipe/lp_texture.c:55:10: fatal error: git_sha1.h: No such file or directory
Fixes: 1608a815e3 ("llvmpipe: add support for EXT_memory_object(_fd)")
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Signed-off-by: orbea <orbea@riseup.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13665>
For example, this allows us to take advantage of command-streamer
based register offsets in mi_builder.
Ref: 06cf838cbd ("intel/mi_builder: Support gen11 command-streamer based register offsets")
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13652>
this ended up being a little trickier than I thought; lazy
descriptors don't use dynamic ubo types for the push set,
which means drivers that (correctly) assert dynamic offset existence
explode because the descriptor template will never work with the
push set
the better, though slightly more annoying, option here is to use the
lazy manager's faster descriptor allocation and lesser complexity to
quickly grab a push set, then tweak the existing cached codepath slightly
in order to update a raw vkdescriptorset
Fixes: 417477f60e ("zink: always use lazy (non-push) updating for fbfetch descriptors")
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13677>
If an app re-issues a timestamp query a lot, but doesn't ever ask
for the results, we could end up running off the end of our query
heap. But we don't actually need to advance/accumulate, so just
use a single entry in the heap.
Reviewed By: Bill Kristiansen <billkris@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12920>
The slice->size0 temp is being used as both the array stride (incorrectly)
and as the size of the slice (for this assert). This assert doesn't seem
to be in the right place to me, if you want to check that offset+slice
size is < bo size, you could just do that at the end of layout setup.
This caused troubles when fixing the temp to be the actual array stride
for filling out the HW state, since then rendering to nonzero levels would
think that the rendering overflowed the BO when it doesn't.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13668>
This should be exactly equivalent code, except for the is_3d "level <= 1"
which doesn't bring over 6c19d37331 ("freedreno/a6xx: fix 3d tex
layout") due to it failing our unit tests where we compare to the blob's
behavior. The layer_stride setup is pulling in what freedreno_resource.c
was doing after the layout setup, so we match fd6 and so that it could
potentially be checked in unit testing.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13668>
