The small DCE of the spiller only removes the original instructions
of rematerialized variables in case they are unused. If a variable
has been renamed, it cannot match any original instruction anymore.
Thus, the lookup is then unnecessary and can be omitted.
No fossil-db changes.
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8055>
(cherry picked from commit ef4101d6d7)
strstr returns a pointer to the needle sub-string within the haystack
string if the latter contains the former, or NULL otherwise. So this
essentially always set info->is_pro_graphics = true, since probably no
marketing name ever contains all of these sub-strings.
Fixes: b635dff256 "ac: fix detection of Pro graphics"
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7675>
After we lowered `return` into `break` - the control flow is changed and
the block with this change has a new successor, which means that in this
new successor phis should have additional source.
Since the instructions that use phis in the successor are predicated -
it's ok for a new phi source to be undef.
If `return` is lowered in a nested loop, `break` is inserted in the outer
loops, so all new blocks with break require the same changes to phis
described above.
Examples of NIR before lowering:
block block_0:
loop {
block block_1:
if ssa_2 {
block block_2:
return
// succs: block_6
} else {
block block_2:
break;
// succs: block_5
}
block block_4:
}
block block_5:
// preds: block_3
vec1 32 ssa_4 = phi block_3: ssa_1
// succs: block_6
block block_6:
Here converting return to break should add block_2 to the phis
of block_5.
block block_0:
loop {
block block_1:
loop {
block block_2:
if ssa_2 {
block block_3:
return
// succs: block_8
} else {
block block_4:
break;
// succs: block_6
}
block block_5:
}
block block_6:
break;
// succs: block_7
}
block block_7:
// preds: block_6
vec1 32 ssa_4 = phi block_6: ssa_1
// succs: block_8
block block_8:
Here converting return to break will insert conditional break in
the outer loop, changing block_6 predcessors.
Cc: <mesa-stable@lists.freedesktop.org>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3322
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3498
Signed-off-by: Danylo Piliaiev <danylo.piliaiev@globallogic.com>
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6186>
Using more blend targets than specified by maxFragmentDualSrcAttachments
is invalid per the Vulkan spec.
I'm usually not a fan to workaround game bugs inside the driver but
it's really easy for us to ignore MRT1+ in the driver and that
prevents wrong behaviour.
Cc: 20.2, 20.3
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/7684>
(cherry picked from commit bc7f442d8e)
the code here tries to be too smart and only use a geometry shader if there's
actually multiple layers being uploaded, but the fragment shader also unconditionally
reads gl_Layer as long as the pipe cap for gs is set, which means that
in the case when the gs is dynamically disabled due to uploading a
single-layer surface, the fs has no input to read for gl_Layer and everything breaks
always using a gs isn't ideal, but it's considerably more work to manage multiple
fs variants based on layer usage
Fixes: c99f2fe70e ("st/mesa: implement PBO upload for multiple layers")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8067>
(cherry picked from commit 614c77772a)
This workaround fixes a hang while loading a renderdoc trace for me.
Since the workload does 1 mip per cmdbuffer it is quite hard to confirm
what exactly the conditions for the hang are but this is the most
restrictive set I found and it corresponds to a workaround in AMDVLK as
well.
CC: mesa-stable
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7210>
(cherry picked from commit 4cce4d22a7)
PIPE_MAX_CONSTANT_BUFFERS is 32, however many Vulkan implementations
has maxPerStageDescriptorUniformBuffers that exceeds it, for example:
radv 8388606,
anv 64
nvidia 1048580 for RTX 2000 and up.
and, together with the current zink logic, the returned value
will exceed the maximum allowed value for the cap.
This causes cso_destroy_context to pass big values back to zink
(via zink_set_constant_buffer), resulting in access beyond end of
allocated buffer for all UBOs.
Cap the cap to PIPE_MAX_CONSTANT_BUFFERS (32), not INT_MAX.
Add an assert to verify future drivers.
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Fixes: daaf5f1d18 ("gallium: Fix leak of currently bound UBOs at CSO context destruction.")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7976>
(cherry picked from commit e2b4247e40)
We need to pick 1u vs 1.0f based on the type of the texture, just like for
normal samples. Move the decision up to the create_sampler_view, and use
that value from both sampler paths.
Cc: mesa-stable
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8012>
(cherry picked from commit 4ba884b814)
avoids errors seen when building on OpenBSD/amd64
../src/amd/compiler/aco_instruction_selection.cpp:1677:62: error: ambiguous conversion for functional-style cast from 'unsigned long' to 'aco::Operand'
bld.vop3(aco_opcode::v_mul_f64, Definition(dst), Operand(0x3FF0000000000000lu), tmp);
^~~~~~~~~~~~~~~~~~~~~~~~~~~
glibc uses unsigned long for uint64_t on LP64 archs and unsigned long long for
uint64_t on ILP32 archs. On OpenBSD unsigned long long is used for uint64_t
on all archs.
The Operand constructors are uint8_t uint16_t uint32_t uint64_t
use UINT64_C so lu or llu suffix will be used as needed.
Fixes: df645fa369 ("aco: implement VK_KHR_shader_float_controls")
Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
Reviewed-by: Tony Wasserka <tony.wasserka@gmx.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7944>
(cherry picked from commit ebfb9e1817)
among all Android gen rules '::' was used only here to declare dependencies;
mesa development and stable branch are worth receiving the fix
Fixes the following building errors with Android 7:
obj/STATIC_LIBRARIES/libmesa_nir_intermediates/spirv/gl_spirv.P:184: *** target file
gen/STATIC_LIBRARIES/libmesa_nir_intermediates/spirv/vtn_generator_ids.h' has both : and :: entries. Stop.
Cc: "20.3" <mesa-stable@lists.freedesktop.org>
Fixes: 1070bba19e ("android: fix SPIR-V -> NIR build")
Reported-by: youling257 <youling257@gmail.com>
(cherry picked from commit 185df8ef07)
In the Chrome WebGL Aquarium stress test, 20 instances of Chrome will run
Aquarium simultaneously over 20+ hours. That causes Chrome crash.
During the stress, glBeginQueryIndexed is called frequently.
1.Each query will only use 32 bytes from query_buffer_uploader. After the offset
exceed 4096, it will alloc new buffer for query_buffer_uploader->buffer
and release the old buffer.
2.But iris_begin_query will call u_upload_alloc when the offset changed, and it
will increase the query_buffer_uploader->buffer->reference.count every time
when it called u_upload_alloc.
3.So when u_upload_release_buffer try to release the resource of
query_buffer_uploader->buffer, its reference.count is
already equal to 129. pipe_reference_described will only decrease its reference
count to 128.So it never called old_dst->screen->resource_destroy.
4.The old resouce bo will never be freeed. And chrome will called mmap every time
when it alloc new resource bo.
5. Chrome process map too many vmas in its process. Its map count exceed the
sysctl_max_map_count which is 65530 defined in kernel.
6. When iris_begin_query want to alloc new resource bo, it will meet NULL pointer
because mmap return failed. Finally chrome crashed when it access this NULL resource
bo.
The fix is decrease the reference count in iris_destroy_query.
Patch is verified by chrome webgl Aquarium test case for more than 72 hours.
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Signed-off-by: Yang Shi <yang.a.shi@intel.com>
Reviewed-by: Alex Zuo <alex.zuo@intel.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7890>
(cherry picked from commit 3aaac40b12)
There's no good reason why drivers that doesn't grok geometry,
tesselation or compute shaders needs to deal with them.
This fixes a crash on a lot of Piglit tests for Zink.
Fixes: daaf5f1d18 ("gallium: Fix leak of currently bound UBOs at CSO context destruction.")
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7971>
(cherry picked from commit 3abac03d49)
If you did:
si_pm4_set_reg(pm4, reg, val0);
si_pm4_cmd_add(pm4, val1);
si_pm4 set_reg(pm4, reg + 4, val1);
it wrote val0 to reg, val1 to reg + 4, and val2 to reg + 8.
This fixes it by clearing last_opcode in si_pm4_cmd_add, so that
si_pm4_set_reg doesn't try to combine set_reg calls across si_pm4_cmd_add.
Fixes: da78d50bc8 - radeonsi: make si_pm4_cmd_begin/end static and simplify all usages
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7721>
(cherry picked from commit 0d4f1dcd15)
Missing a copy of the pipe_sampler_state into the etna_sampler_state object
lead to the texture_use_int_filter() to always see a max_anisotropy of 0, so
the INT filter wasn't disabled when necessary. Also state emission should
never change the state objects, as this might also lead to stale information
being kept around the in the state object.
Fixes: 89a41dae77 (etnaviv: do not use int filter when
anisotropic filtering is used)
Cc: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7638>
So that code applies cleanly from master. This uses the same
.clang-format settings that master does
Equivalent to 82d2d73e03, which has other
changes.
Screen is shared among contexts, other context might be already using
vtbl while another initializes it again.
==45872== Possible data race during write of size 8 at 0x5DDAE78 by thread #549
==45872== Locks held: 1, at address 0x5D1B6F8
==45872== at 0x6D66D91: gen9_init_state (iris_state.c:7816)
==45872== by 0x6BA0A31: iris_create_context (iris_context.c:342)
==45872== by 0x621F390: st_api_create_context (st_manager.c:917)
==45872== by 0x620E6F9: dri_create_context (dri_context.c:163)
==45872== by 0x6A40DB1: driCreateContextAttribs (dri_util.c:480)
==45872== by 0x540B963: dri2_create_context (egl_dri2.c:1583)
==45872== by 0x53FB84E: eglCreateContext (eglapi.c:821)
==45872==
==45872== This conflicts with a previous read of size 8 by thread #544
==45872== Locks held: 1, at address 0x5F6E0E0
==45872== at 0x6CB779E: blorp_alloc_binding_table (iris_blorp.c:167)
==45872== by 0x6CAEF70: blorp_emit_surface_states (blorp_genX_exec.h:1540)
==45872== by 0x6CB67F9: blorp_exec (blorp_genX_exec.h:2016)
==45872== by 0x6CB7AFE: iris_blorp_exec (iris_blorp.c:307)
==45872== by 0x70F5916: try_blorp_blit (blorp_blit.c:2145)
==45872== by 0x70F5FCA: do_blorp_blit (blorp_blit.c:2273)
==45872== by 0x70F778F: blorp_copy (blorp_blit.c:2803)
==45872== by 0x6BB9EB6: iris_copy_region (iris_blit.c:725)
v2: move as genX(init_screen_state) (Lionel)
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7544>
(cherry picked from commit 460287adca)
Conflicts:
src/gallium/drivers/iris/iris_screen.c
Quoting the spec :
"When a pool is destroyed, all descriptor sets allocated from the
pool are implicitly freed and become invalid. Descriptor sets
allocated from a given pool do not need to be freed before
destroying that descriptor pool."
This implies we might leak nodes allocated in the vma object.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 0a6d2593b8 ("anv: Allocate descriptor buffers from the BO cache")
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7796>
(cherry picked from commit 5d55ca9c30)
with a sequence like this:
glClear(STENCIL)
glBeginTransformFeedback()
...
glEndTransformFeedback()
glClear(STENCIL)
The second clear sometimes may produce an unexpected result.
Calling si_flush_gfx_cs() when doing ngg -> legacy transition seems to be a
valid workaround (both for the synthetic reproducer and the real Blender bug).
Using flush flags or events (BOTTOM_OF_PIPE_TS, RESET_TO_LOWEST_VGT) didn't help.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/2941
Cc: mesa-stable
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7750>
(cherry picked from commit 0b3bd7c516)
Currently dpb_size for VP9 profile0 and profile2 is same eventhough
for profile2 dpb_size is multiplied by extra 3/2 and we are
seeing VM_L2_PROTECTION_FAULT error and ring vcn_dec timeout because
of less dpb_size for VP9_2.
This patch will correct dpb_size for VP9_2 and fixes the issue.
Signed-off-by: SureshGuttula <suresh.guttula@amd.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7480>
(cherry picked from commit 956228da3a)
Issue: Encoding parameters not updated after changing FrameRate
Root Cause:
In rvce_begin_frame, need_rate_control was enabled if the target_bitrate,
quant_i_frames, quant_p_frames, quant_b_frames or rate_ctrl_method
changes. Due to this the rate_control() was not updating the encoder
parameters with new framerate, peak_bits_per_picture_integer and
avg_target_bits_per_picture
Fix:
Added the condition where we will check if there is a change in
other parameters and enable need_rate_control. Eventually updating the
encoder parameters with new framerate and bitrate.
Signed-off-by: Krunal Patel <krunalkumarmukeshkumar.patel@amd.corp-partner.google.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7696>
(cherry picked from commit 35613c752f)
Icelake's sampler message header introduces a field in m0.3 bit 0
which controls whether the sampler state pointer should be relative
to bindless sampler state base address or dynamic state base address.
g0.3 bit 0 is part of the per-thread scratch space field. On older
hardware, we were able to copy that along because the sampler ignored
bits 4:0. Now, however, we need to mask them out.
Fixes various textureGatherOffsets piglit tests when forcing the FS
to run with 2048 bytes of per-thread scratch space (which is a
per-thread scratch space encoding of 1, meaning bit 0 will be set).
Cc: mesa-stable
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6735>
(cherry picked from commit 31290f9806)
The code did not return error when VK_IMAGE_CREATE_DISJOINT_BIT was
incompatible with the other input params.
If the Vulkan spec forbids a set of input params for vkCreateImage,
but permits them for vkGetPhysicalDeviceImageFormatProperties2,
then vkGetPhysicalDeviceImageFormatProperties2 must reject those input
params with failure.
- v2: Clearer commit message.
CC: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> (v2)
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
(cherry picked from commit 51a19c83b0)
It's supposed to be ralloced -- there's not even a shader variant destroy
function for freeing, just ralloc_free() on the ir3_shader_variant or the
parent ir3_shader when you're done!
Fixes: f97acb4bb4 ("freedreno/ir3: disk-cache support")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5810>
(cherry picked from commit 433841d9eb)
All other functions calling _eglLookupImage hold the display lock.
==16659== Possible data race during write of size 8 at 0x5D1BCF0 by thread #2668
==16659== Locks held: 1, at address 0x5D1B6F8
==16659== at 0x5405DDF: _eglLinkResource (egldisplay.c:454)
==16659== by 0x53F9189: _eglLinkImage (eglimage.h:138)
==16659== by 0x53FE2CA: _eglCreateImageCommon (eglapi.c:1740)
==16659== by 0x53FE39A: eglCreateImageKHR (eglapi.c:1751)
==16659==
==16659== This conflicts with a previous read of size 8 by thread #2664
==16659== Locks held: 1, at address 0x5308D00
==16659== at 0x5405C06: _eglCheckResource (egldisplay.c:387)
==16659== by 0x5408C92: _eglLookupImage (eglimage.h:162)
==16659== by 0x5409E96: dri2_lookup_egl_image (egl_dri2.c:688)
==16659== by 0x6210AAF: dri2_lookup_egl_image (dri_helpers.c:250)
==16659== by 0x6212843: dri_get_egl_image (dri_screen.c:470)
==16659== by 0x625F7CC: st_get_egl_image (st_cb_eglimage.c:152)
==16659== by 0x625FE7D: st_egl_image_target_texture_2d (st_cb_eglimage.c:354)
==16659== by 0x6501C05: egl_image_target_texture (teximage.c:3446)
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7544>
(cherry picked from commit 959c2d1edb)
OpenGL 3.0 spec, section 4.2.3 "Clearing the Buffers":
depth and stencil are the values to clear the depth and stencil
buffers to, respectively. Clamping and type conversion for
fixed-point depth buffers are performed in the same fashion as for
ClearDepth.
Enables iris to pass the clearbuffer-depth-stencil piglit test.
Cc: mesa-stable
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7410>
(cherry picked from commit 2e713313a2)
OpenGL 3.0 spec, section 4.2.3 "Clearing the Buffers":
If buffer is DEPTH, drawbuffer must be zero, and value points to the
single depth value to clear the depth buffer to. Clamping and type
conversion for fixed-point depth buffers are performed in the same
fashion as for ClearDepth.
Enables iris to pass the clearbuffer-depth piglit test.
v2. Add spec citation. (Eric Anholt)
v3. Don't clamp floating point formats. (Eric Anholt)
Cc: mesa-stable
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7410>
(cherry picked from commit 1bf539b3a2)
This implementation was broken and should have just been the same as the
hash_table_clear() one, which I copied over here. It was setting all
formerly-present entries to deleted, yet also setting deleted_entries to
0. This meant that all new searches or additions after clearing would
have to reprobe the whole table until a rehash happened, and that rehash
would be delayed because we violated the deleted_entries invariant.
No statistically significant performance difference on softpipe
KHR-GL33.texture_swizzle.functional runtime (n=18)
Fixes: 5c075b0855 ("util/set: add a set_clear function")
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7244>
(cherry picked from commit 2afdd94f86)
In bison's commit 72c9fa4510eb (skeletons: use "end of file" instead of
"$end") in bison-3.6, '$end' was changed to 'end of file' in error
messages. Since our glcpp test cases contain the expected output text,
they rely on the particular messages printed by bison. The test case
084-unbalanced-parentheses fails when Mesa is built with bison-3.6 due
to this change.
To allow the test to pass on all supported versions of bison, we:
1. Change '$end' -> 'end of file' in the .expected file, and
2. Normalize the error generated by the test case with the same
replacement
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3181
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7659>
(cherry picked from commit df29d0a111)
We forgot to initialize the sample_count member here, leading to it
being undefined. This causes problems on MSVC when compiling in
debug-mode, where we get a run-time error for using an undefined
variable.
To avoid similar problems in the future if more fields are added,
let's initialize the whole struct to zero to start with. This also
allows us to remove a no-longer-needed zero-initialization.
Fixes: cf170616da ("gallium: Add a util_blitter path for using a custom VS and FS.")
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7503>
(cherry picked from commit 441feda0bb)
In split_var_list_structs where we initalize the splitting, we already
use get_complex_used_vars to avoid splitting any variables that have a
complex use. However, we weren't actually handling the complex uses
properly in the case where we can't actually find the variable.
Fixes: f1cb3348f1 "nir/split_vars: Properly bail in the presence of ..."
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6332>
(cherry picked from commit 5664713d7b)
evergreen_emit_atomic_buffer_setup_count is only called if chip >= EVERGREEN
otherwise atomic_used_mask is left uninitialized when unconditionally used by
r600_need_cs_space so it might want more space than needed
fix this by always initializing atomic_used_mask
Fixes: 32529e6084 ("r600/eg: rework atomic counter emission with flushes")
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7417>
(cherry picked from commit 7ae81d65a4)
Like with other getters, invalid enum is dealt in find_value by setting
error to GL_INVALID_ENUM and returning INVALID_TYPE which makes
get_value_size return 0.
Fixes false 'implementation errors' seen with Piglit test:
ext_external_objects-memory-object-api-errors
"Mesa 20.3.0-devel implementation error: invalid value type in GetUnsignedBytei_vEXT()
Please report at https://gitlab.freedesktop.org/mesa/mesa/-/issues"
v2: add assert to get_value_size() (Lionel)
Fixes: e064d66020 ("mesa: implement glGetUnsignedByte{v|i_v}")
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Eleni Maria Stea <estea@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7403>
(cherry picked from commit 29fc115d58)
Something may go wrong during import which leaves pointer to null and
when ctx and it's shared state gets destroyed we will attempt to call
memobj_destroy. Instead of forcing every driver to handle it, add check
here.
Fixes crashes with Piglit test:
ext_external_objects_fd-memory-object-api-errors
Fixes: 99cf910834 ("mesa/st: Actually free the driver part of memory objects on destruction.")
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Eleni Maria Stea <estea@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7403>
(cherry picked from commit e02e1ccbee)
The CTS now tests to make sure these are not allowed. However, previously
drivers (including Mesa) would allow them to exist and just issue a
warning. Some old applications such as Champions of Regnum seem to
depend on this.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/422
Fixes: 43047384c3 ("glsl/glcpp: Promote "extra token at end of directive" from warning to error")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7361>
(cherry picked from commit a09717c4de)
Conflicts:
src/gallium/auxiliary/pipe-loader/driinfo_gallium.h
src/mesa/drivers/dri/i965/intel_screen.c
Issue: Encoding parameters not updated after changing FrameRate
Root Cause:
In radeon_enc_begin_frame, there is a parameter need_rate_control
which was enabled only if the bitrate is changed. Due to this the
radeon_enc_rc_layer_init was not updating the encoder parameters with new
framerate, peak_bits_per_picture_integer and avg_target_bits_per_picture
Fix:
Added the condition where we will check if there is a change in
other parameters and enable rate control. Eventually updating the
encoder parameters with new framerate and bitrate.
Signed-off-by: Krunal Patel <krunalkumarmukeshkumar.patel@amd.corp-partner.google.com>
Reviewed-by: Boyuan Zhang boyuan.zhang@amd.com
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7363>
(cherry picked from commit 4143572f93)
Issue: While running the tast for odd resolutions there are green lines
observed in the dumped image. The resolution is 321x241, the extra 1 pixel
data is missing in the image. The reason for this is in the post
processing when we adjust the size of height and width we are
dividing it by 2.
Fix: To resolve this issue we first need to align it to 2 and then divide
by 2 to get the required values. Once we do this we will have proper data
in the dumped image and missing pixel data will be available.
Signed-off-by: Krunal Patel <krunalkumarmukeshkumar.patel@amd.corp-partner.google.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
(cherry picked from commit d78e7b7aee)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7282>
Before this change, internalFormat was defaulted to GL_RGBA (
unsized internal format). Therefore, subsequent glTexSubImage2D
call with type != GL_UNSIGNED_BYTE, GL_UNSIGNED_SHORT_4_4_4_4 or
GL_UNSIGNED_SHORT_5_5_5_1 would give GL_INVALID_OPERATION.
This fixes
android.graphics.cts.BitmapColorSpaceTest#test16bitHardware
android.graphics.cts.ImageDecoderTest#testDecodeBitmap*
android.graphics.cts.BitmapTest#testNdkFormatsHardware
in CtsGraphicsTestCases
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6382>
(cherry picked from commit 5e4d69ec78)
This matches what ir3.c does in the mergedregs case: just count max full
reg used. This flag is unset so far, but will be soon and keeps our
output comparable between blob and freedreno.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6323>
(cherry picked from commit ce335dcb19)
The current blorp API only allows source layers for 3D images to be
integers. That is causing problems with the Vulkan API where we need
to be able to use a 3D layer that could be in between 2 layers.
This change allows a floating point value to be passed for blits and
internally sets up the input parameters to pass floating point values
to kernels.
v2: Use tex op to determinate what types are the coordinates (Jason)
Drop setting params->z (Lionel)
v3: Fix nir_texop_txf_ms_mcs op not considered as having integer coords (Lionel)
v4: Fix incorrect test on nir_texop_txf_ms_mcs (Ivan)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3458
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6909>
(cherry picked from commit 87934f02f9)
There is a race where the BO refcount might drop to 0 before the
dmabuf/name import paths had a chance to grab a reference for a
BO found in the handle_table. The easiest solution is to keep the
refcount stable as long as the table_lock is held.
While a more involved scheme of rechecking the refcount before
actually destroying the BO might also work, the bo_del path isn't
called very often, so micro-optimizing a single mutex_lock seems
to be over-engineered, so go for the easy solution.
Cc: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7367>
(cherry picked from commit 866bb22d6b)
Partial rollback as GFX9 really requires height = 1 to work.
The two substantial parts of the fix remaining:
1) Deal with views with multiple levels.
2) Limit the expansion to the base mip pitch/height. On GFX9 this
is exactly equal to the surf_pitch that was used before. I've
done some investigation to make sure that on GFX10 this always
results in the right physical layout.
Remaining stupid question is how the actual extents for bounds
checking never end up too low when the size gets clamped, but
this change and the previous change don't change that ...
Fixes: 1fb3e1fb70 "radv: Fix mipmap extent adjustment on GFX9+."
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7245>
(cherry picked from commit 29999e6b9d)
With swap interval 0, i.e. sync-to-vblank disabled.
This can be necessary for unthrottled drawing with Xwayland:
1) One buffer can be scanned out
2) One buffer can be pending in the kernel for a page flip
3) One buffer can be pending in the Wayland compositor
Therefore, with 3 buffers, the frame-rate could be capped much lower
than the throughput the GPU is capable of, in the worst case at the
Wayland compositor refresh rate.
(The native Wayland EGL backend always uses up to 4 buffers)
Leave the maximum number of buffers at 3 for swap interval != 0, it's
sufficient in that case to always be able to queue one frame ahead of
time.
https://gitlab.gnome.org/GNOME/mutter/-/issues/1455https://gitlab.gnome.org/GNOME/mutter/-/issues/1462
Cc: mesa-stable
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7033>
(cherry picked from commit 31e9de9c8a)
We'd previously take the copy path. If we were actually flipping (in
which case skipped frames are more likely to occur), we'd ping-pong
between a smaller and larger number of back buffers, and frame-rate
could vary / take a dip due to the buffer management overhead.
While I'm not sure this is actually possible to hit at this point, it
definitely will be with the next change.
Cc: mesa-stable
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7033>
(cherry picked from commit 16a7cc4d44)
Previously, we would always allocate 3 buffers for page flipping. But 2
buffers can suffice for clients which always wait for buffer swaps to
complete before starting a new frame.
Therefore, keep track of the maximum number of buffers separately from
the current number, and only bump the latter if both current buffers are
busy.
Cc: mesa-stable
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7033>
(cherry picked from commit 60585fc4e3)
pthread_cond_broadcast man page says this:
"The pthread_cond_broadcast() or pthread_cond_signal() functions may
be called by a thread whether or not it currently owns the mutex that
threads calling pthread_cond_wait() or pthread_cond_timedwait() have
associated with the condition variable during their waits; however,
if predictable scheduling behavior is required, then that mutex shall
be locked by the thread calling pthread_cond_broadcast() or
pthread_cond_signal()."
Found by reading the code.
Compile tested only.
Fixes: da997ebec9 ("vulkan: Add KHR_display extension using DRM [v10]")
Signed-off-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7197>
(cherry picked from commit 4408131142)
Altough the driver isn't expected to receive nir_var_uniform types
from GLSL this happens currently for one of the internal driver shaders.
At vc4_get_yuv_fs at vc4_blit.c there is a "stride" nir_var_uniform
variable that needs to be lowered so the shader can be compiled.
This regression was affecting several piglit tests under
spec/ext_image_dma_buf_import and at least MythTV application.
Fixes: 96d99f2ecc ("vc4: Only call nir_lower_io on shader_in/out")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3536
Reviewed-by: Eric Anholt <eric@anholt.net>
Tested-by: Piotr Oniszczuk <piotr.oniszczuk@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7160>
(cherry picked from commit d91cb31a2a)
Before 8e1b75b330 ("nir/algebraic: optimize iand/ior of (n)eq zero") this
optimization didn't need the use of umax/umin. VC4 HW supports only signed
integer max/min operations.
lower_umin and lower_umax are added to allow enabling previous optimizations
behaviour for this cases.
Fixes: 8e1b75b330 ("nir/algebraic: optimize iand/ior of (n)eq zero")
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7083>
(cherry picked from commit e7127b3468)
With arrays we really have to use the correct size for the base
mipmap to get the right array pitch. In particular, using
surf_pitch results in pitch that is bigger than the base mipmap
and hence results in wrong pitches computed by the HW.
It seems that on GFX9 this has mostly been hidden by the epitch
provided in the descriptor but this is not something we do on
GFX10 anymore.
Now this has some draw-backs:
1. normalized coordinates don't work
2. Bounds checking uses slightly bigger bounds.
2 mostly is not an issue as we still ensure that they're within
the texture memory and not overlapping other layers/mips, but
we can't properly ignore writes.
1 is kinda dead in the water ... On the other hand I'd argue that
using normalized coords & a filter for sampling a block view of
a compressed format is extraordinarily useless.
The old method we employed already had these drawbacks for everything
except the base miplevel of the imageview.
AFAICT this is the same tradeoff AMDVLK makes and no CTS test hits
this. (once it does I think the HW is dead in the water ... Only
workaround I can think of is shader processing which is hard because
we don't know texture formats at compile time.)
I also removed the extra calculations when the image has only 1 mip
level because they ended up being a no-op in that case.
CC: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/2292
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/2266
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/2483
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/2906
Gitlab: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3607
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7090>
(cherry picked from commit 1fb3e1fb70)
Scratch stores are being lowered to the instructions with side-effects,
however they should be enabled in fs helper invocations, since they
are produced from operations which don't imply side-effects.
To fix this - we move the decision of whether the sample mask predication
is enable to the point where logical brw instructions are created.
GLSL example of the issue:
int tmp[1024];
...
do {
// changes to tmp
} while (some_condition(tmp))
If `tmp` is lowered to scrach memory, `some_condition` would be
undefined if scratch write is predicated on sample mask, making
possible for the while loop to become infinite and hang the GPU.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3256
Fixes: 53bfcdeecf
Signed-off-by: Danylo Piliaiev <danylo.piliaiev@globallogic.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6056>
(cherry picked from commit 77486db867)
Fixes rendering corruption in the shadowmappingcascade Sascha Willems
Vulkan demo. To see the corruption, I adjusted the demo options as
follows:
1. Enable "Display depth map"
2. Set "Split lambda" to 0.100
3. Make "Cascade" non-zero.
Fixes: 80ffbe915f ("anv: Add support for HiZ+CCS")
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7046>
(cherry picked from commit cce6fc3b5c)
In 53bfcdeecf, we added load/store_scratch instructions which deviate
a little bit from most memory load/store instructions in that we can't
use the normal untyped read/write instructions which can read and write
up to a vec4 at a time. Instead, we have to use the DWORD scattered
read/write instructions which are scalar. To handle this, we added code
to brw_nir_lower_mem_access_bit_sizes to cause them to be scalarized.
However, one case was missing: the load-as-larger-vector case. In this
case, we take small bit-sized constant-offset loads replace it with a
32-bit load and shuffle the result around as needed.
For scratch, this case is much trickier to get right because it often
emits vec2 or wider which we would then have to lower again. We did
this for other load and store ops because, for lower bit-sizes we have
to scalarize thanks to the byte scattered read/write instructions being
scalar. However, for scratch we're not losing as much because we can't
vectorize 32-bit loads and stores either. It's easier to just disallow
it whenever we have to scalarize.
Fixes: 53bfcdeecf "intel/fs: Implement the new load/store_scratch..."
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6872>
(cherry picked from commit fd04f858b0)
When support for multi-slice fast-clears was introduced for color
surfaces, an existing optimization for skipping fast-clears was not
updated (this optimization assumed single-slice fast-clears). As a
result, the driver began to skip multi-layer fast-clears if just the
first slice was in the CLEAR state (ignoring the state of the others).
A Civilization VI trace was the only workload I found to make use of
this optimization and it did so for 2D, non-array textures. Therefore,
this fix simply checks that the depth of the clear box is 1. It also
moves the single-slice aux-state query closer to the optimization to
clarify the need for the depth check.
Enables iris to pass a case of the fcc-write-after-clear piglit test,
[fast-clear tracking across layers 0 -> 1 -> (0,1)].
Fixes: 393f659ed8 ("iris: Enable fast clears on other miplevels and layers than 0.")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6973>
(cherry picked from commit 3f3a5f3489)
When I copied and pasted the code from MOV_INDIRECT for handling the
dependency controls, I missed a subtle difference between MOV_INDIRECT
and SHUFFLE. Specifically, MOV_INDIRECT gets lowered to a narrow
instruction on Gen7 by the SIMD width lowering whereas SHUFFLE has to
split it in the generator. Therefore, the check safety check for
whether or not we can use dependency control has to be based on the
lowered width rather than the width of the original instruction.
Fixes: a8ac61b0ee "intel/fs: NoMask initialize the address..."
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3593
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6989>
(cherry picked from commit 8427e56067)
The volatile pattern gives me flaky results for 32-bit builds on
ChromeOS Android. This is because on 32-bit the volatile 64-bit
loads gets split into 2 32-bit loads each.
So if we read the lower dword first and then the upper dword, it
can happen that the upper dword is already changed but the lower
dword isn't yet. In particular for occlusion queries this gives
false readings, as the upper dword commonly only constains the
ready bit.
With the GCC atomic intrinsics we get a call to __atomic_load_8
in libatomic.so which does the right thing.
An alternative fix would be to explicitly split the 32-bit loads
in the right order and do a bunch of retries if things change, though
that gets messy quickly and for 32-bit builds only doesn't feel worth
it that much.
CC: mesa-stable
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6933>
(cherry picked from commit 7568c97df1)
The linker was adding all state vars as uniforms, doubling the storage size
for shaders using only builtin uniforms, which increased CPU overhead for
constant buffer uploads.
When this code was originally ported from the GLSL IR linker we forgot
to exclude builtins because the check was not done in the
add_uniform_to_shader class but rather a check was done when passing
variables to this class for processing.
Fixes: 664e4a610d ("glsl/nir: Fill in the Parameters in NIR linker")
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Tested-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6958>
(cherry picked from commit 038fcbcaed)
Workaround # 22011374674
Applied to i965, iris and anv drivers
No performance impact is observed with WA.
Cc: mesa-stable
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
(cherry picked from commit 545d852a7a)
After disable SDMA on Arcturus(gfx9), dead lock with aux_context_lock is
detected since si_screen_clear_buffer is called recursively before
release lock.
The call trace is:
si_clear_render_target->si_compute_clear_render_target->
si_launch_grid_internal->si_launch_grid->si_emit_cache_flush->
si_prim_discard_signal_next_compute_ib_start->u_suballocator_alloc->
si_resource_create->si_buffer_create->si_alloc_resource->
si_screen_clear_buffer->simple_mtx_lock->
si_sdma_clear_buffer->si_pipe_clear_buffer->
si_clear_buffer->si_compute_do_clear_or_copy->
si_launch_grid_internal->si_launch_grid->si_emit_cache_flush->
si_prim_discard_signal_next_compute_ib_start->u_suballocator_alloc->
si_resource_create->si_buffer_create->si_alloc_resource->
si_screen_clear_buffer->simple_mtx_lock
Fixes: 07a49bf597 "radeonsi: disable SDMA on gfx9"
Signed-off-by: James Zhu <James.Zhu@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6941>
(cherry picked from commit 5e8791a0bf)
In the case where end was a instruction-based cursor, we would mix up
our blocks and end up with block_begin pointing after the second split.
This causes a segfault as the cf_node list walk at the end of the
function never terminates properly. There's also a possibility of
mix-up if begin is an instruction-based cursor which was found by
inspection.
Fixes: fc7f2d2364 "nir/cf: add new control modification API's"
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
Acked-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6866>
(cherry picked from commit 7dbb1f7462)
vl_mpeg12_decoder needs to override the chroma_format value to get the
correct size calculated (chroma_format is used by vl_video_buffer_adjust_size).
I'm not sure why it's needed, but this is needed to get correct mpeg decode.
Fixes: 24f2b0a856 ("gallium/video: remove pipe_video_buffer.chroma_format")
Acked-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6817>
(cherry picked from commit 2584d48b2c)
Fix defect reported by Coverity Scan.
Dereference before null check (REVERSE_INULL)
check_after_deref: Null-checking image suggests that it may be
null, but it has already been dereferenced on all paths leading to
the check.
Fixes: ad609bf55a ("frontend/dri: Implement mapping individual planes.")
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6807>
(cherry picked from commit 03e7b75c22)
Without this, we end up throwing errors on code along these lines when
rendering using single-buffering:
GLint att;
glGetIntegerv(GL_READ_BUFFER, &att);
glGetFramebufferAttachmentParameteriv(GL_READ_FRAMEBUFFER, att, ...);
This is because we internally translate GL_BACK (which is what
glGetIntegerv returned) to GL_FRONT, which we don't handle in the
Desktop GL case. So let's start handling it.
This fixes the GLTF-GL33.gtf21.GL2FixedTests.buffer_color.blend_color
test for me.
Fixes: e6ca6e587e ("mesa: Handle pbuffers in desktop GL framebuffer attachment queries")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6815>
(cherry picked from commit 9e13a16c97)
Section 5.11 (Out-of-Bounds Accesses) of the GLSL 4.60 spec says:
"In the subsections described above for array, vector, matrix and
structure accesses, any out-of-bounds access produced undefined
behavior.... Out-of-bounds reads return undefined values, which
include values from other variables of the active program or zero."
Robustness extensions suggest to return zero on out-of-bounds
accesses, however it's not applicable to the arrays of samplers,
so just clamp the index.
Otherwise instr->sampler_index or instr->texture_index would be out
of bounds, and they are used as an index to arrays of driver state.
E.g. this fixes such dereference:
if (options->lower_tex_packing[tex->sampler_index] !=
in nir_lower_tex.c
CC: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Danylo Piliaiev <danylo.piliaiev@globallogic.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6428>
(cherry picked from commit f2b17dec12)
Out-of-bounds writes could be eliminated per spec:
Section 5.11 (Out-of-Bounds Accesses) of the GLSL 4.60 spec says:
"In the subsections described above for array, vector, matrix and
structure accesses, any out-of-bounds access produced undefined
behavior.... Out-of-bounds writes may be discarded or overwrite
other variables of the active program."
Fixes: 1235850522
Signed-off-by: Danylo Piliaiev <danylo.piliaiev@globallogic.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6428>
(cherry picked from commit 0ba82f78a5)
Out-of-bounds writes could be eliminated per spec:
Section 5.11 (Out-of-Bounds Accesses) of the GLSL 4.60 spec says:
"In the subsections described above for array, vector, matrix and
structure accesses, any out-of-bounds access produced undefined
behavior....
Out-of-bounds writes may be discarded or overwrite
other variables of the active program.
Out-of-bounds reads return undefined values, which
include values from other variables of the active program or zero."
GL_KHR_robustness and GL_ARB_robustness encourage us to return zero
for reads.
Otherwise get_io_offset would return out-of-bound offset which may
result in out-of-bound loading/storing of inputs/outputs,
that could cause issues in drivers down the line.
E.g. this fixes such dereference:
int vue_slot = vue_map->varying_to_slot[intrin->const_index[0]];
in brw_nir.c
CC: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Danylo Piliaiev <danylo.piliaiev@globallogic.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6428>
(cherry picked from commit 66669eb529)
It's not really unordered in the sense that it can still stall on
ordered things and we don't need a SYNC_NOP for that because it is a
SYNC_NOP. However, it also doesn't count when computing instruction
distances.
Fixes: 18e72ee210 "intel/fs: Add FS_OPCODE_SCHEDULING_FENCE"
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6781>
(cherry picked from commit f63ffc18e7)
I didn't backport this correctly, and then accidentally pushed to the
stable (not staging branch) so now we have to carry a fixup to avoid
force pushing on the stable branch.
As shown in the valid SPIR-V below, if one switch case statement
directly jumps to the merge block, it has no branches at all and
we have to reset the fall variable. Otherwise, it creates an
unintentional fallthrough.
OpSelectionMerge %97 None
OpSwitch %96 %97 1 %99 2 %100
%100 = OpLabel
%102 = OpAccessChain %_ptr_StorageBuffer_v4float %86 %uint_0 %uint_37
%103 = OpLoad %v4float %102
%104 = OpBitcast %v4uint %103
%105 = OpCompositeExtract %uint %104 0
%106 = OpShiftLeftLogical %uint %105 %uint_1
OpBranch %97
%99 = OpLabel
OpBranch %97
%97 = OpLabel
%107 = OpPhi %uint %uint_4 %75 %uint_5 %99 %106 %100
This fixes serious corruption in Horizon Zero Dawn.
v2: Changed the code to skip the entire if-block instead of resetting
the fallthrough variable.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3460
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Signed-off-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6590>
(cherry picked from commit 57fba85da4)
The raw query is meant to be used with MDAPI [1]. When using this
metric without this library, we usually selected the TestOa metric to
provide some default sensible values (instead of undefined).
Historically this TestOa metric lived in the kernel at ID=1. We
removed all metrics from the kernel in kernel commit 9aba9c188da136
("drm/i915/perf: remove generated code").
This fixes the Mesa code to use a valid metric set ID (1 could work
some of the time, but not guaranteed).
[1] : https://github.com/intel/metrics-discovery
v2: Store fallback metric at init time
v3: Drop TestOa lookout
v4: Skip the existing queries (Marcin)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
CC: <mesa-stable@lists.freedesktop.org>
Tested-by: Marcin Ślusarz <marcin.slusarz@intel.com> (v1)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6438>
(cherry picked from commit ec1fa1d51f)
Several optimization paths, including constant folding, can lead to
indexing vector with an out of bounds index.
Out-of-bounds writes could be eliminated per spec:
Section 5.11 (Out-of-Bounds Accesses) of the GLSL 4.60 spec says:
"In the subsections described above for array, vector, matrix and
structure accesses, any out-of-bounds access produced undefined
behavior.... Out-of-bounds writes may be discarded or overwrite
other variables of the active program."
Fixes piglit tests:
spec@glsl-1.20@execution@vector-out-of-bounds-access@fs-vec4-out-of-bounds-1
spec@glsl-1.20@execution@vector-out-of-bounds-access@fs-vec4-out-of-bounds-6
CC: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Danylo Piliaiev <danylo.piliaiev@globallogic.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6363>
(cherry picked from commit 5922d57a18)
syncobj wait takes int64_t timeout and won't clamp it
in kernel code, so we have to pass in INT64_MAX instead
of OS_TIMEOUT_INFINITE which is UINT64_MAX. Otherwise
syncobj wait with OS_TIMEOUT_INFINITE case just return
fail.
Fixes: c638301b42 "radeonsi: fix syncobj wait timeout"
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6676>
(cherry picked from commit ef980ac0c1)
Fix defects reported by Coverity Scan.
Resource leak (RESOURCE_LEAK)
leaked_handle: Handle variable fd going out of scope leaks the handle.
Argument cannot be negative (NEGATIVE_RETURNS)
negative_returns: fd is passed to a parameter that cannot be negative.
Fixes: 1ea4ef0d3b ("freedreno: slurp in decode tools")
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6642>
(cherry picked from commit 587969154f)
SPIR-V's OpKill is a control-flow instruction but NIR's discard is not.
Therefore, it can be valid SPIR-V to have
if (...) {
foo = /* something */
} else {
discard;
}
use(foo);
without any phi between the definition of foo and its use. This is not
true in NIR, however, because NIR's discard isn't considered
control-flow. Arguably, this is a NIR bug but making discard control-
flow is a very deep change that can have serious ans subtle
side-effects. The easier thing to do is just fix up the SSA in case we
have an OpKill which might have gotten us into the above case.
Fixes dEQP-VK.graphicsfuzz.vectors-and-discard-in-function with the new
NIR dominance validation pass enabled.
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5288>
(cherry picked from commit 7cedc4128a)
The result of 0xf << 28 is a signed integer and hence overflows into the sign
bit. In practice compilers did the right thing here, since the intent of the
code was unsigned arithmetic anyway.
Cc: mesa-stable
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6568>
(cherry picked from commit 93c8777ace)
The result of 0xf << 28 is a signed integer and hence overflows into the sign
bit. In practice compilers did the right thing here, since the intent of the
code was unsigned arithmetic anyway.
These conditions were observed in:
* dEQP-VK.pipeline.image.suballocation.sampling_type.combined.view_type.1d.format.r4g4b4a4_unorm_pack16.count_8.size.512x1
* dEQP-VK.binding_model.descriptorset_random.sets32.noarray.ubolimitlow.sbolimitlow.sampledimglow.outimgonly.noiub.nouab.frag.ialimithigh.0
Cc: mesa-stable
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6568>
(cherry picked from commit f18fc34c4d)
With the kernel timeline sysncobj changes, the kernel submits do
not necessarily happen in global vkQueueSubmit order. Which should
be fine, we added the appropriate waits for that. (See
DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT in the winsys)
However, all kernel submissions take a lock on the bo_list mutex,
and since we do the wait in the winsys, we wait while having the
bo_list mutex held. This means that as soon as a wait and a signal
submission are out of order we have a deadlock on the bo_list mutex
and the wait.
Solution is to use a shared reader lock during the kernel submission,
as we only need read access for the submission.
Fixes: 6bc5ce7a91 "radv: Add timeline syncobj for timeline semaphores."
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3446
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6478>
(cherry picked from commit 61b714a42e)
If decrement == 0 then:
- it isn't safe to access the submission
- even if it is, checking that the result of the atomic_sub is 0
doesn't given an unique owner anymore.
So skip it. The submission always starts out with refcount >= 1,
so first one to decrement to 0 still get dibs on executing it.
Fixes: 4aa75bb3bd "radv: Add wait-before-submit support for timelines."
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6478>
(cherry picked from commit 6b75262941)
We can get duplicate declarations for an index (for example dvec3 + float
packed into 2 vec4s, the second one won't pack into the first's array
decl), and we'd end up stepping by the wrong amount in GS vtx/prim emit.
Fixes vs-gs-fs-double, sso-vs-gs-fs-array-interleave piglit tests.
Fixes: 49155c3264 ("draw/tgsi: fix geometry shader input/output swizzling")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6567>
(cherry picked from commit 329dee1455)
Only advertise VK_TIME_DOMAIN_CLOCK_MONOTONIC_RAW_EXT if CLOCK_MONOTONIC_RAW
is defined. Fixes the build on OpenBSD which has CLOCK_MONOTONIC but not
CLOCK_MONOTONIC_RAW.
Fixes: 67a2c1493c ("vulkan: Add VK_EXT_calibrated_timestamps extension (radv and anv) [v5]")
Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6517>
(cherry picked from commit 4500e6e460)
The immediate case is pretty uncommon to see but it can happen, in
theory. BROADCAST is typically used to uniformize values and those are
usually 32-bit. However, it does come up in some subgroup ops.
Fixes: 49c21802cb "intel/compiler: Split has_64bit_types into float/int"
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6211>
(cherry picked from commit cccb497d3c)
In FIFO presentation mode we block either on our present-queue or on Present
events after an image was transmitted.
In case we receive completion events without idle events at some point we
exhaust our acquire-queue and can not block anymore on present-queue.
Ensure that the consumer has at least one image to acquire before blocking
again on present-queue. Otherwise wait for one from the X server.
CC: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3344
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Simon Ser <contact@emersion.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6513>
(cherry picked from commit ec5e918ef4)
Mesa builds with -std=c99 but uses timespec_get() a c11 function.
Build with _ISOC11_SOURCE for c11 visibility when -std is specified.
On linux c11 visibility comes from defining _GNU_SOURCE.
Fixes: e3a8013de8 ("util/u_queue: add util_queue_fence_wait_timeout")
Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5630>
(cherry picked from commit f9a7e6e854)
Since cbee1bfb34 endian.h is unconditionally
used if available.
glibc has byte order defines with two leading underscores. OpenBSD
has private defines with a single leading underscore in machine/endian.h
and public defines in endian.h with no underscore.
The code under the endian.h block did not check if symbols were
defined before equating them so '#if __BYTE_ORDER == __LITTLE_ENDIAN'
would turn into '#if 0 == 0' which is always true.
Fixes: cbee1bfb34 ("meson/configure: detect endian.h instead of trying to guess when it's available")
Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5630>
(cherry picked from commit 7eab6845e9)
I have no idea how this pass ever worked. I guess it worked ok on the
one or two piglit tests but the whole thing seemed very fragile. It
makes a number of undocumented and unasserted assumptions and they
aren't always valid. This rewrite makes a number of changes:
1. It now properly handles the case where the gl_SampleMask write comes
before the gl_FragColor or gl_FragData[0] write.
2. It should early-exit faster because it now looks at bits in
shader_info::outputs_written instead of looking for variables.
3. Instead of the fragile variable lookup where we try to look the
variable up by both location and driver_location and match, we just
use the driver_location calculations used by brw_fs_nir.
4. It asserts that the index parameter to store_output is a constant
instead of silently failing if it isn't.
5. We now actually assert the implicit assumption that the two writes
are in the same block. We go even further and assert that they are
in the last block in the shader.
6. In the case where 3 or fewer components of the output are written,
we explicitly choose to leave the sample mask alone.
Fixes: 7ecfbd4f6d "nir: Add alpha_to_coverage lowering pass"
Closes: #3166
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6233>
(cherry picked from commit b6fdb1405e)
When calling glWaitSync (fence_server_sync), we added dependencies
in all batches (render and compute) on existing work. Even if
applications don't use compute at all, they theoretically could,
so we record that the compute batch depends on the render batch.
But if the application truly doesn't use compute, or rarely uses
it, we ended up recording dependencies on _all_ previous render
batches, racking up a massive list of syncobjs. Not only is this
pointless, it also meant that we never allowed the kernel to free
the underlying i915_request objects.
There are a number of solutions to this problem, but for now, we
take a simple one: when recording a new syncobj dependency, we
walk the list and see if any of them have already passed. If so,
that dependency has been fulfilled. We no longer need to track it,
and can simply drop it from the list, unreferencing the syncobj.
Android's SurfaceFlinger in particular was hitting this issue,
as it uses glWaitSync, doesn't typically use compute shaders,
and runs for long durations.
Thanks to Yang A Shi <yang.a.shi@intel.com> and
Kefei Yao <kefei.yao@intel.com> for their excellent work in
tracking down this issue!
Fixes: f459c56be6 ("iris: Add fence support using drm_syncobj")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Tested-by: Tapani Pälli <tapani.palli@intel.com>
Tested-by: Yang A Shi <yang.a.shi@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6463>
(cherry picked from commit 6b1a56b908)
Swapping the order of the loops makes the logic much easier to follow:
for each point in our fence, if it hasn't gone by, make future work in
all batches depend on it. Both loops are necessary, and now it's
clearer why.
(This doesn't actually fix a bug but needs to be cherry-picked for
the next patch to apply, which does fix a bug.)
Fixes: f459c56be6 ("iris: Add fence support using drm_syncobj")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Tested-by: Tapani Pälli <tapani.palli@intel.com>
Tested-by: Yang A Shi <yang.a.shi@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6463>
(cherry picked from commit e98c7a6634)
PTB assumes that base instance to be 0 at start of tile, but hw would
not do that, we need to set it. It is worth to note that the opcode
name is somewhat confusing as what it really sets is the base
instance. We could rename the opcode, but then the name would be
different to the original Broadcom name, so confusing in any case.
This fixes several dEQP-GLES3 and dEQP-GLES31 tests that passes
individually, but started to fail depending on other tests running
before using base instance different to zero.
This is the backport of a Vulkan patch that fixed some Vulkan CTS
tests that start to fails after some other tests used an instance id.
CC: 20.2 20.1 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6447>
(cherry picked from commit 05a0349949)
If you have a sequence where there is a single buffer associated with
the current render target, and then you end up shadowing it on the 3d
pipe (u_blitter), because of how we swap the new shadow and rsc before
the back-blit, you could end up confusing things into thinking that
the blitters framebuffer state is the same as the current framebuffer
state.
Re-organizing the sequence to swap after the blit is complicated when
also having to deal with CPU memcpy blit path, and the batch/rsc
accounting. So instead just detect this case and flush if we need to.
Fixes:
dEQP-GLES31.functional.stencil_texturing.render.depth24_stencil8_clear
dEQP-GLES31.functional.stencil_texturing.render.depth24_stencil8_draw
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6434>
(cherry picked from commit 1fa43a4a8e)
Section 5.11 (Out-of-Bounds Accesses) of the GLSL 4.60 spec says:
"In the subsections described above for array, vector, matrix and
structure accesses, any out-of-bounds access produced undefined
behavior.... Out-of-bounds writes may be discarded or overwrite
other variables of the active program."
Fixes crashes when dereferencing gl_ClipDistance and gl_TessLevel*, e.g:
int index = -1;
gl_ClipDistance[index] = -1;
When LowerCombinedClipCullDistance is true.
CC: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Danylo Piliaiev <danylo.piliaiev@globallogic.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6363>
(cherry picked from commit e802bff69e)
On glmark2-es2 -bterrain:
594.05KB leaked over 9282 calls from:
panfrost_batch_update_bo_access
at ../src/gallium/drivers/panfrost/pan_job.c:462
in /home/alyssa/rockchip_dri.so
panfrost_batch_add_bo
at ../src/gallium/drivers/panfrost/pan_job.c:560
panfrost_batch_add_bo
at ../src/gallium/drivers/panfrost/pan_job.c:519
in /home/alyssa/rockchip_dri.so
panfrost_batch_add_resource_bos
at ../src/gallium/drivers/panfrost/pan_job.c:569
panfrost_batch_add_fbo_bos
at ../src/gallium/drivers/panfrost/pan_job.c:588
in /home/alyssa/rockchip_dri.so
panfrost_create_batch
at ../src/gallium/drivers/panfrost/pan_job.c:126
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Cc: mesa-stable
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6373>
(cherry picked from commit 1cb47f8eea)
8.74KB leaked over 52 calls from:
0xffffbb5b9fc3
in ??
_mesa_hash_table_init
at ../src/util/hash_table.c:163
in /home/alyssa/rockchip_dri.so
_mesa_hash_table_create
at ../src/util/hash_table.c:186
_mesa_hash_table_u64_create
at ../src/util/hash_table.c:701
in /home/alyssa/rockchip_dri.so
panfrost_nir_assign_sysvals
at ../src/panfrost/util/pan_sysval.c:130
in /home/alyssa/rockchip_dri.so
midgard_compile_shader_nir
at ../src/panfrost/midgard/midgard_compile.c:2905
in /home/alyssa/rockchip_dri.so
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Cc: mesa-stable
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6373>
(cherry picked from commit 680fb05f99)
Before we drop the reference.
160 calls with 0B peak consumption from:
0xffffbd9d2fc3
in ??
pan_compute_liveness
at ../src/panfrost/util/pan_liveness.c:127
in /home/alyssa/rockchip_dri.so
mir_compute_liveness
at ../src/panfrost/midgard/midgard_liveness.c:55
in /home/alyssa/rockchip_dri.so
midgard_opt_dead_code_eliminate
at ../src/panfrost/midgard/midgard_opt_dce.c:118
in /home/alyssa/rockchip_dri.so
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Cc: mesa-stable
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6373>
(cherry picked from commit 8dd38e5a3e)
No need to put it on the context, we can keep it local in mir_squeeze
and drop when we're done.
15.77KB leaked over 85 calls from:
0xffffaed3bfc3
in ??
_mesa_hash_table_rehash
at ../src/util/hash_table.c:368
in /home/alyssa/rockchip_dri.so
hash_table_insert
at ../src/util/hash_table.c:403
in /home/alyssa/rockchip_dri.so
find_or_allocate_temp
at ../src/panfrost/midgard/mir_squeeze.c:48
in /home/alyssa/rockchip_dri.so
find_or_allocate_temp
at ../src/panfrost/midgard/mir_squeeze.c:35
in /home/alyssa/rockchip_dri.so
mir_squeeze_index
at ../src/panfrost/midgard/mir_squeeze.c:76
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Cc: mesa-stable
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6373>
(cherry picked from commit 62637a913a)
After we compile from NIR to a native binary, we can throw away the NIR.
17.47KB leaked over 104 calls from:
0xffff87dcafc3
in ??
_mesa_hash_table_init
at ../src/util/hash_table.c:163
in /home/alyssa/rockchip_dri.so
_mesa_hash_table_create
at ../src/util/hash_table.c:186
nir_lower_vars_to_ssa_impl
at ../src/compiler/nir/nir_lower_vars_to_ssa.c:717
in /home/alyssa/rockchip_dri.so
nir_lower_vars_to_ssa
at ../src/compiler/nir/nir_lower_vars_to_ssa.c:817
optimise_nir
at ../src/panfrost/midgard/midgard_compile.c:504
in /home/alyssa/rockchip_dri.so
midgard_compile_shader_nir
at ../src/panfrost/midgard/midgard_compile.c:2895
in /home/alyssa/rockchip_dri.so
panfrost_build_blit_shader
at ../src/panfrost/lib/pan_blit.c:103
in /home/alyssa/rockchip_dri.so
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Cc: mesa-stable
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6373>
(cherry picked from commit da6d0e3fac)
Fixes heaptrack leak:
19.37KB leaked over 63 calls from:
0xffff92bbefc3
in ??
nir_alu_instr_create
at ../src/compiler/nir/nir.c:442
in /home/alyssa/rockchip_dri.so
clone_alu
at ../src/compiler/nir/nir_clone.c:277
in /home/alyssa/rockchip_dri.so
clone_instr
at ../src/compiler/nir/nir_clone.c:495
in /home/alyssa/rockchip_dri.so
clone_block
at ../src/compiler/nir/nir_clone.c:544
clone_cf_list
at ../src/compiler/nir/nir_clone.c:594
clone_function_impl
at ../src/compiler/nir/nir_clone.c:672
in /home/alyssa/rockchip_dri.so
nir_shader_clone
at ../src/compiler/nir/nir_clone.c:744
in /home/alyssa/rockchip_dri.so
panfrost_shader_compile
at ../src/gallium/drivers/panfrost/pan_assemble.c:154
in /home/alyssa/rockchip_dri.so
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Cc: mesa-stable
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6373>
(cherry picked from commit 9146f596ed)
The *2 here would bump into the *2 in regset, causing assertion failures
dumping CS programs. Just set the mergedregs flag on a6xx, and don't
duplicate the mergedregs logic. If you're dealing with new HW where we
don't know if mergedregs is set, you may need to tweak the flag during
disasm setup for the stats to make sense.
Fixes: f7bd3456d7 ("freedreno: deduplicate a3xx+ disasm")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6323>
(cherry picked from commit a27823ef2c)
During build on Android 10, build error occurred:
'''
[ 26% 456/1718] Gen Header: libfreedreno_registers_32 <= a3xx.xml.h
FAILED: out/target/product/pinephone/gen/STATIC_LIBRARIES/libfreedreno_registers_intermediates/registers/adreno/a3xx.xml.h
/bin/bash -c "PATH=/usr/bin:\$PATH python3 external/mesa3d/src/freedreno/registers/gen_header.py external/mesa3d/src/freedreno/registers/adreno/a3xx.xml > out/target/product/pinephone/gen/STATIC_LIBRARIES/libfreedreno_registers_intermediates/registers/adreno/a3xx.xml.h"
Traceback (most recent call last):
File "external/mesa3d/src/freedreno/registers/gen_header.py", line 470, in <module>
main()
File "external/mesa3d/src/freedreno/registers/gen_header.py", line 446, in main
xml_file = sys.argv[2]
IndexError: list index out of range
'''
Align build rules with meson fixes it.
Fixes: 62ebd342 ("freedreno/registers: split header build into subdirs")
Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com>
Acked-by: Rob Clark <robdclark@gmail.com>
Acked-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6170>
(cherry picked from commit 8626d4cbef)
We really need to update the enum for consistency, but that involves
a bunch of GL & bitfield work which is error-prone, so since this is
a fix for stable lets do the simple things.
Confirmed that nothing in radv/aco/nir/spirv uses MAX_VERT_ATTRIB
except the one thing I bumped.
CC: mesa-stable
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6120>
(cherry picked from commit f038b3a136)
The round-to-nearest-even implementation found in lower_2f() is incorrect
for any value having a significand that is not directly representable
and whose non-representable part lies between 1 and half the minimum
representable value. In this case, the significand is rounded up instead
of being rounded down.
Fixes: 936c58c8fc ("nir: Extend nir_lower_int64() to support i2f/f2i lowering")
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Tested-by: Jesse Natalie <jenatali@microsoft.com>
Acked-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6290>
(cherry picked from commit 199bea0fd8)
KHR-GL45.robust_buffer_access_behavior.vertex_buffer_objects
on the CTS 4.6.0 branch and this fixes it.
Roland identified that if the vertex format doesn't contain channels
then we shouldn't be overriding them to 0, so RGB fetch out of bounds
should return 0 for RGB, but the A channel should still be getting back
1.
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6287>
(cherry picked from commit 430e3310e2)
Calling SET_TILING on a DMA buffer with the gen12 CCS modifier can fail
unnecessarily. The main surface in the BO is Y-tiled, but the CCS portion is
linear and can have a stride that's not a multiple of 128B. Because SET_TILING
is called on the CCS plane with I915_TILING_Y, the ioctl will sometimes reject
the stride.
SET_TILING was originally used in b6d45e7f74 to
fix an assertion failure in iris_resource_from_handle. Assigning the BO's
tiling_mode field is sufficient to avoid the failure.
Fixes: c19492bcdb ("iris: Handle importing aux-enabled surfaces on TGL")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6296>
(cherry picked from commit c111e9099c)
Fix warnings reported by Coverity Scan.
Resource leak (RESOURCE_LEAK)
leaked_storage: Variable bt1 going out of scope leaks the storage
it points to.
leaked_storage: Variable bt2 going out of scope leaks the storage
it points to.
Fixes: d0d14f3f64 ("util: Add unit test for stack backtrace caputure")
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6246>
(cherry picked from commit 96cfc684e6)
Fixes random failures of dEQP-VK.image.qualifiers.volatile.cube_array.r32i
and similar tests on Vega.
fossil-db (Navi):
Totals from 6 (0.00% of 135946) affected shaders:
VMEM: 1218 -> 1110 (-8.87%); split: +2.46%, -11.33%
SMEM: 174 -> 189 (+8.62%)
Copies: 84 -> 87 (+3.57%)
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Fixes: cd392a10d0 ('radv/aco,aco: use scoped barriers')
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6174>
(cherry picked from commit 7b4c24eb67)
We cannot decompress from the compute queue. While I'm pretty sure
VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL is only useful on the
graphics queue, I cannot find a VU that prevents the transition
from happening on another queue, so we need to be careful here.
This patch ensures we do the decompression on the barrier that changes
the queue ownership.
Another problem was that DCC images were considered fast-clearable
when not DCC compressed, which resulted in a mess with concurrent
queue ownership.
Cc: <mesa-stable@lists.freedesktop.org>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3387
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6252>
(cherry picked from commit e362ccb20c)
Currently Linux kernel gathers performance counters at fixed
intervals (~5-10ms), so if application uses AMD_performance_monitor
extension and immediately after glFinish() asks GL driver for HW
performance counter values it might not get any data (values == 0).
Fix this by moving the "read counters from kernel" code from
"is query ready" to "get counter values" callback with a loop around
it. Unfortunately it means that the "read counters from kernel"
code can spin for up to 10ms.
Ideally kernel should gather performance counters whenever we ask
it for counter values, but for now we have deal with what we have.
Signed-off-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5788>
(cherry picked from commit 2fbab5a1b3)
https://github.com/KhronosGroup/EGL-Registry/pull/95 has moved
a couple of extensions defines and functions to the upstream `eglext.h`,
but when 9a74746bd1 sync'ed these files we broke compilation
of apps that require these symbols on systems that don't have the
updated Khronos headers.
On non-GLVND builds, we still provide these headers, so everything's
fine, but on GLVND builds the Khronos headers are external so we need to
make sure we have a libglvnd version that's recent enough.
Fixes: 9a74746bd1 ("EGL: sync headers with Khronos")
Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6069>
(cherry picked from commit dd003abd2f)
The code applied the restriction too late, which could overflow LDS size,
which started happening more often after the minimum vertex count was
increased for Sienna.
Incorporate the clamping into the previous code for rounding up the counts.
Now the LDS size can never overflow, but it may use vector lanes less
efficiently (max_gsprims can be decreased more), which will be addressed
in the next commit.
Fixes: 4ecc39e1aa ("radeonsi/gfx10: NGG geometry shader PM4 and upload")
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6137>
(cherry picked from commit 64c741ffb7)
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.