This will allow have tests that use gtest (which is C++) for.
Note the reordering of designated initializers in structs is
because C++ requires them to follow the order that they were
defined in the struct.
The table `bifrost_reg_ctrl_lut` is not used by the tests at the
moment, so bailed out trying to replace the C syntax designated
initializer for arrays (that doesn't have an equivalent in C++), and
simply #ifdef it out when including from C++ code.
Also, use not_mod instead of not. not is a keyword in C++ and can't be
used. Luckily, the naming is not determined by the XML, so we can freely
rename.
[Alyssa: squash in not_mod]
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13684>
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>
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>
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>
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>
Caio Oliveira