If the file ptr is not NULL then foz_destroy will also try to destroy it.
Fixes: eca6bb9540 ("util/fossilize_db: add basic fossilize db util to read/write shader caches")
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14671>
(cherry picked from commit 51416b1a12)
Instead of a unreachable.
This would avoid an assert on debug builds that uses vkfoo_to_str to
print structure types. This will become more common as some tests will
start to use VK_STRUCTURE_TYPE_MAX_ENUM to mark structures from
unsupported extensions more often.
v2 (Jason):
* Include enum name on the default message
* Handle MAX_ENUM as a special case
v3 (Jason):
* vk_ObjectType_to_ObjectName don't need to use ${enum.name}
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14525>
(cherry picked from commit 821c66e50c)
Fixes InconsistentSpirv validation errors reporting that PackHalf2x16
outputs uint rather than float.
For example the previous code generates the following SPIR-V with
PackHalf2x16 output as a float:
%2018 = OpExtInst %float %1 PackHalf2x16 %2017
%2019 = OpBitcast %uint %2018
The new code generates:
%2018 = OpExtInst %uint %1 PackHalf2x16 %2017
%2019 = OpBitcast %uint %2018
cc: mesa-stable
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14568>
(cherry picked from commit 985dae7f41)
Fixes the following valgrind warnings:
Conditional jump or move depends on uninitialised value(s)
at 0x5D1298C: draw_pt_so_emit_prepare (draw_pt_so_emit.c:95)
by 0x5D89FD7: llvm_middle_end_prepare (draw_pt_fetch_shade_pipeline_llvm.c:319)
by 0x5D13BFF: vsplit_prepare (draw_pt_vsplit.c:229)
by 0x5D0D5D8: draw_pt_arrays.isra.0 (draw_pt.c:124)
by 0x5D0DA08: draw_instances (draw_pt.c:484)
by 0x5D0DEB9: draw_vbo (draw_pt.c:610)
by 0x5E847D6: r300_swtcl_draw_vbo (r300_render.c:901)
by 0x5D67125: u_vbuf_draw_vbo (u_vbuf.c:1470)
by 0x5CFCAD3: cso_multi_draw (cso_context.c:1639)
by 0x58FEC37: st_draw_gallium (st_draw.c:186)
by 0x5A486BA: _mesa_draw_arrays.part.0 (draw.c:1323)
by 0x48B4E27: stub_glDrawArrays (piglit-dispatch-gen.c:12421)
Uninitialised value was created by a stack allocation
at 0x5E90D3F: r300_draw_init_vertex_shader (r300_vs_draw.c:313)
Conditional jump or move depends on uninitialised value(s)
at 0x5D175D9: draw_create_vertex_shader (draw_vs.c:70)
by 0x5E90E7A: r300_draw_init_vertex_shader (r300_vs_draw.c:366)
by 0x5E8751F: r300_create_vs_state (r300_state.c:1950)
by 0x594453B: st_create_common_variant (st_program.c:888)
by 0x594720C: st_get_common_variant (st_program.c:973)
by 0x59484B6: st_precompile_shader_variant (st_program.c:1994)
by 0x59484B6: st_finalize_program (st_program.c:2056)
by 0x58F0571: st_program_string_notify (st_cb_program.c:128)
by 0x5928C9B: st_link_tgsi (st_glsl_to_tgsi.cpp:7514)
by 0x5904B53: st_link_shader (st_glsl_to_ir.cpp:178)
by 0x58D3E08: _mesa_glsl_link_shader (link_program.cpp:91)
by 0x58865C7: link_program (shaderapi.c:1363)
by 0x58865C7: link_program_error.part.0 (shaderapi.c:1474)
by 0x48DBC5A: stub_glLinkProgram (piglit-dispatch-gen.c:34426)
Uninitialised value was created by a stack allocation
at 0x5E90D4F: r300_draw_init_vertex_shader (r300_vs_draw.c:313)
Based on Filip Gawin's
r300: set new_vs.type to PIPE_SHADER_IR_TGSI
CC: mesa-stable
Reviewed-by: Emma Anholt <emma@anholt.net>
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14620>
(cherry picked from commit b5b105df96)
It's not obvious why the (gl_FrontFacing ? -1.0 : 1.0) case was handled
different for Gfx12+ than for previous generations, and it's not
correct. It tries to negate the result as an integer, and it does this
before the mask operation that clears the other bits in the value.
When we eventually support dual-SIMD8 dispatch, the other front-facing
bit is in g1.6 at bit 15, so similar code should be possible there.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Fixes: c92fb60007 ("intel/fs/gen12: Implement gl_FrontFacing on gen12+.")
Closes: #5876
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14625>
(cherry picked from commit 945fb51fb5)
this would allocate a new stream uploader for every map if the offset was
large (e.g., all sparse buffer usage), which almost immediately consumes all vram
cc: mesa-stable
fixes KHR-GL46.CommonBugs.CommonBug_SparseBuffersWithCopyOps
Acked-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14381>
(cherry picked from commit d83b52928c)
Commit 9da15aa3aa ("llvmpipe: enable EXT_memory_object(_fd)") enabled
the extension, but left this unimplemented.
Leaving this unimplemented causes segfaults for anyone trying to retrieve
the UUIDs, as the calling code in the state tracker does not check if the
function is implemented. This affects e.g. current Wine versions.
Set the UUID to all zeros. Although this slightly violates the vulkan
specification (since 1.2.146), the UUIDs have to match the ones from
lavapipe (lvp_get_physical_device_properties_1_1).
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5865
Fixes: 9da15aa3aa ("llvmpipe: enable EXT_memory_object(_fd)")
Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Reviewed-by: Dave Airlie airlied@redhat.com
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14558>
(cherry picked from commit 537a0ee3b7)
When doing copies of descriptors from one set to another, that contain
either a UNIFORM_BUFFER or STORAGE_BUFFER, both the buffer view &
surface state are allocated from the source descriptor. Therefore we
need to copy their content otherwise we could run into lifecycle
issues when the source descriptor is destroyed.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14585>
(cherry picked from commit acebea9cf1)
This fixes nir_opt_cse miss replace a non-sparse tex instruction
with a sparse tex instruction and fail the nir_validate_shader().
Fixes: 3a7972f72a ("nir,spirv: add sparse texture fetches")
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/14362>
(cherry picked from commit 2cee73f0f7)
By software ABI, a blend shader is permitted to clobber registers
R0-R15. The scheduler needs to be aware of this, to avoid moving a write
to one of these registers past the BLEND itself. Otherwise the schedule
is invalid.
This bug affects GLES3.0, but is rare enough in practice that we had
missed it. It requires a fragment shader to write to multiple render
targets with attached blend shaders, and have temporaries register
allocated to R0-R15 that are not read by the blend shader, but are sunk
past the BLEND instruction by the scheduler. Prevents a regression when
switching boolean representations on:
dEQP-GLES31.functional.shaders.builtin_functions.integer.uaddcarry.uvec4_lowp_fragment
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14577>
(cherry picked from commit b8d37eb1bb)
A rule with executable_regexp tag would match every executable
without this fix and force_glsl_extensions_warn would be always
set to true which breaks some dEQP tests.
Fixes: 5740ac3701 ("xmlconfig: Add static driconfig support")
Reviewed-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14562>
(cherry picked from commit d15021435e)
As indicated by
VkPhysicalDeviceFragmentShadingRatePropertiesKHR::fragmentShadingRateWithShaderSampleMask
our implementation will clamp to 1x1 when reading samplemask or
writing to samplemask.
This fixes vkd3d-proton tests test_sample_mask_dxbc & test_sample_mask_dxil
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: b6332fc4a8 ("intel/compiler: handle coarse pixel in render target writes descriptors")
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14553>
(cherry picked from commit 30a8b8d2df)
Setting the screen ro member before we checked gpu id means the error
case leads to a double-free because screen->ro is set and allocated
by parent who hanbdles de-alloc a second time after we destroyed the
screen we just created because ro was set.
Cc: mesa-stable
Signed-off-by: Carsten Haitzler <carsten.haitzler@foss.arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14516>
(cherry picked from commit 874f4095c5)
the original change here attempted to fix calculating the maximum bound for the
mapped readback buffer by adding the maximum attribute size to the final element
used by readback
the calculation was erroneous, however, because it instead calculated the maximum
offset instead of the size, which would cause a different kind of overrun
Fixes: 3c5b7dca30 ("util/vbuf: fix buffer overrun in attribute conversions")
fixes#5846
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14479>
(cherry picked from commit 596d2ab0ad)
It's optional even if VkPhysicalDeviceExternalImageFormatInfo is there.
Fixes: 108f386a61 ("venus: initial support for VkPhysicalDevice commands")
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/14503>
(cherry picked from commit 17b753459e)
this shouldn't be used at all, but some drivers get it wrong and I don't want
to have to fix every driver
Fixes: 039ed2de94 ("zink: always use type size for query result copy stride")
Reviewed-by: Hoe Hao Cheng <haochengho12907@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14397>
(cherry picked from commit d3bb5b5dd1)
this appeared to fix some sort of bug related to preserving qbo data,
but really there shouldn't have been any sort of bug anyway since the qbos
all get read back, and thus the data is already preserved
instead, it just preserved the query id, which overloaded the pools and crashed
This reverts commit 79790e276f.
fixes#5669
Reviewed-by: Hoe Hao Cheng <haochengho12907@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14397>
(cherry picked from commit 2fa1bf60d6)
xfb queries have 2 results, and the availability bit is a 3rd result, so
the buffer size has to be at least that big and the copy offset has to reflect
the number of xfb results in the src offset
cc: mesa-stable
Reviewed-by: Hoe Hao Cheng <haochengho12907@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14397>
(cherry picked from commit f8d2770737)
st_init_extensions (src/mesa/state_tracker/st_extensions.c) already
enforces the GLSL 1.30 or EXT_gpu_shader4 requirement, so Crocus will
already behave this way on this hardware.
The EXT_texture_integer spec says:
NV_gpu_program4 or EXT_gpu_shader4 is required.
Without one of these extensions or GLSL 1.30, it is impossible to read
integer values from a texture. The spec also says:
This extension does not enforce type consistency for texture
accesses or between fragment shaders and the corresponding
framebuffer attachments. The results of a texture lookup from an
integer texture are undefined:
* for fixed-function fragment processing, or
* for shader texture accesses expecting floating-point return
values.
The color components used for per-fragment operations and written
into a color buffer are undefined:
* for fixed-function fragment processing with an integer color
buffer,
* for fragment shaders that write floating-point color components
to an integer color buffer, or
* for fragment shaders that write integer color components to a
color buffer with floating point or normalized integer
components.
So it's really a soft requirement, but also kind of rude to expose the
extension without a way to use it properly.
Closes: #4497
CC: mesa-stable
This was somehow missed by me and during review.
Fixes fcfc4ddfcc: ("v3dv: Fix V3DV_HAS_SURFACE preprocessor condition")
Signed-off-by: Roman Stratiienko <roman.o.stratiienko@globallogic.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14190>
(cherry picked from commit 2cbbfd23ce)
We're using the wrong helper to get the subslice total count.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: c24ba6cecb ("intel/dev: Handle CHV CS thread weirdness in get_device_info_from_fd")
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14492>
(cherry picked from commit d6c0d16791)
"most" times it isn't necessary to insert any pipeline barriers when binding
descriptors, as GL requires explicit barrier usage which comes through a different
codepath
the exception here is when the following scenario occurs:
* have buffer A
* buffer_subdata is called on A
* discard path is taken || A is not host-visible
* stream uploader is used for host write
* CmdCopyBuffer is used to copy the data back to A
buffer A now has a pending TRANSFER write that must complete before the buffer is
used in a shader, so synchronization is required any time TRANSFER usage is detected
in a bind
there's also going to be more exceptions going forward as more internal usage is added,
so just remove the whole fake-barrier mechanism since it'll become more problematic
going forward
Cc: 21.3 mesa-stable
Reviewed-by: Hoe Hao Cheng <haochengho12907@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14496>
(cherry picked from commit 3e5f4cebe8)
ensure that vertex key data is always zeroed when changing last stage since it will
be updated before draw anyway and can only cause problems if left alone here
fixes the following caselist:
dEQP-GLES31.functional.shaders.builtin_constants.tessellation_shader.max_tess_evaluation_texture_image_units
dEQP-GLES31.functional.tessellation_geometry_interaction.feedback.tessellation_output_quads_geometry_output_points
dEQP-GLES31.functional.ubo.random.all_per_block_buffers.25
cc: mesa-stable
Reviewed-by: Hoe Hao Cheng <haochengho12907@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14482>
(cherry picked from commit d15ff96da2)
If a primitive is added with missing vertices, this will shift all
the vertices and produce incorrect rendering.
In issue #5786 the app uses GL_LINE_STRIPS with a single vertex.
Adding extra vertices can make the initial estimation for the index
buffer size incorrect, so this buffer can now be growed if needed.
Fixes: ac3d4c7635 ("vbo/dlist: convert LINE_STRIPS to LINES")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5786
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14476>
(cherry picked from commit dcbf2423d2)
Fixes a leak:
==47470== 60 bytes in 1 blocks are definitely lost in loss record 1,790 of 1,904
==47470== at 0x484186F: malloc (vg_replace_malloc.c:381)
==47470== by 0x58EBA6A: compile_vertex_list (vbo_save_api.c:535)
==47470== by 0x58EDABF: wrap_buffers (vbo_save_api.c:1021)
==47470== by 0x58EDF97: upgrade_vertex (vbo_save_api.c:1134)
==47470== by 0x58EE52F: fixup_vertex (vbo_save_api.c:1251)
==47470== by 0x58EFE9E: _save_Normal3f (vbo_attrib_tmp.h:315)
Fixes: 69615d92a0 ("vbo/dlist: realloc prims array instead of free/malloc")
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14474>
(cherry picked from commit a5bc8c4be9)
Fixes a leak:
==46154== 48 bytes in 1 blocks are definitely lost in loss record 1,571 of 1,905
==46154== at 0x48466AF: realloc (vg_replace_malloc.c:1437)
==46154== by 0x5FC98EC: util_idalloc_resize (u_idalloc.c:43)
==46154== by 0x5FC9C16: util_idalloc_alloc_range (u_idalloc.c:125)
==46154== by 0x56FDB9F: _mesa_EndList (dlist.c:13681)
Fixes: b703d7c15f ("dlist: store all dlist in a continuous memory block")
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14474>
(cherry picked from commit 6e9cd801a6)
TGSI reserves 2 components for the coord in the first operand vector, even
for 1D. Fixes r600 failure with shadow1d.
Fixes: 390a3fcdc4 ("nir_to_tgsi: Add support for TXP.")
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14322>
(cherry picked from commit 3563ae4b2d)
Different parts of our codebase disagree on whether spatial
coordinates/dimensions are given in pixels or blocks, which differ by a
constant factor for block-compressed formats. This disagreement
manifests as incorrect results accessing block-compressed formats.
To resolve this, define the public tiling routines to take their
coordinates in pixels, and align the relevant code in Panfrost
accordingly.
Fixes rendering glitches in Factorio, as well as a pile of piglits on
Panfrost. It should also fix glTexSubImage() with ETC1 on Lima, but
there are no tests for this in dEQP/Piglit.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Tested-by: Vasily Khoruzhick <anarsoul@gmail.com> [dEQP/Lima]
Tested-by: Erico Nunes <nunes.erico@gmail.com> [Piglit/Lima]
Reported-by: Icecream95 <ixn@disroot.org>
Closes: #5560
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14370>
(cherry picked from commit b920ace4bc)
There is a lot of unit confusion in Gallium due to pixels versus blocks
matching only with uncompressed textures. Add a helper to do a common
pixels->blocks unit conversion required in multiple drivers.
v2: Rename dst->blocks, src->pixels to avoid confusion about the units
to casual readers (Mike).
Note to mesa-stable maintainers: this is marked as Cc: mesa-stable so
the next patch (a set of bug fixes for Lima and Panfrost) can be
backported. It's not a bug fix in its own right, of course.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Emma Anholt <emma@anholt.net> [v1]
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14370>
(cherry picked from commit 26c533f167)
This makes the compiler less predictable and should only have a very small
effect on performance.
fossil-db (Vega):
Totals from 2410 (1.79% of 134756) affected shaders:
CodeSize: 6911568 -> 6942840 (+0.45%)
Fixes Horizon Zero Dawn artifacts.
If a shader has:
a = pack_half_2x16(a, 0) //rtne
store(pack_half_2x16(0, b) | a) //rtne
a = unpack_2x16(a).x
It will become:
store(pack_half_2x16(a, b)) //rtz
a = unpack_2x16(pack_half_2x16(a, 0)).x //rtne
So a later shader with "unpack_2x16(load()).x" will use "a" rounded to
zero, while the previous shader will use "a" rounded to the nearest even.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Fixes: 2f125908b3 ("radv,aco: lower_pack_half_2x16")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14475>
(cherry picked from commit 60c711833f)
If a BO is removed from a cache bucket list via a lookup, we must
handle it in the same way as if a allocation from the cache happened:
tell valgrind that the buffer is active again and take a reference
to the etna_device, which the BO had given up while being in the
cache.
Cc: mesa-stable
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Tested-by: Guido Günther <agx@sigxcpu.org>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14159>
(cherry picked from commit 1b1f8592c0)
The intended limit for command stream size is 64KB, as this is what old
kernels can reliably do and what allows for maximum number of queued
streams on newer kernels. However, due to unit confusion with the size
member, which is in dwords, the submitted streams could grow up to
~128KB. Fix this by using the proper limit in dwords.
Flushing due to some limits being exceeded is not an issue, but is
expected with certain workloads, so lower the severity of the message
being emitted in this case to debug level.
Cc: mesa-stable
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/14425>
(cherry picked from commit ccfd5054a4)
This fixes a test from the vkd3d-proton test_dual_source_blending_dxbc
test which asserts in the backend with :
brw_fs_visitor.cpp:716: void fs_visitor::emit_fb_writes(): Assertion `!prog_data->dual_src_blend || key->nr_color_regions == 1' failed.
This is because there is 2 color attachments provided by the
renderpass so we initially set nr_color_regions = 2. But once we've
parsed the shader, we can see it's only using one output (with dual
source color blending).
This change looks at the output variables to update the valid output
variables.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14417>
(cherry picked from commit 07bc6b7ed9)
Fixes memory leak with dependencies array:
==5224== 104 (96 direct, 8 indirect) bytes in 3 blocks are definitely lost in loss record 1,954 of 2,035
==5224== at 0x484178A: malloc (vg_replace_malloc.c:380)
==5224== by 0x484670B: realloc (vg_replace_malloc.c:1437)
==5224== by 0x14DBAB9B: update_bo_syncobjs (iris_batch.c:819)
==5224== by 0x14DBADB8: update_batch_syncobjs (iris_batch.c:898)
==5224== by 0x14DBB3D5: _iris_batch_flush (iris_batch.c:1031)
==5224== by 0x14DB77D0: iris_transfer_map (iris_resource.c:2348)
==5224== by 0x157786FD: u_transfer_helper_transfer_map (u_transfer_helper.c:243)
==5224== by 0x14C479E7: tc_buffer_map (u_threaded_context.c:2252)
==5224== by 0x1434F3F8: pipe_buffer_map_range (u_inlines.h:393)
==5224== by 0x1435094A: _mesa_bufferobj_map_range (bufferobj.c:491)
==5224== by 0x143586D9: map_buffer_range (bufferobj.c:3737)
==5224== by 0x14358DA3: _mesa_MapBuffer (bufferobj.c:3947)
==5224== 240 (192 direct, 48 indirect) bytes in 6 blocks are definitely lost in loss record 1,984 of 2,035
==5224== at 0x484178A: malloc (vg_replace_malloc.c:380)
==5224== by 0x484670B: realloc (vg_replace_malloc.c:1437)
==5224== by 0x14DBAB9B: update_bo_syncobjs (iris_batch.c:819)
==5224== by 0x14DBADB8: update_batch_syncobjs (iris_batch.c:898)
==5224== by 0x14DBB3D5: _iris_batch_flush (iris_batch.c:1031)
==5224== by 0x14FF72CC: iris_get_query_result (iris_query.c:631)
==5224== by 0x14C4396A: tc_get_query_result (u_threaded_context.c:880)
==5224== by 0x1458F4F7: get_query_result (st_cb_queryobj.c:273)
==5224== by 0x1458F7EB: st_WaitQuery (st_cb_queryobj.c:352)
==5224== by 0x144EFF66: get_query_object (queryobj.c:742)
==5224== by 0x144F01AE: _mesa_GetQueryObjectuiv (queryobj.c:811)
And leak with syncobjs:
==13644== 8 bytes in 1 blocks are definitely lost in loss record 1 of 1,846
==13644== at 0x484186F: malloc (vg_replace_malloc.c:381)
==13644== by 0x639789B: iris_create_syncobj (iris_fence.c:69)
==13644== by 0x63B213A: iris_batch_reset (iris_batch.c:512)
==13644== by 0x63B3637: _iris_batch_flush (iris_batch.c:1056)
==13644== by 0x65EF2BC: iris_get_query_result (iris_query.c:631)
==13644== by 0x623B970: tc_get_query_result (u_threaded_context.c:880)
==13644== by 0x5B874F7: get_query_result (st_cb_queryobj.c:273)
==13644== by 0x5B877EB: st_WaitQuery (st_cb_queryobj.c:352)
==13644== by 0x5AE7F66: get_query_object (queryobj.c:742)
==13644== by 0x5AE8150: _mesa_GetQueryObjectiv (queryobj.c:801)
Fixes: ce2e2296ab ("iris: Suballocate BO using the Gallium pb_slab mechanism")
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14387>
(cherry picked from commit b8f0459d6f)
Use header->header_size to offset cache data as well in case the header
struct extends on a newer driver but the cache data was appended with
an old header.
Fixes: 723f0bf74a ("venus: initial support for module and pipelines")
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/14463>
(cherry picked from commit 48712b8cc5)
Because the extend_cb vfunc is not initialized, there is a risk that
the emission code calls into a random pointer.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14418>
(cherry picked from commit 1d40d53e03)
After some experimentation with computerator, it seems on a618 that
writing a full register and then reading half of it as a half register
requires a delay of 6, the same as the delay for cat5/cat6 sources. The
other direction only has a delay of 5, but just bump it unconditionally
out of an abundance of caution.
Fixes: 890de1a436 ("ir3/delay: Fix full->half and half->full delay")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14246>
(cherry picked from commit 603791bdeb)
