All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	Daniel Vetter <daniel@ffwll.ch>,
	ankitprasad.r.sharma@intel.com, intel-gfx@lists.freedesktop.org,
	akash.goel@intel.com, shashidhar.hiremath@intel.com
Subject: Re: [PATCH v7 0/5] Support for creating/using Stolen memory backed objects
Date: Wed, 23 Sep 2015 19:09:04 +0200	[thread overview]
Message-ID: <20150923170904.GQ3383@phenom.ffwll.local> (raw)
In-Reply-To: <20150923161904.GJ6739@nuc-i3427.alporthouse.com>

On Wed, Sep 23, 2015 at 05:19:04PM +0100, Chris Wilson wrote:
> On Wed, Sep 23, 2015 at 05:14:25PM +0100, Chris Wilson wrote:
> > As far as users go, I'm dubious as to the merits of using stolen (and so
> > have not written patches for the ddx/mesa) simply because we do not have
> > CPU access to them and so that excludes using all of the fast paths and
> > general flexibility. And I have complications like if I allocate a buffer
> > from stolen I need to migrate it if it is exported to a client over
> > DRI2/DRI3 (because I can't communicate that it is not first class). For
> > internal auxiliary buffers (which aren't that many as they get recycled
> > quickly like vertex/batch/instruction/temporary buffers), the quandary is
> > to save a few hundred KiB of memory or stick to fast access along generic
> > paths.
> 
> Typical, hit send and think of a use. Scratch for EU kernels - can be a
> few megabytes in size and do not need user access.

Well whatever it is, it better exists before I'm pulling this series in
... And scratch would be good since then it doesn't matter if we totally
nuke the contents on hibernate when the gpu is idled.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

      reply	other threads:[~2015-09-23 17:06 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-23 10:51 [PATCH v7 0/5] Support for creating/using Stolen memory backed objects ankitprasad.r.sharma
2015-09-23 10:51 ` [PATCH 1/5] drm/i915: Clearing buffer objects via CPU/GTT ankitprasad.r.sharma
2015-09-23 10:51 ` [PATCH 2/5] drm/i915: Support for creating Stolen memory backed objects ankitprasad.r.sharma
2015-09-23 10:51 ` [PATCH 3/5] drm/i915: Add support for stealing purgable stolen pages ankitprasad.r.sharma
2015-09-23 11:42   ` Chris Wilson
2015-09-23 10:51 ` [PATCH 4/5] drm/i915: Support for pread/pwrite from/to non shmem backed objects ankitprasad.r.sharma
2015-09-23 11:50   ` Chris Wilson
2015-09-23 10:51 ` [PATCH 5/5] drm/i915: Propagating correct error codes to the userspace ankitprasad.r.sharma
2015-09-23 11:32   ` Chris Wilson
2015-09-23 13:14     ` [PATCH] drm/i915: Propagate error from drm_gem_object_init() Chris Wilson
2015-09-23 16:03 ` [PATCH v7 0/5] Support for creating/using Stolen memory backed objects Daniel Vetter
2015-09-23 16:14   ` Chris Wilson
2015-09-23 16:19     ` Chris Wilson
2015-09-23 17:09       ` Daniel Vetter [this message]

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=20150923170904.GQ3383@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=akash.goel@intel.com \
    --cc=ankitprasad.r.sharma@intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=shashidhar.hiremath@intel.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.