| Message ID | 1348086543-24427-3-git-send-email-jbarnes@virtuousgeek.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, Sep 19, 2012 at 01:28:57PM -0700, Jesse Barnes wrote: > Some commands and workarounds require stores to occur to function > correctly, so add some scratch space to the HWS page to accommodate > them. > > Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> > --- > drivers/gpu/drm/i915/intel_ringbuffer.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h b/drivers/gpu/drm/i915/intel_ringbuffer.h > index 2ea7a31..ef85742 100644 > --- a/drivers/gpu/drm/i915/intel_ringbuffer.h > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h > @@ -181,6 +181,7 @@ intel_read_status_page(struct intel_ring_buffer *ring, > * The area from dword 0x20 to 0x3ff is available for driver usage. > */ > #define I915_GEM_HWS_INDEX 0x20 > +#define I915_GEM_SCRATCH_INDEX 0x28 /* Some commands need a scratch store */ Any specific reason for using an index divisible by 8? Afaik this is an index, and the hw multiplies by 4 on it's own. So looks a bit puzzling when reading (since iirc only 0x21 is used anywhere else, in some dri1 stuff). -Daniel > > void intel_cleanup_ring_buffer(struct intel_ring_buffer *ring); > > -- > 1.7.9.5 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Tue, 25 Sep 2012 10:54:00 +0200 Daniel Vetter <daniel@ffwll.ch> wrote: > On Wed, Sep 19, 2012 at 01:28:57PM -0700, Jesse Barnes wrote: > > Some commands and workarounds require stores to occur to function > > correctly, so add some scratch space to the HWS page to accommodate > > them. > > > > Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> > > --- > > drivers/gpu/drm/i915/intel_ringbuffer.h | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h b/drivers/gpu/drm/i915/intel_ringbuffer.h > > index 2ea7a31..ef85742 100644 > > --- a/drivers/gpu/drm/i915/intel_ringbuffer.h > > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h > > @@ -181,6 +181,7 @@ intel_read_status_page(struct intel_ring_buffer *ring, > > * The area from dword 0x20 to 0x3ff is available for driver usage. > > */ > > #define I915_GEM_HWS_INDEX 0x20 > > +#define I915_GEM_SCRATCH_INDEX 0x28 /* Some commands need a scratch store */ > > Any specific reason for using an index divisible by 8? Afaik this is an > index, and the hw multiplies by 4 on it's own. So looks a bit puzzling > when reading (since iirc only 0x21 is used anywhere else, in some dri1 > stuff). I got scared when I saw something about qword alignment in the docs.
On Tue, Sep 25, 2012 at 1:08 PM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote: > On Tue, 25 Sep 2012 10:54:00 +0200 > Daniel Vetter <daniel@ffwll.ch> wrote: > >> On Wed, Sep 19, 2012 at 01:28:57PM -0700, Jesse Barnes wrote: >> > Some commands and workarounds require stores to occur to function >> > correctly, so add some scratch space to the HWS page to accommodate >> > them. >> > >> > Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> >> > --- >> > drivers/gpu/drm/i915/intel_ringbuffer.h | 1 + >> > 1 file changed, 1 insertion(+) >> > >> > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h b/drivers/gpu/drm/i915/intel_ringbuffer.h >> > index 2ea7a31..ef85742 100644 >> > --- a/drivers/gpu/drm/i915/intel_ringbuffer.h >> > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h >> > @@ -181,6 +181,7 @@ intel_read_status_page(struct intel_ring_buffer *ring, >> > * The area from dword 0x20 to 0x3ff is available for driver usage. >> > */ >> > #define I915_GEM_HWS_INDEX 0x20 >> > +#define I915_GEM_SCRATCH_INDEX 0x28 /* Some commands need a scratch store */ >> >> Any specific reason for using an index divisible by 8? Afaik this is an >> index, and the hw multiplies by 4 on it's own. So looks a bit puzzling >> when reading (since iirc only 0x21 is used anywhere else, in some dri1 >> stuff). > > I got scared when I saw something about qword alignment in the docs. Afaik you need the qword alignment only when doing a qword write. And iirc that only works with writes to gtt address (not status page offsets). And for 64bit store_dw writes I remember some further restrictions (at least on some pipes). One thing I wonder is whether these workarounds still work when using a status page store dw and not a direct write to a gtt address though ... -Daniel
On Tue, 25 Sep 2012 13:47:54 +0200 Daniel Vetter <daniel@ffwll.ch> wrote: > On Tue, Sep 25, 2012 at 1:08 PM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote: > > On Tue, 25 Sep 2012 10:54:00 +0200 > > Daniel Vetter <daniel@ffwll.ch> wrote: > > > >> On Wed, Sep 19, 2012 at 01:28:57PM -0700, Jesse Barnes wrote: > >> > Some commands and workarounds require stores to occur to function > >> > correctly, so add some scratch space to the HWS page to accommodate > >> > them. > >> > > >> > Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> > >> > --- > >> > drivers/gpu/drm/i915/intel_ringbuffer.h | 1 + > >> > 1 file changed, 1 insertion(+) > >> > > >> > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h b/drivers/gpu/drm/i915/intel_ringbuffer.h > >> > index 2ea7a31..ef85742 100644 > >> > --- a/drivers/gpu/drm/i915/intel_ringbuffer.h > >> > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h > >> > @@ -181,6 +181,7 @@ intel_read_status_page(struct intel_ring_buffer *ring, > >> > * The area from dword 0x20 to 0x3ff is available for driver usage. > >> > */ > >> > #define I915_GEM_HWS_INDEX 0x20 > >> > +#define I915_GEM_SCRATCH_INDEX 0x28 /* Some commands need a scratch store */ > >> > >> Any specific reason for using an index divisible by 8? Afaik this is an > >> index, and the hw multiplies by 4 on it's own. So looks a bit puzzling > >> when reading (since iirc only 0x21 is used anywhere else, in some dri1 > >> stuff). > > > > I got scared when I saw something about qword alignment in the docs. > > Afaik you need the qword alignment only when doing a qword write. And > iirc that only works with writes to gtt address (not status page > offsets). And for 64bit store_dw writes I remember some further > restrictions (at least on some pipes). > > One thing I wonder is whether these workarounds still work when using > a status page store dw and not a direct write to a gtt address though > ... I think they do, but we should come up with a torture test for stuff like this...
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h b/drivers/gpu/drm/i915/intel_ringbuffer.h index 2ea7a31..ef85742 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.h +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h @@ -181,6 +181,7 @@ intel_read_status_page(struct intel_ring_buffer *ring, * The area from dword 0x20 to 0x3ff is available for driver usage. */ #define I915_GEM_HWS_INDEX 0x20 +#define I915_GEM_SCRATCH_INDEX 0x28 /* Some commands need a scratch store */ void intel_cleanup_ring_buffer(struct intel_ring_buffer *ring);
Some commands and workarounds require stores to occur to function correctly, so add some scratch space to the HWS page to accommodate them. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> --- drivers/gpu/drm/i915/intel_ringbuffer.h | 1 + 1 file changed, 1 insertion(+)