mirror of
https://gitlab.freedesktop.org/mesa/mesa.git
synced 2026-05-19 04:58:08 +02:00
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> |
||
|---|---|---|
| .. | ||
| tests | ||
| gen_format_layout.py | ||
| isl.c | ||
| isl.h | ||
| isl_aux_info.c | ||
| isl_drm.c | ||
| isl_emit_cpb.c | ||
| isl_emit_depth_stencil.c | ||
| isl_format.c | ||
| isl_format_layout.csv | ||
| isl_genX_helpers.h | ||
| isl_genX_priv.h | ||
| isl_gfx4.c | ||
| isl_gfx4.h | ||
| isl_gfx6.c | ||
| isl_gfx6.h | ||
| isl_gfx7.c | ||
| isl_gfx7.h | ||
| isl_gfx8.c | ||
| isl_gfx8.h | ||
| isl_gfx9.c | ||
| isl_gfx9.h | ||
| isl_gfx12.c | ||
| isl_gfx12.h | ||
| isl_gfx20.c | ||
| isl_gfx20.h | ||
| isl_priv.h | ||
| isl_query.c | ||
| isl_storage_image.c | ||
| isl_surface_state.c | ||
| isl_tiled_memcpy.c | ||
| isl_tiled_memcpy_normal.c | ||
| isl_tiled_memcpy_sse41.c | ||
| meson.build | ||
| README | ||
Intel Surface Layout
Introduction
============
isl is a small library that calculates the layout of Intel GPU surfaces, queries
those layouts, and queries the properties of surface formats.
Independence from User APIs
===========================
isl's API is independent of any user-facing graphics API, such as OpenGL and
Vulkan. This independence allows isl to be used a shared component by multiple
Intel drivers.
Rather than mimic the user-facing APIs, the isl API attempts to reflect Intel
hardware: the actual memory layout of Intel GPU surfaces and how one programs
the GPU to use those surfaces. For example:
- The tokens of `enum isl_format` (such as `ISL_FORMAT_R8G8B8A8_UNORM`)
match those of the hardware enum `SURFACE_FORMAT` rather than the OpenGL
or Vulkan format tokens. And the values of `isl_format` and
`SURFACE_FORMAT` are identical.
- The OpenGL and Vulkan APIs contain depth and stencil formats. However the
hardware enum `SURFACE_FORMAT` does not, and therefore neither does `enum
isl_format`. Rather than define new pixel formats that have no hardware
counterpart, isl records the intent to use a surface as a depth or stencil
buffer with the usage flags `ISL_SURF_USAGE_DEPTH_BIT` and
`ISL_SURF_USAGE_STENCIL_BIT`.
- `struct isl_surf` distinguishes between the surface's logical dimension
from the user API's perspective (`enum isl_surf_dim`, which may be 1D, 2D,
or 3D) and the layout of those dimensions in memory (`enum isl_dim_layout`).
Surface Units
=============
Intro
-----
ISL takes care in its equations to correctly handle conversion among surface
units (such as pixels and compression blocks) and to carefully distinguish
between a surface's logical layout in the client API and its physical layout
in memory.
Symbol names often explicitly declare their unit with a suffix:
- px: logical pixels
- sa: physical surface samples
- el: physical surface elements
- sa_rows: rows of physical surface samples
- el_rows: rows of physical surface elements
Logical units are independent of hardware generation and are closely related
to the user-facing API (OpenGL and Vulkan). Physical units are dependent on
hardware generation and reflect the surface's layout in memory.
Definitions
-----------
- Logical Pixels (px):
The surface's layout from the perspective of the client API (OpenGL and
Vulkan) is in units of logical pixels. Logical pixels are independent of the
surface's layout in memory.
A surface's width and height, in units of logical pixels, is not affected by
the surface's sample count. For example, consider a VkImage created with
VkImageCreateInfo{width=w0, height=h0, samples=s0}. The surface's width and
height at level 0 is, in units of logical pixels, w0 and h0 regardless of
the value of s0.
For example, the logical array length of a 3D surface is always 1, even on
Gfx9 where the surface's memory layout is that of an array surface
(ISL_DIM_LAYOUT_GFX4_2D).
- Physical Surface Samples (sa):
For a multisampled surface, this unit has the obvious meaning.
A singlesampled surface, from ISL's perspective, is simply a multisampled
surface whose sample count is 1.
For example, consider a 2D single-level non-array surface with samples=4,
width_px=64, and height_px=64 (note that the suffix 'px' indicates logical
pixels). If the surface's multisample layout is ISL_MSAA_LAYOUT_INTERLEAVED,
then the extent of level 0 is, in units of physical surface samples,
width_sa=128, height_sa=128, depth_sa=1, array_length_sa=1. If
ISL_MSAA_LAYOUT_ARRAY, then width_sa=64, height_sa=64, depth_sa=1,
array_length_sa=4.
- Physical Surface Elements (el):
This unit allows ISL to treat compressed and uncompressed formats
identically in many calculations.
If the surface's pixel format is compressed, such as ETC2, then a surface
element is equivalent to a compression block. If uncompressed, then
a surface element is equivalent to a surface sample. As a corollary, for
a given surface a surface element is at least as large as a surface sample.
Errata
------
ISL acquired the term 'surface element' from the Broadwell PRM [1], which
defines it as follows:
An element is defined as a pixel in uncompressed surface formats, and as
a compression block in compressed surface formats. For MSFMT_DEPTH_STENCIL
type multisampled surfaces, an element is a sample.
References
==========
[1]: Broadwell PRM >> Volume 2d: Command Reference: Structures >>
RENDER_SURFACE_STATE Surface Vertical Alignment (p325)