Re: [Intel-gfx] [PATCH 27/43] drm/i915/bdw: Render state init for Execlists
On Wed, Aug 20, 2014 at 03:55:42PM +, Daniel, Thomas wrote:
-Original Message-
From: Daniel, Thomas
Sent: Friday, August 15, 2014 9:44 AM
To: 'Daniel Vetter'
Cc: intel-gfx@lists.freedesktop.org
Subject: RE: [Intel-gfx] [PATCH 27/43] drm/i915/bdw: Render state init for
Execlists
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of
Daniel Vetter
Sent: Thursday, August 14, 2014 9:00 PM
To: Daniel, Thomas
Cc: Daniel Vetter; intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 27/43] drm/i915/bdw: Render state init
for Execlists
On Wed, Aug 13, 2014 at 05:30:07PM +0200, Daniel Vetter wrote:
On Wed, Aug 13, 2014 at 03:07:29PM +, Daniel, Thomas wrote:
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of
Daniel Vetter
Sent: Monday, August 11, 2014 10:25 PM
To: Daniel, Thomas
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 27/43] drm/i915/bdw: Render
state init for Execlists
On Thu, Jul 24, 2014 at 05:04:35PM +0100, Thomas Daniel wrote:
From: Oscar Mateo oscar.ma...@intel.com
index 9085ff1..0dc6992 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -513,8 +513,23 @@ int i915_gem_context_enable(struct
drm_i915_private *dev_priv)
ppgtt-enable(ppgtt);
}
- if (i915.enable_execlists)
+ if (i915.enable_execlists) {
+ struct intel_context *dctx;
+
+ ring = dev_priv-ring[RCS];
+ dctx = ring-default_context;
+
+ if (!dctx-rcs_initialized) {
+ ret = intel_lr_context_render_state_init(ring,
dctx);
+ if (ret) {
+ DRM_ERROR(Init render state failed:
%d\n,
ret);
+ return ret;
+ }
+ dctx-rcs_initialized = true;
+ }
+
return 0;
+ }
This looks very much like the wrong place. We should init the
render state when we create the context, or when we switch to it
for
the first time.
The later is what the legacy contexts currently do in do_switch.
But ctx_enable should do the switch to the default context and
that's about
Well, a side-effect of switching to the default context in legacy
mode is that the render state gets initialized. I could move the
lr render state init call into an enable_execlists branch in
i915_switch_context() but that doen't seem like the right place.
How about in i915_gem_init() after calling i915_gem_init_hw()?
it. If there's some depency then I guess we should stall the
creation of the default context a bit, maybe.
In any case someone needs to explain this better and if there's
not other wey this at least needs a bit comment. So I'll punt for
now.
When the default context is created the driver is not ready to
execute a batch. That is why the render state init can't be done
then.
That sounds like the default context is created too early.
Essentially I want to avoid needless divergence between the default
context and normal contexts, because sooner or later that will means
someone will creep in with a _really_ subtle bug.
What about:
- We create the default lrc contexs in context_init, but like with a
normal context we don't do any of the deferred setup.
- In context_enable (which since yesterday properly propagates errors to
callers) we force the deferred lrc ctx setup for the default contexts
on
all engines.
- The render state init is done as part of the deferred ctx setup for
the
render engine in all cases.
Totally off the track or do you see a workable solution somewhere in
that direction?
I'd like to discuss this first a bit more, so will punt on this patch for
now.
-Daniel
I think that your proposal will work. I've been having some trouble with my
RVP board so haven't had a chance to test it out yet.
Thomas.
I've now tried this out and I don't think it can work without introducing
more problems than the original patch. Trouble is that in lrc mode the
Hardware Status Page is offset 0 from the context. All contexts use the
default context's HWSP for writing seqnos, this is stored in
ring-status_page. We can't populate this until the deferred creation of
the default context is done, so we can't execute any instructions in the
deferred creation (unless we check for default context in the deferred
creation which is what we wanted to avoid in the first place).
That just sounds like we should either
Re: [Intel-gfx] [PATCH 27/43] drm/i915/bdw: Render state init for Execlists
-Original Message-
From: Daniel, Thomas
Sent: Friday, August 15, 2014 9:44 AM
To: 'Daniel Vetter'
Cc: intel-gfx@lists.freedesktop.org
Subject: RE: [Intel-gfx] [PATCH 27/43] drm/i915/bdw: Render state init for
Execlists
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of
Daniel Vetter
Sent: Thursday, August 14, 2014 9:00 PM
To: Daniel, Thomas
Cc: Daniel Vetter; intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 27/43] drm/i915/bdw: Render state init
for Execlists
On Wed, Aug 13, 2014 at 05:30:07PM +0200, Daniel Vetter wrote:
On Wed, Aug 13, 2014 at 03:07:29PM +, Daniel, Thomas wrote:
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of
Daniel Vetter
Sent: Monday, August 11, 2014 10:25 PM
To: Daniel, Thomas
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 27/43] drm/i915/bdw: Render
state init for Execlists
On Thu, Jul 24, 2014 at 05:04:35PM +0100, Thomas Daniel wrote:
From: Oscar Mateo oscar.ma...@intel.com
index 9085ff1..0dc6992 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -513,8 +513,23 @@ int i915_gem_context_enable(struct
drm_i915_private *dev_priv)
ppgtt-enable(ppgtt);
}
- if (i915.enable_execlists)
+ if (i915.enable_execlists) {
+ struct intel_context *dctx;
+
+ ring = dev_priv-ring[RCS];
+ dctx = ring-default_context;
+
+ if (!dctx-rcs_initialized) {
+ ret = intel_lr_context_render_state_init(ring,
dctx);
+ if (ret) {
+ DRM_ERROR(Init render state failed:
%d\n,
ret);
+ return ret;
+ }
+ dctx-rcs_initialized = true;
+ }
+
return 0;
+ }
This looks very much like the wrong place. We should init the
render state when we create the context, or when we switch to it
for
the first time.
The later is what the legacy contexts currently do in do_switch.
But ctx_enable should do the switch to the default context and
that's about
Well, a side-effect of switching to the default context in legacy
mode is that the render state gets initialized. I could move the
lr render state init call into an enable_execlists branch in
i915_switch_context() but that doen't seem like the right place.
How about in i915_gem_init() after calling i915_gem_init_hw()?
it. If there's some depency then I guess we should stall the
creation of the default context a bit, maybe.
In any case someone needs to explain this better and if there's
not other wey this at least needs a bit comment. So I'll punt for now.
When the default context is created the driver is not ready to
execute a batch. That is why the render state init can't be done then.
That sounds like the default context is created too early.
Essentially I want to avoid needless divergence between the default
context and normal contexts, because sooner or later that will means
someone will creep in with a _really_ subtle bug.
What about:
- We create the default lrc contexs in context_init, but like with a
normal context we don't do any of the deferred setup.
- In context_enable (which since yesterday properly propagates errors to
callers) we force the deferred lrc ctx setup for the default contexts on
all engines.
- The render state init is done as part of the deferred ctx setup for the
render engine in all cases.
Totally off the track or do you see a workable solution somewhere in
that direction?
I'd like to discuss this first a bit more, so will punt on this patch for
now.
-Daniel
I think that your proposal will work. I've been having some trouble with my
RVP board so haven't had a chance to test it out yet.
Thomas.
I've now tried this out and I don't think it can work without introducing
more problems than the original patch. Trouble is that in lrc mode the
Hardware Status Page is offset 0 from the context. All contexts use the
default context's HWSP for writing seqnos, this is stored in
ring-status_page. We can't populate this until the deferred creation of
the default context is done, so we can't execute any instructions in the
deferred creation (unless we check for default context in the deferred
creation which is what we wanted to avoid in the first place).
Thomas.
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx
Re: [Intel-gfx] [PATCH 27/43] drm/i915/bdw: Render state init for Execlists
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
Vetter
Sent: Thursday, August 14, 2014 9:00 PM
To: Daniel, Thomas
Cc: Daniel Vetter; intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 27/43] drm/i915/bdw: Render state init for
Execlists
On Wed, Aug 13, 2014 at 05:30:07PM +0200, Daniel Vetter wrote:
On Wed, Aug 13, 2014 at 03:07:29PM +, Daniel, Thomas wrote:
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of
Daniel Vetter
Sent: Monday, August 11, 2014 10:25 PM
To: Daniel, Thomas
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 27/43] drm/i915/bdw: Render state
init for Execlists
On Thu, Jul 24, 2014 at 05:04:35PM +0100, Thomas Daniel wrote:
From: Oscar Mateo oscar.ma...@intel.com
index 9085ff1..0dc6992 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -513,8 +513,23 @@ int i915_gem_context_enable(struct
drm_i915_private *dev_priv)
ppgtt-enable(ppgtt);
}
- if (i915.enable_execlists)
+ if (i915.enable_execlists) {
+ struct intel_context *dctx;
+
+ ring = dev_priv-ring[RCS];
+ dctx = ring-default_context;
+
+ if (!dctx-rcs_initialized) {
+ ret = intel_lr_context_render_state_init(ring,
dctx);
+ if (ret) {
+ DRM_ERROR(Init render state failed:
%d\n,
ret);
+ return ret;
+ }
+ dctx-rcs_initialized = true;
+ }
+
return 0;
+ }
This looks very much like the wrong place. We should init the
render state when we create the context, or when we switch to it for
the first time.
The later is what the legacy contexts currently do in do_switch.
But ctx_enable should do the switch to the default context and
that's about
Well, a side-effect of switching to the default context in legacy
mode is that the render state gets initialized. I could move the lr
render state init call into an enable_execlists branch in
i915_switch_context() but that doen't seem like the right place.
How about in i915_gem_init() after calling i915_gem_init_hw()?
it. If there's some depency then I guess we should stall the
creation of the default context a bit, maybe.
In any case someone needs to explain this better and if there's
not other wey this at least needs a bit comment. So I'll punt for now.
When the default context is created the driver is not ready to
execute a batch. That is why the render state init can't be done then.
That sounds like the default context is created too early. Essentially
I want to avoid needless divergence between the default context and
normal contexts, because sooner or later that will means someone will
creep in with a _really_ subtle bug.
What about:
- We create the default lrc contexs in context_init, but like with a
normal context we don't do any of the deferred setup.
- In context_enable (which since yesterday properly propagates errors to
callers) we force the deferred lrc ctx setup for the default contexts on
all engines.
- The render state init is done as part of the deferred ctx setup for the
render engine in all cases.
Totally off the track or do you see a workable solution somewhere in
that direction?
I'd like to discuss this first a bit more, so will punt on this patch for now.
-Daniel
I think that your proposal will work. I've been having some trouble
with my RVP board so haven't had a chance to test it out yet.
Thomas.
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 27/43] drm/i915/bdw: Render state init for Execlists
On Wed, Aug 13, 2014 at 05:30:07PM +0200, Daniel Vetter wrote:
On Wed, Aug 13, 2014 at 03:07:29PM +, Daniel, Thomas wrote:
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
Vetter
Sent: Monday, August 11, 2014 10:25 PM
To: Daniel, Thomas
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 27/43] drm/i915/bdw: Render state init for
Execlists
On Thu, Jul 24, 2014 at 05:04:35PM +0100, Thomas Daniel wrote:
From: Oscar Mateo oscar.ma...@intel.com
index 9085ff1..0dc6992 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -513,8 +513,23 @@ int i915_gem_context_enable(struct
drm_i915_private *dev_priv)
ppgtt-enable(ppgtt);
}
- if (i915.enable_execlists)
+ if (i915.enable_execlists) {
+ struct intel_context *dctx;
+
+ ring = dev_priv-ring[RCS];
+ dctx = ring-default_context;
+
+ if (!dctx-rcs_initialized) {
+ ret = intel_lr_context_render_state_init(ring,
dctx);
+ if (ret) {
+ DRM_ERROR(Init render state failed:
%d\n,
ret);
+ return ret;
+ }
+ dctx-rcs_initialized = true;
+ }
+
return 0;
+ }
This looks very much like the wrong place. We should init the render state
when we create the context, or when we switch to it for the first time.
The later is what the legacy contexts currently do in do_switch.
But ctx_enable should do the switch to the default context and that's
about
Well, a side-effect of switching to the default context in legacy mode is
that
the render state gets initialized. I could move the lr render state init
call
into an enable_execlists branch in i915_switch_context() but that doen't
seem like the right place.
How about in i915_gem_init() after calling i915_gem_init_hw()?
it. If there's some depency then I guess we should stall the creation of
the
default context a bit, maybe.
In any case someone needs to explain this better and if there's not other
wey this at least needs a bit comment. So I'll punt for now.
When the default context is created the driver is not ready to execute a
batch. That is why the render state init can't be done then.
That sounds like the default context is created too early. Essentially I
want to avoid needless divergence between the default context and normal
contexts, because sooner or later that will means someone will creep in
with a _really_ subtle bug.
What about:
- We create the default lrc contexs in context_init, but like with a
normal context we don't do any of the deferred setup.
- In context_enable (which since yesterday properly propagates errors to
callers) we force the deferred lrc ctx setup for the default contexts on
all engines.
- The render state init is done as part of the deferred ctx setup for the
render engine in all cases.
Totally off the track or do you see a workable solution somewhere in that
direction?
I'd like to discuss this first a bit more, so will punt on this patch for
now.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 27/43] drm/i915/bdw: Render state init for Execlists
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
Vetter
Sent: Monday, August 11, 2014 10:25 PM
To: Daniel, Thomas
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 27/43] drm/i915/bdw: Render state init for
Execlists
On Thu, Jul 24, 2014 at 05:04:35PM +0100, Thomas Daniel wrote:
From: Oscar Mateo oscar.ma...@intel.com
The batchbuffer that sets the render context state is submitted in a
different way, and from different places.
We needed to make both the render state preparation and free functions
outside accesible, and namespace accordingly. This mess is so that all
LR, LRC and Execlists functionality can go together in intel_lrc.c: we
can fix all of this later on, once the interfaces are clear.
v2: Create a separate ctx-rcs_initialized for the Execlists case, as
suggested by Chris Wilson.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h |4 +--
drivers/gpu/drm/i915/i915_gem_context.c | 17 +-
drivers/gpu/drm/i915/i915_gem_render_state.c | 40 ++--
--
drivers/gpu/drm/i915/i915_gem_render_state.h | 47
++
drivers/gpu/drm/i915/intel_lrc.c | 46
+
drivers/gpu/drm/i915/intel_lrc.h |2 ++
drivers/gpu/drm/i915/intel_renderstate.h |8 +
7 files changed, 139 insertions(+), 25 deletions(-) create mode
100644 drivers/gpu/drm/i915/i915_gem_render_state.h
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h index 4303e2c..b7cf0ec 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -37,6 +37,7 @@
#include intel_ringbuffer.h
#include intel_lrc.h
#include i915_gem_gtt.h
+#include i915_gem_render_state.h
#include linux/io-mapping.h
#include linux/i2c.h
#include linux/i2c-algo-bit.h
@@ -623,6 +624,7 @@ struct intel_context {
} legacy_hw_ctx;
/* Execlists */
+ bool rcs_initialized;
struct {
struct drm_i915_gem_object *state;
struct intel_ringbuffer *ringbuf;
@@ -2553,8 +2555,6 @@ int i915_gem_context_create_ioctl(struct
drm_device *dev, void *data, int i915_gem_context_destroy_ioctl(struct
drm_device *dev, void *data,
struct drm_file *file);
-/* i915_gem_render_state.c */
-int i915_gem_render_state_init(struct intel_engine_cs *ring);
/* i915_gem_evict.c */
int __must_check i915_gem_evict_something(struct drm_device *dev,
struct i915_address_space *vm, diff
--git
a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 9085ff1..0dc6992 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -513,8 +513,23 @@ int i915_gem_context_enable(struct
drm_i915_private *dev_priv)
ppgtt-enable(ppgtt);
}
- if (i915.enable_execlists)
+ if (i915.enable_execlists) {
+ struct intel_context *dctx;
+
+ ring = dev_priv-ring[RCS];
+ dctx = ring-default_context;
+
+ if (!dctx-rcs_initialized) {
+ ret = intel_lr_context_render_state_init(ring, dctx);
+ if (ret) {
+ DRM_ERROR(Init render state failed: %d\n,
ret);
+ return ret;
+ }
+ dctx-rcs_initialized = true;
+ }
+
return 0;
+ }
This looks very much like the wrong place. We should init the render state
when we create the context, or when we switch to it for the first time.
The later is what the legacy contexts currently do in do_switch.
But ctx_enable should do the switch to the default context and that's about
Well, a side-effect of switching to the default context in legacy mode is that
the render state gets initialized. I could move the lr render state init call
into an enable_execlists branch in i915_switch_context() but that doen't
seem like the right place.
How about in i915_gem_init() after calling i915_gem_init_hw()?
it. If there's some depency then I guess we should stall the creation of the
default context a bit, maybe.
In any case someone needs to explain this better and if there's not other
wey this at least needs a bit comment. So I'll punt for now.
When the default context is created the driver is not ready to execute a
batch. That is why the render state init can't be done then.
Thomas.
-Daniel
/* FIXME: We should make this work, even in reset */
if (i915_reset_in_progress(dev_priv-gpu_error))
diff --git a/drivers/gpu/drm/i915/i915_gem_render_state.c
b/drivers/gpu/drm/i915/i915_gem_render_state.c
index e60be3f..a9a62d7 100644
--- a/drivers/gpu/drm/i915
Re: [Intel-gfx] [PATCH 27/43] drm/i915/bdw: Render state init for Execlists
On Wed, Aug 13, 2014 at 03:07:29PM +, Daniel, Thomas wrote:
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
Vetter
Sent: Monday, August 11, 2014 10:25 PM
To: Daniel, Thomas
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 27/43] drm/i915/bdw: Render state init for
Execlists
On Thu, Jul 24, 2014 at 05:04:35PM +0100, Thomas Daniel wrote:
From: Oscar Mateo oscar.ma...@intel.com
index 9085ff1..0dc6992 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -513,8 +513,23 @@ int i915_gem_context_enable(struct
drm_i915_private *dev_priv)
ppgtt-enable(ppgtt);
}
- if (i915.enable_execlists)
+ if (i915.enable_execlists) {
+ struct intel_context *dctx;
+
+ ring = dev_priv-ring[RCS];
+ dctx = ring-default_context;
+
+ if (!dctx-rcs_initialized) {
+ ret = intel_lr_context_render_state_init(ring, dctx);
+ if (ret) {
+ DRM_ERROR(Init render state failed: %d\n,
ret);
+ return ret;
+ }
+ dctx-rcs_initialized = true;
+ }
+
return 0;
+ }
This looks very much like the wrong place. We should init the render state
when we create the context, or when we switch to it for the first time.
The later is what the legacy contexts currently do in do_switch.
But ctx_enable should do the switch to the default context and that's about
Well, a side-effect of switching to the default context in legacy mode is that
the render state gets initialized. I could move the lr render state init call
into an enable_execlists branch in i915_switch_context() but that doen't
seem like the right place.
How about in i915_gem_init() after calling i915_gem_init_hw()?
it. If there's some depency then I guess we should stall the creation of the
default context a bit, maybe.
In any case someone needs to explain this better and if there's not other
wey this at least needs a bit comment. So I'll punt for now.
When the default context is created the driver is not ready to execute a
batch. That is why the render state init can't be done then.
That sounds like the default context is created too early. Essentially I
want to avoid needless divergence between the default context and normal
contexts, because sooner or later that will means someone will creep in
with a _really_ subtle bug.
What about:
- We create the default lrc contexs in context_init, but like with a
normal context we don't do any of the deferred setup.
- In context_enable (which since yesterday properly propagates errors to
callers) we force the deferred lrc ctx setup for the default contexts on
all engines.
- The render state init is done as part of the deferred ctx setup for the
render engine in all cases.
Totally off the track or do you see a workable solution somewhere in that
direction?
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 27/43] drm/i915/bdw: Render state init for Execlists
On Thu, Jul 24, 2014 at 05:04:35PM +0100, Thomas Daniel wrote:
From: Oscar Mateo oscar.ma...@intel.com
The batchbuffer that sets the render context state is submitted
in a different way, and from different places.
We needed to make both the render state preparation and free functions
outside accesible, and namespace accordingly. This mess is so that all
LR, LRC and Execlists functionality can go together in intel_lrc.c: we
can fix all of this later on, once the interfaces are clear.
v2: Create a separate ctx-rcs_initialized for the Execlists case, as
suggested by Chris Wilson.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h |4 +--
drivers/gpu/drm/i915/i915_gem_context.c | 17 +-
drivers/gpu/drm/i915/i915_gem_render_state.c | 40 ++
drivers/gpu/drm/i915/i915_gem_render_state.h | 47
++
drivers/gpu/drm/i915/intel_lrc.c | 46 +
drivers/gpu/drm/i915/intel_lrc.h |2 ++
drivers/gpu/drm/i915/intel_renderstate.h |8 +
7 files changed, 139 insertions(+), 25 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_gem_render_state.h
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4303e2c..b7cf0ec 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -37,6 +37,7 @@
#include intel_ringbuffer.h
#include intel_lrc.h
#include i915_gem_gtt.h
+#include i915_gem_render_state.h
#include linux/io-mapping.h
#include linux/i2c.h
#include linux/i2c-algo-bit.h
@@ -623,6 +624,7 @@ struct intel_context {
} legacy_hw_ctx;
/* Execlists */
+ bool rcs_initialized;
struct {
struct drm_i915_gem_object *state;
struct intel_ringbuffer *ringbuf;
@@ -2553,8 +2555,6 @@ int i915_gem_context_create_ioctl(struct drm_device
*dev, void *data,
int i915_gem_context_destroy_ioctl(struct drm_device *dev, void *data,
struct drm_file *file);
-/* i915_gem_render_state.c */
-int i915_gem_render_state_init(struct intel_engine_cs *ring);
/* i915_gem_evict.c */
int __must_check i915_gem_evict_something(struct drm_device *dev,
struct i915_address_space *vm,
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 9085ff1..0dc6992 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -513,8 +513,23 @@ int i915_gem_context_enable(struct drm_i915_private
*dev_priv)
ppgtt-enable(ppgtt);
}
- if (i915.enable_execlists)
+ if (i915.enable_execlists) {
+ struct intel_context *dctx;
+
+ ring = dev_priv-ring[RCS];
+ dctx = ring-default_context;
+
+ if (!dctx-rcs_initialized) {
+ ret = intel_lr_context_render_state_init(ring, dctx);
+ if (ret) {
+ DRM_ERROR(Init render state failed: %d\n,
ret);
+ return ret;
+ }
+ dctx-rcs_initialized = true;
+ }
+
return 0;
+ }
This looks very much like the wrong place. We should init the render state
when we create the context, or when we switch to it for the first time.
The later is what the legacy contexts currently do in do_switch.
But ctx_enable should do the switch to the default context and that's
about it. If there's some depency then I guess we should stall the
creation of the default context a bit, maybe.
In any case someone needs to explain this better and if there's not other
wey this at least needs a bit comment. So I'll punt for now.
-Daniel
/* FIXME: We should make this work, even in reset */
if (i915_reset_in_progress(dev_priv-gpu_error))
diff --git a/drivers/gpu/drm/i915/i915_gem_render_state.c
b/drivers/gpu/drm/i915/i915_gem_render_state.c
index e60be3f..a9a62d7 100644
--- a/drivers/gpu/drm/i915/i915_gem_render_state.c
+++ b/drivers/gpu/drm/i915/i915_gem_render_state.c
@@ -28,13 +28,6 @@
#include i915_drv.h
#include intel_renderstate.h
-struct render_state {
- const struct intel_renderstate_rodata *rodata;
- struct drm_i915_gem_object *obj;
- u64 ggtt_offset;
- int gen;
-};
-
static const struct intel_renderstate_rodata *
render_state_get_rodata(struct drm_device *dev, const int gen)
{
@@ -127,30 +120,47 @@ static int render_state_setup(struct render_state *so)
return 0;
}
-static void render_state_fini(struct render_state *so)
+void i915_gem_render_state_fini(struct render_state *so)
{
i915_gem_object_ggtt_unpin(so-obj);
drm_gem_object_unreference(so-obj-base);
}
-int i915_gem_render_state_init(struct
