Will allow the driver to know if the vertices count is dynamic.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34109>
Take the opportunity to reuse the backend pass.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34109>
Already handled by having a special range created
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34109>
This has no effect on triangles because max 64 patches implied max 192
threads, but it improves performance for cases when the number of threads
per patch is > 3.
This improves the score for gfxbench5 "gl_tess_off" (offscreen) by 11%
on Navi48.
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34863>
All of the GPU renderstage events show a command buffer id/name field in
the UI (default 0/NULL), so let's get it filled with something useful.
This will also be used by perfetto's trace processor for associating
object names with cmdbuf executions.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22350>
This means the perfetto UI will have a non-zero/NULL handle/name in the UI
on these renderstages. Unfortunately, intel/ds is outside of vulkan so
unless we pull in anv headers, we can't just pass in the anv_cmd_buffer.
This also means it would be much more painful to pass the cmd buffer to
the rest of the events, so they'll still have unset command buffers.
Still, being able to see the name of the command buffer in at least one of
the events should be useful once that's glued together.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22350>
You need to re-emit name interning when incremental state is lost, so this
is the right home for the HT of "have we interned this name?". The
emitter function is still on the datasource because it needs the
templating to get the tracecontext type, but now getting the locked
datasource is not really necessary other than being way more ergonomic
than repeating the template parameters.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22350>
Given that the command buffer will be long-lived, no reason not to just do
this so that debugging tools can see what the cmdbuf is doing.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22350>
The spec text here is:
Image Type must be an OpTypeImage. It is the type of the image in the
combined sampler and image type. It must not have a Dim of SubpassData.
Additionally, starting with version 1.6, it must not have a Dim of Buffer.
For older SPIR-V versions, there is no analogous requirement. It is implicitly
valid to use a Dim of Buffer (even though it doesn't make much sense). Should
apps do it anyway? Probably not, but it doesn't matter and they do.
glslang considers this requirement relevant only for 1.6+:
if (glslangIntermediate->getSpv().spv >= glslang::EShTargetSpv_1_6 &&
texType.getSampler().isBuffer()) {
// SamplerBuffer is not supported in spirv1.6 so
// `samplerBuffer(textureBuffer, sampler)` is a no-op
// and textureBuffer is the result going forward
constructed = arguments[0];
} else
constructed = builder.createOp(spv::OpSampledImage, resultType(), arguments);
That means SPIR-V with an older declared version will warn even with a glslang
new enough to know about the 1.6 requirement. That includes a *lot* of SPIR-V's
built with the CTS.
I see no compelling reason to keep the warning for older than 1.6. Removing the
spurious warning silences a *huge* amount of noise from dEQP-VK (plus a bit from
KHR-GL46). In exchange I see very little tradeoff, it's not really our job to
lint for best practices not in the spec.
I see two viable options:
1. Try to convince the whole ecosystem outside of Mesa to pivot to our pedantic
reading of the spec and get them to update all the old SPIR-V binaries in the
wild, in the case of CTS being changed at the glslang level and then
trickling down into CTS.
2. Merge this patch, simplifying Mesa and immediately forget about this forever.
I'm spending all my FOSS political capital on kernel upstreaming so I have a
strong preference for #2, aka hitting Marge on this MR and then moving on with
all of our lives.
("Ignore the problem and make deqp-runner annoying to use" is the secret 3rd
option I'd rather not do.)
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34847>
They have been preventing merges, so documenting them in the hope that
the next attemot will be more successful.
Signed-off-by: Martin Roukala (né Peres) <martin.roukala@mupuf.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34795>
We named these jobs like this despite b2c being an implementation
detail because we did not have a name for this bare-metal infra.
Now that we do (CI-Tron), let's rename the jobs to remove the
confusion.
Co-authored-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34795>
This makes it easier to debug inheritance issues like the one fixed
earlier in this series, and makes it easier to reproduce a job without
needing more than looking at the job log.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34795>
Up until now, every project using CI-Tron had to write their own job
submission flow because CI-Tron itself was not providing any official
way of interacting with it via GitLab.
This however changed, and the solution is vastly superior to what we
have been using in Mesa:
* Ability to pass all the environment variables of the job to the DUT,
so no need to remember to add variables in
`export-gitlab-job-env-for-dut.sh` anymore
* No dependency on Mesa code, which means no need to wait on
python-artifacts and the ability to replicate a run by just copying
the job description outputted by the job \o/
* Ability to have as many initrd, HTTP, and TFTP artifacts as wanted
* Ability to expose a variable through a TFTP/HTTP endpoint or as an
initrd
* Ability to overwrite the platform environment (machine-specific FW)
* Ability to have as many kernel cmdline variables, all merged when
generating the final cmdline. This makes it easy to share some
snippets of cmdline between jobs
Transitioning from the custom to the generic template is however pretty
involved. This commit does the minimum changes needed to switch to the
new model, often simply replacing the B2C_ prefix with CI_TRON_.
Further renaming of "b2c" prefixes into "ci-tron" is left for future
commits.
Co-authored-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34795>
