[Mesa-dev] [PATCH v4 7/7] i965: enable INTEL_blackhole_render

Lionel Landwerlin lionel.g.landwerlin at intel.com
Tue Jul 10 14:12:46 UTC 2018

On 10/07/18 15:04, Daniel Vetter wrote:
> On Wed, Jun 20, 2018 at 06:25:34PM +0100, Lionel Landwerlin wrote:
>> v2: condition the extension on context isolation support from the
>>      kernel (Chris)
>> v3: (Lionel)
>>      The initial version of this change used a feature of the Gen7+
>>      command parser to turn the primitive instructions into no-ops.
>>      Unfortunately this doesn't play well with how we're using the
>>      hardware outside of the user submitted commands. For example
>>      resolves are implicit operations which should not be turned into
>>      no-ops as part of the previously submitted commands (before
>>      blackhole_render is enabled) might not be disabled. For example
>>      this sequence :
>>         glClear();
>>         glEnable(GL_BLACKHOLE_RENDER_INTEL);
>>         glDrawArrays(...);
>>         glReadPixels(...);
>>         glDisable(GL_BLACKHOLE_RENDER_INTEL);
>>      While clear has been emitted outside the blackhole render, it
>>      should still be resolved properly in the read pixels. Hence we
>>      need to be more selective and only disable user submitted
>>      commands.
>>      This v3 manually turns primitives into MI_NOOP if blackhole render
>>      is enabled. This lets us enable this feature on any platform.
>> v4: Limit support to gen7.5+ (Lionel)
>> v5: Enable Gen7.5 support again, requires a kernel update of the
>>      command parser (Lionel)
>> v6: Disable Gen7.5 again... Kernel devs want these patches landed
>>      before they accept the kernel patches to whitelist INSTPM (Lionel)
> Hm, this doesn't quite read how kernel patches are usually handled:
> Ordering sequence is:
> 1. get everything reviewed and tested (both kernel and userspace), but do
> not yet start merging
> 2. merge kernel (if you feel paranoid, wait until Dave Airlie accepted it
> into drm-next)
> 3. merge userspace
> Insisting that the userspace stuff lands before the kernel (even if it's
> just prep work) is kinda the wrong way round, and needlessly complicates
> the process.
> This is all documented in full details in
> https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements
> Cheers, Daniel

Hey Daniel,

I remember somebody using the work "land" on IRC but it could have been 
a mistake :)
This is also to avoid committing code that might end up being wrong if 
somebody bumps the command parser version before my patches.

Thanks for reminder,


More information about the mesa-dev mailing list