This patch does a couple of things to make CL integration with drivers
as seamless as possible:
- We pull in opencl-c.h and opencl-c-base.h to stop relying on system
headers.
- Parts of libcl.h are moved to new headers that are incomplete CL-safe
variants of libc headers.
- A couple of util headers are changed to remove now unnecessary
__OPENCL_VERSION__ guards and make more headers CL safe.
- Drivers now include src/compiler/libcl and use headers like
macros.h,u_math.h instead of libcl.h.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33576>
On X.org startup libgallium crashes on x32 hosts inside
blake3_hash_many_sse41(), most likely because of the different pointer
size. Disable SIMD blake implementation if x32 is detected.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34453>
This allows us to create temporary VGRFs that are larger than
MAX_VGRF_SIZE(devinfo), which will be split eventually. They may not
be split on the initial pass, because we may need LOAD_PAYLOAD lowering,
copy propagation, and so on to occur first. So we allow registers to
exceed that size initially.
The "Register allocation relies on split_virtual_grfs()" assertion in
brw_reg_allocate.cpp still asserts that all VGRFs which reach the
register allocator have been properly split.
One case where this is useful is for vectorizing convergent block loads.
We create temporaries to splat the SIMD1 values out to SIMD(N), which
can lead to some very large temporaries. However, copy propagation and
so on ultimately eliminate these and they'll get split down to proper
sizes or elided entirely in the end.
(Note: both this and the prior commits from this merge request are
needed to close the linked issue.)
Cc: mesa-stable
Reviewed-by: Matt Turner <mattst88@gmail.com>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12324
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34461>
Post-RA scheduling doesn't use liveness analysis, so we continue using
MAX_VGRF_SIZE(devinfo). But for pre-RA scheduling, we now use
live->max_vgrf_size.
This helps get us to a place where we can emit arbitrarily large VGRFs
early on in compilation, but which will be split and cleaned up prior to
register allocation. It may also allocate smaller arrays in practice
since MAX_VGRF_SIZE(devinfo) assumes the worst case scenario for things
we actually could need to allocate.
Cc: mesa-stable
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34461>
We're already looking at this data to calculate the per-component
vars_from_vgrf[] and vgrf_from_vars[] mappings, so just record the
largest VGRF size while we're here. This will allow passes to size
arrays based on the actual size needed, rather than hardcoding some
fixed size. In many cases, MAX_VGRF_SIZE(devinfo) is larger than
necessary, because e.g. vec5 sparse sampling results aren't used.
Not hardcoding this means we can also temporarily handle very large
VGRFs which we know will be split eventually, without having to
increase the maximum which is ultimately used for RA classes.
Cc: mesa-stable
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34461>
When nir_opt_varyings doesn't make progress the first time,
it should not be necessary to call it a second time.
No Fossil DB changes.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33880>
This is to stop calling nir_shader_gather_info repeatedly for
some stages, and also as a pre-requisite to the work in the next commits.
No Fossil DB changes.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33880>
VK_KHR_sampler_ycbcr_conversion is a dependency from the
VK_EXT_image_drm_format_modifier spec. panvk arch < 10 still
doesn't support it, so VK_EXT_image_drm_format_modifier should
not be exposed.
Otherwise, a Vulkan validation error is triggered for users of
VK_EXT_image_drm_format_modifier and it may cause applications
to fail to create a device.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34458>
Not used anymore, just use the existing ADL definitions.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34433>
This verifies that the requested allocation doesn't exceed the maximum
in cases where the size passed to `clSVMAlloc()` isn't a multiple of the
provided alignment. It also clamps the maximum allocation to `i32::MAX`,
which prevents overflowing `pipe_box`'s `width` field.
Both of these changes prevent possible undefined behavior on 32-bit
systems due to violation of `Layout` prerequisites.
v2: use safe layout creation for maintainability, add a few comments
v3: use Layout utils for aligned size calc, split out max alloc changes
v4: use `checked_compare()` for alloc/size comparison
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Cc: stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34166>
This uses the helpers from the previous patch to calculate how many
attachments and MRT buffers we have space for.
In the case where we can support more MSAA samples for smaller formats,
we also add support for that.
The flaking test seems to be due to a CTS issue, see this ticket for
details:
https://gitlab.khronos.org/Tracker/vk-gl-cts/-/issues/5651
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33925>
In order to enable higher MSAA modes, we're going to have to perform
some calculations on how to budget the (sometimes) limited tile-buffer
space.
Due to limited tilebuffer space, we need to prioritize a bit here.
First, we reserve space for 4x MSAA for all formats. Then we try to fit
8 color attachments into the tile-buffer. And then finally, we calculate
how many extra multi-sample buffers we can fit into the rest.
The reason we reserve 4x MSAA first, is that this is required by all
Vulkan versions. It also prevents us from regressing existing features.
Then we try to pick 8 color attachments next, because that's required by
Vulkan 1.4 as well as Vulkan Roadmap 2024 and D3D12. Vulkan Roadmap 2022
requires 7 as well.
This adds helpers that implements this, which can be used by both the
Gallium and the Vulkan driver. It's really benefitial if both of these
drivers prioritize the same way here.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33925>
On v5, as well as v7 onwards, we can disable pipelining in order to fit
more data into the tile-memory. This is important in order to support
multiple, large color buffers with high MSAA sample counts.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33925>
We also have a budget for the tile size for depth-buffers. It's
currently hard to trigger issues with this than for color-buffers,
but this becomes important when we support larger MSAA counts.
We also need to take a bit of care for stencil-only attachments, because
they also count against a limit here. We really only care about the
sample counts here, because the stencil buffer budget is always a
quarter of the depth-buffer budget, and always uses a single byte per
sample.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33925>
There's two limitations we have to cater to:
1. The HW needs at least one render-target. We can disable write-back for
it, but it needs to allocate tile-buffer space for it.
2. The HW can't have "holes" in the render-targets.
In both of those cases, we already set up dummy RGBA8 UNORM as the format,
and disable write-back. But we forgot to take this into account when
calculating the tile buffer allocation.
This makes what we program the HW to do consistent, meaning we don't end
up smashing the tile-buffer space. We might be able to do something
better by adjusting how we program these buffers, but let's leave that
for later.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33925>
