From: Kevin Rogovin <kevin.rogovin@xxxxxxxxx> Correct documentation of logical ring context implementation to note that ringbuffer and backing store are created lazily for all context types (driver global, local default context and local extra context). Signed-off-by: Kevin Rogovin <kevin.rogovin@xxxxxxxxx> --- drivers/gpu/drm/i915/intel_lrc.c | 13 +------------ 1 file changed, 1 insertion(+), 12 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index 53f1c009ed7b..382a4656a1d9 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -70,22 +70,11 @@ * - One ringbuffer per-engine inside each context. * - One backing object per-engine inside each context. * - * The global default context starts its life with these new objects fully - * allocated and populated. The local default context for each opened fd is - * more complex, because we don't know at creation time which engine is going - * to use them. To handle this, we have implemented a deferred creation of LR - * contexts: - * - * The local context starts its life as a hollow or blank holder, that only - * gets populated for a given engine once we receive an execbuffer. If later + * which are populated for a given engine once we receive an execbuffer.If later * on we receive another execbuffer ioctl for the same context but a different * engine, we allocate/populate a new ringbuffer and context backing object and * so on. * - * Finally, regarding local contexts created using the ioctl call: as they are - * only allowed with the render ring, we can allocate & populate them right - * away (no need to defer anything, at least for now). - * * Execlists implementation: * Execlists are the new method by which, on gen8+ hardware, workloads are * submitted for execution (as opposed to the legacy, ringbuffer-based, method). -- 2.16.2 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
