Rather than relying on distro packages, build libwayland and
wayland-protocols from known versions everywhere we need it.
The only place we do not do so but rely on distro packages is the LAVA
rootfs, for which it does not matter right now since the version is
sufficiently new, but this could/should be cleaned up later.
Solved Conflicts:
- .gitlab-ci.yml
- .gitlab-ci/container/build-wayland.sh
- .gitlab-ci/container/debian/x86_test-gl.sh
Signed-off-by: Daniel Stone <daniels@collabora.com>
(cherry picked from commit a2fd507973)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19928>
As discussed at #freedesktop@OFTC, we decided to remove test jobs from
Amber branch, only keeping the build ones.
The main reason for that is that this branch is not being updated often
enough with backports to keep the test jobs green.
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19928>
We don't need to login anymore, but we can't use plain minio commands
now. `ci-fairy` got a helper as `s3cp` to keep an almost identical
API.
Solved Conflicts:
.gitlab-ci.yml
.gitlab-ci/common/init-stage2.sh
.gitlab-ci/container/lava_build.sh
.gitlab-ci/lava/lava-submit.sh
.gitlab-ci/piglit/piglit-traces.sh
.gitlab-ci/prepare-artifacts.sh
.gitlab-ci/test/gitlab-ci.yml
src/broadcom/ci/traces-broadcom.yml
src/freedreno/ci/gitlab-ci.yml
src/gallium/drivers/crocus/ci/traces-crocus.yml
src/gallium/drivers/virgl/ci/traces-virgl-iris.yml
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
(cherry picked from commit 67cee534a8)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19928>
Along with fixing the grammar, this allows it to be deduplicated since
the properly worded description exists in later generations' XMLs.
Cuts 96 B from iris_dri.so and libvulkan_intel.so.
text data bss dec hex filename
917613 0 0 917613 e006d meson-generated_.._intel_perf_metrics.c.o (before)
917511 0 0 917511 e0007 meson-generated_.._intel_perf_metrics.c.o (after)
text data bss dec hex filename
14131044 365708 210004 14706756 e06844 iris_dri.so (before)
14130948 365708 210004 14706660 e067e4 iris_dri.so (after)
text data bss dec hex filename
8124321 214264 22820 8361405 7f95bd libvulkan_intel.so (before)
8124225 214264 22820 8361309 7f955d libvulkan_intel.so (after)
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
(cherry picked from commit d80d3c6760)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16405>
The compiler does a good job of deduplicating strings already, but we
can eliminate the pointers to each string by combining the strings into
a single char array and storing only an index into that array.
The longest of the char arrays is the descriptions array, which is a
little over 45 KiB, so still under MSVC's 64 KiB string literal limit
[0]. Because the string length is under 64 KiB we can use uint16_t as
the index type, which roughly doubles our savings as compared to an int.
This cuts 77 KiB from iris_dri.so (0.5%) and libvulkan_intel.so (0.9%).
text data bss dec hex filename
926811 25920 0 952731 e899b meson-generated_.._intel_perf_metrics.c.o (before)
924401 0 0 924401 e1af1 meson-generated_.._intel_perf_metrics.c.o (after)
text data bss dec hex filename
14190852 391628 210004 14792484 e1b724 iris_dri.so (before)
14137732 365708 210004 14713444 e08264 iris_dri.so (after)
text data bss dec hex filename
8184097 240184 22820 8447101 80e47d libvulkan_intel.so (before)
8131009 214264 22820 8368093 7fafdd libvulkan_intel.so (after)
relinfo:
iris_dri.so (before): 17765 relocations, 17545 relative (98%), 452 PLT entries, 1 for local syms (0%), 0 users
iris_dri.so (after) : 15605 relocations, 15385 relative (98%), 452 PLT entries, 1 for local syms (0%), 0 users
libvulkan_intel.so (before): 10720 relocations, 6989 relative (65%), 355 PLT entries, 1 for local syms (0%), 0 users
libvulkan_intel.so (after) : 8560 relocations, 4829 relative (56%), 355 PLT entries, 1 for local syms (0%), 0 users
[0] https://docs.microsoft.com/en-us/cpp/cpp/string-and-character-literals-cpp?view=msvc-170&viewFallbackFrom=vs-2019
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
(cherry picked from commit 6c0246dcf4)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16405>
intel_perf_query_counter contains fields for things we can't or don't
want to store in our static data (like runtime-determined max values) or
oa_read_counter function pointers which are dependent on the GPU gen and
would make deduplication very ineffective.
Cuts 16 KiB from iris_dri.so and libvulkan_intel.so.
text data bss dec hex filename
926811 43200 0 970011 ecd1b meson-generated_.._intel_perf_metrics.c.o (before)
926811 25920 0 952731 e899b meson-generated_.._intel_perf_metrics.c.o (after)
text data bss dec hex filename
14190852 408908 210004 14809764 e1faa4 iris_dri.so (before)
14190852 391628 210004 14792484 e1b724 iris_dri.so (after)
text data bss dec hex filename
8184097 257464 22820 8464381 8127fd libvulkan_intel.so (before)
8184097 240184 22820 8447101 80e47d libvulkan_intel.so (after)
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
(cherry picked from commit df5e743c80)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16405>
And specifically mark it with ATTRIBUTE_NOINLINE. Otherwise it will be
inlined and actually slightly increase code size.
Cuts 505 KiB from iris_dri.so and libvulkan_intel.so.
text data bss dec hex filename
1538720 0 0 1538720 177aa0 meson-generated_.._intel_perf_metrics.c.o (before)
926811 43200 0 970011 ecd1b meson-generated_.._intel_perf_metrics.c.o (after)
text data bss dec hex filename
14751700 365708 210004 15327412 e9e0b4 iris_dri.so (before)
14190852 408908 210004 14809764 e1faa4 iris_dri.so (after)
text data bss dec hex filename
8744913 214264 22820 8981997 890ded libvulkan_intel.so (before)
8184097 257464 22820 8464381 8127fd libvulkan_intel.so (after)
Relocations increase because the counter initializations are moved from
code (in .text) to pointers (in .text) to .rodata, which require
relocations.
relinfo:
iris_dri.so (before): 15605 relocations, 15385 relative (98%), 452 PLT entries, 1 for local syms (0%), 0 users
iris_dri.so (after) : 17765 relocations, 17545 relative (98%), 452 PLT entries, 1 for local syms (0%), 0 users
libvulkan_intel.so (before): 8560 relocations, 4829 relative (56%), 355 PLT entries, 1 for local syms (0%), 0 users
libvulkan_intel.so (after) : 10720 relocations, 6989 relative (65%), 355 PLT entries, 1 for local syms (0%), 0 users
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
(cherry picked from commit bbbbb0325b)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16405>
No changes in resulting code (yes, seriously!). GCC constant propagates
the static const arrays into the code, yielding bit for bit identical
results. This will however enable further cleanups.
Before this patch, we emit 11916 different initializations of
intel_perf_query_counter. With this patch we emit an array of 539 and
initialize the intel_perf_query_counters in terms of those.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
(cherry picked from commit 5e6c7a572e)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16405>
this fixes desync+crash when:
1. usage is added for bs A
2. tracking is added for bs B
3. tracking is removed for bs B
4. context is destroyed
5. usage A is now dangling and will crash if accessed
as seen in glmark2
cc: mesa-stable
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15429>
(cherry picked from commit 7da211e24f)
This fixes the test_resolve_non_issued_query_data vkd3d-proton test.
This change is required on TGL+ (maybe ICL?) because on all platforms
3D pipeline writes are not coherent with CS. On previous platform we
fixed this by flushing the render cache to make sure data is visble to
CS before it writes to memory. But on more recently platforms,
flushing the render cache leaves the data in the tile cache which is
still not coherent with CS, so we need to flush that one too.
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/14552>
(cherry picked from commit 8b71118aa0)
Most of the time, this doesn't matter. On the versions with _sat, if
the destination type is incorrect, the clamping will not happen
correctly.
Fixes the following CTS tests:
dEQP-VK.spirv_assembly.instruction.compute.opudotaccsatkhr.all_packed_ss_v4i8_out32
dEQP-VK.spirv_assembly.instruction.compute.opudotaccsatkhr.all_packed_su_v4i8_out32
dEQP-VK.spirv_assembly.instruction.compute.opudotaccsatkhr.all_packed_us_v4i8_out32
dEQP-VK.spirv_assembly.instruction.compute.opudotaccsatkhr.all_packed_uu_v4i8_out32
dEQP-VK.spirv_assembly.instruction.compute.opudotaccsatkhr.all_ss_v4i8_out32
dEQP-VK.spirv_assembly.instruction.compute.opudotaccsatkhr.all_su_v4i8_out32
dEQP-VK.spirv_assembly.instruction.compute.opudotaccsatkhr.all_us_v4i8_out32
dEQP-VK.spirv_assembly.instruction.compute.opudotaccsatkhr.all_uu_v4i8_out32
dEQP-VK.spirv_assembly.instruction.compute.opudotaccsatkhr.limits_packed_ss_v4i8_out32
dEQP-VK.spirv_assembly.instruction.compute.opudotaccsatkhr.limits_packed_su_v4i8_out32
dEQP-VK.spirv_assembly.instruction.compute.opudotaccsatkhr.limits_packed_us_v4i8_out32
dEQP-VK.spirv_assembly.instruction.compute.opudotaccsatkhr.limits_packed_uu_v4i8_out32
dEQP-VK.spirv_assembly.instruction.compute.opudotaccsatkhr.limits_ss_v4i8_out32
dEQP-VK.spirv_assembly.instruction.compute.opudotaccsatkhr.limits_su_v4i8_out32
dEQP-VK.spirv_assembly.instruction.compute.opudotaccsatkhr.limits_us_v4i8_out32
dEQP-VK.spirv_assembly.instruction.compute.opudotaccsatkhr.limits_uu_v4i8_out32
dEQP-VK.spirv_assembly.instruction.compute.opudotaccsatkhr.small_packed_ss_v4i8_out32
dEQP-VK.spirv_assembly.instruction.compute.opudotaccsatkhr.small_packed_su_v4i8_out32
dEQP-VK.spirv_assembly.instruction.compute.opudotaccsatkhr.small_packed_us_v4i8_out32
dEQP-VK.spirv_assembly.instruction.compute.opudotaccsatkhr.small_packed_uu_v4i8_out32
dEQP-VK.spirv_assembly.instruction.compute.opudotaccsatkhr.small_ss_v4i8_out32
dEQP-VK.spirv_assembly.instruction.compute.opudotaccsatkhr.small_su_v4i8_out32
dEQP-VK.spirv_assembly.instruction.compute.opudotaccsatkhr.small_us_v4i8_out32
dEQP-VK.spirv_assembly.instruction.compute.opudotaccsatkhr.small_uu_v4i8_out32
v2: Update anv-tgl-fails.txt.
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Fixes: 0f809dbf40 ("intel/compiler: Basic support for DP4A instruction")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15417>
(cherry picked from commit 19330eeb1d)
If you hadn't already called wsi_GetPhysicalDeviceDisplayProperties2KHR or
wsi_GetDrmDisplayEXT before calling
GetPhysicalDeviceDisplayPlaneProperties2KHR, then the connectors list
wouldn't be populated and you'd get no plane properties. Fixes failure of
dEQP-VK.wsi.display.get_display_plane_capabilities when run on its own.
Fixes: #4575
Cc: mesa-stable
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15353>
(cherry picked from commit da834a12cf)
Handle arrays generically by using the last component of the coordinate source
as the array index. That works for both 2D arrays and cube arrays, fixing cube
arrays. Cube arrays were already handled correctly in core Panfrost code.
This code path is not tested in dEQP-GLES31 without exposing OES_cube_map_array,
which depends on OES_geometry_shader, which we don't have. Yet we do expose
PIPE_CAP_CUBE_ARRAY, so ARB_cube_map_array is exposed.
Disabling PIPE_CAP_CUBE_ARRAY would be an easy band-aid fix, but it's easy
enough to handle correctly.
dEQP-GLES31 passes with a hack enabling OES_cube_map_array [without geometry
shaders].
Also fixes 1D arrays on Bifrost for the same reasons.
Fixes: 70d6c5675d ("pan/bi: Emit TEXC with builder")
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15254>
(cherry picked from commit 53f1e57ee7)
Hardware support was removed with Midgard. Use mesa/st to emulate GL_CLAMP with
nir_lower_tex automatically (the Zink lowering), and disable GL_MIRROR_CLAMP
which isn't lowered correctly.
Fixes *texwrap* Piglit tests on G52.
Fixes: f9ceab7b23 ("panfrost: Fix CLAMP wrap mode")
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15253>
(cherry picked from commit 1f97819fbe)
The Vulkan spec for VK_KHR_depth_stencil_resolve allows a format
mismatch between the primary attachment and the resolve attachment
within certain limits. In particular,
VUID-VkSubpassDescriptionDepthStencilResolve-pDepthStencilResolveAttachment-03181
If pDepthStencilResolveAttachment is not NULL and does not have the
value VK_ATTACHMENT_UNUSED and VkFormat of
pDepthStencilResolveAttachment has a depth component, then the
VkFormat of pDepthStencilAttachment must have a depth component with
the same number of bits and numerical type
VUID-VkSubpassDescriptionDepthStencilResolve-pDepthStencilResolveAttachment-03182
If pDepthStencilResolveAttachment is not NULL and does not have the
value VK_ATTACHMENT_UNUSED, and VkFormat of
pDepthStencilResolveAttachment has a stencil component, then the
VkFormat of pDepthStencilAttachment must have a stencil component
with the same number of bits and numerical type
So you can resolve from a depth/stencil format to a depth-only or
stencil-only format so long as the number of bits matches.
Unfortunately, this has never been tested because the CTS tests which
purport to test this are broken and actually test with a destination
combined depth/stencil format.
Fixes: 5e4f9ea363 ("anv: Implement VK_KHR_depth_stencil_resolve")
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15333>
(cherry picked from commit d65dbe8018)
in the initial implementation, a stream like:
* CmdBeginTransformFeedbackEXT
* CmdSetRasterizerDiscardEnableEXT
* CmdDraw
* CmdEndTransformFeedbackEXT
* CmdBeginTransformFeedbackEXT
* CmdDraw
* CmdEndTransformFeedbackEXT
would never enable transform feedback, as it only checked for the change
in rasterizer_discard state
Fixes: 4d531c67df ("anv: support rasterizer discard dynamic state")
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15269>
(cherry picked from commit 52f6978484)
for genuine early depth tests, the samplecount must be updated after depth
test but before samplemask is applied
for inferred-early or regular depth tests, the samplemask can be applied
before the depth test
Fixes: d9276ae965 ("llvmpipe: handle gl_SampleMask writing.")
fixes:
dEQP-VK.fragment_operations.early_fragment.sample_count_early_fragment_tests_depth_samples_4
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15319>
(cherry picked from commit 42e78ba125)
we can effectively skip any kind of checks here and just assume that one
of two scenarios is in effect:
* the user is about to attempt some incredibly illegal behavior that VVL will catch
* the user is about to attempt a pro gamer move and we'll be fine
in either case, it's EXTENDED_USAGE, so hopefully we're about to make a texture
view from a compatible and supported format
cc: mesa-stable
fixes:
dEQP-VK.image.extended_usage_bit_compatibility.image_format_properties*
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15320>
(cherry picked from commit 6a4c7ef728)
For pcopies we only care about the register's type, i.e. whether its a
half-register and whether it's an array (plus its size). Copying over
other flags like IR3_REG_RELATIV just leads to sadness and validator
assertions.
Fixes: 0ffcb19b9d ("ir3: Rewrite register allocation")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14107>
(cherry picked from commit ab0ed4ff3f)
this hardware won't return the correct value from dmod instructions,
so lower it to ensure that cts passes
nobody else will ever hit this, so perf isn't an issue and regular fmod
can be left alone
fixes (amd):
KHR-GL46.gpu_shader_fp64.builtin.mod_d*
Fixes: 5fae35fb17 ('zink: fix 64bit float shader ops ')
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15306>
(cherry picked from commit c24bca2d3a)
The multiViewport feature isn't required for GL 4.3, it's required for
GL 4.1. Technically speaking, we could have just dropped it because we
already list the maxViewports requirement. But it seems better to be
very clear here to me.
Fixes: 29f8f21bff ("docs: document zink GL 4.3 requirements")
Acked-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15300>
(cherry picked from commit e666134975)
this was being set from back before zink actually supported 64bit
natively and only 32bit was functional, but it breaks 64bit support
cc: mesa-stable
fixes (lavapipe):
KHR-GL46.gpu_shader_fp64.builtin.mod_dvec2
KHR-GL46.gpu_shader_fp64.builtin.mod_dvec3
KHR-GL46.gpu_shader_fp64.builtin.mod_dvec4
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15274>
(cherry picked from commit 5fae35fb17)
When using indirect textures, some lanes may not be active,
particularly in a loop, so as with some other areas, extracting
the correct lane is needed here. This extracts the last valid one.
KHR-GL45.texture_barrier.* on zink.
Fixes: e168d148d7 ("gallivm/nir: handle non-uniform texture offsets")
Acked-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15259>
(cherry picked from commit 8346983775)
when migrating a recycled set here, the set was previously invalid and
in the recycled table, meaning it can be reused directly so long as
it's first invalidated
the previous code would instead pop a different set off the allocation array,
leaking this one
cc: mesa-stable
Acked-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15226>
(cherry picked from commit d63f3c31b7)
this got mixed up during some refactor and started indexing based on the
number of bindings instead of the number of descriptors, which means
that array descriptor bindings would have overlapping array memory
cc: mesa-stable
Acked-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15226>
(cherry picked from commit ab3725f533)
the variant data may have changed in the meanwhile, so do a pass to
ensure that the correct variant is used
cc: mesa-stable
fixes caselist:
dEQP-GLES31.functional.shaders.sample_variables.sample_mask.discard_half_per_two_samples.multisample_texture_4
dEQP-GLES31.functional.shaders.sample_variables.sample_mask.discard_half_per_two_samples.singlesample_rbo
Acked-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15226>
(cherry picked from commit 9a6c58b2f7)
BITSET_MASK returns ~0 when given an input of zero, when we need it to
return 0 instead.
Fixes shaders with only sysvals but no UBOs when push constants are
disabled.
This breaks when 31 or 32 UBOs are used, but PAN_MAX_CONST_BUFFERS is
currently set to 16.
Fixes: c246af0dd8 ("panfrost: Only upload UBOs when needed")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15250>
(cherry picked from commit 9d4441c71a)
This could be made slightly more efficient by only setting the dirty
state that is needed, but eventually you reach a point where it's
cheaper to re-emit everything than work out what can or can't be kept.
Fixes rendering issues in Duckstation.
Fixes: cd2c1ef9da ("panfrost: Dirty track textures/samplers")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15250>
(cherry picked from commit d6c431c2e3)
TEXC can have two destinations; the value for neither of them can be
used in the same bundle, so extend the code to check for this to
iterate over both destinations.
Fixes artefacts in the game "LIMBO".
Fixes: a303076c1a ("pan/bi: Add bi_instr_schedulable predicate")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15250>
(cherry picked from commit cb8c47b15e)
Because we have to maintain two different packages of Mesa, one
specific to RADV and another one for RadeonSI and such, it's a bit
annoying to have to synchronize the drirc entries. Currently, only our
Mesa package installs 00-mesa-defaults.conf which means we have to
backport the drirc RADV changes.
This splits 00-mesa-defaults.conf in two to move the drirc RADV entries
to src/amd/vulkan/00-radv-defaults.conf. Meson will install the file
only if RADV is built.
There is still a caveat for common drirc workarounds like for WSI but
they are rare enough and we could still duplicate them if needed.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15152>
(cherry picked from commit 53ca85ac2a)
When we shadow a resource, the backing BO is changed; as such,
existing references to the resource become invalid. So batches accessing the
resource need to be flushed (or otherwise have their references invalidated).
The wrong behaviour change (not flushing) was introduced when we started
tracking resources instead of BOs. The issue manifested as a severe performance
regression in glmark2's -bbuffer test, particular the subdata subtest. The issue
is magnified on slow CPUs; without the fix, the test becomes completely CPU
bound
Relevant glmark2 -bbuffer test from 43fps to 84fps.
Apparently, this causes functional issues too -- this performance-minded change
also fixes a few piglits.
Fixes: cecb889481 ("panfrost: Do tracking of resources, not BOs")
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reported-by: Chris Healy <cphealy@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13502>
(cherry picked from commit 988d5aae74)
When handle->type is WINSYS_HANDLE_TYPE_FD, the caller wants a file descriptor
for the BO backing the resource. We previously had two paths for this:
1. If rsrc->scanout is available, we prime the GEM handle from the KMS device
(rsrc->scanout->handle) to a file descriptor via the KMS device.
2. If rsrc->scanout is not available, we prime the GEM handle from the GPU
(bo->gem_handle) to a file descriptor via the GPU device.
In both cases, the caller passes in a resource (with BO) and expects out a file
descriptor. There are no direct GEM handles in the function signature; the
caller doesn't care which GEM handle we prime to get the file descriptor. In
principle, both paths produce the same file descriptor for the same BO, since
both GEM handles represent the same underlying resource (viewed from different
devices).
On grounds of redundancy alone, it makes sense to remove the rsrc->scanout path.
Why have a path that only works sometimes, when we have another path that works
always?
In fact, the issues with the rsrc->scanout path are deeper. rsrc->scanout is
populated by renderonly_create_gpu_import_for_resource, which does the
following:
1. Get a file descriptor for the resource by resource_get_handle with
WINSYS_HANDLE_TYPE_FD
2. Prime the file descriptor to a GEM handle via the KMS device.
Here comes strike number 2: in order to get a file descriptor via the KMS
device, we had to /already/ get a file descriptor via the GPU device. If we go
down the KMS device path, we effectively round trip:
GPU handle -> fd -> KMS handle -> fd
There is no good reason to do this; if everything works, the fd is the same in
each case. If everything works. If.
The lifetimes of the GPU handle and the KMS handle are not necessarily bound. In
principle, a resource can be created with scanout (constructing a KMS handle).
Then the KMS view can be destroyed (invalidating the GEM handle for the KMS
device), even though the underlying resource is still valid. Notice the GPU
handle is still valid; its lifetime is tied to the resource itself. Then a
caller can ask for the FD for the resource; as the resource is still valid, this
is sensible. Under the scanout path, we try to get the FD by priming the GEM
handle on the KMS device... but that GEM handle is no longer valid, causing the
PRIME ioctl to fail with ENOENT. On the other hand, if we primed the GPU GEM
handle, everything works as expected.
These edge cases are not theoretical; recent versions of Xwayland trigger this
ENOENT, causing issue #5758 on all Panfrost devices. As far as I can tell, no
other kmsro driver has this 'special' kmsro path; the only part of
resource_get_handle that needs special handling for kmsro is getting a KMS
handle.
Let's remove the broken, useless path, fix Xwayland, bring us in line with other
drivers, and delete some code.
Thank you for coming to my ted talk.
Closes: #5758
Fixes: 7da251fc72 ("panfrost: Check in sources for command stream")
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reported-and-tested-by: Jan Palus <jpalus@fastmail.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: James Jones <jajones@nvidia.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Tested-by: Dan Johansen <strit@manjaro.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15120>
(cherry picked from commit b5734cc1c4)
We only have a single prog_data::total_scratch for all shader variants
(SIMD 8, 16, 32). Therefore we should always max the total_scratch on
top of existing variant.
We probably haven't run into that issue before because we compile by
increasing SIMD size and higher SIMD size is more likely to spill. But
for bindless shaders with return shaders, if the last return part
doesn't spill, we completely ignore the previous parts' scratch
computation.
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/15193>
(cherry picked from commit 96c8880900)
ncoords includes the array index, and the NIR source has the array index
as its last component, so we have to insert the extra y coordinate in
the middle in this case.
Fixes: 0bb0cac ("freedreno/ir3: handle image buffer")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15114>
(cherry picked from commit 58d72f45e5)
On mips64, the compiler does not allow use of non-zero argument with
__builtin_frame_address(). However, the returned frame address is only
used when PIPE_ARCH_X86 is defined. The compile error can be avoided
by making #ifdef PIPE_ARCH_X86 cover the getting of frame address too.
The argument checking of __builtin_frame_address() has been present
as a debug assert in clang 8. In clang 10, there is a proper runtime
check for the argument. This is why the build has not failed before.
Fixes: dc94a0506f ("gallium: Do not add -Wframe-address option for gcc <= 4.4.")
from Visa Hankala
Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6511>
(cherry picked from commit 0536b69133)
Make this build on clang architectures that don't have 64-bit atomic
instructions. Clang doesn't allow redeclaration (and therefore
redefinition) of the __sync_* builtins. Use #pragma redefine_extname
to work around that restriction. Clang also turns __sync_add_and_fetch
into __sync_fetch_and_add (and __sync_sub_and_fetch into
__sync_fetch_and_sub) in certain cases, so provide these functions as
well.
Fixes: a6a38a038b ("util/u_atomic: provide 64bit atomics where they're missing")
patch from Mark Kettenis
Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6511>
(cherry picked from commit f12c107b03)
Correct type for sysctl argument to fix the build.
../src/util/u_cpu_detect.c:631:29: error: incompatible pointer types passing 'int *' to parameter of type 'size_t *' (aka 'unsigned long *') [-Werror,-Wincompatible-pointer-types]
sysctl(mib, 2, &ncpu, &len, NULL, 0);
^~~~
Fixes: 5623c75e40 ("util: Fix setting nr_cpus on some BSD variants")
Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13448>
(cherry picked from commit afece589dc)
This extension isn't wired up in Gallium, so there's just no way a
Gallium driver like Panfrost exposes it.
While there were support in i965 for this for the cancelled Broxton GPU,
thre's no such support in the Iris driver. And since Broxton has been
cancelled, it's unlikely to be wired up any time soon.
Fixes: da23a31726 ("docs/features: Update ASTC entries for Panfrost")
Acked-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15145>
(cherry picked from commit 834db3aa8d)
Otherwise a shader invocation would read the value which should have
been set AFTER this shader invocation.
Fixes tests:
dEQP-VK.rasterization.rasterization_order_attachment_access.depth.samples_1.multi_draw_barriers
dEQP-VK.rasterization.rasterization_order_attachment_access.stencil.samples_1.multi_draw_barriers
Fixes: 71595a189a
("tu: Fix feedback loops in sysmem mode")
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15106>
(cherry picked from commit dab34bd5c8)
If a secondary command buffer is used and the client provides a
framebuffer and that framebuffer has a stencil-only attchment, we would
try to get the aux usage for the depth component of that attachment and
crash. Check the aspects of the image before looking at aux usage.
This fixes at least the following SkQP tests on my Tigerlake:
- vk_circular-clips
- vk_filterfastbounds
- vk_innershapes_bw
- vk_lineclosepath
- vk_multipicturedraw_rrectclip_simple
- vk_pathinvfill
- vk_quadclosepath
- vk_rrect_clip_bw
- vk_windowrectangles
Fixes: 0d8b9c529c ("anv: Allow PMA optimization to be enabled in secondary command buffers")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Tested-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15048>
(cherry picked from commit df0e2a1565)
XeHP scratch space is handled differently. Commit ae18e1e707
implemented support for it, but handled it differently between render
and compute shaders: it calculates scratch_addr differently and
doesn't pin the buffer on compute. Make it work on compute shaders by
calling pin_scratch_space() from iris_compute_walker(), which fixes
both the address and the pinning.
This commit can be verified by the two-year-old-but-still-unreviewed
Piglit MR 234. You can also verify this by running a very simple
compute shader with INTEL_DEBUG=spill_fs.
References: https://gitlab.freedesktop.org/mesa/piglit/-/merge_requests/234
Fixes: ae18e1e707 ("iris: Add support for scratch on XeHP")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15070>
(cherry picked from commit d10fd5b7c9)
Setting amber to true changes these defaults:
- glvnd defaults to enabled
- the glvnd vendor name is set to "amber"
- the gallium and vulkan drivers are disabled
- prefer-iris defaults to false
- eglQueryString(EGL_VENDOR) returns "Mesa Project (Amber)"
The megadriver for the classic driver set will be installed to a file
name unique from Mesa main. Beyond that no attempt is made to use
filenames different from main - particularly not if glvnd is explicitly
disabled - so you would still need to configure your install paths
appropriately so things don't collide, if you want them to not collide.
But if you have that problem, consider that glvnd already solves it.
This has a quiet dependency on glapi and gbm's library API remaining
stable. gbm you could fix by linking it statically, glapi is a little
harder. I think the right move for glapi is to use glvnd's gldispatch
more directly, but that's not public API at the moment.
Reviewed-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10557>
this otherwise treates begin/end/begin the same as begin/pause/resume
cc: mesa-stable
fixes:
KHR-GL46.texture_view.view_classes
KHR-GL46.transform_feedback.capture_geometry_separate_test
KHR-GL46.transform_feedback.capture_vertex_separate_test
KHR-GL46.transform_feedback.query_geometry_separate_test
KHR-GL46.transform_feedback.query_vertex_separate_test
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15020>
(cherry picked from commit e8ba9cee27)
by initializing this on context creation, we can ensure that the correct
value is always here
cc: mesa-stable
fixes:
dEQP-GLES31.functional.texture.multisample.samples_1.sample_mask_and_alpha_to_coverage
dEQP-GLES31.functional.texture.multisample.samples_1.sample_mask_and_sample_coverage
dEQP-GLES31.functional.texture.multisample.samples_1.sample_mask_and_sample_coverage_and_alpha_to_coverage
dEQP-GLES31.functional.texture.multisample.samples_1.sample_mask_only
dEQP-GLES31.functional.texture.multisample.samples_2.sample_mask_and_alpha_to_coverage
dEQP-GLES31.functional.texture.multisample.samples_2.sample_mask_and_sample_coverage
dEQP-GLES31.functional.texture.multisample.samples_2.sample_mask_and_sample_coverage_and_alpha_to_coverage
dEQP-GLES31.functional.texture.multisample.samples_2.sample_mask_only
dEQP-GLES31.functional.texture.multisample.samples_3.sample_mask_and_alpha_to_coverage
dEQP-GLES31.functional.texture.multisample.samples_3.sample_mask_and_sample_coverage
dEQP-GLES31.functional.texture.multisample.samples_3.sample_mask_and_sample_coverage_and_alpha_to_coverage
dEQP-GLES31.functional.texture.multisample.samples_3.sample_mask_only
dEQP-GLES31.functional.texture.multisample.samples_4.sample_mask_and_alpha_to_coverage
dEQP-GLES31.functional.texture.multisample.samples_4.sample_mask_and_sample_coverage
dEQP-GLES31.functional.texture.multisample.samples_4.sample_mask_and_sample_coverage_and_alpha_to_coverage
dEQP-GLES31.functional.texture.multisample.samples_4.sample_mask_only
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14974>
(cherry picked from commit 8ff96efcfd)
Commit 38800b38 changed nir_opcodes.py, but that doesn't seem to have
triggered nir_opt_algebraic.py. The change in 75ef5991 depends on
opt_algebraic lowering 16-bit versions of slt, but if opt_algebraic is
not rebuilt, this may not happen. This resulted in some people seeing
assertion failures in, for example,
dEQP-VK.spirv_assembly.instruction.compute.float16.arithmetic_3.step,
due to the backend seeing nir_op_slt that it didn't know how to handle.
v2: Add nir_opcodes.py to nir_algebraic_py so that all the per-driver
algebraic passes pick up the dependency too. Rename it to
nir_algebraic_depends. Suggested by Emma.
Closes: #6047
Fixes: d1992255bb ("meson: Add build Intel "anv" vulkan driver")
Reviewed-by: Emma Anholt <emma@anholt.net>
Acked-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15050>
(cherry picked from commit a01b262990)
memcpy is divided into chunks that are vec4 sized max. The problem
here happens with a structure of 24 bytes :
struct {
float3 a;
float3 b;
}
If you memcpy that struct, the lowering will emit 2 load/store, one of
sized 8, next one sized 16. But both end up located at offset 0, so we
effectively drop 2 floats.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: a3177cca99 ("nir: Add a lowering pass to lower memcpy")
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15049>
(cherry picked from commit 768930a73a)
With the recent addition of the shortcuts aiming to avoid atomic
operations, the reference count on resources can become unbalanced
in the Tegra driver since they are wrapped and then proxied to the
Nouveau driver.
Fix this by keeping a private reference count.
Fixes: 7688b8ae98 ("st/mesa: eliminate all atomic ops when setting vertex buffers")
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Tested-by: Karol Herbst <kherbst@redhat.com>
(cherry picked from commit 108e6eaa83)
With the recent addition of the shortcuts aiming to avoid atomic
operations, the reference count on sampler views can become unbalanced
in the Tegra driver since they are wrapped and then proxied to the
Nouveau driver.
Fix this by keeping a private reference count.
Fixes: ef5d427413 ("st/mesa: add a mechanism to bypass atomics when binding sampler views")
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Tested-by: Karol Herbst <kherbst@redhat.com>
(cherry picked from commit e8ce0a3357)
Once we simplified a phi node, we never updated the definition it points
to, which meant that it could become out of date if that definition were
also simplified, and we didn't check that when rewriting sources. That
could happen when there are multiple nested loops with phi nodes at the
header.
Fix it by updating the phi's pointer. Since we always update sources
after visiting the definition it points to, when we go to rewrite a
source, if that source points to a simplified phi, the phi's pointer
can't be pointing to a simplified phi because we already visited the phi
earlier in the pass and updated it, or else it's been simplified in the
meantime and this isn't the last pass. This way we don't need to
keep recursing when rewriting sources.
Fixes: 613eaac7b5 ("ir3: Initial support for spilling non-shared registers")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15035>
(cherry picked from commit 3ef858a6f6)
This fixes artifacts seen in games when using ASTC transcoding,
we need to use DXT5 for proper alpha channel support.
Number of components is a block specific property, there is no easy
way to see if we will require >1bit alpha support or not, so simply
use DXT5 to have support in place.
Fixes: 91cbe8d855 ("gallium: Add a transcode_astc driconf option")
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15029>
(cherry picked from commit d3b4202b63)
This wasn't much of a problem before because vk_command_buffer_finish()
doesn't do much on an empty command buffer. However, it's about to be
responsible for managing the pool's list of command buffers so it will
be critical to get this right.
Fixes: c9189f4813 ("anv: Use a common vk_command_buffer structure")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14917>
(cherry picked from commit 7b0e306854)
Properly handling NaN adversely affects several hundred shaders in
shader-db (lots of Skia and a few others from various synthetic
benchmarks) and fossil-db (mostly Talos and some Doom 2016). Only apply
the NaN handling work-around when the shader demands it.
v2: Add comment explaining the 1.0*y_over_x. Suggested by Caio.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Fixes: 2098ae16c8 ("nir/builder: Move nir_atan and nir_atan2 from SPIR-V translator")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13999>
(cherry picked from commit 1cb3d1a6ae)
frexp_sig of ±0, ±Inf, or NaN should just return the input unmodified.
frexp_exp of ±Inf or NaN is undefined, and frexp_exp of ±0 should return
the input unmodified. This seems to already work.
No shader-db or fossil-db changes on any Intel platform.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Fixes: 23d30f4099 ("spirv,nir: lower frexp_exp/frexp_sig inside a new NIR pass")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13999>
(cherry picked from commit 7d0d9b9fbc)
NOTE: This commit needs "nir: All set-on-comparison opcodes can take all
float types" or regressions will occur in other Vulkan SPIR-V tests.
No shader-db changes on any Intel platform.
NOTE: This commit depends on "nir: All set-on-comparison opcodes can
take all float types".
v2: Fix handling 16-bit (and presumably 64-bit) values.
About 280 shaders in Talos are hurt by a few instructions, and a couple
shaders in Doom 2016 are hurt by a few instructions.
Tiger Lake
Instructions in all programs: 159893290 -> 159895026 (+0.0%)
SENDs in all programs: 6936431 -> 6936431 (+0.0%)
Loops in all programs: 38385 -> 38385 (+0.0%)
Cycles in all programs: 7019260087 -> 7019254134 (-0.0%)
Spills in all programs: 101389 -> 101389 (+0.0%)
Fills in all programs: 131532 -> 131532 (+0.0%)
Ice Lake
Instructions in all programs: 143624235 -> 143625691 (+0.0%)
SENDs in all programs: 6980289 -> 6980289 (+0.0%)
Loops in all programs: 38383 -> 38383 (+0.0%)
Cycles in all programs: 8440083238 -> 8440090702 (+0.0%)
Spills in all programs: 102246 -> 102246 (+0.0%)
Fills in all programs: 131908 -> 131908 (+0.0%)
Skylake
Instructions in all programs: 134185495 -> 134186618 (+0.0%)
SENDs in all programs: 6938790 -> 6938790 (+0.0%)
Loops in all programs: 38356 -> 38356 (+0.0%)
Cycles in all programs: 8222366923 -> 8222365826 (-0.0%)
Spills in all programs: 98821 -> 98821 (+0.0%)
Fills in all programs: 125218 -> 125218 (+0.0%)
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Fixes: 1feeee9cf4 ("nir/spirv: Add initial support for GLSL 4.50 builtins")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13999>
(cherry picked from commit 75ef5991f5)
This (sort of) matches the behavior of nir_opt_algebraic. This ensures
that subnormal values are properly flushed to zero.
With the aid of "nir/search: Float sources of texture instructions are
float users" and "nir/search: Transitively apply is_only_used_as_float",
there would have been no shader-db regressions on Intel platforms.
However, those caused a significant increase in compile time. Since the
instruction regressions were so small, I just dropped those commits
rather than improve them.
All Haswell and newer platforms had similar results. (Ice Lake shown)
total instructions in shared programs: 20125042 -> 20125094 (<.01%)
instructions in affected programs: 7184 -> 7236 (0.72%)
helped: 0
HURT: 32
HURT stats (abs) min: 1 max: 4 x̄: 1.62 x̃: 2
HURT stats (rel) min: 0.11% max: 1.49% x̄: 0.85% x̃: 0.78%
95% mean confidence interval for instructions value: 1.39 1.86
95% mean confidence interval for instructions %-change: 0.74% 0.96%
Instructions are HURT.
total cycles in shared programs: 862745586 -> 862746551 (<.01%)
cycles in affected programs: 109872 -> 110837 (0.88%)
helped: 12
HURT: 23
helped stats (abs) min: 2 max: 774 x̄: 90.83 x̃: 19
helped stats (rel) min: 0.07% max: 25.23% x̄: 3.06% x̃: 0.40%
HURT stats (abs) min: 2 max: 1106 x̄: 89.35 x̃: 12
HURT stats (rel) min: 0.08% max: 45.40% x̄: 3.01% x̃: 0.47%
95% mean confidence interval for cycles value: -60.09 115.23
95% mean confidence interval for cycles %-change: -2.21% 4.07%
Inconclusive result (value mean confidence interval includes 0).
All of the shaders hurt are in either UE4 shooter-game or shooter_demo.
Tiger Lake
Instructions in all programs: 159893213 -> 159893290 (+0.0%)
SENDs in all programs: 6936431 -> 6936431 (+0.0%)
Loops in all programs: 38385 -> 38385 (+0.0%)
Cycles in all programs: 7019259514 -> 7019260087 (+0.0%)
Spills in all programs: 101389 -> 101389 (+0.0%)
Fills in all programs: 131532 -> 131532 (+0.0%)
Ice Lake
Instructions in all programs: 143624164 -> 143624235 (+0.0%)
SENDs in all programs: 6980289 -> 6980289 (+0.0%)
Loops in all programs: 38383 -> 38383 (+0.0%)
Cycles in all programs: 8440082767 -> 8440083238 (+0.0%)
Spills in all programs: 102246 -> 102246 (+0.0%)
Fills in all programs: 131908 -> 131908 (+0.0%)
Skylake
Instructions in all programs: 134185424 -> 134185495 (+0.0%)
SENDs in all programs: 6938790 -> 6938790 (+0.0%)
Loops in all programs: 38356 -> 38356 (+0.0%)
Cycles in all programs: 8222366529 -> 8222366923 (+0.0%)
Spills in all programs: 98821 -> 98821 (+0.0%)
Fills in all programs: 125218 -> 125218 (+0.0%)
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Fixes: f5dd6dfe01 ("anv: enable VK_KHR_shader_float_controls and SPV_KHR_float_controls")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13999>
(cherry picked from commit 38a94c82e6)
Extend 4195a9450b so that the next poor fool doesn't come along and
say, "sge does the right thing for 16-bit sources, but slt gives a NIR
validation failure. What the deuce?"
NOTE: This commit is necessary to prevent regressions in GLSLstd450Step
tests of 16-bit sources at "spriv: Produce correct result for
GLSLstd450Step with NaN".
Fixes: 4195a9450b ("nir: sge operation is defined for floating-point types")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13999>
(cherry picked from commit 38800b385c)
Fast clear with the resource format instead. This is safe to do because
can_fast_clear_color ensures that the clear color generates the same
pixel with either the view format or the resource format.
On SKL, this prevents us from using an invalid surface state. This platform
doesn't support CCS_E with sRGB formats, but prior to this patch we allowed
fast-clearing with this combination. Piglit's fcc-write-after-clear test
can trigger this.
Fixes: 230952c210 ("iris: Don't support sRGB + Y_TILED_CCS on gen9")
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14806>
(cherry picked from commit 6778b3a379)
the idx param for LLVMBuildInsertElement is zero-indexed based on the
value of 'vector_length' (always 4), and the vector length is (obviously)
sized to 'vector_length', so this should be the member of the vec that is being
inserted, not the invocation index
cc: mesa-stable
fixes (zink, but only on my one machine):
KHR-GL46.tessellation_shader.single.max_patch_vertices
KHR-GL46.tessellation_shader.tessellation_shader_tc_barriers.barrier_guarded_read_write_calls
dEQP-GLES31.functional.tessellation.shader_input_output.barrier
dEQP-GLES31.functional.tessellation.shader_input_output.patch_vertices_5_in_10_out
dEQP-GLES31.functional.tessellation_geometry_interaction.feedback.tessellation_output_isolines_geometry_output_points
dEQP-GLES31.functional.tessellation_geometry_interaction.feedback.tessellation_output_isolines_point_mode_geometry_output_triangles
dEQP-GLES31.functional.tessellation_geometry_interaction.feedback.tessellation_output_quads_geometry_output_points
dEQP-GLES31.functional.tessellation_geometry_interaction.feedback.tessellation_output_quads_point_mode_geometry_output_lines
dEQP-GLES31.functional.tessellation_geometry_interaction.feedback.tessellation_output_triangles_geometry_output_points
dEQP-GLES31.functional.tessellation_geometry_interaction.feedback.tessellation_output_triangles_point_mode_geometry_output_lines
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14949>
(cherry picked from commit 68c1b50e48)
All of the opcodes in nir_opt_algebraic_late are the unsized (1-bit)
versions. If the lowering to int32 happens first, many of the
optimizations and lowerings won't happen.
Of particular importance is the lowering of fisfinite. If a shader
happens to contain fisfinite of an fp16 value, it will assert later
during compliation.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Fixes: 78b4e417d4 ("gallivm: handle fisfinite/fisnormal")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14942>
(cherry picked from commit e3cbc328e0)
The same problem with 17e62a3c23
fixed for i965 with 6bc710d769
exists with other drivers.
With Mesa 21.3.6 on radeon r100 it shows as:
_mesa_is_winsys_fbo (fb=0x0)
radeonFlush
_mesa_make_current
_mesa_free_context_data
radeonDestroyContext
driDestroyContext
dri2_destroy_context
glx_display_free
__glXCloseDisplay
XCloseDisplay
Follow the i965 change and add a NULL test before flush for
radeon, i915 and nouveau.
Fixes: 17e62a3c23 ("mesa: (correctly) flush more in _mesa_make_current")
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14989>
these regions might not have the coords in the correct order, which will
cause them to fail intersection tests, resulting in clears that are never
applied
cc: mesa-stable
fixes:
GTF-GL46.gtf30.GL3Tests.framebuffer_blit.framebuffer_blit_functionality_all_buffer_blit
GTF-GL46.gtf30.GL3Tests.framebuffer_blit.framebuffer_blit_functionality_color_and_depth_blit
GTF-GL46.gtf30.GL3Tests.framebuffer_blit.framebuffer_blit_functionality_color_and_stencil_blit
GTF-GL46.gtf30.GL3Tests.framebuffer_blit.framebuffer_blit_functionality_linear_filter_color_blit
GTF-GL46.gtf30.GL3Tests.framebuffer_blit.framebuffer_blit_functionality_magnifying_blit
GTF-GL46.gtf30.GL3Tests.framebuffer_blit.framebuffer_blit_functionality_minifying_blit
GTF-GL46.gtf30.GL3Tests.framebuffer_blit.framebuffer_blit_functionality_missing_buffers_blit
GTF-GL46.gtf30.GL3Tests.framebuffer_blit.framebuffer_blit_functionality_nearest_filter_color_blit
GTF-GL46.gtf30.GL3Tests.framebuffer_blit.framebuffer_blit_functionality_negative_dimensions_blit
GTF-GL46.gtf30.GL3Tests.framebuffer_blit.framebuffer_blit_functionality_negative_height_blit
GTF-GL46.gtf30.GL3Tests.framebuffer_blit.framebuffer_blit_functionality_negative_width_blit
GTF-GL46.gtf30.GL3Tests.framebuffer_blit.framebuffer_blit_functionality_scissor_blit
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14867>
(cherry picked from commit 388f23eabe)
If we have batch a + b, and writing to batch b, causes batch a
to flush, all the bo->index get reset, and we try to submit a -1
to the kernel.
Look the bo index up when creating relocations.
Fixes crash seen in KHR-GL46.compute_shader.pipeline-post-fs
and a trace from Wasteland 3
Fixes: f3630548f1 ("crocus: initial gallium driver for Intel gfx 4-7")
Reviewed-by: Zoltán Böszörményi <zboszor@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14905>
(cherry picked from commit 37c3be6947)
Commit 17e62a3c23 made _mesa_make_current
begin calling ctx->Driver.Flush() in more cases, including when called
during context destruction, after _mesa_free_context_data has set
ctx->DrawBuffer to NULL. i965's flush hook wasn't prepared for this,
and assumed that ctx->DrawBuffer was non-NULL. This led to a crash
with the following backtrace:
#0 0x00007ffff5bf97b5 in _mesa_is_winsys_fbo (fb=0x0)
at ../../src/mesa/main/fbobject.h:52
#1 0x00007ffff5bfa359 in brw_flush_front (ctx=0x5555555a4110)
at ../../src/mesa/drivers/dri/i965/brw_context.c:242
#2 0x00007ffff5bfa587 in brw_glFlush (ctx=0x5555555a4110,
gallium_flush_flags=0) at ../../src/mesa/drivers/dri/i965/brw_context.c:301
#3 0x00007ffff5d46b2b in _mesa_make_current (newCtx=0x0, drawBuffer=0x0,
readBuffer=0x0) at ../../src/mesa/main/context.c:1616
#4 0x00007ffff5d46484 in _mesa_free_context_data (ctx=0x5555555a4110,
destroy_debug_output=true) at ../../src/mesa/main/context.c:1309
#5 0x00007ffff5bfcb59 in brw_destroy_context (driContextPriv=0x555555590260)
at ../../src/mesa/drivers/dri/i965/brw_context.c:1301
There is really no point in worrying about front buffer flushing during
the context's destruction when we've already discarded the drawbuffer,
so just add a NULL check in brw_flush_front and skip that work.
Fixes: 17e62a3c23 ("mesa: (correctly) flush more in _mesa_make_current")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5957
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14828>
We need to check the source of the copy, not the destination. That means
this we need to move this check inside the ifs, where we know that the
source is a copy.
Fixes: 590efd180b ("Prevent propagating shared regs out of loops")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14412>
(cherry picked from commit 09731fc79a)
Workgroup is only allowed in compute shaders, and Device should be more
in line with the intended use here
the alternative would be to keep using Workgroup for compute and use Device
otherwise, but this would effectively make atomic ops non-atomic, which seems
like it isn't desirable
cc: mesa-stable
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14690>
(cherry picked from commit 6f38ea4ac7)
according to spec, these must match the texel pointer type
cc: mesa-stable
fixes (nvidia):
dEQP-GLES31.functional.image_load_store.2d.atomic.exchange_r32f_return_value
dEQP-GLES31.functional.image_load_store.2d_array.atomic.exchange_r32f_return_value
dEQP-GLES31.functional.image_load_store.cube.atomic.exchange_r32f_return_value
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14690>
(cherry picked from commit 2361c52b5e)
- the current batch id is always 0
- there is always a current batch
- a batch id can only be set at the time of submit
thus when passing 0 to wait on the current batch, the submit must complete
so that there is a batch id, and this must occur before the timeline wait
path or else the timeline wait does nothing
cc: mesa-stable
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14693>
(cherry picked from commit 3a0888c62f)
Previously, no buffers were ever marked as EXEC_OBJECT_ASYNC so the
Kernel would ensure dependency tracking for us. After we implemented
explicit busy tracking in commit 89a34cb845, only the external
objects kept relying on the Kernel's implicit tracking and Iris did
inter-batch busy tracking, meaning we lost inter-screen and
inter-context synchronization. This seemed fine to me since, as far as
I understood, it is the duty of the application to synchronize itself
against multiple screens and contexts.
The problem here is that applications were actually relying on the old
behavior where the Kernel guarantees synchronization, so 89a34cb845
can be seen as a regression. This commit addresses the inter-context
synchronization case.
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5731
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5812
Fixes: 89a34cb845 ("iris: switch to explicit busy tracking")
Tested-by: Konstantin Kharlamov <hi-angel@yandex.ru>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14783>
Commit e614789588 ("anv: Also disallow CCS_E for multi-LOD images")
accidentally disabled CCS_E on TGL+ because it checked for
image->vk.mip_levels > 0 instead of image->vk.mip_levels > 1.
Instead of reverting it, we remove the code which disables CCS_E for
mipmapped or arrayed images now that we've sufficiently handled the
clear color issue in other ways.
Fixes: e614789588 ("anv: Also disallow CCS_E for multi-LOD images")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14723>
(cherry picked from commit 57445adc89)
On TGL, if a block of fragment shader outputs match the surface's clear
color, the HW may convert them to fast-clears (see HSD 14010672564).
This can lead to rendering corruptions if not handled properly. We
restrict the clear color to zero to avoid issues that can occur with:
- Texture view rendering (including blorp_copy calls)
- Images with multiple levels or array layers
Fixes: e614789588 ("anv: Also disallow CCS_E for multi-LOD images")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14723>
(cherry picked from commit c48401404c)
CCS_E is currently disabled on TGL+, but we'll enable it soon. We choose
to explicitly disable it for certain copy operations to avoid CTS
failures in the following groups:
- dEQP-VK.drm_format_modifiers.export_import.*
- dEQP-VK.synchronization*
Fixes: e614789588 ("anv: Also disallow CCS_E for multi-LOD images")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14723>
(cherry picked from commit d68b2db89c)
This fixes a bug in the handcrafted SIMD lowering done by the SHUFFLE
code generation, which wasn't taking into account the source and
destination region strides while deciding whether it needs to split an
instruction.
v2: Use new element_sz() helper instead of left shift. (Lionel)
Fixes: 90c9f29518 ("i965/fs: Add support for nir_intrinsic_shuffle")
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14273>
(cherry picked from commit d1038197f3)
Instead of a unreachable.
This would avoid an assert on debug builds that uses vkfoo_to_str to
print structure types. This will become more common as some tests will
start to use VK_STRUCTURE_TYPE_MAX_ENUM to mark structures from
unsupported extensions more often.
v2 (Jason):
* Include enum name on the default message
* Handle MAX_ENUM as a special case
v3 (Jason):
* vk_ObjectType_to_ObjectName don't need to use ${enum.name}
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14525>
(cherry picked from commit 821c66e50c)
Fixes InconsistentSpirv validation errors reporting that PackHalf2x16
outputs uint rather than float.
For example the previous code generates the following SPIR-V with
PackHalf2x16 output as a float:
%2018 = OpExtInst %float %1 PackHalf2x16 %2017
%2019 = OpBitcast %uint %2018
The new code generates:
%2018 = OpExtInst %uint %1 PackHalf2x16 %2017
%2019 = OpBitcast %uint %2018
cc: mesa-stable
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14568>
(cherry picked from commit 985dae7f41)
Fixes the following valgrind warnings:
Conditional jump or move depends on uninitialised value(s)
at 0x5D1298C: draw_pt_so_emit_prepare (draw_pt_so_emit.c:95)
by 0x5D89FD7: llvm_middle_end_prepare (draw_pt_fetch_shade_pipeline_llvm.c:319)
by 0x5D13BFF: vsplit_prepare (draw_pt_vsplit.c:229)
by 0x5D0D5D8: draw_pt_arrays.isra.0 (draw_pt.c:124)
by 0x5D0DA08: draw_instances (draw_pt.c:484)
by 0x5D0DEB9: draw_vbo (draw_pt.c:610)
by 0x5E847D6: r300_swtcl_draw_vbo (r300_render.c:901)
by 0x5D67125: u_vbuf_draw_vbo (u_vbuf.c:1470)
by 0x5CFCAD3: cso_multi_draw (cso_context.c:1639)
by 0x58FEC37: st_draw_gallium (st_draw.c:186)
by 0x5A486BA: _mesa_draw_arrays.part.0 (draw.c:1323)
by 0x48B4E27: stub_glDrawArrays (piglit-dispatch-gen.c:12421)
Uninitialised value was created by a stack allocation
at 0x5E90D3F: r300_draw_init_vertex_shader (r300_vs_draw.c:313)
Conditional jump or move depends on uninitialised value(s)
at 0x5D175D9: draw_create_vertex_shader (draw_vs.c:70)
by 0x5E90E7A: r300_draw_init_vertex_shader (r300_vs_draw.c:366)
by 0x5E8751F: r300_create_vs_state (r300_state.c:1950)
by 0x594453B: st_create_common_variant (st_program.c:888)
by 0x594720C: st_get_common_variant (st_program.c:973)
by 0x59484B6: st_precompile_shader_variant (st_program.c:1994)
by 0x59484B6: st_finalize_program (st_program.c:2056)
by 0x58F0571: st_program_string_notify (st_cb_program.c:128)
by 0x5928C9B: st_link_tgsi (st_glsl_to_tgsi.cpp:7514)
by 0x5904B53: st_link_shader (st_glsl_to_ir.cpp:178)
by 0x58D3E08: _mesa_glsl_link_shader (link_program.cpp:91)
by 0x58865C7: link_program (shaderapi.c:1363)
by 0x58865C7: link_program_error.part.0 (shaderapi.c:1474)
by 0x48DBC5A: stub_glLinkProgram (piglit-dispatch-gen.c:34426)
Uninitialised value was created by a stack allocation
at 0x5E90D4F: r300_draw_init_vertex_shader (r300_vs_draw.c:313)
Based on Filip Gawin's
r300: set new_vs.type to PIPE_SHADER_IR_TGSI
CC: mesa-stable
Reviewed-by: Emma Anholt <emma@anholt.net>
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14620>
(cherry picked from commit b5b105df96)
It's not obvious why the (gl_FrontFacing ? -1.0 : 1.0) case was handled
different for Gfx12+ than for previous generations, and it's not
correct. It tries to negate the result as an integer, and it does this
before the mask operation that clears the other bits in the value.
When we eventually support dual-SIMD8 dispatch, the other front-facing
bit is in g1.6 at bit 15, so similar code should be possible there.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Fixes: c92fb60007 ("intel/fs/gen12: Implement gl_FrontFacing on gen12+.")
Closes: #5876
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14625>
(cherry picked from commit 945fb51fb5)
this would allocate a new stream uploader for every map if the offset was
large (e.g., all sparse buffer usage), which almost immediately consumes all vram
cc: mesa-stable
fixes KHR-GL46.CommonBugs.CommonBug_SparseBuffersWithCopyOps
Acked-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14381>
(cherry picked from commit d83b52928c)
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>
(cherry picked from commit 537a0ee3b7)
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>
(cherry picked from commit acebea9cf1)
By software ABI, a blend shader is permitted to clobber registers
R0-R15. The scheduler needs to be aware of this, to avoid moving a write
to one of these registers past the BLEND itself. Otherwise the schedule
is invalid.
This bug affects GLES3.0, but is rare enough in practice that we had
missed it. It requires a fragment shader to write to multiple render
targets with attached blend shaders, and have temporaries register
allocated to R0-R15 that are not read by the blend shader, but are sunk
past the BLEND instruction by the scheduler. Prevents a regression when
switching boolean representations on:
dEQP-GLES31.functional.shaders.builtin_functions.integer.uaddcarry.uvec4_lowp_fragment
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14577>
(cherry picked from commit b8d37eb1bb)
As indicated by
VkPhysicalDeviceFragmentShadingRatePropertiesKHR::fragmentShadingRateWithShaderSampleMask
our implementation will clamp to 1x1 when reading samplemask or
writing to samplemask.
This fixes vkd3d-proton tests test_sample_mask_dxbc & test_sample_mask_dxil
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: b6332fc4a8 ("intel/compiler: handle coarse pixel in render target writes descriptors")
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14553>
(cherry picked from commit 30a8b8d2df)
Setting the screen ro member before we checked gpu id means the error
case leads to a double-free because screen->ro is set and allocated
by parent who hanbdles de-alloc a second time after we destroyed the
screen we just created because ro was set.
Cc: mesa-stable
Signed-off-by: Carsten Haitzler <carsten.haitzler@foss.arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14516>
(cherry picked from commit 874f4095c5)
the original change here attempted to fix calculating the maximum bound for the
mapped readback buffer by adding the maximum attribute size to the final element
used by readback
the calculation was erroneous, however, because it instead calculated the maximum
offset instead of the size, which would cause a different kind of overrun
Fixes: 3c5b7dca30 ("util/vbuf: fix buffer overrun in attribute conversions")
fixes#5846
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14479>
(cherry picked from commit 596d2ab0ad)
this appeared to fix some sort of bug related to preserving qbo data,
but really there shouldn't have been any sort of bug anyway since the qbos
all get read back, and thus the data is already preserved
instead, it just preserved the query id, which overloaded the pools and crashed
This reverts commit 79790e276f.
fixes#5669
Reviewed-by: Hoe Hao Cheng <haochengho12907@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14397>
(cherry picked from commit 2fa1bf60d6)
st_init_extensions (src/mesa/state_tracker/st_extensions.c) already
enforces the GLSL 1.30 or EXT_gpu_shader4 requirement, so Crocus will
already behave this way on this hardware.
The EXT_texture_integer spec says:
NV_gpu_program4 or EXT_gpu_shader4 is required.
Without one of these extensions or GLSL 1.30, it is impossible to read
integer values from a texture. The spec also says:
This extension does not enforce type consistency for texture
accesses or between fragment shaders and the corresponding
framebuffer attachments. The results of a texture lookup from an
integer texture are undefined:
* for fixed-function fragment processing, or
* for shader texture accesses expecting floating-point return
values.
The color components used for per-fragment operations and written
into a color buffer are undefined:
* for fixed-function fragment processing with an integer color
buffer,
* for fragment shaders that write floating-point color components
to an integer color buffer, or
* for fragment shaders that write integer color components to a
color buffer with floating point or normalized integer
components.
So it's really a soft requirement, but also kind of rude to expose the
extension without a way to use it properly.
Closes: #4497
CC: mesa-stable
"most" times it isn't necessary to insert any pipeline barriers when binding
descriptors, as GL requires explicit barrier usage which comes through a different
codepath
the exception here is when the following scenario occurs:
* have buffer A
* buffer_subdata is called on A
* discard path is taken || A is not host-visible
* stream uploader is used for host write
* CmdCopyBuffer is used to copy the data back to A
buffer A now has a pending TRANSFER write that must complete before the buffer is
used in a shader, so synchronization is required any time TRANSFER usage is detected
in a bind
there's also going to be more exceptions going forward as more internal usage is added,
so just remove the whole fake-barrier mechanism since it'll become more problematic
going forward
Cc: 21.3 mesa-stable
Reviewed-by: Hoe Hao Cheng <haochengho12907@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14496>
(cherry picked from commit 3e5f4cebe8)
ensure that vertex key data is always zeroed when changing last stage since it will
be updated before draw anyway and can only cause problems if left alone here
fixes the following caselist:
dEQP-GLES31.functional.shaders.builtin_constants.tessellation_shader.max_tess_evaluation_texture_image_units
dEQP-GLES31.functional.tessellation_geometry_interaction.feedback.tessellation_output_quads_geometry_output_points
dEQP-GLES31.functional.ubo.random.all_per_block_buffers.25
cc: mesa-stable
Reviewed-by: Hoe Hao Cheng <haochengho12907@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14482>
(cherry picked from commit d15ff96da2)
Fixes a leak:
==47470== 60 bytes in 1 blocks are definitely lost in loss record 1,790 of 1,904
==47470== at 0x484186F: malloc (vg_replace_malloc.c:381)
==47470== by 0x58EBA6A: compile_vertex_list (vbo_save_api.c:535)
==47470== by 0x58EDABF: wrap_buffers (vbo_save_api.c:1021)
==47470== by 0x58EDF97: upgrade_vertex (vbo_save_api.c:1134)
==47470== by 0x58EE52F: fixup_vertex (vbo_save_api.c:1251)
==47470== by 0x58EFE9E: _save_Normal3f (vbo_attrib_tmp.h:315)
Fixes: 69615d92a0 ("vbo/dlist: realloc prims array instead of free/malloc")
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14474>
(cherry picked from commit a5bc8c4be9)
Fixes a leak:
==46154== 48 bytes in 1 blocks are definitely lost in loss record 1,571 of 1,905
==46154== at 0x48466AF: realloc (vg_replace_malloc.c:1437)
==46154== by 0x5FC98EC: util_idalloc_resize (u_idalloc.c:43)
==46154== by 0x5FC9C16: util_idalloc_alloc_range (u_idalloc.c:125)
==46154== by 0x56FDB9F: _mesa_EndList (dlist.c:13681)
Fixes: b703d7c15f ("dlist: store all dlist in a continuous memory block")
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14474>
(cherry picked from commit 6e9cd801a6)
Different parts of our codebase disagree on whether spatial
coordinates/dimensions are given in pixels or blocks, which differ by a
constant factor for block-compressed formats. This disagreement
manifests as incorrect results accessing block-compressed formats.
To resolve this, define the public tiling routines to take their
coordinates in pixels, and align the relevant code in Panfrost
accordingly.
Fixes rendering glitches in Factorio, as well as a pile of piglits on
Panfrost. It should also fix glTexSubImage() with ETC1 on Lima, but
there are no tests for this in dEQP/Piglit.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Tested-by: Vasily Khoruzhick <anarsoul@gmail.com> [dEQP/Lima]
Tested-by: Erico Nunes <nunes.erico@gmail.com> [Piglit/Lima]
Reported-by: Icecream95 <ixn@disroot.org>
Closes: #5560
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14370>
(cherry picked from commit b920ace4bc)
There is a lot of unit confusion in Gallium due to pixels versus blocks
matching only with uncompressed textures. Add a helper to do a common
pixels->blocks unit conversion required in multiple drivers.
v2: Rename dst->blocks, src->pixels to avoid confusion about the units
to casual readers (Mike).
Note to mesa-stable maintainers: this is marked as Cc: mesa-stable so
the next patch (a set of bug fixes for Lima and Panfrost) can be
backported. It's not a bug fix in its own right, of course.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Emma Anholt <emma@anholt.net> [v1]
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14370>
(cherry picked from commit 26c533f167)
This makes the compiler less predictable and should only have a very small
effect on performance.
fossil-db (Vega):
Totals from 2410 (1.79% of 134756) affected shaders:
CodeSize: 6911568 -> 6942840 (+0.45%)
Fixes Horizon Zero Dawn artifacts.
If a shader has:
a = pack_half_2x16(a, 0) //rtne
store(pack_half_2x16(0, b) | a) //rtne
a = unpack_2x16(a).x
It will become:
store(pack_half_2x16(a, b)) //rtz
a = unpack_2x16(pack_half_2x16(a, 0)).x //rtne
So a later shader with "unpack_2x16(load()).x" will use "a" rounded to
zero, while the previous shader will use "a" rounded to the nearest even.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Fixes: 2f125908b3 ("radv,aco: lower_pack_half_2x16")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14475>
(cherry picked from commit 60c711833f)
If a BO is removed from a cache bucket list via a lookup, we must
handle it in the same way as if a allocation from the cache happened:
tell valgrind that the buffer is active again and take a reference
to the etna_device, which the BO had given up while being in the
cache.
Cc: mesa-stable
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Tested-by: Guido Günther <agx@sigxcpu.org>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14159>
(cherry picked from commit 1b1f8592c0)
The intended limit for command stream size is 64KB, as this is what old
kernels can reliably do and what allows for maximum number of queued
streams on newer kernels. However, due to unit confusion with the size
member, which is in dwords, the submitted streams could grow up to
~128KB. Fix this by using the proper limit in dwords.
Flushing due to some limits being exceeded is not an issue, but is
expected with certain workloads, so lower the severity of the message
being emitted in this case to debug level.
Cc: mesa-stable
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14425>
(cherry picked from commit ccfd5054a4)
This fixes a test from the vkd3d-proton test_dual_source_blending_dxbc
test which asserts in the backend with :
brw_fs_visitor.cpp:716: void fs_visitor::emit_fb_writes(): Assertion `!prog_data->dual_src_blend || key->nr_color_regions == 1' failed.
This is because there is 2 color attachments provided by the
renderpass so we initially set nr_color_regions = 2. But once we've
parsed the shader, we can see it's only using one output (with dual
source color blending).
This change looks at the output variables to update the valid output
variables.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14417>
(cherry picked from commit 07bc6b7ed9)
Fixes memory leak with dependencies array:
==5224== 104 (96 direct, 8 indirect) bytes in 3 blocks are definitely lost in loss record 1,954 of 2,035
==5224== at 0x484178A: malloc (vg_replace_malloc.c:380)
==5224== by 0x484670B: realloc (vg_replace_malloc.c:1437)
==5224== by 0x14DBAB9B: update_bo_syncobjs (iris_batch.c:819)
==5224== by 0x14DBADB8: update_batch_syncobjs (iris_batch.c:898)
==5224== by 0x14DBB3D5: _iris_batch_flush (iris_batch.c:1031)
==5224== by 0x14DB77D0: iris_transfer_map (iris_resource.c:2348)
==5224== by 0x157786FD: u_transfer_helper_transfer_map (u_transfer_helper.c:243)
==5224== by 0x14C479E7: tc_buffer_map (u_threaded_context.c:2252)
==5224== by 0x1434F3F8: pipe_buffer_map_range (u_inlines.h:393)
==5224== by 0x1435094A: _mesa_bufferobj_map_range (bufferobj.c:491)
==5224== by 0x143586D9: map_buffer_range (bufferobj.c:3737)
==5224== by 0x14358DA3: _mesa_MapBuffer (bufferobj.c:3947)
==5224== 240 (192 direct, 48 indirect) bytes in 6 blocks are definitely lost in loss record 1,984 of 2,035
==5224== at 0x484178A: malloc (vg_replace_malloc.c:380)
==5224== by 0x484670B: realloc (vg_replace_malloc.c:1437)
==5224== by 0x14DBAB9B: update_bo_syncobjs (iris_batch.c:819)
==5224== by 0x14DBADB8: update_batch_syncobjs (iris_batch.c:898)
==5224== by 0x14DBB3D5: _iris_batch_flush (iris_batch.c:1031)
==5224== by 0x14FF72CC: iris_get_query_result (iris_query.c:631)
==5224== by 0x14C4396A: tc_get_query_result (u_threaded_context.c:880)
==5224== by 0x1458F4F7: get_query_result (st_cb_queryobj.c:273)
==5224== by 0x1458F7EB: st_WaitQuery (st_cb_queryobj.c:352)
==5224== by 0x144EFF66: get_query_object (queryobj.c:742)
==5224== by 0x144F01AE: _mesa_GetQueryObjectuiv (queryobj.c:811)
And leak with syncobjs:
==13644== 8 bytes in 1 blocks are definitely lost in loss record 1 of 1,846
==13644== at 0x484186F: malloc (vg_replace_malloc.c:381)
==13644== by 0x639789B: iris_create_syncobj (iris_fence.c:69)
==13644== by 0x63B213A: iris_batch_reset (iris_batch.c:512)
==13644== by 0x63B3637: _iris_batch_flush (iris_batch.c:1056)
==13644== by 0x65EF2BC: iris_get_query_result (iris_query.c:631)
==13644== by 0x623B970: tc_get_query_result (u_threaded_context.c:880)
==13644== by 0x5B874F7: get_query_result (st_cb_queryobj.c:273)
==13644== by 0x5B877EB: st_WaitQuery (st_cb_queryobj.c:352)
==13644== by 0x5AE7F66: get_query_object (queryobj.c:742)
==13644== by 0x5AE8150: _mesa_GetQueryObjectiv (queryobj.c:801)
Fixes: ce2e2296ab ("iris: Suballocate BO using the Gallium pb_slab mechanism")
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14387>
(cherry picked from commit b8f0459d6f)
After some experimentation with computerator, it seems on a618 that
writing a full register and then reading half of it as a half register
requires a delay of 6, the same as the delay for cat5/cat6 sources. The
other direction only has a delay of 5, but just bump it unconditionally
out of an abundance of caution.
Fixes: 890de1a436 ("ir3/delay: Fix full->half and half->full delay")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14246>
(cherry picked from commit 603791bdeb)
If we're allocating a source then we force is_killed to false, not to
true. Fixes a regression in
dEQP-GLES31.functional.synchronization.in_invocation.image_atomic_write_read
later.
Fixes: 0ffcb19b9d ("ir3: Rewrite register allocation")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14246>
(cherry picked from commit d371d807eb)
When we lower SPIR-V to NIR for textures in vtn_handle_texture, we only
bump the number of coordinate components when the op is not a lod query.
Update the assert to take this into account.
This fixes:
- dEQP-VK.robustness.robustness2.bind.template.r32f.dontunroll.nonvolatile.sampled_image.no_fmt_qual.null_descriptor.samples_1.cube_array.frag
- dEQP-VK.robustness.robustness2.bind.template.r32f.unroll.nonvolatile.sampled_image.no_fmt_qual.null_descriptor.samples_1.cube_array.frag
- dEQP-VK.robustness.robustness2.bind.template.r32i.dontunroll.nonvolatile.sampled_image.no_fmt_qual.null_descriptor.samples_1.cube_array.frag
- dEQP-VK.robustness.robustness2.bind.template.r32i.unroll.nonvolatile.sampled_image.no_fmt_qual.null_descriptor.samples_1.cube_array.frag
- dEQP-VK.robustness.robustness2.bind.template.r32ui.dontunroll.nonvolatile.sampled_image.no_fmt_qual.null_descriptor.samples_1.cube_array.frag
- dEQP-VK.robustness.robustness2.bind.template.r32ui.unroll.nonvolatile.sampled_image.no_fmt_qual.null_descriptor.samples_1.cube_array.frag
- dEQP-VK.robustness.robustness2.bind.template.rg32f.dontunroll.nonvolatile.sampled_image.no_fmt_qual.null_descriptor.samples_1.cube_array.frag
- dEQP-VK.robustness.robustness2.bind.template.rg32f.unroll.nonvolatile.sampled_image.no_fmt_qual.null_descriptor.samples_1.cube_array.frag
- dEQP-VK.robustness.robustness2.bind.template.rg32i.dontunroll.nonvolatile.sampled_image.no_fmt_qual.null_descriptor.samples_1.cube_array.frag
- dEQP-VK.robustness.robustness2.bind.template.rg32i.unroll.nonvolatile.sampled_image.no_fmt_qual.null_descriptor.samples_1.cube_array.frag
- dEQP-VK.robustness.robustness2.bind.template.rg32ui.dontunroll.nonvolatile.sampled_image.no_fmt_qual.null_descriptor.samples_1.cube_array.frag
- dEQP-VK.robustness.robustness2.bind.template.rg32ui.unroll.nonvolatile.sampled_image.no_fmt_qual.null_descriptor.samples_1.cube_array.frag
- dEQP-VK.robustness.robustness2.bind.template.rgba32f.dontunroll.nonvolatile.sampled_image.no_fmt_qual.null_descriptor.samples_1.cube_array.frag
- dEQP-VK.robustness.robustness2.bind.template.rgba32f.unroll.nonvolatile.sampled_image.no_fmt_qual.null_descriptor.samples_1.cube_array.frag
- dEQP-VK.robustness.robustness2.bind.template.rgba32i.dontunroll.nonvolatile.sampled_image.no_fmt_qual.null_descriptor.samples_1.cube_array.frag
- dEQP-VK.robustness.robustness2.bind.template.rgba32i.unroll.nonvolatile.sampled_image.no_fmt_qual.null_descriptor.samples_1.cube_array.frag
- dEQP-VK.robustness.robustness2.bind.template.rgba32ui.dontunroll.nonvolatile.sampled_image.no_fmt_qual.null_descriptor.samples_1.cube_array.frag
- dEQP-VK.robustness.robustness2.bind.template.rgba32ui.unroll.nonvolatile.sampled_image.no_fmt_qual.null_descriptor.samples_1.cube_array.frag
- dEQP-VK.robustness.robustness2.push.notemplate.r32f.dontunroll.nonvolatile.sampled_image.no_fmt_qual.null_descriptor.samples_1.cube_array.frag
- dEQP-VK.robustness.robustness2.push.notemplate.r32f.unroll.nonvolatile.sampled_image.no_fmt_qual.null_descriptor.samples_1.cube_array.frag
- dEQP-VK.robustness.robustness2.push.notemplate.r32i.dontunroll.nonvolatile.sampled_image.no_fmt_qual.null_descriptor.samples_1.cube_array.frag
- dEQP-VK.robustness.robustness2.push.notemplate.r32i.unroll.nonvolatile.sampled_image.no_fmt_qual.null_descriptor.samples_1.cube_array.frag
- dEQP-VK.robustness.robustness2.push.notemplate.r32ui.dontunroll.nonvolatile.sampled_image.no_fmt_qual.null_descriptor.samples_1.cube_array.frag
- dEQP-VK.robustness.robustness2.push.notemplate.r32ui.unroll.nonvolatile.sampled_image.no_fmt_qual.null_descriptor.samples_1.cube_array.frag
- dEQP-VK.robustness.robustness2.push.notemplate.rg32f.dontunroll.nonvolatile.sampled_image.no_fmt_qual.null_descriptor.samples_1.cube_array.frag
- dEQP-VK.robustness.robustness2.push.notemplate.rg32f.unroll.nonvolatile.sampled_image.no_fmt_qual.null_descriptor.samples_1.cube_array.frag
- dEQP-VK.robustness.robustness2.push.notemplate.rg32i.dontunroll.nonvolatile.sampled_image.no_fmt_qual.null_descriptor.samples_1.cube_array.frag
- dEQP-VK.robustness.robustness2.push.notemplate.rg32i.unroll.nonvolatile.sampled_image.no_fmt_qual.null_descriptor.samples_1.cube_array.frag
- dEQP-VK.robustness.robustness2.push.notemplate.rg32ui.dontunroll.nonvolatile.sampled_image.no_fmt_qual.null_descriptor.samples_1.cube_array.frag
- dEQP-VK.robustness.robustness2.push.notemplate.rg32ui.unroll.nonvolatile.sampled_image.no_fmt_qual.null_descriptor.samples_1.cube_array.frag
- dEQP-VK.robustness.robustness2.push.notemplate.rgba32f.dontunroll.nonvolatile.sampled_image.no_fmt_qual.null_descriptor.samples_1.cube_array.frag
- dEQP-VK.robustness.robustness2.push.notemplate.rgba32f.unroll.nonvolatile.sampled_image.no_fmt_qual.null_descriptor.samples_1.cube_array.frag
- dEQP-VK.robustness.robustness2.push.notemplate.rgba32i.dontunroll.nonvolatile.sampled_image.no_fmt_qual.null_descriptor.samples_1.cube_array.frag
- dEQP-VK.robustness.robustness2.push.notemplate.rgba32i.unroll.nonvolatile.sampled_image.no_fmt_qual.null_descriptor.samples_1.cube_array.frag
- dEQP-VK.robustness.robustness2.push.notemplate.rgba32ui.dontunroll.nonvolatile.sampled_image.no_fmt_qual.null_descriptor.samples_1.cube_array.frag
- dEQP-VK.robustness.robustness2.push.notemplate.rgba32ui.unroll.nonvolatile.sampled_image.no_fmt_qual.null_descriptor.samples_1.cube_array.frag
Fixes: 231337a1 ("intel/fs/xehp: Assert that the compiler is sending all 3 coords for cubemaps.")
Signed-off-by: Rohan Garg <rohan.garg@intel.com>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13925>
(cherry picked from commit af13119993)
It seems that at least some GC400 come out of reset with random vertex
attributes enabled and also don't disable them on the write to the first
config register as normal. Enabling all attributes seems to provide the
GPU with the required edge to actually disable the unused attributes on
the next draw.
Cc: mesa-stable
Reported-by: Steven Walter
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14285>
(cherry picked from commit c1f8bc67e2)
In dEQP-GLES2.functional.shaders.operator.geometric.reflect.highp_vec2_fragment
and friends this pass would turn:
0: DP3 temp[1].x, input[1].yx0_, input[0].wy0_;
1: MUL temp[2].xy, temp[1].xx__, const[0].xx__;
into
0: DP3 temp[2].x * 2, input[1].yx0_, input[0].wy0_;
1: MUL temp[3].xy, temp[2].xy__, input[1].yx__;
Note the attempt to use .y of temp[2]. Just bail when we more dst
channels than src channels, since the rewrite can't generate more channels
for us. Fixes this subset of tests (which I hadn't included in the xfails
until now since results hadn't quite been stable).
Cc: mesa-stable
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Tested-by: Filip Gawin <filip.gawin@zoho.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14405>
(cherry picked from commit 105b48c85c)
It would seems msvc and mingw dont pack across disparate types so zink_bind_rasterizer_state is too big for int32
string.h:202:10: warning: ‘__builtin___memcpy_chk’ forming offset [4, 7] is out of the bounds [0, 4] of object ‘rast_bits’ with type ‘uint32_t’ {aka ‘unsigned int’} [-Warray-bounds]
202 | return __builtin___memcpy_chk(__dst, __src, __n, __mingw_bos(__dst, 0));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/gallium/drivers/zink/zink_state.c: In function ‘zink_bind_rasterizer_state’:
../src/gallium/drivers/zink/zink_state.c:586:16: note: ‘rast_bits’ declared here
Fixes: 9c5a2ab6
Acked-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12609>
(cherry picked from commit 4ff57e5aba)
Previously the code was using a hack to change the token type from
INDETIFIER -> OTHER in order to avoid getting in an infinite loop
expanding the tokens. This worked ok until we got to a paste where
the replacement parameters had already had their type changed
to OTHER because the newly created paste token would then
inherit the OTHER type and never get expanded inself.
For example with the follow code:
#define STEP_ONE() \
out_Color = vec4(0.0,1.0,0.0,1.0)
#define GLUE(x,y) x ## _ ## y
#define EVALUATE(x,y) GLUE(x,y)
#define STEP(stepname) EVALUATE(STEP, stepname)()
#define PERFORM_RAYCASTING_STEP STEP(ONE)
This would get all the way to expanding PERFORM_RAYCASTING_STEP to
STEP_ONE() but because it was created via the paste `x ## _ ## y`
it would never get any further.
To fix this we remove the OTHER hack and instead just track if the
token has already been handled via a bool value `explanding`.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5724
Fixes: 28842c2331 ("glcpp: Implement token pasting for non-function-like macros")
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14101>
(cherry picked from commit d2711f9b61)
For historical reasons, we ingest 1-bit booleans in NIR but expand them
to 16/32-bit booleans in the backend IR. We need to handle this case
when loading boolean constants, extending from 1-bit to 16/32-bit as
required. This issue is masked by effective constant folding for
booleans, but is visible in a shader from Firefox WebRender.
Fixes: 646e03c451 ("pan/bi: Temporarily switch back to 0/~0 bools")
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reported-by: Icecream95
Closes: #5797
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14371>
(cherry picked from commit 29d319c767)
these tests are now passing:
dEQP-GLES2.functional.shaders.operator.exponential.pow.highp_vec2_vertex,Fail
dEQP-GLES2.functional.shaders.operator.exponential.pow.highp_vec3_vertex,Fail
dEQP-GLES2.functional.shaders.operator.exponential.pow.highp_vec4_vertex,Fail
dEQP-GLES2.functional.shaders.operator.exponential.pow.mediump_vec2_vertex,Fail
dEQP-GLES2.functional.shaders.operator.exponential.pow.mediump_vec3_vertex,Fail
dEQP-GLES2.functional.shaders.operator.exponential.pow.mediump_vec4_vertex,Fail
Fixes: 1c2c4ddbd1 ("r300g: copy the compiler from r300c")
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14282>
(cherry picked from commit 2ddfb9c256)
Older gens have a limit of 2GB on surfaces, this results in
isl_surf_init_s failing if the surface exceeds that, in this
case this should fail all the way back up the stack.
This fixes some cases of max-texture-size on crocus
Fixes: f3630548f1 ("crocus: initial gallium driver for Intel gfx 4-7")
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14347>
(cherry picked from commit d8a38edc48)
We tried to step over the instruction we just generated, except we didn't
always just generate one. In the sequence_vertex tests, that meant we
skipped processing the next BGNLOOP and then underflowed our stack.
Cc: mesa-stable
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14271>
(cherry picked from commit 658b2ca467)
This adds a missing CFG edge that represents a possible physical
control flow path the EU might take under some conditions which isn't
part of the logical CFG of the program. This possibility shouldn't
have led to problems on platforms prior to Gfx12, since the missing
control flow edge cannot possibly influence liveness intervals.
However on Gfx12+ it becomes the compiler's responsibility to resolve
data dependencies across instructions, and the missing physical
control flow paths may lead to a WaR data hazard currently not visible
to the software scoreboard pass, which could lead to data corruption.
Worse, the possibility for this path to be taken by the EU increases
on Gfx12+ due to a hardware bug affecting EU fusion -- However the
same physical path can be potentially taken on earlier platforms as
well, so this patch extends the CFG on all platforms for consistency,
even though the lack of this edge shouldn't lead to any functional
issues on platforms earlier than Gfx12. There are no shader-db
changes on earlier platforms, so there seems to be no disadvantage
from using the same CFG representation as on later platforms.
This issue has ben reported on TGL with the following conformance
test, thanks to Ian for bringing the FULSIM dependency check warning
to my attention:
dEQP-VK.graphicsfuzz.spv-stable-pillars-volatile-nontemporal-store
Fixes: 4d1959e693 ("intel/cfg: Represent divergent control flow paths caused by non-uniform loop execution.")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4940
Reported-by: Tapani Pälli <tapani.palli@intel.com>
Reported-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14248>
(cherry picked from commit e7470a40c5)
Without this, a cloned instruction that takes full regs will trigger an
ir3_validate assert. This can happen, for ex, if an instruction that
writes p0.x and has a relative src gets cloned in ir3_sched.
Fixes an assert in Genshin Impact with a debug build.
Fixes: 9af795d9b9 ("ir3: Make ir3_instruction::address a normal register")
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14231>
(cherry picked from commit 78c53f4888)
We already have code to deal with non-client-visible objects but we were
asserting if it didn't fall into one of the clearly mappable error
cases. However, we didn't have a mapping for VK_ERROR_NOT_PERMITTED
which can happen during object creation. Let's just be sloppy and drop
the assert. Worst case, the client gets an error with no object.
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13341>
(cherry picked from commit 116e23e385)
This function is called on load/store_input/output. It makes no sense
for it to get a SYSTEM_VALUE enum. This only doesn't explode because
SYSTEM_VALUE_PRIMITIVE_ID happens to be below VARYING_SLOT_VAR0 so it
doesn't interact with any actual varyings. The next commit is going to
add another system value which will push SYSTEM_VALUE_PRIMITIVE_ID up by
one so it will equal VARYING_SLOT_VAR0 and then the first FS input will
always get smashed to flat which isn't what we want.
Fixes: b59bb9c07a ("radeonsi: force flat for PrimID early in si_nir_scan_shader")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14198>
(cherry picked from commit 732b234ddb)
Insert a flush after a depth decompression pass if the texture
was fast cleared.
This fixes a corruption which seems to only affect gfx10.3 chips.
Ideally we should also clear tex->need_flush_after_depth_decompression
after a flush but there's no easy way for this so this commit will
introduce extra flushes.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14089>
(cherry picked from commit 573d645133)
Currently V3DV_HAS_SURFACE is always defined.
There is no WSI for Android in mesa3d, therefore WSI related extensions
should not be exposed.
1. Define V3DV_HAS_SURFACE only for platforms which has WSI implemented.
2. Rename V3DV_HAS_SURFACE -> V3DV_USE_WSI_PLATFORM to align naming
with other platforms.
Fixes dEQP-VK.wsi.android.surface#query_protected_capabilities
Fixes: 79e4451430 ("v3dv: move extensions table to v3dv_device")
Signed-off-by: Roman Stratiienko <roman.o.stratiienko@globallogic.com>
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14144>
(cherry picked from commit fcfc4ddfcc)
(v1) Changelog:
-Ddri-drivers option is added in MESON_GEN_NINJA
$(foreach ) cycle copies *_dri.so files to /vendor/lib{64}/dri/
(v2) Changelog
Remove unwanted Symlinks created for classic dri drivers
Update the comments describing each step
Rename .symlinks.timestamp to .targets.timestamp
Squash all the changes in one commit to facilitate picking in mesa stable
HowTo:
BoardConfig.mk: BOARD_MESA3D_CLASSIC_DRIVERS defines the list of classic dri drivers
example: BOARD_MESA3D_CLASSIC_DRIVERS := i965
Fixes: 8621bd8d ("android: Add scripts to build using meson")
Cc: "21.3" "21.2" mesa-stable
Reviewed-by: Roman Stratiienko <r.stratiienko@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13973>
We were setting anv_pipeline::sample_shading_enable based on
sampleShadingEnable without looking at minSampleShading. We would then
pass this value into nir_lower_wpos_center which would add sample_pos to
frag_coord. Then the back-end compiler picks up on the existence of
sample_pos and forces persample dispatch. This leads to doing
per-sample dispatch whenever sampleShadingEnable = VK_TRUE regardless of
the value of minSampleShading. This is almost certainly costing us
perf somewhere.
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14022>
(cherry picked from commit 1f559930b6)
Previously a predicated BREAK that appeared immediately before the WHILE
would get merged into the WHILE. This doesn't work if other flow
control (e.g., a CONT) can transfer directly to the WHILE.
On Intel platforms, this fixes the CTS test
dEQP-VK.graphicsfuzz.stable-binarysearch-tree-nested-if-and-conditional.
No shader-db changes on any Intel platform.
When this commit was first created (over a month before it is going to
land), there were some regressions that were prevented by other commits
in MR !13095. That does not appear to be the case now, so I don't know
what changed. Basically, the treatment of discard as a combination of
demote and terminate causes additional continues in some loops, and
those continues trigger this bug. The other commits from that MR
prevent those continues from being generated in the first place.
All Intel platforms had simlar fossil-db results. (Ice Lake shown)
Instructions in all programs: 144419989 -> 144419995 (+0.0%)
SENDs in all programs: 6947332 -> 6947332 (+0.0%)
Loops in all programs: 38277 -> 38277 (+0.0%)
Spills in all programs: 204075 -> 204075 (+0.0%)
Fills in all programs: 319480 -> 319480 (+0.0%)
A few shaders in Doom 2016 were hurt by one instruction each. It seems
likely that these shaders would have experienced at least some
mis-rendering.
Closes: #4213
Fixes: d13bcdb3a9 ("i965/fs: Extend predicated break pass to predicate WHILE.")
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14128>
(cherry picked from commit 4563261ad1)
When mesa3d is built without VK_USE_PLATFORM_DISPLAY_KHR definition,
dEQP test fails:
dEQP : Test case 'dEQP-VK.info.instance_extensions'..
dEQP : Fail (Extension VK_KHR_get_display_properties2 is missing
dependency: VK_KHR_display)
dEQP : DONE!
Enable KHR_get_display_properties2 only if VK_USE_PLATFORM_DISPLAY_KHR
is enabled.
Fixes: f884c2e3be ("v3dv: implement VK_KHR_get_display_properties2")
Signed-off-by: Roman Stratiienko <roman.o.stratiienko@globallogic.com>
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14047>
(cherry picked from commit 72db15913f)
This virtual instruction is translated into multiple half float
physical instructions, even though its destination is typically of
integer type, which prevents the software scoreboard pass from
inferring the correct execution pipeline for the virtual instruction
on XeHP+ platforms. Teach the SWSB lowering pass about this
inconsistency between the IR and physical instruction types.
Fixes among other tests:
dEQP-GLES31.functional.shaders.builtin_functions.pack_unpack.packhalf2x16_compute
Fixes: d4537770bb ("intel/fs: Add helper functions inferring sync and exec pipeline of an instruction.")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5685
Reported-by: Tapani Pälli <tapani.palli@intel.com>
Tested-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14002>
(cherry picked from commit de55fd358f)
ASAN found a leak:
```
Direct leak of 1440 byte(s) in 10 object(s) allocated from:
#0 0x4a9a92 in calloc (build-Monado-CMake/src/xrt/targets/service/monado-service+0x4a9a92)
#1 0x7fdf82afed06 in drmDeviceAlloc build-drm/../drm/xf86drm.c:3933:14
#2 0x7fdf82b00203 in drmProcessPciDevice build-drm/../drm/xf86drm.c:3965:11
#3 0x7fdf82b00203 in process_device build-drm/../drm/xf86drm.c:4359:16
#4 0x7fdf82b0485e in drmGetDevice2 build-drm/../drm/xf86drm.c:4528:15
#5 0x7fdf70751113 in device_select_find_xcb_pci_default ../src/vulkan/device-select-layer/device_select_x11.c:95:13
#6 0x7fdf70751113 in get_default_device ../src/vulkan/device-select-layer/device_select_layer.c:395:21
#7 0x7fdf70751113 in device_select_EnumeratePhysicalDevices ../src/vulkan/device-select-layer/device_select_layer.c:456:33
```
Cc: mesa-stable
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14068>
(cherry picked from commit 555f93cdcd)
From VK_KHR_synchronization2:
"Image memory barriers that do not perform an image layout
transition can be specified by setting oldLayout equal to
newLayout.
E.g. the old and new layout can both be set to
VK_IMAGE_LAYOUT_UNDEFINED, without discarding data in the
image."
v2: make assert more readable (Lionel Landwerlin)
Cc: mesa-stable
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14008>
(cherry picked from commit d44d2e823f)
Found while running valgrind :
==3583454== Invalid read of size 4
==3583454== at 0xF48336: glsl_get_struct_field_offset (nir_types.cpp:84)
==3583454== by 0xC7CD0D: opt_replace_struct_wrapper_cast (nir_deref.c:1068)
==3583454== by 0xC7CDD9: opt_deref_cast (nir_deref.c:1087)
==3583454== by 0xC7DD8E: nir_opt_deref_impl (nir_deref.c:1369)
==3583454== by 0xC7DF4E: nir_opt_deref (nir_deref.c:1428)
==3583454== by 0xA63F3C: brw_kernel_from_spirv (brw_kernel.c:325)
==3583454== by 0xA3BC2C: main (intel_clc.c:481)
==3583454== Address 0xe4f7e88 is 24 bytes after a block of size 48 in arena "client"
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13952>
(cherry picked from commit 8e568d3f00)
libLLVM for Android is built without RTTI, but after commit ad86267
mesa inherits meson default RTTI enabled state.
cpp_rtti=false is added to meson options in android/mesa3d_cross.mk
(v2) Add Fixes tag and use spaces instead of tabs for aligning the trailing \
Signed-off-by: Mauro Rossi <issor.oruam@gmail.com>
Fixes: ad862674 ("meson: Don't override built-in cpp_rtti option, error if it's invalid")
Cc: "21.3" "21.2" mesa-stable
Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13901>
(cherry picked from commit 1ba231fb75)
When cloning a chunk of tracepoints, we cannot just copy the elements
of the traces[] array. We also need the payloads associated with
those.
This change introduces a new u_trace_payloaf_buf object that is
refcounted so that we can easily import traces[] elements and their
payloads from one utrace to another.
v2: use u_vector (Danylo)
v3: Delete outdate comment (Danylo)
Fix assert (Danylo)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 0565c993f9 ("u_trace: helpers for tracing tiling GPUs and re-usable VK cmdbuffers")
Reviewed-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13899>
(cherry picked from commit 14e45cb21e)
spirv_to_nir sometimes wraps derefs in vec2 or mov instructions as part of
its texture handling. These get in the way of
nir_rematerialize_derefs_in_use_blocks_impl. Running copy propagation
should get rid of the extra move instructions and get us back to intact
deref chains for everything except variable pointer use-cases.
fossil-db (Sienna Cichlid):
Totals from 6 (0.00% of 134572) affected shaders:
CodeSize: 92656 -> 93088 (+0.47%)
Instrs: 17060 -> 17138 (+0.46%)
Latency: 224408 -> 227539 (+1.40%)
InvThroughput: 37402 -> 37924 (+1.40%)
VClause: 408 -> 402 (-1.47%)
Copies: 1065 -> 1107 (+3.94%)
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5668
Fixes: 14a12b771d ("spirv: Rework our handling of images and samplers")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13924>
(cherry picked from commit b425100781)
The function need_temp_reg_initialization looks suspecious.
It will only ever return true if we get past this if:
if (!(emit->info.indirect_files && (1u << TGSI_FILE_TEMPORARY)) ...
Using the logical && means the intended initialization done
based on the result of this check is not performed.
This code was both introduced and altered in MR 5317.
ccb4ea5a introduces the function.
ba37d408 is a collection of performance improvements and misc
fixes. This altered the if from using bitwise to logical and.
This commit changes it back to bitwise.
Spotted from a compile warning.
Fixes: ba37d408da ("svga: Performance fixes")
Reviewed-by: Zoltán Böszörményi <zboszor@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12157>
(cherry picked from commit 64292c0f05)
In the following scenario:
CmdBindPipeline()
CmdBindVertexBuffers()
CmdSetVertexInput()
CmdDraw()
CmdBindVertexBuffers()
CmdSetVertexInput()
CmdDraw()
The VBO won't be updated for the second draw because the state is
cleared when the dynamic state is emitted and the pipeline isn't dirty.
Found by inspection.
Cc: 21.3 mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13855>
(cherry picked from commit aee25471b9)
Now that we removed the intel intrinsic and just use the generic one,
we can skip it in the intel call lowering pass and just deal with it
in the intel rt intrinsic lowering.
v2: rewrite with nir_shader_instructions_pass() (Jason)
v3: handle everything in switch (Jason)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 423c47de99 ("nir: drop the btd_resume_intel intrinsic")
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12113>
(cherry picked from commit c5a42e4010)
If the source and destination were within the same full register, like
hr90.x and hr90.y (which both map to r45.x), then we'd perform the
swap/copy with the wrong register. This broke
dEQP-VK.ssbo.phys.layout.random.16bit.scalar.35 once BDA is enabled.
Fixes: 0ffcb19b9d ("ir3: Rewrite register allocation")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13818>
(cherry picked from commit c98adc56f4)
If we did, we would have the instruction coming right after ldvary write
to the same implicit destination as ldvary at the same time. We prevent
this when merging instructions, but we should make sure we prevent this
when we move ldvary around for pipelining too.
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
(cherry picked from commit 79dee14cc2)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13923>
According to the spec the hardware locks the scoreboard on the first
or last thread switch (selected via shader state) and any TLB accesses
executed before this are not synchronized by hardware.
This change updates the logic to ensure we respect this requirement
and that we don't assume that the lock is acquired automatically
on the first TLB access, which is not valid at least since V3D 4.1+.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
(cherry picked from commit 7fec4f4135)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13923>
We need to perform cross-batch flushing if any batch writes to a BO
while others refer to it. We checked this case when recording a new
BO in the list which we'd never seen before. However, we neglected to
handle the case when we already read from a BO, but then began writing
to it. That new write may provoke a conflict between existing reads
in other batches, so we need to re-check the cross-batch flushing.
Caught by Piglit's copyteximage when forcing blits and copies to use
a new IRIS_BATCH_BLITTER that isn't upstream yet. But this bug could
be provoked by render/compute work today...we just hadn't noticed it.
Fixes: b21e916a62 ("iris: Combine iris_use_pinned_bo and add_exec_bo")
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13808>
(cherry picked from commit 6e90984934)
No matter the format, this should return true if the instruction has an
exec operand.
Otherwise, eliminate_useless_exec_writes_in_block() could remove an exec
write in a block if it's successor begins with:
s2: %3737:s[8-9] = p_parallelcopy %0:exec
s2: %0:exec, s1: %3738:scc = s_wqm_b64 %3737:s[8-9]
Totals from 3 (0.00% of 150170) affected shaders (GFX10.3):
CodeSize: 23184 -> 23204 (+0.09%)
Instrs: 4143 -> 4148 (+0.12%)
Latency: 98379 -> 98382 (+0.00%)
Copies: 172 -> 175 (+1.74%)
Branches: 95 -> 97 (+2.11%)
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Fixes: bc13049747 ("aco: Eliminate useless exec writes in jump threading.")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5620
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13776>
(cherry picked from commit d89461208b)
VK CTS just added some new tests to write to a compressed image
from a compute shader, which was overrunning memory.
The image width/height need to be sized according to the block
sizes to avoid overwriting memory.
dEQP-VK.image.sample_texture.*bit_compressed*
Cc: mesa-stable
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13618>
(cherry picked from commit 27903abbb6)
Pattern match the point coord sysval and support lowering it as well.
This is required to handle flipped framebuffers on Bifrost. However,
what this pass normalizes to is the opposite of the hardware mode we
used on Bifrost before, so we need to swap modes at the same time to
prevent regressions.
Fixes Piglit glsl-fs-pointcoord and glsl-fs-pointcoord_gles2
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13073>
(cherry picked from commit e257344a82)
We need to guarantee that when vkQueueSubmit() returns the application
can actually wait on a signaled semaphore/syncobj.
When using a thread to do the submission to i915, this gets a bit
tricky in the following case :
A syncobj is used both as a wait & signal semaphore and has been
signaled once already. It contains a fence before entering
vkQueueSubmit().
This means we need to reset the syncobj to ensure when we return
from vkQueueSubmit(), the syncobj contains no stale fence.
Currently in the Anv, the submission thread is in charge of putting
the new fence in the syncobj and also picks up the wait fence
directly from the syncobj. This means we can't reset the syncobj
from vkQueueSubmit().
The solution to this has been pointed by Bas & Jason :
In vkQueueSubmit(), clone the wait syncobj fence into a new
temporary syncobj that will be destroy after submission and use
this temporary syncobj as a wait fence for i915. This allows us to
reset the original syncobj in vkQueueSubmit().
For this to work with wait_before_signal behavior, we also need to
do a wait-on-materialize on binary semaphores from vkQueueSubmit().
Otherwise the application thread calling vkQueueSubmit() could race
the submission thread and pick up the wrong fence when cloing.
v2: Use copy semantic for clone_syncobj_dma_fence() (Jason)
Do the cloning prior to adding the syncobj to anv_queue_submit so
that if the cloning fails don't have an invalid syncobj in
anv_queue_submit (Jason)
v3: Fix another syncobj leak (Jason)
v4: Fix invalid argument order (Lionel)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4945
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11474>
(cherry picked from commit d2ff2b9e4a)
In order to implement GL_PRIMITIVES_GENERATED, v3d allocates a small
resource and adds a command to the job to store the prim counts to it.
However it was only doing this when TF was enabled which meant that if
the query was used with a geometry shader but no TF then the query would
always be zero. This patch makes the driver keep track of how many
PRIMITIVES_GENERATED queries are in flight and then enable writing the
prim count if its more than zero.
Fix dEQP-GLES31.functional.geometry_shading.query.primitives_generated_*
v2: Update CI expectations and references to fixed tests in commit log.
v3: - Add comment that GL_PRIMITIVES_GENERATED query is included because
OES_geometry_shader, but it is not part of OpenGL ES 3.1. (Iago)
- Update Fixes to commit introducing geometry shaders. (Iago)
Fixes: a1b7c084 ("v3d: fix primitive queries for geometry shaders")
Signed-off-by: Neil Roberts <nroberts@igalia.com>
Signed-off-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13712>
(cherry picked from commit bdaf185889)
We reference the scratch BO using a bindless index in the command
streamer instructions, but we forgot to add them to the BO list.
v2: Make use of pipeline reloc list (Jason)
v3: Don't add NULL BOs to the reloc list (Lionel)
v4: Don't add BOs twice to reloc list when dealing with addresses
(Lionel)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: eeeea5cb87 ("anv: Add support for scratch on XeHP")
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13544>
(cherry picked from commit 46c37c8600)
this was a little spaghetti-ish: the module hash was sometimes being applied
during module update, sometimes in draw during program create, and then also
it was removed when a shader unbind would cause the program to no longer be reachable
now things are more consistent:
* keep removing module hash when program becomes unreachable
* only apply module hash in draw during updates there
cc: mesa-stable
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13727>
(cherry picked from commit bfa81c1e8c)
When the client calls vkMapMemory(), we have to align the requested
offset down to the nearest page or else the map will fail. On platforms
where we have DRM_IOCTL_I915_GEM_MMAP_OFFSET, we always map the whole
buffer. In either case, the original map may start before the requested
offset and we need to take that into account when we clflush.
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13610>
(cherry picked from commit 90ac06e502)
We have to mark the root as non-spillable in case the interval is the
child of some other interval, but we can't know whether it's the child
of some other interval until it's been inserted. Move the setting of
cant_spill below the insertion. This prevents us from using a bogus
parent value.
Fixes: 613eaac7b5 ("ir3: Initial support for spilling non-shared registers")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13650>
(cherry picked from commit db566904ba)
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>
(cherry picked from commit e10c641f00)
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>
(cherry picked from commit 1ee3fbd703)
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>
(cherry picked from commit 8c37cd8860)
We have to set 8c01 to say "leave these channels alone" when
clearing/storing just Z or S of z24s8. Fixes the bypass path for
KHR-GLES3.packed_depth_stencil.verify_read_pixels.depth24_stencil8.
Cc: mesa-stable
Fixes: #5592
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13659>
(cherry picked from commit f0f5b8d47c)
The gmem store stores both depth and stencil for z24s8. So, if we're
doing a write (clear or draw) to one or the other of the channels, we need
the other one restored as well.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13649>
(cherry picked from commit 29093bc42d)
At that point we didn't call all the v3dv lowerings. So the reference
nir shader used to call the v3d compiler could be different.
Note that at that point the nir shader is only available for internal
shaders (like gs multiview).
This specifically affected multiview tests that wrote gl_PointSize, as
the nir shader for the geometry shader were wrongly exposing
per_vertex_point_size as false, as we were basing our check on the
nir_shader_info, and that was gathered calling nir_shader_gather_info
at pipeline_lower_nir.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13325>
(cherry picked from commit 19894bec1f)
OpenGL 3.0 requires the driver can draw to 8 simultaneous render
targets. Similarly, OpenGL ES 3.0 requires the driver can draw to 4
simultaneous render targets. Fix the version computation logic to take
this into account.
On Mali T720, we support ~all features of OpenGL ES 3.1 except we only
support a single render target. Mali T720 should advertise OpenGL 2.1
and OpenGL ES 2.0 only. With the previous logic, it incorrectly
advertised OpenGL ES 3.1.
v2: Lie about the minimum for GL 3.0 to make freedreno a3xx happy. Add
Emma's reviewed-by.
v3: Update the Mali T720 CI expectations. There are tests that pass on
GLES3 but not GLES2. Unclear if these are dEQP bugs or Mesa bugs, lima
hits the same issues. Add them to the known fails
Note to mesa-stable maintainers: this downgrades the OpenGL version
advertised on Mali T720. As such, this patch should apply to the
unreleased 21.3 (Eric) but should NOT be backported to any released Mesa
versions (21.2 or older should NOT have this patch). This is a bit of a
compromise; Emma agreed with this plan on IRC.
Reported-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Emma Anholt <emma@anholt.net> [v2]
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu> [v2]
Cc: 21.3 mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13455>
(cherry picked from commit 861a35b3bc)
* Update Kconfig for x86_64 and ARM64. Follow the dependency tree of the
kernel modules to make sure that the intended configurations are being
set. Check scripts/merge_config.sh output as well to see if there is
a requested Kconfig not being considered.
For a630 devices:
* Use kernel version with a6xx workaround for frequency scaling
* Enable CONFIG_QCOM_LMH targeting a630 slowness on new kernel
---- Out of tree patches used ----
For a360 device:
* Revert a commit which remove slpi_region from msm8996:
8b0031f8bda2 ("Revert "arm64: msm8996: fix memory region overlap"")
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13089>
(cherry picked from commit 7fea3c6f14)
We've noticed issues with these tests when uprevving Mesa in Chrome OS.
This CI catches some existing failures, and some debug-build assertion
failures as well.
To do this, uprev deqp-runner for its new gtest-runner command. This
runner is not as efficient as I would hope, due to some expensive code in
gtest. I've reported the issue to gtest and it should be easily fixable,
but for now it at least means we get to use the same baseline/skip/flake
handling we have from deqp and piglit runners.
I also fixed build-libdrm for our rootfses to not throw away libdrm's
share directory, which was causing a bunch of test-time spam from radeon's
libdrm when trying to look up its marketing name tables (not that big of a
deal for deqp-runner, but really noisy for piglit and libva-utils which
make gallium screens approximatly per-test).
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13419>
(cherry picked from commit 8fb850651c)
The test names are definitely unique (deqp has specific prefixes, piglit
uses '@' as a separator instead of '.'), so we can just have a single file
regardless of test type. Merges the two groups of xfails together so you
can't mix up which file to edit (I certainly have), and so that we don't
need to introduce yet another set of files when we add gtest for libva.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Acked-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13517>
(cherry picked from commit bfbc41a9fa)
This is prettier in the log files, less shell code, and for non-suite mode
adds checking that the driver has the right git sha1. Also, no need for
suites to have a DEQP_VER to say which dEQP we should run for the renderer
check.
The version checks can help us make sure that GL version exposed doesn't
accidentally regress, and the ".*git" checks that we're using a git
version of Mesa rather than something that snuck in through distro
packages.
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13372>
(cherry picked from commit b978688df6)
vertex shader stages that can produce xfb must have
their input size clamped to the compiler define MAX_VARYING
to successfully be able to export an xfb output for each input
fixes KHR-GL46.geometry_shader.limits.max_input_components
cc: mesa-stable
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13632>
(cherry picked from commit 5d1b81d8ac)
sparse binds have to be processed synchronously with cmdbuf recording to
avoid resource object desync in the vk driver, which means they have to be
done in the driver thread instead of the flush thread. this necessitates
adding locking for the queue since there is now a case when submissions occur
in a different thread
fixes illegal multithread usage in KHR-GL46.CommonBugs.CommonBug_SparseBuffersWithCopyOps
cc: mesa-stable
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13597>
(cherry picked from commit 3137ff4709)
Lavapipe was hitting asserts in this area due to incorrect bits being
specified.
Set the handle type depending on the sw flag, and set a correct handle
type for the memory host ptrs.
v2: add image export struct to image creation (Jason)
Fixes: 895d3399f7 ("lavapipe: add support for KHR_external_memory_fd")
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13615>
(cherry picked from commit a8725ec3dc)
Fixes dEQP-VK.reconvergence.*nesting* tests.
There are cases when cmod is set to an instruction that cannot have
conditional modifier. E.g. following:
find_live_channel(32) vgrf166:UD, NoMask
cmp.z.f0.0(32) null:D, vgrf166+0.0<0>:D, 0d
is optimized to:
find_live_channel.z.f0.0(32) vgrf166:UD, NoMask
v2:
- Add unit test to check cmod is not set to 'find_live_channel' (Matt Turner)
- Update flag_subreg when conditonal_mod is updated (Ian Romanick)
Signed-off-by: Vadym Shovkoplias <vadym.shovkoplias@globallogic.com>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5431
Fixes: 32b7ba66b0 ("intel/compiler: fix cmod propagation optimisations")
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13268>
(cherry picked from commit 2dbb66997e)
The original implementation in os_memory_fd.c always uses memfds.
Replace this by using the already existing os_create_anonymous_file in
order to support older systems or systems without memfd.
Fixes: 1166ee9caf ("gallium: add utility and interface for memory fd allocations")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13331>
(cherry picked from commit 4856586ac6)
zink_resource_has_binds() only checks descriptor binds, and this doesn't
include streamout or fb bindings, so call these functions from the specific
rebind points to ensure those cases are also checked
fixes#5541
cc: mesa-stable
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13490>
(cherry picked from commit 0a6f5ec942)
When compiling for x86 with MSVC, Vulkan API entry points follow the
__stdcall convention (VKAPI_CALL maps to __stdcall), which uses the
following name mangling:
_<function_name>@<arguments_size>
Fix the vk_entrypoint_stub()/alternatename definitions accordingly.
Fixes: 6d44b21d4f ("vulkan: Fix weak symbol emulation when compiling with MSVC")
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13516>
(cherry picked from commit 1813bb5917)
The streamout_config SGPR is used to determine if streamout is enabled.
This fixes a GPU hang with various transform feedback tests:
- dEQP-GLES3.functional.transform_feedback.*
- KHR-GL46.transform_feedback.api_errors_test
- KHR-GL46.draw_indirect.basic-draw*-xfbPaused
- KHR-GL46.geometry_shader.api.draw_calls_while_tf_is_paused
Cc: 21.3 mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13514>
(cherry picked from commit dc74285d32)
AFBC is keyed to the format. Depending on the hardware, we'll get an
Invalid Data Fault or a GPU timeout if we attempt to sample from an
AFBC-compressed RGBA8 texture as R32F (for example).
Fixes Piglit ./bin/arb_texture_view-rendering-formats_gles3 with AFBC.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13205>
(cherry picked from commit 789601a189)
We need to know the internal (physical) formats used for AFBC of a given
logical format, in order to check format compatibility and determine if
we need to decompress AFBC for conformance.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13205>
(cherry picked from commit 93c9123c31)
According to mali_kbase, all Bifrost and Valhall GPUs are affected by
issue TSIX_2033. This hardware bug breaks the INTERSECT frame shader
mode when forcing clean_tile_writes. What does that mean?
The hardware considers a tile "clean" if it has been cleared but not
drawn to. Setting clean_tile_write forces the hardware to write back
such "clean" tiles to main memory.
Bifrost hardware supports frame shaders, which insert a rectangle into
every tile according to a configured rule. Frame shaders are used in
Panfrost to implement tile reloads (i.e. LOAD_OP_LOAD). Two modes are
relevant to the current discussion: ALWAYS, which always inserts a frame
shader, and INTERSECT, which tries to only insert where there is
geometry. Normally, we use INTERSECT for tile reloads as it is more
efficient than ALWAYS-- it allows us to skip reloads of tiles that are
discarded and never written back to memory.
From a software perspective, Panfrost's current logic is correct: if we
clear, we set clean_tile_writes, else we use an INTERSECT frame shader.
There is no software interaction between the two.
Unfortunately, there is a hardware interaction. The hardware forces
clean_tile_writes in certain circumstances when AFBC is used.
Ordinarily, this is a hardware implementation detail and invisible to
software. Unfortunately, this implicit clean tile write is enough to
trigger the hardware bug when using INTERSECT. As such, we need to
detect this case and use ALWAYS instead of INTERSECT for correct
results.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13205>
(cherry picked from commit 342ed4909f)
The gl_FragColor lowering in the fragment shader depends on the number
of render targets, which can change every set_framebuffer_state.
set_framebuffer_state thus needs to force a rebind of the fragment
shader.
Fixes a regression in Piglit fbo-drawbuffers-none gl_FragColor -auto
-fbo from enabling AFBC on Mali G52.
Fixes: 28ac4d1e00 ("panfrost: Call nir_lower_fragcolor based on key")
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13498>
(cherry picked from commit e0335ad888)
This uses the new property for AFBC we've added. The AFBC quirk is
applied only to v4, and we only set dev->has_afbc on v5+ so this is not
a regression. It now respects the hardware-specific AFBC disable.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13497>
(cherry picked from commit 68a7fafe2a)
If the application first uses nontrivial divisors, the driver emits
the vertex shader VA to the upload BO rather than directly via the
user SGPRs locations. But, if the vertex input dynamic state changes,
the driver might select a different VS prolog that no longer needs
nontrivial divisors.
In this case, the driver needs to re-emit the prolog inputs because
otherwise the VS prolog will jump to the PC that is emitted via the
user SGPR locations, and the previous one was somewhere in the
upload BO...
This fixes a GPU hang with Bioshock and Zink.
Fixes: d9c7a17542 ("radv: enable VK_EXT_vertex_input_dynamic_state")
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13377>
(cherry picked from commit b6a69dbb40)
This was not considering the possibility that the driver has called
nir_before_block() or nir_after_block() to update the cursor, in which
case the cursor link points to the instruction list header and not
to an actual instruction.
Fixes incorrect debug-assert crash in:
dEQP-VK.graphicsfuzz.cov-increment-vector-component-with-matrix-copy
Fixes: 265515fa62 ("broadcom/compiler: check instruction belongs to current block")
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13467>
(cherry picked from commit 1561d0126a)
this was a bit confusing to read, and I originally left it in the hybrid
path to enable fallbacks to push descriptors in hybrid mode. the problem with
that idea is that it's impossible: the constant buffer set is the one set
that will never, ever trigger a fallback, so leaving it there just leaves
room for error and confusion
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13350>
(cherry picked from commit 7c840f5103)
this is a wild race condition, but it's possible for these to get their
final unref, enter their destructor, and then get a cache hit while waiting
on the lock to remove themselves from the cache
in such a scenario, a second, normal check of the refcount will suffice,
as the increment is atomic, and the value will otherwise be zero
fixes crashes in basemark
cc: mesa-stable
Reviewed-by: Hoe Hao Cheng <haochengho12907@gmail.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13442>
(cherry picked from commit 86b3d8c66c)
INTEL_DEBUG is defined (since 4015e1876a) as:
#define INTEL_DEBUG __builtin_expect(intel_debug, 0)
which unfortunately chops off upper 32 bits from intel_debug
on platforms where sizeof(long) != sizeof(uint64_t) because
__builtin_expect is defined only for the long type.
Fix this by changing the definition of INTEL_DEBUG to be function-like
macro with "flags" argument. New definition returns 0 or 1 when
any of the flags match.
Most of the changes in this commit were generated using:
for c in `git grep INTEL_DEBUG | grep "&" | grep -v i915 | awk -F: '{print $1}' | sort | uniq`; do
perl -pi -e "s/INTEL_DEBUG & ([A-Z0-9a-z_]+)/INTEL_DBG(\1)/" $c
perl -pi -e "s/INTEL_DEBUG & (\([A-Z0-9_ |]+\))/INTEL_DBG\1/" $c
done
but it didn't handle all cases and required minor cleanups (like removal
of round brackets which were not needed anymore).
Signed-off-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13334>
(cherry picked from commit d05f7b4a2c)
Patch 77c2b022a0 removed lowering of 64-bit vertex attribs to 32bits.
This has thrown TGSI translation off the guard for 64bit attrib.
This lead to fail/crash of 1000+ piglit tests.
This patch basically fixes 64 bit attrib index for TGSI shader by adding placeholder
for second part of a double attribute.
It fixes all regressed piglit tests.
A big help from Charmaine to fix this regression
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Fixes: 77c2b022a0 ("st/mesa: remove lowering of 64-bit vertex attribs to 32 bits")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13363>
(cherry picked from commit be6d584de4)
The following chain of events results in an incorrectly sized buffer
persisting beyond its useful lifetime, and causing visual artifacts.
buffer is attached at size A
window is resized to size B
rendering takes place for size B
window is resized back to size A
swapbuffers with damage is called
In this scenario, update_buffers fails to recognize that the surface it's
about to commit is a different size than it has rendered. The
attached_width and attached_height are set incorrectly, and periodic
flickering is observed.
Instead, we set a boolean flag at time of resize and use this at the time
we latch the window dimensions as surface dimensions to decide whether to
discard stale buffers.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13270>
(cherry picked from commit 28d12716e8)
originally, a slab attempts to reclaim a single bo. there are two outcomes
to this which can occur:
* the bo is reclaimed
* the bo is not reclaimed
if the bo is reclaimed, great.
if the bo is not reclaimed, it remains at the head of the list until it can
be reclaimed. this means that any bo with a "long" work queue which makes it
into a slab will effectively kill the entire slab. in a benchmarking scenario,
this can occur in rapid succession, and every slab will get 1-2 suballocations
before it reaches a bo that blocks long enough for a new slab to be needed.
the inevitable result of this scenario is that all memory is depleted almost instantly,
all because pb assumes that if the first bo in the reclaim list isn't ready, none of them
can be ready
for drivers like radeonsi, this happens to be a fine assumption
for drivers like zink, this is entirely not workable and explodes the gpu
Cc: mesa-stable
Reviewed-by: Witold Baryluk <witold.baryluk@gmail.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Tested-by: Witold Baryluk <witold.baryluk@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13345>
(cherry picked from commit 3d6c8829f5)
Scratch patching code in iris_upload_dirty_render_state (see MERGE_SCRATCH_ADDR
calls) assumes that in all shader stages derived_data field stores 3DSTATE_XS
packet first.
This is not true for TESS_EVAL (DS), so we end up patching 3DSTATE_TE
instead of 3DSTATE_DS leading to DWordLength becoming 11 instead of 9
(9 == 3DSTATE_DS.DWordLength, 2 == 3DSTATE_TE.DWordLength, and 9|2 == 11),
and hardware hanging on the next instruction.
Fix this by reversing the order of packets for TESS_EVAL stage.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5499
Fixes: 4256f7ed58 ("iris: Fill out scratch base address dynamically")
Signed-off-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13358>
(cherry picked from commit 5387522bd0)
When eglReleaseThread() is called from application's
destructor (API with __attribute__((destructor))),
it crashes due to invalid memory access.
In this case, _egl_TLS is freed in the flow of
_eglAtExit() as below but _egl_TLS is not set to NULL.
_eglDestroyThreadInfo
_eglFiniTSD
_eglAtExit
_run_exit_handlers
exit
Later when the eglReleaseThread is called from
application's destructor, it ends-up accessing
the freed _egl_TLS pointer.
eglReleaseThread -> in libEGL_mesa
eglReleaseThread -> in libEGL(glvnd)
destructor() -> App's destructor
To resolve the invalid access, setting the _egl_TLS
pointer as NULL after freeing it.
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5466
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13302>
(cherry picked from commit 796c9ab3fd)
This sets the conformance version to 0.0.0.0 for GPUs that have
incomplete support for vulkan, so that it's easier to check if vulkan is
fully supported by a GPU at runtime for applications/libraries.
$ vulkaninfo|grep conf
MESA-INTEL: warning: Ivy Bridge Vulkan support is incomplete
conformanceVersion = 0.0.0.0
Signed-off-by: Clayton Craft <clayton@craftyguy.net>
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13275>
(cherry picked from commit b2ef7e6d6b)
VK_ERROR_INITIALIZATION_FAILED can happen as part of device creation and
isn't really an instance error in that case.
VK_ERROR_EXTENSION_NOT_PRESENT, on the other hand, is always an instance
thing and we should handle it as such.
Fixes: 0cad3beb2a ("vulkan/log: Add common vk_error and vk_errorf helpers")
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13341>
(cherry picked from commit 071437d29d)
Mapping unimplemented entrypoints to a global function pointer variable
initialized to NULL is a bit cumbersome, and actually led to a bug
in the vk_xxx_dispatch_table_from_entrypoints() template: the !override
case didn't have the right check on the source table entries. Instead of
fixing that case, let's simplify the logic by creating a stub function
and making the alternatename pragma point to this stub. This way we get
rid of all those uneeded xxx_Null symbols/variables and simplify the
tests in vk_xxxx_dispatch_table_from_entrypoints().
Cc: mesa-stable
Fixes: 98c622a96e ("vulkan: Update dispatch table gen for Windows")
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13348>
(cherry picked from commit 6d44b21d4f)
Two carchase compute shaders (shader-db) and two Fallout 4 fragment
shaders (fossil-db) were helped. Based on the NIR of the shaders, all
four had structures like
for (i = 0; i < 1; i++) {
...
for (...) {
...
}
}
All HSW+ platforms had similar results. (Ice Lake shown)
total loops in shared programs: 6033 -> 6031 (-0.03%)
loops in affected programs: 4 -> 2 (-50.00%)
helped: 2
HURT: 0
All Intel platforms had similar results. (Ice Lake shown)
Instructions in all programs: 143692018 -> 143692006 (-0.0%)
SENDs in all programs: 6947154 -> 6947154 (+0.0%)
Loops in all programs: 38285 -> 38283 (-0.0%)
Cycles in all programs: 8434822225 -> 8434476815 (-0.0%)
Spills in all programs: 191665 -> 191665 (+0.0%)
Fills in all programs: 298822 -> 298822 (+0.0%)
In the presense of loop unrolling like this, the change in cycles is not
accurate.
v2: Rearrange the logic in the if-condition to read a little better.
Suggested by Tim.
Closes: #5089
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
(cherry picked from commit ae99ea6f4d)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13366>
Apparently, we've been requiring a 4K alignment for internally allocated
clear color addresses to work around some unknown issues. There's a
comment to that effect in iris_resource_create_with_modifiers().
When importing a dmabuf and tacking on an additional clear color BO, we
only required an alignment of 1. This wasn't a problem for a long time
because all BO allocations were naturally aligned to the 4K page size.
However, once we enabled suballocation, we were able to allocate "BOs"
at 256B granularity, making this no longer 4K aligned. Increase the
alignment requirement to 4K to match the behavior of our normal
allocations and also our previous behavior.
Fixes Piglit's ext_image_dma_buf_import-intel-modifiers.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5482
Fixes: ce2e2296ab ("iris: Suballocate BO using the Gallium pb_slab mechanism")
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13326>
Since we're not checking for this, xcb has to do it for us the first
time we call xcb_sync_destroy_fence, which puts a blocking round-trip in
the swapchain destroy path for no reason. Check for the extension so we
have the extension's opcode cached when we need it.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13339>
Only try to invalidate L2 if we actually hit one of the incoherent images.
Note we may actually insert some extra flushes at the end of a command
buffer so that we may asume the caches are clean the start of the next
command buffer. However, on average I think that case is uncommon
enough that being able to make assumptions at the start of a cmdbuffer
is beneficial. Especially since MSAA is somewhat rare in more recent
games.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13239>
By default line mode is VK_LINE_RASTERIZATION_MODE_RECTANGULAR_EXT,
when lineRasterizationMode is VK_LINE_RASTERIZATION_MODE_BRESENHAM_EXT
and primtype is line - we enable bresenham line mode.
We have to disable MSAA when bresenham lines are used, this is
a hardware limitation and spec allows it:
"When Bresenham lines are being rasterized, sample locations may
all be treated as being at the pixel center (this may affect
attribute and depth interpolation)."
This forces us to re-emit msaa state when line mode is changed.
Signed-off-by: Hyunjun Ko <zzoon@igalia.com>
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6020>
This bit seems like the control for line mode of rastrization.
That can be simply figured out by comparing
dEQP-VK.rasterization.primitives.no_stipple.bresenham_lines,
dEQP-VK.rasterization.primitives.no_stipple.rectangular_lines and
dEQP-VK.rasterization.primitives.no_stipple.lines.
For opengl, the value of bresenham lines mode, which is 0, is set
by default and the value of rectangular mode, which is 0x1, is set
when multi-sampled.
For vulkan, the bresenham lines are enabled when lineRasterizationMode is
VK_LINE_RASTERIZATION_MODE_BRESENHAM_EXT, which sets the bit to 0, while
the value is 1 when it's VK_LINE_RASTERIZATION_MODE_RECTANGULAR_EXT,
that seems to be default.
If both multi-sampled and bresenham-lines are used when primitive type is
line, the bit is to be set as 0 and makes msaa disabled.
Note that this is only tested on a6xx, but I guess it's likely the same
for a5xx.
Signed-off-by: Hyunjun Ko <zzoon@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6020>
For a long time, our Vulkan WSI code has acted as something of a layer.
The WSI code calls into various Vulkan entrypoints inside the driver to
create images, allocate memory, etc. It then implements the API-facing
interface almost entirely. The only thing the driver has to provide is
little wrappers that wrap around the WSI calls to expose them through
the API.
However, now that we have a common dispatch framework, we can implement
entrypoints directly in the WSI code. As long as the driver uses
vk_instance, vk_physical_device, and vk_device, we can provide common
wrappers for the vast majority of entrypoints. The only exceptions are
vkAcquireNextImage, vkQueuePresent, vkRegisterDeviceEventEXT, and
vkRegisterDisplayEventEXT because those may have to manually poke at
synchronization primitives. We provide wrappers for vkAcquireNextImage
and vkQueuePresent because some drivers can use the default versions.
For now, we're intentionally avoiding any link-time dependencies between
WSI and the common code. We only use VK_FROM_HANDLE and associated
inline helpers and vk_physical_device has a pointer to a wsi_device.
Eventually, we may tie the two together closer, but this lets us get 95%
of the way there without reworking the universe.
Acked-by: Chia-I Wu <olvaffe@gmail.com>
Acked-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13234>
In the following cases:
- lower 16 bits are extracted and the shift amount is 16 or more
- lower 8 bits are extracted and the shift amount is 24 or more
the undesireable upper bits are already shifted out, and therefore
there is no need to add SDWA to the v_lshlrev instruction.
Fossil DB stats on Sienna Cichlid with NGGC on:
Totals from 58239 (45.27% of 128647) affected shaders:
CodeSize: 153498624 -> 153265616 (-0.15%); split: -0.15%, +0.00%
Instrs: 29636304 -> 29578064 (-0.20%); split: -0.20%, +0.00%
Latency: 136931496 -> 136876379 (-0.04%); split: -0.04%, +0.00%
InvThroughput: 21134367 -> 21078861 (-0.26%); split: -0.26%, +0.00%
Copies: 2777550 -> 2777548 (-0.00%); split: -0.00%, +0.00%
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13121>
When the determinant that we use for calculating triangle area
is NaN, it's not possible to decide the facing of the triangle.
This can happen when a coordinate of one of the triangle's vertices
is INFINITY. It's better to just accept these triangles in the shader
and let the PA deal with them.
Let's do the same for +/- Infinity too.
Though we haven't seen this yet, it may be troublesome as well.
Fixes: 651a3da1b5Closes: #5470
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13299>
We were treating them the same as regular cat2/cat3/cat4 immediates, but
that's not right because cat6 sources are only 8 bits.
Our bindless code was handling this before for bindless resources, and
it was disabled for most other things, so this was mostly harmless, but
fixing it will be necessary for handling ldc offsets.
In addition enable tests for this that were just commented out, and add
a custom test making sure that the immediate source is treated as
unsigned.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13142>
Otherwise, when there are uses in multiple blocks the collect may not
dominate some of the uses.
This is a bugfix, but before it would've mattered only in weird
scenarios with interpolateAt*. When we start moving prefetch textures
into the block before the preamble it will start to matter more, because
it will need to read the barycentrics from a different block than the
bary.f instructions.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13142>
There's no reason to make this any different from the other builders,
since it just creates a collect instruction, and in the next commit
we'll need to create a collect in the first block for prefetch textures.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13142>
In order for the load to never straddle the load can't extend past 8
bytes, not 16. For example a vec2 load with align_mul = 8 and
align_offset = 4 can straddle.
Fixes assertion failures when we stop pushing UBOs in the preamble on
a6xx.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13142>
Fix a build error.
In file included from ../src/util/u_queue.h:38,
from ../src/freedreno/drm/freedreno_ringbuffer.h:33,
from ../src/freedreno/ds/fd_pps_driver.h:13,
from ../src/freedreno/ds/fd_pps_driver.cc:7:
../src/util/simple_mtx.h:35:12: fatal error: valgrind.h: No such file or directory
35 | # include <valgrind.h>
| ^~~~~~~~~~~~
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13280>
Let's assume we have a vec2 collect instruction with killed sources that
are non-contiguous and the entire rest of the register file is blocked,
which can happen when our register target is very tight. It's impossible
to just insert move instructions to resolve this, but we can make space
by swapping one of the killed sources with the value next to the other,
assuming it's also scalar.
This commit implements that idea, preventing us from falling back to the
terrible shuffle-everything approach in this case.
total instructions in shared programs: 1566648 -> 1565117 (-0.10%)
instructions in affected programs: 13332 -> 11801 (-11.48%)
helped: 30
HURT: 5
helped stats (abs) min: 6 max: 535 x̄: 51.77 x̃: 25
helped stats (rel) min: 2.67% max: 33.63% x̄: 12.28% x̃: 9.58%
HURT stats (abs) min: 1 max: 6 x̄: 4.40 x̃: 6
HURT stats (rel) min: 0.18% max: 5.13% x̄: 2.41% x̃: 2.13%
95% mean confidence interval for instructions value: -75.05 -12.43
95% mean confidence interval for instructions %-change: -13.18% -7.18%
Instructions are helped.
total mov in shared programs: 77336 -> 76683 (-0.84%)
mov in affected programs: 2135 -> 1482 (-30.59%)
helped: 29
HURT: 5
helped stats (abs) min: 2 max: 227 x̄: 23.31 x̃: 10
helped stats (rel) min: 6.06% max: 72.73% x̄: 31.83% x̃: 30.00%
HURT stats (abs) min: 2 max: 9 x̄: 4.60 x̃: 4
HURT stats (rel) min: 14.29% max: 69.23% x̄: 34.00% x̃: 27.78%
95% mean confidence interval for mov value: -33.21 -5.20
95% mean confidence interval for mov %-change: -32.94% -11.35%
Mov are helped.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13143>
We need the local size in RA for occupancy calculations. Not
initializing these had the unfortunate consequence of
ir3_get_reg_independent_max_waves() returning 0 for compute shaders with
shared variables, disabling the register limiting logic.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13143>
There are roughly two cases when it comes to storage images. In the
easy case, we have full hardware support and we can just emit a typed
read/write message in the shader and we're done. In the more complex
cases, we may need to fall back to a typed read with a different format
or even to a raw (SSBO) read.
The hardware has always had basically full support for typed writes all
the way back to Ivy Bridge but typed reads have been harder to come by.
Starting with Skylake, we finally have enough that we at least have a
format of the right bit size but not necessarily the right format so we
can use a typed read but may still have to do an int->unorm or similar
cast in the shader.
Previously, in ANV, we treated lowered images as the default and write-
only as a special case that we can optimize. This flips everything
around and treats the cases where we don't need to do any lowering as
the default "vanilla" case and treats the lowered case as special.
Importantly, this means that read-write access to surfaces where the
native format handles typed writes now use the same surface state as
write-only access and the only thing that uses the lowered surface state
is access read-write access with a format that doesn't support typed
reads. This has the added benefit that now, if someone does a read
without specifying a format, we can default to the vanilla surface and
it will work as long as it's a format that supports typed reads.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13198>
This will allow us to avoid postprocessing binaries when they are
loaded from the shaders cache.
LLVM binaries already contain the shader config as part of the ELF,
so it's duplicated and increase the cache entry by 48 bytes. Though,
I don't think that should matter for LLVM.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12992>
Description by Coverity:
"Unintentional integer overflow (OVERFLOW_BEFORE_WIDEN)
overflow_before_widen: Potentially overflowing expression 1 << b with type int
(32 bits, signed) is evaluated using 32-bit arithmetic, and then used in
a context that expects an expression of type VkAccessFlags2KHR (64 bits,
unsigned)"
CID: 1492745
CID: 1492748
Fixes: b996fa8efa ("anv: implement VK_KHR_synchronization2")
Signed-off-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13284>
This is similar change as commit f535ab59e2.
[2/4] Compiling C object src/mesa/libmesa_classic.a.p/swrast_s_texfilter.c.o
../src/mesa/swrast/s_texfilter.c: In function ‘sample_2d_footprint’:
../src/mesa/swrast/s_texfilter.c:1817:7: warning: ‘sample_2d_linear’ reading 16 bytes from a region of size 8 [-Wstringop-overread]
1817 | sample_2d_linear(ctx, samp, img, newCoord, rgba);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/mesa/swrast/s_texfilter.c:1817:7: note: referencing argument 4 of type ‘const GLfloat *’ {aka ‘const float *’}
../src/mesa/swrast/s_texfilter.c:1150:1: note: in a call to function ‘sample_2d_linear’
1150 | sample_2d_linear(struct gl_context *ctx,
| ^~~~~~~~~~~~~~~~
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13245>
Passes generally shouldn't use nir_metadata_all unless they don't change
the program in any significant way. Some of these passes insert new
instructions so they should definitely not be preserving most of it.
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13261>
This is mostly a matter of auditing uses of
cmd->state.framebuffer and replacing every use of fb->attachments with
cmd->state.attachments. We already weren't using the attachments
anywhere outside of the render pass, so this is pretty straightforward.
We also don't have any use for anything in
VkFramebufferAttachmentImageInfo so we can just ignore it.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13228>
This commit enables NGG culling on all GFX10.3 GPUs by default.
A new debug flag environment variable RADV_DEBUG=nonggc is added to
disable this feature on GPUs where it is enabled by default.
The previous perf test flag RADV_PERFTEST=nggc will not be needed on
GFX10.3 anymore but it can still be used to enable the feature on
GPUs where it isn't on by default.
Totals from 58239 (45.27% of 128647) affected shaders:
VGPRs: 1989752 -> 2049408 (+3.00%); split: -3.21%, +6.21%
SpillSGPRs: 675 -> 883 (+30.81%); split: -78.07%, +108.89%
CodeSize: 72205968 -> 153572764 (+112.69%)
LDS: 0 -> 227125248 (+inf%)
MaxWaves: 1614598 -> 1646934 (+2.00%); split: +3.08%, -1.08%
Instrs: 14202239 -> 29654042 (+108.80%)
Latency: 87986508 -> 136960419 (+55.66%); split: -0.23%, +55.89%
InvThroughput: 14444832 -> 21141875 (+46.36%); split: -0.01%, +46.37%
VClause: 340794 -> 493067 (+44.68%); split: -1.33%, +46.01%
SClause: 520983 -> 738636 (+41.78%); split: -0.25%, +42.03%
Copies: 775639 -> 2787382 (+259.37%)
Branches: 296911 -> 1225431 (+312.73%)
PreSGPRs: 1316896 -> 2057270 (+56.22%); split: -0.14%, +56.36%
PreVGPRs: 1473558 -> 1658432 (+12.55%); split: -1.44%, +13.99%
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13086>
In function fill_drm_device_info(), struct ext_pci_properties is filled only
if has_vulkan11 is true. But the data received from ext_pci_properties is used
without checking for has_vulkan11. Fixing this by setting
drm_device->has_bus_info also if has_vulkan11 is true.
This fix will help in case of nonidentical gpu being used and xcb_surface
extension enabled.
Signed-off-by: Yogesh Mohanmarimuthu <yogesh.mohanmarimuthu@amd.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12816>
Dropping the final pipe ref could in turn drop the final ref to one
of a couple other bo's, which in turn could indirectly recurse back
into cleanup_fences() on the same bo, resulting in a double decrement
of bo->nr_fences and underflow to a large positive #. This happens
because free'ing a bo back to the bo cache periodically calls
fd_bo_cache_cleanup() and any bo's that have not been re-used can
be really free'd, which in turn calls cleanup_fences().
Fixes: 7dabd62464 ("freedreno/drm: Userspace fences")
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13263>
it was useful to have this be a hash table back before timeline semaphores when
the batch state needed to be looked up every time to determine resource busy state,
but now in the modern world, this is almost never happening, and storing them like
this is actually worse for performance, so flatten it out into a simpler list
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13265>
I tried to be pointlessly clever here to avoid an atomic op, but the move()
here ended up leaking a ref in some cases (descriptor bind + multiple replacements in same cmdbuf)
more importantly, it's a stupid idea now that zink_resource_object structs
are entirely owned by the driver, meaning their refcounts are never
altered in threads, and thus the atomic ops are just regular ops
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13258>
when dispatch is fast enough, some tests fire off cmdbufs so quickly that the normal
oom flushing and batch pruning in end_batch isn't sufficient to keep memory
usage down
to combat this, start throwing in stalls after submission to clean out a bunch of cmdbufs
while preventing further ones from being submitted
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13247>
This reverts the following commit from main:
commit f6abb3445b
Author: Marek Olšák <maraeo@gmail.com>
Date: Fri Oct 1 15:46:48 2021 -0400
mesa: use simple_mtx_t for TexMutex
change mtx_recursive -> mtx_plain, there's no recursive locking
Acked-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13152>
Contrary to the claim in the commit message, there is recursive locking.
The meta stuff used by i965 does GL operations while the texture is
locked. If we don't allow recursive locks, it will deadlock. No, it's
not great, but it's the current state of affairs. Once we delete i965
in favor of crocus and any other users of meta, we can restore the above
patch. Until then, we need mtx_recursive.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13254>
The VK_ERROR_FRAGMENTED_POOL and VK_ERROR_OUT_OF_POOL_MEMORY errors are
not as exceptional cases as most. These are expected to be hit by
applications in the normal course of doing their thing. Probably best
not to spam stderr and the debug logs with them.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13045>
The VK_ERROR_FRAGMENTED_POOL and VK_ERROR_OUT_OF_POOL_MEMORY errors are
not as exceptional cases as most. These are expected to be hit by
applications in the normal course of doing their thing. Probably best
not to spam stderr and the debug logs with them.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13045>
When dealing with debug logging, it's useful to track when an object's
construction is finished and it's now visible to the client. We can
detect this pretty easily by setting a flag the first time foo_to_handle
is called. As long as drivers only ever call that function at the end
of object construction (they all do to my knowledge), this should be a
reliable mechanism for detecting when a client knows about a handle.
Tested-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13045>
This is an attempt at simplifying the spirv_to_nir() backend when it
comes to choosing between system values and input varyings. Let's patch
drivers to do the sysval to input varying conversion on their own so we
can get rid of the frag_coord_is_varying field in spirv_to_nir_options
and unconditionally create create sysvals for FragCoord, FrontFacing and
PointCoord inputs instead of adding new xxx_is_{sysval,varying} flags.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Suggested-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Hyunjun Ko <zzoon@igalia.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13017>
Gallium caches sampler states for TBOs. Now if a buffer is first
attached to a TBO specifying one format, and later attached by
specifying another format and this TBO is then used, that would lead
to an assertion failure in debug builds, or to invalid rendering in
release builds, because the TBO picks the original, wrong format for
the sampler view.
Resolve this by signalling the change to Gallium (and other drivers), so
that Gallium clears the sampler view cache.
Fixes: f0ecd36ef8
st/mesa: add an entirely separate codepath for setting up buffer views
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13230>
Doing this copy using SDMA frees up the dGPU to do more
interesting things while the copy is happening; for instance
the rendering of the next frame.
hw queue activity before:
------------------------
dGPU:
gfx: [renderframe 1][copy->iGPU][renderframe 2][copy->iGPU]...
iGPU:
gfx: [Xorg] [Xorg]
hw queue activity before after:
------------------------------
dGPU:
gfx: [renderframe 1][renderframe 2][renderframe 3]....
sdma: [copy->iGPU] [copy->iGPU] [copy->iGPU]
iGPU:
gfx: [Xorg] [Xorg] ...
If SDMA isn't available or can't do the copy, use an async compute
context instead.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12763>
SDMA support was dropped in 1f31a21664 mainly because the
advantages of delegating some copy/clear operations to the
SDMA hw came with large drawbacks: CPU overhead due to the
sdma/gfx synchronization and hangs.
This commit restores SDMA support for all gfx7+ chips but
only for the image copy operations.
SDMA operations won't be intertwined with gfx operations
like before. Instead, a SDMA IB will contain a single copy
at a time and the synchronization will be handled by the
winsys (based on the used buffers).
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12763>
The old REVIEWERS file was useful back in the mailing lists days, but
nowadays we use GitLab, and we tag people by using their usernames, not
email addresses.
Most of us know each other's usernames by now, but documentation like
this is not meant for us but for everyone else, so that they can talk to
us.
Let's convert the file into GitLab's CODEOWNERS format, which maps files
in the repository to GitLab users that people can look up or tag in
their issues or merge requests.
See also: https://docs.gitlab.com/ce/user/project/code_owners.html
Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2178>
v2: Use u_foreach_bit64() (Samuel)
v3: Add missing handling of VkMemoryBarrier2KHR in pNext of
VkSubpassDependency2KHR (Samuel)
v4: Remove unused ANV_PIPELINE_STAGE_PIPELINED_BITS (Ivan)
v5: fix missing anv_measure_submit() (Jason)
constify anv_pipeline_stage_pipelined_bits (Jason)
v6: Split flushes & invalidation emissions on
vkCmdSetEvent2KHR()/vkCmdWaitEvents2KHR() (Jason)
v7: Only apply flushes once on events (Jason)
v8: Drop split flushes for this patch
v9: Add comment about ignore some fields of VkMemoryBarrier2 in
VkSubpassDependency2KHR (Jason)
Drop spurious PIPE_CONTROL change s/,/;/ (Jason)
v10: Fix build issue on Android (Lionel)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9045>
One of the unfortunate effect of Vulkan starting to use 64bit bitmasks
is that they can no longer be defined using enums because C doesn't
guarantees that enum values will be 64bits.
Vulkan therefore started using those patterns :
static const VkAccessFlags2KHR VK_ACCESS_2_INDIRECT_COMMAND_READ_BIT_KHR = 0x00000001;
This has the effect that we can not longer use those values in
switch/case statements.
This change introduces defines so that we can keep doing this. For now
only VkAccessFlags2KHR/VkPipelineStageFlags2KHR are allowed to be
redefined this way, this list could be changed later (or all bitmask
could be processed this way).
v2: Generate hexadecimal numbers (Jason)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9045>
When enabling a new feature we made the mistake of initializing some fields
of the device object conditionally, which leads to crashes later. Initializing
those fields would be a trivial fix, but it's probably better to just zero
everything at allocation time and prevent any future screwups. Device objects
are allocated rarely enough for this additional memset to not matter for
performance.
Signed-off-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13221>
Bit 27 is the "ASTC Format" bit in the PRMs but we just extended the
Surface Format field by one bit and made sure all the ASTC formats have
that bit set. Since Gfx12.5 doesn't support ASTC, we can drop that bit
from the field and this will cause GenXML packing functions to assert if
it's ever set.
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13206>
This commit fixes two issues:
* On CreateInstance, we are freeing the instance, and then trying to
use it when calling vk_error. This could be problematic, so let's
just use NULL.
* On CreateDevice, we are getting a unsupported feature error, and
then trying to call vk_error using the instance. That's is not
really a instance error, and will assert when the ongoing common
vk_error lands mesa. Let's use NULL instead, as the object it
applies, the device, was not created.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13219>
virgl makes one array of UBOs starting from the first non-CB0 UBO used,
and does dynamic indexing off of that. It requires that the dynamic
indexing be CONST[ADDR[0]+base], rather than having the base be loaded in
addr0.
If we had a nir_intrinsic_base() on load_ubo, this would be easy. As we
don't, emit a subtract at address deref time.
Acked-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12800>
Recent ncnn benchmarks showed a slowdown, and this change seemed
more likely.
The batching into threads for the main workloads is fine, however
the remainder stuff doesn't get spread out and can bottleneck in
one thread.
Switch to a model where the initial work is batched, but the
remainder is iterated over one by one.
Brings ncnn benchmarks back in line with previously.
Fixes: 69109e0b19 ("llvmpipe/cs: rework thread pool for avoid mtx locking")
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13210>
No shader-db changes on any Intel platform.
Fossil-db results:
All Intel platforms had similar results. (Ice Lake shown)
Instructions in all programs: 144380118 -> 143692823 (-0.5%)
SENDs in all programs: 6920822 -> 6920822 (+0.0%)
Loops in all programs: 38299 -> 38299 (+0.0%)
Cycles in all programs: 8434782176 -> 8423078994 (-0.1%)
Spills in all programs: 206830 -> 204469 (-1.1%)
Fills in all programs: 318737 -> 313660 (-1.6%)
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12320>
No shader-db or fossil-db changes on any Intel platform.
v2: Keep the flt <-> fge switcharoo local to the SpvOpFUnordLessThan,
etc. handling. Add a comment explaining why the suboptimal
SpvOpFUnordEqual implementation is used here. Suggested by Caio.
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12320>
Add derivative opcodes fddx_must_abs_mali/fddy_must_abs_mali satisfying:
fabs(fdd*_must_abs_mali(v)) = fabs(fdd*(v))
The sign of their result is undefined.
On Bifrost and Valhall, these unsigned derivatives can be implemented
more efficiently than the correctly-signed counterparts, since the sign
fixup requires extra ALU instructions. On backends where this is the
case, it is useful to optimize fabs(fdd*(v)) to
fabs(fdd*_must_abs_mali(v)). This pattern comes up with the GLSL builtin
`fwidth`.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12332>
DCC_IND_BLK is not hooked up for this to work in the kernel in any released version, and it's unsafe to do so even if it was because it doesn't check the modifiers.
There's no reason to change the legacy non-modifier path to be more performant at the expense of breaking backwards compatibility with older versions of Mesa.
Fixes: 0f6251b3 ("ac/surface: use DCC compatible with image stores for < 4K resolutions")
Closes: #5422
Signed-off-by: Joshua Ashton <joshua@froggi.es>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Acked-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13122>
KHR-GL32.packed_pixels.pbo_rectangle.r16i on zink on lavapipe
ends up using a pbo that does an SINT image write. This was producing
truncated rather than clamped values.
Fix the calculations for 8/16-bit signed ints to clamp not truncate.
Fixes: 13e5f331db ("gallivm/nir: fix image store conversions")
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13187>
Fixes leaks (release) or assertion failures (debug) on allocating small
scanout resources, when falling through to the non-scanout-specific layout
code, which became more common as of ad50b47a14 ("gbm: assume
USE_SCANOUT in create_with_modifiers").
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13202>
We already set HALF_INTEGER, which is what the compiler actually does.
If we also set PIPE_CAP_TGSI_FS_COORD_PIXEL_CENTER_INTEGER, we get
incorrect lowering. Only set the CAP we respect.
On Bifrost, this convention is arbitrary. We should consider moving the
Bifrost lowering into NIR to optimize this better...
Fixes Piglit glsl-arb-fragment-coord-conventions.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13070>
The number of varying records we need to reserve in the worst case is
greater than the number of source-level varyings we advertise
(gl_Position, gl_PointSize...)
We advertise MAX_VARYINGS source level varyings, which means anywhere we
manipulate varyings we need up to (MAX_VARYINGS + max non-source level
varyings) records. Add a PAN_MAX_VARYINGS define for this and use it
throughout.
Fixes a buffer overflow in Piglit glsl-max-varyings, which now passes
instead of crashes.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13070>
The number of special varyings on midgard can influence how much space
we need to allocate for varyings in the compiler ABI. Move the enum so
we can get access it.
No functional change. This is cc stable purely so the following patches
can be backported.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13070>
Intermediate step to make sure things stay the same as I transition us to
sharing the format table.
The YUV special casing is pretty not the prettiest, but I'm hoping to
continue working on planar RGB formats as pipe formats separately.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13046>
We won't actually use the native format here, as when sampling our image
we we just see the format for either the D or S aspect. This syncs us up
with freedreno's table, though.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13046>
The differences between the two are:
- tex supports more formats (fine, we've already decided on which formats
we can blit)
- FMT6_10_10_10_2_UNORM instead of FMT6_10_10_10_2_UNORM_DEST.
- FMT6_A8_UNORM for PIPE_FORMAT_A8_UNORM.
For 1555 support we get another difference between tex and color, and we
need 2/3 of the tex differences for blit srcs, so switch it over. This
also matches what turnip does (except it doesn't have A8 as a format).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13046>
This means that EGLimage imports of YUYV and UYVY can use a single sampler
instead of having to create RGBA8 and RG8 samplers mapping the same
texture. The swizzles are the same as turnip uses, and it makes the
piglit tests for these formats happy.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13046>
Noticed because the vertex formats didn't match up between the two. GL
doesn't actually look for these vertex formats, though.
Having these marked as supporting texture or color could theoretically
change things I think.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13046>
Tiles on the edge may cross maximum viewport size, we have to clamp
per-tile scissor to maximum allowed viewport dimensions.
Add MAX_VIEWPORT_SIZE constant along the way.
Fixes vkd3d test "test_draw_uav_only"
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13197>
The core ones have some nifty stuff like asserts that it's a valid
vk_object_base and has the right type. We don't have real type safety
with Vulkan handles but this is as close as we can get. The core ones
also track when we've started handing out handles for logging purposes
which we want.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13100>
Changes:
- nir_metadata_preserve(..., nir_metadata_block_index | nir_metadata_dominance)
is called only when pass makes progress
- nir_metadata_preserve(..., nir_metadata_all) is called when pass doesn't
make progress
- pass returns true ONLY when it makes progress ("progress" was initialized incorrectly)
Signed-off-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13189>
When a GPU hang occurs, the syncobj will eventually timeout,
if this is a wait, just set ready, so things will continue.
This matches 965 behaviour better.
Fixes: c282a082be ("crocus/query: poll the syncobj in the no wait situation")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13188>
The code here is well-intentioned, but the only way a GetGeometry
request can fail is if you name an invalid drawable. And if we did that,
either our internal state got corrupted, or - more likely - the user
destroyed the window. In either case there's nothing more we can do with
the surface, so report that it's been lost.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13104>
at this point it's guaranteed that the cmdbuf has completed since the
timeline id has passed, but vulkan hasn't technically "released" the fence
until it's been waited upon, so cut down on some validation spam by waiting
here like in get_batch_state()
Acked-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13144>
The MI_COPY_MEM_MEM version of resource_copy_region has known bugs:
- It's failing to set valid_buffer_range correctly
- It's missing iris_emit_buffer_barrier_for() for the
source/destination, so there may be missing flushes.
- There are some bad interactions with the tile cache and VF using L3.
Even with those fixed, if you expand the "no more than 16 bytes"
restriction to allow copies up to 1024 bytes, then it starts failing
Piglit tests on Icelake.
We could probably fix this. However, I had originally only measured a
0.689096% +/- 0.473968% (n=4) speedup in Shadow of Mordor's OpenGL
port, which is already fairly small, especially before adding missing
flushes. Further, some of that likely came from not switching between
render and compute...which we'll soon be able to avoid thanks to BLOCS.
Folks were also worried that MI_COPY_MEM_MEM can't be pipelined, and
that stalling the command streamer may actually slow things down,
especially as the GPUs become more powerful. We aren't really sure
about this, but it's another concern.
So, let's just get rid of this optimization. It seemed like a good
idea at the time, but it's just causing issues for very little gain.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12863>
Now they run automatically in parallel with other unit testing, rather
than needing a separate script and environment to run them.
Instead of doing shell script filtering afterwards, I just added a little
flag to suppress printing the path name. Also dropped the "Parsing
<file>" in addition to "Reading <file>" in the tested script, since it's
redundant and baked the path name into the reference.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6360>
Now they run automatically in parallel with other unit testing, rather
than needing a separate script and environment to run them.
Instead of doing shell script filtering afterwards, I just added a little
flag to suppress printing the path name.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6360>
Types <32 bit get promoted to int32_t when you do expressions on them
(thus why (u8)x << 8 works at all), but shifting into the top bit of the
signed int is undefined behavior.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6360>
We add "Turnip" so that users (and vulkan.gpuinfo.org) can distinguish us
without requiring VK_KHR_driver_properties. This will be a lot more
user-friendly than "FD618", though.
I made some little vk_asprintf helpers, because I figure other drivers
setting up deviceName's will want them too.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13041>
v2: move checks to vk_device_init, ignore struct types from
provisional extensions + lots of cleanups/fixes (Jason Ekstrand)
v3: squash in following patch from Jason:
"vulkan: Restructure vk_physical_device_check_device_features()"
v4 (Jason): Fix a Windows build error
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12867>
It is an improved version of etna_drm_screen_create_renderonly(..)
which also needs the gpu fd. Also switch etna_drm_screen_create(..)
and etna_drm_screen_create_renderonly(..) to use the new function.
This follows how other driver's winsys code looks like and fixes a
crash I when running piglit with PIGLIT_PLATFORM="gbm".
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Tested-by: Philipp Zabel p.zabel@pengutronix.de
Reviewed-by: Simon Ser <contact@emersion.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12904>
There are exceptions in spec where the framebuffer image format and
format given for render pass attachment may differ. This happens in
particular when subpass has resolve attachment that might resolve
only depth from a combined depth+stencil format. There the formats do
not need to match but be 'compatible' with each other.
As example using VK_FORMAT_D32_SFLOAT format is considered compatible
when actual framebuffer format is VK_FORMAT_D32_SFLOAT_S8_UINT.
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13082>
The previous code checked for element containment first and then performed
another map lookup upon element access. Instead, map::find can be used to
retrieve an iterator usable for element access with no extra lookup needed.
Furthermore, pure containment checks have been simplified using map::count.
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11925>
The function local_next_uses allocated one next-use map per instruction in
the current block. Since the function is called once per block, this caused
an excessive amount of memory allocations to take place.
With this change, the memory for next-use maps is allocated only once and
then reused for later blocks.
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11925>
By default, std::stack uses std::deque to allocate its elements, which has
poor cache efficiency. std::vector makes appending elements more expensive
(due to potential reallocations), but in the changed contexts the element
count should always be low anyway.
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11925>
Now that ACO is considered feature-complete, it can be nice to avoid the
huge LLVM dependency when one only wants a Vulkan driver.
This patch allows radv to be built without LLVM. The two features which
get disabled are RADV_DEBUG=llvm and shader disassembly. The latter
is an issue for debugging, so I added a warning that this configuration
is unsupported.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11319>
ACO relies on LLVM to disassemble AMD shaders for ISAs newer than GFX7,
so disassembly needs to be skipped when LLVM is not enabled.
For vkGetPipelineExecutableInternalRepresentationsKHR and vkGetShaderInfoAMD,
the disassembly will not be reported anymore if it can't be generated.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11319>
These tests have been flaky on vega10/renoir. We don't have time to look
into it just yet, so let's just mark them as such for now!
I am also including raven, as it likely has the same issue!
v2: add dEQP-VK.api.object_management.multithreaded_per_thread_resources.image_2d
v3:
- don't skip the test, mark them as flakes (Emma Anholt)
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Signed-off-by: Martin Roukala (néé Peres) <martin.roukala@mupuf.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13118>
With all the preparation in place to handle suballocated BOs at
submission and export, we can now wire up the actual suballocator.
We use Gallium's pb_slab infrastructure for this, which is already
used for this purpose in the amdgpu winsys and now zink as well.
Unlike those drivers, we don't use pb_buffer (it doesn't do much) nor
pb_cache (we already have a buffer cache). Just pb_slab for now.
We can now suballocate BOs at power-of-two (or 3/4 power-of-two)
granularity, between 256B and 2MB. Beyond that, we use actual GEM
objects as before. This should save us some memory on current GPUs
where we previously had a minimum allocation granularity of 4K (page
size), but should save us a /ton/ of memory on future GPUs where the
minimum page size is 64K. Fewer actual GEM objects should also mean
shorter exec_object2 lists passed to the kernel, which could reduce
CPU overhead a bit. Using large allocations where the underlying
GEM objects correspond with the PTE fragment size may also allow the
kernel to use a more efficient page table layout, improving memory
access times.
This cuts nearly half of the memory usage in a Unity3D demo on a
GPU that uses 64K pages.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4722
Acked-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12623>
We don't want to export suballocated resources to external consumers,
for a variety of reasons. First of all, it would be exporting random
other pieces of memory which we may not want those external consumers
to have access to. Secondly, external clients wouldn't be aware of
what buffers are packed together and busy-tracking implications there.
Nor should they be. And those are just the obvious reasons.
When we allocate a resource with the PIPE_BIND_SHARED flag, indicating
that it's going to be used externally, we avoid suballocation.
However, there are times when the client may suddenly decide to export
a texture or buffer, without any prior warning. Since we had no idea
this buffer would be exported, we suballocated it. Unfortunately, this
means we need to transition it to a dedicated allocation on the fly, by
allocating a new buffer and copying the contents over.
Making things worse, this often happens in DRI hooks that don't have an
associated context (which we need to say, run BLORP commands). We have
to create an temporary context for this purpose, perform our blit, then
destroy it. The radeonsi driver uses a permanent auxiliary context
stored in the screen for this purpose, but we can't do that because it
causes circular reference counting. radeonsi doesn't do the reference
counting that we do, but also doesn't use u_transfer_helper, so they
get lucky in avoiding stale resource->screen pointers. Other drivers
don't create an auxiliary context, so they avoid this problem for now.
For auxiliary data, rather than copying it over bit-for-bit, we simply
copy over the underlying data using iris_copy_region (GPU memcpy), and
take whatever the resulting aux state is from that operation. Assuming
the copy operation compresses, the result will be compressed.
v2: Stop using a screen->aux_context and just invent one on the fly to
avoid circular reference counting issues.
Acked-by: Paulo Zanoni <paulo.r.zanoni@intel.com> [v1]
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12623>
This code assumed that batch->exec_bos[i] matched validation_list[i],
which won't be true once we start suballocating BOs. This patch changes
it to print the full exec_bos[i] list instead of the validation list,
as that has the logical list of objects, names, addresses, placement,
whether they are suballocated, and so on.
It may be useful to look at the actual validation list as well; I'm not
sure how common that is. We may want to add additional debug prints in
the future.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12623>
The vast majority of cases need no handling at all, as they simply
read bo->address or similar fields, which works in either case.
Some other cases simply need to unwrap to look at the underlying BO.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12623>
With suballocation, our batch BO list may have multiple BOs that are
suballocated from the same GEM object. We still need to track each of
those buffers for cross-batch write tracking, cache tracking, and busy
tracking. However, we only want to include underlying GEM objects in
the actual validation list building. The validation list entry should
have EXEC_OBJECT_WRITE if any of the BOs are marked as writable.
We use a temporary array to map GEM handles to validation list entries
so we can quickly see if we've already emitted one and update the
EXEC_OBJECT_WRITE flag as needed.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12623>
We would like to start performing slab allocation of resources, where
multiple resources can be backed by a single GEM object.
Originally, I had thought to move busy tracking, cache domain tracking,
and so on into resources themselves, instead of having them at the BO
level. Multiple resources would point at the same BO with an offset.
Unfortunately, this meant adjusting the batch BO pinning code to take
resources rather than BOs. That cascades into needing iris_address
for genxml packing to store resources, not BOs. Which means that places
which have use raw BOs would need to start creating resources instead.
Except some places, like aux BO handling, really don't make sense as
pipe resources and really would rather use raw BOs. So iris_address
would need to store both, which convolutes the genxml field. And,
having a BO and resource means that every place in the code needs to
handle that offset correctly. It sounds simple, but is a giant mess.
Instead, we take a different route: adjust iris_bo itself, so that BOs
are either be backed by a GEM object (as is the case today), or backed
by another underlying BO. "Real" BOs have bo->gem_handle != 0. "Slab
allocated" or "fake" or "wrapper" BOs have bo->gem_handle == 0. We move
fields into a union based on these cases. amdgpu takes this approach.
This sounds complex at first glance---in theory, every place that
interacts with BOs might need to handle the wrapper BO special case.
But in practice, they don't. For suballocated BOs, we can set the
wrapper's address field to the underlying BO's address plus any offset,
at which point it looks like any other BO. Most other properties are
easily queried; the main code that needs updating is execbuf handling
and bufmgr internals.
For now, we simply move the fields. Any code that accesses either
bo->real.* or bo->gem_handle will need updating in future patches to
actually handle the slab-allocated case.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12623>
==767499== Conditional jump or move depends on uninitialised value(s)
==767499== at 0xEB8E3ED: x11_image_finish (wsi_common_x11.c:1539)
==767499== by 0xEB8E768: x11_swapchain_destroy (wsi_common_x11.c:1640)
==767499== by 0xEB8A8FA: wsi_common_destroy_swapchain (wsi_common.c:505)
==767499== by 0xDE30BA1: anv_DestroySwapchainKHR (anv_wsi.c:242)
==767499== by 0x6817A21: copper_displaytarget_destroy (zink_copper.c:192)
==767499== by 0x6882BE6: zink_destroy_resource_object (zink_resource.c:95)
==767499== by 0x6882447: zink_resource_object_reference (zink_resource.h:198)
==767499== by 0x6882D33: zink_resource_destroy (zink_resource.c:123)
==767499== by 0x688AC97: pipe_resource_destroy (u_inlines.h:145)
==767499== by 0x688AD2E: pipe_resource_reference (u_inlines.h:162)
==767499== by 0x688BE1E: zink_destroy_surface (zink_surface.c:319)
==767499== by 0x688AE0A: zink_surface_reference (zink_surface.h:102)
==767499== by 0x688BE6D: zink_surface_destroy (zink_surface.c:328)
==767499== by 0x67F9CA2: pipe_surface_release (u_inlines.h:134)
==767499== by 0x67FB8AD: zink_context_destroy (zink_context.c:92)
==767499== by 0x5D47B65: st_destroy_context_priv (st_context.c:475)
==767499== by 0x5D49AF2: st_destroy_context (st_context.c:1193)
==767499== by 0x5D5C90F: st_context_destroy (st_manager.c:816)
==767499== by 0x5CC1FC9: dri_destroy_context (dri_context.c:248)
==767499== by 0x658DD63: driDestroyContext (dri_util.c:535)
==767499== by 0x5A30166: drisw_destroy_context (drisw_glx.c:417)
==767499== by 0x5A32484: glXDestroyContext (glxcmds.c:515)
==767499== by 0x5315AEB: glXDestroyContext (libglx.c:332)
==767499== by 0x4AA8E7D: glXDestroyContext (g_libglglxwrapper.c:384)
==767499== by 0x4D5A3F0: ??? (in /usr/lib64/libwaffle-1.so.0.6.1)
==767499== by 0x499DDD5: piglit_wfl_framework_teardown (piglit_wfl_framework.c:638)
==767499== by 0x499E4C5: piglit_winsys_framework_teardown (piglit_winsys_framework.c:238)
==767499== by 0x499F50C: destroy (piglit_x11_framework.c:212)
==767499== by 0x498C535: destroy (piglit-framework-gl.c:210)
==767499== by 0x4F48AF6: __run_exit_handlers (in /usr/lib64/libc-2.33.so)
==767499== by 0x4F48C9F: exit (in /usr/lib64/libc-2.33.so)
==767499== by 0x4AEFD71: piglit_report_result (piglit-util.c:245)
==767499== by 0x499F2CA: process_next_event (piglit_x11_framework.c:139)
==767499== by 0x499F365: enter_event_loop (piglit_x11_framework.c:153)
==767499== by 0x499DF88: run_test (piglit_winsys_framework.c:88)
==767499== by 0x498C5EF: piglit_gl_test_run (piglit-framework-gl.c:229)
==767499== by 0x4022B4: main (primitive-restart.c:45)
==767499== Uninitialised value was created by a heap allocation
==767499== at 0x484086F: malloc (vg_replace_malloc.c:380)
==767499== by 0xE964E85: vk_default_alloc (vk_alloc.c:26)
==767499== by 0xEB8B24B: vk_alloc (vk_alloc.h:43)
==767499== by 0xEB8EAF9: x11_surface_create_swapchain (wsi_common_x11.c:1723)
==767499== by 0xEB8A82A: wsi_common_create_swapchain (wsi_common.c:476)
==767499== by 0xDE30B47: anv_CreateSwapchainKHR (anv_wsi.c:225)
==767499== by 0xE96134F: vk_tramp_CreateSwapchainKHR (vk_dispatch_table.c:6592)
==767499== by 0xD7B88F0: ??? (in /usr/lib64/libvulkan.so.1.2.162)
==767499== by 0x6817796: copper_CreateSwapchain (zink_copper.c:123)
==767499== by 0x6817960: copper_displaytarget_create (zink_copper.c:170)
==767499== by 0x6884C65: resource_create (zink_resource.c:780)
==767499== by 0x6884EC5: zink_resource_create_drawable (zink_resource.c:829)
==767499== by 0x5CC0FE3: copper_allocate_textures (copper.c:199)
==767499== by 0x5CC28C2: dri_st_framebuffer_validate (dri_drawable.c:82)
==767499== by 0x5D5B69A: st_framebuffer_validate (st_manager.c:222)
==767499== by 0x5D5D32D: st_api_make_current (st_manager.c:1102)
==767499== by 0x5CC220B: dri_make_current (dri_context.c:306)
==767499== by 0x658DE23: driBindContext (dri_util.c:588)
==767499== by 0x5A3022A: drisw_bind_context (drisw_glx.c:435)
==767499== by 0x5A36CC2: MakeContextCurrent (glxcurrent.c:220)
==767499== by 0x5A36DF9: glXMakeCurrent (glxcurrent.c:253)
==767499== by 0x531849C: InternalMakeCurrentVendor (libglx.c:875)
==767499== by 0x53185C3: InternalMakeCurrentDispatch (libglx.c:930)
==767499== by 0x5318DE5: CommonMakeCurrent (libglx.c:1074)
==767499== by 0x5318ED5: glXMakeCurrent (libglx.c:1119)
==767499== by 0x4AA9CFA: glXMakeCurrent (g_libglglxwrapper.c:930)
==767499== by 0x4D5AA36: ??? (in /usr/lib64/libwaffle-1.so.0.6.1)
==767499== by 0x4D5E16E: waffle_make_current (in /usr/lib64/libwaffle-1.so.0.6.1)
==767499== by 0x499C8CD: wfl_checked_make_current (piglit-util-waffle.h:115)
==767499== by 0x499DA04: make_context_current_singlepass (piglit_wfl_framework.c:488)
==767499== by 0x499DC43: make_context_current (piglit_wfl_framework.c:565)
==767499== by 0x499DD88: piglit_wfl_framework_init (piglit_wfl_framework.c:628)
==767499== by 0x499E3FC: piglit_winsys_framework_init (piglit_winsys_framework.c:209)
==767499== by 0x499F581: piglit_x11_framework_create (piglit_x11_framework.c:229)
==767499== by 0x499E361: piglit_winsys_framework_factory (piglit_winsys_framework.c:175)
==767499== by 0x498CA60: piglit_gl_framework_factory (piglit_gl_framework.c:53)
==767499== by 0x498C587: piglit_gl_test_run (piglit-framework-gl.c:221)
==767499== by 0x4022B4: main (primitive-restart.c:45)
Fixes: b5c390c113 ("vulkan/wsi: add support for detecting mit-shm pixmaps.")
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13124>
If we're going to have to bind them as separate planes with colorspace
conversion for sampling on the frontend, then we need to report that
they're only for external-image samplers, otherwise the lowering won't be
applied.
Fixes: 4e3a7dcf ("gallium: enable EGL_EXT_image_dma_buf_import_modifiers unconditionally")
Reviewed-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13038>
This morning saw at least 3 pipelines fail from a530 not responding and
not coming back after we tried to power cycle, and airlied was having some
similar trouble yesterday. Until I can figure out what's going wrong
(python script failing to set up serial after retry? relays worn out?
Power supply failing?), just disable the boards.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13123>
Reworks:
* Use BLORP_BATCH_USE_COMPUTE flag rather than compute param to
blorp_copy (s-b Jason)
* Squash "intel/blorp: Set shader_pipeline for compute"
* Squash "intel/blorp: Add blorp_copy_supports_compute function"
* Squash "intel: Support compute for image/buffer copy if INTEL_DEBUG=blocs
is set"
* Squash "intel/blorp: Support compute for some blit operations"
* Use nir_image_store (s-b Jason)
* Use nir_push_if (s-b Jason)
* Require gfx12 for ccs in blorp_copy_supports_compute (s-b Jason)
* Add nir_pop_if (s-b Ken)
* Fix aux_usage check on gfx12 blorp_copy_supports_compute (s-b Ken)
* Use blorp_set_cs_dims (s-b Jason)
* Use dim=2d with array=true for nir_image_store (s-b Jason, Francisco)
* Restructure gen checks in blorp_copy_supports_compute (s-b Ken)
* Use nir_load_global_invocation_id (s-b Jason)
* Fix inefficient calculation of store_pos (s-b Jason)
* Use bounds_if being NULL/non-NULL for nir_pop_if (s-b Jason)
* discard => bounds (s-b Ken)
* Re-add ISL_AUX_USAGE_CCS_E in *_supports_compute (s-b Sagar)
* Skip duplicated in_bounds calculation (s-b Jason)
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11564>
Reworks:
* Don't pack params, just memcpy param struct (s-b Jason)
* Old subject: "intel/blorp: Emit compute program if
params.cs_prog_data is set"
* Various cleanups of push-const size/alignment (s-b Jason)
* Fix subslice count by moving to devinfo (s-b Ken)
* Simplify cw.InterfaceDescriptor code (s-b Ken)
* Drop some comments from i965 (s-b Ken)
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11564>
This change allows creating contexts of depending on set of
context parameters. The meaning of each of the parameters
is listed below:
1) VIRTGPU_CONTEXT_PARAM_CAPSET_ID
This determines the type of a context based on the capability set
ID. For example, the current capsets:
VIRTIO_GPU_CAPSET_VIRGL
VIRTIO_GPU_CAPSET_VIRGL2
define a Gallium, TGSI based "virgl" context. We only need 1 capset
ID per context type, though virgl has two due a bug that has since
been fixed.
The use case is the "gfxstream" rendering library and "venus"
renderer.
gfxstream doesn't do Gallium/TGSI translation and mostly relies on
auto-generated API streaming. Certain users prefer gfxstream over
virgl for GLES on GLES emulation. {gfxstream vk}/{venus} are also
required for Vulkan emulation.
The goal is for guest userspace to choose the optimal context type
depending on the situation/hardware.
2) VIRTGPU_CONTEXT_PARAM_NUM_RINGS
This tells the number of independent command rings that the context
will use. This value may be zero and is inferred to be zero if
VIRTGPU_CONTEXT_PARAM_NUM_RINGS is not passed in. This is backwards
compatibility for virgl, which has one big giant command ring for all
commands.
The maxiumum number of rings is 32. In practice, multi-queue or
multi-ring submission is used for powerful dGPUs and virtio-gpu
may not be the best option in that case (see PCI passthrough or
rendernode forwarding).
3) VIRTGPU_CONTEXT_PARAM_POLL_RING_IDX_MASK
This is a mask of ring indices for which the DRM fd is pollable.
For example, if VIRTGPU_CONTEXT_PARAM_NUM_RINGS is 2, then the mask
may be:
[ring idx] | [1 << ring_idx] | final mask
-------------------------------------------
0 1 1
1 2 3
The "Sommelier" guest Wayland proxy uses this to poll for events
from the host compositor.
Reviewed-by: Anthoine Bourgeois <anthoine.bourgeois@gmail.com>
Tested-by: Anthoine Bourgeois <anthoine.bourgeois@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7712>
The gallium driver makes use of blend shaders, but panvk takes a
slightly different approach. Vulkan drivers are passed the blend
operation at pipeline creation time, which means they know it when
compiling the fragment shader and can lower the blend operation
directly in the fragment shader itself. Doing that simplifies the
pipeline creation since we don't have to deal with blend shaders
anymore.
This might come at a cost for translation layers like Zink though,
since it requires re-compiling the fragment shader every time the
blend operation changes, which we do anyway, since we don't have
a pipeline cache yet. Let's keep things simple for now and revise
things if/when we end up having performance issues.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Suggested-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13060>
This is basically the same workaround as in 9b577f2a88 (driconf, glsl: Add a
vs_position_always_invariant option) commit but for tesselation evaluation
shaders. Some applications do not mark outputs as precise in tesselation
evaluation shaders which can lead to different results in case some
optimizations were applied.
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Signed-off-by: Vadym Shovkoplias <vadym.shovkoplias@globallogic.com>
Fixes: 09705747d7 ("nir/algebraic: Reassociate fadd into fmul in DPH-like pattern")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13027>
The logic behind this change is intuitive: if we are waiting for
something, we should probably flush all pending rendering so that it
starts executing in the meantime. This prevents the GPU from sitting
idle for long periods of time while we are also blocked in the app.
With the gun3d trace:
Before: 79 fps After: 215 fps
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13096>
Currently, if we ever fail to create a re-interpreted uncompressed view
of the resource, we fall back to a SW path. On some Intel hardware,
this happens whenever LOD > 0. Instead, we should fall back to
attempting to upload one slice at a time and only fall back to SW as a
last resort.
v2 [by Ken]: Fix buf_offset calculation and loop over layers.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com> [v1]
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11737>
This fixes SPECVIEWPERF13 creo test case hang:
1. Client: send present pixmap request (serial=1) when swap_interval==1
and increase send_sbc=1
2. Server: pend the request before vblank arrives
3. Client: set swap_interval=0 (so set XCB_PRESENT_OPTION_ASYNC),
send another present pixmap request (serial=2), increase send_sbc=2
4. Server: handle the async request immediately and send complete event
(serial=2)
5. Client: handle the event and set recv_sbc=event->serial=2
6. Server: vblank arrives so handle pending request and send complete
event (serial=1)
7. Client: handle the event and set recv_sbc=event->serial=1
8. Client: someone call loader_dri3_swapbuffer_barrier() and waiting
on recv_sbc==send_sbc, but no one will set recv_sbc=2 again
So basically it's caused by swap happens out of order. This commit
fixes the problem by waiting on the pending sync swaps all done when
switching to async mode, so move 6&7 before 3.
Attach the xtrace when problem happens:
005:<:003e: 72: Present-Request(148,1): Pixmap window=0x03000002 pixmap=0x0300000b serial=1 valid=0x00000000 update=0x00000000 x_off=0 y_off=0 target_crtc=0x00000000 wait_fence=0x00000000 idle_fence=0x0300000c options=0 target_msc=4294967296 divisor=0 remainder=0 notifies=;
...
005:<:0041: 72: Present-Request(148,1): Pixmap window=0x03000002 pixmap=0x03000011 serial=2 valid=0x00000000 update=0x00000000 x_off=0 y_off=0 target_crtc=0x00000000 wait_fence=0x00000000 idle_fence=0x03000012 options=Async target_msc=0 divisor=0 remainder=0 notifies=;
005:>:0041: Event Generic(35) Present(148) IdleNotify(2) event=0x03000006 window=0x03000002 serial=2 pixmap=0x03000011 idle_fence=0x03000012
005:>:0041: Event Generic(35) Present(148) CompleteNotify(1) kind=Pixmap(0x00) mode=Copy(0x00) event=0x03000006 window=0x03000002 serial=2 ust=7505462213117739011 msc=3565046193979392
005:>:0041: Event Generic(35) Present(148) IdleNotify(2) event=0x03000006 window=0x03000002 serial=1 pixmap=0x0300000b idle_fence=0x0300000c
005:>:0041: Event Generic(35) Present(148) CompleteNotify(1) kind=Pixmap(0x00) mode=Copy(0x00) event=0x03000006 window=0x03000002 serial=1 ust=7505533793042694147 msc=3565050488946688
Cc: mesa-stable
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13019>
The core ones have some nifty stuff like asserts that it's a valid
vk_object_base and has the right type. We don't have real type safety
with Vulkan handles but this is as close as we can get. The core ones
also track when we've started handing out handles for logging purposes
which we want.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13101>
The vk_shader_module_handle_from_nir() macro was constructing a
temporary vk_shader_module and passing it through
vk_shader_module_to_handle(). Since this is a function and not a macro,
it means that the lifetime of the temporary vk_shader_module will end
once the to_handle() function is called. Technically, this is a
use-after-free. I really don't know why no one has been bitten by this
yet....
Fixes: a41e98ddca "vk/util: add a util macro for initializing stack..."
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13101>
bitset encoding tends to have a lot of duplication, for ex. many
instructions with the same encoding modulo the fixed pattern. Now that
encode_bitset is split out into it's own template, so that we can
capture the result, use a hash table to de-duplicate the bitset encoding
into "snippet" functions so that bitset cases with identical encoding
can re-use the same generated code.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13049>
Found this nugget while looking at the ACO driver. It seems sensible to
avoid SLM fences if there is no SLM. This also makes the check depend
on SLM usage rather than just shader stage which will be useful if we
ever implement task/mesh because task shaders also have SLM.
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13092>
Start off making everything look like LSC where we have three types of
fences: TGM, UGM, and SLM. Then, emit the actual code in a generation-
aware way. There are three HW generation cases we care about:
XeHP+ (LSC), ICL-TGL, and IVB-SKL. Even though it looks like there's a
lot to deduplicate, it only increases the number of ubld.emit() calls
from 5 to 7 and entirely gets rid of the SFID juggling and other
weirdness we've introduced along the way to make those cases "general".
While we're here, also clean up the code for stalling after fences and
clearly document every case where we insert a stall.
There are only three known functional changes from this commit:
1. We now avoid the render cache fence on IVB if we don't need image
barriers.
2. On ICL+, we no longer unconditionally stall on barriers. We still
stall if we have more than one to help tie them together but
independent barriers are independent. Barrier instructions will
still operate in write-commit mode and still be scheduling barriers
but won't necessarily stall.
3. We now assert-fail for URB fences on LSC platforms. We'll be adding
in the new URB fence message for those platforms in a follow-on
commit.
It is a big enough refactor, however, that other minor changes may be
present.
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13092>
GL_ALPHA, GL_LUMINANCE and GL_LUMINANCE_ALPHA
texture formats are supported in:
1. GL Compatibility spec
2. GLES 1.0 - GLES 3.2 spec
However, these formats are not supported in:
1. GL Core spec
This patch changes a logic of validation
texture formats in calls like glTexImage2D.
If the context is CORE and these formats were
selected, then return "-1" and in upper layer
return GL_INVALID_ENUM.
If the context is not CORE, return appropriate
format.
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13059>
For DRI_PRIME setup where the dGPU -> iGPU copy can happen asynchronously,
we need to ensure that we're not continuously reusing the same back buffer.
The existing code relies on XCB_PRESENT_EVENT_IDLE_NOTIFY to decide if
a buffer is busy or idle. If this event is received before the hardware
is done using the buffer, then it will reuse the same buffer and introduce
a dependency between the copy and the next frame.
This commit mitigates this by trying to allocate a different back buffer
when called from dri3_get_buffer (not from dri3_find_back_alloc, because it
seems that it expects dri3_get_buffer - see 0cc4c7e33e).
An alternative would be to query the busy-ness using is_resource_busy
but this complicates the code to achieve the same result.
One affected app is Unigine Superposition, and this change improves the
score by 0% - 5% depending on the settings.
This behavior is enabled if PIPE_CAP_PREFER_BACK_BUFFER_REUSE is 0.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12788>
When it comes to AHB, pExternalBufferInfo->handleType is already
overridden to the renderer handle type. Thus the AHB buffer prop path is
not used. However, this is not caught by cts, vvl or apps because the
host renderer memory features so far satisfy the ahb requirement.
Fixes: ebf0e45506 ("venus: add ahb image and buffer properties query support")
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13076>
Some input varyings might not be written by any of the active stages
preceding the stage reading the varying (e.g. gl_Layer should be set
to 0 when not written by vertex/geometry shaders). In this case, we can
insert a dummy varying attribute returning zero. This is actually what
the code intended to do, but 2 things were missing:
1. formats[NONE] is not mapping to the CONSTANT0 format
2. the offset and strides should always be set to 0 when using a
CONSTANT0 attribute
All of this is needed to have the input attachments working. Indeed, we
use the nir_lower_input_attachments() pass which lowers input attachment
loads to texel fetches, and the txf operation is passed the layer_id
in its 3rd coordinate.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13077>
If we queue multiple draws to the same batch, the TLS size should be
adjusted to cover the maximum TLS size requirement, not just the one
of the pipeline bound when the batch is closed. This requires keeping
TLS info attached to the batch and updating it every time a draw is
issued.
While at it, get rid of the wg_count state: we'll let vkCmdDispatch()
calculate the total WLS size.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13077>
llvmpipe expects valid size parameter, and when just VK_WHOLE_SIZE is
passed very bad things can happen.
This was handled specially before, but got dropped when lavapipe was
converted to use the generated command queue.
Fixes: eb7eccc76f ("lavapipe: Use generated command queue code")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13036>
The LLVM-SPIRV translator creates variables with initializers, but
most of those are actually undef initializers. We can just skip
composites that are entirely made of undefs, but for partially undefs,
we will still zero initialize.
v2: Rename wa_llvm_spirv_undef_initializer to wa_llvm_spirv_ignore_workgroup_initializer (Caio)
Limit workaround to OpenCL (Caio)
Make workaround clearer (Caio)
v3: Only apply workaround on workgroup storage (Caio)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13030>
We were assertion failing on some large draws due to indices >16bits,
despite asking draw to limit the max indices. I haven't managed to track
it down, so flip us back to the older, non-index drawing path that doesn't
hit this bug until it can get fixed. Leave an I915_DEBUG=vbuf flag around
so we can look into this later.
This is a pretty big performance hit for vertex shaders. Using glmark2 -b
build:use-vbo=true:
i915g-vbuf: 211 fps
i915g-nonvbuf: 185 fps
i915c: 41 fps
Given how massively better i915g still is than i915c (llvmpipe VS instead
of the classic swrast interpreter), I think it's still worth it to get
i915g correct before we fix this perf regression.
Fixes: #4971
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13052>
The common code fails dEQP-VK.wsi.display_control.register_device_event
due to having a stub NOT_IMPLEMENTED return, and thus fails the CTS. This
is one of our last failures, so disable the extension until it can get
finished off, so we can unblock passing the CTS.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13010>
This patch allows to form clauses even if the register pressure
is at the limit with the effect that VMEM instructions are less
scattered after the first clause in a Block.
It respects the previous clause size to avoid excessive moving
of VMEM instructions.
VMEM_CLAUSE_MAX_GRAB_DIST is further reduced to compensate
some of the effects.
Totals from 28922 (19.26% of 150170) affected shaders: (GFX10.3)
VGPRs: 1546568 -> 1523072 (-1.52%); split: -1.52%, +0.00%
CodeSize: 117524892 -> 117510288 (-0.01%); split: -0.08%, +0.07%
MaxWaves: 605554 -> 611120 (+0.92%)
Instrs: 22292568 -> 22291927 (-0.00%); split: -0.10%, +0.09%
Latency: 488975399 -> 490230904 (+0.26%); split: -0.06%, +0.32%
InvThroughput: 117842300 -> 116521653 (-1.12%); split: -1.15%, +0.03%
VClause: 541550 -> 522464 (-3.52%); split: -9.73%, +6.20%
SClause: 718185 -> 718298 (+0.02%); split: -0.00%, +0.02%
Copies: 1420603 -> 1386949 (-2.37%); split: -2.64%, +0.27%
Branches: 559559 -> 559278 (-0.05%); split: -0.06%, +0.01%
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10896>
Fixes several problems in the pan_blit() logic:
1. We actually need the reciprocal of the depth scaling in z_scale (maybe
we should rename this field z_scale_rcp to make it clear)
2. When Z end < Z start we should remove one to the cur_layer/layer_offset
instead of doing it on the last_layer field, otherwise there's an
off-by-one error
3. The Z src offset should be adjusted to account for scaling. If we don't
do that we won't sample from the right layer when upscaling.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12961>
Bit 12 of render->aux1 is GL_CCW/GL_CW. For GL_CCW (default of glFrontFace) we have
to set that bit active.
This is not what the blob does and what the original reverse engineering documentation
says. The blob sets this value inverted and does some bogus negation of the fragment
shaders gl_FrontFacing variable instead.
Anyway, doing it this way does not cause regressions but fixes
dEQP-GLES2.functional.shaders.builtin_variable.frontfacing and 4 piglit tests.
Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com>
Signed-off-by: Andreas Baierl <ichgeh@imkreisrum.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7690>
Again if you get passed an invoc but the exec mask has the
active lane somewhere other than at 0, then if we have an
invoc we should find the active lane and extract the value
from invoc rather than using the idx.
This fixes a bunch of VK 1.2 subgroup tests once 1.2 is enabled:
dEQP-VK.subgroups.ballot_broadcast.compute.subgroupbroadcast_nonconst*
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Acked-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12953>
this works by tracking 1024-member arrays of images and textures using idalloc
for indexing. each idalloc id is an index into the array that is returned as a handle,
and this handle is used to index into the array in shaders.
in the driver, VK_EXT_descriptor_indexing features are used to enable updates on the live
bindless descriptor set and leave unused members of the arrays unbound, which works as
long as no member is updated while it is in use. to avoid this, idalloc ids must cycle through
a batch once the image/texture handle is destroyed before being returned to the available pool
in shaders, bindless ops come in one of two types:
- i/o variables
- bindless instructions
for i/o, the image/texture variables have to be rewritten back to the integer
handles which represent them so that the successive shader stage utilizing them
can perform the indexing
for instructions, the src representing the image/texture has to be rewritten as a deref
into the bindless image/texture array
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12855>
this requires allocating and using a lazily-allocated msaa surface as a transient
attachment for the base render operation, resolving it
...except vulkan has no "replicate" renderpass attachment mechanism, so for now we're
just gonna allocate a transient surface and hang on to it. sorry tilers!
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12934>
tc rebind info can't distinguish between buffers bound multiple times
in a given bind point (e.g., for multiple vertex buffers), so ensure all
rebinds are processed and the global rebind isn't triggered if multiple rebinds
are processed for a given buffer
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12934>
With NGG culling, the shaders are split into two parts:
the top part that computes just the position output,
and the bottom part which produces the other outputs.
To reduce redundancy between the two, I added some code
to reuse uniform variables between them. However, there is
an edge case I didn't think about: because of vertex repacking,
it is possible for the bottom part to process a different vertex.
Therefore it can take a different divergent code path
(though it must still take the same uniform code path).
Due to this, when a uniform value comes from divergent control
flow, this may be undefined in the bottom part.
This commit stops reusing uniform variables from
divergent control flow, to fix issues that arise from this.
Fossil DB stats on Sienna Cichlid with NGGC on:
Totals from 1723 (1.34% of 128647) affected shaders:
VGPRs: 89312 -> 89184 (-0.14%); split: -0.15%, +0.01%
SpillSGPRs: 4575 -> 120 (-97.38%)
CodeSize: 10846424 -> 10873836 (+0.25%); split: -0.68%, +0.93%
MaxWaves: 34582 -> 34602 (+0.06%); split: +0.06%, -0.01%
Instrs: 2124471 -> 2128835 (+0.21%); split: -0.51%, +0.72%
Latency: 7274569 -> 7293899 (+0.27%); split: -0.22%, +0.48%
InvThroughput: 1637130 -> 1635490 (-0.10%); split: -0.17%, +0.07%
VClause: 25141 -> 25414 (+1.09%); split: -0.02%, +1.10%
SClause: 56367 -> 59503 (+5.56%); split: -1.36%, +6.93%
Copies: 230704 -> 219313 (-4.94%); split: -5.49%, +0.55%
Branches: 72781 -> 72681 (-0.14%); split: -0.21%, +0.07%
PreSGPRs: 118766 -> 100176 (-15.65%); split: -15.70%, +0.05%
PreVGPRs: 76876 -> 76833 (-0.06%)
Fixes: 0bb543bb60
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13001>
Oh, the irony. I linked to this file in a software design class as an
example of how unit testing works under the hood, since it's not using
any particular testing framework. In doing so I realized the test is
totally broken. It doesn't matter -- the tests passed before, pass now,
and the code being tested is correct. But let's still fix the
embarassing logic error for future Panfrost hackers.
Fixes: d42e53c77a ("panfrost: Unit test clear colour packing")
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13006>
It is really small, and used just twice, so we just call qpu_magic.
We also update how it is used:
* QFILE_NULL is an undef so we can just load anything. Previously we
were using accumulator 0, but there isn't any real reason to use
an accumulator for this. Using reg 0.
* QFILE_LOAD_IMM: it seems that we don't use at all right now, so
let's add an assert
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13008>
This is boilerplate that drivers have to replicate, so make a nice helper.
The feature/property macro lists are are copy and pasted from anv, though
the helper functions has been split between 1.1 and 1.2 (and thus the macros
refactored).
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12967>
clc_object was overloaded, containing SPIR-V binary and metadata,
and it would only sometimes contain metadata (after linking). Split
it into a more generic clc_binary class which holds some type of data
(the kind depends on where it came from), and clc_metadata which can
be independently parsed on compiled or linked data.
Rename a couple entrypoints to be more explicit about what they're
actually transforming (c_to_spirv, link_spirv, spirv_to_dxil).
Add a logger to SPIR-V binary parsing so it can report errors on app-
provided SPIR-V.
Re-order helper function parameters to be more consistent (out params last).
Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10322>
Patch removes 'desktop=false' from aliased function, otherwise
glPrimitiveBoundingBox[ARB] cannot be retrieved via GetProcAddress.
This was seen with new OpenGL 4.5 tests that utilize
GL_ARB_ES3_2_compatibility and bounding box API.
v2: fixes to display list support (Ilia Mirkin)
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12846>
The bacon is long past its expiration date and has got to go.
Composting it in the flower-beds was probably inadvisable.
So we shall throw it away.
(Originally, I imported libdrm_intel into i965, but to avoid symbol
conflicts, renamed drm_intel_* to drm_bacon_* as it was the same number
of letters and we needed an arbitrary name. After slicing-and-dicing
away most of the fat, er, code, we renamed it to brw_bufmgr...except
for apparently this comment, which then got replicated to both iris
and crocus. Originally it served to indicate what file contained these
functions, but bufmgr.h having prototypes for bufmgr.c is obvious, so
just delete the silly comment. No bacon for you!)
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12985>
Yo' dawg, I heard you like bindings in your bindings.
When you have VertexAttribs with a binding, it's not an index into
the VertexBindings, you have to match it to the VertexBinding
with the same binding value.
This fixes
dEQP-VK.pipeline.extended_dynamic_state.after_pipelines.vertex_input_multiple_bindings
and some others.
Fixes: 5951d2abac ("lavapipe: implement EXT_vertex_input_dynamic_state")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12983>
The negative API tests ask to transpose a non-matrix uniform, and expect
the transpose error rather than the non-matrix error. This may be a test
bug about ambiguous results, but since every other driver is presumably
doing this too, just follow along.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Andreas Baierl <ichgeh@imkreisrum.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12924>
The populate_base_prog_key will set VARYING depending if the pipeline
flag is used. Later, when full subgroups flag is set, it will flip to
UNIFORM -- which for compute shaders is effectively the same, so don't
bother setting it again.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12946>
Use create_backed_surface_view helper function to create/reuse
alternate surface view when the to-be-bound surface view was created
in a different context. This fixes render target views leak running gazebo.
Cc: mesa-stable
Reviewed-by: Neha Bhende <bhenden@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12952>
There are at least three situations where we need to preload FBs:
1. The attachment is flagged VK_ATTACHMENT_LOAD_OP_LOAD and has not been
accessed in previous subpasses
2. The batch is implicitly split (e.g. too many jobs queued to the
batch, wait/set events queued, ...)
3. The attachment has been written by a previous subpass
With those changes, we can get rid of panvk_emit_fb() and call
pan_emit_fbd() directly (fb_info is initialized when starting a subpass
and updated when an implicit split happens).
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12095>
SVGA DRM stat calls were situated but did not actually register with the mks-stats
mechanism due to absence of corresponding ioctls. The employed new ioctls in vmwgfx
are DRM_VMW_MKSSTAT_ADD and DRM_VMW_MKSSTAT_REMOVE, subject to version check.
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
(cherry picked from commit be47c077cc927c27a8c36342b47697aa81719677)
(cherry picked from commit 0388afc67b830f6ab916d0839c33eb1d91d6353f)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12873>
If the fragment shader writes fragment depth from an ALU instruction,
the register allocator makes sure that the instruction is pointed to the
correct register and write mask (t0.__z_).
If there is no instruction emitted because the source is an input
load intrinsic, or if the source instruction does not support swizzle
and write mask, we have to add a mov instruction for this to work.
Fixes piglit test spec@glsl-1.10@execution@glsl-1.10-fragdepth.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12891>
These are I/O variables which are not going to be removed anyway.
However, get_variable_io_mask handles their location incorrectly.
Found using the GCC undefined behavior sanitizer.
Fixes the following error:
runtime error:
shift exponent 4294967258 is too large
for 64-bit type 'long unsigned int'
Closes: #5319
Fixes: cf5f8f55c3
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12719>
match_mask checks the intrinsic type and decides whether it's
per-patch or not. VS don't have per-patch outputs,
so this causes wrong behaviour there.
Found using the GCC undefined behavior sanitizer.
Fixes the following error:
runtime error:
shift exponent 18446744073709551584 is too large
for 64-bit type 'long unsigned int'
Closes: #5319
Fixes: bf966d1c1d
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12719>
The jump lowering enabled by EmitNoLoops breaks GLSL's loop unrolling on
various obviously unrollable loops, resulting in a lot of deqp-gles2 and
piglit failures. NIR will help unroll whatever GLSL doesn't, so we can
trust the driver to apply that after GLSL's unrolling, so no need to ask
GLSL to lower all loops.
Fixes: #4979
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Zoltán Böszörményi <zboszor@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12917>
Commit 0245b825 switched from returning the error code VK_ERROR_OUT_OF_DATE_KHR
to returning the success code VK_SUBOPTIMAL_KHR. Prior to that commit, the error
code caused all code paths to fail immediately, but the success code does not.
Currently the success code is not recorded in some scenarios, resulting in a
result of VK_SUCCESS instead. This breaks applications that rely on the
result (per the spec) to trigger resizes.
This commit ensures that the proper VK_SUBOPTIMAL_KHR success code is set as a
sticky status (as comments indicate was intended), ensuring that it is
propagated to user code.
Fixes#5331
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12782>
Only if the image is TC-compat HTILE because it can be decompressed
on compute for partial copies.
This should remove few depth/stencil decompressions for RAGE2 and Red
Dead Redemption 2 because they declare all images as concurrent but
never use the compute queue for them.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12452>
We lack a dependency between the vertex job filling the indirect draw
buffers and the indirect draw compute job reading from these buffers,
leading to unreliable results (the tests pass if the vertex job is
done before the compute job starts, and fail otherwise). Let's disable
those tests until we sort it out.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12589>
Sampling from SCALED textures / rendering to SCALED FBOs is a bit tricky
(requires extra int <-> float conversions in a few places).
mesa/st only use SCALED formats as vertex formats, and those formats
are optional in Vulkan, so let's drop the RENDER/TEXTURE flags to keep
things simple.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Suggested-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12508>
The byte-permute instruction v_perm_b32 is not exposed by older
LLVM releases (only available on LLVM 13 and later), therefore a new
sequence is needed which we can use with these LLVM versions too.
The prefix sum is replaced by two alternatives:
1. For GPUs that support v_dot, we shift 0x01 to the wanted byte
positions and then use v_dot to sum the results.
2. For older GPUs (Navi 10), we simply shift out the unwanted bytes
and use v_sad_u8 to produce the sum.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12786>
This arg size should be 1 instead of 3. It does not affect functionality
because we does not enable it in SPI_PS_INPUT_ADDR. But it does affect
the VGPR number that LLVM produce when LLVM still count with all PS
function arguments.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12922>
The previous code had a number of errors, the most glaring of which was
forcing linear when it was one of the possible layouts requested.
When modifiers are being used, a list of _acceptable_ modifiers is
supplied; it's up to the driver to then make a decision as to which it
thinks is most optimal.
Normally we would select between linear/tiled/UBWC in ascending order of
preference according to what's possible, however we can't use a tiled
layout with explicit modifiers as there is no modifier token defined for
it.
Rewrite the layout-selection mechanism to always try to do the most
optimal thing. If the use flags force us to, or we have a shared
resource without explicit modifiers, we use linear. Failing that, we use
UBWC wherever possible; if this is not possible, we use tiled for
internal resources only or linear for shared resources.
v2 (Rob): respect FD_FORMAT_MOD_QCOM_TILED; do not print perf warning on
user choice of disabling UBWC;
v3: fix several issues breaking CI tests: revert removal of using
MOD_INVALID in various places, and assume implicit modifiers if present;
do not attempt to set UBWC flags when screen->tile_mode(prsc) falls back
to LINEAR (e.g. for small mip-maps levels); use TILED for implicit
modifier case with non-shared resources
v4: fix unintended demotion of UBWC, i.e. only check QCOM_COMPRESSED
modifier and demote UBWC to less optimal format when using explicit
modifiers
Signed-off-by: Daniel Stone <daniels@collabora.com>
Tested-by: Heinrich Fink <hfink@snap.com>
Signed-off-by: Heinrich Fink <hfink@snap.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12595>
Improves performance of SynMark OglDrvShComp by +241.879%±1.01366% (n=5)
on a random KBL desktop that I have. That seems to put it at about the
same performance as i965, but I did not test that in a statistically
sound way.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12858>
Use the flag that was set by nir_lower_passthrough_edgeflags. The
lowering passes will soon be moved to a finalize_nir hook, so there
won't be any choice. Ideally we'd like to eliminate iris_fix_edge_flags
completely, and this is a first step.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12858>
Most modern hardware needs the edge flag added as a hidden vertex input
and needs code added to the vertex shader to copy the input to an
output. Intel hardware is a little different. Gfx4 and Gfx5 hardware
works in the previously described mannter. Gfx6+ hardware needs the
edge flag as a specific vertex shader input, and that input is magically
processed by fixed-function hardware without need for extra shader code.
This flag signals only that the vertex shader input is needed. It would
be nice if we could decouple adding the vertex shader input from
generating the copy-to-output code, but that has proven to be
challenging. Not having that code causes other passes to want to
eliminate that shader input.
v2: Convert conditional to assertion. This pass is only called for
vertex shaders. Suggested by Ken.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12858>
The lowering passes will soon be moved to another function, so there
won't be any choice.
As a side benefit, this allows eliminating the uses_atomic_load_store
**pointer** parameter from brw_nir_lower_storage_image. For some reason
crocus was passing false instead of NULL.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12858>
...instead of looking for "ARB" in the name of the shader. This matches
the behavior of i965. Using "ARB" was added in a1ebac3750 ("iris:
Implement ALT mode for ARB_{vertex,fragment}_shader"), but there's no
explanation of why that method was used.
v2: Just use shader_info::is_arb_asm everywhere instead of
iris_uncompiled_shader::use_alt_mode. Suggested by Ken.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12858>
No need to re-create this every time we transition from stream-out
enabled to disabled.
Creation of streamout_disable_stateobj is deferred until we create
a program state using streamout to avoid creating it unnecessarily
and because fd6_prog_init() is called before ctx->pipe is created.
(Changing that ordering is complicated by the fact that u_blitter
copies pctx->bind_fs_state(), and friends.)
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12918>
Some more extreme examples, like gl_driver2_off, can be bottlenecked on
writes to cmdstream. OTOH the CP is pretty pipelined in how it slurps
in memory, so the penalty of using coherent buffers should not be so
much.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11176>
It hasn't really mattered until now, as we keep a separate cache for
cmdstream (which is FD_BO_GPU_READONLY), and the only other flag so
far is FD_BO_SCANOUT (which the bo cache probably messes up, but it
does not matter on most hw, and on hw where it does the scanout buffer
will be imported (and therefore won't end up in the bo cache).
But when we add cached-coherent (or if we wanted to use GPU_READONLY
more) it starts to matter.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11176>
When moving the batch cache to the context, I added hash table lookups
from batch to rsc for "is this resource in use" because we could no longer
store data in the rsc bo under the batch cache's lock.
We can save that cost by tracking a bitfield of resources referenced by
the batch, which gives us very cheap checks in the draw path at a minor
cost in memory. We can just use the GEM BO handle, since it's a nice
small integer already (we can't use the TC buffer ID, because the frontend
changes that, and we're in the driver thread).
This required moving the !pending() assert up in resource shadowing, since
the BO swap meant we were checking pending on the wrong resource.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11511>
I think the whole submit lock thing should be possible to remove now, but
just getting rid of the lock since we're no longer sharing batches between
ctxes means another several percent draw overhead improvement.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11511>
In moving batch cache to the context, the check for whether there's
pending work being done to this resources ends up accessing the context,
so we can't do it outside of the fd_context_access_begin(). This flag
lets us do the driver-thread asserts before we've decided whether we need
to flush.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11511>
This prevents other optimizations from associating the inner multiply,
which can add inaccuracies that can lead to discontinuities around the
boundary of the ffract. We should use exactly the sequence that the blob
uses to avoid problems.
Since fadd + fmul cannot be combined to ffma when exact is specified, we
have to use ffma ourselves.
Fixes artifacts in PixMark Volplosion with !7458.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12912>
this parameter is only a hint, as tc provides no method for tracking cases
when a buffer is bound multiple times to the same site (e.g., multiple vertex
buffer slots will be counted as 1 bind), so rename to "minimum" to be more clear
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12898>
upgrade_vertex copies save->copied.nr vertices to the vertex buffer,
so we need to make sure it has enough space to accomodate them.
This commit also drops the usage of COPY_CLEAN_4V_TYPE_AS_UNION in
this function because it always writes 4-components for all attributes,
but our buffer might be smaller. Instead, only write the needed
components.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5353
Fixes: cc57156dce ("vbo/dlist: rework vertex_store management")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12849>
The fd_fence_finish() may be passed a special timeout value PIPE_TIMEOUT_INFINITE.
This gets propagated all the way to get_abs_timeout(), where it gets converted to
a huge timeout value and passed down to the kernel. At least on iMX53, the kernel
may complain about this value being too large and emit a backtrace. The relevant
piece of information there is the following:
schedule_timeout: wrong timeout value bf94984b
Per suggestion by Rob Clark, fix this in get_abs_timeout() by picking the same
rollover implementation present in etnaviv. This fixes one part of the problem
where the tv_nsec becomes larger than NSEC_PER_SEC, which is invalid.
However, the PIPE_TIMEOUT_INFINITE is sufficiently large to make tv_secs larger
than KTIME_SEC_MAX, which makes kernel-side ktime_set() return KTIME_MAX and
that in turn triggers the above "wrong timeout value N" message. Fix this by
setting the timeout to large enough value in case of PIPE_TIMEOUT_INFINITE.
While the timeout is not truly infinite, the timeout is long enough as anything
longer than a few seconds means the GPU got hung.
The "util/timespec.h" is added so we can use NSEC_PER_SEC instead of ad-hoc
constant 1000000000 . The "pipe/p_defines.h" is needed for PIPE_TIMEOUT_INFINITE.
This problem can be reliably triggered on iMX53 using Qt5 with EGLFS support,
using the qtbase examples, as follows:
/usr/share/examples/opengl/qopenglwidget/qopenglwidget -platform eglfs
Fixes: f3cc0d2747 ("freedreno: import libdrm_freedreno + redesign submit")
Signed-off-by: Marek Vasut <marex@denx.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12886>
This helper simply is a wrapper to the clear color fields in the
iris_resource struct. We choose to delete it for two reasons:
1) It incorrectly asserts that the resource argument has an aux BO.
This doesn't hold for CCS_E on XeHP.
2) The majority of functions ignore the helper anyway and access these
fields directly.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12795>
Now that they're no longer ralloc'd, we have to be much more careful
about indirects. We have to make sure every time a source or
destination is overwritten, its indirect (if any) is freed. We also
have to choose a memory ownership convention for the rewrite functions.
Assuming that they will be called with the source from some other
instruction, we choose to always make a copy of the indirect (if any).
It's the responsibility of the caller to ensure its copy of the indirect
is freed.
Unfortunately, all this extra logic is going to make
nir_instr_rewrite/move_src/dest more expensive because they now have
all the logic of nir_src/dest_copy instead of a simple struct
assignment. Fortunately, the vast majority of rewrite calls are done by
nir_ssa_def_rewrite_uses which is an SSA-only fast-path.
Fixes: 879a569884 "nir: Switch from ralloc to malloc for NIR instructions."
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12884>
PSIZ output is only needed when:
1. There is a next stage and it reads it.
2. Primitive topology is point list, in the last vertex pipeline stage.
Zink always adds this output in its vertex (and other) shaders,
because it helps Zink avoid recompiling shader variants.
However, this has a performance impact for RADV because
it needs a scalar memory load. That becomes noticeable
at high primitive rates.
The Fossil stats are unremarkable because our DB doesn't include any
shaders from Zink or D9VK, but there are a few affected shaders.
Note that there may be an increase in LDS use in some GS. This is
because with PSIZ removed the ES per-vertex LDS size is smaller, so
we can squeeze more GS threads in the same workgroup.
Fossil DB stats on Sienna Cichlid:
Totals from 14 (0.01% of 128647) affected shaders:
CodeSize: 119884 -> 119732 (-0.13%)
LDS: 235008 -> 228864 (-2.61%); split: -2.83%, +0.22%
Instrs: 23076 -> 23048 (-0.12%)
Latency: 71667 -> 71625 (-0.06%)
InvThroughput: 19155 -> 18870 (-1.49%)
Copies: 1586 -> 1572 (-0.88%)
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10725>
this should be significantly more performant for the majority of cases
since it's rare that shaders have multiple variants outside of unit tests,
so now there can just be a list of shaders being iterated instead where the
first entry is the last used
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12842>
Get comfy.
llvmpipe coroutines have a stack frame. This is created by hooking
in malloc and coro.alloc and coro.size intrinsics.
LLVM has an CoroElide pass that is meant to allow that stack frame
to be done as an alloca in the caller instead of using the malloc path.
The CoroElide pass relies on the coroutine being inlined (fixed that).
The CoroElide pass relies on there being a direct connect between
coro.destroy(i8 *arg) and arg = coro.begin(id). However due to the
way the compute shaders are launched, there is no way to ensure that
link. Fixing the CoroElide pass seems quite difficult, I considered
having a force CoroElide always flag to make it dtrt, however I'm not
sure how ugly that would end up.
My first attempt tried to preallocate the stacks at a fixed size,
this turned out to be naive as the stack frame size was not sized
like I expected. Instead the first coro to run allocs enough for
everyone, so avoid the massive amounts of small allocations.
This remove coro malloc from a lot of profiles and shaves another 30s
or so from OpenCL ./conversions/test_conversions uchar_uin
(from 4.40m to just under 4m on my ryzen 7 1800x)
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12432>
This helps reduced the mtx lock/unlock overheads for the threadpool
if the work evenly distributes across the number of threads.
The CL CTS conversions tests really hit this, and this takes maybe 10-20s
off a 5min test run.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12432>
the mask can't entirely be calculated based on the integer parameters,
as it's possible for some of the "bind" slots to actually be unbinds,
so remove bits as necessary to fix this
also add some debug asserts to ensure I don't break this again for the
tenth time
Fixes: 6dd02a5139 ("zink: stop using util_set_vertex_buffers_mask()")
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12871>
Although the index has to be dynamically uniform, if we don't ever
execute a few lanes then we'll have 0, so it important to read the
ssbo index from the first active lane.
Just loop over them all.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12689>
* Refactor timeouts and retry attempts constants to variables in the top
of the python script.
* Increase LAVA job timeout value from 1 minute to 5 minutes, since the
timeout detection is just a heuristic based on the log silence in LAVA
devices. If we keep 1 minute timeout, maybe we could cancel jobs that
have tasks which may take too long to respond. Also, one minute
timeout is prone to misdetect scenarios when some network errors or
slowness may happen.
* Increase polling rate to check if the job has started from 1 check
every 30 seconds to 1 check every 10 seconds. Since it was taking 30
seconds in the worst case to start to get the log output from a LAVA
job. It is important to note that some LAVA jobs take less than 2
minutes to finish, so a 10 second wait would be more suitable in those
cases.
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12870>
There should be no difference in handling these two samplers,
handle GLSL_SAMPLER_DIM_EXTERNAL just like GLSL_SAMPLER_DIM_2D
to fix "unimplemented sampler 6" error in case someone tries to
use samplerExternalOES in shader program.
Signed-off-by: Marek Vasut <marex@denx.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12817>
Instead of creating our own based on the V3D version. CTS waivers
are registered using a combination of VendorID and DeviceID, so if
we want to reuse any wavers filed by Broadcom we want to use the
same identifiers. We are already using the Broadcom VendorId, so
let's start using the same deviceID as well.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12865>
This code was being tricky with passing a mem_ctx instead of the shader,
then freeing the mem_ctx when the pass was done and all the parallel
copies had been removed from the shader. Use the right type for instr
creation and do a bit of manual list management to prepare the way for
non-ralloc NIR instrs.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11776>
Calling this lower pass twice in a row would cause spurious
set_vertex_and_primitive_count(0, undef) intrinsics after the proper
set_vertex_and_primitive_count intrinsic. This pretty much turns any
geometry shader into garbage.
Fix this by treating nir_intrinsic_emit_vertex_with_counter and
nir_intrinsic_end_primitive_with_counter just like the non-_with_counter
versions. If no blocks would need set_vertex_and_primitive_count
intrinsics added, exit the pass before doing any work. This prevents
the need for DCE to do extra clean up later.
Since this pass is potentially called multiple times via multiple
invocations of a finalize_nir callback, it is (hypothetically?) possible
that control flow could be changed to add new blocks that need this
intrinsic. The check implemented in this commit should be robust
against that possibility.
v2: Add a_block_needs_set_vertex_and_primitive_count. Suggested by
Timur.
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12802>
This replaces vs_output_param_offset by vs_output_ps_input_cntl,
which is easier to use.
For geometry shaders, vs_output_ps_input_cntl is stored in the GS si_shader
structure, not gs_copy_shader. This requires that gs_copy_shader compilation
is finished before the GS main shader part, so that GS can initialize
vs_output_ps_input_cntl using the compiled GS copy shader.
output_semantic_to_slot becomes unused, so it's removed.
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12343>
This decreases overhead of si_update_shaders and overall driver overhead.
The VS shader key portion related to VS inputs is updated in set & bind
functions. Other fields related to outputs are still updated
in si_shader_selector_key.
Now that all modified fields are set to 0 when not needed, and remove
the memsets.
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12343>
While it doesn't immediately hang like on a660, it seems to be buggy and
the blob disables it.
This fixes a bunch of r8_* dEQP-VK tests, which seem to pass
individually but don't work when run after other tests. For example this
fixes failures running dEQP-VK.pipeline.sampler.*.r8_uint*.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12830>
In the future, we're going to have "real" BOs representing GEM objects,
and "slab allocated" BOs suballocated out of a larger BO. Many fields
are properties of the real underlying BO, but we may still want to ask
about an arbitrary BO, and have the accessor chase answers down as
necessary.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12848>
When I wrote this code originally, I decided to try and construct the
validation list up front, rather than at submission time. That worked
okay, but it's not really necessary. It's a fair amount of data to
store (struct drm_i915_gem_exec_object2 is 56 bytes per object), when
we can easily construct it on the fly.
More importantly, with suballocation, batch->exec_bos[i] may have
multiple entries corresponding to a single validation list entry.
Rather than tracking two lists with an awkward mapping between them,
we choose to just store the BO list and generate the other on the fly.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12848>
When we start suballocating BOs, multiple logical BOs may map to the
same GEM object, and thus share a validation list entry. However, we
want to track whether logical BOs are written, to avoid unnecessary
cross-batch data dependencies.
Just track that in a bitfield instead, where bit i corresponds to
batch->exec_bos[i].
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12848>
this is a partial barrier, so having access of any kind is invalid
VUID-vkCmdPipelineBarrier-srcAccessMask-02815(ERROR / SPEC): msgNum: 618171435 - Validation Error: [ VUID-vkCmdPipelineBarrier-srcAccessMask-02815 ] Object 0: handle = 0x2834530, type = VK_OBJECT_TYPE_COMMAND_BUFFER; | MessageID = 0x24d88c2b | vkCmdPipelineBarrier(): .pImageMemoryBarriers[0].srcAccessMask bit VK_ACCESS_TRANSFER_READ_BIT is not supported by stage mask (VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT). The Vulkan spec states: The srcAccessMask member of each element of pMemoryBarriers must only include access flags that are supported by one or more of the pipeline stages in srcStageMask, as specified in the table of supported access types (https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/vkspec.html#VUID-vkCmdPipelineBarrier-srcAccessMask-02815)
Objects: 1
[0] 0x2834530, type: 6, name: NULL
zink DEBUG: ERR: 'Validation Error: [ VUID-vkCmdPipelineBarrier-srcAccessMask-02815 ] Object 0: handle = 0x2834530, type = VK_OBJECT_TYPE_COMMAND_BUFFER; | MessageID = 0x24d88c2b | vkCmdPipelineBarrier(): .pImageMemoryBarriers[0].srcAccessMask bit VK_ACCESS_TRANSFER_READ_BIT is not supported by stage mask (VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT). The Vulkan spec states: The srcAccessMask member of each element of pMemoryBarriers must only include access flags that are supported by one or more of the pipeline stages in srcStageMask, as specified in the table of supported access types (https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/vkspec.html#VUID-vkCmdPipelineBarrier-srcAccessMask-02815)'
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12845>
It only makes sense to call this pass for fragment shaders, and the
first thing the pass does is read a FS-specific field out of a union,
so it isn't safe to call it for other shader stages.
We could make it early return, but instead we just assert, so that
drivers know to only call it when appropriate.
(A previous version of this patch, which early returned instead of
asserting, was Reviewed-by: Emma Anholt <emma@anholt.net> as well.)
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12839>
i965 called this pass unconditionally, while st/mesa only calls it for
fragment shaders. It only makes sense to run for fragment shaders, and
the first thing the pass does is read a FS-specific field out of a
union. This isn't safe for other stages.
Fixes about 20,630 test failures on i965 since 91dc863921, which moved
the advanced_blend_modes field. The field had previously been in a
union with no other fields, so it never aliased anything, and thus
worked, even if it was wrong. That commit moved it to a union that had
fields for other stages, so it started reading garbage and trying to
lower advanced blending for other stages on i965.
Fixes: 91dc863921 ("mesa: Move the advanced blend bitmask to shader_info.")
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12839>
this reduces the component key size for decomposition by up to 75%, down
to as low as 2 bytes, which is more optimal for both hashing and memcmp of
the key
it will become more useful as further changes are added to improve vertex format
support, enabling the keysize to remain relatively small
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12771>
This consolidates several duplicated pieces of code into devinfo.
max_scratch_ids is an array that provides the max number of threads
for the rendering and compute stages.
This fixes some exceptions missed by crocus for scratch ids on haswell
and cherryview.
It also fills out devinfo->max_scratch_ids properly for stages VS
through CS on Gfx12.5. But, functionally this should not make a
difference as Gfx12.5 already uses COMPUTE for all stages.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12799>
By default, Mesa's X11 Vulkan WSI will wait for buffers to be ready
before submitting them to Xwayland when the swapchain is created
with the IMMEDIATE mode.
This is undesirable when the Wayland compositor already monitors
fences. A Wayland compositor may want to know the delay between
the buffer submition and the end of the GPU work, this is impossible
to measure if the WSI waits for the buffer to be ready before
submission.
Since most compositors don't monitor fences, let's introduce a driconf
option for this for now. We can reconsider once more compositors
have better support for fences.
Signed-off-by: Simon Ser <contact@emersion.fr>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11290>
VK-CTS v1.2.7.0 has buggy tests that only work if DRM support is
available for them (drm_files_exist). This isn't exposed in the Mesa
CI by other farms, because their infra installs libdrm-dev as part
of either rootfs generation for freedreno/broadcom or respective
container stages (for lava). In the case of radv, we directly use the
x86 Mesa testing containers, so we are the odd ones out here.
By moving the building of the custom libdrm above the building of
vk-gl-cts, it will compile in support required for this test to pass,
ensuring the x86_test-vk container has the right dependencies to match
the rest of the CI. Lava actually installs drm development files
twice, once from the Debian repos, which vk-gl-cts then compiles
against, and a second time from a tarball, which the tests will use at
runtime. Seemed a little cleaner to use the version of libdrm
specified in the Mesa CI, and hence used at both build time and
runtime.
A bug should be raised with the testsuite to avoid this in the future,
but we should probably have libdrm development files exposed for these
components anyway.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Martin Peres <martin.peres@mupuf.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12777>
unrefs here (almost always) mean destruction, which means eating the cost
of the atomics for the unrefs and then also the destructors
instead, handle this at the end of the next submit from this batch, since the
submit thread is never as busy as the driver thread
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12759>
Brings in these changes:
99be1b06ff36 framework/replay: Display the image differences if any
3074b9c72b3d glsl-predication-on-large-array: Test predication on values from large array
c97da22d35b4 cmake: Fix gbm test compiling
0cbccd68c3c1 piglit: Find our data directory when we're invoked through a symlink
4eb71fc10bbe arb_sso: add test that has explicit locations and array fields in ifc
fa9c82380273 glsl-1.30: test shadow var in a switch
aa7f042b0417 glsl-1.30: add tests for incorrect "compare to 0" optimizations
60138ef32ec1 add explicit tests for GetFragDataLocation/Index(gl_Frag*)
4a8806696b90 egl: add test for EGL_KHR_display_reference
d6b7053b4e52 glsl-1.30: test that switch expression is evaluated once
8023a3c945c3 arb_shader_storage_buffer_object: Require extension on the new test
8820cac60827 pbobench: Fix sometimes-uninitialized warning.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12675>
Re-usable command buffer could be resubmitted any number of times,
but tracepoints are written once. u_trace_clone_append allows
copying tracepoints and copying timestamps if GPU doesn't support
writing timestamps into indirect address.
The case of tiling GPUs is similar, command stream for draws is
resubmitted for each tile.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Reviewed-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10969>
With little modifications u_trace could be usable for Vulkan drivers.
Beside removing dependencies on gallium, the other notable change is
the passing of opaque flush_data pointer via u_trace_flush. There
is data which becomes available only at this point which other drivers
may want to pass.
For example Vulkan drivers would want to pass at least submission id
(for perfetto) and a sync object to wait on in u_trace_read_ts.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Reviewed-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10969>
This matches the blob. In theory, this is necessary only because the
VS/HS workgroup can now span more than one wave and a patch may be
assigned to different waves in the VS and HS. However I've seen it fix
tests where the entire draw should fit in one wave, so there may some
other sort of waiting this does or the HW dispatch may be inefficient
sometimes.
Fixes
EQP-VK.tessellation.user_defined_io.per_patch.vertex_io_array_size_implicit.*
when run immediately after
dEQP-VK.tessellation.invariance.outer_triangle_set.quads_fractional_even_spacing
or when all of dEQP-VK.tessellation.* is run in sequence on a650.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12791>
Memory is never unbound, and vulkan mandates that the memory stays around
for the image lifetime, unless another chunk of memory is bound to this
image. Let's keep things simple and don't take a reference on the BO
we bind to an image, this way, the memory gets released as soon as
vkFreeMemory() is called.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12762>
As we don't know if we are going to have spilling or not, emit always a
last thrsw at the end of the shader.
If later we don't have spillings and we don't need that last thrsw, we
remove it and switch back to the previous one.
This way we ensure all the spilling happens always before the last
thrsw.
v2 (Juan):
- Rework the code to force a last thrsw and remove later if no spilling
v3:
- Merge functionality inside vir_emit_last_thrsw (Iago)
- Add vir_restore_last_thrsw (Juan)
v4 (Iago):
- Fix/add new comments
- Rename variables/parameters
v5 (Iago):
- Fix comments
- Add assertion
Cc: mesa-stable
Fixes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4760
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12322>
This will let some copy prop happen automatically, avoiding MOVs to temps.
Most importantly, though, it means that virgl won't see (unused channel)
swizzles from channels beyond the bounds of sysvals, which trigger shader
compile failures on the host.
softpipe shader-db:
total instructions in shared programs: 2946336 -> 2934777 (-0.39%)
instructions in affected programs: 374676 -> 363117 (-3.09%)
total temps in shared programs: 565552 -> 564139 (-0.25%)
temps in affected programs: 18138 -> 16725 (-7.79%)
Reviewed-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12781>
It is not an error when a physical device is filtered out. But it is an
error when a physical device fails to initialize.
Fixed
dEQP-VK.api.device_init.create_instance_device_intentional_alloc_fail.
v2: separate success and fail paths
Fixes: 7dfac808 ("venus: no supported device is not an error")
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org> (v1)
Reviewed-by: Ryan Neph <ryanneph@google.com> (v1)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12723>
This is required for d3d10+, which has depth_clamp always enabled
regardless of depth_clip (in contrast to OpenGL, where enabling
depth_clamp disables depth_clip). There doesn't seem to be a GL
extension for it, but it will be used for lavapipe to implement
VK_EXT_depth_clip_enable.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12260>
According to ARB_tbo spec, default format is LUMINANCE8, but according
to core spec, it is R8.
This fixes piglit's spec@arb_texture_buffer_object@get test with drivers
supporting ARB_tbo spec but OpenGL/ES < 3.1.
v2:
- Compare against compat profile (Ilia)
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12774>
Simplify the whole thing:
- keep a single function (grow_vertex_storage) that extends the array
- call it when the array is full (in ATTR_UNION) or at the beginning of
a primitive when the vertex count is known to avoid multiple reallocations.
- allocate save->vertex_store in vbo_save_NewList if needed
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12646>
This means that each list will start writing its vertices at index 0.
The previous mode (append) was useful in the past when the vertices
were written directly to a mapped-buffer object.
Now that there's an intermediate storage in RAM, the added complexity
of the append-mode has no value so drop it.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12646>
Now that we don't have links to the prim_store->prims pointers, we
can replace the free/malloc by a realloc version to grow the prim
storage as needed by a list.
This will be used in the next commit to avoid splitting lists in
multiple vbo_save_vertex_list instances because the prim_store was full.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12646>
If tess is enabled, then VS chains to the HS and we have to use the HS
value for the PrimID sysval. This is still true if GS is also enabled,
so we need to use the HS instead of the GS if both are enabled. In
particular if the HS or DS uses gl_PrimitiveID but the GS doesn't then
we still need to setup the register.
This fixes a bunch of dEQP-VK.tessellation.invariance.primitive_set.*
cases on a650, although it seems they managed to still pass on a630 with
the broken PrimID handling.
Fixes: 8115cde3ba ("tu, freedreno/a6xx, ir3: Rewrite tess PrimID handling")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12768>
flat interpolation type is not enabled because we need to set
SPI_PS_INPUT_CNTL_x.FLAT_SHADE=1
which is per vec4.
16 bit varying also need to set
SPI_PS_INPUT_CNTL_x.FP16_INTERP_MODE
but varying packing only support 32 bit, so we don't need to
worry about this for now.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12537>
Driver like radeonsi load varying in a scalar manner, so prefer to pack
varying with different interpolation qualifier into same slot to save
space.
But driver like panfrost/bifrost can load varying in vector manner,
so prefer to pack varying with same interpolation qualifier.
Driver can add interpolation qualifiers which are able to be
packed into same varying slot to pack_varying_options nir option.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12537>
This fixes dEQP EGL tests when glthread is enabled:
dEQP-EGL.functional.sharing.gles2.multithread.random.images.copyteximage2d.*
dEQP-EGL.functional.sharing.gles2.multithread.random.images.texsubimage2d.*
dEQP-EGL.functional.sharing.gles2.multithread.random_egl_server_sync.images.teximage2d.*
dEQP-EGL.functional.sharing.gles2.multithread.random_egl_server_sync.images.texsubimage2d.*
dEQP-EGL.functional.sharing.gles2.multithread.random_egl_sync.images.copyteximage2d.*
dEQP-EGL.functional.sharing.gles2.multithread.random_egl_sync.images.texsubimage2d.*
Deadlock happens when:
Thread A: call EGL context functions which will involve _mesa_glthread_finish(), like
eglMakeCurrent() and eglDestroyContext(). It will hold the EGLDisplay.Mutex and wait
on glthread job queue empty (util_queue_fence_wait(&last->fence)). glthread job thread
executes batch holding gl_context.Shared.TexMutex (glthread_unmarshal_batch()).
Thread B: call EGLImage import functions like EGLImageTargetTexture2DOES() which will
hold gl_context.Shared.TexMutex (egl_image_target_texture()) then validate EGLImage
and hold EGLDisplay.Mutex (dri2_lookup_egl_image()).
This fixes the deadlock by moving the EGLImage validation out of gl_context.Shared.TexMutex
lock area.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12336>
__declspec(dllimport) isn't needed for linking to functions, extern
is sufficient. The preprocessor define used to determine when to
set it (_DLL) was incorrect, since that preprocessor define is set
anytime you're linking against dynamic CRT as opposed to static CRT.
Reviewed-by: Bill Kristiansen <billkris@Microsoft.com>
Reviewed-by: Marek Olák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12776>
I'd like to support EGL on Windows, using the same architecture as Linux.
On Linux, libgallium_dri.so is a "megadriver," containing the Mesa Gallium
state tracker, plus the actual driver implementations.
Now, on Windows, libgallium_wgl.dll is a proper OpenGL ICD, and OpenGL32.dll
is just a stub DLL which implements the wgl* APIs in terms of that ICD.
This is the more "architecturally clean" way to share the state tracker
between EGL and WGL.
Reviewed By: Bill Kristiansen <billkris@microsoft.com>
Reviewed-by: Charmaine Lee >charmainel@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12677>
Previously, any DLL which links any function from libglapi-static would
end up exporting the entire GL API surface area, due to the dllexport
introduced by BUILD_GL32. This fix allows DLLs to internally include
definitions of gl* APIs without having to export the entire surface.
Also, remove unreachable with_shared_glapi branch already in an else block.
Reviewed By: Bill Kristiansen <billkris@microsoft.com>
Reviewed-by: Charmaine Lee >charmainel@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12677>
From the OpenGL 4.6 spec, section 18.2.8:
"For a signed normalized fixed-point color buffer, each component is
clamped to [0,1] if read color clamping is enabled, or if type
represents un- signed integer components; otherwise type represents
signed integer components, and each component is clamped to [−1,1]."
Signed-off-by: Italo Nicola <italonicola@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12749>
When a batch fails we either recreate our context (in case we got -EIO
or -ENOMEM) or we abort() (every other error). If we don't abort and a
later batch has a dependency on the batch that failed, then this newer
batch will fail with -EINVAL since it requires a syncobj that was
never submitted, which means we'll abort().
To avoid this problem, in this patch we simply signal syncobjs of
failed batches. This means we may be breaking our dependency tracking,
but IMHO it's better than simply letting it abort() later.
In other words, this moves the situation for some apps from "app
causes a GPU hang and then aborts" to "app causes a GPU hang but keeps
running".
Note: on some older Kernels (like today's Debian 5.10 Kernel) I see X
simply freezing after the GPU hang when the app doesn't decide to
abort(). Switching to a more recent Kernel fixes this issue for me, so
in case it happens to you make sure you have the most recent stable
trees.
v2:
- Fix coding style (Ken).
- Use the big comment block provided by Ken (Ken).
- Adjust the commit message so avoid saying we retry (Ken).
- Rebase after the syncobj ownership changes.
- Drive-by add a missing white space in the header.
Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12657>
Following on from !12475, do the same CCU workaround for freedreno as
turnip is doing, so that we flush CCU correctly for when color/depth is
next read under a different cache domain from where it was written.
Fixes instability (particularly if the GPU is clocked up) on
dEQP-GLES3.functional.fbo.blit.depth_stencil.depth32f_stencil8* in bypass
mode on a630.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11481>
At some point I split up the flags into overall/source flags and made
copies from immed/const only set IR3_REG_IMMED/IR3_REG_CONST on the
source flags, but I forgot to update this. Noticed by inspection.
Fixes: 0ffcb19b9d ("ir3: Rewrite register allocation")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12747>
In the case of an app returning from main(), Windows will apparently terminate
other threads before invoking final cleanup on the main thread.
llvmpipe can't wait for threads to signal a semaphore if the thread is already
gone. Since we're already in a WIN32 special case, just call the Win32 API
to check if the thread is terminated or STILL_ALIVE.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12731>
i915 has no support for control flow, so we need to link-fail shaders that
fail to unrooll loops. This is valid for GLES2, and non-conformant but
the best we can do for GL2.
Note that we still have some dEQP failures where loops that should be
unrollable and thus are required to be supported don't get unrolled
(#4979).
Closes: #4978
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12218>
GLES2 drivers are allowed to reject some GLSL constructs, like dynamic
loop bounds (which neither i915g nor vc4 can fully support), but gallium
hasn't had any way to trigger a link failure. Add a return msg to the
finalize_nir hook, which is called at the end of GLSL linking, and use
that. This means that some other callers of finalize need to do something
with the msg, and we (for now) just throw it away.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12218>
We want to be able to use finalize_nir, but doing so requires this flag to
be set because not having it is incompatible with being able to finalize
twice (since the texcoord workaround varyings shift happens at variant
time rather than link time).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12218>
We had an optimization to auto-enable early fragment tests when a shader
didn't have side effects, but of course, we cannot do that this if the
shader writes Z, as in that case the fragment tests need to use the
value written from the shader.
Also, if the shader enables early fragment tests, then any shader Z
writes should be ignored.
Fixes:
dEQP-VK.spirv_assembly.instruction.graphics.early_fragment.*
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12736>
If the coherent flag is present, then we need to not have an incoherent
cache between us and previous stores to the image that were also decorated
as coherent. isam apparently (unsurprisingly) goes through a texture
cache. Use ldib instead, so that we don't get the wrong result.
We would need a similar fix for a4xx, but that uses ldgb and I don't
have hardware to test on.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12704>
If the coherent flag is present, then we need to not have an incoherent
cache between us and previous stores to the image that were also decorated
as coherent. isam apparently (unsurprisingly) goes through a texture
cache. Use ldib instead, so that we don't get the wrong result.
We need a similar fix for pre-a6xx, but we don't have
emit_intrinsic_load_image for those (yet).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12704>
We disabled PIPE_CAP_PRIMITIVE_RESTART on ffc4d82438 ("v3d: Disable
PIPE_CAP_PRIMITIVE_RESTART") because the HW can only support
PIPE_CAP_PRIMITIVE_RESTART_FIXED_INDEX subset.
But the introduction of PIPE_CAP_EMULATE_NONFIXED_PRIMITIVE_RESTART
allows us to support these nonfixed primitive restarts so we can now
re-enable NV_primitive_restart for OpenGL extensions.
Acked-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12669>
We are losing the optimization of converting a single quad to
a triangle fan reusing the same four vertex in the buffer.
Maybe this optimization can be ported to primconvert, QUADS are
always converted to TRIANGLES with primconvert. And i965, crocus
and svga have similar optimizations.
V3D doesn't implement this optimization and according to when it was
introduced on 230e646a40 ("broadcom/vc4: Decompose single QUADs to
a TRIANGLE_FAN."):
"No significant difference in the minetest replay, but it should reduce
overhead by not requiring that we write quad indices to index buffers
that we repeatedly re-upload (and making the draw packet smaller, as
well)."
v2: Commit log includes more detail about the removed optimization.
(Alejandro Piñeiro)
Reference: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5277
Suggested-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Acked-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12669>
This is allowed by the Vulkan spec and we have to handle this situation
internally. We used to create and bind a 4096x4096 image to copy the
VRS rates but this wasted too much VRAM (~33MiB). Now, the driver only
allocates a HTILE buffer (~1MiB) and bind it to the framebuffer.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12243>
This commit introduces a new struct SubdwordSel
in order to ease and clean up the usage of SDWA
selections. This includes removing the distinction
between register-allocated and fixed SDWA selections.
Instead, SDWA selections can now also access the high
bits of subdword variables. Alignment and sizes are
validated accordingly. Size, offset and sign_extend
can be evaluated via helper methods.
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12640>
this feature lets zink avoid the screen-based framebuffer cache with locks
in favor of a context-based one that doesn't need any complicated wizardry
to work since it doesn't need to track refcounts for attachments or work
across contexts since the surface info gets passed in when the renderpass
is begun
also expand the dummy surface to an array for use with multisampling and simplify
surface refs there for non-imageless case
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12661>
This estimation was incorrect, the number of waves doesn't only
depend of the number of VGPRs.
Though, {SPI,COMPUTE}_TMPRING_SIZE.WAVES should limit the number of
scratch waves in flight, not sure if limiting it really works.
This fixes a GPU hang with an upcoming game, and this might also
helps resolving some spurious random GPU hangs.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12700>
This includes setting the correct end point of the propagation and
not propagating the incoming values after the loop header.
This patch also changes the propagation to a single iteration for
loop exit phis.
No fossil-db changes.
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
aco: don't propagate incoming value in init_any_pred_defined()
No fossil-db changes.
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11659>
Offical naming of Mali GPUs is like Mali-G52 or Mali-T860 wth a dash.
Also variants of the same GPU e.g. revision 1 are generally not part
of the name. This adds a dash instead of a space between Mali and the
model and also splits off the r1 revision with a space. This should
keep the naming in-line with offical names and with what the binary
DDK uses for naming.
Signed-off-by: Carsten Haitzler <carsten.haitzler@foss.arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12667>
This is the last step before we can start removing the history flush
mechanism: In cases where a dirtied buffer has the potential to be
concurrently bound to the pipeline (as indicated by the bind_history
mask), flag the "flush" dirty bits corresponding to its binding point.
This ensures that the buffer-local memory barriers introduced earlier
in this series are executed before the next draw call, which in turn
will emit any necessary PIPE_CONTROLs in cases where the buffer is
bound through a cache incoherent with the cache that performed the
write.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12691>
This adds buffer-local barriers so any required synchronization
commands are emitted before a buffer object is used as source for
indirect draw parameters. An unconditional PIPE_CONTROL meant to
flush the contents of the draw count buffer can now be removed, since
it's redundant with the more accurate buffer-local barrier introduced
here, which should avoid flushing in cases where the buffer wasn't
written by any incoherent cache since the last flush.
(Rebased by Kenneth Graunke.)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12691>
This ensures that any required synchronization (i.e. PIPE_CONTROL)
commands are emitted whenever a vertex or index buffer is used in
cases where it had been previously accessed from an incoherent caching
domain.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12691>
This will allow us to order writes and reads of vertex and index
buffers by using the same cache tracking infrastructure introduced
previously for render and depth buffers. The ultimate goal is to
remove the somewhat heavy-handed history flush mechanism currently
used for buffer objects, and use a single cache tracking mechanism
across the whole driver.
v2: Use C99 designated initializers (Ken).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12691>
For blob_mem allocated from virtgpu_virgl backend, the guest mappable
size queried can be smaller than the size returned from image memory
requirement query from the host side. Here we temporarily workaround
until we switch to use cross-domain backend in minigbm.
Cc: 21.2.3 mesa-stable
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12687>
We're moving away from relying on the Kernel's implicit busy tracking
into our own tracking, except for shared buffers.
Not only this shouldn't hurt now (it doesn't, according to my
measurements), when we switch to vm_bind we will be able to cut some
significant overhead by simply omitting all the async buffers from the
execbuf ioctl.
v2:
- Change iris_bo_busy() to bool (Ken).
- Fix coding style issues (Ken).
- Rebase on not having the refcount _inc and _dec helpers anymore
(Ken).
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4748
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12363>
We want to implement explicit BO dependency tracking and for that
we'll use arrays of dependencies (syncobjs) indexed by screen->id.
This is way more efficient than storing and checking screen pointers
everywhere.
v2: Properly use atomic operations in a non-racy way (Alyssa, Ken).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12363>
The next patches will justify the new ownership. We want the BOs to
have references on the batches' syncobjs so we can implement implicit
tracking. In other words: BOs will be able to wait on syncobjs owned
by different screens. Since our syncobjs are actually just a Kernel
handle with a refcount, they can be used globally and it makes more
sense to map them to the bufmgr, just like the BOs.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12363>
This is the first part of a refactor to make vertex compaction optional.
Additionally, it may yield a very small benefit to allocate the PC
space sligtly sooner.
Fossil DB stats on Sienna Cichlid with NGGC on:
Totals from 58239 (45.27% of 128647) affected shaders:
CodeSize: 160502348 -> 160502340 (-0.00%)
Instrs: 30722664 -> 30722662 (-0.00%)
Latency: 137627419 -> 137782218 (+0.11%); split: -0.00%, +0.11%
InvThroughput: 21698587 -> 21699068 (+0.00%); split: -0.00%, +0.00%
Copies: 3288263 -> 3288261 (-0.00%)
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12246>
On a6xx resinfo returns size in bytes divided by IBO_0_FMT format size
(not just size in dwords), we have to shift it back to NIR meaning which
is size in bytes.
Make freedreno use 16b buffers when they are supported in order to be
able to depend on hardware capabilities when lowering ssbo size.
Fixes: ce1a381e57 "turnip: enable VK_KHR_16bit_storage on A650"
Fixes cts tests:
dEQP-VK.ssbo.unsized_array_length.float_offset_explicit_size
dEQP-VK.ssbo.unsized_array_length.float_no_offset_whole_size
dEQP-VK.compute.basic.write_multiple_unsized_arr_single_invocation
and many more
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12485>
In this case std::array doesn't behave like a regular array, therefore
it is NOT okay to index it outside the array, even though std::fill
needs us to do so.
Change the syntax to do the same thing slightly differently,
and add an assertion to make sure the registers are always within
the array's bounds.
Closes: #5289
Fixes: 0e4747d3fb
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Tony Wasserka <tony.wasserka@gmx.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12664>
The usual linear-scan register allocation algorithm can't handle
preallocated registers, since we might be forced to choose a color for
a non-preallocated variable that overlaps with a pre-allocated variable.
But in such cases we can simply split the live range of the offending
variable when we reach the beginning of the pre-allocated variable's
live range. This is still optimal in the sense that it always finds a
coloring whenever one is possible, but we may not insert the smallest
possible number of moves. However, since it's actually the scheduler
which splits live ranges afterwards, we can simply fold in the move
while keeping its fake dependencies, and then everything still works! In
other words, inserting a live range split for a value register during
register allocation is pretty much free.
This means that we can split register allocation in two. First globally
allocate the cross-block registers accessed through load_reg and
store_reg instructions, which is still done via graph coloring, and then
run a linear scan algorithm over each block, treating the load_reg and
store_reg nodes as referring to pre-allocated registers. This makes the
existing RA more complicated, but it has two benefits: first, using
round-robin with the linear scan allocator results in much fewer fake
dependencies, resulting in around 15 less instructions in the glmark2
jellyfish shader and fixing a regression in instruction count since
branching support went in. Second, it will simplify handling spilling.
With just graph coloring for everything, every time we spill a node, we
have to create new value registers which become new nodes in the graph
and re-run RA. This is worsened by the fact that when writing a value to
a temporary, we need to have an extra register available to load the
write address with a load_const node. With the new scheme, we can ignore
this entirely in the first part and then in the second part we can just
reserve an extra register in sections where we know we have to spill. So
no re-running RA many times, and we can get a good result quickly.
The current implementation does linear scan backwards, so that we can
insert the fake dependencies while allocating and avoid creating any
move nodes at all when we have to split a live range. However, it turns
out that this makes handling schedule_first nodes a bit more
complicated, so it's not clear if that was worth it.
Note:
The commit was originally authored by Connor Abbott <cwabbott@gmail.com>
and was cherry-picked from <mesa/mesa!2315>.
Rebasing was necessary due to changes to BITSET_FOREACH_SET,
see 4413537c
Because some deqp tests pass now, deqp-lima-fails.txt was also changed.
The above changes are
Signed-off-by: Andreas Baierl <ichgeh@imkreisrum.de>
Reviewed-by: Erico Nunes <nunes.erico@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7682>
and use it with vertex shaders.
Note:
The commit was originally authored by Connor Abbott <cwabbott@gmail.com>
and was cherry-picked from <mesa/mesa!2315>.
Apart from some changes, which were necessary due to rebasing, the following
changes have been added:
clone_intrinsic() was changed to use nir_instr_clone() instead of
doing it manually.
Tests against `src->parent_instr->type != nir_instr_type_phi` have been
inserted, otherwise we may run into a nir validation error.
Intrinsic load_input and load_uniform are not duplicated, if their source
type is nir_instr_type_load_const.
The above changes are
Signed-off-by: Andreas Baierl <ichgeh@imkreisrum.de>
Reviewed-by: Erico Nunes <nunes.erico@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7682>
Two render passes are compatible if their corresponding color, input, resolve, and depth/stencil
attachment references are compatible and if they are otherwise identical except for:
• Initial and final image layout in attachment descriptions
• Load and store operations in attachment descriptions
• Image layout in attachment references
VK 8.2
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12605>
stall and flush+stall are not the same; in some cases, the driver must only
stall and never flush, so ensure that this is possible to avoid infinite
recursion
fixes Metro Last Light: Redux benchmark mode
Fixes: d8905446d6 ("zink: rework oom flushing")
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12652>
This just changes the calcs to be cleaner and easier to interpret.
Adjust the inclusive (x0/y0) by -1 like before, and then flip the
sign for the correct direction.
Add full pixel to the exclusive side after scaling, this is do
show that this value is incorrect and the next patch fixes that
taking multisample into account
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12504>
The state wasn't storing the shader depth/stencil outputs
per-sample, so only the last sample emitted was being used
for the late depth test and stencil ref.
Noticed while trying to fix some vulkan depth stencil resolve
issues
Fixes: a0195240c4 ("llvmpipe: handle multisample early depth test/late depth write")
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12504>
According to OES_EGL_image_external_essl3:
On p. 196 in the errors section for BindImageTexture, replace the
last error with the following:
"An INVALID_OPERATION error is generated if <texture> is neither the
name of an immutable texture object, nor the name of an external
texture object."
According to OES_EGL_image_external:
The command
void EGLImageTargetTexture2DOES(enum target, eglImageOES image);
with <target> set to TEXTURE_EXTERNAL_OES defines the currently bound
external texture object to be a target sibling of <image>.
...
If <target> is not TEXTURE_EXTERNAL_OES, the error INVALID_ENUM is
generated. (Note: if GL_OES_EGL_image is supported then <target> may
also be TEXTURE_2D).
Currently, mesa only allows GL_TEXTURE_EXTERNAL_OES textures to be bound
by glBindImageTexture. However, the language of the specification does not
appear to use "external" to refer to GL_TEXTURE_EXTERNAL_OES specifically,
since OES_EGL_image_external allows external eglImageOES to be attached
to GL_TEXTURE_2D in the presence of GL_OES_EGL_image. Thus, it should be
interpreted to refer to all types of external textures, including 2D
textures attached via glEGLImageTargetTexture2DOES.
Fixes: ed43dd62ac ("main: allow external textures for BindImageTexture")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12383>
a6xx supports shaders with more than 64k dwords, or at least the shader
size register has increased in size, and the matching name is gone so
there's no reason to be clever here. This doesn't fix anything at the
moment.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12487>
For now, only mark the 4x8BitPacked variants as accelerated.
Applications are unlikely to use the "add with saturate" opcodes from
VK_INTEL_shader_integer_functions2, so, technically, all of the
AccumulatingSaturating variants "[provide] a performance advantage over
user-provided code composed from elementary instructions..." on all
Intel platforms. If we encounter an application that cares, we can do
things differently then. Ditto for the non-packed 8Bit, 4-element
vector variants.
v2: Don't memset props as this also zeros sType and pNext. Noticed by
Georg Lehmann in !12617.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12624>
Previously, we misunderstood how conditional modifiers and saturate
interacted. We thought the condition was evaulated before the saturate
was applied. For the floating point cases, we went to some heroics to
modify the condition to maintain the same results. For integer cases,
it was not clear that this could even work. We had no use-cases and no
tests-cases, so we just disallowed everything.
Now we understand that the condition is evaluated after the saturate.
Earlier commits in this series removed the various floating point
heroics. It is easier to just delete the code that prevents some cases
that just work.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
Originally this was part of "intel/fs: Remove condition-based
restriction for cmod propagation to saturated operations". With some
additional changes to that commit, it caused a lot of extra churn in the
unit tests. I felt that made it harder to see the actual changes in the
unit tests, so I split it out.
Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
I don't know why the float_saturate_l_mov test was #if'ed out, but it
passes... so this commit enables it.
No shader-db or fossil-db changes.
In a previous iteration of this MR, this commit helped ~200 shaders in
shader-db. Now all of those same shaders are helped by "intel/fs: cmod
propagate from MOV with any condition". All of these shaders come from
Mad Max. After initial translation from NIR to assembly, these shader
contain patterns like:
mul(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */
...
mov.sat(8) g90<1>F g90<8,8,1>F
...
cmp.nz.f0(8) null<1>F g90<8,8,1>F 0 /* 0F */
An initial pass of cmod propagation converts this to
mul(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */
...
mov.sat.XX.f0(8) g90<1>F g90<8,8,1>F
Without this commit, XX is G. With this commit, XX is NZ. Saturate
propagation moves the saturate:
mul.sat(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */
...
mov.XX.f0(8) g90<1>F g90<8,8,1>F
Without this commit (but with "intel/fs: cmod propagate from MOV with
any condition"), the G gets propagated:
mul.sat.g.f0(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */
With this commit (with or without "intel/fs: cmod propagate from MOV
with any condition"), the NZ gets propagated:
mul.sat.nz.f0(8) g90<1>F g88<8,8,1>F 0x40400000F /* 3F */
Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
There were tests related to propagating conditional modifiers from a MOV
to an instruction with a .SAT modifier for a very long time, but they
were #if'ed out.
There are restrictions later in the function that limit the kinds of MOV
instructions that can propagate. This avoids the dangers of
type-converting MOVs that may generate flags in different ways.
v2: Update the added comment to look more like the existing comment.
That makes the small differences between the two cases more obvious.
Noticed by Marcin.
All Intel platforms had similar results. (Ice Lake shown)
total instructions in shared programs: 19827127 -> 19826924 (<.01%)
instructions in affected programs: 62024 -> 61821 (-0.33%)
helped: 201
HURT: 0
helped stats (abs) min: 1 max: 2 x̄: 1.01 x̃: 1
helped stats (rel) min: 0.13% max: 0.60% x̄: 0.35% x̃: 0.36%
95% mean confidence interval for instructions value: -1.02 -1.00
95% mean confidence interval for instructions %-change: -0.36% -0.34%
Instructions are helped.
total cycles in shared programs: 954655879 -> 954655356 (<.01%)
cycles in affected programs: 1212877 -> 1212354 (-0.04%)
helped: 155
HURT: 6
helped stats (abs) min: 1 max: 6 x̄: 3.65 x̃: 4
helped stats (rel) min: <.01% max: 0.17% x̄: 0.07% x̃: 0.07%
HURT stats (abs) min: 2 max: 12 x̄: 7.00 x̃: 8
HURT stats (rel) min: 0.04% max: 0.23% x̄: 0.14% x̃: 0.15%
95% mean confidence interval for cycles value: -3.60 -2.90
95% mean confidence interval for cycles %-change: -0.07% -0.05%
Cycles are helped.
Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
We were previously operating with the mindset "a MOV is just a compare
with zero." As a result, we were trying to share as much code between
the MOV path and the CMP path as possible. However, MOV instructions
can perform type conversions that affect the result of the comparison.
There was some code added to better handle this for cases like
and(16) g31<1>UD g20<8,8,1>UD g22<8,8,1>UD
mov.nz.f0(16) null<1>F g31<8,8,1>D
The flaw in these changed special cases is that it allowed things like
or(8) dest:D src0:D src1:D
mov.nz(8) null:D dest:F
Because both destinations were integer types, the propagation was
allowed. The source type of the MOV and the destination type of the OR
do not match, so type conversion rules have to be accounted for.
My solution was to just split the MOV and non-MOV paths with completely
separate checks. The "else" path in this commit is basically the old
code with the BRW_OPCODE_MOV special case removed.
The new MOV code further splits into "destination of scan_inst is float"
and "destination of scan_inst is integer" paths. For each case I
enumerate the rules that I belive apply. For the integer path, only the
"Z or NZ" rules are listed as only NZ is currently allowed (hence the
conditional_mod assertion in that path). A later commit relaxes this
and adds the rule.
The new rules slightly relax one of the previous rules. Previously the
sizes of the MOV destination and the MOV source had to be the same. In
some cases now the sizes can be different by the following conditions:
- Floating point to integer conversion are not allowed.
- If the conversion is integer to floating point, the size of the
floating point value does not matter as it will not affect the
comparison result.
- If the conversion is float to float, the size of the destination
must be greater than or equal to the size of the source.
- If the conversion is integer to integer, the size of the destination
must be greater than or equal to the size of the source.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
Of particular interest are the tests where the MOV performs a type
conversion. If the restriction on conditional modifier for a MOV is
ever relaxed, some of these cases must still be disallowed.
v2: s/NZ/Z/ in one of the comments. Notice by Marcin.
Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12045>
==244108== Conditional jump or move depends on uninitialised value(s)
==244108== at 0x48498D5: bcmp (vg_replace_strmem.c:1129)
==244108== by 0x1C37B7DD: radv_bind_dynamic_state (radv_cmd_buffer.c:237)
==244108== by 0x1C388027: radv_CmdBindPipeline (radv_cmd_buffer.c:4794)
==244108== by 0x14E9C01E: bool update_gfx_pipeline<true>(zink_context*, zink_batch_state*, pipe_prim_type) (zink_draw.cpp:406)
==244108== by 0x14E9AAB9: void zink_draw_vbo<(zink_multidraw)1, (zink_dynamic_state)1, (zink_dynamic_state2)1, (zink_dynamic_vertex_input)1, true>(pipe_cont>
==244108== by 0x14B017EB: tc_call_draw_single (u_threaded_context.c:3033)
==244108== by 0x14AF9C0E: tc_batch_execute (u_threaded_context.c:190)
==244108== by 0x14AFA24F: _tc_sync (u_threaded_context.c:341)
==244108== by 0x14B006E7: tc_texture_subdata (u_threaded_context.c:2549)
==244108== by 0x14238F8C: st_TexSubImage (st_cb_texture.c:2134)
==244108== by 0x14239931: st_TexImage (st_cb_texture.c:2363)
==244108== by 0x1453698A: teximage (teximage.c:3154)
==244108== by 0x1453698A: teximage_err (teximage.c:3181)
==244108== by 0x145388BD: _mesa_TexImage2D (teximage.c:3252)
==244108== by 0x5E88D4: ??? (in /home/zmike/src/piglit/tesseract/bin_unix/linux_64_client)
==244108== by 0x5E9527: ??? (in /home/zmike/src/piglit/tesseract/bin_unix/linux_64_client)
==244108== by 0x5E9B72: ??? (in /home/zmike/src/piglit/tesseract/bin_unix/linux_64_client)
==244108== by 0x5F1092: ??? (in /home/zmike/src/piglit/tesseract/bin_unix/linux_64_client)
==244108== by 0x5F10AC: ??? (in /home/zmike/src/piglit/tesseract/bin_unix/linux_64_client)
==244108== by 0x48CC66: ??? (in /home/zmike/src/piglit/tesseract/bin_unix/linux_64_client)
==244108== by 0x48DDC7: ??? (in /home/zmike/src/piglit/tesseract/bin_unix/linux_64_client)
==244108== by 0x40D525: ??? (in /home/zmike/src/piglit/tesseract/bin_unix/linux_64_client)
==244108== by 0x4FF7B74: (below main) (in /usr/lib64/libc-2.33.so)
==244108== Uninitialised value was created by a stack allocation
==244108== at 0x14ECDF55: zink_create_gfx_pipeline (zink_pipeline.c:53)
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12618>
The lowered LS and NGG stages use local_invocation_index and they
can benefit from the unsigned upper bound because they can emit a
less expensive integer multiplication instruction.
This was working in the past, but accidentally borked by a refactor.
Fossil DB changes on Sienna Cichlid:
Totals from 956 (0.74% of 128647) affected shaders:
CodeSize: 2354172 -> 2344712 (-0.40%)
Instrs: 434359 -> 434327 (-0.01%)
Latency: 1883949 -> 1876814 (-0.38%)
InvThroughput: 762638 -> 757405 (-0.69%)
Fossil DB changes on Sienna Cichlid (with NGGC enabled):
Totals from 57873 (44.99% of 128647) affected shaders:
CodeSize: 155844192 -> 155607064 (-0.15%)
Instrs: 29799184 -> 29799152 (-0.00%)
Latency: 130959764 -> 130814224 (-0.11%); split: -0.11%, +0.00%
InvThroughput: 21100300 -> 20928635 (-0.81%); split: -0.81%, +0.00%
Fixes: 8af6766062
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12558>
Consider the following sequence in a shader:
b = p_extract a
c = v_mad_u32_u16 b, X, 0
The optimizer applies extract, resulting in:
c = v_mad_u32_u16 a, X, 0 (correct)
Then it mistakenly turns that into:
c = v_mul_u32_u24 a, X, 0 (incorrect)
In this case, the p_extract is applied to v_mad_u32_u16 by
apply_extract. After this, we can no longer be sure that
the operands are still 16 or 24-bit, so we have to remove
this flag.
No Fossil DB changes.
Fixes: 54292e99c7
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12558>
Mesh shader outputs are either:
- non-array builtins
- array builtins that are either per-primitive or per-vertex
- user-defined outputs that must be either per-primitive or per-vertex
So we can identify any array output as "arrayed" for the purposes of
I/O lowering.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10600>
Per-primitive is similar to per-vertex attributes, but applies to all
fragments of the primitive without any interpolation involved.
Because they are regular input and outputs, keep track in shader_info
of which I/O is per-primitive so we can distinguish them after deref
lowering. These fields can be used combined with the regular
`inputs_read`, `outputs_written` and `outputs_read`.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10600>
Previously, the optimization to use v_mul_lo_u16 for
32bit multiplications was done in instruction_selection.
This was moved to the optimizer to ease some case distinctions.
The mixed results are due to increased use of SDWA.
Totals from 2616 (1.74% of 150170) affected shaders: (GFX10.3)
VGPRs: 143888 -> 143872 (-0.01%); split: -0.02%, +0.01%
CodeSize: 5604032 -> 5604080 (+0.00%); split: -0.01%, +0.01%
Instrs: 1086798 -> 1083915 (-0.27%); split: -0.27%, +0.01%
Latency: 8215793 -> 8213023 (-0.03%); split: -0.10%, +0.07%
InvThroughput: 20765157 -> 20773766 (+0.04%); split: -0.02%, +0.06%
VClause: 35256 -> 35260 (+0.01%); split: -0.02%, +0.03%
SClause: 29021 -> 29024 (+0.01%); split: -0.00%, +0.01%
Copies: 74163 -> 74306 (+0.19%); split: -0.05%, +0.24%
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11678>
This partially reverts commit 4d9acfa533.
The original patch said:
"Python 3 handles unicode strings by default, so we can drop all that."
But this breaks building on RHEL 7 (or similiar) since python3 support
on is much more limited than newer distros. Backporting all the needed
python 3 libraries to EL7 is a pretty big task, and isn't very easy to
maintain.
For workstation purposes, we need the AMD MM/GL driver building on RHEL
7, so only src/util/driconf_static.py needs to be reverted.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Jeremy Newton <Jeremy.Newton@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12549>
With this code, we end up generating code such as:
if (!strcmp(extensions[i].extensionName, "VK_KHR_maintenance1")) {
if (VK_MAKE_VERSION(1,2,0) >= screen->vk_version) {
info->have_KHR_maintenance1 = true;
} else {
info->have_KHR_maintenance1 = true;
}
}
That's clearly nonsense, as it does the same thing in the true and false
case. So let's instead try to walk the Vulkan versions up to the one
we're using in a separate pass, and add all extensions that were made core
in that version.
CID: 1473289
Reviewed-by: Hoe Hao Cheng <haochengho12907@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12593>
nir_src_as_const_value can return null pointers, and in other places we
at least assert for this. So let's do that here as well, which makes
Coverity a bit less paranoid.
While we're at it, avoid duplicating the nir_src_as_const_value call to
the same source.
CID: 1444291
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12594>
The documentation for ASSERTED in macros.h says:
> Use ASSERTED to indicate that an identifier is unused outside of an `assert()`,
> so that assert-free builds don't get "unused variable" warnings.
We're using this variable outside of assert, so this shouldn't apply
here.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12594>
nir_src_as_const_value also checks if the src is const, and not
checking that it returned null makes Coverity go paranoid thinking we
could dereference a null-pointer. But because it's slightly better to
check once than to check twice, let's rewrite this to avoid the
double-check, making it obvious what's going on here.
CID: 1485624
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12594>
This NULL-check makes Coverity paranoid because we just dereferenced the
pointer a few lines above.
But we never call this function with a NULL-pointer here, so the NULL
check isn't needed. Let's just remove it, to calm Coverity down a bit.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12559>
We do this in the other pipe_buffer_map_range failure case, so it makes
sense that we need to do it here as well. If we don't, we'll end up
taking a crash in the check_query_results function, which will
dereference that pointer.
We also need to unmap the buffer if we fail, otherwise we'll leak.
CID: 1475925
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12559>
We're checking if pctx is null here, but that can't be true. If it
could, then the code that follows would have immediately crashed.
A quick peek at other drivers seems to indicate that this is a safe
assumption.
CID: 1474410, 1474554
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12559>
We can't do any of this logic if key is NULL, because that means we'll
dereference memory close to a NULL-pointer.
While we're at it, add some asserts to the zink_fs_key and zink_vs_key
functions who would otherwise be responsible for giving us invalid
non-null pointers out of null-pointers.
CID: 1475973, 1475983
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12559>
We currently cause the following scary warning to be printed on
start-up for *every* application regardless if that feature is being
used or not when run on top of ANV:
> WARNING: Some incorrect rendering might occur because the selected
> Vulkan device (Intel(R) UHD Graphics 620 (KBL GT2)) doesn't support
> base Zink requirements: line_rast_feats.stippledRectangularLines
> line_rast_feats.stippledSmoothLines
There's no need to scare the users about this, as most applications
don't care about these combinational features. So let's instead emit a
warning when these features are attempted (but failed) to be used
instead.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12587>
This reverts commit 336dea90f0.
This change was incorrect for two reasons:
1. We already initialize this field on line 334
2. Unconditionally setting this to
VK_BORDER_COLOR_FLOAT_TRANSPARENT_BLACK breaks rendering with e.g
opaque white borders, because we've already matched those to a
non-custom enum value first.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12591>
Before PS waves are launched, PS inputs are moved from PC to LDS
and the corresponding part of the PC is deallocated.
Each PS input occupies 3 * vec4 (3 * 16 = 48 bytes) of LDS space.
See Figure 10.3 in the GCN3 ISA manual.
These limit occupancy the same way as other stages' LDS usage does.
Note that PS can request additional LDS space via EXTRA_LDS_SIZE,
so that also must be taken into account here.
No Fossil DB changes.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12517>
When VK_DESCRIPTOR_POOL_CREATE_FREE_DESCRIPTOR_SET_BIT is not used to
create the pool, set allocation is guaranteed to not return
VK_ERROR_FRAGMENTED_POOL, and we can safely move set allocation to async
after doing resource tracking in the driver.
Enable after fully tested with assert(false) in the failure case.
Tested with:
- dEQP-VK.api.descriptor*
- dEQP-VK.api.object_management.*
- dEQP-VK.binding_model.descriptor*
- dEQP-VK.descriptor_indexing.*
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12501>
I915_FORMAT_MOD_Y_TILED_CCS was already disabled for Xe+ due to a change
in the CCS layout. Disable the remaining Y-tiled modifiers since XeHP
lacks support for Y-tiling.
Rework:
* Nanley: Include Anuj's fix for the non-CCS modifiers.
* Nanley: Split out Anuj's fix into a separate if statement.
* Nanley: Rewrite commit message.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12132>
We're going to start asserting for valid halign/valign values during
surface state emission. Pre-SKL, isl_surf_get_uncompressed_surf creates
uncompressed surfaces with invalid halign/valign values - 1x1. Fix this
by replacing the call to isl_surf_get_image_surf with isl_surf_init,
passing in the uncompressed format up-front.
As we're no longer using isl_surf_get_image_surf, we also need to get
the x and y offset of the image ourselves. Instead of getting a
sample-based offset, then converting to elements later on, we use
isl_surf_get_image_offset_B_tile_el to get the offset in elements
up-front.
With the above two changes, the generic code after the else-block is no
longer needed for the single-layer-view code path. We move it and
specialize it to the if-block (which is executed SKL+ and handles
multi-layer views).
Cc: mesa-stable
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12132>
On XeHP, NPOT and POT formatted surfaces will use different image
alignment units when emitting surface states. When BLORP fakes an RGB
image as RED, update the image alignment to prevent assert failures when
emitting surface states.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12132>
Implement the new XeHP alignment rules for surface layout.
RENDER_SURFACE_STATE objects still need updating, but that's left for a
separate commit.
Rework:
* Nanley: Include Sagar's VALIGN fix for D16_UNORM.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12132>
XeHP defines new tiling formats, Tile4 and Tile64. They are needed in
order to support depth/stencil surfaces and multisampling. Create new
ISL enums and define some initial tiling information in order to enable
them later on.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12132>
If the z components here contain negative values, we'll end up with the
wrong maximum value.
This updated equation is taken from the D3D11 functional spec (section
15.10 Depth Bias), which is a bit more clear than the OpenGL spec.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12443>
The formula for calculating these two values seems to depend on
tess_use_shared, ie. a6xx_gen3 and a6xx_gen4 match. The existing
calculation matches a6xx_gen1 and a6xx_gen2.
The new formula is based on traces varying # of output (from VS)
varyings from (1..31)*vec4 and vertices from (1..31) and coming up
with something that matches the blob. Once hs_input_size*4 divided
by tcs_vertices_out goes above 64, this deviates a bit from the
blob, but AFAICT it is safe to pick a larger values.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12497>
The hardware can handle much larger textures than we allowed. The game
"Cathedral" requires larger textures for some bizarre reason. Raise the
limit so the game runs, syncing MAX_MIP_LEVELS, the comments, and the CAPs.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Closes: #5203
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12312>
We can't append instructions following a return/halt instruction
because the control flow helpers will modify the successor of the
block containing the return/halt. And the NIR validator enforces that
the return/halt must have the end of the function as successor.
This tends to happen following lower_shader_calls lowering which
inserts halts. This probably doesn't prevent the optimization, it'll
just happen in one of the return shaders after the halt has been
removed.
v2: Move prev block ending check earlier in the function (Daniel)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12506>
Use Piglit's replay profile to measure and store the time that frames
take to render in the GPU.
This job won't run automatically in regular pipelines, but will be
triggered automatically by a script for every successful pre-merge
pipeline.
This is because we want to generate performance data for every relevant
commit merged in main, but we don't want to keep a device busy during
the pre-merge run.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12236>
v2 (Ivan): Add missing capability enum handling.
v3 (idr): Properly handle cases where dest_size != 32.
v4 (idr): Rewrite most of the error checking to use vtn_fail_if. Use
nir_ssa_def with vtn_push_nir_ssa instead of vtn_ssa_value with
vtn_push_ssa_value. All suggested by Jason. Massive rewrite of the
handling of packed 4x8 saturating opcodes. Based on some observations
made by Jason.
v5 (idr): Remove some debugging cruft accidentally added in v4. Noticed
by Jason.
v6: Emit packed versions of vectored instructions when possible.
Suggested by Jason.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12142>
v2: Fix copy-and-paste bugs in lowering patterns.
v3: Add has_sudot_4x8 flag. Requested by Rhys.
v4: Since the names of the opcodes changed from dp4 to dot_4x8, also
change the names of the lowering helpers. Suggested by Jason.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12142>
v2: Add and modify patterns to let constant folding do better.
v3: Remove '(is_not_zero)' from the patterns that try to combine
addends. I honestly don't know why I had it there in the first place,
and nothing in my deep git logs could help clue me in. Noticed by
Alyssa. Remover patterns that detect open-coded udot_4x8. Suggested by
Alyssa and Jason. Add missing sudot_4x8 patterns.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12142>
Six opcodes are added: sdot_4x8_iadd, udot_4x8_uadd, sudot_4x8_iadd,
sdot_4x8_iadd_sat, udot_4x8_uadd_sate, and sudot_4x8_iadd_sat. These
represent the combinations of integer dot-product and add that operate
on packed source vectors. That is, the four 8-bit values for each
vector is stored in a single 32-bit integer.
Some hardware may prefer to operate on unpacked byte vectors. When such
hardware comes to Mesa, we'll have to figure out how to name things.
v2: Add nir_op_iudp4a and nir_op_iudp4a_sat instructions. These opcodes
are not 2-source commutative.
v3: Rename all opcodes to be more like some existing 4x8 opcodes.
Suggested by Timur. Change type of packed vector sources to uint32,
change types of constant folding variables to have explicit size, and
delete some extra casts. All suggested by Jason.
v4: Fix typo previously noticed by Alyssa but missed in v2.
v5: Add has_sudot_4x8 flag. Requested by Rhys.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12142>
Without this, lowered saturating ALU instructions would only clamp to
the range of the new type instead of the range of the old type.
v2: Use nir_iclamp. Suggested by Jason. Use new
u_{int,uint}N_{min,max}() helpers.
Fixes: 090e282407 ("nir: Add a saturated unsigned integer add opcode")
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12142>
This ensures each context can have a separate batch writing a resource
and we don't race trying to flush each other's batches. Unfortunately
the extra hash table operations regress draw-overhead numbers by about
8% but I'd rather eat the overhead and have an obviously correct
implementation than leave known buggy code in tree.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12528>
ralloc is not thread safe, so we cannot use a pipe_screen as a ralloc
context unless we lock the screen. The allocation patterns for resources
are trivial, so just use malloc/calloc/free directly instead of ralloc.
This fixes a segfault in:
dEQP-EGL.functional.sharing.gles2.multithread.random.images.copytexsubimage2d.1
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12525>
Without a lock, two threads may bind the same shader CSO simultaneously,
allocate the same variant simultaneously, and then race each other in
the compiler. This manifests in various ways, most commonly failing the
assertion that UBO pushing has only run once. The simple_mtx_t solution
is used in Iris. Fixes the crash in:
dEQP-EGL.functional.sharing.gles2.multithread.simple.buffers.bufferdata_render
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12525>
Use the new deqp-runner suite support to combine our dEQP-GLES2,
dEQP-GLES3, and dEQP-GLES31 jobs into a single job. This simplifies load
balancing, enabling us to expand our test coverage without impacting
wall clock time.
With the new infrastructure in place, we add KHR-GLES* jobs for Mali
G52. This would have caught some recent regressions. Once we hit
conformance it's essential we remain conformant.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12313>
And in vn_ring_write_buffer as well, to fix the assert in
vn_ring_write_buffer.
The ring code uses 32-bit unsigned integers and relies on that their
overflow/underflow behavior is well-defined. When ring->shared.head is
about to overflow and ring->cur has overflowed, this expression
ring->cur + size - vn_ring_load_head(ring)
gives an incorrect result when size is 64-bit.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12494>
We already have the infrastructure for querying shader program properties
without syncing. This just uses it. _mesa_error_glthread_safe sets a GL
error from the producer thread.
This decreases CPU overhead for viewperf/snx.
Reviewed-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12490>
We have no reason to report a subpixel precision of 4 for lines; in fact
LLVMpipe uses 8 subpixel bits for lines, similar to other primitives.
But let's use the pipe-cap for this instead of hard-coding it.
Fixes: 9fbf6b2abf ("lavapipe: implement VK_EXT_line_rasterization")
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12277>
Fix defect reported by Coverity Scan.
Same on both sides (CONSTANT_EXPRESSION_RESULT)
pointless_expression: The expression inst->qpu.flags.auf !=
V3D_QPU_UF_NONE || inst->qpu.flags.auf != V3D_QPU_UF_NONE does not
accomplish anything because it evaluates to either of its identical
operands, inst->qpu.flags.auf != V3D_QPU_UF_NONE.
Fixes: 3f2c54a27f ("broadcom/compiler: rewrite partial update liveness tracking")
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12385>
This performs the polygon offset addition after interpolation, which
prevents floating-point cancellation issues completely.
This does mean that we have to perform a single floating-point addition
more per fragment than before, unless we also want to spend a bit in
the fragment-shader variant key to avoid this.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12442>
The OpenGL 4.6 compatibility spec, section 14.6.5 (Depth Offset) says
the following:
> For fixed-point depth buffers, fragment depth values are always
> limited to the range [0,1] by clamping after offset addition is
> performed. Fragment depth values are clamped even when the depth
> buffer uses a floating-point representation.
So we need to properly clamp the result here.
This fixes the following dEQP failures, that the CI has missed:
- dEQP-GLES3.functional.polygon_offset.default_result_depth_clamp
- dEQP-GLES3.functional.polygon_offset.default_factor_1_slope
- dEQP-GLES3.functional.polygon_offset.fixed24_result_depth_clamp
- dEQP-GLES3.functional.polygon_offset.fixed24_factor_1_slope
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12442>
The current code overwrote the original view which meant if we
had to reemit a surface the second emit would be wrong.
This fixes cubemaps on gm45 and maybe some issues with 3D textures
elsewhere.
Fixes: f3630548f1 ("crocus: initial gallium driver for Intel gfx 4-7")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12514>
Commit 3a772be026 ("freedreno: Add perfetto renderpass support")
uses C++17 init-statement feature.
GCC
../src/gallium/drivers/freedreno/freedreno_perfetto.cc: In lambda function:
../src/gallium/drivers/freedreno/freedreno_perfetto.cc:148:11: warning: init-statement in selection statements only available with ‘-std=c++17’ or ‘-std=gnu++17’
148 | if (auto state = tctx.GetIncrementalState(); state->was_cleared) {
| ^~~~
Clang
../src/gallium/drivers/freedreno/freedreno_perfetto.cc:148:11: warning: 'if' initialization statements are a C++17 extension [-Wc++17-extensions]
if (auto state = tctx.GetIncrementalState(); state->was_cleared) {
^
Intel C++ Compiler
../src/gallium/drivers/freedreno/freedreno_perfetto.cc(148): error: expected a ")"
if (auto state = tctx.GetIncrementalState(); state->was_cleared) {
^
Fixes: 3a772be026 ("freedreno: Add perfetto renderpass support")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5193
Suggested-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Acked-by: Rob Clark <robdclark@chromium.org>
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12293>
If a user attempts to run Panfrost on an unsupported GPU (e.g. Mali
T604), Panfrost will refuse to load and will destroy the screen
immediately, allowing for a graceful fallback to a software rasterizer.
However, the screen destroy code calls a screen_destroy function in the
GenXML vtbl -- and this function is still NULL when the allowlist is
checked. This manifests as crashes on unsuported GPUs.
Issue tracked down with Icecream95's mad Ghidra skills.
Closes: #5269
Fixes: 88dc4db6be ("panfrost: Init/destroy blitter from per-gen file")
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reported-by: Icecream95 <ixn@disroot.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12512>
This commit does several things:
* Unify code common to several drivers by evaluating INTEL_NO_HW within
intel_get_device_info_from_fd (suggested by Jordan).
* For drivers that keep a copy of the intel_device_info struct, a
separate copy of the no_hw field is now unnecessary. Remove them.
* Minimize kernel queries when INTEL_NO_HW is true. This is done for
code simplification, but we may find reason to undo this later on.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12007>
This is a presumed erratum workaround. Fixes INSTR_INVALID_PC faults on
some draw_buffers_indexed.* cases on Midgard, where a blend shader is
required to pack RT n > 0.
Backport the workaround from the GL driver. The helper is now in common
code for panvk to use as well; it has the same bug.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11383>
Fixes an invalid read caught by valgrind when there is a hole in the
valid render target mask:
==6749== Conditional jump or move depends on uninitialised value(s)
==6749== at 0x5E88EC0: panfrost_prepare_fs_state (pan_cmdstream.c:417)
==6749== by 0x5E88EC0: panfrost_emit_frag_shader (pan_cmdstream.c:501)
==6749== by 0x5E88EC0: panfrost_emit_frag_shader_meta (pan_cmdstream.c:573)
==6749== by 0x5E88EC0: panfrost_update_state_fs (pan_cmdstream.c:2593)
==6749== by 0x5E8B0BF: panfrost_direct_draw (pan_cmdstream.c:2839)
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Fixes: a124c47b9f ("panfrost: Fix NULL derefs in pan_cmdstream.c")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11383>
When freeing a buffer, we may return a non-idle buffer to the cache,
which means we cannot unmap aux entries at that time. Instead, we
defer unmapping the stale aux entry until we reuse a BO from the cache.
Unfortunately, this can lead to a recursive locking issue:
1. intel_aux_map_add_mapping wants to set up a new aux entry
It takes the intel_aux_map_context::mutex lock, then calls:
add_mapping -> get_aux_entry -> add_sub_table -> add_buffer ->
intel_aux_map_buffer_alloc -> iris_bo_alloc
2. iris_bo_alloc tries to allocate a BO from the cache, doing:
alloc_bo_from_cache -> intel_aux_map_unmap_range ->
intel_aux_unmap_range
...which then tries to take the intel_aux_map_context::mutex lock.
But it is already locked.
One solution would be to rework the aux map handling code to allocate
BOs without holding its lock, but that looks to be painful. Another
is to make the lock recursive, but we try and avoid that. A third
option wuold be to add a BO_ALLOC flag that makes alloc_bo_from_cache
skip any buffers with aux_map_address != 0 so we don't have to unmap,
making the less cache effective but fixing the recursive lock.
A fourth option is to simply bypass the BO cache altogether for the
buffers that hold the aux map itself. Allocating new BOs for the aux
tables should be relatively rare, so there's probably not a lot of
benefit in using the BO cache.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5191
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12420>
With hw devices, when you submit a present, implicit sync will
make sure the work submitted to the gpu on the client will end
up happening before the present work submitted on the server.
However with sw paths there is no real GPU, the lavapipe fake
GPU thread is client side only and presenting is done directly
from the pixmap (or later shared pixmap). In order for this to
make sense the wsi common code should wait for the fence on the
image before queueing the submit to the server so that all
client works has been flushed to the pixmap before the copy or
present operation is submitted.
Fixes: 8004fa9c95 ("vulkan/wsi: add sw support. (v2)")
Acked-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12502>
When rasterizing legacy-lines, OpenGL defines the width as being an
extrusion along the minor axis, repeating varyings. While the spec
*does* allow for an alternative method that matches our current results,
the OpenGL ES CTS doesn't allow these results even if OpenGL ES has the
same wording of an alternative method.
This is technically speaking a bug in the OpenGL ES CTS, but it seems
like nobody else is using the alternative formulation, at least not
while passing the OpenGL ES CTS. On top of this, the OpenGL specification
explicitly lists the extrusion results as the preferred method.
So it seems like a good idea for us to do this the way the OpenGL
specification prefers regardless; it's going to give less surprising
results to applications, and it's helping us pass some tests.
This math to set these up would "trivially" be:
dx = (dx * dx + dy * dy) / dx
dy = 0
and:
dy = (dx * dx + dy * dy) / dy
dx = 0
...but since we've already calculated dxdy, we can reformulate this to
save a division.
This fixes the following dEQP test-cases:
- dEQP-GLES2.functional.rasterization.interpolation.basic.line_loop_wide
- dEQP-GLES2.functional.rasterization.interpolation.basic.line_strip_wide
- dEQP-GLES2.functional.rasterization.interpolation.basic.lines_wide
- dEQP-GLES2.functional.rasterization.interpolation.projected.line_loop_wide
- dEQP-GLES2.functional.rasterization.interpolation.projected.line_strip_wide
- dEQP-GLES2.functional.rasterization.interpolation.projected.lines_wide
- dEQP-GLES3.functional.rasterization.fbo.rbo_singlesample.interpolation.lines_wide
- dEQP-GLES3.functional.rasterization.fbo.texture_2d.interpolation.lines_wide
- dEQP-GLES3.functional.rasterization.interpolation.basic.line_loop_wide
- dEQP-GLES3.functional.rasterization.interpolation.basic.line_strip_wide
- dEQP-GLES3.functional.rasterization.interpolation.basic.lines_wide
- dEQP-GLES3.functional.rasterization.interpolation.projected.line_loop_wide
- dEQP-GLES3.functional.rasterization.interpolation.projected.line_strip_wide
- dEQP-GLES3.functional.rasterization.interpolation.projected.lines_wide
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11315>
Fixes framebuffer_fetch and blend_equation_advanced dEQP tests on v6.
v2: Use clause dependencies rather than comparing the message type
v3: Shift the BIFROST_SLOT_* constants before using them as a mask
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12375>
Two related changes:
- in tu_device.c:tu_CreateDevice we need to free both pointers in the
teardown path after tu_bo_finish(global_bo), which uses the pointers.
They are allocated in the first call to tu_bo_init(), which happens
when global_bo is allocated.
- in tu_drm.c:tu_bo_init we need to free bo_list if the bo_idx
allocation fails. Convert to the goto teardown pattern as well.
Fixes the following dEQP-VK tests:
dEQP-VK.api.device_init.create_instance_device_intentional_alloc_fail
dEQP-VK.api.object_management.alloc_callback_fail.device
dEQP-VK.api.object_management.alloc_callback_fail.device_group
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12481>
Apparently, CLPER_V7 is missing from Mali G31, but CLPER_V6 works. Fixes
INSTR_INVALID_ENC faults and failures in
dEQP-GLES3.functional.shaders.derivate.* on Dvalin.
Technically not an errata but an implementation difference. I suspect
Mali G51 will need this as well, should we ever allowlist it.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12478>
ST_TILE lets us specify an explicit sample, whereas BLEND replicates to
all samples. This fully fixes the interaction between blend shaders and
multisampling on Bifrost, manifesting as
dEQP-GLES3.functional.fragment_ops.random.* failures with the
configuration rgba8888d24s8ms4.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12478>
This varies the sample ID value, which will be used in the next commit.
This is less complicated than keying blend shaders to the content of
this flag and trying to make mega blend shaders covering all samples at
once ... complexity I'd rather not think about right now. The DDK does
it this way.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12478>
Use the explicit sample mode and set the sample ID in the pixel indices
structure to the current sample ID. This fixes tilebuffer loads in blend
shaders on multisampled framebuffers.
Make sure the new routine is broken out to a helper for use with ST_TILE
in the next commit.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12478>
Although it is passing all of dEQP-GLES31, it is failing a few
KHR-GLES31.* tests. It also has performance issues at the moment. Invert
the existing noindirect debug flag to become a indirect debug flag. Set
this flag for dEQP-GLES31 CI on G52, to make sure the code doesn't bit
rot on the hope someone will pick this up later on.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12478>
struct wsi_wl_image is only used as member of the swapchain, and during
the swapchain creation the image is already initialized to zero. So we
have no problems with members of the image being used uninitialized.
But for consistency, memset the members of this struct to zero in
wsi_wl_image_init(). This can help to avoid problems in the future.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12451>
In wsi_wl_surface_create_swapchain() we have a piece of code to init
some members of the chain to 0, in order to allow us to call
wsi_wl_swapchain_destroy() for cleanup.
Instead, we can use vk_zalloc() to allocate the chain, as it initializes
all members of the struct to zero. This help us to avoid problems when
people add new members to the struct and forget to initialize them.
Also, it makes the code look better.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12451>
I never really implemented this properly, because I wasn't aware of the
clusters when doing the original pipeline barrier implementation. It
turns out that the Vulkan stages we get as part of the barriers are
actually good for something, because it turns out that the pipeline
state is split into stages, so earlier stages can run ahead of later
stages and sometimes we need to wait when an earlier stage depends on
the result of a later stage. This happens most often whenever a shader
reads the result of a color/depth attachment write, because attachment
writes happen in a logically later stage. However this could also happen
for a FS -> VS dependency.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12475>
Implement the workarounds in anv and iris instead.
Before this commit, ISL unconditionally modified workaround registers
while filling out depth stencil state. To account for this, drivers
unconditionally stalled prior to emitting depth stencil packets. This
hurt performance.
By having the drivers perform the workarounds, they can choose when to
modify the relevant registers. The drivers now avoid emitting the
workaround for NULL depth buffers. This reduces stalls and leads to
better performance.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> (the ISL/Anv bits)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (the Iris bits)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11454>
mul.s24/u24 always return 32b result regardless of its sources size,
hence we cannot guarantee the high 16b of dst being zero or sign extended.
Fixes cts tests on a650:
dEQP-VK.spirv_assembly.type.scalar.i16.mul_test_high_part_zero_*
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12471>
Support for spilling shared registers to normal registers is still TODO.
There are also several improvements to be made, like rematerialization.
Note, there is one behavior change to register pressure accounting: we
now include half registers in the current full pressure directly in
mergedregs mode, rather than adding the max half pressure to the max
full pressure afterwards, which might result in lower calculated max
pressure in some cases with half registers. This is needed for spilling,
since we need to make sure the total pressure including half registers
is below the maximum at each instruction. Because the entire pass is
rewritten, including the register pressure calculating parts, it didn't
seem worth it to separate out this change.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12033>
This was just wrong - we need to check against the entire register file,
and we need to include removed full regs even if the register we're
trying to insert is a half-reg, or else we could run out of space when
reinserting full regs after it. There does need to be an additional
check so that we don't try to insert a half-reg beyond the half-reg
limit, but that has to happen in addition to the normal check.
This fixes KHR-GLES31.core.arrays_of_arrays.InteractionArgumentAliasing6
once spilling is added.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12033>
RA uses this to pop and then reinsert intervals when shuffling around
registers. For spilling, we want to remove the interval and also mark
all its descendants as removed. Since "remove_all" sounds more like the
latter, rename the old "remove_all" to "remove_temp". "remove_all" was
already exposed in ir3_ra.h, so there's no need to add it.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12033>
It can happen that we create an enormous merge set, even larger than the
entire register file, in which case find_best_gap() would loop
infinitely. This seems to be triggered more often with
IR3_SHADER_DEBUG=spillall, since it actually happened with a CTS test.
Just bail out in that case.
Fixes: 0ffcb19b9d ("ir3: Rewrite register allocation")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12033>
When we mark live-through sources that are merged with the destination
as killed, we kept the bitsets in sync, but we forgot to keep them in
sync when unmarking them after allocating the destination. The result
was that "available" wasn't correct for any instruction afterwards. This
resulted in a bad register allocation with IR3_SHADER_DEBUG=spillall for
a dEQP-VK test.
While we're changing this, use ra_foreach_src().
Fixes: 0ffcb19b9d ("ir3: Rewrite register allocation")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12033>
Otherwise when an interval is removed and then re-inserted it could
have an invalid/corrupted parent link and child tree. I think RA
happened to never do this, but spilling will.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12033>
Floats have much better precision close to zero than close to one, so
let's make sure we compute an interpolation factor that goes in the
direction that discards the fewest bits.
This makes a big difference when interpolating from very small to very
large values for screen-space positions.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12355>
By checking the output images against the reference ones on the failed
trace jobs, I looked for artifacts via naked eye and image diffs. No
significant change was found. So the trace produced by the failed jobs
can be considered valid.
Updated devices' traces:
* Intel Comet Lake: iris-cml-traces
* Intel Gemini Lake: iris-glk-traces
* Intel Kaby Lake: iris-kbl-traces
* Intel Whiskey Lake: iris-whl-traces
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12394>
CTS draw_indirect usage of TFB output was flaking due to the TFB writes
possibly not having completed. Since GL TFB doesn't require any other
barrier between TFB and use of the BO (as seen by the CTS not emitting any
memory barrier), we have to do it ourselves.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12457>
There are a bunch of optimizations that are broken when DPP is involved.
fossil-db (Sienna Cichlid):
Totals from 100 (0.07% of 150170) affected shaders:
CodeSize: 325204 -> 325192 (-0.00%); split: -0.06%, +0.05%
Instrs: 62773 -> 62664 (-0.17%); split: -0.18%, +0.00%
Latency: 295348 -> 295266 (-0.03%); split: -0.03%, +0.00%
InvThroughput: 73990 -> 73946 (-0.06%); split: -0.06%, +0.01%
Copies: 1650 -> 1609 (-2.48%); split: -2.55%, +0.06%
PreSGPRs: 3554 -> 3520 (-0.96%)
Fossil-db changes are probably because v_sub_f32_dpp(v_mul_f32) is no
longer being combined into MAD and then split back into separate
instructions.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11924>
I haven't gone through every test (particularly ones I think are loop
unrolling or instruction-count-related ones I think), but this gives a
better picture of what's going on in this driver.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12436>
Prior to this commit, the stride, offset and modifier were fetched
via WINSYS_HANDLE_TYPE_KMS. However we can't make such a query
succeed if the buffer couldn't be imported to the KMS device.
Instead, implement the resource_get_param hook to allow users to
fetch this information without WINSYS_HANDLE_TYPE_KMS.
A tiny helper function is introduced to compute the modifier of a
resource.
Signed-off-by: Simon Ser <contact@emersion.fr>
Fixes: 7bcb223639 ("v3d, vc4: Fix dmabuf import for non-scanout buffers")
Reported-by: Roman Stratiienko <r.stratiienko@gmail.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12370>
Prior to this commit, the stride, offset and modifier were fetched
via WINSYS_HANDLE_TYPE_KMS. However we can't make such a query
succeed if the buffer couldn't be imported to the KMS device.
Instead, implement the resource_get_param hook to allow users to
fetch this information without WINSYS_HANDLE_TYPE_KMS.
A tiny helper function is introduced to compute the modifier of a
resource.
Signed-off-by: Simon Ser <contact@emersion.fr>
Fixes: 7bcb223639 ("v3d, vc4: Fix dmabuf import for non-scanout buffers")
Reported-by: Roman Stratiienko <r.stratiienko@gmail.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12370>
Prior to this commit, the stride, offset and modifier were fetched
via WINSYS_HANDLE_TYPE_KMS. However we can't make such a query
succeed if the buffer couldn't be imported to the KMS device.
Instead, implement the resource_get_param hook to allow users to
fetch this information without WINSYS_HANDLE_TYPE_KMS.
Signed-off-by: Simon Ser <contact@emersion.fr>
Fixes: 4c092947df ("panfrost: fail in get_handle(TYPE_KMS) without a scanout resource")
Reported-by: Roman Stratiienko <r.stratiienko@gmail.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12370>
When this was rewritten to support Vulkan, we stopped initializing
file_max to -1 in the case of no inputs. This causes the draw module
to go down a needlessly pessimistic case, printing an error while we're
at it.
Fixes: 42b5cfdbd2 ("gallivm/nir: fix vulkan vertex inputs")
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12440>
On some GPUs when:
- depth bounds test is enabled
- depth test is disabled
- depth attachment uses UBWC in sysmem mode
GPU hangs. As a workaround we should enable z test. That's what blob
is doing for a630. And since we enable z test we should make it always pass.
Blob doesn't emit this workaround on a650 and a660. Untested on a640.
Fixes:
dEQP-VK.pipeline.extended_dynamic_state.two_draws_static.depth_bounds_test_disable
dEQP-VK.pipeline.extended_dynamic_state.two_draws_dynamic.depth_bounds_test_disable
dEQP-VK.dynamic_state.ds_state.depth_bounds_1
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12407>
The OpenGL 4.6 specification, section 14.5.2.1 (Line Stipple) says:
> The masking is achieved using three parameters: the 16-bit line
> stipple p, the line repeat count r, and an integer stipple counter s.
This is pretty clear that the stipple counter shouldn't carry fractional
parts. But we also don't really do anything useful with the fractional
part anyway, apart from skewing the third or later line-segments
Properly carrying over the fractional parts as the Vulkan specification
allows for rectangular lines is trickier than this and would require us
to use a shorter output-line at the start of the following
line-segments.
But let's just do what the OpenGL specification describes, and the
Vulkan specification allows for now.
This, combined with the following patch for the vulkan CTS makes the
last two rasterization-tests pass for me:
https://github.com/KhronosGroup/VK-GL-CTS/pull/279
Fixes the "spec/!opengl 1.1/linestipple/line strip" piglit-test.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12327>
Glue together all the GLES related jobs using the suites feature.
This allow us to reduce the total number of devices required, moving
some of them to help in other jobs, and the remaining free for other
pipelines in parallel.
Reviewed-by: Emma Anholt <emma@anholt.net>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12453>
Be able to inline uniforms in loop for unrolling it.
Nested loop/if is also supported.
Some example:
for (i = 0; i < count; i++)
...
uniform "count" will be inlined. But note this does not
make sure the loop will be unrolled (ie. count = 1000).
for (i = 0; i < count; i++)
for (j = init; j < 10; j++)
if (type == 2)
...
uniform "count", "init" and "type" will be inlined.
It is intentional to not be too aggressive to add uniforms
to avoid false positive case while be able to support most
common usage.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11950>
In b9c095cc2c ("panfrost: Rewrite the clear colour packing code"),
packing of clear colours was corrected to use the tilebuffer's
fractional bits, fixing dithering of the clear colour with formats like
RGB565. Unfortunately, that commit did so unconditionally. If the
framebuffer is dithered, but dithering is disabled at the time of
the clear, we would incorrectly dither the clear.
This is a regression, as the old (broken) code passed the relevant CTS
test. What's the catch? Depending on dither state, there are two
formulas to pack tilebuffer colours. We need to handle both. Fixes
KHR-GLES31.core.draw_buffers_indexed.color_masks.
Fixes: b9c095cc2c ("panfrost: Rewrite the clear colour packing code")
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12460>
Right now opcode_desc struct, used to define data for all the
operations to pack/unpack, include a version field. In theory that
could be used to check if we are retrieving a opcode valid for our hw
version, or to get the correct opcode if a given one changed across hw
versions, or just the same if it didn't change.
In practice that field was not used. So for example, if by mistake we
asked for an opcode defined at version 41, while being on version 33
hardware, we would still get that opcode description.
This commit fixes that, and as we are here we expand the functionality
to allow to define version ranges, just in case a given opcode number
and their description is only valid for a given range.
v2 (from Iago feedback):
* Fixed some comment typos
* Simplified filtering opcode method
* Rename filtering opcode method
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12301>
Right now there is a helper to get the opcode description from a
packed instruction, used on unpack related instructions. This commit
adds a helper that refactors the equivalent that is already in use on
pack related instructions.
Right now the helper is small, but we plan to extend it on following
commits in order to use the opcode description version field.
To avoid any possible confusion we rename the existing lookup helper.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12301>
* Remove one about waddr 6 being reserved, when at some point it
become NOP
* Fix one comment about reserved signals on v41 map, as 24 and 25
are in fact defined. This seems a C&P issue (see v40 map).
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12301>
A lot of CTS tests write a u8vec4 or an i8vec4 to an SSBO. This results
in a lot of shifts and MOVs. When that pattern can be recognized, the
individual 8-bit components can be packed much more efficiently.
v2: Rebase on b4369de27f ("nir/lower_packing: use
shader_instructions_pass")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9025>
Not only does this eliminate a bunch of unnecessary type converting
MOVs, but it can also enable some SWAR. The
dEQP-VK.spirv_assembly.type.vec3.i8.bitwise_xor_frag test does
something about like:
c = a.x ^ b.x;
d = a.y ^ b.y;
e = a.z ^ b.z;
After this change, it looks more like:
uint t = i8vec3AsUint(a) ^ i8vec3AsUint(b);
c = extract_u8(t, 0);
d = extract_u8(t, 1);
e = extract_u8(t, 2);
On Ice Lake, this results in:
SIMD8 shader: 41 instructions. 1 loops. 3804 cycles. 0:0 spills:fills, 5 sends
SIMD8 shader: 31 instructions. 1 loops. 2844 cycles. 0:0 spills:fills, 5 sends
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9025>
Emitting the instructions one by one results in two MOV instructions
that won't be propagated. By handling both instructions at once, a
single MOV is emitted. For example, on Ice Lake this helps
dEQP-VK.spirv_assembly.type.vec3.i8.bitwise_xor_frag:
SIMD8 shader: 49 instructions. 1 loops. 4044 cycles. 0:0 spills:fills, 5 sends
SIMD8 shader: 41 instructions. 1 loops. 3804 cycles. 0:0 spills:fills, 5 sends
Without "intel/fs: Allow copy propagation between MOVs of mixed sizes,"
the improvement is still 8 instructions, but there are more instructions
to begin with:
SIMD8 shader: 52 instructions. 1 loops. 4164 cycles. 0:0 spills:fills, 5 sends
SIMD8 shader: 44 instructions. 1 loops. 3944 cycles. 0:0 spills:fills, 5 sends
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9025>
This eliminates some spurious, size-converting moves. For example, on
Ice Lake this helps dEQP-VK.spirv_assembly.type.vec3.i8.bitwise_xor_frag:
SIMD8 shader: 56 instructions. 1 loops. 4444 cycles. 0:0 spills:fills, 5 sends
SIMD8 shader: 52 instructions. 1 loops. 4164 cycles. 0:0 spills:fills, 5 sends
v2: Condition two of the patterns on !options->lower_extract_byte.
Suggested by Lionel.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9025>
In the vec4 compiler, 8-bit types should never exist.
In the scalar compiler, 8-bit types should only ever be able to exist on
Gfx ver 8 and 9.
Some instructions are handled in non-obvious ways.
Hopefully this will save the next person some time.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9025>
GLX_ARB_create_context_profile has some clever language that sets the
default to core profile but silently degrades back to compat for pre-3.2
GLs. We can just do that, rather than track whether the user specified a
profile.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12456>
We only end up with one DRI provider per screen, so the only way the
context vtable can differ is if they're not the same directness. Rewrite
the test in those terms to help us unify some of this code away in the
future. Also apply the same logic to the indirect context creation path.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12456>
Instead of making LMEM the special case, unify the two paths by setting
up a fake drm_i915_query_memory_regions struct and filling it out based
on OS queries. The important functional change here is that we now pass
system memory through the same GTT size and 3/4 filter that we were
using with the OS queries. This should make behavior consistent on
integrated GPUs regardless of whether or not we have the memory region
query API.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12433>
16bit integer support also implies using 16-bit results when sampling
textures.
Because we're returning the results in float SSA values instead of int,
we need to bitcast back to integers before truncating the values.
Fixes: 00ff60f799 ("gallivm: add 16-bit integer support")
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12413>
This is what I see happening in
dEQP-VK.spirv_assembly.instruction.compute.opatomic_storage_buffer.load on
pixel 2 (also where I found a buffer big enough to show how to encode the
size).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12258>
Even though we can't really do the parsing on behalf of the driver (it's
too complicated), storing it in the vk_image lets us provide a common
implementation of vkGetImageDrmFormatModifierPropertiesEXT(). It'll
also be useful in the next few commits for swapchain images.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12023>
It doesn't make sense to ask for the depth-only or stencil-only format
if there is no depth or stencil. One bit of radv_image.c did seem to
take advantage of the default case in vk_format_depth_only so throw an
`if (vk_format_has_depth(format))` around it.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12023>
Using suites makes load-balancing our jobs much easier, keeps the CPU busy
handling the a630_gles_others.sh test sets (and improves the output and
baseline handling for them), and makes it trivial to add in more short
test sets.
a306: still 5 jobs, and we add KHR-GLES2 (KHR-GLES3 is unstable)
a530: still 5 jobs, added KHR-GLES*
a630_gl: 5 jobs becomes 4, and we add KHR-GLES*
a630_vk: still 3 jobs, now 1/3 of all VK instead of 1/4.
a630_vk_full: still 2 jobs, now includes full bypass testing, partial
no-force testing, and testing of pre-merge-skipped tests.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12256>
We were adding them if there was an external dep instead of if there
wasn't, and we were skipping the entire subpass which would've resulted
in attachments not getting marked as used.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12386>
Doesn't fix, but improves the situation in issue #5163. The
VK.spirv_assembly.instruction.graphics.spirv_ids_abuse.lots_ids_* tests
emit about 160k instructions. ir3_sched blows out the stack after
dag_traverse_bottom_up_node reaches a depth of about 130k frames.
This patch replaces the recursively-implemented post-order traversal
with an iterative implementation using a stack, allowing us to process
DAGs as large as memory can hold.
Definitely makes you appreciate the elegance of recursion...
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12232>
The OpenGL ES 2.0 (and later) specifications, section 2.13 (Primitive
Clipping) say the following about point-clipping:
> If the primitive under consideration is a point, then clipping
> discards it if it lies outside the near or far clip plane; otherwise
> it is passed unchanged.
This matches the D3D convention, and we already have a rasterizer-state
bit for it. So let's set that bit when the API is OpenGL ES 2.
We can set this inside the PointSprite-conditional block, because that's
always enabled on GLES 2, and it's undefined to enable this state
without also enabling point_quad_rasterization.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12350>
When I updated this code for multi-sampling, I missed one detail; if we
want to be able to support pipe_rasterizer_state::point_tri_clip, we
need to use the intersection of the bbox (clipped to the viewport
rectangle) and the generated primitive, otherwise we won't end up doing
x/y viewport clipping at all.
Because we've adjusted some of the parts of the bbox when adjusting for
inclusiveness/exclusiveness and fill-rule, we also need to reverse the
adjustment.
Fixes: f530e72ea0 ("llvmpipe: do not always use pixel-rounded coordinates for points")
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12350>
This is mostly a bit of future-proofing. We never end up with offsets
that don't fit in 32 bits today because, thanks to driver limitations
caused by relocations, we don't allocate buffers bigger than 2GB today.
However, if we ever did, it's possible to create a surface on modern
platforms that consumes more than 4GB and we would end up with wrapping
in our offset calculations.
Acked-by: Ivan Briano <ivan.briano@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11765>
this is an aux/pipebuffer implementation borrowing heavily from the
one in radeonsi. it currently has the following limitations, which
will be resolved in a followup series:
* 32bit address space still explodes
* swapchain images still have separate memory handling
performance in games like Tomb Raider has been observed to increase by
over 1000%
SQUASHED: simplify get_memory_type_index()
now that the heaps are enumerated, this can be reduced to a simple
array index with a fallback
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12146>
Enable CI for lima again on meson-gxl-s805x-libretech-ac boards
with Mali-450.
These boards are managed by a LAVA instance and so follow the LAVA CI
workflow in Mesa.
The goal is to have coverage for deqp-gles2, as lima is a GLES2-only
driver.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11789>
Currently stride, offset, modifier is obtained by invoking
lima_resource_get_handle() with WINSYS_HANDLE_TYPE_KMS.
Before commit 47f000c170 this path was working. Obtained handle
was simply ignored by DRI frontend and only requested data used.
After commit 47f000c170 such requests started to fail when
DRI is initialized using KMSRO and resource has no scanout data.
When lima_resource_get_param() is implemented, it will be used in
a first place to obtain resource data.
Fixes: 47f000c170 ("lima: fail in get_handle(TYPE_KMS) without a scanout resource")
Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Erico Nunes <nunes.erico@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12362>
When operators other than eq and ne are involved we can't really
move operands around and negate them because such transformation
may change the value of the whole expression.
Some examples:
For unsigned var:
0 >= 1u + var would eventually become 0xffffffff >= var,
which would always evaluate to true, when original expression
was true only for var == 0xffffffff.
For signed var:
0 >= 1 + var would become -1 >= var, which would evaluate to
false for var == 2147483647, when original expression evaluated
to true (because signed overflow is defined to wrap around in
glsl, 1 + 2147483647 == -2147483648, so 0 >= -2147483648).
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5226
Fixes: 34ec1a24d6 ("glsl: Optimize (x + y cmp 0) into (x cmp -y).")
Signed-off-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12359>
Fix defects reported by Coverity Scan.
Dereference before null check (REVERSE_INULL)
check_after_deref: Null-checking sa suggests that it may be null,
but it has already been dereferenced on all paths leading to the
check.
check_after_deref: Null-checking sb suggests that it may be null,
but it has already been dereferenced on all paths leading to the
check.
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12298>
This refactors out the vertex color clamping from the VS shader,
and adds calls to it for the tes/gs stages. It also conditionalised
they key on having later stages as clamping should only happen in
the last stage.
This is needed for GL compatibility profiles
Reviewed-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12374>
In order to enable compat contexts QUADS/QUAD_STRIPS need
to support primitive ID. There are some piglit tests for this.
This adds support to the decomposer to pass quads so the prim
assembler can pick them up and add primitive IDs.
Acked-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12374>
dEQP has poor coverage of clear colours with odd formats, and doesn't
check that we dither as expected. This functionality is trivial to unit
test, so there's no excuse not to. Nontrivial reference values are
captured from pandecode of the Mali G52 DDK but should be valid for all
Midgard/Bifrost.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12365>
At the beginning of a render pass, the hardware will fill the tilebuffer
with an arbitrary 128-bit word. To implement colour clears, the driver
must pack the API-specific clear colour according to the 128-bit layout
of the tilebuffer. This layout depends only on the render target format.
The existing code to handle this was based on loose guesswork. It works
for the format / clear colour combinations tested in dEQP-GLES3, but it
is severely deficient in the general case. It works by matching on the
PIPE format of the render target (not the layout of the tilebuffer). For
special cased PIPE formats, it open codes a buggy pack routine.
Otherwise, it defaults to util_pack_color in the hope that will work.
Since util_pack_color doesn't know anything about Mali tilebuffer
layouts, that means it's defaulting to wrong behaviour.
Now that we understand internal tilebuffer layouts, let's rewrite the
packing code. Instead of matching PIPE formats, map the PIPE format to
the internal tilebuffer layout using the common table, ensuring the
mapping remains in sync with the render target descriptor. Then for
blendable tilebuffer formats, pack using a common float -> fixed point
path supporting optional sRGB translation. Raw formats use
util_pack_color as before.
For formats with less than 8 bits per channel, the new code uses the
fractional bits of the fixed-point representation. This is required for
correct dithering if the clear colour is not exactly representable in
the final low precision format.
In summary, at least the following bugs in the old code are fixed:
* Swapped R/B channels with sRGB
* Swapped R/B channels with some missing formats
* Incorrect dithering with RGB565, RGB5_A1
Fixes the following test cases:
dEQP-EGL.functional.wide_color.window_8888_colorspace_srgb
dEQP-EGL.functional.wide_color.pbuffer_8888_colorspace_srgb
dEQP-EGL.functional.wide_color.window_888_colorspace_srgb
dEQP-EGL.functional.wide_color.pbuffer_888_colorspace_srgb
Later in the series, unit tests are added for the new implementation.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12365>
Transfer ownership of the render node fd to the panfrost_device (minor
change to panvk), and then close the file descriptor for the render node
bound to the panfrost_device when destroying the panfrost_device. Of all
the users of panfrost_open_device, panvk is the only one that correctly
closed the fd before. Accordingly, this fixes an fd leak in the Gallium
driver (and performance counter utilities).
This fix still applies to the Gallium driver when renderonly is in use--
although renderonly closes its own fd, the fd is _duplicated_ in
panfrost_drm_winsys.c, so renderonly and panfrost must _both_ close
their respective fd to fix the leak.
This fixes a crash when running dEQP-EGL for more than two hours.
dEQP-EGL creates a new screen for every test case and then immediately
destroys it. If destroying a screen leaks the fd, this causes the number
of open file descriptors to increase monotonically until the process
ends. This will eventually hit the system limit for number of open files
and abort the process.
This bug was identified while attempting to run the OpenGL ES
conformance tests via cts-runner, and then confirmed with `lsof`. With
the fix, the number of file descriptors reported by `lsof | wc -l` is
now constant while running dEQP-EGL as expected.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12346>
We were handling the case where we had an unassigned output in the
middle of the outputs array, but v->outputs can be smaller than the
shader's info.num_outputs when an output at the end isn't assigned. This
lead to us reading garbage after the end, and assuming that it
corresponded to r0.x and overwriting the xfb entry for some other random
output with the unassigned output's entry.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12310>
Add a value discovered when investigating how the blob implements
GL_KHR_blend_equation_advanced.
Note that everything added here is a bit speculative, because it's
assuming the blob's implementation of GL_KHR_blend_equation_advanced is
sane. In particular a value of 0x3 seems to solve the UBWC problem as
well, so I'm not sure whether my description of the difference between
0x1 and 0x3 is correct. I'm also surprised that it uses the same value
for the coherent and non-coherent cases when forcing sysmem.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12360>
In wsi_wl_display_init(), the format vector is initialized only when the
caller sets the function to query the formats/modifiers. But
wsi_wl_display_finish() always release the vector, no matter if it has
been initialized or not.
For now it just works because the u_vector_foreach() macro works when
the format vector is uninitialized, but it is a weird design to try to
release something that has not been initialized.
So in this patch we start to always initialize the format vector, even
when not querying formats/modifiers.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12117>
Instead of having hard-coded lists of modifiers for argb8888 and
xrgb8888, store a list of modifiers alongside each VkFormat. To
achieve this goal, introduce a new struct wsi_wl_format that holds
both a VkFormat and a modifier list, and use it for the items in
the formats list.
This commit unlocks non-{A,X}RGB8888 formats, which were previously
always disabled for linux-dmabuf.
Signed-off-by: Simon Ser <contact@emersion.fr>
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12117>
The two structs wsi_wl_display_swrast and wsi_wl_display_dmabuf have in
common the list of formats and the only difference between both is the
interface object.
As we know that only one of the arrays is populated (we never bind to
wl_shm and the dmabuf interface simultaneously), we can move the members
of these structs to wsi_wl_display and simplify the code.
This is based on previous work of Simon Ser <contact@emersion.fr>.
Signed-off-by: Simon Ser <contact@emersion.fr>
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12117>
When force_bgra8_unorm_first is true, we access display->formats and
change the order of certain formats. The final result is BGRA8_UNORM
being the first in the format list, as some clients require this.
But we are trying to do this before before setting up display->formats,
so it should result in a crash. Fix this by changing the order of
things. Now we first set up display->formats before trying to access it.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12117>
If a loop is followed by a barrier, the ordering between a load inside
the loop and other memory operations after the barrier may have to be
preserved depending on the type of memory involved. This is relevant
when the memory is writeable by other invocations. In such case, it
is not valid to completely eliminate the loop.
This commit doesn't attempt to precisely catch the barrier case, as
analysis could become too complex. It simply assumes it can't drop
the loops that contain certain types of loads unless those are known
to be safe to reorder (via the access flag).
Fixes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4475
Acked-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9938>
mmap requires its offset is page aligned, but the current code only
guarantees 4k alignment, causing drm-shim to break badly on kernels with
>4k page sizes. This fixes drm-shim on my Apple M1, running bare metal
Linux with 16k pages. It probably also fixes exotic PowerPC systems with
64k pages.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Zoltan Boszormenyi <zboszor@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12347>
Without this stitch_blocks complains about ending in a jump with a
non-empty block after the inserted body.
I hit this with CTS raytracing tests where we tried to inline a
function that basically ended up being something like
{
ignore_ray_intersection
halt
}
I kept the nop path when possible as that does not leave a mess
for the optimization loop to optimize.
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12163>
Need to avoid lowering temps when they are used by other instructions,
like the rt instructions (some of the shader call parameters get
converted to temp variables and we will lower them later with
the explicit io lowering pass as we need to guarantee they will
end up in scratch).
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12162>
When creating an image out of a swapchain on Android, the android
layer call will detect a VkBindImageMemorySwapchainInfoKHR in the
pNext chain of the vkBindImageMemory2() call and add a
VkNativeBufferANDROID in the chain. This is what we should use as
backing memory for that image.
v2: Fix a couple of obvious mistakes (Tapani)
v3: Silence build warning (Lionel)
Fix invalid object argument to vk_error() (Lionel)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: bc3c71b87a ("anv: don't try to access Android swapchains")
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5180
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12244>
We're just using this as a minor optimization to allocate pages for
buffers up front outside of some kernel locking. It's not essential.
The SET_DOMAIN ioctl may be going away in the future, so let's be a
bit cautious and try it but not fail.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12044>
We need to raise an error when importing a user pointer as a BO if the
supplied pointer can't actually be used on the GPU. Previously, we were
(ab)using the SET_DOMAIN ioctl for this, but it's not really intended
for that purpose, and is going away on discrete.
Fortunately, there's a new kernel API for this: the I915_USERPTR_PROBE
flag tries to perform basic sanity checking of the supplied pointer so
that we can at least reject obvious misuse of this API up front.
Use the new API where available. Fall back to SET_DOMAIN if it isn't.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12044>
Previously, when importing a resource with modifiers that include
clear color as auxiliary data, we were mapping the clear color BO
on the CPU in order to set res->aux.clear_color to the value stored
there.
We are generally trying to avoid CPU mapping imported buffers, because
in hybrid setups, they could be from a different device, and may not be
mappable. So we'd like to avoid that here.
This CPU-side knowledge of the clear color is only used in a few cases:
1. Avoiding a resolve due to a partial clear with a changing clear color
2. Avoiding disabling CCS when rendering to a texture view of a resource
where the only format difference is sRGB vs. linear and the clear
color is 0/1.
Instead of mapping the clear color BO on the CPU, we instead set a flag
indicating that we don't know the clear color, and reset it to known on
our first clear.
In the first case, the first partial fast clear of a resource would eat
an extra resolve (there is no penalty if we clear the whole resource).
The second case doesn't seem that critical, as it's someone rendering
to an imported BO - when the common case is to texture from it.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11888>
When incrementing unifa address in DCE optimization, ensure that we
setup correctly the current block, so the ldfunif optimization is also
executed correctly.
This fixes
dEQP-VK.graphicsfuzz.cov-struct-float-array-mix-uniform-vectors
heap-buffer overflow with address sanitizer enabled.
v2 (Iago):
- Save and restore current block
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12339>
While this feature is optional in Vulkan 1.1 and we don't currently
expose it, the CTS still requires that the entry points exist.
From the Vulkan 1.1 spec:
"If the VK_KHR_sampler_ycbcr_conversion extension is not supported,
support for the samplerYcbcrConversion feature is optional."
(...)
"samplerYcbcrConversion specifies whether the implementation supports
sampler YCBCR conversion. If samplerYcbcrConversion is VK_FALSE,
sampler YCBCR conversion is not supported, and samplers using sampler
YCBCR conversion must not be used."
Fixes (with Vulkan 1.1 exposed):
dEQP-VK.api.version_check.entry_points
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12338>
This allows this pattern:
$ radeonsi-run-tests.py /tmp/foo
... reports that some piglit tests regressed ...
$ radeonsi-run-tests.py -t /tmp/foo/new_baseline/sienna_cichlid-piglit-quick-fail.csv
... this only runs the test that regressed ...
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12306>
Before a73cb106a6, cso contexts were never reused, but now that they
are we need to be extra careful that the state in the cso context and
in the pipe context matches even after an unbind, since when the cso
context is reused the state might otherwise get out of sync (as there is
no concept of "initial state", basically cso always relied on the default
values being the same both in cso and the drivers).
This fixes some errors we've seen internally with lavapipe.
Fixes: a73cb106a6 ("aux/cso: split cso_destroy_context into unbind and a destroy functions")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12261>
This allows to set VK_PRIMITIVE_TOPOLOGY_PATCH_LIST dynamically when
tessellation used.
If other values are set via vkCmdSetPrimitiveTopologyEXT for the case,
the validation layer can detect the issue.
Fixes dEQP-VK.pipeline.extended_dynamic_state.*.topology_patch*
Signed-off-by: Hyunjun Ko <zzoon@igalia.com>
Reviewed-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12299>
drm_i915_query_perf_config::data is an unsized array and declaring a
struct containing an unsized array that isn't at the end is a GNU
extension which trips up Android builds. Instead, stuff both into a
char array of the appropriate size. This emulates what you'd normally
do to allocate one of these with malloc only on the stack.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12308>
Again, we don't need all the dependency checking, seqno incrementing
and duplicate tracking for batch->bo. Just use the unchecked version.
This commit is not particularly significant since it really just saves
us a check in the iris_use_pinned_bo() hot path, but since we already
have the helper function, why not?
v2:
- (turns out the answer to "why not?" is because the patch had a bug)
- Call ensure_exec_obj_space() since batch batch chaining can happen
and doesn't guarantee pre-reserved space (Ken).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12194>
Don't use iris_use_pinned_bo(), go directly with add_bo_to_batch(),
skipping every check. This allows us to early return from
iris_use_pinned_bo when the workaround bo is used, saving us the call
to find_validation_entry() which ends up doing nothing except
iterating over every bo in the batch. Also don't bother with
ensure_exec_obj_space() since we just reset the batch and this is the
second BO we're adding to it.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12194>
I don't see these BOs being searched for in the benchmarks I tested so
I don't think this should improve anything. On the other hand, it
shouldn't hurt either since it's just an extra assignment.
I want to unify both places where we have this code into a single
function and the lack of the bo->index assignment was the only
difference between the two places. So first we make both functions the
same and in the next commit we'll unify things. This should make
bisecting easier in case I'm wrong.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12194>
On Gfx4 and Gfx5, sel.l (for min) and sel.ge (for max) are implemented
using a separte cmpn and sel instruction. This lowering occurs in
fs_vistor::lower_minmax which is called very, very late... a long, long
time after the first calls to opt_cmod_propagation. As a result,
conditional modifiers can be incorrectly propagated across sel.cond on
those platforms.
No tests were affected by this change, and I find that quite shocking.
After just changing flags_written(), all of the atan tests started
failing on ILK. That required the change in cmod_propagatin (and the
addition of the prop_across_into_sel_gfx5 unit test).
Shader-db results for ILK and GM45 are below. I looked at a couple
before and after shaders... and every case that I looked at had
experienced incorrect cmod propagation. This affected a LOT of apps!
Euro Truck Simulator 2, The Talos Principle, Serious Sam 3, Sanctum 2,
Gang Beasts, and on and on... :(
I discovered this bug while working on a couple new optimization
passes. One of the passes attempts to remove condition modifiers that
are never used. The pass made no progress except on ILK and GM45.
After investigating a couple of the affected shaders, I noticed that
the code in those shaders looked wrong... investigation led to this
cause.
v2: Trivial changes in the unit tests.
v3: Fix type in comment in unit tests. Noticed by Jason and Priit.
v4: Tweak handling of BRW_OPCODE_SEL special case. Suggested by Jason.
Fixes: df1aec763e ("i965/fs: Define methods to calculate the flag subset read or written by an fs_inst.")
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Tested-by: Dave Airlie <airlied@redhat.com>
Iron Lake
total instructions in shared programs: 8180493 -> 8181781 (0.02%)
instructions in affected programs: 541796 -> 543084 (0.24%)
helped: 28
HURT: 1158
helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1
helped stats (rel) min: 0.35% max: 0.86% x̄: 0.53% x̃: 0.50%
HURT stats (abs) min: 1 max: 3 x̄: 1.14 x̃: 1
HURT stats (rel) min: 0.12% max: 4.00% x̄: 0.37% x̃: 0.23%
95% mean confidence interval for instructions value: 1.06 1.11
95% mean confidence interval for instructions %-change: 0.31% 0.38%
Instructions are HURT.
total cycles in shared programs: 239420470 -> 239421690 (<.01%)
cycles in affected programs: 2925992 -> 2927212 (0.04%)
helped: 49
HURT: 157
helped stats (abs) min: 2 max: 284 x̄: 62.69 x̃: 70
helped stats (rel) min: 0.04% max: 6.20% x̄: 1.68% x̃: 1.96%
HURT stats (abs) min: 2 max: 48 x̄: 27.34 x̃: 24
HURT stats (rel) min: 0.02% max: 2.91% x̄: 0.31% x̃: 0.20%
95% mean confidence interval for cycles value: -0.80 12.64
95% mean confidence interval for cycles %-change: -0.31% <.01%
Inconclusive result (value mean confidence interval includes 0).
GM45
total instructions in shared programs: 4985517 -> 4986207 (0.01%)
instructions in affected programs: 306935 -> 307625 (0.22%)
helped: 14
HURT: 625
helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1
helped stats (rel) min: 0.35% max: 0.82% x̄: 0.52% x̃: 0.49%
HURT stats (abs) min: 1 max: 3 x̄: 1.13 x̃: 1
HURT stats (rel) min: 0.12% max: 3.90% x̄: 0.34% x̃: 0.22%
95% mean confidence interval for instructions value: 1.04 1.12
95% mean confidence interval for instructions %-change: 0.29% 0.36%
Instructions are HURT.
total cycles in shared programs: 153827268 -> 153828052 (<.01%)
cycles in affected programs: 1669290 -> 1670074 (0.05%)
helped: 24
HURT: 84
helped stats (abs) min: 2 max: 232 x̄: 64.33 x̃: 67
helped stats (rel) min: 0.04% max: 4.62% x̄: 1.60% x̃: 1.94%
HURT stats (abs) min: 2 max: 48 x̄: 27.71 x̃: 24
HURT stats (rel) min: 0.02% max: 2.66% x̄: 0.34% x̃: 0.14%
95% mean confidence interval for cycles value: -1.94 16.46
95% mean confidence interval for cycles %-change: -0.29% 0.11%
Inconclusive result (value mean confidence interval includes 0).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12191>
Map nir_op_fsat/etc to FCLAMP pseudo ops, instead of FADD. There are
significantly fewer knobs on FCLAMP, meaning significantly fewer things
to get wrong.
This fixes two(!) classes of bugs:
* Swizzles (failing to lower/compose swizzles on clamps)
* Numerical bugs (incorrectly treating +0.0 as an additive identity)
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12205>
Simplifies pattern matching. This commit by itself fixes multiple
numerical issues -- the previous fabsneg check failed to check the round
mode or the sign of the zero. That will break Vulkan/OpenCL.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12205>
Bifrost adds a value for the C factor equaling 2*src. This does not
correspond directly to API blend modes so it is not too useful in
general. However, it's required for src*dest + dest*src blending to be
done in hardware instead of a blend shader. GFXbench uses that blend
mode, so it must be important ;-)
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12152>
Add unit tests for the fixed-function blending helpers in pan_blend.c.
Each test consists of a Porter-Duff blend mode and the associated
hardware state. In this commit, we add tests for the most common modes.
For motivation, this code has NOT been properly tested in CI. True,
functional correctness of the blend module as a whole is tested by
dEQP-GLES3.functional.fragment_ops.blend.* among other integration
tests. However, this testing is insufficient to check for regressions.
Crucially, the following broken patch would clear CI:
bool pan_can_fixed_function(...) {
return false;
}
In that case, blend shaders are used 100% of the time, which will
regress performance horribly but still pass dEQP. The only clue
something went wrong would be some traces changing checksum due to the
fixed-function blender producing slightly different output than
equivalent blend shaders. By unit testing the fixed blend path, we
ensure we always use the fixed-function path when we expect it to.
Similarly, using incorrect values for the blend metadata may not affect
functional correctness but will increase power consumption. Let's check
all the data we export to drivers.
Note: due to additive commutativity, there are many pairs of equivalent
Mali blend modes. Unfortunately, the vendor is... inconsistent about how
to resolve ambiguous modes. Our algorithm for computing modes is
correct; the "preferred" values are left in comments since otherwise our
tests fail despite correct code. I want to blame Bifrost for this, but
Midgard was patient zero.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12152>
This is required to disable dithering on a per-draw basis when OPAQUE
output is used (bypassing the blender which normally uses the
round_to_framebuffer_precision flag to do the same).
This functionally reverts:
ebc07f4b2f ("panfrost: Remove padded unorm blendable formats")
fae90a7940 ("panfrost: Always pick dithered tb formats")
while adding the functionality to make them useful.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12152>
gl_FragDepth default value is gl_FragCoord.z so if a shader does:
gl_FragDepth = gl_FragCoord.z
we can drop this assignment.
v2: use nir_ssa_scalar_resolved and don't do this is gl_FragDepth
is wrote multiple times (Jason)
v3: - move to its own pass (Jason)
- handle var = NULL (Rhys)
v4: refactoring (Jason)
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10697>
Per https://gitlab.freedesktop.org/mesa/mesa/-/issues/5178#note_1019666,
the assumption fundamental to this optimization is false. Section
2.4.1 (Float to Integer) of Ivy Bridge PRMs describes the situation.
The wording of the section is somewhat confusing (because it doesn't
clearly delineate between signed and unsigned integers), but the last
two rows of the table make it clear that F->UD conversion clamps
negative float values to 0.
All other hardware mentioned in that thread seems to behave the same
way.
The real problem is that, with hardware that behaves in this ways,
converting f2u(2147483648.0) to f2i(2147483648.0) changes the bit pattern
that would be produced from 0x80000000 to 0x7fffffff.
This reverts commit ad05920258.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12297>
Otherwise drivers that don't use 16-bit slots for varyings will get
confused and have their driver_locations scribbled over. This has caused
multiple problems for both Panfrost and Asahi this week. Given the only
other user of the pass for varyings is radeonsi, which needs both
together, I think this is the least controversial fix.
Fixes: fb29cef8dd ("nir: add many passes that lower and optimize 16-bit input/outputs and samplers")
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11732>
It can happen that the user reads an input attachment as the first use
of that attachment. In that case there are no subpass dependencies
required at all, because there could be a pipeline barrier before the
renderpass instead, and in any case we assume that dependencies with the
first subpass as a destination can be executed only once outside the
renderpass. The result is that we only do a CACHE_INVALIDATE once
before the entire renderpass, but it's actually required after each GMEM
load, because input attachments read GMEM through UCHE and those writes
to GMEM invalidate UCHE.
While we could add the missing CACHE_INVALIDATE "by hand" somehow, it
turns out it's actually just as easy to do an optimization the blob
does, where it simply doesn't patch those input attachments and reads
them directly instead. This means we can skip allocating memory in GMEM
for them entirely in some circumstances.
This fixes e.g.
dEQP-VK.api.copy_and_blit.core.resolve_image.whole_array_image.4_bit
with TU_DEBUG=forcebin.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12213>
Only GFX10+ is affected because older chips don't support
comp-to-single. For them, we need to implement FCE on compute with DCC
and eventually CMASK.
Fixes the gap between concurrent vs exclusive queue with Scarlet Nexus,
also gives a boost with Doom Eternal.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12088>
The code we had for this was a work in progress and not finished. Also,
it was geared towards partial writes caused by output packing (i.e.
fp16) and was ignoring partial updates caused by conditional writes,
which are far more common in our case.
This change provides an implementation for tracking conditional writes
that works in tandem with the previous spill change to narrow liveness
for their spills.
Fixes register allocation failures in:
dEQP-VK.graphicsfuzz.spv-stable-maze-flatten-copy-composite
We also gain one shader from shader-db:
total instructions in shared programs: 13339969 -> 13338584 (-0.01%)
instructions in affected programs: 185520 -> 184135 (-0.75%)
helped: 375
HURT: 130
Instructions are helped.
total threads in shared programs: 412038 -> 412040 (<.01%)
threads in affected programs: 2 -> 4 (100.00%)
helped: 1
HURT: 0
total uniforms in shared programs: 3746581 -> 3746585 (<.01%)
uniforms in affected programs: 49 -> 53 (8.16%)
helped: 0
HURT: 1
total max-temps in shared programs: 2359960 -> 2359947 (<.01%)
max-temps in affected programs: 289 -> 276 (-4.50%)
helped: 7
HURT: 0
Max-temps are helped.
total sfu-stalls in shared programs: 34351 -> 34359 (0.02%)
sfu-stalls in affected programs: 218 -> 226 (3.67%)
helped: 35
HURT: 37
Inconclusive result (value mean confidence interval includes 0).
total inst-and-stalls in shared programs: 13374320 -> 13372943 (-0.01%)
inst-and-stalls in affected programs: 186653 -> 185276 (-0.74%)
helped: 373
HURT: 132
Inst-and-stalls are helped.
LOST: 0
GAINED: 1
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12278>
A spill of a conditional write generates code like this:
mov.ifa t5000, 0
mov tmud, t5000
nop t5001; ldunif (0x00008100 / 0.000000)
add tmua, t11, t5001
Here, we are spilling t5000, which has a conditional write, and we
produce an inconditional spill for it. This implicitly means that
our spill requires a correct value for all channels of t5000.
If we do a conditional spill, then we emit:
mov.ifa t5000, 0
mov tmud.ifa, t5000
nop t5001; ldunif (0x00008100 / 0.000000)
add tmua.ifa, t11, t5001
Which only uses channels of t5000 that have been written by the
instruction being spilled.
By doing the latter, we can then narrow down the liveness for t5000
more effectively, as we can use this to detect that the block only reads
(in the tmud instruction) the values that have been written previously
in the same block (in the mov instruction). This means that values in
other channels are not used, and therefore, we don't need them to be
alive at the start of the block. This means that if this is the only
write of t5000 in this block, we can consider that the block
completely defines t5000.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12278>
Crosvm deals with virtio-gpu commands sequentially, so parallelization
in the host doesn't help much.
Also, too much parallelization in the guest causes some tests to time
out.
So reduce the number of dEQP instances being run concurrently, make sure
we dont limit the number of CPUs being used in the host and schedule
more jobs in CI to keep the times below 10 minutes.
Closes: #5172
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12196>
From the Vulkan spec 1.2.187.
"fragmentShadingRateWithCustomSampleLocations specifies whether
custom sample locations are supported for multi-pixel fragments.
It must be VK_FALSE if VK_EXT_sample_locations is not supported."
VK_EXT_sample_locations is disabled on GFX10+.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12245>
It's called anv_image_* so it really should take an anv_image. For the
couple of cases where we really want to pass in a set of aspects, we
leave an anv_aspect_to_plane() helper. anv_image_aspect_to_plane() is
then just a wrapper around it which grabs the aspects from the image.
While we're in the area, sprinkle some const around.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12141>
The Vulkan 1.2.184 spec says:
"When creating a VkImageView, if sampler Y′CBCR conversion is
enabled in the sampler, the aspectMask of a subresourceRange used by
the VkImageView must be VK_IMAGE_ASPECT_COLOR_BIT.
When creating a VkImageView, if sampler Y′CBCR conversion is not
enabled in the sampler and the image format is multi-planar, the
image must have been created with
VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT, and the aspectMask of the
VkImageView’s subresourceRange must be VK_IMAGE_ASPECT_PLANE_0_BIT,
VK_IMAGE_ASPECT_PLANE_1_BIT or VK_IMAGE_ASPECT_PLANE_2_BIT."
Previously, for YCbCr images, we were flipping this around. For single-
plane views where VK_IMAGE_ASPECT_PLANE_N_BIT would be passed in by the
app, we would store VK_IMAGE_ASPECT_COLOR_BIT. For multi-plane views
where the client says VK_IMAGE_ASPECT_COLOR_BIT, we would store a all of
the planes. (There was also an extra bit of remapping that would
compact the planes in the non-existent case of a format with a non-
contiguous set of planes.) The idea behind this was that for things
like rendering or single-plane sampling, storage, or compute, we want it
to look as much like a single-plane image as possible but we wanted the
multi-plane case to be the awkward one.
This commit changes it around so that iview->aspects is always exactly
the subset of image->vk.aspects represented by the view. This is
identical to how aspects work for depth/stencil so it gains us some
consistency.
This commit also changes anv_image_view::aspect_mask to aspects to force
a full audit of the field. As can be seen, there are only a few uses of
this field and they're all mostly fine:
- A bunch of them are used to check for depth/stencil. That hasn't
changed.
- Most of the checks for color already used ANY_COLOR_BIT, only one
needed fixing.
- There's a check that both src/depth are color for MSAA resolves.
However, we don't support MSAA on YCbCr so there's no point in
checking for ANY_COLOR_BIT.
There is a hidden usage of planes in anv_descriptor_set_write_image_view
that's not as obvious. However, this function simply looks at
anv_image_view::n_planes and blindly fills out the descriptor
accordingly. As long as image views with a single plane continue to
claim n_planes == 1, this will be fine.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12141>
Previously, we initialized vplane in anv_CreateImageView to 0 and
incremented it every iteration of the aspect loop. This only works
because planes are guaranteed to be in aspect-bit-order which wasn't
documented anywhere. Instead, drop this assumption and burn a couple
CPU cycles properly calculating vplane.
While we're here, make iplane const as well.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12141>
When creating a single-plane view of a multi-plane image, we were
relying on vplane_aspect to be VK_IMAGE_ASPECT_COLOR_BIT so that
anv_get_format_plane of the single-plane view format would work.
Instead of relying on this quirk, we can drop vplane_aspect and rely
entirely on vplane to only be 0 in this case. In the case of depth or
stencil images, we still need to grab the format aspect but we can use
the actual aspect and don't need the vplane_aspect trickery.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12141>
The comment about modifiers is bogus because we check the modifier
before this check and return early. Also, there's no reason why we need
to check the requested aspect when we could check the format itself.
anv_image_aspect_to_plane will ensure that the requested aspect is one
that actually exists.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12141>
Vulkan allows us to, in theory, support ycbcr on single-plane formats if
the client really wants it. Also, these functions should work on a
multi-plane color image as long as the client specifies the right
aspect. This gets rid of our usage of can_ycbcr outside of anv_image.c.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12141>
In the compute dispatch path we do not allocate a huge amount
of space to cover everything so the individual functions have to
allocate. This was missing here, causing a hang in Cyberpunk when
accessing the system menu at some locations with thread tracing
enabled.
Fixes: bd1186572f ("radv: add support for push constants inlining when possible")
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12271>
The spill base setting instructions (which includes some uniforms) are
added in the entry block, not in the current block. When ldunif
optimization is applied, the cursor is pointing to instructions in the
entry block, but the current block is a different one. This leads to a
heap-buffer-overflow when going through the list of instructions
(detected by the address sanitizer).
Thus change the current block to entry block, and restore it after the
setup is done.
This fixes
dEQP-VK.ssbo.readonly.layout.single_struct.single_buffer.std430_instance_array_comp_access_store_cols
with address sanitizer enabled.
v2:
- Set current block instead of disabling ldunif optimization (Iago)
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12221>
These two bits were added in 2012, but never got wired up. Let's cut our
losses, and remove them again. 9 years unused seems sufficient.
While we're at it, remove reduction_mode from the hacks-section, because
this isn't a hack at all, rather normal state.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12240>
Through some exhaustive searching, I've found that our log2 approximation
is precise to around 3.5 bits. And the squaring step should increase the
result with one bit, leaving us with 4.5 bits of precision.
Reporting the right mipmap precision fixes a few CTS-tests.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12238>
This is similar to u_transfer_helper wrap but implemented in
the driver as the layout between drivers can vary.
v2: remove else, simplify (Rohan, Eleni)
v3: add hiz surface support when importing depth buffer
v4: use iris_resource_configure_aux_offsets for setting
aux offsets for depth
v5: introduce helper for configuring imported memobj aux
offsets and utilize that
v6: simplify, remove aux support for now
v7: cleanups, fix offset calculation (Nanley)
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10609>
11 instructions, but now processes up to 4 channels at once (since TGSI
splits to scalar for these math ops) while being higher accuracy.
Previously we used 6 instructions per channel, but it didn't look like a
sine wave. i915c managed it in 9 instructions per scalar channel, thanks
to avoiding an extra mov we do for the fabs (should be fixable), and
avoiding an extra MUL (maybe just needs reassociation of our immediates?).
But, the ALU count win from doing 4 channels at once will be way more
important for making sure that programs compile than those 2 ALU ops, plus
now we do it in NIR instead of assembly.
Closes: #4981
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12250>
The flock is per-fd, not per thread, and we do it outside of the main mutex. This was
done to avoid having to wait in the mutex, but we can get a case where one ends up running
the body with the flock unlocked.
Fix this by adding a mutex that doesn't need to be locked for reads.
Fixes: 4f0f8133a3 "util/fossilize_db: Do not lock the fossilize db permanently."
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12266>
Don't anticipate seeing any partial written headers but just in case we
should probably wait on the lock to make sure whatever header was being
written is finished being written.
Fixes: 4f0f8133a3 "util/fossilize_db: Do not lock the fossilize db permanently."
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12204>
Building toward scheduled nightly runs, add a button to do a full VK run
when you think you're changing test expectations.
Be gentle with the play button on this, 4 people doing this at once
would block marge for everyone else for a while.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12150>
Otherwise, another thread might reuse their object ids for other
objects. For example,
T1: free queue with object id X
T2: reuse id X
T2: emit vkCreateFoo with id X
T1: emit vkDestroyDevice
virglrenderer happily accepts that which leads to double frees of the
queue: once when X is updated to point to another object and once when
vkDestroyDevice is executed. virglrenderer should be fixed to catch
such invalid object id reuse as well.
Fixes
dEQP-VK.api.object_management.multithreaded_shared_resources.device_group.
Fixes: ddd7533055 ("venus: initial support for queue/fence/semaphore")
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12252>
In the UABI it is already 64b, but userspace ignored the upper 32b. But
it looks like we will start needing the upper 32b. So before we start
actually *using* chip_id, lets make sure everything is treating it as
64b.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12159>
Newer GPU's are moving away from using gpu_id, including the code
landing upstream for "7c Gen 3". But most of the places in the gallium
driver where we were looking at gpu_id, we only cared about the major
generation. So convert those to use screen->gen instead.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12159>
... and reduce maxDescriptorSetUpdateAfterBindStorageBuffersDynamic from 12 to
8.
MAX_DYNAMIC_BUFFERS is MAX_DYNAMIC_UNIFORM_BUFFERS +
MAX_DYNAMIC_STORAGE_BUFFERS. We set
maxDescriptorSetUniformBuffersDynamic = MAX_DYNAMIC_UNIFORM_BUFFERS
maxDescriptorSetStorageBuffersDynamic = MAX_DYNAMIC_STORAGE_BUFFERS
maxDescriptorSetUpdateAfterBindUniformBuffersDynamic = MAX_DYNAMIC_BUFFERS / 2
maxDescriptorSetUpdateAfterBindStorageBuffersDynamic = MAX_DYNAMIC_BUFFERS / 2
The CTS test checks that
maxDescriptorSetUpdateAfterBindUniformBuffersDynamic
- is at least 8; and
- is at least maxDescriptorSetUniformBuffersDynamic
maxDescriptorSetUpdateAfterBindStorageBuffersDynamic
- is at least 4; and
- and is at least maxDescriptorSetStorageBuffersDynamic
Prior to this patch maxDescriptorSetUpdateAfterBindUniformBuffersDynamic was 12
but maxDescriptorSetUniformBuffersDynamic was 16, thus causing the CTS failure
in
dEQP-VK.api.info.vulkan1p2_limits_validation.ext_descriptor_indexing
By raising maxDescriptorSetUpdateAfterBindUniformBuffersDynamic to the same
value as maxDescriptorSetUniformBuffersDynamic, we bring the limits into the
appropriate ranges. We do the same thing for
maxDescriptorSetUpdateAfterBindStorageBuffersDynamic by assigning it the same
value as maxDescriptorSetStorageBuffersDynamic.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12193>
The radv_emit_ngg_culling_state function won't write the
SPI_SHADER_PGM_RSRC2_GS register when it knows in advance that
radv_emit_graphics_pipeline will overwrite it anyway.
However, there is an unhandled case:
radv_emit_graphics_pipeline will not emit anything (including this
register) when the pipeline is already emitted. Hence, improve
the check in radv_emit_ngg_culling_state to consider this.
Fixes: 9a95f5487f
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12237>
This adds support for SpvOpAtomicFlag operations.
This is just a simple implementation that lowers
Clear to Store 0
and
TestAndSet to Cas (0, -1)
There are likely platforms/hw that will want to
lower this all the way through NIR and into their
backend, but this will do for now.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12229>
Previously, most piglit GL manual runs on a5xx would get a bunch of
failures in random tests around the same time in the run, with a
characteristic OUT_OF_MEMORY in the logs. With this, that instability
seems to have gone away.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12224>
This is supposed to be set when that stage needs the PrimID sysval
preloaded, except for the VS which doesn't have this bit and instead
infers it from the HS or GS bit (depending on whether tess/GS is
enabled). Therefore for HS, GS, and DS we should set it whenever the
corresponding sysval is there. This includes adding a missing
PC_HS_OUT_CNTL, which I confirmed is set when the HS reads PrimID from
the VS. Note that the DS sysval is currently always enabled whenever
there's a GS, if we were to fix that then we should also change the
logic here.
This doesn't fix anything that I know of, but aligns us more with what
the blob does.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12166>
The previous handling conflated RelPatchID and PrimID, which would
result in incorrect gl_PrimitiveID when doing draw splitting and didn't
work with PrimID passthrough which fills the VPC slot with the "correct"
PrimID value from the tess factor BO which we left 0. Replace PrimID in
the tess lowering pass with a new RelPatchID sysval, and relace PrimID
with RelPatchID in the VS input code in turnip/freedreno at the same
time so that there is no net change in the tess lowering code. However,
now we have to add new mechanisms for getting the user-level PrimID:
- In the TCS it comes from the VS, just like gl_PrimitiveIDIn in the GS.
This means we have to add another register to our VS->TCS ABI. I
decided to put PrimID in r0.z, after the TCS header and RelPatchID,
because it might not be read in the TCS.
- If any stage after the TCS uses PrimID, the TCS stores it in the first
dword of the tess factor BO, and it is read by the fixed-function
tessellator and accessed in the TES via the newly-uncovered DSPRIMID
field. If we have tess and GS, the TES passes this value through to
the GS in the same way as the VS does. PrimID passthrough for reading
it in the FS when there's tess but no GS also "just works" once we
start storing it in the TCS. In particular this fixes
dEQP-VK.pipeline.misc.primitive_id_from_tess which tests exactly that.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12166>
DSPATCHID and HSPATCHID, which we mapped gl_PrimitiveID to, are actually
relative to the current subdraw. Subdraws aren't supported yet by turnip
but they are by freedreno for indirect draws.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12166>
It was added to make sure every pipeline for a merge request has at
least one job which passes (otherwise it's not possible to merge the
MR). Now the "sanity" job always exists in such pipelines, so this
isn't needed anymore.
Fixes: 4c41d1900e "ci: Add jobs running ci-fairy checks"
Reviewed-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12198>
Rather surprisingly, the value stored in the NumVectors field of the
DXIL PSV header isn't the number of vectors, but rather the *maximum*
vector used.
This makes a difference when we're not writing to the first element of
an array, where we would previously generate a validation error.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12197>
Use Piglit's replay profile to measure and store the time that frames
take to render in the GPU.
This job won't run automatically in regular pipelines, but will be
triggered automatically by a script for every successful pre-merge
pipeline.
This is because we want to generate performance data for every relevant
commit merged in main, but we don't want to keep a device busy during
the pre-merge run.
Signed-off-by: Antonio Caggiano <antonio.caggiano@collabora.com>
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12185>
Navi 10 can hang when an NGG workgroup has no output,
so we work around that by always exporting a single zero-area
triangle with a single vertex that has all-NaN coordinates.
Thus far, we only employed this for NGG GS, because on all
other stages, the output can't be empty.
However, with NGG culling, the output can be empty, so let's
apply the same workaround there too.
Cc: mesa-stable
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12169>
When a vertex program is translated to nir, it uses
nir_to_tgsi_compile_options for drivers with only nir-to-tgsi based
NIR support. But this compile option might not be the same as the NIR
compile option from llvmpipe, hence when the nir shader is bound
to the draw module, it hits an assertion in do_alu_action() when
encounters nir_op_fdot3.
With this patch, draw will take the nir-to-tgsi path if preferred IR
from the driver is TGSI.
Fixes assert running Maya on SVGA device.
Reviewed-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Neha Bhende <bhenden@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12176>
Many places need to know the maximum or minimum possible value for a
given size integer... so everyone just open-codes their favorite
version. There is some potential to hit either undefined or
implementation-defined behavior, so having one version that Just Works
seems beneficial.
v2: Fix copy-and-pasted bug (INT64_MAX instead of INT64_MIN) in
u_intmin. Noticed by CI. Lol. Rename functions
`s/u_(uint|int)(min|max)/u_\1N_\2/g`. Suggested by Jason. Add some
unit tests that would have caught the copy-and-paste bug before wasting
CI time. Change the implementation of u_intN_min to use the same
pattern as stdint.h. This avoids the integer division. Noticed by
Jason.
v3: Add changes to convert_clear_color
(src/gallium/drivers/iris/iris_clear.c). Suggested by Nanley.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Suggested-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12177>
The `argument::size` is supposed to represent the size of a pointer on
the host and not on the device (for which argument::target_size`
exists).
v3: Use `sizeof(buf)` instead of `marg.size`. (Francisco Jerez)
Fixes: 7c6f1d3bf9 ("clover/nir: extract constant buffer into its own section")
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Pierre Moreau <dev@pmoreau.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10256>
By adding comments regarding which version or extension introduced the
following dispatched functions, it makes it easier to glance at the
table and see which functions are missing for a particular version, but
more importantly makes it easier to compare against cl_icd.h and see if
anything is missing.
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Signed-off-by: Pierre Moreau <dev@pmoreau.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10256>
This resolves clover returning `CL_INVALID_ARG_SIZE` whenever the OpenCL
CTS called `clSetKernelArg()` for 3-component vectors.
Fixes: 2147386505 ("clover/spirv: Add functions for parsing arguments, linking programs, etc.")
v2: Remove “api/clsetkernelarg/set kernel argument for cl_int3” from the
expected fails for llvmpipe
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Signed-off-by: Pierre Moreau <dev@pmoreau.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10256>
OpenCL only has an upper limit on the size taken by all arguments to a
kernel (implementation-defined, but at least 1024 bytes), and not on the
count of those arguments.
This fixes OpenCL-CTS’s api.min_max_parameter_size.
v2: Use `numeric_limits<>::max()` instead of hardcoded value.
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Signed-off-by: Pierre Moreau <dev@pmoreau.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10256>
Instead of hardcoding a fixed version for all devices, compute the
highest version supported by a device based on the different constraints
mandated by each new version.
For example, besides new functionalities, OpenCL 1.1 also increases the
minimum limits regarding the amount of local memory and the amount of
bytes taken by all arguments to a kernel. Some hardware (such as all
GPUs from NVIDIA’s Tesla micro-architecture) can support the additional
features but do not pass those new minimums.
v3:
* Change `get_highest_supported_version()` to return the version instead
of modifying the version components passed as arguments. (Francisco
Jerez)
* Tweak the line wrapping for `has_extension()`. (Francisco Jerez)
v2:
* Invert the ordering of OpenCL and OpenCL C version, to restrict OpenCL
version based on supported OpenCL C version.
* Rename `get_supported_version()` to `get_highest_supported_version()`;
* Use device methods to query parameters instead of manually executing
them;
* Clarify that the limit checking is only for non-custom devices
supporting the full profile.
* Check for mandatory extensions as well;
* Validate CL_DEVICE_MEM_BASE_ADDR_ALIGN;
* Fix the OpenCL>=1.1 minimum limit for CL_DEVICE_LOCAL_MEM_SIZE, from
32 * 1000 to 32 * 1024;
* Restrict to OpenCL 1.0 if OpenCL C 1.1 is not supported.
* Compute the highest supported version based on constraints (ignoring
2.x versions).
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Signed-off-by: Pierre Moreau <dev@pmoreau.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10256>
SRV descriptors can require state-transitions before it's legal to set
them on the command-list. We used to just set them right away, and get
away with is, because the validator didn't verify this because we used
to flag the parameters as volatile.
Now that we don't, we trigger validation errors when setting a root
parameter that needs a transition first.
So let's split up the logic a bit, so we can prepare the tables, then do
the transision, and finally set the tables. We do this for all tables
instead of just the SRVs, just because it makes the logic a bit easier to
follow. We leave root constants alone, because they will never require
this, and doing them late would just compilcate things.
Fixes: 1208290558 ("d3d12: Sets all SRV descriptors as data-static")
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Bill Kristiansen <billkris@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12187>
Most of the drivers don't set up the maximum value in the query info. So
when later hud_pane_set_max_value() is invoked, we are using a rather
"random" number.
Turns out that in some 32bit cases, this random number is big enough
that `leftmost_digit` is 0 because DIV_ROUND_UP() overflows, aborting
with an assertion.
Fixes: c91cf7d7d2 ("gallium: implement a heads-up display module")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12181>
Now that we've disabled brilinear and have per-pixel cube derivatives, we
can use the same rendering paths that end users will see.
In a few cases, we switch to the no_quad_lod option instead, because
otherwise we get a piglit failure.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12125>
This is where it should be rather than having to pass it into the
optimisation pass every time.
It also allows us to call the loop analysis pass without having to
duplicate these options which we will do later in this series.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12064>
This fixes a hang in the following piglit test when GCM moves a
UBO load outside of the loop.
tests/shaders/ssa/fs-if-def-else-break.shader_test
The end NIR ends up looking like this:
vec2 32 ssa_3 = intrinsic load_ubo (ssa_2, ssa_0) (0, 1073741824, 0, 0, 8)
vec1 32 ssa_4 = mov ssa_3.x
vec1 32 ssa_5 = inot ssa_3.y
/* succs: block_1 */
loop {
...
if ssa_5 { }
}
Fixes: 1edf67fc3f ("intel/fs: Generate if instructions with inverted conditions")
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12064>
Add support for performance counters when using the simulator.
v2 (Iago):
- Remove brackets from single-line conditionals
- Rename channel to channels
- Ensure perfmon start/stop function is implemented in all versions
- Use an array for perfmons instead of hash table
- Implement performance counters in CSD
v3 (Iago):
- Rename PERFMON_CHUNKS to PERFMONS_ALLOC_SIZE.
- Merge increasing lastid and ensuring space in a single function.
v4 (Iago):
- Assert perfid <= perfmons_size.
v7 (Iago):
- Do not stop perfmon on each submission
v8 (Iago):
- Add comment about stopping the perfmon when retrieving values.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10666>
These queries are used to retrieve the different hardware counters
values, useful to detect performance issues.
v2 (Iago):
- Fix copyright
- Assert hwperfmon exists
- Print message on error
- Rename hwperfmon structure to make it clear
v4 (Juan):
- Save last_job_fence when perfmon is stopped
v5 (Juan):
- No need to ask for counter values if no job was submitted
v6 (Juan):
- Ensure to flush all jobs before capturing last job fence
v7 (Iago)
- No braces for single-line body conditionals
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10666>
When a performance monitor is enabled in the context, all the jobs
submitted to the kernel will have attached this monitor ID, so the
kernel will measuring the performance counters selected in the monitor
when these jobs are executed by the GPU (accumulating the results).
v2 (Iago):
- Update comment
- Assert fence is not NULL
- Assert has_perfmon when using perfmon
- Rewrite conditional
- Implement performance counters in CSD
v4 (Juan):
- Track previous perfmon and sync BCL if required (Juan).
- Track if a job with perfmon was submitted (Juan)
v7 (Iago)
- No braces for single-line body conditionals
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10666>
A number of android games are so far, sadly, unaware of open source
drivers. And when they see an unknown driver they lump it in the lowest
performance tier, artificially limiting framerate and/or gfx settings.
So until the games catch up, use driconf to override vendor/renderer
settings for moar fps and nicer gfx.
Furthermore, some games seem to be limiting *too* conservatively when
we otherwise have plenty of headroom even if we claim to be a bigger
adreno. Possibly a concession to battery life or tighter thermal
constraints in a phone, as compared to something like a chromebook.
Or maybe the flagship gaming phone thing is a scam ;-)
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12135>
This will give the driver a chance to set a device name separate from the
driver name, using info probed during screen creation. All drivers
querying driconf in screen creation now have to call parsing on their own,
but other drivers get fallback parsing after screen creation.
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12135>
Break it up into vn_{device,instance,physical_device}.c. Suggested by
Ryan Neph.
vn_EnumerateDeviceExtensionProperties and
vn_EnumerateDeviceLayerProperties were previously said to be device
commands. But in this commit, we move them to vn_physical_device.c
instead.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12144>
Fixes
In file included from ../src/gallium/drivers/iris/iris_query.c:49:
../src/gallium/drivers/iris/iris_genx_macros.h:81:10: fatal error: genxml/genX_bits.h: No such file or directory
and
In file included from ../src/gallium/drivers/crocus/crocus_query.c:50:
../src/gallium/drivers/crocus/crocus_genx_macros.h:86:10: fatal error: genxml/genX_bits.h: No such file or directory
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12149>
This lower each 64-bit vertex element into 1 or 2 32-bit vertex elements.
The motivation is to simplify st/mesa, which uses a lot more complicated
code to do the same thing, and do the lowering only on a cso_cache miss.
Reviewed-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11370>
A future commit will replace st_vertex_program::input_to_index with
a prefix bitcount of inputs_read, but it needs vertex inputs to be
in the same order as vertex attribs.
Some of the FF definitions don't make sense with this ordering and are
removed.
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11370>
We would determine that it was unsupported, then ask for the size and
triggered the assertion checking that we never ask for the size of a
combined sampler.
Fixes: ee3495e465 ("turnip: Add support for VK_VALVE_mutable_descriptor_type")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12148>
Blob advertises { 1024, 1024, 64 }, but from tests they all
could be 1024.
Fixes tests:
dEQP-VK.compute.basic.max_local_size_x
dEQP-VK.compute.basic.max_local_size_y
dEQP-VK.compute.basic.max_local_size_z
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9409>
To properly init buffer memory requirement for AHB, memory type bits
from dma_buf fd properties need to be masked. However, creating a test
AHB at buffer creation is too costy. This patch caches the ahb backed
buffer memory type bits at device creation time if the app is requesting
AHB extension.
Cc: 21.2 mesa-stable
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12171>
These are not needed anymore, because the EXEC mask doesn't depend on them.
Fossil DB results on Sienna Cichlid (with NGGC on):
Totals from 58239 (45.27% of 128647) affected shaders:
Latency: 138113669 -> 138285372 (+0.12%)
InvThroughput: 22404840 -> 22405245 (+0.00%)
No Fossil DB changes with NGGC off.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11908>
This prevents us from recalculating the EXEC mask later
in the shader, and removes the requirement for
counting the number of primitives.
The stats are better than expected because they also
show that some code that is still there is now DCE'd by ACO.
Fossil DB results on Sienna Cichlid (with NGGC on):
Totals from 58239 (45.27% of 128647) affected shaders:
SpillSGPRs: 330 -> 340 (+3.03%)
CodeSize: 166356072 -> 162805724 (-2.13%)
Instrs: 31920041 -> 31089256 (-2.60%)
Latency: 138815742 -> 138113669 (-0.51%); split: -0.54%, +0.03%
InvThroughput: 22459553 -> 22404840 (-0.24%); split: -0.26%, +0.02%
SClause: 753746 -> 753765 (+0.00%); split: -0.00%, +0.01%
Copies: 3226647 -> 3268973 (+1.31%); split: -0.45%, +1.76%
Branches: 1223441 -> 1223440 (-0.00%); split: -0.00%, +0.00%
PreSGPRs: 2025339 -> 2091013 (+3.24%)
No Fossil DB changes with NGGC off.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11908>
This avoids re-calculating the exec mask for ES vertices,
and makes it unnecessary to count the number of vertices left.
Fossil DB results on Sienna Cichlid (with NGGC on):
Totals from 58239 (45.27% of 128647) affected shaders:
CodeSize: 166521108 -> 166356072 (-0.10%); split: -0.10%, +0.00%
Instrs: 31961308 -> 31920041 (-0.13%); split: -0.13%, +0.00%
Latency: 138820463 -> 138815742 (-0.00%); split: -0.04%, +0.04%
InvThroughput: 22460177 -> 22459553 (-0.00%); split: -0.00%, +0.00%
SClause: 753744 -> 753746 (+0.00%)
Copies: 3093140 -> 3226647 (+4.32%); split: -0.03%, +4.34%
No Fossil DB changes with NGGC off.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11908>
Instead of v_bfe + v_lshl_or for each vertex, get all 3 edge flags
at once of every vertex. This takes fewer VALU instructions than
previously.
Fossil DB results on Sienna Cichlid (with NGGC on):
Totals from 56917 (44.24% of 128647) affected shaders:
CodeSize: 161028288 -> 158751628 (-1.41%)
Instrs: 30917985 -> 30519571 (-1.29%)
Latency: 130617204 -> 129975532 (-0.49%); split: -0.50%, +0.01%
InvThroughput: 21280238 -> 20927401 (-1.66%)
Copies: 3011120 -> 3011125 (+0.00%); split: -0.00%, +0.00%
No Fossil DB changed with NGGC off.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11908>
We were trying to calculate how much space they need, That was already
difficult and one of the most opaque and hard-to-verify uses of sub_cs,
but it will become even more difficult with the 3D path. What's worse is
that sometimes we have to touch that path when we start touching
registers that would affect rasterization, and there's no indication
that you have to then recalculate the size etc. Just rip this out and
start keeping a separate CS for it instead. Note that this adds a small
amount of memory wastage and extra buffers (at worst one buffer per
command buffer).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12102>
Now that the vertices attributes are in RAM, we can easily
compute their hash and compare to earlier vertices (in the
same list so they have compatible vertex_size).
We can't do that for list that will be executed using
loopback because the replay code ignore the index buffer.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11927>
Previously vertices were uploaded on-the-fly: each time
the position attribute was set, the newly added vertex
was copied to the mapped bo.
Replace this with a plain RAM buffer, and do the upload
at the end of compile_vertex_list.
This allows to remove the we-need-to-unmap-the-buffer-
before-drawing special case, but more importantly it
will allow to implement vertices deduplication in the
next commit.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11927>
Two threads enter and see *id == 0. Both threads update the value.
Upon returning, one of the threads might see the overwritten value some
of the time and the updated value other times. Use cmpxchg to ensure
that there's only ever one value written to *id.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12136>
There are two problems with the current architecture.
In OpenGL, the id is supposed to be a unique identifier for a particular
log source. This is done so that applications can (theoretically)
filter particular log messages. The debug callback infrastructure in
Mesa assigns a uniqe value when a value of 0 is passed in. This causes
the id to get set once to a unique value for each message.
By passing a stack variable that is initialized to 0 on every call,
every time the same message is logged, it will have a different id.
This isn't great, but it's also not catastrophic.
When threaded shader compiles are used, the id *pointer* is saved and
dereferenced at a possibly much later time on a possibly different
thread. This causes one thread to access the stack from a different
thread... and that stack frame might not be valid any more. :(
I have not observed any crashes related to this particular issue.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12136>
There are two problems with the current architecture.
In OpenGL, the id is supposed to be a unique identifier for a particular
log source. This is done so that applications can (theoretically)
filter particular log messages. The debug callback infrastructure in
Mesa assigns a uniqe value when a value of 0 is passed in. This causes
the id to get set once to a unique value for each message.
By passing a stack variable that is initialized to 0 on every call,
every time the same message is logged, it will have a different id.
This isn't great, but it's also not catastrophic.
When threaded shader compiles are used, the id *pointer* is saved and
dereferenced at a possibly much later time on a possibly different
thread. This causes one thread to access the stack from a different
thread... and that stack frame might not be valid any more. :(
This fixes shader-db crashes of various kinds on Iris with threaded
shader compiles enabled.
Fixes: 42c34e1ac8 ("iris: Enable threaded shader compilation")
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12136>
Similar to the fix in 6bf8e960fa ("pan/bi: Do helper termination
analysis on clauses")
Though apparently a "theoretical issue only", fixes artefacts in
DarkPlaces with both D3D9 and GL renderers.
Fixes: 9a7f0e268b ("pan/mdg: Use the helper invo analyze passes")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12156>
While char is signed on macOS AArch64, on Linux it is unsigned. This
means it cannot represent the -1 return value of getopt_long.
Change the type of `c` to int, the type that getopt_long returns, so
that the -1 will be kept intact and can be checked for.
Fixes: c6be4f85e3 ("pan/bi: Use getopt for bifrost_compiler")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12153>
Both Panfrost and the DDK add padding zero bytes to the end of
shaders, so we can use this instead of the end-of-shader clause for
checking whether to stop disassembling.
Shaders can have end-of-shader clauses partway through; these shaders
will now be completely disassembled instead of cut off at the first
end-of-shader clause.
A tag byte of zero is an invalid encoding, so unlike the previous
version of this test only check the first word.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12153>
Rather than just printing an offset such as '(pc + 192)', print the
target of branches as a clause number that matches up with the clause
headers printed by disassemble_bifrost.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12153>
There's no need for us to do this lowering ourselves while emitting
code, when there's already a helper that can do this for us that we're
even using. Let's just set the right flag, and not worry about
projectors any more.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12126>
The existing code handled the case where the new definition of the
same field was larger than the old one.
This commit adds a check to handle the reverse case: the new def
is smaller than the old one (= so writing using the merged macro
would affect the next fields).
The affected fields are:
* LGKM_CNT (in SQ_WAVE_IB_STS)
* DONUT_SPLIT (in VGT_TESS_DISTRIBUTION)
* HEAD_QUEUE (in GDS_GWS_RESOURCE)
DONUT_SPLIT is the only one used by radeonsi/radv.
Fixes: e6184b0892 ("amd/registers: scripts for processing register descriptions in JSON")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12063>
Otherwise there is an uninitialized read, and the register allocation
will fail. (In the sense of failing a precondition. This manifests as
synthetic interference leading to higher register pressure and useless
moves. The allocation itself is ok, but it indicates a real bug.)
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12130>
When Valhall lands, we'll need to be more methodical about this. In the
mean time, this gets validation passing on
KHR-GLES31.core.compute_shader.atomic-case3 which was crashing in RA and
now again passes.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12130>
This is much more maintainable, extensible, and easy to read than
hand-rolled structs approximating assembly. This also removes the last
use of the old hand-written packing structs. There are a few minor
differences:
- The shaders are larger because ir3 currently doesn't support (rpt),
which means that some shaders are larger than one instrlen and the
current logic has to be extended to allow for that. This seems a small
price to pay, ir3 will gain support for (rpt) eventually, and we
shouldn't have limitations like this baked in anyway. For example some
GL blob r8g8 <-> r16 copy shaders are apparently quite large.
- Due to the inability to switch inputs/outputs on the fly, we need to
split the VS into two variants. I made the layer-writing variant also
used for other clears, because the old method of overloading c0.z/c1.z
to mean both "src x coordinate" and "z clear value" in the same shader
seemed too clever and I didn't want to add yet another variant. This
means that non-layered clears will also write the layer (to 0), but
that shouldn't be a big deal performance-wise.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12079>
If the passed VkPipelineRasterizationLineStateCreateInfoEXT wasn't zero
initialized, we copy garbage values that are later on used to set the
state and may end up crashing when they are beyond the limits of the HW.
v2 (Lionel): Simplify if condition
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12121>
Failure to create a buffer for scanout should not be fatal when
importing a buffer. Buffers allocated from a render-only device may not
be able to scanned out directly but can still be used for other
rendering purposes (e.g. as a texture).
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12081>
Hand typed. We could generate this from the XML to avoid the repititon
but I think the cure is worse than the disease.
This fixes instruction encoding faults seen in conformance tests.
Only a single shader-db affected, and it was likely already broken...
quadwords HURT: shaders/glmark/22-1.shader_test MESA_SHADER_FRAGMENT: 133 -> 135 (1.50%)
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12114>
The previous logic was returning a handle valid for the render-only
device if rsc->scanout was NULL. However the caller doesn't expect
this: the caller will use the handle with the KMS device.
Instead of returning a handle for the wrong device, fail if we don't
have one.
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12074>
The previous logic was returning a handle valid for the render-only
device if rsc->scanout was NULL. However the caller doesn't expect
this: the caller will use the handle with the KMS device.
Instead of returning a handle for the wrong device, fail if we don't
have one.
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12074>
The previous logic was returning a handle valid for the render-only
device if rsc->scanout was NULL. However the caller doesn't expect
this: the caller will use the handle with the KMS device.
Instead of returning a handle for the wrong device, fail if we don't
have one.
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Emma Anholt <emma@anholt.net>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12074>
The previous logic was returning a handle valid for the render-only
device if rsc->scanout was NULL. However the caller doesn't expect
this: the caller will use the handle with the KMS device.
Instead of returning a handle for the wrong device, fail if we don't
have one.
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12074>
A previous commit cleaned up the asserts but the last part of
this assert looks like it got mixed up. It should have allowed
param->rel for D3DSPR_INPUT if version is 3.0. Instead it does
&& on the enum value D3DSPR_ADDR which is of course always true,
with the version check. The result is that we miss input
validation with version 3.0.
Spotted by a compile warning
Fixes: 5974401a4a ("st/nine: Regroup param->rel tests")
Reviewed-by: Axel Davy davyaxel0@gmail.com
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11880>
This doesn't perfectly emit all the TXPs we might be able to (if you get
any non-TXP-able projectors, that whole sampler dim gets lowered), but it
should be a big boost to i915g.
softpipe shader-db:
total instructions in shared programs: 2953625 -> 2951201 (-0.08%)
instructions in affected programs: 108901 -> 106477 (-2.23%)
total temps in shared programs: 565869 -> 566632 (0.13%)
temps in affected programs: 8922 -> 9685 (8.55%)
i915g shader-db:
total instructions in shared programs: 372570 -> 370254 (-0.62%)
instructions in affected programs: 39825 -> 37509 (-5.82%)
total tex_indirect in shared programs: 11420 -> 11074 (-3.03%)
tex_indirect in affected programs: 913 -> 567 (-37.90%)
LOST: 0
GAINED: 12
Closes: #4984
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11912>
For TGSI, we need the coordinate, comparator, bias, and LOD all together
in the first two vec4 args, and by doing it in the backend we were
generating extra MOVs.
softpipe shader-db results:
total instructions in shared programs: 2985416 -> 2953625 (-1.06%)
instructions in affected programs: 499937 -> 468146 (-6.36%)
total temps in shared programs: 544769 -> 565869 (3.87%)
temps in affected programs: 105469 -> 126569 (20.01%)
i915g shader-db:
total instructions in shared programs: 371625 -> 369594 (-0.55%)
instructions in affected programs: 24903 -> 22872 (-8.16%)
total tex_indirect in shared programs: 11381 -> 11365 (-0.14%)
tex_indirect in affected programs: 43 -> 27 (-37.21%)
LOST: 7
GAINED: 16
The temps increase is the pre-existing issue that we never release temps
for NIR regs, which doesn't matter much for softpipe (just memory/cache
footprint) but does for i915g as seen by shaders that no longer compile
(though overall we seem to win).
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11912>
These were fixed previously, but due to the CI not really running all
tests any more, I didn't notice these fixes. Let's bring the expected
results up to date.
Fixes: 2e29857bb6 ("llvmpipe: only report supported shader-image formats")
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12077>
All vulkan drivers have been copying anv's code to convert
VkSpecializationInfo into nir_spirv_specialization.
Recently there was a Vulkan spec change on allowed values for
VkSpecializationInfo, and all drivers got affected.
This commits creates a new helper, and uses it on all Vulkan Mesa
drivers.
v2: use (uint8_t*) castings, instead of void*, to avoid C2036 with
MSVC (detected by the CI, inspired on what radv was doing)
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12047>
this simplifies the entire queue mechanism and makes it more consistent:
previously some cases (e.g., null cmdbuf submission) would immediately
be marked as finished, which meant that fences could theoretically become
desynchronized, breaking application assumptions
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12071>
It's non-conformant for GL and Vulkan, and not expected to be a desired
quality/speed tradeoff for applications using llvmpipe. The option is
left in place using GALLIVM_PERF=brilinear.
Causes minor rasterization changes in our traces:
- improved sharpness of the trees in CS
- more consistent mipmap filtering of the ground in CS:Source, STK and the
RaytracedShadows demo.
- changing some aliasing on shadow maps in 0ad (not consistently
visibly better or worse)
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10219>
Now we have all our Bifrost unit tests under meson and can remove the
test entrypoint from bifrost_compiler. This does require a small
refactoring for our util_dynarray handling to make sure we don't leak
memory. Otherwise meson-arm64-asan complains.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12109>
There are a couple minor things that can be improved:
1. Eliminate (or reduce) the dynamic allocation of the
threaded_compile_job.
2. For apps like shader-db, improve the case where nr_threads=0. Right
now this adds thread switching and mutex overhead.
3. Other performance improvements? iris_uncompiled_shader::variants has
some special properties that make it ripe for replacement with a
lockless list. Without gathering some data, it's hard to guess what
impact that could have.
v2: Fix whitespace and formatting issues. Noticed by Ken.
s/threaded_compile_job/iris_threaded_compile_job/g. Suggested by Ken.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11229>
I tried to find a way to break this into some smaller commits, but
everything is very intertwined. :(
When searching the variants list in the iris_uncompiled_shader, add the
new variant if it is not found. This will be necessary for threaded
shader compilation. This conceptually simple change had a bunch of
fallout.
Much of this was at least conceptually borrowed from radeonsi.
- Other threads might find a variant in the list before the variant has
been compiled. To accomdate this, add a fence. Each thread will wait
on the fence in the variant when searching the list.
- A variant in the list may fail compilation. To accomodate this, add a
flag. All paths will examine iris_compiled_shader::compilation_failed
before trying to use the variant.
- The race condition between multiple threads trying to create the same
variant at the same time is handled *before* both thread spend the
effort to compile the shader. The means that iris_upload_shader
cannot change shaders on the caller, so it does not need to return
anything.
v2: Change "found" parameter of find_or_add_variant to "added." This
inverts the values returned, and it probably makes uses of the returned
value more easily understood. Always set the value in the called
function. Suggested by Ken.
v3: Move shader->compilation_failed check to avoid shader != NULL test.
Rearrange some logic and add a comment in iris_update_compiled_tcs.
Suggested by Ken. Don't call find_or_add_variant in
iris_create_shader_state. See
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11229#note_1000843
for more details. Noticed by Ken.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11229>
The added assertion in iris_create_shader_variant helped catch a bug in
the next commit.
v2: Drop (unnecessary) initialization of shader->assembly.res when
moving to iris_create_shader_variant. Suggested by Ken.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11229>
I tried /just/ ref counting the uncompiled shaders, but that is not
sufficient. At the very least, it's a problem for blorp shaders that
only have variants (and no uncompiled shader).
This is in prepartion for using the live shader cache.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11229>
With clang building tests:
../src/gallium/tests/trivial/compute.c:1215:29: warning: taking the absolute value of unsigned type 'unsigned int' has no effect [-Wabsolute-value]
if (abs(((uint32_t *)x)[j] -
^
../src/gallium/tests/trivial/compute.c:1215:29: note: remove the call to 'abs' since unsigned values cannot be negative
if (abs(((uint32_t *)x)[j] -
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12087>
DXVK always inserts vertex stage subpass self-dependency for every
subpass regardless of whether there actually would be a barrier.
This effectively disabled gmem rendering with DXVK.
Thus we delay the decision to disable gmem rendering until we
see a barrier with vertex stages.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12038>
Add a job to test with traces that we cannot redistribute, listed in a
separate file. Since those traces might not be accessible by everyone,
this job is created only when the pipeline is triggered by `marge-bot`.
This job is optional because otherwise it could be blocking a merge
request of someone who cannot really debug the issue due to lack of
access to these traces.
The documentation available under `docs/ci` goes into more details
explaining the rationale behind optional traces.
Signed-off-by: Antonio Caggiano <antonio.caggiano@collabora.com>
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6441>
We can have more than 32 samplers, but the code below will assert in that
case. The return value is not used for samplers, so let's just return
zero early and be done with it.
Fixes: c18ff60087 ("lavapipe: emit correct textures_used for texture-arrays")
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11845>
Under XWayland, the first present after a window resize is sometimes
completed with COPY (seems to happen when the previous present with the
old size is pending; not really sure). The following presents are
completed with FLIP.
When a swapchain is created with an old swapchain, and
old_chain->last_present_mode is FLIP, chain->last_present_mode is set to
FLIP as well. This causes the new swapchain to be marked
VK_SUBOPTIMAL_KHR, which is sticky, if the first present is completed
with COPY.
Instead of inheriting, treat each swapchain as independent. We will
miss the case where an old swapchain is flipping but a new swapchain is
copying. But swapchain reallocation normally happens in response to
present engine state change. If the newly allocated swapchain is
copying, another reallocation is unlikely to fix that.
Fixes: 61309c2a72 ("vulkan/wsi/x11: Return VK_SUBOPTIMAL_KHR for X11")
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12030>
this collects a bunch of changes which need to be made but which can't
be split up incrementally without breaking things:
* move map offset to zink_transfer::offset for consistent handling
* fix stream uploader map rules to only apply for discard cases so
the stream uploader doesn't explode
* fix the staging buffer map rules to apply to any non-staging readback
* stop making huge staging buffers for readback
* break out the DONTBLOCK case since this is only coming from qbo readback
* add explicit read-only sync for maps to stall on writes
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12090>
This handles the following from the Valhall specification (that I wrote):
If multiple subsequent staging registers are accessed, the base must
be aligned to 2. However, even if 4 registers are accessed, it is
not necessary to align to 4, only to 2. This restriction allows the
hardware to use a 64-bit data path without handling unaligned
access, which is more efficient. This restriction does not apply if
only a single register is accessed.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12026>
Decides when we need "branch reconvergence" (canonical term), the
logical opposite of "back-to-back execution" (non-canonical term, this
is old code in Bifrost terms). So invert the return value, rename, and
export so we can use it when packing Valhall instructions.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12026>
Needed to correctly lower sources to moves, used in the FAU lowering.
Technically, the issue is already present on Bifrost, but it's hidden
because Bifrost packing doesn't validate the absense of unsupported
modifiers. Valhall packing adds more safety, which caught this issue.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12026>
Implement resource_get_param for PIPE_RESOURCE_PARAM_NPLANES and fix
resource_get_handle to walk to the correct linked resource for
multiplanar images, allowing gbm_bo_get_handle_for_plane to be called
with plane > 0.
This fixes an assert that is triggered when a wayland client tries
to send weston an NV12 dmabuf, for example:
weston: .../mesa/src/gbm/backends/dri/gbm_dri.c:752: gbm_dri_bo_get_handle_for_plane: Assertion `plane == 0' failed.
Fixes: 788f6dc857 ('Revert "gallium/dri: fix dri2_from_planar for multiplanar images"')
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12037>
When we bring up the Valhall compiler in Mesa, we will like to have a
disassembler in native code, so we shouldn't write our disassembler in
Python. Instead, we write a disassembler generator in Python with mako
templates, which will produce a va_disasm_instr entrypoint from the
architecture defined in ISA.xml and valhall.py.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12025>
This Python script acts as a standalone assembler. It takes Valhall
instructions with Mesa-flavour syntax, parses them, errors out if there
are syntax errors, and writes out an assembled binary if there are not.
It also is available as a programmatic interface for automated testing.
While this attempts to handle syntax errors, it does not check
semantics. It will happily compile programs that fault, provided each
instruction locally 'looks' plausible.
The code itself is quite small, despite supporting most of the known
ISA, because the syntax is regular and the heavylifting is done by
ISA.xml and valhall.py.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12025>
This Python module parses the ISA.xml file added in the previous
commits, extracts all the useful information, and combines it with
extra annotations. In total, it provides a programmatic way to interface
with the Valhall instruction set.
from valhall import instructions, enums
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12025>
This handwritten file is the product of over a hundred hours of
reverse-engineering and represents the sum of what I've learned about
the Valhall architecture. It will be used in the next commits as the
backbone of a Valhall toolchain.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12025>
GALLIVM_PERF_NO_OPT is "belond" to GALLIVM_PERF environment variable,
not GALLIVM_DEBUG. when GALLIVM_PERF=nopt is passed to llvmpipe,
"-sroa -early-cse -simplifycfg -reassociate -constprop -instcombine -gvn"
should not be printed. Those llvm optimation techniques should only be
printed when the default(-O2) optimation is enabled.
$ GALLIVM_PERF=nopt GALLIVM_DEBUG=dumpbc glmark2
Before apply this patch:
Invoke as "opt -sroa -early-cse -simplifycfg -reassociate -mem2reg -constprop -instcombine -gvn ir_setup_variant_0.bc | llc -O2 [-mcpu=<-mcpu option>] [-mattr=<-mattr option(s)>]"
After apply this patch:
Invoke as "opt -mem2reg ir_fs304_variant0.bc | llc -O0 [-mcpu=<-mcpu option>] [-mattr=<-mattr option(s)>]"
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Signed-off-by: suijingfeng <suijingfeng@loongson.cn>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11994>
The code in dri_make_current just checks the value of the pointers
to decide to update texture_stamp or not. This is buggy since a new
allocated drawable could share the same address with the previous
released drawable. Fix the stale pointer issue by always resetting
these pointers to NULL in dri_unbind_context.
v2:
Move the reset codes to the end of the function.
Signed-off-by: Lepton Wu <lepton@chromium.org>
Cc: mesa-stable
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12050>
The current code we have for this is a bit of a mess, likely due to
trying too hard to put it in anv_android.c. The external_format bit in
anv_image, for instance, really means "quit creation early" which is
something we want to do for AHardwareBuffer imports regardless of
whether or not they use a native format. It gets set both by declaring
an AHardwareBuffer external handle type and by VkExternalFormatANDROID.
However, VkExternalFormatANDROID is only allowed for AHardwareBuffer
imports. If we ever did get an external format outside the context of
an AHardwareBuffer import, we would end up with a useless partially
created image.
When we detect an AHardwareBuffer import, we punt off to a function in
anv_android.c that does nothing interesting but call anv_create_image
with AUX disabled and external_format = true. The aux disable here is
useless because the actual isl_surf layout is done by resolve_ahw_image
which also sets ISL_SURF_USAGE_DISABLE_AUX_BIT. As far as external
formats go, anv_image_from_external() sets it regardless of whether or
not there is actually an external format.
This commit replaces anv_image::external_format with anv_image::from_ahb
which is the thing we actually want to track for this. We delete
anv_image_from_external and a bunch of the external_format handling
because it's all useless. The end result is massively simpler and,
while it appears to blur the boundary between Android code and the rest
of the driver, it makes the whole flow more obvious.
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12040>
The comment was incorrect: we can have N draws using the
same mode with N > 1 (eg: GL_QUAD_STRIP draws
cannot be merged).
This commit fixes the drawing code to use the correct draw
function.
This fixes a hang in Starsector (see issue #5086).
Fixes: b328d8e9bc ("dlist: use an union instead of allocating a 1-sized array")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11978>
When multiview is enabled, queries must begin and end in the
same subpass and N consecutive queries are implicitly used,
where N is the number of views enabled in the subpass.
Implementations decide how results are split across queries.
In our case, only one query is really used, but we still need
to flag all N queries as available by the time we flag the one
we use so that the application doesn't receive unexpected errors
when trying to retrieve values from them.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12034>
When multiview is enabled, we no longer care about when a particular
attachment is first or last used in a render pass, since not all views
in the attachment will meet that criteria. Instead, we need to track
each individual view (layer) in each attachment and emit our stores,
loads and clears accordingly.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12034>
The Vulkan spec states that when multiview is enabled the number of
layers in the framebuffer is set to one and that each attachment
must then have at least as many layers as referenced by view masks
in the subpasses in which is used.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12034>
When the dot product uses a source which can be optimized to a scalar,
after a bunch of nir optimization steps the source to fsum will be a scalar
with a x replicate swizzle. Hence nir_src_num_components is just 1 and the
fsum was just a no-op which is not correct. Arguably this could be optimized
a bit better, but just determine the number of addends by using nir_op_infos
instead (the operand fetch was fixed already by 39a938ecf4 doing the same).
Fixes: 4eb0475b5a ("gallivm/nir: add fsum support")
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12066>
This patch allows to shrink vecN instructions where
one or more components at any position are unused.
Stat changes for softpipe:
total instructions in shared programs: 2986101 -> 2985416 (-0.02%)
instructions in affected programs: 51216 -> 50531 (-1.34%)
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11411>
ALU instructions of which not all components are read,
can be shrunk to the number of read components.
Previously, this would only remove trailing components.
This patch enables to remove components from any position.
Stat changes for softpipe:
total instructions in shared programs: 3001291 -> 2984698 (-0.55%)
instructions in affected programs: 225585 -> 208992 (-7.36%)
total loops in shared programs: 1389 -> 1358 (-2.23%)
loops in affected programs: 36 -> 5 (-86.11%)
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11411>
In v3dv_write_uniforms_wg_offsets() function, the job's cmd_buffer is a
valid command buffer, so there is no reason to check if its NULL or not.
This fixes CID#1487441 ("Dereference after null check") error.
v1:
- `job->cmd_buffer` is the same as `cmd_buffer` (Alejandro)
v2:
- Use `cmd_buffer` instead of `job->cmd_buffer` (Iago)
Fixes: 31a786c80a ("v3dv: handle QUNIFORM_FB_LAYERS")
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11999>
We started doing this in:
commit 4d6d55deef
Author: Tapani Pälli <tapani.palli@intel.com>
Date: Mon Sep 26 10:03:32 2016 +0300
egl: stop claiming support for pbuffer + msaa
This fixes a crash in egl-create-msaa-pbuffer-surface Piglit test
and same crash in many dEQP EGL tests.
Whatever bug that was papering over appears to be fixed by now, I can
no longer reproduce that crash with piglit. Furthermore, disabling that
bit in the generic dri2 code had the side effect that the surfaceless
platform would advertise EGLConfigs with _no_ supported surface types
(since surfaceless only supports pbuffers).
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/1859>
Only fragment and some compute shaders support implicit derivatives.
They're totally meaningless without helper invocations and some
understanding of the dispatch pattern. We've got code to lower
nir_texop_tex in these shader stages to use an explicit derivative of 0
but it was pretty badly broken:
1. It only handled nir_texop_tex, not nir_texop_txb or nir_texop_lod.
2. It didn't take min_lod into account
3. It was conflated with adding a missing LOD parameter to opcodes
which expect one such as nir_texop_txf. While not really a bug,
this does make it way harder to reason about the code.
4. Unless you set a flag (which most drivers don't), it left the
opcode nir_texop_tex instead of nir_texop_txl which it should have
been.
This reworks it to go through roughly the same path as other LOD
lowering only with a constant lod of 0 instead of calling out to
nir_texop_lod. We also get rid of the lower_tex_without_implicit_lod
flag because most drivers set it and those that don't are probably
subtly broken. If someone really wants to get nir_texop_tex in their
vertex shaders, they can write a new patch to add the flag back in.
Fixes: e382890e25 "nir: set default lod to texture opcodes that..."
Fixes: d5ac5d6e83 "nir: Add option to lower tex to txl when..."
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11775>
Switch from using debug_control structure to debug_named_value
structure.
The main nice feature is that it provides a "help" option, so using
"V3D_DEBUG=help" will print all the debug options with a brief
description.
Useful to avoid going to https://docs.mesa3d.org/envvars.html everytime
we need to know the available options.
v1:
- Modify a couple of debug option documentation (Alejandro)
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12036>
Required to build Mesa on macOS with
-Dbuild-tests=true -Dglx=gallium-xlib
Without this change, the build fails with
In file included from ../src/gallium/targets/graw-xlib/graw_xlib.c:8:
../src/gallium/include/frontend/xlibsw_api.h:5:10: fatal error: 'X11/Xlib.h' file not found
#include <X11/Xlib.h>
With `brew sh` X11 is found but linking fails due to `llvm-ar` missing
in the path. That issue appears to be unrelated to this missing
dependency. X11 is installed via XQuartz, so Homebrew should not be
required.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12022>
This expands on commit c54c42321e. See the code comment for full
justifications. At the time of the previous commit Ian wanted to
limit the relaxing of the rule to GLSL 3.30 as that was the highest
version of shaders seen in the wild that were having trouble with
the stricter rules.
However since then I've found that the long standing issue with tess
shaders failing to compile in the game 'Layers Of Fear' is due to
this same issue. The game uses 4.10 shaders and also makes use of
explicit varying locations, so here we relax the rule to 4.20 and
make sure to apply the restriction to shaders using varyings with
explicit locations also.
Fixes: c54c42321e ("glsl: relax rule on varying matching for shaders older than 4.00")
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11873>
I was trying to fix this test, but noticed brw_clip.c in i965
does a * 2 here, and it seems to fix this test as well.
Fixes:
dEQP-GLES2.functional.polygon_offset.default_displacement_with_units
Fixes: f9e2c24326 ("draw,llvmpipe,util: add depth bias calculation for arb_depth_buffer_float")
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12029>
glsl_to_tgsi had been emitting outputs in sorted order, and it seems virgl
has a dependency on that -- it collects outputs into an array and indexes
by the subtracting the ".First" value of the first one seen, even if
that's not the first entry in the array.
Fixes the regressions in deqp-gles2 on virgl with ST_DEBUG=force_nir, and
fixes neverball trace rendering.
Reviewed-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11934>
VK CTS has a test that does -256 for sample index but since we use
signed >= we fail and write to random memory, changing to uint here
for comparisons for out of bounds and address calcs should ensure,
we stay within bounds even for negative vals.
Remove unused int_type/bld while here.
Fixes dEQP-VK.texture.multisample.invalid_sample_index.sample_count_4
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11913>
For compute shaders stats avail was never signalling because nothing
flushed.
Fixes dEQP-VK.query_pool.statistics_query.host_query_reset.compute_shader_invocations.64bits_cmdcopyquerypoolresults_primary
and others
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11913>
Fixes the warning caught by clang (why did gcc miss this one?)
../src/panfrost/bifrost/bifrost_compile.h:81:45: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides]
.lower_bitfield_extract_to_shifts = true,
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12003>
The enums alias. Fixes the following warning under clang:
../src/panfrost/bifrost/bifrost_compile.c:2515:25: warning: implicit conversion from enumeration type 'enum bifrost_texture_fetch' to different enumeration type 'enum bifrost_lod_mode' [-Wenum-conversion]
BIFROST_TEXTURE_FETCH_TEXEL;
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12003>
We need it in the next commit to replace setting the stack alignment on
i386 with LLVM >= 13 through the TargetOption::StackAlignmentOverride,
which was removed in the upstream commit
<3787ee4571>.
Unfortunately Module::setOverrideStackAlignment() is not available
through the C API and we need to wrap it ourselves.
Signed-off-by: Kai Wasserbäch <kai@dev.carbon-project.org>
Reference: mesa/mesa#4906
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11940>
This new EGL extension has been introduced in [1].
When we have a DRM device and a render node, we can advertise the
extension and return the render node name for the
EGL_DRM_RENDER_NODE_FILE_EXT query.
For the special software EGL device, we can advertise the extension
and return NULL for the EGL_DRM_RENDER_NODE_FILE_EXT query, because
we can guarantee that llvmpipe will never use a render node for
rendering operations.
However, llvmpipe might be using a primary node when used with the
GBM platform. So we can't advertise EXT_device_drm in this case.
When we have a DRM device but no render node, that means we're on a
split render/display SoC. We _should_ return the render node used
by the renderonly driver, however Mesa needs more plumbing to allow
this, so let's just disable the extension for now.
[1]: https://github.com/KhronosGroup/EGL-Registry/pull/127
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11797>
Unfortunately I contacted the dev about this issue years ago and he
made a fix, but it has never been released after all these years.
This stops the screen from being completely black in game.
CC: mesa-stable
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11941>
tracking mem usage on the context is bad because if an app is always using
a large amount of memory across multiple batches, it triggers the oom flushes
on every flush and forces fencing
instead, add an explicit flag for oom flushing and another for stalling, then
flag oom flushing and stalling as needed, with set_framebuffer_state being an
additional flush point now since it's guaranteed not to split renderpasses
also proactively prune pending batch states if there's a lot of them
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11965>
Before commit f7e0cdcf1a, we tried these in order
- if (!ForceSoftware) surfaceless_probe_device(disp, false);
- surfaceless_probe_device(disp, true);
- surfaceless_probe_device_sw(disp);
The commit changed it to
- surfaceless_probe_device(disp, ForceSoftware);
- surfaceless_probe_device_sw(disp);
and broke 2D virtio-gpu and vgem when ForceSoftware is false. This
commit restores the old behavior.
Fixes: f7e0cdcf1a ("egl/surfaceless: simplify dri2_initialize_surfaceless()")
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11992>
This was still used in the linear branch, since it works all a little
differently there (in particular, when using guard band we have to
intersect the draw regions with the viewport, since draw won't clip
for us). However, we should always intersect with draw_regions
(regardless if that includes the intersection with vp or not), since
the viewport can be larger than the fb size, and we don't want to
draw outside the fb (usually harmless, but important for occlusion
queries and shader image/buffer writes).
This fixes various dEQP-GLES31.functional.fbo.no_attachments failures
(which uses oversized viewport with occlusion queries).
The other ci changes aren't really bugs (the humus/Portals image
looks the same, we cannot expect bit-identical results, and
for the piglit quad-invariance test, I think we merely passed it
by accident since our interpolation may give different results
depending on where on the screen a tri is regardless of linear
rasterizer).
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11969>
This change adds:
- an alternative rasterizer, which rasterizes bins in a left->right &
top->bottom linear fashion;
- triangle -> rectangle detection;
- 1:1 blit detection;
- a special TGSI -> LLVM IR code generation that uses 8-bit SSE integers
in AoS fashion (as opposed to 32bits floats.)
Altogether these changes yield a 2x to 3x performance improvement for 2D
workloads. It was designed to render Windows 7 Aero and other Windows
built-in 3D applications (like Windows Media Player, Internet Explorer
11, UWP applications) with minimum CPU utilization, but it should be
generally applicable to other 2D-on-3D applications, like desktop
compositors, HTML browsers, 3D based UI toolkits, etc.
This was mostly the brainchild of Keith Whitwell back in 2010. I wrote
TGSI -> AoS translation. And many others added bug-fixes and
enhancements over the years: Roland Scheidegger, Brian Paul, and James
Benton.
Known issues:
- piglit spec@!opengl 1.1@quad-invariance will warn that "left and right
half should match" due to rounding error difference
- These optimized paths to kick in is that depth-buffer must not be
used, so some applications which want to benefit from these improvements
might need to be modified to ensure they use painter's algorithm instead
of depth-buffers.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Acked-by: Keith Whitwell <keithw@vmware.com>
v2: Incorporate Dave Airlie feedback: cleanup LP_DEBUG_xx; shrink 3+
empty lines.
v3: silence unused var warning, adapt to new upstream code (point setup)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11969>
This changes the pass to extract pinned instructions and not just unpinned
instructions when rescheduling instructions. This stops pinned instructions
from being bunched together when instructions are reinserted into the blocks
which can result in regressions with regards to cycles and instruction
counts on i965 and register use/Max Waves on AMD hardware.
In order to do this we also throw away the post-order depth-first
search linearization algorithm used to re-insert the instructions, which
itself causes possible regressions when instructions are reinserted into
a less than ideal new order (of which the bunched together pinned
instructions is one example). Instead we simply insert instructions in the
reverse order they were extracted. This will simply place instructions
that were scheduled earlier onto the end of their new block and
instructions that were scheduled later to the start of their new block.
With this everything should remain in order without the need to run
over uses.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/597>
With this pass enabled in Intel drivers, running shader-db on
shaders/unity/38.shader_test resulted in
Program received signal SIGSEGV, Segmentation fault.
gcm_schedule_early_src (src=0x555555d45348, void_state=0x7fffffffba40) at ../../SOURCE/master/src/compiler/nir/nir_opt_gcm.c:297
297 if (info->early_block->index < src_info->early_block->index)
(gdb) print src_info->early_block
$1 = (nir_block *) 0x0
I tracked this down to an early exit from gcm_schedule_early_instr on
the parent instruction because instr->pass_flags was 0x1c. That
should be an impossible value for this pass, so I inferred that
pass_flags must have dirt left from some previous pass.
Fixes: 8dfe6f672f ("nir/GCM: Use pass_flags instead of bitsets for tracking visited/pinned")
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/597>
Without this patch the egl symbols check test fail on mips platform:
72/87 mesa:egl / egl-symbols-check FAIL 0.20s (exit status 1)
src/egl/libEGL.so.1.0.0: unknown symbol exported: _fbss
src/egl/libEGL.so.1.0.0: unknown symbol exported: _fdata
src/egl/libEGL.so.1.0.0: unknown symbol exported: _ftext
See Mips Run say thoes special symbols are automatically defined by the
linker to allow programs to discover the start and end of their various
section. They are descended from conventions that grew up in UNIX-like OSs,
and are peculiar to the MIPS environment.
_fbss : Start of uninitialized data segment
_fdata : Start of initialized data segment
_ftext : Start of text segment
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: suijingfeng <suijingfeng@loongson.cn>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11955>
ls3a4000 and ls2k1000 cpu is mips64r5 compatible with MSA SIMD
instruction set implemented, while ls3a3000 is mips64r2 compatible only.
Due to lacking llvm support for loongson CPU, llvm::sys::getHostCPUName().
return "generic" on all loongson mips CPU.
So we override the MCPU to mips64r5 if MSA is implemented, feedback to
mips64r2 for all other ordinaries.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: suijingfeng <suijingfeng@loongson.cn>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11955>
This is a port of the softpipe anisotropic filtering
to llvmpipe. It should produce pretty similiar results.
This contains the proposed fix to the softpipe calculating
dq after scaling.
It also contains a number of other fixes around vector lengths
etc caught during test.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8804>
The rules here are the same as for texture instructions. The bits on
the intrinsic are the ground truth and are allowed to vary from the
deref a bit as-needed. If the intrinsic says PIPE_FORMAT_NONE, then we
can look at the variable, if visible, to get format information. This
means that we need to be careful when we rewrite intrinsics based on the
deref to only override the format from the _deref intrinsic from the
image variable unless the intrinsic is PIPE_FORMAT_NONE.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11849>
Semantically, -1 means "Unknown; don't validate" but it's really only
used for derefs because they often need to be flexible. We don't really
need that flexibility for image intrinsics but this makes it more
consistent. More immediately useful is that this gives us the ability
to tell _deref forms of these intrinsics apart from the lowered ones.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11849>
Some drivers doesn't support PIPE_SHADER_CAP_INTEGERS.
This leads to using load_ubo_vec4 which throws llvmpipe off the guard since
it doesn't expect load_ubo_vec4 in shader. Use nir_to_tgsi utility in
such a case.
This fixes crash seen with conform's mustpass.c, select.c and feedback.c.
Also, few gl-select related piglit tests exhibit same crash. Found in vmware's
internal testing
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
v2: incorporated Emma's comments. Added check for PIPE_SHADER_CAP_INTEGERS and
remove PIPE_SHADER_IR_TGSI check
v3: As per Emma's comment, removed expected crashes for i915 piglit
v4: update expetcted passes
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11911>
tc drivers set this based on os_get_total_physical_memory()/divisor,
which is going to be totally wrong for 32bit processes and explode
the address space
this util function can be used to handle per-platform clamping
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11853>
We have a "maximum bpp of all render targets" field for several
packets. For them we were defining manually the possible values. But
all the possible values are the ones defined at the already defined
type "Internal BPP". So in practice we were defining the possible BPP
values twice.
Also for those fields, sometimes we were using the "Internal BPP" type
and in some other cases we were not, so this commit also adds some
consistency.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11976>
Like in the case of emitting a block, process pending TMU operations
before a jump is executed.
Fixes dEQP-VK.graphicsfuzz.stable-binarysearch-tree-nested-if-and-conditional.
Fixes: 197090a3fc ("broadcom/compiler: implement pipelining for general
TMU operations")
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11971>
The function radeonsi_screen_create_impl() tries to create the
aux_context but doesn't actually check for the returned value from
si_create_context().
Then, on si_destroy_screen() the aux_context is used without actually
checking whether it's a thing or not.
As a result, if for any reason si_create_context() failed, we shall
crash in si_destroy_screen() with a NULL pointer dereference trying to
access ((struct si_context *)sscreen->aux_context)->log.
Simply check for aux_context not being NULL to avoid that crash.
Cc: mesa-stable
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11948>
If you didn't have a freed+ready instruction, you'd redo the live_effect
and check_instr() logic multiple times per instr. Replace the multiple
loops in each function with a ranking that I think is more readable,
reducing the overhead in the process.
debugoptimized dEQP-GLES31.functional.ubo.random.all_per_block_buffers.20
runtime goes from ~3.5s -> ~3.0s on my lazor. No shader-db change.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11855>
Originally I fixed the case where the nir itself has a shared mem size of
0, but the frontend (e.g. clover) set it to some other value.
But st/mesa sets the shared mem size on the state object as well and we
end up actually doubling the value in the driver as we set smemSize to the
value from the state object before calling into the compiler.
So just max the value instead.
Fixes the compute_shader.shared-max CTS test.
Fixes: dc667b1f19 ("nv50/ir/nir: fix smem size")
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11047>
Gets rid of the silly inheritance everywhere, which has caused _far_
more problems in practice than it has fixed. It was an idea I tried
before the pandemic. It didn't work. I'm finally cleaning it up.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11936>
This replaces some new/delete uses with malloc/free.
This is more consistent with most of the other glsl IR code but
more importantly it allows the game "Battle Block Theater" to
start working on some mesa drivers. The game overrides new and
ends up throwing an assert and crashing when it sees this
function calling new [0].
Note: The game still crashes with radeonsi due to similar conflicts
with LLVM.
CC: mesa-stable
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11907>
Sync object for i915 support has been in upstream Linux since 4.14 which
is 3.5 years old at this point and, as far as we can tell, it also
exists in all the ChromeOS kernels. Assuming it allows us to drop some
of our more gnarly synchronization fall-back paths.
At the time of merge, ChromeOS was on the following kernels:
- kernel 3.18: SKL
- kernel 4.4: BYT, KBL, APL
- Kernel 4.14: BDW, GLK
All of the pre-4.14 kernels have had syncobj support back-ported.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Acked-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9777>
Implement elect using a pseudo-op which is lowered during the
insert_exec_mask pass. This makes it possible to emit a more
optimal sequence when the exec mask is constant.
Fossil DB results on Sienna Cichlid:
Totals from 211 (0.16% of 128647) affected shaders:
CodeSize: 2254356 -> 2240468 (-0.62%); split: -0.62%, +0.00%
Instrs: 438471 -> 434996 (-0.79%); split: -0.80%, +0.01%
Latency: 2717082 -> 2709400 (-0.28%); split: -0.28%, +0.00%
InvThroughput: 566987 -> 566342 (-0.11%); split: -0.11%, +0.00%
Copies: 40058 -> 40162 (+0.26%)
Branches: 31209 -> 31211 (+0.01%)
PreSGPRs: 9927 -> 10125 (+1.99%)
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11458>
This allows our optimizer to recognize this and eliminate it when
it can prove that the s_and with exec is unneeded.
Fossil DB changes on Sienna Cichlid:
Totals from 1969 (1.53% of 128647) affected shaders:
CodeSize: 9468228 -> 9469348 (+0.01%); split: -0.00%, +0.01%
Instrs: 1773566 -> 1773581 (+0.00%); split: -0.01%, +0.01%
Latency: 19504042 -> 19503385 (-0.00%); split: -0.00%, +0.00%
InvThroughput: 3617406 -> 3617333 (-0.00%)
Copies: 108998 -> 110592 (+1.46%)
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11458>
Error handling with DRM_IOCTL_I915_QUERY is tricky and we got it wrong
in one of the two calls here. Use the common helper instead. This also
fixes a theoretical bug where calloc() fails. While we're here, inline
iris_bufmgr_update_meminfo because we're not really benefiting from
having it separate anymore.
Fixes: e60114b2ae "iris/bufmgr: Query memory region info."
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11770>
Error handling with DRM_IOCTL_I915_QUERY is tricky and we got it wrong
in one of the two calls here. Use the common helper instead. This also
fixes a theoretical bug where calloc() fails. While we're here, inline
anv_track_meminfo because we're not really benefiting from having it
separate anymore.
Fixes: 65e8d72bc1 "anv: Query memory region info"
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11770>
We also add a helper which contains the standard query+alloc+query
pattern used by anv_gem_get_engine_info(). The caller is required to
free the pointer.
These are declared static inline not because we care about the
performance of these helpers but because we're going to use them in the
intel_device_info code and we don't want a link dependency.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11770>
DRM_IOCTL_I915_QUERY is a multi-query. The most egregious errors are
returned via the usual ioctl error mechanism but there are also
per-query errors that are indicated by item.length < 0. We need to
handle those as well. While we're at it, scrape errno so we can return
a proper integer error.
Fixes: c0d07c838a "anv: Support i915 query (DRM_IOCTL_I915_QUERY)..."
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11770>
Generally, all meta operations that are implemented via the TLB and
only involve tile load/store operations only need one layer worth
of tile state memory and a single frame setup pointing the binner
to that memory.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11923>
With multilayered framebuffer we want to allocate enough tile state for
all layers involved, so te binner can handle layered rendering where
a geometry shader is used to redirect primitives to specific layers by
writing to gl_Layer.
However, we may also have layered framebuffers in cases where layered
rendering won't be used. Typically this will happen for meta copy/clear
operations, where we setup multilayered framebuffers but then we just
load and/or store the tile buffer without ever rendering a primitive,
let alone use a geometry shader to do layered rendering. In these cases
we can reduce the amount of tile state allocated to a sigle layer.
This patch allows us to specify if we should allocate tile state for all
layers when we start a new frame. We will take advantage of this in
later patches targetting the meta copy/clear code paths.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11923>
Our meta image clearing code was emitting a job per layer to clear,
but we can emit a single job that packs multiple layer clears for
better performance. For this we just need to make sure we pass
the maximum layer we can emit to v3dv_job_start_frame so we
allocate sufficent tile state memory.
Actually, since this operation is TLB based and doesn't make use of
layered rendering, we could do with allocating less tile state
memory too. We will improve this for this and many others TLB meta
implementations in follow up patches.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11923>
On APUs, we fake heaps to simulate a dGPU setup because it seems to
have the maximum compatibility. Though, some applications like RDR2
still only looks at GTT if the driver reports an iGPU which means it
will only use 1/3rd of total memory available.
This is currently behind a drirc option because it might have
implications for other apps but we might want to extend this later
if everything is fine.
Cc: 21.2 mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11891>
We can use a better algorithm from ICL and onward by setting a chicken
bit, but prior to that we need to resort to disabling rectangular lines.
Since we don't support strictLines anyway, this shouldn't be a major
issue.
Closes#2833
Fixes dEQP-VK.rasterization.interpolation_multisample_*_bit.*lines_wide
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11672>
The code being removed here requires that the old context have a
window-system drawable bound to the default framebuffer as a condition
of the context-release flush. I can find no justification for
restricting flushes to contexts like this, and GL 3.0 (etc) let you make
a context current without any drawable bound.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11423>
This means the drawable was already destroyed. This can happen during
diplay teardown, destroying the context will make it current first so it
can flush rendering and destroy textures and such, and if the drawable
is already destroyed then flushing to nowhere would crash.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11423>
Fix defect reported by Coverity Scan.
Dereference before null check (REVERSE_INULL)
check_after_deref: Null-checking so suggests that it may be null,
but it has already been dereferenced on all paths leading to the
check.
Fixes: dcd2d8ca50 ("asahi: Track more Gallium state")
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11898>
This change does the following:
- Moves image clearing code from v3dv_meta_copy.c to v3dv_meta_clear.c
where it belongs.
- Renames v3dv_meta_copy.h to v3dv_meta_common.h since now it is required
by the copy and clear code.
- Renames 'struct framebuffer_data' type.
- Merges v3dvx_meta_clear.c and v3dvx_meta_copy.c into v3dvx_meta_common.c.
- Prefixes all "public" meta functions with the 'meta' prefix.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11902>
This is distinct form max_cs_threads because it also encodes
restrictions about the way we use GPGPU/COMPUTE_WALKER. This gets rid
of the MIN2(64, devinfo->max_cs_threads) we have scattered all over the
driver and puts it in a central place.
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11861>
Braswell, a particular Cherryview variant, is especially strange. We
can't even get the chip name from the PCI ID and instead have to look at
fusing information to decide if it's a 400 or a 405. Pull that into the
common code as well. This fixes BSW naming on ANV and crocus.
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11861>
Cherryview is weird in that the actual limits we can expose through GL
are dependent on fusing information which is only obtainable at runtime.
The same PCI ID may have different configurations with different maximum
CS thread counts. We currently handle this in i965 and ANV by doing the
calculation in the driver.
This dates back to when intel_device_info was computed from the PCI ID.
Now that we have get_device_info_from_fd, we can move the CHV stuff
there and get it out of the driver. This fixes CHV thread counts on
crocus as well.
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11861>
Drops the vk_format_to_pipe (and it's outdated table) for vk_format_to_pipe_format, aswell as the duplicated vk_format_aspects function.
The old format table was missing USCALED and other values, causing incorrect rendering in many games.
Fixes rendering in Portal 1, Hat in Time, Half-Life 2 and pretty much every other D3D9 title with DXVK.
Fixes: b38879f8c5 ("vallium: initial import of the vulkan frontend")
Signed-off-by: Joshua Ashton <joshua@froggi.es>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11863>
echo'DEQP_SUITE must be set to the name of your deqp-gpu_version.toml, or DEQP_VER must be set to something like "gles2", "gles31-khr" or "vk" for the test run'
# Replace in the range between __START_TEST_PATTERN and
# __REPLACE_TEST_PATTERN leaving __START_TEST_PATTERN out
# from the substitution
sed '\%'"${__START_TEST_PATTERN}"'%,\%'"${__REPLACE_TEST_PATTERN}"'%{\%'"${__START_TEST_PATTERN}"'%b;s%'"${__REPLACE_TEST_PATTERN}"'%</system-out><failure type="fail">To view the image differences visit: '"${__DASHBOARD_URL}"'</failure></testcase>%}'\
disabling depth clipping (through pipe_rasterizer_state) separately for
the near and far plane. If not, depth_clip_near and depth_clip_far will be
equal.
``PIPE_CAP_DEPTH_CLAMP_ENABLE``: Whether the driver is capable of
enabling depth clamping (through pipe_rasterizer_state) separately from depth
clipping. If not, depth_clamp will be the inverse of depth_clip_far.
*``PIPE_CAP_SHADER_STENCIL_EXPORT``: Whether a stencil reference value can be
written from a fragment shader.
*``PIPE_CAP_TGSI_INSTANCEID``: Whether TGSI_SEMANTIC_INSTANCEID is supported
@@ -618,6 +621,8 @@ The integer capabilities:
*``PIPE_CAP_EMULATE_NONFIXED_PRIMITIVE_RESTART``: Driver requests all draws using a non-fixed restart index to be rewritten to use a fixed restart index.
*``PIPE_CAP_SUPPORTED_PRIM_MODES``: A bitmask of the ``pipe_prim_type`` enum values that the driver can natively support.
*``PIPE_CAP_SUPPORTED_PRIM_MODES_WITH_RESTART``: A bitmask of the ``pipe_prim_type`` enum values that the driver can natively support for primitive restart. Only useful if ``PIPE_CAP_PRIMITIVE_RESTART`` is also exported.
*``PIPE_CAP_PREFER_BACK_BUFFER_REUSE``: Only applies to DRI_PRIME. If 1, the driver prefers that DRI3 tries to use the same back buffer each frame. If 0, this means DRI3 will at least use 2 back buffers and ping-pong between them to allow the tiled->linear copy to run in parallel.
*``PIPE_CAP_DRAW_VERTEX_STATE``: Driver supports `pipe_screen::create_vertex_state/vertex_state_destroy` and `pipe_context::draw_vertex_state`. Only used by display lists and designed to serve vbo_save.
File diff suppressed because it is too large
Load Diff
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
