'relative_constants_mode' has always been tracked per-device, but whereas this was adequate in legacy ringbuffer mode, it's wrong in execlists (or GuC) mode, as the INSTPM register is saved and restored with the logical context, and the per-context value could therefore get out of sync with the tracked value. The test case (if anyone wants to write it) would be to create two separate logical contexts, submit a render batch with a non-default mode in the first context, submit a render batch with the default mode in the other context, then submit a second batch in the first context, but this time selecting the default mode. The driver will fail to insert the instructions to reset INSTPM into the first context's ringbuffer, as it will compare the mode required for the new batch with the last mode set (which will be in a different context). The batch will then be executed with the incorrect mode setting. The bug has been there since the first implementation of execlists: ba8b7ccb1 drm/i915/bdw: Workload submission mechanism for Execlists
Fix is under review : https://patchwork.freedesktop.org/series/91/
Patch to delete this support entirely here: https://patchwork.freedesktop.org/patch/138963/
commit ef0f411f51475f4eebf9fc1b19a85be698af19ff Author: Kenneth Graunke <kenneth@whitecape.org> Date: Wed Feb 15 01:34:46 2017 -0800 drm/i915: Drop support for I915_EXEC_CONSTANTS_* execbuf parameters.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.