[Intel-gfx] [PATCH 2/4] drm/i915/guc: Submit GuC workitems containing coalesced requests

[Chris Wilson]

Quoting Michał Winiarski (2017-09-12 13:47:24)
> To create an upper bound on number of GuC workitems, we need to change
> the way that requests are being submitted. Rather than submitting each
> request as an individual workitem, we can do coalescing in a similar way
> we're handlig execlist submission ports. We also need to stop pretending
> that we're doing "lite-restore" in GuC submission (we would create a
> workitem each time we hit this condition). This allows us to completely
> remove the reservation, replacing it with a compile time check.
> 
> v2: Also coalesce when replaying on reset (Daniele)
> v3: Consistent wq_resv - per-request (Daniele)
> v4: Squash removing wq_resv
> 
> References: https://bugs.freedesktop.org/show_bug.cgi?id=101873
> Cc: Chris Wilson <chris at chris-wilson.co.uk>
> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio at intel.com>
> Cc: Jeff McGee <jeff.mcgee at intel.com>
> Cc: Michal Wajdeczko <michal.wajdeczko at intel.com>
> Cc: Oscar Mateo <oscar.mateo at intel.com>
> Signed-off-by: Michał Winiarski <michal.winiarski at intel.com>

Matches my expectations,
Reviewed-by: Chris Wilson <chris at chris-wilson.co.uk>

Just pondering the interaction with gen8_cs_irq_handler(). Since we are
now tweaking port_count(), it is theoretically possible that we get a
cs-interrupt. That seems entirely harmless as the guc tasklet checks the
breadcrumb anyway. Just something to keep in the back of the mind when
reviewing the interactions between execlist.port[] and guc.

But I'm wondering if we should be masking the cs-interrupt on switching
to guc... I don't believe we are in gen9_enable_guc_interrupts().
-Chris