It's only needed by X11/DRI2. This allows glthread to be used by android,
drm, wayland, and device (EGL backend).
This is the only solution to allow the egl/drm backend to work with glthread
without ugly hacks between libgbm and libEGL.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18223>
GLES1 only has (Multi)Draw{Array,Elements}, but glthread converts them
to the more complicated versions and then calls them through the dispatch,
which generated GL_INVALID_OPERATION.
Luckily, we can export them with the Internal prefix, so they are unlikely
to be used by apps by accident.
Acked-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18223>
If an invalid parameter is received along with an invalid pointer and we
ignore the invalid parameter and dereference the pointer, we crash.
Since we can't fully validate all parameters (such as whether "shader"
is a valid object ID), remove the custom code.
Acked-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18223>
Now that the state for each pipeline is split into pieces, we can mostly
implement it by stitching together the pieces. One TODO is that we could
do more to split up the pre-rast and FS commands into separate draw
states so that we have to emit less commands when fast linking,
currently we compile the variants but delay emitting the commands until
link time, but note that even the Gallium driver doesn't currently do
this. Given the strict SSO model (e.g. with separate VPC registers for
each stage) it may even be possible to do most of the linking ahead of
time with only a few fixups for corner cases.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18554>
Right now, we pass around the push constant state in a lot of places,
but we'll want to add other driver-managed constants. Add a struct which
we can add to, and separate out the total driver-reserved constants from
the size of push constants.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18554>
With pipeline libraries, computing this might have to be delayed because
it depends on multiple pieces of state and there's no way to disentangle
them. Therefore we have to store the requisite state in the pipeline and
combine it later.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18554>
The other state in this register comes from the FS, so determine whether
dual-source blending is enabled from the FS too, in order to avoid
entangling FS state and output state that with graphics pipeline library
can be in different pipelines.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18554>
If there are disabled attachments that are nevertheless written to, they
should already be disabled in the blend state, via the same mechanism as
color_write_enable, so there should be no reason to mix the FS state and
blend state like this. This helps unentangle state that in graphics
pipeline library can be provided in different pipelines.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18554>
This means it has to be rederived rather than passed from the place
where we actually do the optimization, but it eliminates the clutter of
having to pass it around in turnip, which will only get worse with
graphics pipeline libraries.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18554>
In the compiler, this was only used to replace some inputs in the
non-MSAA case which apparently no longer need to be replaced anymore,
probably because we clarified some registers related to them and started
setting them better. In the pipeline libraries case we may not have
access to the sample locations state when compiling the FS (although we
do know whether sample shading is enabled), so this removes a
problematic state dependency in turnip.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18554>
With pipeline libraries, we may not know the HW primtype if the user
passes a primtype of PATCHES because the tess shaders and input assembly
state may be in different pipelines. We need to split out the patch
control points and only determine the final primtype once everything has
been merged. In preparation for this, and for dynamic patch control
points, calculate the final primtype dynamically. We already had a
draw-time workaround for dynamic primtype we can now remove, so this
actually reduces the amount of draw-time work we have to do anyway.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18554>
This wasn't taking into account the dynamic primitive topology, and it
was suboptimal with dynamic rendering, because we don't know when
compiling the pipeline whether variable multisample rate is being used.
It's going to be even more difficult to support the current approach
with graphics pipeline library because the MSAA state is derived from
mulisample state, rasterization state, input assembly state, and
tessellation state, which may be in different pipelines. Just set it
dynamically based on the pipeline and re-emit it when the pipeline's
MSAA or rectangular/bresenham state differs.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18554>
We weren't setting it in the CmdClearAttachments case. With this, we can
stop setting it in tu6_emit_msaa(), which only happened to work and
would break things in the next commit when we move it to a draw state.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18554>
Some CTS tests, in particular,
dEQP-VK.pipeline.pipeline_library.graphics_library.misc.independent_pipeline_layout_sets.*,
do the following:
1. Create a pipeline with a vertex input struct that defines a single
attribute pointing to vertex buffer #0, but a vertex shader that
doesn't use any attributes.
2. Bind the pipeline, but don't call vkCmdBindVertexBuffers(), then
draw.
Other drivers handle this just fine because the vertex input registers
are never used. However we have an optimization in turnip where we
pre-calculate the size of the vertex buffer draw state when the vertex
input draw state is bound, which results in a vertex buffer draw state
with non-zero size but zero iova, resulting in hangs. While it's
questionable whether this is allowed, it's easy enough to just disable
the draw state in that case.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18554>
This fixes some flakes with
dEQP-VK.pipeline.monolithic.multisample.alpha_to_coverage_unused_attachment.samples_2.alpha_opaque
on a650 with some other patches on top. I believe this is also the
source of the flakes on a630.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18554>
When the main FS needs sample positions and the number of samples
isn't known at compile time with GPL.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18677>
Use two different paths (static vs dynamic) to avoid running more NIR
pass to remove dead CF code when static is used.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18677>
This will be used to load the number of rasterization samples when a
fragment shader is compiled inside a library without the MSAA state.
RADV needs to know the number of samples for loading sample positions
with interpolateAtSample().
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18677>
With GPL, it's possible to build the main FS without the multisample
state, but the number of rasterization samples is required for
lowering interpolateAtSample(). In this rare situation, the number of
samples will be passed through a new user SGPR.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18677>
AMDGPU pstate is per-device, not per Vulkan logical devices. The same
AMDGPU device is shared accross logical devices because the driver
creates only one winsys per fd. The kernel only allows one context
at a time per AMDGPU device, otherwise it returns -EBUSY.
Fixes this by acquiring pstate on-demand to avoid this multiple
logical device problem.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Tatsuyuki Ishi <ishitatsuyuki@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17712>
Setting pstate is used for RGP captures and performance counters, so
this name is more generic. Also make it non static.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Tatsuyuki Ishi <ishitatsuyuki@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17712>
