This ends up polluting the namespace if you build iris/crocus
at once, just move it to where it's used for now.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10308>
Only internal compute shaders use DCC stores, so the TODOs are not
critical yet.
Fixes: 1d64a1045e - radeonsi: enable dcc image stores on gfx10+
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10261>
The lowering code removes the "VS inputs" item from the list because the hw
doesn't support indirect indexing of VS inputs.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10261>
because gfx103.json is automatically generated and can't be changed
manually. This fixes the file generator without changing the generated
header.
Missing registers must be in registers-manually-defined.json, and
missing fields must be in parse_kernel_headers.py.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10261>
A helper called from vn_wsi_create_scanout_image to hijack wsi scanout
image creation.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10294>
The prog_to_nir->NIR-to-TGSI change ended up causing regressions on r300,
and svga against r300-class hardware, because nir_lower_uniforms_to_ubo()
introduced shifts that nir_lower_ubo_vec4() tried to reverse, but that NIR
couldn't prove are no-ops (since shifting up and back down may drop bits),
and the hardware can't do the integer ops.
Instead, make it so that nir_lower_uniforms_to_ubo can generate
nir_intrinsic_load_ubo_vec4 directly for !INTEGER hardware.
Fixes: cf3fc79cd0 ("st/mesa: Replace mesa_to_tgsi() with prog_to_nir() and nir_to_tgsi().")
Closes: #4602
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10194>
Our "integer" index is stored as a float in this case, and we just need to
use teh right opcode for loading it, which will be the only one supported
by !native_integers hardware.
Fixes: cf3fc79cd0 ("st/mesa: Replace mesa_to_tgsi() with prog_to_nir() and nir_to_tgsi().")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10194>
This has been confirmed to fix sporadic graphics corruption on Gen12
platforms for a number of workloads (including Heaven, Valley and
CS:GO among others). Corruption seems to occur during context switch
fairly consistently, but unfortunately this problem doesn't seem to be
documented. Until the hardware team comes up with a better
workaround, fix the problem by reemitting constants at the beginning
of each batch.
No corruption has been observed so far in GL due to preemption,
however this is a possibility to keep in mind, it may be necessary to
disable preemption in addition to this patch in order to fully address
this problem (see also 81201e4617).
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4412
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4454
Cc: mesa-stable
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Previously UBOs only supported static indices, and SSBOs only
supported dynamic indices. UBO support for descriptors was added
as an alternative to static indices, but the logic for detecting
descriptors to SSBOs couldn't just differentiate on constants vs not.
Add a helper which can differentiate cleanly across the board and
handle pre-created handles from descriptors, or static/dynamic raw
indices.
Reviewed-by: Enrico Galli <enrico.galli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10149>
Instead of doing all of the handle logic in the descriptor load, split
it so that the resource index is actually computed during resource_index
processing, and it's converted to a handle during the load_descriptor.
At the same time, add SSBO handling and dynamic indexing handling.
Reviewed-by: Enrico Galli <enrico.galli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10149>
The resources need to be emitted in a particular order, so CBVs
have to be emitted first and can't be emitted as we iterate through
instructions.
Reviewed-by: Enrico Galli <enrico.galli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10149>
Fixes the following building error:
external/mesa/src/egl/drivers/dri2/platform_android.c:1263:10: error: use of undeclared identifier 'FALLTHROUGH'
FALLTHROUGH; /* for pbuffers */
^
1 error generated.
Fixes: 2928c21eb7 ("Convert most remaining free-form fall-through comments to FALLTHROUGH")
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10264>
Instead of checking whether the attribute is settable for each
attrib type, check that once at the beginning of the loop.
Instead of having an if for each attrib type, use a switch.
Return an error if we encounter an unknown attribute. This allows
the caller to make sure settable attributes aren't ignored. The
intel media driver seems to just assert [1] that it doesn't encounter
unknown attributes.
[1]: 95d413e519/media_driver/linux/common/ddi/media_libva.cpp (L2530)
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10104>
We were using the pipeline layout to discard uniform updates for
stages that don't use descriptors, but we can do better by keeping
track of the stages used by the specific dirty descriptor sets and
only update uniforms for stages that are included in those.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10283>
In 27ee40f4c9 ("anv: Add support for sample locations") we
introduced the ability to emit sample locations baked in as part of
the pipeline or dynamically.
This is different from the previous dynamic states that were always
removed from the pipeline batch and instead emitted dynamically all
the time.
The mistake in 27ee40f4c9 is that sample locations are now emitted
all the time, leading to bigger command buffers for unnecessary
reasons.
This change introduces a bit fields of what is baked in the pipeline
and doesn't need to be dynamically emitted.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 4ad4cd8906 ("anv: Enabled the VK_EXT_sample_locations extension")
Cc: <mesa-stable>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10282>
When pipeline->dynamic_state.sample_locations.samples is not set
because the state is dynamic, we're currently calling
genX(emit_multisample) with a 0 samples value which is incorrect.
Found when using renderdoc with the drawing overlay.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 4ad4cd8906 ("anv: Enabled the VK_EXT_sample_locations extension")
Cc: <mesa-stable>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10282>
Fixes
dEQP-VK.api.image_clearing.core.clear_color_image.2d.optimal.single_layer.e5b9g9r9_ufloat_pack32_33x128
with RADV_DEBUG=forcecompress on GFX10.3.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Cc: 21.1 <mesa-stable>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10176>
The initialization we're doing for it in __glXExtensionsCtr is trivial,
and this is only to make glGetString(GL_EXTENSIONS) work in indirect
contexts anyway.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10223>
These are rare enough to not be worth tracking separately. Especially
since after this change all the known_gl_extensions have N for both
direct_support and direct_only (unsurprising, since that's only used to
compute usable indirect extensions).
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10223>
... at least as far as libGL is concerned, because they'd work just fine
if you tried. The only thing the ATI extension seems to add (I can't
find an official spec, this is inferred from the registry XML) is
selecting the GLX_RENDER_TYPE, which we don't validate before putting on
the wire. The only thing the NV extension adds is an additional fbconfig
attribute, and that only known by glXGetFBConfigAttrib; our
implementation of that just reads the value the server sends, if any,
and doesn't try to filter out unknown attributes.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10223>
The "left here but disabled" comment dates to 2004! The idea here is to
add extensions implied by a particular GL version to the GL extension
string, but nothing useful is accomplished by doing so, and this is all
only used in the case of indirect rendering anyway.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10223>
Without image stores, DCC is always decompressed on compute.
Cc: 21.1 <mesa-stable@lists.freedesktop.org>
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10168>
This would be easy to support except that it doesn't support RDNA 2.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10199>
It doesn't support Navi1x and the removal enables this nice code cleanup.
v2: rebase - mareko
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> (v1)
Acked-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10199>
This patch includes a number of reworks and fixes squashed in by
Nanley Chery, Sagar Ghuge, Jordan Justen and Francisco Jerez.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10000>
The PIXEL_X/Y opcodes used by the current implementation are broken on
XeHP due to the new regioning restrictions of the floating-point pipe.
We could have the regioning lowering pass fix it in theory by lowering
the conversions into separate MOV instructions, but that would be more
costly than this implementation that only needs a pair of pipelined
ADDs and a pair of pipelined MOVs.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10000>
Unfortunately the funky Align1 regions used by the code generator in
order to implement derivatives efficiently aren't available to the
floating-point pipeline on XeHP. We need to lower them into a number
of pipelined integer shuffle instructions followed by the
floating-point difference computation.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10000>
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
[ Francisco Jerez: Add TODO comment explaining why this is helpful and
how we could better fix it. ]
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10000>
It has been removed from the hardware.
[jordan.l.justen@intel.com: Move to brw_postprocess_nir]
v2: Switch to nir_lower_idiv_precise (Rhys).
v3: Fix for interface changes of nir_lower_idiv.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10000>
From the BSpec:
"When multiplying DW X DW, resulting dst can only be QW precision. If
DW precision is required at output than MUL/MACH macro must be used."
So for now simply lower it. We might want to revisit it later.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10000>
The floating-point and double-precision FPU pipelines of XeHP
platforms don't support arbitrary regioning modes, corresponding
channels of sources and destination are required to be aligned to the
same sub-register offset, similar to the restriction FP64 instructions
had on CHV/BXT platforms.
Most violations of this restriction can be fixed easily by teaching
has_dst_aligned_region_restriction() about the change so the regioning
lowering pass gets rid of any unsupported regioning. For cases where
this is not sufficient (e.g. because a virtual instruction internally
uses some regioning mode not supported by the floating-point pipeline)
the regioning lowering pass is extended with an additional
lower_exec_type() codepath that bit-casts sources and destination to
an integer type whenever the execution type is not supported by the
instruction.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10000>
The regioning mode used here is no longer supported by the
floating-point pipeline. We could run the regioning lowering pass in
order to fix it with some extra copies, but it's more efficient to
change the instruction to use integer types.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10000>
According to the hardware spec "Vx1 and VxH indirect addressing for
Float, Half-Float, Double-Float and Quad-Word data must not be used."
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10000>
In combination with the previous changes we can just check whether an
instruction has any potentially unsatisfied dependencies on more than
one pipeline, and if so use TGL_PIPE_ALL synchronization with an
appropriate RegDist counter, otherwise synchronize with the single
pipeline it has a dependency on, if any.
Only minor difficulty is caused by the fact that the hardware doesn't
have any way to encode pipeline information when a RegDist and an SBID
dependency need to be provided simultaneously, in which case the
synchronization pipeline is inferred by the hardware. We need to
verify that the hardware's inference will give the correct result
(which may not be the case if e.g. some data was bit-cast from a
different type), and if not emit separate SYNC instructions instead of
baking the RegDist dependency into the instruction (Note that SET SBID
dependencies must always be baked into the corresponding out-of-order
instruction).
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10000>
This extends the current ordered_address instruction counter to a
vector with one component per asynchronous ALU pipeline, allowing us
to track the last instruction that accessed a register separately for
each ALU pipeline of the XeHP EU, making it straightforward to
infer the right cross-pipeline synchronization annotations.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
v2: Make unit tests happy (with ubsan as run by GitLab automation).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10000>
This was a placeholder for the XeHP cross-pipeline synchronization
code, bring it back.
This reverts commit a80e44902f.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10000>
Define two helper functions local to the software scoreboard lowering
pass describing the behavior of the hardware and code generator:
inferred_sync_pipe() calculates the ALU pipeline the hardware will
implicitly synchronize with when a RegDist SWSB annotation is used
without providing explicit pipeline synchronization information,
inferred_exec_pipe() infers the ALU pipeline that will execute the
instruction.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10000>
The execution units of XeHP platforms have multiple asynchronous ALU
pipelines instead of (as far as software is concerned) the single
in-order pipeline that handled most ALU instructions except for
extended math in the original Xe. It's now the compiler's
responsibility to identify cross-pipeline dependencies and insert
synchronization annotations whenever necessary, which are encoded as
some additional bits of the SWSB instruction field.
This commit represents the cross-pipeline synchronization annotations
as part of the existing tgl_swsb structure used for codegen. The
existing tgl_swsb_*() helpers used by hand-crafted assembly are
extended to default to TGL_PIPE_ALL big-hammer synchronization in
order to ensure backwards compatibility with the existing assembly.
The following commits will extend the software scoreboard lowering
pass in order to keep track of cross-pipeline dependencies across IR
instructions, and insert more specific pipeline annotations in the
SWSB field.
The disassembler is also extended here to print out any existing
pipeline sync annotations.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10000>
1. only do size check if the input size is not 0
2. blob_mem can be 0 because guest minigbm uses RESOURCE_CREATE_3D
3. set bo->blob_flags to 0 for classic resource to fail virtgpu_bo_map
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10273>
These have flaked as Timeouts in CI in the last month. .precision.* is
generally very slow (some in the 15s-30s range), but it's unclear to me
why they sometimes spike up to 60 seconds (thermal throttling?).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10274>
The parameters GL_TEXTURE_MIN_LOD, GL_TEXTURE_MAX_LOD,
GL_TEXTURE_MAX_ANISOTROPY_EXT, GL_TEXTURE_LOD_BIAS are stored as floats but
returned as integers. Setting their values outside of the integer range results
has undefined behaviour when the c-runtime method lroundf converts the value
back to an integer.
Fixes: 53c36dfc('replace IROUND with util functions')
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10244>
Android hasn't officially adopted 1.2 yet, so we just cap it to avoid
troubles(e.g. vkjson doesn't like 1.2 atm).
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10258>
We have to keep sampler uniforms around for later YUV lowering, and we
only need to remove uniforms that take up storage space. Code comes from
radeonsi.
Closes: #4644.
Fixes: de17b4aab5 ("freedreno: Remove uniform variables after finalizing NIR.")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10246>
Avoids warning about the annotation with GCC 10:
../src/gallium/frontends/osmesa/osmesa.c: In function ‘osmesa_choose_format’:
../src/util/compiler.h:84:21: warning: attribute ‘fallthrough’ not preceding a case label or default label
84 | #define FALLTHROUGH __attribute__((fallthrough))
| ^~~~~~~~~~~~~
../src/gallium/frontends/osmesa/osmesa.c:316:7: note: in expansion of macro ‘FALLTHROUGH’
316 | FALLTHROUGH;
| ^~~~~~~~~~~
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10220>
clang generates a warning if there's no explicit break or fall-through
annotation. The latter would be kind of silly in this case, and not
robust against any future changes turning the fall-through invalid.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10220>
One exception is src/amd/addrlib/, for which -Wimplicit-fallthrough is
explicitly disabled.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10220>
Avoids warnings on armhf:
./src/gallium/drivers/lima/ir/pp/nir.c: In function 'ppir_get_block':
../src/gallium/drivers/lima/ir/pp/nir.c:554:66: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
ppir_block *block = _mesa_hash_table_u64_search(comp->blocks, (uint64_t)nblock);
^
../src/gallium/drivers/lima/ir/pp/nir.c: In function 'ppir_compile_nir':
../src/gallium/drivers/lima/ir/pp/nir.c:899:52: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
_mesa_hash_table_u64_insert(comp->blocks, (uint64_t)nblock, block);
^
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10220>
If we push a UBO range but then find out at draw-time that part of the
pushed range is out of range of the UBO descriptor, then we have to fill
in the rest of the range with 0's to mimic the bounds-checking that ldc
would've done.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7573>
We were never setting set->size, so we were always copying 0 bytes. But
as we only copy the contents when the layout and therefore the size is
the same, we don't have to take the old size into account anyway.
This fixes some VK_EXT_robustness2 tests that use push descriptors.
Fixes: 6d4f33e ("turnip: initial implementation of VK_KHR_push_descriptor")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7573>
This needs to be part of the compiler because it's the only piece that
we always have access to in all the places ir3_optimize_loop() is
called, and it's only enabled for the whole Vulkan device. Right now
it's just used for constraining vectorization, but the next commit adds
another use.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7573>
This fixes
dEQP-VK.robustness.robustness2.bind.notemplate.r32i.dontunroll.nonvolatile.uniform_buffer.no_fmt_qual.len_260.samples_1.1d.frag,
which accesses the shader UBO with c<a0.x + 512> due to the constant
data UBO coming before it in the const file. The len_256 variant has a
smaller constant data UBO, so it uses c<a0.x + 256> instead, and that
works, so 512 seems to be the real limit.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7573>
We forgot to remove the instruction under consideration from instr_list
before inserting it into the block's list, which caused instr_list to
become corrupted. This happened to work but caused further corruption in
some rare scenarios.
Fixes: adf1659 ("freedreno/ir3: use standard list implementation")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7573>
The LAVA lab has been running well with the rammus chromebook for some
time now. Let's add it to MesaCI as experimental to get more testing,
and later enable it in production.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10238>
Dedicated BOs waste memory and are also a significant cause of CPU
overhead when applications use hundreds of them per frame due to
all the work the kernel has to do to page in all these BOs for a job.
The UE4 Vehicle demo was hitting this causing it to freeze and stutter
under 1fps.
The hardware allows us to setup groups of 16 queries in consecutive
4-byte addresses, requiring only that each group of 16 queries is
aligned to a 1024 byte boundary. With this change, we allocate all
the queries in a pool in a single BO and we assign them different
offsets based on the above restriction. This eliminates the freezes
and stutters in the Vehicle sample.
One caveat of this solution is that we can only wait or test for
completion of a query by testing if the GPU is still using its BO,
which basically means that we can only wait for all active queries
in a pool to complete and not just the ones being requested by the
API. Since the Vulkan recommendation is to use a different query
pool per frame this should not be a big issue though.
If this ever becomes a problem (for example if an application does't
follow the recommendation and instead allocates a single pool and
splits its queries between frames), we could try to group queries
in a pool into a number of BOs to try and find a balance, but for
now this should work fine in most cases.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10253>
ACO doesn't create a waitcnt for barriers between texture samples and
image stores because texture samples are supposed to use read-only
memory. It could also schedule the barrier to above the texture sample.
We also have use a larger memory scope to avoid an ACO optimization.
Tested on GFX8 with Sachsa Willems deferred sample. With some DCC
decompressions and the compute path forced.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Cc: 21.1 <mesa-stable>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9496>
Allocating a descriptor set is aligned to 32 bytes, so just like the
other buffer types, bump the descriptor size to 32 bytes when allocating
MUTABLE descriptor types from a pool.
Fixes: 86644b84b9 ("radv: Implement VK_VALVE_mutable_descriptor_type.")
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10132>
The resource indices we get point to descriptor map entries that include
all shader stages, so we need to size the arrays to account for more than
just one stage.
For now we only support up to 2 stages in a pipeline, so we use that.
Fixes: 002304482c ('v3dv: avoid redundant BO job additions for UBO/SSBO')
Fixes: fa170dab4c ('v3dv: avoid redundant BO job additions for textures and samplers')
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10252>
There were various issues here:
- MAX_DYNAMIC_UNIFORM_BUFFERS was larger than MAX_UNIFORM_BUFFERS.
- In some cases we were exposing more than the minimums required.
While that is not incorrect, it is not following what we have
been doing in general.
- The Vulkan spec states that some of the MaxDescriptorSet limits
need to be multipled by 6 to include all shader stages, even
if the implementation doesn't support all shader stages.
Fixes: cbd299b051 ('v3dv/device: do not compute per-pipeline limits multiplying per-stage')
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10252>
piglit_gl clocked in at 6:12 end-to-end runtime, and piglit_shader spent
2:53 in deqp-runner, so merging them together should be about 9 minutes.
Removing a boot should save us a minute or two of runner time per
pipeline.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10243>
Accept non-linear tiling for multi-planar formats on GFX9+, as long
as DCC is disabled. DCC support is possible in theory, but untested
for now.
GFX8 is still restricted to linear tiling because it's not yet clear
how modifiers should be handled on these chips for multi-planar
formats. Each plane may need a different modifier.
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Acked-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10134>
Instead of having a special case for YUV formats in
si_query_dmabuf_modifiers, let ac_get_supported_modifiers handle
them. Keep setting external_only = 1 for YUV formats, since we
can only sample from such formats (we can't use them as render
targets).
This shouldn't change si_query_dmabuf_modifiers's behavior, because
for YUV formats ac_get_supported_modifiers will return a single
LINEAR modifier.
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Acked-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10134>
util_format_get_blocksize asserts that the blocksize isn't zero.
However the blocksize will be zero if the format's channel encoding
is unspecified. The channel encoding is only meaningful for the
plain u_format layout, so util_format_get_blocksize can't be used
for formats with another layout. For example, YUV formats don't have
the channel encoding specified.
Use util_format_get_blocksizebits, which just returns zero without
an assertion for formats which don't have a channel encoding.
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Acked-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10134>
After the pixel block width and height, a third field is used to
store the pixel block depth. Document this field.
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Acked-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10134>
Set the swizzle mode when decoding.
Add a safe-guard to make sure the provided surface isn't DCC, because
we don't handle this situation.
Signed-off-by: Leo Liu <leo.liu@amd.com>
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10134>
When the depth or stencil state changes dynamically, that might affect
LRZ state and we need to recalculate it and emit it again.
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8615>
Move them up, so they are initialized even when the dynamic state is
not used.
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8615>
In these cases we know that the BO has not been added to the job
before, so we can skip the usual process for adding the BO where
we check if we had already added it before to avoid duplicates.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10210>
We are flushing tile cache more often than is necessary. In
unified cache mode, tile cache flushing is expensive, evicting all
depth/pixel data from the L3$. This is only need for a handful of
cases, such as: making cpu or gpu changes globally visible
(e.g. map), fast color clears, or slow depth clears. Tile cache
flushing is a gen12+ feature.
Remove blanket flushing of tile cache on all depth/RT flushes.
Replace with selective tile cache flushing.
Improves performance in several workloads:
AztecRuins.ogl-high-offscreen-1440p 1%
UnigineValley.ogl-g2 1%
Dota 2 (replay Jul 2020).ogl-g2 1%
Counter-Strike GO.ogl-g2 1%
Manhattan.ogl-Off-19x10 2%
CarChase.ogl-Off-19x10 1%
Bioshock Infinite.ogl-g2 1%
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10217>
enable per-format querying of texture_filter_minmax support if the ARB extension
is enabled
also now return 0 if neither extension is supported
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10030>
this enables detection for the EXT vs the ARB extension, which have
different specifications regarding which formats must be supported
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10030>
This change is for supporting VK_ANDROID_native_buffer implementation,
and it does not advertise VK_KHR_external_memory_fd.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10195>
We are no longer limited to Vulkan 1.1 in VMs.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10146>
Add vn_renderer_info::has_implicit_fencing. Force vkQueueWaitIdle
during vkQueuePresentKHR when it is false.
This kills the performance, but we have to do this until the kernel does
implicit fencing.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10146>
Move away from vn_renderer_sync and toward a userspace-only solution
temporarily until the kernel does what we need.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10146>
Move away from vn_renderer_sync and toward a userspace-only solution
temporarily until the kernel does what we need.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10146>
Move away from vn_renderer_sync and toward a userspace-only solution
temporarily until the kernel does what we need.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10146>
We don't need to initialize the BO since blorp updates the clear color
BO content with fast clear value i.e ANV_HZ_FC_VAL for depth surface.
With this approach, we can get rid of possibility of corruption since we
are no longer sharing the same clear BO for depth formats.
Closes: #3614
Signed-off-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9941>
Previously, on the platforms which support the indirect clear color
values, we were just setting the clear color address and not enforcing
any clear color values but some of the blorp operations were using the
wrong fast clear value.
With this patch, we make sure to set the correct fast clear color value
during blorp operations.
Signed-off-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9941>
On Bifrost, AFBC is not supported if the format has a non-identity
swizzle. For internal resources we fix the format at runtime, but this
fixup is not applicable when we export the resource. Don't advertise
AFBC modifiers on such formats.
Fixes: 44217be921 ("panfrost: Adjust the format for AFBC textures on Bifrost v7")
Cc: mesa-stable
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10233>
Undefine __STDC_VERSION__ for C files to avoid mismatch with C11/C17.
Define __STDC_VERSION__ for C++ files to use <inttypes.h> path.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10196>
Otherwise, handle_loop_phis() might pass it to handle_live_in() and then
we could have two phis for this variable.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Fixes: 7c64623e94 ("aco/ra: refactor SSA repairing during register allocation")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10236>
Prior to supporting VK_EXT_descriptor_indexing all of our descriptor
limits where below 64k which fitted a uint16_t. Now all of those can
go up to 2^20 entries so we need 32bits indexes to keep track of them.
This change leaves the dynamic indexes at 16bits. We could arguably
bump them too, up to the reviewer's taste.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 6e230d7607 ("anv: Implement VK_EXT_descriptor_indexing")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4636
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10228>
Consider a simple loop that does a series of texture instructions and
then reduces the results:
vec4 sum = vec4(0);
for (int i = 0; i < N; i++) {
sum += texture(...);
}
Assume that the loop is unrolled and we schedule the resulting basic
block. Right now, after we schedule the first texture instruction, the
only instructions available to schedule that don't incur a sync are the
instructions to setup the second texture instruction. So we keep picking
the texture instructions, no matter how large N is, resulting in a
pathological schedule for register pressure when N is very large:
sum1 = texture(...);
sum2 = texture(...);
sum3 = texture(...);
...
sum = sum1 + sum2 + sum3 + ...;
In particular this happens with some CTS tests for VK_EXT_robustness2,
where a loop like that with many iterations is marked as [[unroll]],
forcing NIR to unroll it.
This solution is a balance between the current approach and always
scheduling for register pressure (and ignoring sync's). We only allow a
certain number of texture fetches to be in flight before considering
textures to "sync", even though they don't really, both because they
likely *will* sync in reality (overflowing the internal queue of waiting
texture instructions) and because at some point we need the normal
algorithm to kick in and start lowering register pressure.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7571>
Once we insert a use of a given tex or SFU instruction, then we must
wait for that tex/SFU instruction (as well as all earlier ones) to
complete, so we shouldn't penalize further uses, even if a subsequent
tex/SFU instruction gets scheduled after the first use. This especially
matters after the next commit when we start forcibly breaking up long
sequences of texture instructions, since if we schedule a group of 8
texture instructions then we want to schedule the uses of those
instructions in parallel with the next 8 texture instructions to reduce
register pressure.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7571>
Similar to the previous commit, we should also verify that the
source-format support linear-filter if we try to blit with it.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10234>
Some Vulkan-drivers don't support blitting between all formats and
layouts. So let's verify this while blitting, and fall back to the
normal rendering code-path instead.
This fixes a crash on start-up in OpenArena on V3DV.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10234>
In most games I tested we use 32 MiB of cmdbuffers+cmd upload buffers
at most. Especially since we have mutable descriptors it seems
somewhat unlikely anything else will eat it up so be a bit more
aggressive allocating them in VRAM.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10198>
If first_frame_done isn't set, but fence is NULL, we end up dereferncing
that NULL-pointer.
This can happen in the case where the first submitted batch has no work,
and pfence was passed as a NULL-pointer.
While we're at it, simplify the check with the surrounding code, which
also checks for a NULL-pointer here.
Fixes: e93ca92d4a ("zink: force explicit fence only on first frame flush")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10235>
Late export is theoretically better if used with LATE_ALLOC,
but in practice, the early export has an advantage of
lower register usage, therefore more concurrent waves.
The idea of this commit is that "small" shaders benefit from early
primitive export more, due to being able to launch much more waves.
Let's consider a NIR shader "small" when it has only 1 block.
This yields both better performance, and better stats, than always
using late export.
Fossil DB on Sienna:
Totals from 12807 (8.76% of 146265) affected shaders:
VGPRs: 609128 -> 620216 (+1.82%); split: -0.01%, +1.83%
SpillSGPRs: 1458 -> 1538 (+5.49%)
CodeSize: 37028204 -> 37019320 (-0.02%); split: -0.17%, +0.14%
MaxWaves: 282902 -> 278516 (-1.55%)
Instrs: 7163142 -> 7162925 (-0.00%); split: -0.18%, +0.18%
VClause: 169285 -> 169547 (+0.15%); split: -1.15%, +1.30%
SClause: 267373 -> 267151 (-0.08%); split: -0.24%, +0.16%
Copies: 446442 -> 444567 (-0.42%); split: -2.68%, +2.26%
Branches: 156245 -> 156195 (-0.03%); split: -0.30%, +0.26%
PreSGPRs: 434701 -> 447396 (+2.92%)
PreVGPRs: 527783 -> 540527 (+2.41%)
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10106>
The user-set priority of shaders matters very little, but we hope
this might still help speed up VS input loads especially.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10106>
We learned that the gs_alloc_req is not actually when the export
space allocation happens. So it makes no sense to prioritize it.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10106>
This fixes basic rendering on top of V3DV, which doesn't seem to expose
the cached memory we expect and love.
Fixes: 598dc3dca4 ("zink: use cached memory for all resources when possible")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10230>
Previously, every wave had multiple active lanes read the LDS, and
the data was processed by VALU DPP instructions.
Now, only the first lane reads the LDS in order to avoid bank
conflicts, and the results are processed by SALU.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10155>
The key passed to _mesa_hash_table_search() is wrong, fix it.
Fixes: 8ba2f9f698 ("panfrost: Create a blitter library to replace the existing preload helpers")
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10232>
This seems to simply be a mixup of what utility function to use.
util_clear_render_target clears on the CPU, whereas
util_blitter_clear_render_target clears on the GPU. Because we do the
zink_blit_begin dance, it seems reasonable to assume the latter was
intended.
Fixes: 622f8f6ed5 ("zink: add a pipe_context::clear_texture hook")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10211>
Among other things, this gets us GCC 10 (was 6).
Requires some changes to third party components we use:
* Install apitrace (& waffle) from Debian; was hitting issues with the
local build, and it's the same version 9.0 anyway.
* Update Fossilize to a newer commit which builds with GCC 10.
* apt.llvm.org repositories are no longer needed.
* Use an SPIRV-LLVM-Translator commit which builds with LLVM 11.0.1.
* Install XCB packages from Debian, 1.13 fails to build with Python 3.9.
* Install wayland-protocols from Debian, 1.12 is too old for
libgtk-3-dev in bullseye.
LLVM 7/8 packages are no longer available.
Also adapt expected test results to Xvfb now exposing multi-samle
GLXFBConfigs.
v2:
* Install clang instead of clang-11.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3124
Reviewed-by: Eric Anholt <eric@anholt.net> # v1
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9833>
Avoids warning with GCC 10:
../src/intel/blorp/blorp_blit.c: In function 'blorp_nir_combine_samples':
../src/intel/blorp/blorp_blit.c:702:25: error: 'texture_data[0]' may be used uninitialized in this function [-Werror=maybe-uninitialized]
702 | texture_data[0] = nir_fmul(b, texture_data[0],
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
703 | nir_imm_float(b, 1.0 / tex_samples));
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9833>
Avoids warning with newer GCC:
../src/gallium/drivers/r600/sb/sb_sched.cpp: In member function 'void r600_sb::literal_tracker::reset()':
../src/gallium/drivers/r600/sb/sb_sched.cpp:1953:26: error: 'void* memset(void*, int, size_t)' clearing an object of non-trivial type 'struct r600_sb::literal'; use assignment or value-initialization instead [-Werror=class-memaccess]
1953 | memset(lt, 0, sizeof(lt));
| ^
In file included from ../src/gallium/drivers/r600/sb/sb_sched.cpp:35:
../src/gallium/drivers/r600/sb/sb_bc.h:409:8: note: 'struct r600_sb::literal' declared here
409 | struct literal {
| ^~~~~~~
[ Michel Dänzer:
* Expanded commit log
v2:
* Clear all 4 members of lt[4] (Eric Anholt)
]
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9833>
No fossil-db changes, probably because all fp16 shaders have at least one
16-bit mov or vec2 somehwere.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10227>
VK_KHR_spirv_1_4 is trivial because vtn already supports all the added
SPIR-V features that aren't gated behind Vulkan extensions. I've
observed some robustness2 CTS tests requiring this. However there are
a few tests currently failing due to lacking spilling.
VK_EXT_scalar_block_layout should also be trivial, since support for
"straddling" UBO loads was added recently for other reasons. This is
used by every robustness2 CTS test.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8695>
64 was a temporary and conservative "big enough" value, but we can do
better.
Note that as mentioned on the FIXME, we could be even more detailed,
adding a descriptor map allocate method based on the descriptor
type. That would mean more individual allocations, and slightly more
complexity.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10207>
We had some cases were we have defined a value on v3dv_limits but
using other when setting it at GetPhysicalDeviceProperties (like
dynamic storage buffers).
Also we do a cleanup. So far we were adding on v3dv_limits only the
limits that were used on more that one place. But then we had the
definition of several limits on different places. It is clearer to
have a common place for those, even if it is used on just one place.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10207>
There were two problems here:
* We were multiplying by 6, when for graphics pipelines, we only
support 2.
* Right now we are tracking descriptors through the descriptor
maps, and we have one per pipeline. So in practice there is no
difference between per-stage and per-pipeline limits. So far this
was not a problem, we could revisit in the future.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10207>
Layered VRS attachments is for later.
The CTS failures are similar to the existing ones, I will investigate
soon.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10187>
The global VRS image is created on-demand to avoid wasting space.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10187>
When a subpass uses a VRS attachment without binding a depth/stencil
attachment (yes, this is allowed by the Vulkan spec), we have to bind
our internal depth buffer that contains the VRS data.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10187>
The Vulkan spec doesn't require the application to always binds
a depth/stencil attachment when a VRS attachment is used inside the
same subpass.
To handle this situation, the driver creates a global 4096x4096
VRS image that will be bind at draw-time if needed. This isn't
super ideal but we have to do that unfortunately.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10187>
The stencil data needs to be included for storing the VRS rates
into the HTILE buffer.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10187>
When VRS attachment, any depth buffer can potentially be used for VRS.
We also have to create a global depth buffer if the app doesn't
provide one.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10187>
The Vulkan spec requires the implementation to only supports
VK_SAMPLE_COUNT_1_BIT with fragment shading rate attachments.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10187>
This will be used to copy VRS rates to the HTILE buffer.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10187>
For the HTILE equation.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10187>
gfx9_meta_equation will be used to store the HTILE equation.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10187>
This file will also contain HTILE equation tests.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10187>
Similar to the DCC address equations. Only GFX10+ because this
is for copying VRS rates to the HTILE buffer.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10187>
For these caps, we need to check all stages to be sure we've got things
right.
Again, this is probably benign, because LLVMpipe should support the same
value for all stages.
Fixes: b38879f8c5 ("vallium: initial import of the vulkan frontend")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10189>
We should really check for the minimum of all supported vertex-stages
here, not just the vertex-shader.
This shouldn't make any real-world difference, because we really only
support LLVMpipe here, and that driver has the same limits for all
stages. But it seems better to actually check all stages instead of just
assuming.
Fixes: b38879f8c5 ("vallium: initial import of the vulkan frontend")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10189>
This seems arbitrary, and makes us check for PIPE_SHADER_CAP_MAX_SAMPLER_VIEWS
instead of PIPE_SHADER_CAP_MAX_SHADER_IMAGES, which isn't what we want.
The end result is that we accidentally exposed 128 shader images,
instead of 16. This can lead to us writing outside of the array of
shader images in llvmpipe_set_shader_images, among other bad things.
Fixes: b38879f8c5 ("vallium: initial import of the vulkan frontend")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10189>
With tearfree_discard=false, we tear when rendering
fullscreen apps with vsync off.
This is a feature in the sense it's the same as the native
implementation. This also means lower input lag.
However I think most users will prefer to have no tearing,
and don't care about sub refresh-rate input lag.
Thus it's better to default tearfree_discard to true.
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
Acked-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10160>
When rendering fullscreen with vsync on at
a rate close to the refresh rate, you can
miss pageflips by submitting buffers for pageflip
that end up not finished being rendered when the pageflip is due.
With Nine in this situation you could get half the refresh
rate fps before this patch.
Due to the way the presentation backend is implemented,
it's not possible to easily detect the situation and adapt (use
one more backbuffer, but only in this scenario to not increase input
lap when the issue is not present).
thread_submit doesn't have this issue.
Let's default thread_submit to true.
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
Acked-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10160>
Use the Async flush flag to return faster during
Present() when thread_submit is used.
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
Acked-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10160>
Running some high fps benchmarks, thread_submit gets
subpar fps with the option tearfree_discard.
Increasing the number of backbuffers fixes it.
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
Acked-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10160>
512 MB is too ambitious as default value.
128 MB seems safer, and users can increase the limit
manually for the few games that would benefit from it.
Also fixes a typo in the description
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
Acked-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10160>
Until the problem described in
https://gitlab.freedesktop.org/mesa/mesa/-/issues/4489
is fixed, the advantages of using a sw renderer for the
sw rendering in nine are too small compared to the
disadvantages.
Add an option to control whether we use a sw renderer,
and make it so by default we don't.
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
Acked-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10160>
This can be useful for debugging, or for some apps
not supporting >= 4GB of vram.
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
Acked-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10160>
This enables radeonsi to really unmap on release,
which reduces virtual memory usage.
Do it only on 32 bits, as it can reduce performance if the
allocation is reused.
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
Acked-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10160>
I held for a long time the belief DISCARD wins
over NOOVERWRITE, backed by experiments.
But probably both behaviours are ok.
For perf it is better to have NOOVERWRITE win.
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
Acked-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10160>
Returning D3D_OK instead of an error when it
makes sense.
Return the value passed previously (or the default)
when it makes sense.
Add (void)variable for unused input variables.
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
Acked-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10160>
The redundancy check is done in the nine_context function,
rather than the device function, in order to also filter
calls from SetRenderTarget and Reset*.
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
Acked-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10160>
GL does the same.
Fixes the low texture quality issue of
https://github.com/iXit/wine-nine-standalone/issues/21
The are some indications it might not be the native
behaviour (which makes sense, the native filtering
of states seems more to not update internal states
when the passed value is invalid).
However it's better visually to have anisotropic filtering
enabled in these buggy cases.
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
Acked-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10160>
Wine tests seem to indicate more the 256 should
be supported for this case, but I couldn't find the
doc for how much it should be. Use the vs >= 2
settings for now.
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
Acked-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10160>
When D3DFMT_NULL is set as render target,
we must take the multisampling state
from the depth buffer.
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
Acked-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10160>
The sequence of states to disable NVidia alpha
to coverage was disabling AMD alpha to coverage.
This patch fixes it.
Found with wine tests.
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
Acked-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10160>
Prevents a crash in wine tests. Not sure
this behaviour is the correct one, but at
least it'll check the IID passed is the device
before returning it.
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
Acked-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10160>
According to wine tests, some apps can allocate very
small ATI1/ATI2 textures levels.
The issue is that the CPU versions of these textures are stored
in buffers which size is the same as if the format was uncompressed.
Thus the content filled cannot possibly be correct for these levels.
The tests seems to hint when rendering with these levels the output
is bad, but at least it the runtime shouldn't crash when using them.
Previously nine would read outside bounds (found with asan) in this
scenario, as the gallium helper copies a full compressed block.
Instead do not copy anything for these levels.
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
Acked-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10160>
Apparently it is incorrect to use the pointer in
LIST_FOR_EACH_ENTRY like I used to.
Found with asan.
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
Acked-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10160>
When the surface creation fails, the dtor
can face NULL pointers for the surfaces.
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
Acked-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10160>
Fixes regression introduced by:
a179ea2e "st/nine: Use the texture memory helper"
The device is used on texture/surface dtor since this commit.
We need to early fill the device field in case of error.
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
Acked-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10160>
v2:
- Bump up MESA_ROOTFS_TAG instead of arm_build (Michel)
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10136>
Since virgl has no backend compilation, this is just a disk cache for the
frontend. As such it is very simple and only implements enough for
get_disk_shader_cache() to work.
With portal2 apitrace:
Before: 100.65 fps
After: 129.051 fps
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10200>
No-op dispatch should only be setup for full reset, not soft-recovery resets.
The same trick cannot be used in si_get_reset_status because EGL expects
us to return GL_***_CONTEXT_RESET even if it has been fixed by a soft
recovery.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10179>
Using this boolean the caller tells if it wants to ignore resets
fixed by a soft recovery.
When true, amdgpu can skip the call to libdrm if no cs has been
rejected (since only full gpu reset cause cs rejections).
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10179>
If a GPU reset occurs, all contexts need to be recreated.
So instead of re-creating the aux context during the flush
of a normal context, we build a new one if we detect that
it needs to be updated.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10179>
When a GPU hang is detected in the kernel, it can uses 2 different
mechanism to recovery: a soft recovery or a hard reset.
Soft recovery doesn't lose the vram content so contexts are still
valid. In this case we don't need to recreate the aux context.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10179>
The kernel can do different types of recovery (soft recovery, GPU reset).
Since they both increase gpu_reset_counter, this will cause all contexts
to report AMDGPU_CTX_QUERY2_FLAGS_RESET, which is a bit misleading: if
a single context was soft-recovered, the others are fine and we don't need
special processing.
This commit uses the AMDGPU_CTX_QUERY2_FLAGS_VRAMLOST to distinguish
between the 2 kind of reset and later commits will use this information.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10179>
If info->take_index_buffer_ownership is true we can skip
refcounting but only for the first iteration of the loop.
The next iterations have to use tc_set_resource_reference.
Fixes: 363c1ef0c0 ("gallium/u_threaded: split draws that don't fit in a batch")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10171>
Group mediump varyings and don't put 16-bit and 32-bit components
in the same vec4.
... and reply to the comment there.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10224>
The kill_outputs logic uses our internal IO indices. Just add indices for
16-bit varyings. We don't have enough free indices to use, but we can reuse
the indices that GLES doesn't have. Those are all the legacy desktop GL
varyings.
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9051>
Somewhat terrifyingly, we never sent this for direct contexts, which
means the server never knew the context/drawable bindings. To handle
this sanely, pull the request code up out of the indirect backend, and
rewrite the context switch path to call it as appropriate. This
attempts to preserve the existing behavior of not calling unbind() on
the context if its refcount would not drop to zero.
Of course, you can't just do this indiscriminately, because this is GLX
and extant X servers have bugs and everything is terrible. To wit:
- For 1.20.x prior to 1.20.6, you can bind a direct context once, but
the second time you try to modify the context's binding you will get
GLXBadContextTag. This includes unbinding the context. And "deleting"
the context will leak memory, because it will still appear to be
current.
- For 1.19 and earlier, glXMakeCurrent(dpy, None, ctx) should be legal
for GL 3.0+ contexts, but the server will throw BadMatch.
To guard against this, we only send the request for indirect contexts
unless the server is known good, and only mention one context at a time
in such a request; if switching between contexts, we first unbind the
old, and then bind the new. Note that the second VendorRelease() version
is to catch XFree86 4.x and Xorg [67].x, which almost certainly have the
above bugs. Other servers might report different version numbers here,
but we can't do direct rendering against them, so this should be safe.
Fixes: mesa/mesa#4418
Acked-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9992>
We've never read any of this out. The transparency stuff we've never
implemented and the shift/mask stuff doesn't vary independently enough
to need to match on.
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9992>
Move the macros defining the expected number of attributes into the same
file as their consumer, remove a pointless maximum, and allocate more
space for attribs on the stack to avoid malloc in the common case.
glxext.c knows about 46 config attribs, 46 - 18 = 28, round up to 32 to
future proof a bit.
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9992>
When a surface of type SURFTYPE_NULL is accessed by resinfo, the MIPCount
returned is undefined instead of 0.
Closes#4309
Fixes dEQP-VK.robustness.robustness2.*.sampled_image.*.null_descriptor.*
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10147>
The previous pass was based on misconceptions and
rounded up with bug fixes. The new pass is entirely
rewritten and basically just one-to-one from the paper:
"Revisiting Out-of-SSA Translation for Correctness, CodeQuality, and Efficiency"
by B. Boissinot et al.
It also incorporates the value-equality testing.
The regressions are mainly due to creating parallelcopies for
exec phis at loop headers (mitigated in the next commit).
Totals from 4933 (3.61% of 136546) affected shaders (Raven):
SpillSGPRs: 16249 -> 16527 (+1.71%); split: -0.28%, +1.99%
SpillVGPRs: 1771 -> 1595 (-9.94%)
CodeSize: 57544436 -> 58280304 (+1.28%); split: -0.00%, +1.28%
Scratch: 176128 -> 179200 (+1.74%)
Instrs: 11265783 -> 11445884 (+1.60%); split: -0.00%, +1.60%
Latency: 552596156 -> 555880540 (+0.59%); split: -0.53%, +1.13%
InvThroughput: 271431862 -> 273097423 (+0.61%); split: -0.18%, +0.79%
VClause: 160240 -> 160241 (+0.00%); split: -0.02%, +0.02%
SClause: 386863 -> 386685 (-0.05%); split: -0.07%, +0.02%
Copies: 1180801 -> 1345633 (+13.96%); split: -0.02%, +13.98%
Branches: 379129 -> 393052 (+3.67%); split: -0.01%, +3.69%
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9196>
To decide which variables to spill, we must use the distances at the
beginning of the loop-header, and not the distances at the end of the
loop-preheader. The difference are that the former includes phis which are
viable to be spilled as opposed to the phi operands which would be reloaded
by add_coupling_code(), ending up in potentially too high register pressure
before the loop.
Totals from 206 (0.15% of 136546) affected shaders (Raven):
SpillSGPRs: 5154 -> 5000 (-2.99%)
CodeSize: 3654072 -> 3647184 (-0.19%); split: -0.19%, +0.00%
Instrs: 701482 -> 700526 (-0.14%); split: -0.14%, +0.00%
Latency: 40988780 -> 40872506 (-0.28%); split: -0.29%, +0.00%
InvThroughput: 20364560 -> 20306006 (-0.29%)
SClause: 20192 -> 20198 (+0.03%)
Copies: 77732 -> 77688 (-0.06%); split: -0.08%, +0.03%
Branches: 24204 -> 24050 (-0.64%)
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9196>
This also fixes some hypothetical issue for loops without phis
and for loops with higher register pressure at the end of the
loop preheader.
No fossil-db changes.
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9196>
This handles the case of
exec = p_linear_phi %a, %b
where %a or %b might have been spilled.
By directly reloading these variables into the exec mask register,
we can avoid additional CSSA parallelcopies.
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9196>
We only do that when there are more than one damage rectangle and the
number of tiles to reload is significantly lower than the total number
of tiles covered by the damage extent, otherwise the overhead of the
TEM read might defeat the optimization that we might get from using one.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10033>
Now that the gallium driver uses the pan_preload() helpers we can get
rid of the code in pan_blit.c and all its dependencies.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10033>
We also rework the code to have the FB descriptor shared by the tiler
and fragment jobs, instead of allocating a separate FB descriptor for
tiler jobs.
The new implementation seems to fix a few dEQP failures on T720.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10033>
The KHR_partial_update spec says:
"
If EGL_EXT_buffer_age is supported, the contents of the buffer inside
the damage region may also be relied upon to contain the same content
as the last time they were defined for the current back buffer.
"
but we currently assume that everything inside the damage region will
be overwritten by new data and that the previous content doesn't need
to be reloaded.
Let's get rid of the damage rect inversion logic for now and reload
everything inside the damage extent. We will optimize things further
down the line, using pre-frame DCDs on Bifrost, and a tile enable map
on Midgard.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10033>
pan_blitter.c is meant to replace the pan_blit.c which currently
provides helpers to preload the tile buffer. Some changes
are worth mentioning:
- we use pre-frame DCDs on Bifrost (Midgard still uses a tiler job
to preload the tile buffer)
- the blit shaders are now stored in a hash table and created lazily
- we now cache blend shader binaries and blit RSDs too
This library will soon be extended to cover regular blits.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10033>
We will soon have a different handling for Bifrost, and we need to know
which GPU we're targeting to choose the right path.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10033>
We will use this tile enable map to implement KHR_partial_update and
replace the current solution where the preload process is done by
inverting damage regions, merging the resulting inverted regions and
issuing preloading draws for those rectangles.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10033>
Bifrost FB descritptors can be attached 3 DCDs describing pre/post frame
operations (pre frames DCDs can be used to preload the tile buffers).
Decode them when mode != NEVER.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10033>
We will soon use this function to decode pre/post frame DCDs which are
not part of a job descriptor.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10033>
Needed if we want to allocate pre/post frame draw descriptors.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10033>
Now that image and image views are gallium-agnostic and contain enough
information, we can provide generic helpers to emit FB descriptors and
their dependencies, thread storage and tiler descriptors.
This helpers will be re-used in the Vulkan driver.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10033>
This function doesn't modify the dev object, we can constify this
argument.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10033>
pan_image_view contains everything we need to emit a texture
descriptor. Pass this object instead of the dozen of arguments
we have now.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10033>
Now that we have a generic implementation, we can use it and get rid
of panfrost_setup_layout().
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10033>
We are about to move the panfrost_setup_layout() logic out of the
gallium driver, and the Z32_S8X24 split is not mandatory (some GPU
support this format natively). Let's move this special case out of
panfrost_setup_layout() and patch the format of the first plane
instead.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10033>
We already have the data BO stored there, let's move the out-of-band
CRC BO too. We also add a CRC mode to pan_image_layout so we can easily
know where the CRC resides.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10033>
Move the image view bit out of pan_image and create a separate
pan_image_view struct. Once this is done we can embed a pan_image
object in panfrost_resource which will be referenced by the image
view that we pass to panfrost_load_{midgard,bifrost}().
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10033>
This means duplicating some of the bits we already have in the
pipe_resource object embedded in panfrost_resource, but if will also
allow us to move some code out of the gallium driver without requiring
copy those fields every time we call a generic helper.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10033>
The depth field is ignored if dim != 3D, but it's a bit confusing.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10033>
We will need this information at the layout level if we want to move
some of the code out of the gallium driver and share it with the
Vulkan driver. Let's get rid of panfrost_resource.internal_format which
basically encodes the same thing.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10033>
The layout is supposed to encode image miplevels/surfaces layout, not
the state data stored in the buffers. It doesn't matter for a gallium
driver, since resources are expected to hold both a layout and a state,
but Vulkan is a bit different. In Vulkan, the image state is explicitly
passed by the user when starting a render pass (vkCmdBeginRenderPass()),
and might evolve depending on the operation done in this render pass.
This state is not effective until the command buffer is queued and
executed. For these reasons, keeping the image state attached to the
VkImage object is not an option, but we'd still like to re-use the
layout and state objects, and all common helpers acting on those objects.
Let's move the state bits out of the layout to make that possible.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10033>
We are about to move slice states out of the panfrost_slice object,
but before we do that, let's rename the existing struct to reflect what
this object refers to.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10033>
These decorations allow you to override the signedness of image
instructions. This means that we have to override the type we get from
the sampled image.
Apparently both Intel and AMD get the type from the descriptor rather
than the instruction, but this appears to not be the case with Adreno,
which is why this wasn't noticed until now. So this probably won't fix
any preexisting bugs, but it's required to fix
dEQP-VK.image.extend_operands_spirv1p4.* when exposing VK_KHR_spirv_1_4
on turnip.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7968>
As documented in 6ec7e0d406 (gallium: document convention for get_handle
calls on multi-planar resources) it's the drivers responsibility to walk
the chain of resources for multi-planar resources. The get_handle interface
should always be called with the base resource by the frontend.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Acked-by: Simon Ser <contact@emersion.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10212>
Ensure subpass_idx has a valid value; we use "-1" as invalid one.
Fixes CID#1468096 "Macro compares unsigned to 0 (NO_EFFECT)"
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10203>
When creating the Vextex Shader bin, only store outputs that will be
read later as inputs by the Geometry Shader bin.
This fixes
KHR-GLES31.core.geometry_shader.rendering.rendering.lines_input_triangle_strip_output_line_loop_drawcall
(exposed by previous commit).
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10129>
Vertex Shader has a store_out lowering pass that converts gallium driver
locations in offsets inside the VPM.
One of the consequences is that these offsets are consecutives; that is,
if the VS stores VARYING_SLOT_VAR0.xyz and VARYING_SLOT_VAR1.xyzw, there
isn't a hole in the VPM offsets for the un-stored VARYING_SLOT_VAR0.w.
Thus we need to change how the VPM offset is computed in the Geometry
Shader when loading the inputs.
This bug is exposed by !9050.
v2 (Iago):
- Include explanatory comment.
- Use assert.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10129>
If the pipeline struct isn't found, the state might still be dynamic.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10193>
When formatting the error here, we're currently casting an
ast_type_qualifier as a string.
But we don't need to use a string here at all, because we know from
context exactly what qualifier we're talking about, because the
if-statements explicitly check for the uniform-qualifier.
So let's just hard-code the format-string to reference the right
qualifier instead of the string-shenanigans. The latter cannot do the
right thing.
Fixes: 2d03f48a65 ("glsl: Add parsing for GLSL uniform blocks.")
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9911>
Dave Airlie
Rob Clark
Marek Olšák
Chia-I Wu
Eric Anholt
Mike Blumenkrantz
Francisco Jerez
Jesse Natalie
Mauro Rossi
Axel Davy
Michel Dänzer
Simon Ser
Iago Toral Quiroga
Lionel Landwerlin
Juan A. Suarez Romero
Rhys Perry
Adam Jackson
Samuel Pitoiset
Matt Turner
Jordan Justen
Rafael Antognolli
Yiwei Zhang
Alexander Shi
Icecream95
Connor Abbott
Gustavo Padovan
Hans-Kristian Arntzen
Karol Herbst
Alejandro Piñeiro
Samuel Iglesias Gonsálvez
Felix DeGrood
Kenneth Graunke
Sagar Ghuge
Boris Brezillon
James Park
Erik Faye-Lund
Bas Nieuwenhuizen
Timur Kristóf
Pierre-Eric Pelloux-Prayer
Stéphane Marchesin
Iván Briano
Jason Ekstrand
Ella-0
Daniel Schürmann
Lucas Stach