8x and 16x MSAA should work now, so we no longer need to deal with those
separately. We have more accurate checks for when it's supported or not
in place already.
2x MSAA isn't supported at all until v12, which we haven't finished
wiring up yet. So let's leave that one for now... We'll need some more
fixes for that anyway.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34455>
The AMD_framebuffer_multisample_advanced extension interacts kinda badly
with ARB_internalformat_query and GLES 3. The problem is that
ARB_internalformat_query etc untangles MAX_SAMPLES and
per-internalformat sample limits, but the multisample advanced spec
explicitly requires that we can't go above the global maximum.
This isn't the biggest problem in the world; one could just deal with
these limitations for the multisample_advanced functions... if it wasn't
for the fact that we by mistake apply the multisample_advanced
limitations for functions where they shouldn't be taken into account.
Whoops. So let's make sure we don't do that.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34455>
This makes sure the extension is only effective in the APIs that it
supports.
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34455>
The _mesa_check_sample_count() helper deals with these errors much more
carefully, considering multiple extensions that extends the features.
In particular, GLES 3 and and ARB_internalformat_query allows us to use
higher sample-counts than what MAX_SAMPLES reports for some formats.
Because this actually needs to be done in a few more places, let's
implmenent this as a helper, similar to check_level. We also need to
call the helper a bit later on, after the level has been verified.
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34455>
This is fairly subtle, but internalformat query doesn't modify GLES 1
or GLES 2 on drivers that doesn't support full GLES 3.
Also fix up a tiny detail in the comment while we're at it.
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34455>
For MaxColorTextureSamples etc, we need to report the smallest
sample-count that is guaranteed to work. On some GPUs (e.g. Arm's Mali
GPUs), larger pixel-formats can't always support the higher sample
counts, becuse it takes up too much storage in the tile buffers.
From the OpenGL 4.6 spec, section 22.3.2 ("Other internal format
queries"):
"The maximum value in SAMPLES is guaranteed to be at least the
lowest of the following:
* The value of MAX_INTEGER_SAMPLES, if internalformat is a
signed or unsigned integer format.
* The value of MAX_DEPTH_TEXTURE_SAMPLES, if internalformat
is a depth/stencil-renderable format and target is TEXTURE_2D_-
MULTISAMPLE or TEXTURE_2D_MULTISAMPLE_ARRAY.
* The value of MAX_COLOR_TEXTURE_SAMPLES, if internalfor-
mat is a color-renderable format and target is TEXTURE_2D_-
MULTISAMPLE or TEXTURE_2D_MULTISAMPLE_ARRAY.
* The value of MAX_SAMPLES"
Since SAMPLES needs to be *at least* MAX_COLOR_TEXTURE_SAMPLES here, we
need to set it to the smallest possible value for any format.
So let's swap the loops here, trying one format at the time. To avoid
doing needless tests, we check from the largest value supported in all
previous formats, omitting sample-counts that has previously been ruled
out.
In addition, we need to check a few larger formats as well, to capture
the limitations above. Since large formats exists in fewer swizzle
variants, we don't need to check as many options as for 8-bit per
component formats.
And since the larger formats are the most likely ones to support lower
sample counts, make sure those formats are listed first.
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34455>
The constants we were comparing with here aren't the max values in all
cases. These are the max *guaranteed* to be supported values, but
specific formats can support higher sample counts. If we don't serach
for higher values, we might end up not picking a format, leading to
FBOs that are incorrectly marked as incomplete.
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34455>
We're hard-coding the max to 16 in several places, but this value needs
to be consistent. Let's introduce a define here, that we can use instead
of hard-coding 16 more places.
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34455>
This is used both in the vkQueueSubmit path and in the vkCreateDevice
path and we don't want vkCreateDevice to return VK_ERROR_DEVICE_LOST.
In the vkQueueSubmit path we already have a catch-all that will cause
device loss on any error so we don't need to do it in nvk_queue_push().
This fixes dEQP-VK.api.device_init.create_instance_device_intentional_alloc_fail.basic
Fixes: e814fc16ff ("nvk: Use an nvk_mem_stream for nvk_queue_push()")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35442>
This change extends the ARB_shader_draw_parameters
algorithm to support ARB_indirect_parameters.
The linux kernel needs to be updated to support
the following PM4 commands: COND_EXEC and COND_WRITE.
Without the update, this extension is disabled.
This change was tested on cypress, palm, barts and cayman.
It passes all the piglit tests (6/6) and all the khr-gl45
tests (3/3).
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34726>
This implementation is aimed at compatibility. The
new multi draw indirect mode is unrolled at the
command stream level.
This change was tested on cypress, palm, barts and cayman.
It passes all the piglit tests (23/23) and all the khr-gl45
tests (11/11).
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34726>
This functionality was mostly implemented but not enabled.
The functionality which is using SET_PREDICATION seems to
not work as expected.
This change was tested on palm, barts and cayman,
piglit tests (26/28), and khr-gl45 tests (7/13).
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34726>
The previous limit was eight.
The number of atomic counters of the evergreen implementation
is limited by the number of R_02872C_GDS_APPEND_COUNT_x registers.
This limits this implementation to twelve atomic counters.
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34726>
This change updates the cayman atomic counters implementation
to be compatible with the OpenGL limit MAX_ATOMIC_COUNTERS (4096).
The previous limit was eight.
This change preserves the compatibility with the evergreen
implementation.
Here is the improvement at the test level:
khr-gl4[2-5]/shader_atomic_counters/basic-usage-tes: fail pass
spec/arb_arrays_of_arrays/execution/atomic_counters/fs-simple-inc-dec-read: skip pass
spec/arb_arrays_of_arrays/execution/atomic_counters/vs-simple-inc-dec-read: skip pass
spec/arb_arrays_of_arrays/linker/vs-to-fs-atomic-counter: skip pass
spec/arb_shader_atomic_counters/active-counters: skip pass
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34726>
This change adds some abstractions and updates the atomic function with a
"count" which is what the hardware and sfn_shader are using. The software
limitation to eight atomic counters (uint8_t) is removed as well. The
function headers are updated in the process.
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34726>
The previous fix 0cae8d372e is the right way to proceed, but it
should also apply when index_size is non-zero.
This change was tested on palm and cayman. Here is the test fixed:
spec/arb_multi_draw_indirect/arb_draw_elements_base_vertex-multidrawelements -indirect: fail pass
Fixes: 0cae8d372e ("r600: don't set an index_bias for indirect draw calls")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34726>
iter_sb is now unused on v11+, let's not store it on this codepath and
only define it for v10.
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35307>
Now that all paths support indirect wait for iter scoreboards, we can
remove the previous limit.
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35307>
Now that cs_next_iter_sb match NEXT_SB_ENTRY behavior, we can just
implement it with it.
We also setup the scoreboard wait mask when selecting the next
scoreboard entry to prepare for defer indirect wait and signal usage
around the codebase.
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35307>
This closely match what NEXT_SB_ENTRY gives us on v11+ and should also
reduce the number of instruction by low margin.
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35307>
This patch changes iter_sb to contains the actual scoreboard info
instead of the index in the iter range.
This is required to handle NEXT_SB_ENTRY on v11+.
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35307>
Otherwise, errors such as:
GrallocEmulated.cpp:101:29: error: use of undeclared identifier 'VIRGL_FORMAT_R8G8B8A8_UNORM'
101 | .virglFormat = VIRGL_FORMAT_R8G8B8A8_UNORM,
| ^
GrallocEmulated.cpp:117:29: error: use of undeclared identifier 'VIRGL_FORMAT_B8G8R8A8_UNORM'
117 | .virglFormat = VIRGL_FORMAT_B8G8R8A8_UNORM,
happen in Android builds. Add it to VirtGpu.h to fix this.
Reviewed-by: Marcin Radomski <dextero@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35416>
Swapchain mutable format extension issues were resolved by converting
clear colors on the guest side but that introduced regressions on other
clear related CTS test. Limit clear color modification to images with
Android native buffer structure, to filter swapchain images better.
Test: dEQP-VK.image.*
Reviewed-by: Marcin Radomski <dextero@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35416>
... as VkSnapshotApiCallInfo* is a pointer into a
std::vector<VkSnapshotApiCallInfo> which can be invalidated during
multi threaded VK usage when the std::vector<> is resized.
Test: bazel test common/end2end:gfxstream_end2end_tests \
--graphics_drivers=gles_angle_vulkan_swiftshader \
--test_arg="--gtest_filter=*MultiThreadedResetCommandBuffer*VulkanSnapshots*" \
--test_arg="--gtest_repeat=100" \
--test_output=streamed
Reviewed-by: Marcin Radomski <dextero@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35416>
On v4, we can't lower the tile-size to get enough per-pixel space for
both 4xMSAA *and* 128-bit formats at the same time.
And because GLES 2 doesn't support per-format queries, this means that
we'd effectively not support MSAA at all. We can avoid this issue by
dropping support for the 128-bit formats on V4, unless explicitly
requested by a driconf.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35207>
Lima can't do *both* FP16 *and* 4x MSAA at the same time. And because
GLES2 requires MAX_SAMPLES to be valid for *all* supported formats,
this means we can't support MSAA at all unless we disable support for
the FP16 formats when used as render-targets.
To allow applications that needs FP16 render-targets to still support
it, we introduce a driconf that makes the opposite trade; support FP16,
but not 4x MSAA. Unfortunately, we can't support both, and still be
following the spec.
Reviewed-by: Erico Nunes <nunes.erico@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35207>
We're currently reporting support for this format, but trying to use it
leads to asserts in pan_access_tiled_image(). Right now, it's
effectively unused, because the state-tracker will end up using the RGBA
version, because that is renderable.
This is all about to change, so let's drop this format for now. But
because this is technically speaking supported on the HW, let's leave
this ifdeffed out with a comment to re-enable once the assert has been
fixed.
Reviewed-by: Erico Nunes <nunes.erico@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35207>
This runs in 11 seconds and doesn't even clone the git repo, so we can
use the placeholder tag here to get it through instantly.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35203>
For pre-merge pipelines, we know that we don't need to run the
container-check jobs unless image-tags.yml has been modified. In this
case, we can just skip the container jobs, because we 'know' that the
containers are present in the upstream repo.
For downstream or off-main pipelines, we still need to run the check
job, because the changed-file tracking is not reliable on other
branches, and because we may need to copy the container image from the
upstream container storage into the user's namespace.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35203>
The rules we want here are pretty simple:
- only run rustfmt when Rust code changes, to the extent that we can
tell what has or hasn't changed (only really reliable for pre-merge)
- make rustfmt success mandatory for pre-merge, advisory for other
branches
Encode that, and make sure we don't run rustfmt when we don't need to.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35203>
The way we pull needs is overly baroque and relies on some jobs
overriding some other jobs to not be broken. This doesn't make it all
the way better, but does improve at least some parts.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35203>
debian/baremetal_arm_test no longer exists, although this was not
material beacuse the dependencies were overridden later anyway.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35203>
It's not clear what this ever referred to, but it's a no-op now since
the rules are no different for .container versus directly overriding
from .container+build-rules.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35203>
