For the piglit drawoverhead case, 5/18 of the objects' relocs were
duplicated. We can dedupe them at object create time (since objects are
long-lived) and avoid repeated relocation work at emit time.
nohw drawoverhead program statechange throughput 2.34082% +/- 0.645832%
(n=10).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5020>
vkCmdResolveImage doesn't respect render-condition, so let's fall back
to blitter in this case instead.
Fixes: 80d7cc6f129 ("zink: enable conditional rendering if available")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5008>
mingw-w64 pulls in a lot more packages we don't need.
g++-mingw-w64-x86-64-win32 is only available in Debian testing, so get
all mingw packages from there.
Acked-by: Andres Gomez <agomez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4851>
Instead of a third-party repository which has proved unreliable at
times.
This pulls in glibc 2.30 from testing in the x86_build image, so we need
to update the x86_test-{gl,vk} images to match.
Acked-by: Andres Gomez <agomez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4851>
We don't want LLVM 8 packages to be pulled in from testing though (it
would make installing llvm-8-dev for cross architectures a lot more
complicated), so explicitly select buster-backports for them (they were
already implicitly installed from there before, since they're not
available in buster proper).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4851>
Notable changes:
* No longer generate a separate *-built-by-job-* image tag, instead
store the pipeline/job information as labels in the image.
* Clean up some package information files which were accidentally left
before, possibly resulting in slightly smaller images.
Acked-by: Andres Gomez <agomez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4851>
Changed the sampler variable name from 'sampler' to 'sampler_<num>' to stop symbol classes in the Metal MSL shaders, as 'sampler' is a keyword.
Improves human readability when debugging issues.
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4211>
This is a requirement for the shaderResourceMinLod feature which
allows to clamp LOD. This uses all image_sample_*_cl variants.
All dEQP-VK.glsl.texture_functions.texture*clamp.* pass.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4989>
This is a requirement for the shaderResourceMinLod feature which
allows to clamp LOD. This uses all image_sample_*_cl variants.
All dEQP-VK.glsl.texture_functions.texture*clamp.* pass.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4989>
We will eventually need to build our own LLVM on Windows in order to
build libclc and other bits which are required for the d3d12 build, as
well as to be able to test SPIR-V/OpenCL on llvmpipe.
Start doing this now, building into the base container, and exercise
this by building llvmpipe under Windows.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4946>
'Newer' versions of MSVCRT than 2013 appear to have fixed the bug around expf
precision which caused bb9e8c5090. It's not clear when this was
changed, but at least on Windows 10 machines with Visual Studio 2019,
expf behaves in line with other implementations.
As there is no clear way to test for the version of the VCRT in use,
simply mark this test as expected-pass rather than xfail.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4946>
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
It seems less brittle to not assume they are in the same order for src
and dst instructions.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Caught by the sanity checking in nir_intrinsic_copy_const_indices()
(which is introduced by the next patch).
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Cleans up a couple spots that were still open-coding this.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
These intrinsics are supposed to map to the underlying hardware
instructions, which don't have wrmask. We use them when we lower
store_output in the geometry pipeline and since store_output gets
lowered to temps, we always see full wrmasks there.
This fixes problems in a number of games, including SuperTuxKart,
OpenMW and RVGL.
v2: Use MALI_READS_ZS | 0x20 instead of MALI_WRITES_Z to match with
the blob. Keep using 0x400 | 0x20 when depth is disabled.
Closes: #2620
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5001>
It probably doesn't matter because that buffer should have a stride of
zero. However, it still seems like a good idea just to be safe.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5022>
It saves addressing math, but may cause multiple loads to be done and
bcseled due to NIR not giving us good address alignment information
currently. I don't have any workloads I know of using non-const-uploaded
UBOs, so I don't have perf numbers for it
This makes us match the GLES blob's behavior, and turnip (other than being
bindful).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4858>
With the upcoming LDC usage in the GL driver, we don't want to be
uploading descriptors for every UBO when they aren't actually in use.
Trimming NIR's num_ubos will avoid that, and cleans up num_ubo handling
elsewhere right now.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4858>
The vma_heap allocator was originally designed to prefer high addresses
in order to find bugs in ANV's high address handling. However, there
are cases where you might want the allocator to prefer lower addresses
for some reason. This provides a configure bit for exactly this
purpose.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5019>