Now that the negative lodbias bug is fixed we can expect tests
using this to pass.
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/28224>
The hand rolled etnaviv conversion functions were able to handle
negative input values when converting to fixpoint. By replacing
them with U_FIXED all negative values are clamped to zero, which
breaks usages where negative inputs are valid, like lodbias.
Fixes: 8bce68edf5 ("etnaviv: switch to U_FIXED(..) macro")
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/28224>
This is a known bug in CTS affecting a number of tests in the
renderpass, renderpass2 and dynamic_rendering categories, but
it seems this is the only one triggered by CI. The bug has been
fixed in CTS 1.3.7.3.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27978>
These start executing with dynamic rendering, and despite the name,
they don't actually require shader object. The reason they fail
is a bug in CTS (main).
Note: these are a crash in CI, but in CTS main they are a Fail.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27978>
We want these as skips instead of fails because there are many tests involved
and not all of them fail, so every time we add a new feature and change the
subset of tests we run in CI we start hitting different tests and we have
to keep patching the list, so just move them to skips since we know we don't
support them and we should not be running them.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27978>
With dynamic rendering secondary command buffers can start subpasses
so we need this. Outside dynamic rendering secondary command buffers
won't be calling here since they are restricted to record commands
within a subpass.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27978>
If a secondary command buffer recording a dynamic pass has the
VK_COMMAND_BUFFER_USAGE_RENDER_PASS_CONTINUE_BIT flag
then the rendering information for it should come from a
VkCommandBufferInheritanceRenderingInfo struct in the pNext
chain instead of the usual render pass information in the
VkCommandBufferInheritanceInfo struct. We take the information
from the new struct and build a render pass description from it
assuming a setup without a framebuffer (which is optional for
regular render passes too).
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27978>
Because we are cloning these into primaries but the cloning is
superficial the command lists in them still point to the original
jobs and therefore paching new addresses would make the packing
code add the BO of the resume address to the original job. This
has two problems:
1. This is probably not what we want since the patching should only
be affecting the clone.
2. The bo_count of the clone job will not be updated accordingly and
we end up with a mismatch that will blow up when we submit.
The solution used here is a big hack, but works for now: we just
specify the address by its full offset rather than a relative
offset from a BO. We already have to add all the BOS in the resume
job manually which will include this the BO for the branch address
too, so this is fine.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27978>
This was used only in secondary CL command buffers so it made
sense but with dynamic rendering we are going to also have
regular CLs also in secondaries (since secondaries can now
record full dynamic rendering passes), so renaming this to
INCOMPLETE makes more sense, since this is really what they
refer to: parts of CLs that are intended to be merged into
other primaries through branching.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27978>
Dynamic rendering allows the client to suspend recording of a
render pass and have it continued in a different command buffer.
When a suspended command buffer is submitted to a queue, the
resuming command buffer must be te next one in submission order.
This means we need to be able to "merge" or "stitch" together
these command buffers at submit time.
To accomplish this, when we suspend a command buffer we emit
a BRANCH instruction to finish it. Then at submit time, when
we know the resuming job, we patch the BRANCH address with the
address of the resuming binning list (bcl). This is very similar
to how we execute secondary command buffers inside a render pass.
Also, only the last resuming job should flush the binning lists
in the bcl since we won't have processed the full binning command
list until we have execute the last linked job in the resume
list.
Since all jobs and command buffers in the suspend/resume chain
must be part of the same dynamic render pass, we only need to
produce and emit the render command list (rcl) once.
Since the way we implement stitching is that we branch from the
suspending job into the resuming one, the first job suspending
will link into all the resuming jobs necessary to complete the
chain, therefore, after the stitching is complete, we only want
to submit the first job in the suspend/resume chain, and thus,
we only produce and emit the rcl for this one job.
Notice as well that suspending only affects the last job
recording a dynamic rendering pass (the one that needs the branch
so we can resume execution with another job in another command
buffer).
Resuming affects all jobs in the dynamic render pass, since
we won't produce RCLs for them (as only the originating job
on the suspend/resume chain will emit the RCL).
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27978>
With this we are able to run basic dynamic render passes, however,
we are still missing a few things like support for secondary
render passes, suspend/resume, etc that will be adding in follow-up
patches.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27978>
This builds up on the previous patch and rewrites all the pipeline
code that fetched information from the pipeline's render pass (which
will be NULL for dynamic rendering) to instead fetch it through the
new rendering_info field, which will be valid for both regular and
dynamic render passes.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27978>
With dynamic rendering the API formally eliminates render passes,
so the pipeline create info can now have a NULL render pass, in
which case rendering info must be provided via pNext struct
VkPipelineRenderingCreateInfo, or if this is missing too then
defaults to no multiview and no attachments.
Since we don't want to have separate paths all over the place
whenever we need to access render pass / rendering info for the
pipeline, we will always produce a valid vk_render_pass_state
struct with the relevant information even when we have a render
pass, so we can rely on that always being available.
A follow-up patch will rewrite all the places where we assumed
the existence of a render pass in the pipeline to instead fetch
the info it needs from this new field instead.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27978>
Since the plan is to leverage our render pass infrastructure, we
also need to setup a framebuffer from the rendering info provided
with dynamic rendering.
We allocate the framebuffer lazily, only once, if a dynamic render
pass is used. To do this, we make it so it can hold the maximum
number of attachments possible with our hardware.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27978>
The idea is to build a regular render pass from the rendering info
provided with dynamic rendering. We will use this when recording
dynamic render passes to leverage our existing implementation
for render passes with dynamic rendering.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27978>
It is allowed for a shader to enable the multiview extension
even if the draw call in which it is used doesn't use multidraw.
This allows the shader to still use gl_ViewIndex, which will
always be 0 in that scenario.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27978>
The number of samples should be the rasterization samples and not the
framebuffer samples.
Fixes recent dEQP-VK.query_pool.occlusion_query.no_attachments_*.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28198>
GLCTS contains more recent dEQP, so we can remove the deqp clone.
Changes:
- glcts should use the main branch
- glcts/build contains gl-cts and deqp
- glcts/build_es contains gles-cts
- remove the escts and deqp directories and paths
- it saves about 27 GB of disk space
Updated build instructions:
https://github.com/marekolsak/marek-build/
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28219>
These have been incredibly useful when debugging regressions and weird
behavior in the Intel backend when trying to spill multiple registers
before retrying allocation. With them, we can print out not only what
register was chosen, but the benefit and cost. Seeing lists of chosen
registers where the benefit/cost was not sorted, and poor options were
chosen before better ones, led me to investigate a number of issues.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28257>
We also need the BV/LPAC info, so run the entire thing until we get to a
waitin or read $data without waitin, which the BV microcode does
because it is disabled by default and skips everything until a
CP_THREAD_CONTROL packet.
The actual microcode writes the packet table last, but my simple test
one doesn't, and there's no guarantee it will continue to do so.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26771>
This is similar to a7xx but slightly different, because it inverts the
sense of the bits (the firmware sets to 1 once it starts) and there are
only 2 processors. We didn't need this before because the waiting on
THREAD_SYNC only happens after setting the packet table.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26771>
This frees us from having to strip the trailing colon, and makes it
easier to add other identifiers like for section names. The downside is
that now we can't name a label with a reserved word like "mov" but that
doesn't seem too bad.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26771>
Some a7xx firmwares have junk after the LPAC jump table, and the old
method of hardcoding the location of the jumptable and the jumptable
offset when assembling and disassembling also doesn't work well on a7xx
where the location of the jumptable offset changes. Make jump tables
explicit in the disassembly with a ".jumptbl" directive which expands to
contain the contents of the jump table, make disassembly find the jump
table and emit the directive there. Then add the ability for a literal
to reference a label, which will be used for the jump table offset at
the beginning of the firmware. The disassembler guesses when a word is
actually the jump table offset and replaces it with a relocation.
This restores the ability to disassemble a630_sqe.fw and a650_sqe.fw and
reassemble to an identical binary without modifying the disassembly to
remove the jump table.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26771>
For whatever reasons this has been known in rnndb for ages, but
never was hooked up in the driver. Do so now.
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/28218>
