All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Wilson <chris@chris-wilson.co.uk>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Dave Airlie <airlied@linux.ie>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 21/21] drm/i915: Introduce vmap (mapping of user pages into video memory) ioctl
Date: Tue, 19 Apr 2011 07:20:47 +0100	[thread overview]
Message-ID: <849307$ci4pqk@azsmga001.ch.intel.com> (raw)
In-Reply-To: <20110418145817.GA3420@viiv.ffwll.ch>

Thanks for excellent comments... Skipping to the end for a quick response:

On Mon, 18 Apr 2011 16:58:17 +0200, Daniel Vetter <daniel@ffwll.ch> wrote:
> I have hopes that we might be able to subsume that use-case into the
> single-shot use-case by beefing up pwrite/read with a blt variant that
> does the right thing for 2d/tiled buffers (and also handles stride
> mismatches). That feels a bit more generally useful, which is why I lean a
> bit towards it. On the other hand we might turn vmap on it's head and
> create an shm id out of a bo for X to use (if X shm turns out to be the
> only user for such a thing).

This is where I started: a new 2D pread/pwrite ioctl that used the BLT if
it so desired.

This was flawed in my use cases by the synchronous nature of the API I
used. When I thought about introducing async versions, I realised that it
became so much simpler if I moved the entirety of the serialisation into
userspace and vmap was born. And then I realised that a vmap bo could be
used in places other than simple BLT uploads and downloads.

Meanwhile, I'm intrigued by the idea of integrating SHM and bo... The use
case is a bit narrow though, latter protocol designs already use the bo as
the natural transport.

Anyway, it looks like my next task is see if vmap is a workable interface
for Mesa as well. I'd much prefer spending another couple of months
addressing your comments and widening the use cases, so I can drop this
patch for this merge window.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

      reply	other threads:[~2011-04-19  6:20 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-16  9:17 i915 next, post-llc Chris Wilson
2011-04-16  9:17 ` [PATCH 01/21] drm/i915: Cache GT fifo count for SandyBridge Chris Wilson
2011-04-16  9:17 ` [PATCH 02/21] drm/i915: Refactor pwrite/pread to use single copy of get_user_pages Chris Wilson
2011-04-16  9:17 ` [PATCH 03/21] drm/i915: s/addr & ~PAGE_MASK/offset_in_page(addr)/ Chris Wilson
2011-04-16  9:17 ` [PATCH 04/21] drm/i915: Maintain fenced gpu access until we flush the fence Chris Wilson
2011-04-16  9:17 ` [PATCH 05/21] drm/i915: Invalidate fenced read domains upon flush Chris Wilson
2011-04-16  9:17 ` [PATCH 06/21] drm/i915: Pass the fence register number to be written Chris Wilson
2011-04-16  9:17 ` [PATCH 07/21] drm/i915: Track fence setup separately from fenced object lifetime Chris Wilson
2011-04-16 13:20   ` Daniel Vetter
2011-04-16  9:17 ` [PATCH 08/21] drm/i915: Only print out the actual number of fences for i915_error_state Chris Wilson
2011-04-16  9:17 ` [PATCH 09/21] drm/i915: Implement direct support for 24 bit LVDS pixel format Chris Wilson
2011-04-16  9:17 ` [PATCH 10/21] drm/i915: Implement manual override of LVDS single/dual channel mode Chris Wilson
2011-04-16  9:17 ` [PATCH 11/21] drm/i915/tv: Use a direct pointer for tv_mode Chris Wilson
2011-04-16  9:17 ` [PATCH 12/21] drm/i915: Replace ironlake_compute_wm0 with g4x_compute_wm0 Chris Wilson
2011-04-16  9:17 ` [PATCH 13/21] drm/i915/crt: Explicitly return false if connected to a digital monitor Chris Wilson
2011-04-16  9:17 ` [PATCH 14/21] drm/i915/i2c: Convert from using GMBUS1 + reg_offset idiom to reg + 0 Chris Wilson
2011-04-16  9:17 ` [PATCH 15/21] drm/i915/gmbus: Reset the controller on initialisation Chris Wilson
2011-04-16  9:17 ` [PATCH 16/21] drm/i915: Retire requests before disabling pagefaults Chris Wilson
2011-04-16 13:44   ` Daniel Vetter
2011-04-16  9:17 ` [PATCH 17/21] drm/i915: Repeat retiring of requests until the seqno is stable Chris Wilson
2011-04-16 13:45   ` Daniel Vetter
2011-04-16  9:17 ` [PATCH 18/21] drm/i915: Split out i915_gem_object_move_to_ring() from execbuffer Chris Wilson
2011-04-16 13:54   ` Daniel Vetter
2011-04-16 14:18     ` Chris Wilson
2011-04-16 14:24       ` Daniel Vetter
2011-04-16  9:17 ` [PATCH 19/21] drm/i915: Enable the use of GPU semaphores whilst page-flipping Chris Wilson
2011-04-16 13:58   ` Daniel Vetter
2011-04-16 14:20     ` Chris Wilson
2011-04-16  9:17 ` [PATCH 20/21] drm/i915: Use a slab for object allocation Chris Wilson
2011-04-16 14:07   ` Daniel Vetter
2011-04-16  9:17 ` [PATCH 21/21] drm/i915: Introduce vmap (mapping of user pages into video memory) ioctl Chris Wilson
2011-04-18 14:58   ` Daniel Vetter
2011-04-19  6:20     ` Chris Wilson [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='849307$ci4pqk@azsmga001.ch.intel.com' \
    --to=chris@chris-wilson.co.uk \
    --cc=airlied@linux.ie \
    --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.