This is the first time we see an application running out of mmap().
We essentially allocate too many batches (+65k) and end up not being
able to mmap them, at which point we can't mmap anything anymore and
things go sideways.
This change allocates bigger batch BOs as we grow an existing command
buffer. This drastically reduces the number of BOs we need to allocate
(the benchmark that reported the issue now reaches a max of ~630 BOs,
instead of reaching 65k and failing previously).
v2: Track the total batch size of command buffers (Jason)
Just give 0 for batch_len to i915 (Jason)
v3: Fix indentation (Jason)
v4: Drop uncessary reshuffling of error labels (Jason)
v5: Remove empty lines (Marcin)
v6: Limit BO growing to chunks of 16Mb (Jason)
v7: Add assert on initial size (Jason)
v8: Add define for max size (Jason)
v9: Fixup v7 assert for non softpin platforms (Lionel)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4956
Cc: mesa-stable
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11482>
There's no SPIR-V Capability associated, so check in the Execution
Mode. For now, don't keep track of whether a shader uses uniform
control flow in the shader_info, we can add that when/if a driver
actually need that information.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11476>
Some infinite loop cases were already covered by other
restrictions (e.g. if the loop had a body), but the case with a single
block in the loop body wasn't yet.
This prevents an infinite loop when optimizing the shader in
dEQP-VK.reconvergence.subgroup_uniform_control_flow_ballot.compute.nesting2.3.2
and various others reconvergence tests.
Fixes: 0881e90c09 ("nir: Split ALU instructions in loops that read phis")
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> [v1]
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11476>
Move and rename warn_non_conformant_implementation() to common location
of src/vulkan/util/vk_util.c as vk_warn_non_conformant_implementation().
In freedreno/ci, move MESA_VK_IGNORE_CONFORMANCE_WARNING to common
location of .baremetal-deqp-test-freedreno-vk.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11563>
The full form for ldg.a/stg.a offset is:
g[reg_address + reg_offset << (imm_shift + 2) + imm_offset << 2]
where imm_shift is in [0, 3] and imm_offset is in [0, 3]
a6xx blob was found to produce a bit simplier offset calculations
for TES/TCS shaders in GTA V:
[c002000a_03c14215] ldg.a.f32 r2.z, g[r1.y+((r2.z+1)<<2)], 3;
[c0020004_01c14609] ldg.a.f32 r1.x, g[r1.y+((r1.x+3)<<2)], 1;
Our new syntax:
stg.a.u32 g[r2.x+(r1.x+1)<<2], r5.x, 1
stg.a.u32 g[r2.x+r1.x<<4+3<<2], r5.x, 1
ldg.a.f32 r1.w, g[r1.y+(r1.w+1)<<2], 3
ldg.a.f32 r1.w, g[r1.y+r1.w<<5+2<<2], 3
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11431>
VkGraphicsPipelineCreateInfo.pMultisampleState is a pointer to a
VkPipelineMultisampleStateCreateInfo structure, and is ignored if the
pipeline has rasterization disabled.
Fixes a crash in one CTS tests that checks this.
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11601>
Improves drawoverhead perf through Zink up to 260%
Before:
1, DrawElements ( 1 VBO| 0 UBO| 0 ) w/ no state change, 1518
After:
1, DrawElements ( 1 VBO| 0 UBO| 0 ) w/ no state change, 3981
This brings it close to Freedreno, which has around 4300.
In vkQuake vs params re-emission now occurs in 0.23% of draw calls.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11556>
Rework:
* Jordan: Handle per_thread_scratch==0 in anv_scratch_pool_get_surf
* Jordan: Update subslices in anv_scratch_pool_alloc
* Jason: Clean up the patch a bit
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11582>
Rework:
* Jordan: Handle prog_data->total_scratch==0 in iris_upload_compute_walker
* Jordan: Resolve iris_get_scratch_space conflict with e2c5ef6cd6
* Jordan: Rebase on 4256f7ed58. broken
* Ken: Mostly fixed the rebase
* Jordan: Fix two small compilation issues
* Jordan: Rebase on Ken's ("iris: Make a pin_scratch_space() helper")
* Lionel: Fix a few bugs with scratch handles
* Jason: Tidy the patch up a bit
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11582>
XeHP adds support for a new surface type for scratch. It's similar to
SURFTYPE_STRBUF in that it's a 2D array-of-struct format but the one
key difference is that the U coordinate is computed automatically based
on the thread ID and only the V coordinate is provided in the dataport
message.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11582>
This reverts commit 5cb043cf82.
While the numbers were impressive for drawoverhead, it comes at the cost
of additional flushes, which for gmem access (what we actually care about
most!) would greatly increase the actual cost to render. Also, gl_driver2
overhead is increased, probably due to spending time in the kernel for the
flushes.
drawoverhead's win came from the increased flushing causing the GPU to
start processing the buffers sooner on everything but test 1, which
already had some incremental flushing happening. That was certainly not
intended by the change.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11599>
binding new images may require auto-transitions for the other pipeline, and
unbinding an image requires that any persistent sampler binds have their layouts
updated
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11590>
When I added the build-rules for zink to the windows build, I
accidentally added it to .windows-test-rules instead of
.windows-build-rules. This seems to trigger a build-error if we trigger
*just* a test due to a zink-change, but not a build.
Hopefully this fixes the problems Mike has had with Zink CI recently.
Fixes: a426d7c264 ("ci/windows: enable msvc builds of zink")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11597>