Buffer resources are quite special as they are only one dimensional,
always linear, don't have miplevels or array slices, never have a
texture or render compatible sibling, don't ever use TS.
The gallium context interface acknowledges this fact by providing
separate entry points for buffer maps/unmaps/flushes.
Provide a specialized etna_buffer_resource as a much more lightweight
alternative to the fullblown etna_resource and implement buffer
maps/unmaps in the same straight forward, direct map manner that is
hidden inside all the tiling, TS and resource sibling handling in
etna_transfer_map/unmap. It is expected that further map optimizations
can be added on top of this simple implementation much more easily
than in the merged buffer/texture transfer code.
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/34061>
A begin/end sequence is something like (it's all macros based):
radeon_begin(cs);
radeon_emit(PKT3(PKT3_DRAW_INDEX_AUTO, 1, cmd_buffer->state.predicating));
radeon_emit(vertex_count);
radeon_emit(V_0287F0_DI_SRC_SEL_AUTO_INDEX | use_opaque);
radeon_end();
This is loosely based on RadeonSI (see !8653 (a0978fff)) and it seems
indeed faster overall.
The main goal of this rework is to re-use the same logic as RadeonSI
for paired packets on GFX12 (also GFX11 dGPUs) because it's supposed
to be way faster, especially on GFX12 where the CP is slow. The other
goal is to share more cmdbuf emission between both drivers in the near
future.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34229>
This is probably a little more code but we're about to add real data for
Turing+ so it's better to have things contained like this. Since Volta
and earlier will always remain hacks, we might as well have those hacks
in the per-SM files rather than pretending we have a general thing in
sched_common.rs.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Mel Henning <mhenning@darkrefraction.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34302>
We're about to add instruction latencies which are going to be in their
own files because they're also massive. This makes things follow a bit
more of a module structure where sm70.rs is the thing that ties it all
together, sm70_encode.rs is the encoder, and smXX_instr_latencies.rs
will be the individual latency files.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Mel Henning <mhenning@darkrefraction.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34302>
After ca09c173f6, util_blitter_clear_render_target() requires
a call to util_blitter_save_fragment_constant_buffer_slot().
The radeonsi implementation was using the same sequence with
util_blitter_clear_depth_stencil() which does not need this
call. This was the cause of the refcnt imbalance.
For instance, this issue is triggered with:
"piglit/bin/ext_clear_texture-stencil -auto -fbo"
while setting GALLIUM_REFCNT_LOG=refcnt.log.
Fixes: ca09c173f6 ("gallium/u_blitter: remove UTIL_BLITTER_ATTRIB_COLOR, use a constant buffer")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34291>
This enables support for NV12, which are really useful when
dealing with hardware video decoders. This patch makes use
of the integrated YUV tiler to convert multi-planar to YUYV.
The binary blob uses the same method to deal with multi-planar
YUV formats. Other formarts will be added in a follow-up patch.
Tested with kmscube (nv12-1img) and the following gstreamer pipeline:
gst-launch-1.0 filesrc location=/tmp/test.mp4 ! qtdemux ! v4l2slh264dec ! video/x-raw,format=NV12 ! glimagesink
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Signed-off-by: Peter Frühberger
Signed-off-by: Marek Vasut <marex@denx.de>
Acked-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3418>
By default mesa now only supports DRI3.
If Xorg is not activating DRI3, it will show an almost empty screen, which is not working.
No error message is given.
This e.g. happens at Debian package
xserver-xorg-video-intel at the i915 gallium driver.
This commit generates error messages to explain the problem.
Signed-off-by: GKraats <vd.kraats@hccnet.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33679>
A pipeline barrier which contains an image layout transition like
COLOR_ATTACHMENT_OPTIMAL -> TRANSFER_DST_OPTIMAL on compute queue
would just hang. Such a barrier is useless in practice but it's legal.
Prevent GPU hangs by skipping FCE or FMASK_DECOMPRESS when it's not
on the graphics queue.
Fixes dEQP-VK.synchronization2.layout_transition.compute_transition*.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34231>
Daniel Stone