[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,

-
Lionel


More information about the mesa-dev mailing list