From: Thomas Hellstrom <thellstrom@vmware.com>
To: Jerome Glisse <glisse@freedesktop.org>
Cc: "airlied@linux.ie" <airlied@linux.ie>,
Jerome Glisse <j.glisse@gmail.com>,
Luca Barbieri <luca@luca-barbieri.com>,
"dri-devel@lists.sourceforge.net"
<dri-devel@lists.sourceforge.net>
Subject: Re: [PATCH] drm/ttm: Only try to preserve caching in moves in the same space
Date: Mon, 01 Feb 2010 17:18:13 +0100 [thread overview]
Message-ID: <4B66FEC5.9050503@vmware.com> (raw)
In-Reply-To: <20100201133317.GH29000@localhost.localdomain>
Jerome Glisse wrote:
> On Mon, Feb 01, 2010 at 11:35:21AM +1000, Dave Airlie wrote:
>
>> On Thu, Jan 28, 2010 at 7:26 PM, Luca Barbieri <luca@luca-barbieri.com> wrote:
>>
>>> Currently TTM tries to preserve the previous caching even for moves
>>> between unrelated memory spaces.
>>>
>>> This results for instance in moves from VRAM to PCIE GART changing
>>> system memory to WC state needlessly.
>>>
>>> This patch changes TTM to only try to preserve caching if moving from
>>> system/TT to system/TT.
>>>
>>> In theory, we should also do that if moving between two device memory
>>> spaces that are backend by the same physical memory area.
>>> However, I'm not sure how to do that in the current TTM framework and
>>> I suspect no card/driver uses memory spaces in that way.
>>>
>> Thomas or Jerome (since I think placement changes were you), any
>> chance of ack or review?
>>
>> Dave.
>>
>>
>
> I think i will NACK, the idea to avoid switching to WC is good but i think it
> can be achieve with current code by using cleverly the infrastructure.
>
I agree with Jerome. It *should* be possible to have the driver control
this sort of thing depending on what triggered the validate / move call.
Thanks,
Thomas
------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
--
next prev parent reply other threads:[~2010-02-01 16:18 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-28 9:26 [PATCH] drm/ttm: Only try to preserve caching in moves in the same space Luca Barbieri
2010-02-01 1:35 ` Dave Airlie
2010-02-01 13:33 ` Jerome Glisse
2010-02-01 16:18 ` Thomas Hellstrom [this message]
2010-02-01 16:26 ` Luca Barbieri
2010-02-01 16:28 ` Luca Barbieri
2010-02-01 17:05 ` Jerome Glisse
2010-02-01 17:46 ` Luca Barbieri
2010-02-01 18:05 ` Jerome Glisse
2010-02-01 18:21 ` Luca Barbieri
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=4B66FEC5.9050503@vmware.com \
--to=thellstrom@vmware.com \
--cc=airlied@linux.ie \
--cc=dri-devel@lists.sourceforge.net \
--cc=glisse@freedesktop.org \
--cc=j.glisse@gmail.com \
--cc=luca@luca-barbieri.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.