For nir_to_tgsi, I want to be able to fold into the base from a vector
load_const, which the ad-hoc scalar chasing couldn't handle.
r300:
total instructions in shared programs: 1278731 -> 1256502 (-1.74%)
instructions in affected programs: 457909 -> 435680 (-4.85%)
total flowcontrol in shared programs: 8316 -> 8313 (-0.04%)
flowcontrol in affected programs: 5 -> 2 (-60.00%)
total temps in shared programs: 213687 -> 213774 (0.04%)
temps in affected programs: 13140 -> 13227 (0.66%)
total consts in shared programs: 952850 -> 949929 (-0.31%)
consts in affected programs: 386352 -> 383431 (-0.76%)
Fixes: #5781
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Acked-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14309>
This helps non-native-integers hardware where relative addressing of UBOs
has a constant offset field, and having addressing math (particularly for
D3D9) emitted as ALU ops ends up running us out of constants. For
native-integers drivers (such as softpipe), the possible-overflow check
typically triggers and we end up not folding.
r300:
total instructions in shared programs: 1279167 -> 1278731 (-0.03%)
instructions in affected programs: 50834 -> 50398 (-0.86%)
total temps in shared programs: 213736 -> 213687 (-0.02%)
temps in affected programs: 598 -> 549 (-8.19%)
total consts in shared programs: 952973 -> 952850 (-0.01%)
consts in affected programs: 26776 -> 26653 (-0.46%)
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14309>
This lets nir-to-tgsi fold the constant offset of addressing calculations
into the CONST[] reference, which is important for D3D9-era compatibility:
HW of that age has limited uniform space, and if we do the addressing math
as math in the shader for dynamic indexing, the nir_load_consts end up
taking up uniforms we don't have available.
r300:
total instructions in shared programs: 1279699 -> 1279167 (-0.04%)
instructions in affected programs: 134796 -> 134264 (-0.39%)
total instructions in shared programs: 1279699 -> 1279167 (-0.04%)
instructions in affected programs: 134796 -> 134264 (-0.39%)
total temps in shared programs: 213912 -> 213736 (-0.08%)
temps in affected programs: 2166 -> 1990 (-8.13%)
total consts in shared programs: 953237 -> 952973 (-0.03%)
consts in affected programs: 45980 -> 45716 (-0.57%)
Acked-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14309>
Commit 9da15aa3aa ("llvmpipe: enable EXT_memory_object(_fd)") enabled
the extension, but left this unimplemented.
Leaving this unimplemented causes segfaults for anyone trying to retrieve
the UUIDs, as the calling code in the state tracker does not check if the
function is implemented. This affects e.g. current Wine versions.
Set the UUID to all zeros. Although this slightly violates the vulkan
specification (since 1.2.146), the UUIDs have to match the ones from
lavapipe (lvp_get_physical_device_properties_1_1).
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5865
Fixes: 9da15aa3aa ("llvmpipe: enable EXT_memory_object(_fd)")
Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Reviewed-by: Dave Airlie airlied@redhat.com
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14558>
Having only magic constants instead of human-readable strings in
traces not only hinders readability, but also may affect trace
comparision of old and new traces if new enums have been added
or modified (thus possibly changing the values of existing ones.)
So we implement printing of enum names as strings instead.
In order to have those strings, we need to add some new helper
functions, which we will automatically generate from header file
src/gallium/include/pipe/p_defines.h via a new Python script
enums2names.py.
We also bolt this all into the Meson build system.
Link: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4609
Signed-off-by: Matti Hamalainen <ccr@tnsp.org>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14398>
When doing copies of descriptors from one set to another, that contain
either a UNIFORM_BUFFER or STORAGE_BUFFER, both the buffer view &
surface state are allocated from the source descriptor. Therefore we
need to copy their content otherwise we could run into lifecycle
issues when the source descriptor is destroyed.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14585>
many times it will be the case that an allocation for a block of data
needs to be done in one alloc() call such that the members of a struct as well
as some extra trailing data are all in the same allocation like
```
struct Test {
unsigned a[4];
unsigned c;
};
unsigned *b; //ptr to uint[8]
```
should be allocated as a single block of (13 * sizeof(unsigned)) memory using
C pointer offsets to allocate the memory as
```
| Test | b |
```
with something like
```
struct Test *t = malloc(sizeof(struct Test) + (8 * sizeof(unsigned)));
```
and then set `b` with
```
t->b = ((uint8_t*)t) + sizeof(struct Test);
```
this is annoying, awful to read, and (at least for dum-dums like me) prone to errors,
however, so having some utility functions which can deliver the same
functionality with better readability helps out this case by transforming it to
```
unsigned *b;
void **ptrs[] = {(void*)&b};
size_t sizes[] = {8 * sizeof(unsigned));
struct Test *t = ptralloc(sizeof(struct Test), 1, sizes, ptrs);
```
where `b` is now set to the appropriate offset in memory
Acked-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13678>
Broadwell introduced new fields in 3DSTATE_SBE which allow us to ask
the hardware to override Primitive ID for us, rather than requiring us
to turn on attribute swizzling and specify per-attribute overrides in
3DSTATE_SBE_SWIZ. We unconditionally enable attribute swizzling today,
but this is a step toward letting us think about disabling it in the
future.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14210>
VARYING_SLOT_{VIEWPORT,LAYER,PSIZ} all live in the same VUE header slot,
and the FS is already set up to read the x/y/z/w component of that vec4.
However, we were setting up the SBE to pass each of those items as a
separate FS input, so hypothetically if a shader read all three, we
would burn 3 FS inputs with redundant data. Not only was this passing
extra data to the FS, but it would count as extra input slots for the
"Do we have 16 or fewer attributes?" check for using SBE swizzling to
rearrange them in a convenient manner.
Now we make them share a single FS attribute and only count them once.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14210>
Dave Airlie