diff options
author | Matt Roper <matthew.d.roper@intel.com> | 2024-08-12 21:10:43 +0300 |
---|---|---|
committer | Matt Roper <matthew.d.roper@intel.com> | 2024-08-13 20:14:59 +0300 |
commit | 1d734a3e5d6bb266f52eaf2b1400c5d3f1875a54 (patch) | |
tree | b8972818e56f017c58a5b68d517a4a2cdc109609 /tools/perf/scripts/python/export-to-postgresql.py | |
parent | d408d6f8cbbb5ad92b383f33d091f027f5740aea (diff) | |
download | linux-1d734a3e5d6bb266f52eaf2b1400c5d3f1875a54.tar.xz |
drm/xe: Name and document Wa_14019789679
Early in the development of Xe we identified an issue with SVG state
handling on DG2 and MTL (and later on Xe2 as well). In
commit 72ac304769dd ("drm/xe: Emit SVG state on RCS during driver load
on DG2 and MTL") and commit fb24b858a20d ("drm/xe/xe2: Update SVG state
handling") we implemented our own workaround to prevent SVG state from
leaking from context A to context B in cases where context B never
issues a specific state setting.
The hardware teams have now created official workaround Wa_14019789679
to cover this issue. The workaround description only requires emitting
3DSTATE_MESH_CONTROL, since they believe that's the only SVG instruction
that would potentially remain unset by a context B, but still cause
notable issues if unwanted values were inherited from context A.
However since we already have a more extensive implementation that emits
the entire SVG state and prevents _any_ SVG state from unintentionally
leaking, we'll stick with our existing implementation just to be safe.
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240812181042.2013508-2-matthew.d.roper@intel.com
Diffstat (limited to 'tools/perf/scripts/python/export-to-postgresql.py')
0 files changed, 0 insertions, 0 deletions