It's very common needing to extract or overwrite a certain field
in an already packed register value, so add macros to do that
instead of manually doing that each time.
Signed-off-by: Karmjit Mahil <karmjit.mahil@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35088>
In panfrost_clear_depth_stencil and panfrost_clear_render_target, we
start the blit context before binding the clear targets. If we don't
legalize AFBC beforehand, we get a recursive blit crash. panfrost_clear
does not need this because the resource should already be legalized in
panfrost_batch_add_surface.
Fixes the following piglit tests with pan_force_afbc_packing:
- spec@arb_clear_texture@arb_clear_texture-base-formats
- spec@arb_clear_texture@arb_clear_texture-simple
- spec@arb_clear_texture@arb_clear_texture-sized-formats
Fixes: 17a62ff993 ("panfrost: legalize afbc before blitting")
Signed-off-by: Olivia Lee <olivia.lee@collabora.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34992>
In 59a3e12039, we changed the UBO->push optimization in panfrost to
only push UBOs that are available in a CPU buffer. We require
first_ubo_is_default_ubo, to ensure that UBO0 will be a user buffer. We
weren't setting this flag for the image conversion shaders, so got an
assertion failure compiling them. This can be triggered by the
panvk_force_afbc_packing driconf option.
The conversion shader info UBO isn't exactly a "default" UBO in the
sense of being lowered from uniforms, but it is a user buffer, so
setting the flag should be fine.
Fixes: 59a3e12039 ("panfrost: do not push "true" UBOs")
Signed-off-by: Olivia Lee <olivia.lee@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34992>
There's no behavior change, but to prepare for the next img2buf blit
improvement, except adding asserts to make clear of the existing blit
code paths.
v2: use switch with unreachable default per @gfxstrand has suggested
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35220>
Add perf ETW events using TraceLogging API, the following are adding:
- MFT receives fence (FenceCompletion).
- MFT has output MFSample (METransformHaveOutput).
- MFT calls to pipe end_frame (PipeEndFrame) -- bracketed.
- MFT calls to pipe flush (PipeFlush) -- bracketed.
- MFT submits a frame to pipe (PipeSubmitFrame) -- bracketed from begine_frame to encode_bitstream/encode_bitstream_sliced
- MFT processinput (ProcessInput) -- bracketed
- MFT processoutput (ProcessOutput) -- bracketed
The ETW provider(s) are:
- H264Enc: 0000e264-0dc9-401d-b9b8-05e4eca4977e
- H265Enc: 0000e265-0dc9-401d-b9b8-05e4eca4977e
- AV1Enc: 0000eaa1-0dc9-401d-b9b8-05e4eca4977e
Note that the provider is mostly the same as the WPPTrace provider for each codec, with the additional 'e' (e.g. 0000e264 vs 00000264)
Reviewed-by: Yubo Xie <yuboxie@microsoft.com>
Reviewed-by: Sil Vilerino <sivileri@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35219>
Allocate TS together with the tracked resource, which gets rid
of the resource mutation on surface creation and the diversion
between the interal and shared TS handling.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34488>
Untangle the convoluted render compatible check from
etna_render_handle_incompatible to make it easier to read and move it
into a separate function so it can be reused from other callers.
As this is intended to be called also at resource creation time, where
we don't know the exact level of the resource that might be rendered to,
the stride check for linear resources is made a bit more conservative by
checking that the last level (the one with the smallest stride) still
meets the render target stride alignment requirement.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34488>
TS is only allocated for single layer surfaces, so there is no need to
cache a ts_offset taking into account the layer offset in etna_surface.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34488>
etna_screen_resource_alloc_ts is only called for textures that have a
single layer and slice, as we don't want to duplicate the driver side
TS tracking information per layer or depth slice. Stop pretending to
support allocating TS for such resources.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34488>
Prevent the function from unnecessarily returning false by:
* Comparing the image tile range with that of every LOD instead of only
LOD0.
* Using the correct comparison check for the exclusive tile end ranges.
Fixes: 8dad01903a ("intel: Add and use isl _surf_image_has_unique_tiles()")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35192>
The BSpec page for Structure_RENDER_SURFACE_STATE says:
"For typed buffer and structured buffer surfaces, the number of
entries in the buffer ranges from 1 to 2^27. For raw buffer
surfaces, the number of entries in the buffer is the number of
bytes which can range from 1 to 2^30. After subtracting one from
the number of entries, software must place the fields of the
resulting 27-bit value into the Height, Width, and Depth fields as
indicated, right-justified in each field. Unused upper bits must be
set to zero."
According to the vkd3d-proton developers, this is what is happening
with the applications:
"There's also the problematic case of games using typed descriptors
but passing non-typed buffer descriptors, which is an extremely
common app bug that works on all D3D12 drivers that we need to work
around by creating typed views."
Previously, we had an assert() to check for "num_elements > (1 <<
27)", but that assert was preventing us from running games such as
Marvel's Spider-Man Remastered and Assassin's Creed: Valhalla in Debug
mode. So not only I removed the assert, but I also made the code clamp
num_elements to the maximum of (1 << 27) based on my incorrect
interpretation of the paragraph quoted above from BSpec.
What I did not realize was that num_elements is being used just to
calculate Structure_RENDER_SURFACE_STATE Height, Width and Depth, and
our register bit fields on SKL and newer are big enough to fit any
number of num_elements up to 2^32, not only 2^27. Clamping
num_elements results in an incorrect value for S.Depth, which
generates visual corruption in some games.
On Marvel's Spider-Man Remastered, without this patch the texture of
the asphalt in some streets (like the very first one you jump to when
the game starts) gets rendered incorrectly.
Testcase: vkd3d-proton/d3d12/test_large_texel_buffer_view
Link: https://github.com/HansKristian-Work/vkd3d-proton/issues/2071
Link: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12827
Fixes: f3c7e14f09 ("isl: don't assert(num_elements > (1ull << 27))")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35032>
This fprintf() was added in commit cce3bea2a7 ("i965/disasm: Align send
instruction meta-information with dst.")) to align the human-readable
send message info (e.g. "render MsgDesc: RT write ...") with the
destination register on the previous line.
Two months later we disabled printing the instruction offset in commit
662f1ccc24 ("i965: Disable hex offset printing in disassembly."),
thereby unaligning the human-readable send message info for the next 11
years.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35077>
We're calling it for fragment shaders and NVK is calling it for
eerything before invoking NAK so we may as well call it unconditionally
in NAK and skip calling it in NVK.
Reviewed-by: Lorenzo Rossi <snowycoder@gmail.com>
Acked-by: Karol Herbst <kherbst@redhat.com>
Reviewed-by: Mel Henning <mhenning@darkrefraction.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30403>
Codegen expects to get the handle in both the sampler and texture handle
sources. NAK only cares about texture_handle. Now that we don't care
about codegen anymore, we can drop the extra source.
Reviewed-by: Lorenzo Rossi <snowycoder@gmail.com>
Acked-by: Karol Herbst <kherbst@redhat.com>
Reviewed-by: Mel Henning <mhenning@darkrefraction.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30403>
With codegen gone, there's no point in hanging onto this helper.
Reviewed-by: Lorenzo Rossi <snowycoder@gmail.com>
Acked-by: Karol Herbst <kherbst@redhat.com>
Reviewed-by: Mel Henning <mhenning@darkrefraction.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30403>
Now that NAK is the default for everything, if someone explicitly
switches to codegen, they get what they get.
Reviewed-by: Lorenzo Rossi <snowycoder@gmail.com>
Acked-by: Karol Herbst <kherbst@redhat.com>
Reviewed-by: Mel Henning <mhenning@darkrefraction.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30403>
In current Xe KMD error dump it will remove the GuC log from dump
but would also drop any new binary added to error dump.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33249>
Xe KMD added topics without our notice in the past and that may happen
in future so better rename XE_TOPIC_INVALID to XE_TOPIC_UNKNOWN
and better detect topic changes.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33249>
error_decode_xe_read_hw_sp_or_ctx_line() is too specific, replacing
it by a more generic function that later will be used in other places
too.
Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33249>
this (conceptually) flattens out the batches into a wrapping id which
is used to determine whether a resource has in-flight work pending
the code cleanup is nice, but evaluating performance of this is difficult.
in testing a heavy use case of unsynchronized subdata:
* 10% fewer driver flushes (good)
* 20% fewer direct unsynchronized uploads (bad? or possibly hidden race conditions fixed...)
Fixes: 9cc06f817c ("tc: allow unsynchronized texture_subdata calls where possible")
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35026>
We should use the cl_slice code to get proper validation, which also makes
it simpler to read out data and gets rid of some UB there.
This also fixes CL_KERNEL_EXEC_INFO_SVM_PTRS with param_value being null.
Cc: mesa-stable
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32942>
The old interfaces added back in clover's time were modeled after a very
bindful resource model.
However SVM (shared virtual memory) requires us to be way more flexible.
The new interfaces allow frontends to create a cut-out in the GPU's vm and
to assign addresses themselves. This gives us the following benefits:
- The frontend is empowered to synchronize resource addresses between
several devices. cl_mem objects in OpenCL span across a set of multiple
devices and SVM requires them to have the same VMA across all of them.
- Coarse grain SVM can be implemented without bothering drivers too much
as the frontend can be responsible to make sure a host allocation with
a specific VMA matches a GPU allocation with the identical VMA.
- Support for Global variables in the CrossWorkgroup storage class
Initializers. Those can depend on addresses of CrossWorkgroup memory,
if the frontend can just assign a VMA, this address can be passed as a
constant to spirv_to_nir and folded without the need to support
spilling of constant initializers.
Drivers not able to give us a vm-cutout are left with implementing
cl_ext_buffer_device_address instead.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32942>
cl_ext_buffer_device_address requires us to set a fixed address for a
given memory allocation. As this extension is intended to be implemented
on top of vulkan we have to take its limitations into account.
For SVM we'll add proper VM management interfaces, but zink won't be able
to implement those, so here we are.
The old interfaces added back in clover's time were modeled after a very
bindful resource model and the frontend was require to bind all the used
resources ahead of launch_grid.
cl_ext_buffer_device_address and also SVM however will require us to
dynamically attach a list of buffers used in a dispatch with known
addresses, hence set_global_binding isn't really suited for those use
cases.
So PIPE_RESOURCE_FLAG_FIXED_ADDRESS is added to tell a driver that the
address of a resource needs to stay the same over its lifetime, which then
can be queried via pipe_screen::resource_get_address.
All such buffers then can be either bound via set_global_binding or passed
in via pipe_grid_info::globals.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32942>
