All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Wilson <chris@chris-wilson.co.uk>
To: Jerome Glisse <j.glisse@gmail.com>
Cc: Dave Airlie <airlied@gmail.com>, r6144 <rainy6144@gmail.com>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: GEM-related desktop sluggishness due to linear-time arch_get_unmapped_area_topdown()
Date: Wed, 30 Mar 2011 15:07:28 +0100	[thread overview]
Message-ID: <b7da2f$qtmdi3@fmsmga001.fm.intel.com> (raw)
In-Reply-To: <AANLkTinxVznFtHwM2RM3kNm9-eSXuz9L7TgfaMpgu=uZ@mail.gmail.com>

On Wed, 30 Mar 2011 09:28:07 -0400, Jerome Glisse <j.glisse@gmail.com> wrote:
> On Wed, Mar 30, 2011 at 3:32 AM, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> > On Wed, 30 Mar 2011 07:57:49 +1000, Dave Airlie <airlied@gmail.com> wrote:
> >> On Wed, Mar 30, 2011 at 7:04 AM, Jerome Glisse <j.glisse@gmail.com> wrote:
> >> > What i had in mind was something little bit more advance that pwrite,
> >> > somethings that would take width,height,pitch of userpage and would be
> >> > able to perform proper blit. But yes pwrite in intel is kind of
> >> > limited.
> >>
> >> TTM has support for userpage binding we just don't use it.
> >
> > Yes, and I've been experimenting with the same in GEM to great effect in
> > the DDX. The complication remains in managing the CPU synchronisation,
> > which suggests that it would only be useful for STREAM_DRAW objects (and
> > perhaps the sub-region updates to STATIC_DRAW). (And for readback, if
> > retrieving the data were the actual bottleneck.)
> 
> What do you mean by CPU synchronisation ? In what i had in mind the
> upload/download would block userspace until operation is, this would
> make upload/dowload barrier of course it doesn't play well with
> usecase where you keep uploading/downloading (idea to aleviate that is
> to allow several download/upload in one ioctl call).

Yes, that is the issue: having to control access to the user pages whilst
they are in use by the GPU. A completely synchronous API for performing
a single pwrite with the blitter is too slow, much slower than doing an
uncached write with the CPU and queueing up multiple blits (as we
currently do).

The API I ended up with for the pwrite using the BLT was to specify a 2D
region (addr, width, height, stride, flags etc) and list of clip rects. At
which point I grew disenchanted, and realised that simply creating a bo
for mapping user pages was the far better solution.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

WARNING: multiple messages have this Message-ID (diff)
From: Chris Wilson <chris@chris-wilson.co.uk>
To: Jerome Glisse <j.glisse@gmail.com>
Cc: r6144 <rainy6144@gmail.com>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: GEM-related desktop sluggishness due to linear-time arch_get_unmapped_area_topdown()
Date: Wed, 30 Mar 2011 15:07:28 +0100	[thread overview]
Message-ID: <b7da2f$qtmdi3@fmsmga001.fm.intel.com> (raw)
In-Reply-To: <AANLkTinxVznFtHwM2RM3kNm9-eSXuz9L7TgfaMpgu=uZ@mail.gmail.com>

On Wed, 30 Mar 2011 09:28:07 -0400, Jerome Glisse <j.glisse@gmail.com> wrote:
> On Wed, Mar 30, 2011 at 3:32 AM, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> > On Wed, 30 Mar 2011 07:57:49 +1000, Dave Airlie <airlied@gmail.com> wrote:
> >> On Wed, Mar 30, 2011 at 7:04 AM, Jerome Glisse <j.glisse@gmail.com> wrote:
> >> > What i had in mind was something little bit more advance that pwrite,
> >> > somethings that would take width,height,pitch of userpage and would be
> >> > able to perform proper blit. But yes pwrite in intel is kind of
> >> > limited.
> >>
> >> TTM has support for userpage binding we just don't use it.
> >
> > Yes, and I've been experimenting with the same in GEM to great effect in
> > the DDX. The complication remains in managing the CPU synchronisation,
> > which suggests that it would only be useful for STREAM_DRAW objects (and
> > perhaps the sub-region updates to STATIC_DRAW). (And for readback, if
> > retrieving the data were the actual bottleneck.)
> 
> What do you mean by CPU synchronisation ? In what i had in mind the
> upload/download would block userspace until operation is, this would
> make upload/dowload barrier of course it doesn't play well with
> usecase where you keep uploading/downloading (idea to aleviate that is
> to allow several download/upload in one ioctl call).

Yes, that is the issue: having to control access to the user pages whilst
they are in use by the GPU. A completely synchronous API for performing
a single pwrite with the blitter is too slow, much slower than doing an
uncached write with the CPU and queueing up multiple blits (as we
currently do).

The API I ended up with for the pwrite using the BLT was to specify a 2D
region (addr, width, height, stride, flags etc) and list of clip rects. At
which point I grew disenchanted, and realised that simply creating a bo
for mapping user pages was the far better solution.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

  reply	other threads:[~2011-03-30 14:07 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-28 11:16 GEM-related desktop sluggishness due to linear-time arch_get_unmapped_area_topdown() r6144
2011-03-28 18:13 ` Lucas Stach
2011-03-29 14:22   ` Jerome Glisse
2011-03-29 14:44     ` r6144
2011-03-29 15:23       ` Jerome Glisse
2011-03-29 18:01         ` Lucas Stach
2011-03-29 18:01           ` Lucas Stach
2011-03-29 19:45           ` Jerome Glisse
2011-03-29 20:26             ` Daniel Vetter
2011-03-29 21:04               ` Jerome Glisse
2011-03-29 21:57                 ` Dave Airlie
2011-03-30  7:32                   ` Chris Wilson
2011-03-30 13:28                     ` Jerome Glisse
2011-03-30 14:07                       ` Chris Wilson [this message]
2011-03-30 14:07                         ` Chris Wilson
2011-03-30 15:07                         ` Jerome Glisse
2011-03-30 15:22                           ` Chris Wilson
2011-03-30 15:22                             ` Chris Wilson

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='b7da2f$qtmdi3@fmsmga001.fm.intel.com' \
    --to=chris@chris-wilson.co.uk \
    --cc=airlied@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=j.glisse@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rainy6144@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.