The TGL PRM says,
This bit should never be programmed to 0
So, set it to true. I chose not to use the MBO attribute in genxml
because the field lacks the "Format: MBO" line in the PRM.
We previously made this programming conditional with commit 2e1be771e4
because of tests failing in
dEQP-GLES3.functional.texture.specification.tex*depth*. However, those
failures were fixed when we started using gl_FragDepth for depth buffer
copies in commit 6cec618e82.
Note: when bisecting this, I cherry-picked commit 7a68045b5d in order
to get past build failures related to a deprecated python function.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31066>
Some games such as Marvel's Spider-Man Remastered and Assassin's
Creed: Valhalla don't work in debug mode because they hit this
assertion. In Release mode, they appear to work (although in some
platforms there may be visual corruption or GPU hangs). There's
nothing we can do about this error (see below), so in this patch we
replace the assertion with an error message, because it allows us to
(i) test the rest of the game in debug mode so we may catch other
issues; and (ii) warn users of release mode that the issue is
happening.
The unsupported num_elements comes from vkGetDescriptorEXT() and
appears to be violating VUID-VkDescriptorGetInfoEXT-type-09427. This
function cannot return errors, but we can disable
VK_EXT_descriptor_buffer.
If we do disable the extension, then vkCreateBufferView() will start
triggering the assertion, and we can see that
VkBufferViewCreateInfo-range-00930 is being violated. If we change Anv
to return errors on these vkCreateBufferView() cases, then the games
won't work at all.
I reported this to vkd3d-proton, but according to the vkd3d-proton
developer Philip Rebohle:
"There's also the problematic case of games using typed descriptors
but passing non-typed buffer descriptors, which is an extremely
common app bug that works on all D3D12 drivers that we need to work
around by creating typed views. If that's what's happening here then
the best we can do is to just not create the typed view and have the
game be broken entirely, or create a smaller view and most likely
still completely break the game, but at least that way it wouldn't
trigger Vulkan validation. Emulating larger views via multiple
smaller views is not possible for us."
"Confirmed that it's the app itself creating these views."
"D3D12 does not have runtime validation for this or any sort of query
for the app, so we really can't do much here."
Link: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9963
Link: https://github.com/HansKristian-Work/vkd3d-proton/issues/2071
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30775>
The hardware's clear color conversion feature unfortunately requires
invalidating the texture cache for every fast clear. To avoid the
performance penalty that comes with the invalidation, avoid using the
hardware feature and write out the converted clear color pixel
ourselves.
When testing a patch which moves a state cache invalidate to occur after
fast clears instead of before, this prevents the following failures on
icl/zink:
* piglit.fast_color_clear.fcc-read-after-clear sample tex
* piglit.spec.arb_clear_texture.arb_clear_texture-cube
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30646>
For correct fast-clearing with HiZ+CCS, we require roughly 16x8
alignment of LODs. The next patch will cause drivers to ignore the
alignment of LOD0, so align the qpitch to 8 to avoid breakage and so
that fast clears will be enabled more often.
Prevents failures with the piglit test case:
./bin/fbo-depth-array depth-clear -fbo
in the next patch.
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30250>
The CMF values of these formats are not explicitly defined in the
spec. Refer to the added comment for more details.
Fixed Piglit tests:
[ISL_FORMAT_L8A8_UNORM_SRGB]
getteximage-formats -auto -fbo
[ISL_FORMAT_L8_UNORM_SRGB]
teximage-colors GL_SLUMINANCE8 -auto -fbo
[ISL_FORMAT_R9G9B9E5_SHAREDEXP]
fbo-generatemipmap-3d RGB9_E5 -auto -fbo
src/intel/isl/isl_genX_helpers.h:322: isl_get_render_compression_format:
Assertion `!"" "Unsupported render compression format!"' failed.
Also bump up Bspec revision in comments.
Signed-off-by: Jianxun Zhang <jianxun.zhang@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28620>
Pass struct isl_tile_info to isl_choose_image_alignment_el() and its
subfunctions. We already compute isl_tile_info at isl_surf_init_s(),
don't make the subfunctions compute it again, just reuse the results.
Other subfunctions of isl_surf_init_s() also take the tile info as an
argument instead of recomputing it.
v2: Rebase after the gen20 version was added.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> (v1)
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com> (v2)
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29337>
I got the image alignment requirements for CPCB surfaces from Bspec
authors. The vertical alignment value of 8 was confirmed through the
Vulkan CTS test group, dEQP-VK.fragment_shading_rate*layered*. It also
happens to match the QPitch alignment requirement documented in the
Bspec. Hopefully the CTS will add tests for LOD2+ in order to exercise
the horizontal alignment value.
With this in place, we can start using Tile4.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10784
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29355>
Intel modifiers supporting compression are specified to be compatible
with the display engine, even if they won't actually be used for
scanout.
Attempting to capture a wider scope of modifiers resulted in test
errors. I chose to narrow the scope instead of digging into them.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jianxun Zhang <jianxun.zhang@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29659>
This workaround ask us to set a dummy aux address to all
SURFTYPE_BUFFERs with AuxiliarySurfaceMode == AUX_NONE.
It also says that the same dummy aux address can be reused acrsoss all
buffers.
So here adding dummy_aux_address to isl_device, ANV and Iris will
set a value to when running a in a GPU affected.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29619>
In the import paths in iris, there are several cases where surface VMAs
are created without relying on the calculated surface alignment.
Asserting the alignments of surface addresses, should help catch any
cases where we end up with the wrong alignment.
This found a couple issues during development. One which required a
change to existing code is that when creating uncompressed surfaces from
compressed ones, ISL will sometimes increase the image alignment as a
result of the new format supporting CCS. This patch adds the usage flag
to disable that behavior.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29094>
Add and use two new surf usage bits:
* ISL_SURF_USAGE_MULTI_ENGINE_SEQ_BIT: the surface may be accessed by
multiple engines, but not in parallel.
* ISL_SURF_USAGE_MULTI_ENGINE_PAR_BIT: the surface may be accessed by
multiple engines in parallel.
Both usages are not concerned with read-after-read access patterns.
Using these bits allows ISL to conditionally use Tile64 or a 64KB
alignment to account for the gfx12.5 CCS WA from HSD 22015614752. Apart
from the potential space savings, there are three benefits of this
approach:
1) CCS can now be used with miptails (though nothing makes use of this
today).
2) CCS can now be used with 3D depth/stencil surfaces in GL.
3) CCS can now be used with 3D depth/stencil surfaces in Vulkan when
apps only use a single queue.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11111
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11117
Tested-by: Mark Janes <markjanes@swizzler.org>
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29094>
In iris, use the CCS scale down factor to calculate the impact of CCS on
TBIMR tile sizes. Even though we fall back to a seemingly less accurate
method to calculate the impact of CCS, it ends up giving the same
answer, 1bpp. Anv already uses this factor, so this patch replaces the
constant with this macro.
There are two benefits to doing this:
1) Consistency between anv and iris.
2) Preparation for a future where we no longer use ISL surfaces to
describe CCS on Xe+. In fact, in iris, we already don't create such
surfaces on ACM.
I considered using INTEL_AUX_MAP_MAIN_SIZE_SCALEDOWN for the calculation
in both drivers, but the naming is aux-map specific and the scaledown
actually exists on flat-ccs platforms as well.
So, we introduce a new macro for all Xe platforms, currently only used
for the specific use case of TBIMR calculations. We can add more such
macros for future platforms, as needed.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28942>
At the interfaces which query the pitch of the clear color plane in GL
and Vulkan, we've been returning 64B for various reasons. Unify the
rationale under a macro.
The documentation for the macro is picked from anv, which reflects the
most recently synchronized copy of drm_fourcc.h. See the notable changes
at 8cd8f3d697.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28942>
We were accidentally leaving XY_BLOCK_COPY_BLT's Source and Destination
MOCS fields set to 0 (Error: Reserved for Non-Use) on Gfx12.0 systems.
This was causing assert fails in debug builds, since we try to ensure
that we don't do that. In theory, MOCS 0 is supposed to be equivalent
to MOCS 2 (all the caching), but...we probably ought to use MOCS 3
(uncached). Every Gfx12.5+ platform requires it, so although there
isn't a note about Gfx12.0 needing that, it's possible that it does.
We're currently only using the blitter for DRI PRIME blits on Gfx12.0,
anyway, and I think we're flushing all the caches regardless.
This bug was somewhat obscure to hit:
- You need a hybrid graphics system with Gfx12.0 and some other GPU
- You have to be using "reverse PRIME", i.e. rendering on the integrated
GPU and displaying on the discrete one. This is not the common case.
- You have to be using a debug build.
No observable performance delta in GfxBench5 Car Chase (an arbitrary
program) when rendering on Alderlake GT1 and displaying on an Arc A770.
Fixes: 194afe8416 ("anv/iris/blorp: use the right MOCS values for each engine")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28894>
Nanley Chery