[Bug 96624] [SKL, KBL] texture misrender in The Talos Principle

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Wed May 30 08:08:16 UTC 2018


--- Comment #11 from Sergii Romantsov <sergii.romantsov at globallogic.com> ---
Created attachment 139842
  --> https://bugs.freedesktop.org/attachment.cgi?id=139842&action=edit
Workaround for trace Talos_flicker3_trim2.trace.xz

Investigation was done with trace
Workarounds (standalone):
1. Only for that trace (helps not for all cases, so sometimes still problem
will happen): 96624_wa.diff
2. To use LIBGL_ALWAYS_SOFTWARE=true (swrast)

More investigations:
1. Used simplified shaders for program 1496 (vertex shader 1286, fragment
shader 1296):
1.1. VS_f5145e822d6ab91eba69ffa69464742d03d0545a.glsl:
  - Left computation of vVexPosAbs
  - Assign vMaskLightUV.xy by vLightUV.xy
  - Avoid any more computations
1.2. FS_a6439012ab28d0bb9cc17c615c9b0487158f9cb1.glsl:
  - Use vMaskLightUV.xy to compute vOutColor.rgb
  - Avoid any more computations
2. Used array buffers:
2.1. 254490 @0 glBindBuffer(target = GL_ELEMENT_ARRAY_BUFFER, buffer = 1139)
2.2. 254517 @0 glBindBuffer(target = GL_ARRAY_BUFFER, buffer = 1140)

2. Final observation:
2.1. For vertex shader data in array vLightUV are invalid.
2.2. Reading of data by DRM_IOCTL_I915_GEM_PREA (for buffers 1139 and 1140) on
differnet stages shows that data in arrays are not changed.

3. Temporal conclusion:
3.1. Or some invalid offsets/addresses computed
3.2. Or before glDraw*-calls missed some flushing/caching/command

4. Questions:
4.1. Is it possible to debug by which address vertex shader reads vLightUV?
4.2. Any more ideas?

You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-3d-bugs/attachments/20180530/234a105b/attachment-0001.html>

More information about the intel-3d-bugs mailing list