If supported this means that src_x/src_y/width/height parameters of
CopyTex functions will not be clipped using the read framebuffer's dimensions.
Cc: mesa-stable
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6259>
Gallvm API changes in TCS/TES, but the compilation worked
for older LLVM APIs. With LLVM 12 update is needed.
Reviewed-by: Krzysztof Raszkowski <krzysztof.raszkowski@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6554>
Since the dest type is retrieved from the SPIR-V return type now,
we have to set it manually for OpFragmentMaskFetchAMD. The result
type must be a 32-bit unsigned integer type scalar.
Fix dEQP-VK.pipeline.multisample.shader_fragment_mask.* with RADV.
Fixes: a196f05fc2 ("nir/vtn: Use return type rather than image type for tex ops")
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6533>
Only advertise VK_TIME_DOMAIN_CLOCK_MONOTONIC_RAW_EXT if CLOCK_MONOTONIC_RAW
is defined. Fixes the build on OpenBSD which has CLOCK_MONOTONIC but not
CLOCK_MONOTONIC_RAW.
Fixes: 67a2c1493c ("vulkan: Add VK_EXT_calibrated_timestamps extension (radv and anv) [v5]")
Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6517>
57c95d2ce2 ("radv: a support for a secure compile fork at device creation")
added includes which were not removed in
7324977e42 ("radv: remove the secure compile support feature")
remove these no longer needed includes to fix the non-linux build
Fixes: 7324977e42 ("radv: remove the secure compile support feature")
Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6517>
Return the smallest value of available non-kernel physical memory and
the static per process data size limit as the amount of available
system memory on OpenBSD.
Fixes: b80930a6fe ("anv: add support for VK_EXT_memory_budget")
Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6517>
Replace local get_available_system_memory() function with
os_get_available_system_memory().
Fixes: b80930a6fe ("anv: add support for VK_EXT_memory_budget")
Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6517>
Add os_get_available_system_memory() derived from
src/intel/vulkan/anv_device.c get_available_system_memory()
Fixes: b80930a6fe ("anv: add support for VK_EXT_memory_budget")
Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6517>
Passes piglit depth_clamp, depth-clamp-range,
amd_depth_clamp_separate_range. This is part of enabling GL 3.2 (the
other is bumping PIPE_CAP_GLSL_FEATURE_LEVEL, which I'm hoping to do once
we have the KHR-GL* testing in place).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6544>
There's no need to have separate build scripts here, just choose what the
DEQP_TARGET is for the particular container being built. This brings in a
tremendous number of GLES test fixes that haven't made it into a tagged
gles CTS release.
Closes: #2056
Reviewed-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6526>
The version bump gets us various testcase fixes, mostly to test
requirements). While we're rebuilding the container, copy GL CTS stuff
from build-deqp-gl.sh -- we had already included the glcts binary in our
image, but we had unnecessary other binaries and were missing the mustpass
files (container size stays the same overall). Also pull in all the GLES
mustpass lists, not just the main ones -- Rob wants them to increase our
coverage to match what Android CTS covers.
Reviewed-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6526>
Just leave it at 0 and the frontend will lower for us.
Fixes dEQP-GLES31.functional.atomic_counter.get.1_counter_*
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6439>
Atomic ops have to encode the address of the variable it's writing to.
This property is used to align the address to 64-bit boundaries.
Signed-off-by: Italo Nicola <italonicola@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6439>
This really shouldn't matter as inputs should have logical pointers.
However, nir_builder defaults to building derefs based on the pointer
size in the shader_info. It's easier for now to just be consistent
everywhere.
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6379>
For now, we leave the constant_as_global option intact and get rid of
the UBO path which no one upstream is using today.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6379>
This commit adds support for nir_var_mem_constant various places. It
also adds a pass similar to nir_lower_vars_to_explicit_types except it
also scrapes out the constants and stuffs them into constant_data.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6379>
This has the same semantics as load_global except the memory it reads is
known to be constant so load_global_constant intrinsics can be CSEd
rather than relying on more complex copy-propagation.
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6379>
clover gives us a uint32_t pointer into the kernel input bufffer, but also
for actual 64 bit pointers, so we can just use memcpy instead.
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6433>
libclang seems to define this on its own for SPIR targets, but the CTS
requires it to be not set if the device doesn't support images.
The SPIRV-LLVM-Translator also requires the spir triple to be set so we
can't really do anything else except to undefine.
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Reviewed-by: Jason Ekstrand <jason@jlekstran.net>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6433>
eglInitialize() already handles the "retry using the software path"
logic, there's no need to repeat it here.
Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6353>
eglInitialize() already handles the "retry using the software path"
logic, there's no need to repeat it here.
Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6353>
eglInitialize() already handles the "retry using the software path"
logic, there's no need to repeat it here.
Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6353>
eglInitialize() already handles the "retry using the software path"
logic, there's no need to repeat it here.
Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6353>
The immediate case is pretty uncommon to see but it can happen, in
theory. BROADCAST is typically used to uniformize values and those are
usually 32-bit. However, it does come up in some subgroup ops.
Fixes: 49c21802cb "intel/compiler: Split has_64bit_types into float/int"
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6211>
Pierre-Eric Pelloux-Prayer
jzielins
Samuel Pitoiset
Jonathan Gray
Eric Anholt
Alyssa Rosenzweig
Italo Nicola
Jason Ekstrand
Karol Herbst
Eric Engestrom