iris: Update comment about 2GB dynamic state range

We tracked this down with the HW teams back in 2020 and there's now a
documented workaround.  Comments from the HW team say this applies all
the way through XeHP but we're not sure beyond that.

This is a bug that we hit but the Windows drivers didn't because Jason
decided to allocate our memory structures from the top end of the VMA
range explicitly to catch bugs like this, while Windows allocates from
zero and up, so they would need to allocate more than 2GB of dynamic
state before running into it.

Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4880
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17216>
This commit is contained in:
Kenneth Graunke 2022-06-23 11:44:18 -07:00 committed by Marge Bot
parent 627ba5c91b
commit b28efd80eb
1 changed files with 9 additions and 4 deletions

View File

@ -2421,10 +2421,15 @@ iris_bufmgr_create(struct intel_device_info *devinfo, int fd, bool bo_reuse)
util_vma_heap_init(&bufmgr->vma_allocator[IRIS_MEMZONE_SURFACE],
IRIS_MEMZONE_SURFACE_START, _4GB_minus_1 -
IRIS_BINDER_ZONE_SIZE - IRIS_BINDLESS_SIZE);
/* TODO: Why does limiting to 2GB help some state items on gfx12?
* - CC Viewport Pointer
* - Blend State Pointer
* - Color Calc State Pointer
/* Wa_2209859288: the Tigerlake PRM's workarounds volume says:
*
* "PSDunit is dropping MSB of the blend state pointer from SD FIFO"
* "Limit the Blend State Pointer to < 2G"
*
* We restrict the dynamic state pool to 2GB so that we don't ever get a
* BLEND_STATE pointer with the MSB set. We aren't likely to need the
* full 4GB for dynamic state anyway.
*/
const uint64_t dynamic_pool_size =
(devinfo->ver >= 12 ? _2GB : _4GB_minus_1) - IRIS_BORDER_COLOR_POOL_SIZE;