It's the number of elements. RADV exposes VK_FORMAT_R64_{UINT,SINT}
formats for texel buffers, so the maximum is 1<<29 to fit in the
32-bit bounds checking.
Fixes KHR-GL46.texture_buffer_size_clamping.* with Zink and new VKCTS
dEQP-VK.texture.misc.max_elements.*.
Cc: mesa-stable.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38140>
It's already called by st_nir_opts, so it shouldn't be necessary to do
it again here.
This is only compile tested. I have not collected any shader-db or
fossil-db data.
Acked-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12526>
This is only compile tested. I have not collected any shader-db or
fossil-db data.
v2: Drop the calls to nir_opt_constant_folding. The builder in
nir_lower_flrp will already take care of this.
v3: NIR_PASS_V is gone. Noticed by Marge.
Acked-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12526>
No shader-db changes on any Intel platform. Both Iris and Crocus use
st_nir_opts, which calls nir_lower_flrp before brw_nir_optimize. The
call still needs to exist for hasvk, but I don't collect fossil-db data
for hasvk.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12526>
No shader-db or fossil-db changes on any Intel platform.
v2: Return early if lowering_mask is zero. If the first call to
nir_lower_flrp has a lowering_mask of zero, later calls with non-zero
masks would not do any lowering. lp_bld_nir.c has this issue.
Suggested-by: Alyssa
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12526>
Prevents failures with fp16 in lavapipe and Zink on lavapipe when
"nir/lower_flrp: Check and set shader_info::flrp_lowered" is
applied. Lowering with an incomplete mask on the first call to
nir_lower_flrp will prevent later calls (with the complete mask) from
doing anything.
Fixes: b38879f8c5 ("vallium: initial import of the vulkan frontend")
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12526>
There is nothing IR about it. It's really the compiler interface file,
so it should all go in pan_compiler.h.
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38753>
While we're at it, rename pan_lower_* to pan_nir_lower_* for consistency
with everything else. The intention is that eventually this will be a
private header and drivers will stop calling these passes themselves.
However, that is a long way off so for now we'll just move them to the
sensibly named place. Notably, pan_preprocess/optimize/postprocess_nir
stay in pan_compiler.h because those are intended to be external APIs
indefinitely.
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38753>
This is going to be where we put the compiler interface. For now,
disassembly wrappers are as good a place to start as any.
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38753>
The only thing that only pulls in bifrost is our CL compiler for
pre-builts. Everything that uses pan_shader.h pulls it in because
that's header-only and calls into both back-ends anyway. Some day
we might want to figure out how to properly dead-code the midgard
compiler for Vulkan but today is not that day.
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38753>
src/panfrost/util is all compiler stuff, we just put it in util/ so it
could be used by both midgard and bifrost. We also rename all the files
to have a pan_nir prefix. We'll rename the functions later.
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38753>
It was this way for a while but then someone decided that we should try
to hide midgard and get it off the main path. However, we still try to
present a unified interface to the GL driver. The combination of these
two things means that those common compiler interfaces have to live
outside of panfrost/compiler which makes everything more awkward than
it needs to be. We either need to move it back into src/gallium and
make abstracting across the two the GL driver's problem (which breaks
other tooling) or need to put both under src/panfrost/compiler. The
midgard compiler can just as easily bitrot in panfrost/compiler/midgard.
The first step is moving the bifrost compiler.
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38753>
When building with linux_glibc_x86_64 in AOSP, this is
observed.
src/util/u_debug_stack.h:66:4: error: unknown type name 'uint64_t'
66 | uint64_t start_ip;
| ^
Adding <stdint.h> fixes it.
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38644>
Rather than having two independent copies of the same header in two
different places, place a single copy in nouveau/headers. The two copies
did differ, but the one in nouveau/winsys matches the one in the kernel
and the only changes in the one in nvc0 are some removed defines and
changed whitespace.
Reviewed-by: Mary Guillemard <mary@mary.zone>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38761>
WSI extensions are implemented on the Venus driver side, layering on top
of external memory extensions. So we have to filter out WSI extensions
during device creation, otherwise the headless driver on the venus
renderer side can fail the device creation with _EXTENSION_NOT_PRESENT.
Fixes: 11195eb8de ("vulkan: Add KHR_swapchain_maintenance1 promotions.")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38763>
This enhances the DescriptorType enum to include the
memory handle type (DMABUF vs SHM) alongside the size,
allowing consumers to differentiate between DMA-BUF and
shared memory file descriptors without redundant code.
Signed-off-by: Dorinda Bassey <dbassey@redhat.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38677>
The "REF" comparision is a timestamp comparision with rollover.
Our current use of CP_COND_EXEC is still fine, but we should be more
clear about the comparision operation.
Signed-off-by: Rob Clark <rob.clark@oss.qualcomm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38755>
Shader objects are by definition I think independents.
But implementation like Anv would like to optimize dynamic descriptors
if possible. It's possible if the sets are not independent.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38678>
Dynamic descriptors are mapped an array of offsets provided through
vkCmdBindDescriptorSets*() commands.
When pipelines are compiled with independent sets layouts, the
implementation might have to do additional runtime calculation to
figure out what offset in the contiguous array maps to what dynamic
descriptor in the pipeline layout.
For graphics pipelines you can always compute that information when
binding the shaders. There is always a limited amount of shaders (5
max).
For ray tracing pipelines, there could be lots of shaders to process
at every pipeline binding call. Besides there is no interface from the
runtime to the driver to list all the shaders used at the moment.
So do that tracking in the runtime and pass the information down to
the driver through the cmd_set_rt_state() vfunc.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 69a04151db ("vulkan/runtime: add ray tracing pipeline support")
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38678>
`comps <= (1 << subword_shift)` cannot be guarantee.
Here is an example:
```
8x2 %27 = @load_ssbo (%26 (0x1000001), %4) (access=readonly|reorderable, align_mul=2, align_offset=0, offset_shift=0)
8x2 %32 = ior %25, %31
32 %34 = ult32 %33 (0x7), %12
8x2 %35 = b32csel %34.xx, %27, %32
```
When processing `%34.xx` in `bi_emit_alu` (for `instr->src[0]`),
`comps` is computed from the instr definition (`%35`), but
`subword_shift` from the src bitsize.
In that case comps is greater than `1 << subword_shift`, but this is
supported by `bi_alu_src_index`.
This example is extracted from `dEQP-VK.spirv_assembly.type.vec2.i8.bit_field_insert_offset16_count16_comp`
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36638>
When v4i8 instruction are using to compute a v2i8, it puts the 2
result values in b0 & b2, thus we need to swizzle the destination to
have them in b0 & b1 as expected by the consumer of the v2i8 produced.
example: dEQP-VK.spirv_assembly.type.vec2.i8.mul_frag
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36638>
