From: "Christian König" <deathsimple@vodafone.de>
To: Lauri Kasanen <cand@gmx.com>
Cc: jglisse@redhat.com, Thomas Hellstrom <thellstrom@vmware.com>,
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm: Add support for two-ended allocation, v2
Date: Wed, 02 Apr 2014 17:11:15 +0200 [thread overview]
Message-ID: <533C2893.5030202@vodafone.de> (raw)
In-Reply-To: <20140402175434.4ee3f283.cand@gmx.com>
Am 02.04.2014 16:54, schrieb Lauri Kasanen:
> On Wed, 02 Apr 2014 13:00:00 +0200
> Christian König <deathsimple@vodafone.de> wrote:
>
>> Nice idea, but I wouldn't put the decision where to place the buffer
>> into TTM based on it's size.
>>
>> Instead please make that a proper TTM placement flag because for example
>> for VM page tables we want them to be at the end of VRAM, not because
>> they are big (which they are anyway) but because they never accessed by
>> the CPU.
> I think there aren't many special cases like that, and they could
> already be handled by setting the first and last pages for the bo?
Nope, that would require the driver to find a certain position for the
buffer by itself.
The placement flag should just move allocation from preferring the start
of the address space to preferring the end of it.
What I wanted to note is that this way the driver could use this feature
in a much more flexible way, not only to change placement of buffers
based on the size, but also on other criteria as well (and yes I have
couple of use cases for this in mind).
Additional to that you could also separate the patch into adding this
functionality and enabling it for radeon, which in the end will allow
people to easier bisect it in the case something is wrong.
Apart from that the patch is a really nice piece of work,
Christian.
>
> - Lauri
prev parent reply other threads:[~2014-04-02 15:11 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-02 9:08 [PATCH] drm: Add support for two-ended allocation, v2 Lauri Kasanen
2014-04-02 11:00 ` Christian König
2014-04-02 14:54 ` Lauri Kasanen
2014-04-02 15:11 ` Christian König [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=533C2893.5030202@vodafone.de \
--to=deathsimple@vodafone.de \
--cc=cand@gmx.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=jglisse@redhat.com \
--cc=thellstrom@vmware.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.