From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: "Weng, Chuanbo" <chuanbo.weng@intel.com>
Cc: "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>
Subject: Re: Does display engine read contents from LLC of scanout buffer?
Date: Wed, 7 Dec 2016 16:09:59 +0200 [thread overview]
Message-ID: <20161207140959.GJ31595@intel.com> (raw)
In-Reply-To: <5A0E318D73C83C40A09BDBBE131796D738CBA5A3@shsmsx102.ccr.corp.intel.com>
On Wed, Dec 07, 2016 at 11:30:37AM +0000, Weng, Chuanbo wrote:
> Hi Ville,
> Thanks for your useful info.
> How about L3 cache? In my scenario, Beignet will use Read Write Data Port to write data (typed write) to bo.
> So the cache path is L3 -> LLC -> memory. So only leave LLC cache ability the same as PTEs is not enough.
> In order to make data access efficient, I set L3 to WB. So is there a way to flush L3 cache to memory?
I don't recall. But actually caching in L3 is dangerous anyway since
IIRC L3 evictions can land in LLC despite the LLC cacheability being set
to UC/WT. Or at least there was a note stating that in bspec at some
point. So to be totally correct you should not use L3 either. Well, I
suppose you could use L3 as a RO cache, but sounds like you want to write
as well.
>
> Thanks,
> Chuanbo Weng
>
> -----Original Message-----
> From: Ville Syrjälä [mailto:ville.syrjala@linux.intel.com]
> Sent: Friday, November 25, 2016 3:07 AM
> To: Weng, Chuanbo <chuanbo.weng@intel.com>
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] Does display engine read contents from LLC of scanout buffer?
>
> On Thu, Nov 24, 2016 at 06:20:22PM +0000, Weng, Chuanbo wrote:
> > Hi all,
> > I have a question of display (forgive me if it's too simple because I'm not familiar with display):
> >
> > My scenario is as below:
> > gbm_bo_create to create gbm_bo
> > Get its handle
> > drmModeAddFB to specify this bo as scanout buffer
> > do rendering to this bo by OpenCL(Beignet)
> > drmModePageFlip to do page flip
> >
> > Does display engine directly read contents from scanout
> > buffer or read contents from LLC of this scanout buffer?
>
> The display engine sits between the LLC and main memory effectively, so the answer is that it always reads directly from memory. When you make a bo a scanout buffer the kernel will flush the caches and reconfigure the PTEs to UC/WC so that subsequent rendering will hit memory directly.
> And that also means you should never override potential scanout buffers to WB via MOCS, and instead you should leave the choice up to the PTEs.
>
> --
> Ville Syrjälä
> Intel OTC
--
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-12-07 14:10 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-24 18:20 Does display engine read contents from LLC of scanout buffer? Weng, Chuanbo
2016-11-24 19:07 ` Ville Syrjälä
2016-12-07 11:30 ` Weng, Chuanbo
2016-12-07 14:09 ` Ville Syrjälä [this message]
2016-12-08 9:14 ` Weng, Chuanbo
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=20161207140959.GJ31595@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=chuanbo.weng@intel.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox