When a job loop is submitted to the GPU, as in IGT
panfrost_submit@pan-reset, this will trigger a DRM scheduler timeout and
eventually a devcoredump. However, when pandecode traverses the list of
jobs in a submit BO, it will iterate forever.
Fix it by adding already-visited CPU VA's into a mesa pointer set and
checking that the current job's CPU VA hasn't already been handled.
Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14034>
I do not understand the code here well enough to tell what the correct
behavior is. prog->num_gprs is a unit8_t, so my guess is that the MIN
is there to make sure we stay within the limit of that. However the
current logic is a bit strange. If info_out.bin.maxGPR + 5 is bellow
256 we use that. If not then we write 256 which converts to 0 in a
uint8_t...
The patch changes the upper value to 255.
Fixes a warning with clang
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14304>
We had a mix of common-macro-and-chip-overrides in static decls and plus
more overrides later in C code. It's way cleaner to just have a static
decl for the base options and chip overrides in C code.
This moves a few things (lower_cs_local_index_to_id, lower_wpos_pntc,
lower_int64_options) to the common static decl that had been pasted into
both a3xx-a5xx and a6xx.
Reviewed-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18327>
We'd keep incrementing the costs in a cmd buffer's dynamic_pass on each
BeginRendering. This fixes the main renderpass of aztec ruins on zink to
use gmem, taking fps from ~8 to ~10.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18352>
The usage of _MTX_INITIALIZER_NP is a problem. Sure, the code builds on
Linux and Windows, and it even usually works, but is problematic.
It means that Windows lock debugging tools cannot be used with that code.
So we remove _MTX_INITIALIZER_NP to gain the following benefit:
Aligning to the C11 standard threads.h definitions.
Improving portability of the threading code to better support Windows.
This change removes one of the most prolific uses of _MTX_INITIALIZER_NP by
slightly increasing the cost of simple_mtx_lock when targeting platforms that
don't support futex, but it's cost are far less than the cost of syscall,
so the affect are negligible.
The futex code path are not affected. And Windows 8 and upper also
supports the futex codepath, so it's only affect the Windows version < 8, MacOS
or other platforms that doesn't support for futex.
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17122>
This might not be optimal but it matches our current behaviour and is much more
justified than the "accidental" code before. Caught by the gcc warning:
../src/panfrost/midgard/midgard_schedule.c:1227:48: warning: the comparison will
always evaluate as ‘true’ for the address of ‘writeout_branch’ will never be
NULL [-Waddress]
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18338>
Command buffers were only being partially reset. Fix this by factoring out the
common parts of pvr_cmd_buffer_reset() and pvr_cmd_buffer_reset() into a common
function, so there's now only a single place to free command buffer state, and
zeroing out parts of the command buffer that were missed.
Signed-off-by: Frank Binns <frank.binns@imgtec.com>
Reviewed-by: Rajnesh Kanwal <rajnesh.kanwal@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18317>
The common code in Mesa will rewrite the old entry points to these
if available.
Since we implement events and timestamps queries in the driver the
API changes don't quite affect us.
vkQueueSubmit2 is already implemented in the common synchronization
framework and the driver works in terms of a submit hook that is
independent of the actual entry point used by the application.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18290>
Added with KHR_synchronization2. The common code in Mesa will
rewrite vkCmdPipelineBarrier to vkCmdPipelineBarrier2.
With synchronization2 barriers now have a per-barrier stage
and access flags (previously these were shared by all the barriers
in a vkCmdPipelineBarrier commands), so we need to rewrite a bit
the logic to account for this.
Also, stage and access flag bits have been expanded and renamed.
Particularly, some new flags have been added that we need to account
for.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18290>
OpenGL 3.0 requires ARB_texture_float, which technically speaking
requires linear-filtering support for FP32 textures. However, because a
lot of early implementations just ignore this and does nearest filtering
instead due to lack of hardware features for this, this functionality
was never added to the OpenGL CTS.
The result is that FP32 is a feature that is required on paper, but
is unreliable to be used by applications in practice. This is mostly
fine; for most filterable use-cases (e.g colors), FP16 is fine and saves
a bunch of bandwidth, and for cases where you really need the extra bits
(depth-reads etc), filtering is usually not what's wanted.
To save drivers that doesn't support filtering of FP32 filtering from
having to manually whack the state, and get needless CSOs in the CSO
caches, let's force this in early, where we already do the same for
integer textures.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18292>
There's no need to re-check the DRI-config setting here; we either
already got nearest filtering already, or the we applied a work-around
to avoid incomplete textures. In either case, these should be nearest,
no need to check for it again.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18292>
From the Vulkan spec says:
"VUID-VkGraphicsPipelineCreateInfo-pStages-00738
If the pipeline is being created with pre-rasterization shader
state and pStages includes a geometry shader stage, and does not
include any tessellation shader stages, its shader code must
contain an OpExecutionMode instruction specifying an input
primitive type that is compatible with the primitive topology
specified in pInputAssembly"
In other words, the GS input primitive and the topology must match, so
it's possible to get this information directly from the GS instead of
from the pipeline key. Main benefit is that the driver can compile all
pre-rasterization stages without knowing the primitive topology.
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/18282>
Take this real-world (trimmed) shader:
precision highp float;
in lowp vec4 var_varVertexColor;
layout(location = 0) out vec4 out_FragColor0;
void main() {
vec4 textureColor0 = vec4(1.000000e+00, 0.000000e+00, 0.000000e+00, 1.000000e+00);
vec3 color = vec3(1.000000e+00, 1.000000e+00, 1.000000e+00);
vec4 outColor = vec4(vec3((color).rgb), 1.000000e+00);
(outColor *= vec4(var_varVertexColor));
(out_FragColor0 = outColor);
}
After opts, it's just a store from input to output. If we decide to lower
the input to 16-bit, then as long as the driver can handle 16-bit outputs,
it would be a good idea to demote the output and save the conversions.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18003>
