From: Jesse Barnes <jbarnes@virtuousgeek.org>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 3/9] drm/i915: add a HSW scratch location for flush commands
Date: Tue, 25 Sep 2012 05:08:12 -0700 [thread overview]
Message-ID: <20120925050812.3dea029a@jbarnes-desktop> (raw)
In-Reply-To: <CAKMK7uGsZpk04EPgFHY8b9uPV-0bKgsj_+KtrhmrH+rdKHg6=w@mail.gmail.com>
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...
--
Jesse Barnes, Intel Open Source Technology Center
next prev parent reply other threads:[~2012-09-25 12:08 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-19 20:28 [PATCH 1/9] drm/i915: disable DOP clock gating on VLV and IVB Jesse Barnes
2012-09-19 20:28 ` [PATCH 2/9] drm/i915: implement WaForceL3Serialization " Jesse Barnes
2012-09-19 20:28 ` [PATCH 3/9] drm/i915: add a HSW scratch location for flush commands Jesse Barnes
2012-09-25 8:54 ` Daniel Vetter
2012-09-25 11:08 ` Jesse Barnes
2012-09-25 11:47 ` Daniel Vetter
2012-09-25 12:08 ` Jesse Barnes [this message]
2012-09-19 20:28 ` [PATCH 4/9] drm/i915: add post-flush store dw workaround Jesse Barnes
2012-09-25 8:49 ` Daniel Vetter
2012-09-25 11:07 ` Jesse Barnes
2012-09-19 20:28 ` [PATCH 5/9] drm/i915: implement WaDisableEarlyCull for VLV and IVB Jesse Barnes
2012-09-19 20:29 ` [PATCH 6/9] drm/i915: implement WaDisablePSDDualDispatchEnable on IVB and VLV Jesse Barnes
2012-09-25 8:51 ` Daniel Vetter
2012-10-01 16:52 ` Lespiau, Damien
2012-10-01 16:56 ` Jesse Barnes
2012-10-01 17:07 ` Lespiau, Damien
2012-10-01 16:57 ` Lespiau, Damien
2012-09-19 20:29 ` [PATCH 7/9] drm/i915: limit VLV IRQ enables to those we use Jesse Barnes
2012-09-26 14:16 ` Daniel Vetter
2012-09-19 20:29 ` [PATCH 8/9] drm/i915: TLB invalidation with MI_FLUSH_SW requires a post-sync op Jesse Barnes
2012-09-19 20:29 ` [PATCH 9/9] drm/i915: PIPE_CONTROL TLB invalidate requires CS stall Jesse Barnes
2012-09-19 21:41 ` [PATCH 1/9] drm/i915: disable DOP clock gating on VLV and IVB Ben Widawsky
2012-09-19 22:06 ` Jesse Barnes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120925050812.3dea029a@jbarnes-desktop \
--to=jbarnes@virtuousgeek.org \
--cc=daniel@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.