mesa merge requestshttps://gitlab.freedesktop.org/mesa/mesa/-/merge_requests2024-03-27T13:06:51Zhttps://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28407Draft: vtn: stop validating caps2024-03-27T13:06:51ZAlyssa RosenzweigDraft: vtn: stop validating capsWhen we -- and as usual, by "we" I mean Faith -- first added SPIR-V support to
Mesa, the landscape looked pretty different:
* there were very few caps
* there were very few drivers consuming SPIR-V
* the VVL was young and not used unive...When we -- and as usual, by "we" I mean Faith -- first added SPIR-V support to
Mesa, the landscape looked pretty different:
* there were very few caps
* there were very few drivers consuming SPIR-V
* the VVL was young and not used universally
As such, it made a reasonable amount of sense to collect cap lists in every
Vulkan driver and validate them in vtn, to help check for app bugs.
Things look different today. We now have lots of caps, lots of drivers, and a
competent VVL that has the responsibility of making sure apps don't declare any
caps that the underlying driver doesn't actually support.
So, rip out the validation so we can stop burdening every driver individually
with this. The alternative would be to auto-generate the validation code -- and I
do have patches to get Mesa most of the way there as a fallback -- but you know
who else has that code? The VVL. It's not Mesa's job to validate Vulkan usage,
and we're totally justified in dropping this pile of stuff.
OpenGL SPIR-V seems to me to be DOA so I'm not at all concerned about the loss
of coverage there.
The one open question I have about this plan is the implications for OpenCL.
That said, I'm not too worried in practice... we have just one source of
in-the-wild CL-flavour SPIR-V (Rusticl), with just a few relevant caps compared
to the larger number of graphics caps. If we need to for Rusticl only, we can
add back just a bit of validation as a treat.https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28396anv: only check patch_control_points changes in runtime flush2024-03-26T14:02:29ZLionel Landwerlinanv: only check patch_control_points changes in runtime flush### What does this MR do and why?
<!-- Describe in detail what your merge request does and why. -->
Just a small cleanup### What does this MR do and why?
<!-- Describe in detail what your merge request does and why. -->
Just a small cleanuphttps://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28348Teach the various `_clc` tools how to generate a dep file2024-03-28T02:45:11ZDylan BakerTeach the various `_clc` tools how to generate a dep file### What does this MR do and why?
```
This teach the various `_clc` build tools how to generate a dependency
file that Meson can point Ninja at. The result is that we need to do
less manual tracking of dependencies, as `intel_clc` and...### What does this MR do and why?
```
This teach the various `_clc` build tools how to generate a dependency
file that Meson can point Ninja at. The result is that we need to do
less manual tracking of dependencies, as `intel_clc` and friends can
simply tell Ninja what headers they imported, and ninja can track
those automatically.
```Dylan BakerDylan Bakerhttps://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28347anv/xe: improve error handling for the vm_bind ioctl2024-03-28T03:52:46ZPaulo Zanonianv/xe: improve error handling for the vm_bind ioctlThis MR is the result of a long conversation I had with @thomash regarding vm_bind error handling. We can do better under memory pressure situations, so that's what the series tries to do.
It was also agreed that `xe.ko` would slightly ...This MR is the result of a long conversation I had with @thomash regarding vm_bind error handling. We can do better under memory pressure situations, so that's what the series tries to do.
It was also agreed that `xe.ko` would slightly improve error reporting for the `vm_bind` ioctl, so the last patch addresses that. Given the nature of the change, it should be possible to merge our side even before `xe.ko` merges its change. Still, it would be nice to receive a ping from @thomash when it happens.
Cc: @zehortigoza our `xe.ko` backend specialist.Paulo ZanoniPaulo Zanonihttps://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28310Revert "anv: Enable EXT_swapchain_maintenance1"2024-03-21T14:34:46ZMark JanesRevert "anv: Enable EXT_swapchain_maintenance1"```
Revert "anv: Enable EXT_swapchain_maintenance1"
This reverts commit 145ab5b853d8ce7d47f6e9e66e74e03b501bff68.
Fixes: #10859
``````
Revert "anv: Enable EXT_swapchain_maintenance1"
This reverts commit 145ab5b853d8ce7d47f6e9e66e74e03b501bff68.
Fixes: #10859
```https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28299anv: Create protected engine context when i915 supports vm control2024-03-22T00:55:32ZJosé Roberto de Souzaanv: Create protected engine context when i915 supports vm control### What does this MR do and why?
When has_vm_control is supported it takes a different code path and
creates one context per engine and in this code path we were not
setting the protected context flag.### What does this MR do and why?
When has_vm_control is supported it takes a different code path and
creates one context per engine and in this code path we were not
setting the protected context flag.https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28282Draft: anv: Low latency hint for the workloads2024-03-26T14:42:27ZSushma Venkatesh ReddyDraft: anv: Low latency hint for the workloads### What does this MR do and why?
Sync i915_drm.h with commit cec82816d0d0 ("drm/i915/guc: Use context hints for GT frequency") and the implementation to utilize I915_CONTEXT_PARAM_LOW_LATENCY.### What does this MR do and why?
Sync i915_drm.h with commit cec82816d0d0 ("drm/i915/guc: Use context hints for GT frequency") and the implementation to utilize I915_CONTEXT_PARAM_LOW_LATENCY.https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28212anv, vulkan: add support for P010 sampling2024-03-26T00:59:38ZChia-I Wuanv, vulkan: add support for P010 sampling`P010` maps to `VK_FORMAT_G10X6_B10X6R10X6_2PLANE_420_UNORM_3PACK16` in Vulkan. anv treats the planes as `R16` and `R16G16` and supports sampling. IIUC, the only caveat is, while `P010` requires the lower 6 bits to be 0, `VK_FORMAT_G10...`P010` maps to `VK_FORMAT_G10X6_B10X6R10X6_2PLANE_420_UNORM_3PACK16` in Vulkan. anv treats the planes as `R16` and `R16G16` and supports sampling. IIUC, the only caveat is, while `P010` requires the lower 6 bits to be 0, `VK_FORMAT_G10X6_B10X6R10X6_2PLANE_420_UNORM_3PACK16` requires us to ignore the lower 6 bits.
The first 2 commits extend `nir_vk_lower_ycbcr_tex` to support masking out the lower bits. The third commit enables `P010` support in anv. The last commit advertises DRM modifier support for all supported ycbcr formats.
/cc @linyaahttps://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28190anv: allow TR-TT for compute and copy contexts2024-03-25T16:45:22ZPaulo Zanonianv: allow TR-TT for compute and copy contextsThese patches enable TR-TT for the compute and copy contexts. This should work on LNL and the first 4 patches do it on LNL, but patch 5 also does it for Gen12+ (DG2 and MTL, in practice).
The Gen12 patch is marked as RFC. On DG2 I'm see...These patches enable TR-TT for the compute and copy contexts. This should work on LNL and the first 4 patches do it on LNL, but patch 5 also does it for Gen12+ (DG2 and MTL, in practice).
The Gen12 patch is marked as RFC. On DG2 I'm seeing some random test failures which I'm not 100% sure are caused by this or related to this, so I'll keep working on them. In the meantime, patches 1 to 4 could be merged after review.
Also notice that LNL is only supported by xe.ko so it's not using TR-TT by default (it's using vm_bind), so to test this on LNL you'll need `ANV_SPARSE_USE_TRTT=1`.Paulo ZanoniPaulo Zanonihttps://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28184anv: disable fcv optimization on gfx1252024-03-21T10:51:11ZTapani Pällianv: disable fcv optimization on gfx125```
anv: disable fcv optimization on >= gfx125
Earlier strategy was to enable always on DG2 but there has been bunch of
issues that indicate this feature is not working correctly. Disable
until we figure out issues with it.
Cc:...```
anv: disable fcv optimization on >= gfx125
Earlier strategy was to enable always on DG2 but there has been bunch of
issues that indicate this feature is not working correctly. Disable
until we figure out issues with it.
Cc: mesa-stable
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
```https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28054ci: run vulkaninfo on drm-shim and store the output2024-03-09T00:12:03ZEric Engestromeric@engestrom.chci: run vulkaninfo on drm-shim and store the outputThis has two benefits:
- it ensures no regression in exposed features can get merged unnoticed
- it allows much more detailed and accurate information than
`docs/features.txt`, and having this information auto-generated means it
can ...This has two benefits:
- it ensures no regression in exposed features can get merged unnoticed
- it allows much more detailed and accurate information than
`docs/features.txt`, and having this information auto-generated means it
can no longer get out of date or have mistakes with less effort
required from developers.
---
Of all the VK drivers:
~lavapipe, ~turnip, ~ANV, ~hasvk, ~RADV, ~NVK are added.
~v3dv and ~panfrost should be supported, but I couldn't figure out how to make their respective drm-shim to work on vulkan; please help :)
~dozen and ~powervr don't have a drm-shim so they can't be supported (yet).
~venus I'm not sure how it would work, but I'm guessing it would be a cross-product of venus over each of the possible underlying driver? I'm not sure how this would be tested in CI, so I'm also leaving it out for now.https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27909anv: add an option to disable EXT_descriptor_buffer with TRTT2024-03-01T10:11:10ZLionel Landwerlinanv: add an option to disable EXT_descriptor_buffer with TRTT### What does this MR do and why?
<!-- Describe in detail what your merge request does and why. -->
Another case where we have to be careful with TRTT.
In theory we're not spec compliant with both features enabled, but I doubt apps are...### What does this MR do and why?
<!-- Describe in detail what your merge request does and why. -->
Another case where we have to be careful with TRTT.
In theory we're not spec compliant with both features enabled, but I doubt apps are going to use sparse descriptor buffers much.https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27873anv: increase maxResourceDescriptorBufferRange on DG2+2024-02-29T07:47:23ZLionel Landwerlinanv: increase maxResourceDescriptorBufferRange on DG2+### What does this MR do and why?
<!-- Describe in detail what your merge request does and why. -->
```
anv: increase maxResourceDescriptorBufferRange on DG2+
The current helper anv_physical_device_bindless_heap_size()
artificially lim...### What does this MR do and why?
<!-- Describe in detail what your merge request does and why. -->
```
anv: increase maxResourceDescriptorBufferRange on DG2+
The current helper anv_physical_device_bindless_heap_size()
artificially limited the surface heap size on DG2+ to 128MB. The HW is
actually 4GB capable, but we have workaround requiring to overlap the
dynamic state heap with the bindless surface state heap.
The actual limit comes from our virtual address space setup. It is
different between descriptor buffers and regular descriptors.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: fe037dec6e ("anv: expose VK_EXT_descriptor_buffer")
```
/cc @ibrianohttps://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27810Draft: Support H264/H265 encoding on ANV2024-03-05T07:16:20ZHyunjun KoDraft: Support H264/H265 encoding on ANVStill needs to fix some issues but welcome comments in general.
- H264
- Support CQP mode only.
- VDENC(Low power encoding) only.
- Tested on gen9(CometLake) and gen12(AlderLake-P)
- Issues
- Cr channel not encoded...Still needs to fix some issues but welcome comments in general.
- H264
- Support CQP mode only.
- VDENC(Low power encoding) only.
- Tested on gen9(CometLake) and gen12(AlderLake-P)
- Issues
- Cr channel not encoded.
- H265
- Support CQP mode only.
- VDENC(Low power encoding) only.
- Tested on gen12(AlderLake-P),
- Issues
- The output of P frame encoding has small artifacts sometimes.
- Need to test on gen11.Hyunjun KoHyunjun Kohttps://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27803anv: enable EDS3 AlphaToCoverageEnable2024-02-27T10:12:22ZLionel Landwerlinanv: enable EDS3 AlphaToCoverageEnable### What does this MR do and why?
<!-- Describe in detail what your merge request does and why. -->
```
anv: enable EDS3 AlphaToCoverageEnable
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Closes: https://gitlab.free...### What does this MR do and why?
<!-- Describe in detail what your merge request does and why. -->
```
anv: enable EDS3 AlphaToCoverageEnable
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10647
```https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27773anv: Enable async compute and blit when Sparse TRTT is not used in i9152024-03-25T21:34:32ZJosé Roberto de Souzaanv: Enable async compute and blit when Sparse TRTT is not used in i915### What does this MR do and why?
Sparse TRTT and async compute and blit are not compatible but if no queue is created with VK_QUEUE_SPARSE_BINDING_BIT, enable the usage of compute and copy engines.
This is a different approach to https...### What does this MR do and why?
Sparse TRTT and async compute and blit are not compatible but if no queue is created with VK_QUEUE_SPARSE_BINDING_BIT, enable the usage of compute and copy engines.
This is a different approach to https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27620
Not much tested yet but crucible is passing(with this fix https://gitlab.freedesktop.org/mesa/crucible/-/merge_requests/149) and was able to validate that some https://github.com/SaschaWillems/Vulkan tests where using compute engine.https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27717Draft: anv, hasvk: more common physical device properties2024-02-23T09:35:57ZOskar ViljasaarDraft: anv, hasvk: more common physical device properties### What does this MR do and why?
Depends on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26386, marking this MR draft so we can merge this after
- get rid of the GPDP2 entrypoint in anv, as https://gitlab.freedesktop.org/...### What does this MR do and why?
Depends on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26386, marking this MR draft so we can merge this after
- get rid of the GPDP2 entrypoint in anv, as https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26386 adds support for VkPhysicalDevicePresentationPropertiesANDROID
- move hasvk over to the common physical device infrastructure, mirroring the code structure in anv
I did test hasvk (not the android part though), but I don't have any anv hardware available, nor did I have any practical way to compile-test the anv change.https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27659anv: report non-Intel vender if xess loaded2024-02-20T17:52:38ZFelix Degroodanv: report non-Intel vender if xess loadedAvoids XeSS crash on Intel with Proton by faking non-Intel vendorID when XeSS detected. Only expected to work on traditional linux environment that save per-proc information in /proc dir.Avoids XeSS crash on Intel with Proton by faking non-Intel vendorID when XeSS detected. Only expected to work on traditional linux environment that save per-proc information in /proc dir.Felix DegroodFelix Degroodhttps://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27543anv/ci: add WSI testing to all the deqp-vk jobs2024-02-09T15:55:11ZEric Engestromeric@engestrom.chanv/ci: add WSI testing to all the deqp-vk jobshttps://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27505anv: implement Wa_140108401762024-03-14T11:17:52ZLionel Landwerlinanv: implement Wa_14010840176### What does this MR do and why?
<!-- Describe in detail what your merge request does and why. -->
Should close https://gitlab.freedesktop.org/mesa/mesa/-/issues/9899
Waiting for our CI to come back online to have this tested properly.### What does this MR do and why?
<!-- Describe in detail what your merge request does and why. -->
Should close https://gitlab.freedesktop.org/mesa/mesa/-/issues/9899
Waiting for our CI to come back online to have this tested properly.