From: Daniel Vetter <daniel@ffwll.ch>
To: Chris Wilson <chris@chris-wilson.co.uk>,
Daniel Vetter <daniel@ffwll.ch>,
Jesse Barnes <jbarnes@virtuousgeek.org>,
intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/6] drm/i915: Replace hardcoded cacheline size with macro
Date: Thu, 3 Apr 2014 23:09:51 +0200 [thread overview]
Message-ID: <20140403210951.GN7225@phenom.ffwll.local> (raw)
In-Reply-To: <20140403152305.GL5602@nuc-i3427.alporthouse.com>
On Thu, Apr 03, 2014 at 04:23:05PM +0100, Chris Wilson wrote:
> On Thu, Apr 03, 2014 at 05:16:16PM +0200, Daniel Vetter wrote:
> > btw the 1k thing at least on i865G is iirc just the writeout fifo between
> > the cpu and the gmch to paper over FSB latencies (or whatever irked hw
> > designers).
>
> Isn't there a 1024 byte supercacheline for msaa as well? At least that
> sticks out in my mind from the discussions on when not to use eDRAM etc.
I've thought that was just a recommendation to not use eDRAM with
compressed msaa buffers since for those you only use the pixels on the
edges of primitives. And since one msaa pixel is less than the 1024bytes
the supercacheline is actual edram utilization for common workloads would
be horrible.
Or at least that's how I've interpreted the graphs and diagrams in the
docs. Afaik the coherency mocs bits for edram are still available on a 64
byte boundary, it's just the address tag which is much larger.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
next prev parent reply other threads:[~2014-04-03 21:09 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-02 15:36 [PATCH 1/6] drm/i915: Replace hardcoded cacheline size with macro Chris Wilson
2014-04-02 15:36 ` [PATCH 2/6] drm/i915: Move all ring resets before setting the HWS page Chris Wilson
2014-04-02 21:58 ` Jesse Barnes
2014-04-03 15:18 ` Daniel Vetter
2014-04-02 15:36 ` [PATCH 3/6] drm/i915: Preserve ring buffers objects across resume Chris Wilson
2014-04-02 22:10 ` Jesse Barnes
2014-04-03 6:43 ` Chris Wilson
2014-04-02 15:36 ` [PATCH 4/6] drm/i915: Allow the module to load even if we fail to setup rings Chris Wilson
2014-04-02 22:11 ` Jesse Barnes
2014-04-03 6:42 ` Chris Wilson
2014-04-02 15:36 ` [PATCH 5/6] drm/i915: Mark device as wedged if we fail to resume Chris Wilson
2014-04-02 15:36 ` [PATCH 6/6] drm/i915: Include a little more information about why ring init fails Chris Wilson
2014-04-02 21:57 ` [PATCH 1/6] drm/i915: Replace hardcoded cacheline size with macro Jesse Barnes
2014-04-03 6:45 ` Chris Wilson
2014-04-03 15:16 ` Daniel Vetter
2014-04-03 15:23 ` Chris Wilson
2014-04-03 21:09 ` Daniel Vetter [this message]
-- strict thread matches above, loose matches on Subject: below --
2014-04-09 8:19 Chris Wilson
2014-04-22 12:35 ` Mateo Lozano, Oscar
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=20140403210951.GN7225@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=chris@chris-wilson.co.uk \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jbarnes@virtuousgeek.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox