A proper emulation of a second queue requires handling of
wait-before-signal behavior of timeline semaphore. It's doable in Venus
but not that much useful since 1.4 requires a second transfer queue
family if not implementing hostImageCopy. So this change has limited
the second queue emulation as a workaround for android framework on
Android 14 and above.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33698>
There is a spec issue about this to clarify this behavior, but the current
wording can be interpreted that the platform always lists all extensions
supported by all drivers.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33667>
We'll want to disable some support for software detiled accesses on
sparse 64bit images because we'll pick a single optimized tiling for
shader detiling which is not going to be block shape compliant for
sparse resources.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32676>
We're about to introduce R64_(S|U)INT support for some images. This
will use a different HW format than what we want for VBOs.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32676>
The expectations are :
- no MSAA images
- a single tiling mode is used when not linear
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32676>
For shader detiling, it's useful to know if we avoid bothering trying
to detile a 1D image.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32676>
Only look for sample location info when MSAA state is valid.
Test: dEQP-VK.api.pipeline.pipeline_invalid_pointers_unused_structs.graphics
Fixes: ff64092ff3 ("venus: support VK_EXT_sample_locations")
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33696>
This is surprisingly not caught by maint6 tests or the entire
binding_model group.
Fixes: 0fa2758103a ("venus: support VK_KHR_maintenance6")
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33695>
This change:
- adds the core 1.4 support
- handles partially promoted dynamicRenderingLocalRead feature
- properly scrubs host copy related features and properties if needed
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33690>
What we need is a way to tell GitLab "queue `build-only` jobs after
`build-for-tests` jobs have started", to make sure that `build-only`
jobs don't start before `build-for-tests` jobs and thus delays test jobs
and the overall pipeline.
The best I had found was "queue `build-only` jobs after *all* the
`build-for-tests` jobs have finished", but this introduces a larger
delay than we want, and causes `build-only` jobs to often be the last
ones to finish in a pipeline, after test jobs that respect the 15min
runtime limit.
Instead, we can tell GitLab "queue `build-only` jobs after the
`build-for-tests` jobs have been queued for X minutes", which is closer
to what we want, and in particular this ensures the correct order of
*starting* jobs as long as the CI is not overwhelmed and doesn't manage
to actually start a queued `build-for-tests` job within 5min, in which
case I'd argue we don't care about job order anymore because we have
bigger problems anyway and likely everything's going to timeout.
This also gets rid of the hard-to-maintain `.build-for-tests-jobs` list
of `needs:`, which also needed to be manually merged in half the jobs.
The trade-off is that we need to make a (shallow) copy of the
`.container+build-rules` list, that replaces all the `when: on_success`
with `when: delayed` + `start_in: 5 minutes`. This means that we'll need
to make sure the two lists of conditions remain identical, but this
seems more manageable; nevertheless, I added a comment to remind us.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33564>
This is a debug feature that we kind of manage in the driver atm. It's
better that we move this completely to the compiler and can load it
from the cache.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Michael Cheng <michael.cheng@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33643>
