From: Jerome Glisse <glisse@freedesktop.org>
To: Keith Packard <keithp@keithp.com>
Cc: Nick Piggin <npiggin@suse.de>,
eric@anholt.net, hugh@veritas.com, hch@infradead.org,
airlied@linux.ie, jbarnes@virtuousgeek.org,
thomas@tungstengraphics.com, dri-devel@lists.sourceforge.net,
Linux Memory Management List <linux-mm@kvack.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [patch] mm: pageable memory allocator (for DRM-GEM?)
Date: Tue, 23 Sep 2008 20:29:40 +0200 [thread overview]
Message-ID: <20080923202940.a9ce8943.glisse@freedesktop.org> (raw)
In-Reply-To: <1222185029.4873.157.camel@koto.keithp.com>
On Tue, 23 Sep 2008 08:50:29 -0700
Keith Packard <keithp@keithp.com> wrote:
> On Tue, 2008-09-23 at 11:10 +0200, Nick Piggin wrote:
> > If my cursory reading is correct, then my allocator won't work so well as a
> > drop in replacement because one isn't allowed to know about the filp behind
> > the pageable object. It would also indicate some serious crack smoking by
> > anyone who thinks open(2), pread(2), mmap(2), etc is ugly in comparison...
>
> Yes, we'd like to be able to use regular system calls for our API, right
> now we haven't figured out how to do that.
>
> > So please, nobody who worked on that code is allowed to use ugly as an
> > argument. Technical arguments are fine, so let's try to cover them.
>
> I think we're looking for a mechanism that we know how to use and which
> will allow us to provide compatibility with user space going forward.
> Hiding the precise semantics of the object storage behind our
> ioctl-based API means that we can completely replace in the future
> without affecting user space.
>
I am starting to ponder if driver specific ioctl for memory object is a
better plan. On intel you have your GTT mapping trick (whether you want
to access an object through GTT or directly map ram page iirc), on radeon
i can think of similar but bit different use case where we can ask to
map some vram with special properties on it so we can access some tiled
surface transparently.
Of course the underlying implementation will share quite bit of code.
I just think that each hw have its own specificity and that trying to
hamer out all this in a common userspace API is not the best thing to do.
I am pretty sure nvidia hw offer some nice trick that won't fit in any
common userspace interface.
So the point is that Nick proposal does make lot of sense and i think
we should let each driver design their own memory object API to fit their
need. We don't have the need for a common interface anymore in DRI2.
Cheers,
Jerome Glisse <glisse@freedesktop.org>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2008-09-23 18:29 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-23 9:10 Nick Piggin
2008-09-23 10:21 ` Thomas Hellström
2008-09-23 11:31 ` Jerome Glisse
2008-09-23 13:18 ` Christoph Lameter
2008-09-25 0:18 ` Nick Piggin
2008-09-25 7:19 ` Thomas Hellström
2008-09-25 14:38 ` Keith Packard
2008-09-25 15:39 ` Thomas Hellström
2008-09-25 22:41 ` Dave Airlie
2008-09-23 15:50 ` Keith Packard
2008-09-23 18:29 ` Jerome Glisse [this message]
2008-09-25 0:30 ` Nick Piggin
2008-09-25 1:20 ` Keith Packard
2008-09-25 2:30 ` Nick Piggin
2008-09-25 2:43 ` Keith Packard
2008-09-25 3:07 ` Nick Piggin
2008-09-25 6:16 ` Keith Packard
2008-09-25 8:45 ` KAMEZAWA Hiroyuki
2008-09-30 1:10 ` Eric Anholt
2008-10-02 17:15 ` Jesse Barnes
2008-10-03 5:17 ` Keith Packard
2008-10-03 6:40 ` Nick Piggin
2008-09-23 9:10 Nick Piggin
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=20080923202940.a9ce8943.glisse@freedesktop.org \
--to=glisse@freedesktop.org \
--cc=airlied@linux.ie \
--cc=dri-devel@lists.sourceforge.net \
--cc=eric@anholt.net \
--cc=hch@infradead.org \
--cc=hugh@veritas.com \
--cc=jbarnes@virtuousgeek.org \
--cc=keithp@keithp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=npiggin@suse.de \
--cc=thomas@tungstengraphics.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