From: Lucas Stach <dev@lynxeye.de>
To: Ben Skeggs <skeggsb@gmail.com>
Cc: "nouveau@lists.freedesktop.org" <nouveau@lists.freedesktop.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 4/6] drm/nouveau: introduce NOUVEAU_GEM_TILE_WCUS
Date: Wed, 28 Aug 2013 09:39:30 +0200 [thread overview]
Message-ID: <1377675570.1624.9.camel@tellur> (raw)
In-Reply-To: <CACAvsv5EbqpS+f99Q9-oJxm3pz+42wEYNPSHcDe2GbLwvEH4TQ@mail.gmail.com>
Am Mittwoch, den 28.08.2013, 17:11 +1000 schrieb Ben Skeggs:
> On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach <dev@lynxeye.de> wrote:
> > This flag allows userspace to give the kernel a hint that it should use
> > a non-snooped resource. To guarantee coherency at all times mappings
> > into userspace are done write combined, so userspace should avoid
> > reading back from those resources.
> Do any other combinations of cached/uncached and snooped/non-snooped
> make any sense? If so, perhaps we want to split the flags.
>
Thought about that and I came to the conclusion that it isn't worth the
hassle. If we split it then things get more complicated on x86, were we
would have to invalidate caches manually with all the related
performance implications.
So I think it's a lot easier for userspace writers to just set the WCUS
flag on resources where the can promise no to touch the resource for
reading (AFAIR Christoph wanted this flag mostly for resources that the
driver isn't going to touch ever), or where it can happily live with
uncached reading.
> >
> > Signed-off-by: Lucas Stach <dev@lynxeye.de>
> > ---
> > On x86 an optimized userspace can save up on snoop traffic in the
> > system, on ARM the benefits are potentially much larger, as we can save
> > the manual cache flush/invalidate.
> > ---
> > drivers/gpu/drm/nouveau/nouveau_bo.c | 11 ++++++++++-
> > drivers/gpu/drm/nouveau/nouveau_bo.h | 1 +
> > include/uapi/drm/nouveau_drm.h | 1 +
> > 3 files changed, 12 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > index f4a2eb9..c5fcbcc 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> > +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > @@ -231,6 +231,12 @@ nouveau_bo_new(struct drm_device *dev, int size, int align,
> >
> > nouveau_bo_fixup_align(nvbo, flags, &align, &size);
> > nvbo->bo.mem.num_pages = size >> PAGE_SHIFT;
> > +
> > + if (tile_flags & NOUVEAU_GEM_TILE_WCUS)
> > + nvbo->valid_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
> > + else
> > + nvbo->valid_caching = TTM_PL_MASK_CACHING;
> > +
> > nouveau_bo_placement_set(nvbo, flags, 0);
> >
> > acc_size = ttm_bo_dma_acc_size(&drm->ttm.bdev, size,
> > @@ -292,7 +298,7 @@ void
> > nouveau_bo_placement_set(struct nouveau_bo *nvbo, uint32_t type, uint32_t busy)
> > {
> > struct ttm_placement *pl = &nvbo->placement;
> > - uint32_t flags = TTM_PL_MASK_CACHING |
> > + uint32_t flags = nvbo->valid_caching |
> > (nvbo->pin_refcnt ? TTM_PL_FLAG_NO_EVICT : 0);
> >
> > pl->placement = nvbo->placements;
> > @@ -1554,6 +1560,9 @@ nouveau_bo_vma_add(struct nouveau_bo *nvbo, struct nouveau_vm *vm,
> > if (nvbo->bo.mem.mem_type == TTM_PL_VRAM)
> > nouveau_vm_map(vma, nvbo->bo.mem.mm_node);
> > else if (nvbo->bo.mem.mem_type == TTM_PL_TT) {
> > + if (!(nvbo->valid_caching & TTM_PL_FLAG_CACHED))
> > + vma->access |= NV_MEM_ACCESS_NOSNOOP;
> > +
> > if (node->sg)
> > nouveau_vm_map_sg_table(vma, 0, size, node);
> > else
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.h b/drivers/gpu/drm/nouveau/nouveau_bo.h
> > index 653dbbb..2ecf8b7 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_bo.h
> > +++ b/drivers/gpu/drm/nouveau/nouveau_bo.h
> > @@ -9,6 +9,7 @@ struct nouveau_bo {
> > struct ttm_buffer_object bo;
> > struct ttm_placement placement;
> > u32 valid_domains;
> > + u32 valid_caching;
> > u32 placements[3];
> > u32 busy_placements[3];
> > struct ttm_bo_kmap_obj kmap;
> > diff --git a/include/uapi/drm/nouveau_drm.h b/include/uapi/drm/nouveau_drm.h
> > index 2a5769f..4948eee2 100644
> > --- a/include/uapi/drm/nouveau_drm.h
> > +++ b/include/uapi/drm/nouveau_drm.h
> > @@ -36,6 +36,7 @@
> > #define NOUVEAU_GEM_TILE_32BPP 0x00000002
> > #define NOUVEAU_GEM_TILE_ZETA 0x00000004
> > #define NOUVEAU_GEM_TILE_NONCONTIG 0x00000008
> > +#define NOUVEAU_GEM_TILE_WCUS 0x00000010 /* write-combined, unsnooped */
> >
> > struct drm_nouveau_gem_info {
> > uint32_t handle;
> > --
> > 1.8.3.1
> >
next prev parent reply other threads:[~2013-08-28 7:39 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-28 0:00 [PATCH 0/6] Nouveau on ARM fixes Lucas Stach
2013-08-28 0:00 ` [PATCH 1/6] drm/ttm: recognize ARM arch in ioprot handler Lucas Stach
2013-08-28 0:00 ` [PATCH 2/6] drm/ttm: introduce dma cache sync helpers Lucas Stach
2013-08-28 0:00 ` [PATCH 4/6] drm/nouveau: introduce NOUVEAU_GEM_TILE_WCUS Lucas Stach
2013-08-28 7:11 ` Ben Skeggs
2013-08-28 7:39 ` Lucas Stach [this message]
2013-08-28 0:00 ` [PATCH 5/6] drm/nouveau: map IB write-combined Lucas Stach
[not found] ` <1377648050-6649-1-git-send-email-dev-8ppwABl0HbeELgA04lAiVw@public.gmane.org>
2013-08-28 0:00 ` [PATCH 3/6] drm/nouveau: hook up cache sync functions Lucas Stach
2013-08-28 16:43 ` Konrad Rzeszutek Wilk
[not found] ` <20130828164357.GB27172-6K5HmflnPlqSPmnEAIUT9EEOCMrvLtNR@public.gmane.org>
2013-08-28 16:58 ` Lucas Stach
2013-08-28 18:21 ` Konrad Rzeszutek Wilk
2013-08-28 0:00 ` [PATCH 6/6] drm/nouveau: use MSI interrupts Lucas Stach
[not found] ` <1377648050-6649-7-git-send-email-dev-8ppwABl0HbeELgA04lAiVw@public.gmane.org>
2013-08-28 7:09 ` Ben Skeggs
2013-08-28 7:28 ` Lucas Stach
2013-08-28 13:54 ` Ilia Mirkin
2013-08-29 0:07 ` Ben Skeggs
[not found] ` <CACAvsv7Ew+0icWEq6ixdtP9Vpux4zeWjV5Lpih94YZWgs_jx4A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-08-29 2:20 ` Ilia Mirkin
2013-08-29 4:45 ` Ben Skeggs
2013-08-29 5:00 ` Ilia Mirkin
2013-08-29 5:07 ` Ben Skeggs
[not found] ` <CACAvsv4AZo-B3MtTh3oN946YAC=vPiR=S3TsEg7R2-hEma57tg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-08-30 1:10 ` Ilia Mirkin
2013-08-30 1:58 ` Ben Skeggs
2013-08-30 2:00 ` Ben Skeggs
[not found] ` <CACAvsv5f3vfP1Fs41N=L8Sc_ih32_h5Vz44mjMTJ-WXH9mDe0A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-08-30 2:01 ` Ilia Mirkin
2013-08-30 5:36 ` Ben Skeggs
2013-08-30 7:11 ` Lucas Stach
2013-09-04 1:45 ` Ben Skeggs
2013-09-30 17:27 ` [Nouveau] " Peter Hurley
[not found] ` <5249B494.5020500-WaGBZJeGNqdsbIuE7sb01tBPR1lH4CV8@public.gmane.org>
2013-10-01 17:32 ` Peter Hurley
2013-08-28 16:08 ` Konrad Rzeszutek Wilk
2013-08-28 7:50 ` [PATCH 0/6] Nouveau on ARM fixes Thierry Reding
2013-08-28 8:09 ` Ben Skeggs
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=1377675570.1624.9.camel@tellur \
--to=dev@lynxeye.de \
--cc=dri-devel@lists.freedesktop.org \
--cc=nouveau@lists.freedesktop.org \
--cc=skeggsb@gmail.com \
/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.