For color buffers, conditional fast clears can cause aux-state tracking
to lose information necessary for resolves later on.
For depth buffers, they never actually worked because they occurred
unconditionally. Even if they were conditional, they would suffer from
the same issues as color buffers.
Enables iris to pass the nv_conditional_render-clear-bug piglit test.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3565
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7762>
Apart from an issue with fast clears that will be addressed soon,
aux-state tracking with conditional rendering works because the
aux-state info needed for performing required resolves is never lost.
Add comments explaining how this works. Assertions are omitted to avoid
having to pass render_condition variables into
iris_resource_prepare_access and iris_resource_finish_write.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7762>
GLES3 supports pause/resume of xfb. However since there's no geometry
shader support in ES3, it's a lot easier to figure out the offsets to
use. This makes it work for the dEQP tests at least.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8346>
We don't support stencil-exports yet, and even when we will, we might
not support it on all hardware. So we really need an alternative plan
here, even when render_condition_enable is true.
Fixing this properly is much more involved, and depends on reworking
render-condition along the lines that we do in !7746 to support pausing
and resuming properly first. So let's do the minimal thing, which is to
allow this to work in cases where no render-condition is active.
Fixes: 767f70dfe1 ("gallium/util: fix util_can_blit_via_copy_region for conditional rendering")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4056
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8379>
some vulkan drivers (e.g., amdvlk) advertise absolutely huge values here,
resulting in bitmask overflows everywhere since gallium assumes a max of
32 for vertex inputs and nir uses 64bit types for others
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8318>
In order to handle blitting the stencil aspect of a depth-stencil
resource, use aspect-specific pipe formats in the aspect_mask loop.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8340>
When blitting just the stencil aspect, the source and destination
resources are prepared/setup twice. Move the unconditional resource
setup into the aspect_mask loop to avoid this.
In addition, use the aspect provided by the loop instead of the mask
provided by the info parameter.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8340>
Use iris_resource_prepare_texture in iris_blit to avoid partial resolves
for sRGB <-> linear texture views. This affects a trace of L4D2.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8340>
Instead of having a depth-specific assertion in a generic portion of
iris_blit, move it into the depth-specific cases of
iris_resource_texture_aux_usage. Since iris_blit calls that function,
the test still occurs.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8340>
Before this change, iris_blit would prepare the depth buffer in a
depth-stencil resource even when only the stencil aspect was used for the
blit. Use the aspect mask to prepare the correct resource.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8340>
There is a path to blit stencil buffers reinterpreting the stencil data
as an RGBA8888 or R8 float texture.
This works fine except for the case when the stencil buffer is
multisampled, and the blit operation needs to resolve it: an average of
the samples is done, which is incorrect, as only one sample must be
used.
This can be observed n the piglit test
`ext_framebuffer_multisample-unaligned-blit 2 stencil downsample -auto
-fbo`, specifically in the triangles border.
To avoid this averaging, let's reinterpret the stencil data as RGBA8888
or R8 uint texture.
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8361>
Increase the scope of atomic operations from GPU to system. This is
required for support of SVM to ensure atomic access is maintained for
memory buffers that are not local to the current GPU.
Signed-off-by: Alistair Popple <apopple@nvidia.com>
Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7955>
GV100 code generation uses ATOM instructions for compare-and-swap and
RED instructions for other atomic operations. Make the scope consistent
for both types of operations.
Signed-off-by: Alistair Popple <apopple@nvidia.com>
Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7955>
It didn't do anything useful. GS doesn't use the other user SGPRs.
If we decrease the number of user SGPRs we declare for the GS prolog,
we can remove gfx9_prev_is_vs.
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8344>
LLVM expects that exec != 0 when entering loops and generates this code
that becomes an infinite loop if exec == 0:
BB5_1:
vcc_lo = (inverted terminating condition)
s_and_b32 vcc_lo, exec_lo, vcc_lo
s_cbranch_vccnz BB5_3 // jump if vcc != 0 (break statement)
// ... loop body ...
s_branch BB5_1
BB5_3:
For non-monolithic VS before TCS, VS before GS, and TES before GS,
we set exec = (thread enabledmask), which sets 0 for HS-only and GS-only
waves, causing the infinite loop condition above.
Fix it as follows:
- set exec = ~0 at the beginning
- wrap the whole shader (LS and ES) in a conditional block, so that HS-only
and GS-only waves jump over it and never enter such a loop
The TES before GS hang can be reproduced by gfxbench:
testfw_app --gfx egl -w 1920 -h 1080 --gl_api gles -t gl_tess
Fixes: 68d6d097f1 - radeonsi/gfx9: add GFX9 and VEGA10 enums
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8344>
Stencil texture sampling (such as what we have to do for BlitFramebuffer)
is broken with UBWC enabled. We can't just take the
fd_resource_uncompress() path, because that's a blit just like
BlitFramebuffer.
Fixes failure in dEQP-GLES3.functional.fbo.msaa.2_samples.stencil_index8,
but also the uncaught rendering fails of 4_samples.stencil_index8 and
depth24_stencil8.
Prior to "911ce374caf0 freedreno/a6xx: Fix MSAA clear" we would usually
pass and sometimes flake fail on this test occasionally, thus it being
listed as a flake (though the rendering was actually broken). Since that
commit, though, we consistently fail on a pixel of the broken rendering,
and thus this was brought to my attention by the #freedreno-ci channel
spam.
Rob took a look at the performance impact of this, and the worst was maybe
up to .5% fps hit on trex.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8319>
Sync Android.mk GALLIUM_TARGET_DRIVERS names from kmsro meson.build,
notably adding the missing mediatek, meson and rockchip display drivers
names.
It also fixes the imx name into imx-drm as referenced in meson.build
and src/gallium/targets/dri/target.c
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7443>
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8295>
fcsel is only emitted by bool -> float lowering. We used to do that a
long time ago, but no longer. So we don't need to support this opcode
any longer.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8347>
We recently added two versions of these options, due to soft-fp support.
So let's also add the lowering to the soft-fp version.
Fixes: 43302ead38 ("zink: use lower_scmp instead of open-coding")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8347>
The AFBC layout of RT/ZS-extension descriptors on Bifrost v6 matches the
v7 one except for the Block Format field. Update the set_buf() functions
accordingly.
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/8328>
Enable vrs2x2 coarse shading if flat shading as per
idea and guidance given by Marek.
is_flat_shading variable in struct si_shader_info is set
based on the data from gather_intrinsic_info() function
and struct si_state_rasterizer. If is_flat_shading_variable
is set, then in function si_emit_db_render_state() vrs2x2
shading is enabled in hardware.
v2: Fix review comments from Pierre-Eric. Code optimizations.
v3: Fix indentation style issue.
v4: Fix review comments from Marek. Fixed logical issue pointed
by Marek where info->is_flat_shading variable can be corrupted
and other code cleanup.
v5: Make the code compact as suggested by Pierre-Eric.
v6: Fix new review comments from Marek.
v7: use info->uses_interp_color variable fix from Marek.
v8: Fix coding style comment from Marek.
v9: Add uses_fbfetch_output check as suggested by Marek.
Signed-off-by: Yogesh Mohan Marimuthu <yogesh.mohanmarimuthu@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8161>
I had a funny +1 in nir_to_tgsi's load_ubo lowering on the buffer index,
because I hadn't set lower_uniform_to_ubo for softpipe. This removes that
weirdness in favor of just using lower_uniform_to_ubo, regardless of
driver preference (which matters if a NIR-native driver had it set, and
then the gallium draw module triggered the non-LLVM TGSI fallback path
that hit NTT).
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8196>
There's not really a reason to directly map textures. Doing so
requires the texture to be allocated in system RAM instead of
video RAM, which means all GPU access to it would be needlessly slow.
Notably, the one texture type that was allocated this way is the
display target texture for the software driver path. Instead, use
pipe_transfer_map to be able to copy the texture to system RAM.
Reviewed-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8095>
For non-CPU-accessible pipe resource types (DEFAULT/IMMUTABLE),
allocate non-CPU-accessible buffers directly from the cache_bufmgr.
Update the d3d12_bo creation to handle nonmappable buffers.
For CPU-write-only (DYNAMIC/STREAM), use the upload slab_bufmgr.
Update this slab manager to use CPU_WRITE | GPU_READ PB usage.
For CPU-read-write (STAGING), use the readback_slab_bufmgr.
Reviewed-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8095>
Readback (GPU write, CPU read) should use different CPU page
properties compared to upload (write-back vs write-combined).
A future commit will start to respect these PB usage flags.
Reviewed-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8095>
Currently all buffers are allocated as mappable, but a future
commit will change that so that some buffers can be allocated
directly in non-CPU-accessible memory for improved performance.
Note that the returned pointer must be appropriately offset from
a 64-byte-aligned base pointer, so if offsets are used, the data
will be read/written to an offset region in the staging buffer.
Reviewed-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8095>
