This is especially for p010 format, which isn't supported for YCbCr
conversion yet.
Signed-off-by: Hyunjun Ko <zzoon@igalia.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22202>
Only for video 10-bit hevc decoding, so shouldn't enable such as YCbCr
conversion.
v1. Fix to avoid YCbCr CTS tests for this format.
( Lionel Landwerlin <lionel.g.landwerlin@intel.com> )
v2. Add a flag can_video so we could handle supported video formats
neatly.
( Lionel Landwerlin <lionel.g.landwerlin@intel.com> )
Signed-off-by: Hyunjun Ko <zzoon@igalia.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22202>
We need compression tracking for full resolves and at the moment only
CCS_E has full resolves.
Signed-off-by: Rohan Garg <rohan.garg@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22737>
Most of the compressed writes are tracked by the driver, for
instances :
- blorp writes
- render target writes
But we don't have any tracking for storage images (which have gained
compression support on DG2+). So inspect the layout transition and
when we see a layout/access that can do writes outside of our driver
tracking, update the image state tracking.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8946
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22988>
Not doing so all the reads/writes go to the scratch page on i915.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: f9fa09ec92 ("anv/image: Add ANV_IMAGE_MEMORY_BINDING_PRIVATE")
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22957>
Instead of checking if the very same bit we want to enable is already
enabled, which obviously doesn't work.
Fixes: fbc0e74bda ("anv: enable graphics pipeline libraries by default")
Acked-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23039>
Refactor framebuffer to renderpass to mirror previous INTEL_MEASURE
changes.
We dump hashes/pointers for shaders and framebuffer/renderpass.
Reduce from 64bit to 32bit pointers. We don't benefit from the
extra precision and reduced output size is convenient.
Reviewed-by: Mark Janes <markjanes@swizzler.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22723>
Per-RenderTarget analysis was removed from anv's INTEL_MEASURE
previously, probably after switching to dynamic rendering model.
Restore capability by tracking count of beginRenderPass calls.
Reviewed-by: Mark Janes <markjanes@swizzler.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22723>
Up until now, we have been initializing MCS with fast clears. This is
mostly safe, but there's a corner case that can be an issue.
The issue is with a workaround for MCS that requires the sampler not see
any fast-cleared blocks for certain surfaces (14013111325). Even though
we have been initializing MCS with fast clears, we expect most
applications to be safe because we expect that they would only sample
the samples they've rendered to previously (and the render would've
removed the fast-cleared blocks). In other words we don't expect that
apps would transition from VK_IMAGE_LAYOUT_UNDEFINED to
VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL and start sampling immediately.
If an application took the unexpected path of sampling undefined
samples, it's possible they'd hit the issue described in the workaround.
Fix this corner case by using an ambiguate to initialize MCS.
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22545>
The comment above the warning explains that not all bit patterns are
necessarily valid. While we're at it, fix a typo in that comment.
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22545>
With the shader cache enabled, intel_clc attempts to write to ~/.cache.
Many distributions' build systems limit file-system access, and will
kill the process thus causing the build to fail.
Fixes: 639665053f ("anv/grl: Build OpenCL kernels")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22968>
anv_ahb_format_for_vk_format needs to know the format at least. There
is no guarantee that AHardwareBuffer_allocate will succeed, but we are
reluctant to check with AHardwareBuffer_isSupported which may
test-allocate internally and is expensive.
v2: add anv_ahb_format_for_vk_format to anv_android_stubs.c
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22619>
When allocating a VkDeviceMemory exportable as AHB, it seems incorrect
to fall back to AHARDWAREBUFFER_FORMAT_BLOB when the image has no known
AHB format. We should fail the allocation instead.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22619>
Due the lack of APIs to set mmap modes, Xe KMD can't support the same
memory types as i915.
So here adding a i915 and Xe function to set memory types supported
by each KMD.
Iris function iris_xe_bo_flags_to_mmap_mode() has a table with all the
mmaps modes of each type of placement.
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22906>
We're missing it for the memcpy with streamout
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 5cc4075f95 ("anv, iris: Add Wa_16011411144 for DG2")
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22930>
This reverts commit 5489033fa8.
The problem I was trying to address is that we were programming the
3DSTATE_PS::PositionXYOffsetSelect bit differently with GPL (CENTROID)
than without (NONE).
I failed to understand that this bit also impacts the thread payload
layout. GPL fragment shaders don't know ahead of time if pos_offset is
going to be used. It'll be choosen at runtime base on push constant
bits. So we need to program this bit different just to have a payload
matching the compiled shader code.
This fixes the freedoom replay with GPL FS shader in SIMD32.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Acked-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22938>
This is necessary to make anv work with clients like VA-API which relies
on implicit fencing only. The bahavior matches iris i915_batch_submit.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22937>
Since we are disabling mesh, which has issues with gpl, enable gpl by
default now, leaving the renamed environment variable as a way to
disable it for debug purposes.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22910>
We are seeing frequent hangs in other workloads when something using
mesh shaders runs at the same time, so gate the feature behind an
environment variable until we figure out what's going on.
v2: (Sagar)
- Give the mesh enabled variable a more descriptive name
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22910>
Matching the original %016lx, and the "0x" prefix which is still
in the format string.
Fixes: 53b77a8102 ("anv: remove 48bit address space checks")
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22882>
We're about to manipulate these pools and dealing with the fix address
ranges is painful.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22847>
We want to add more heaps in the future and so not having to do
address checks to find out in what heap to release a BO is convinient.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22847>
All the supported platforms should have 36+ bits of virtual address
space.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22847>
This value depends on the per-sample value which can be unknown at
compile time with graphics pipeline libraries. So we need to have this
dynamic has well and pick the right value when generating the
3DSTATE_PS/3DSTATE_WM packet.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: d8dfd153c5 ("intel/fs: Make per-sample and coarse dispatch tri-state")
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22728>
