From: Chris Wilson <chris@chris-wilson.co.uk>
To: Dave Airlie <airlied@gmail.com>, 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 08:32:33 +0100 [thread overview]
Message-ID: <849307$c7qtj5@azsmga001.ch.intel.com> (raw)
In-Reply-To: <AANLkTi=vFwoKCOsvyGBQA9w01QX_TwGu_GF6mA0grr2o@mail.gmail.com>
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.)
And I did play with a new pread/pwrite interface that did as you suggest,
binding the user pages and performing a blit. But by the time you make the
interface asynchronous, it becomes much easier to let the client code
create the mapping and be fully aware of the barriers.
And yes I do concur that vma bookkeeping does impose significant overheads
and I have been removing as many mappings from our drivers as I can; within
the limitations of the pwrite interface.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
next prev parent reply other threads:[~2011-03-30 7:32 UTC|newest]
Thread overview: 15+ 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 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 [this message]
2011-03-30 13:28 ` Jerome Glisse
2011-03-30 14:07 ` Chris Wilson
2011-03-30 15:07 ` Jerome Glisse
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='849307$c7qtj5@azsmga001.ch.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox