From: Jonathan Campbell <jon@nerdgrounds.com>
To: Mark Knecht <markknecht@gmail.com>
Cc: Linux Kernel List <linux-kernel@vger.kernel.org>
Subject: Re: Vramfs: filesystem driver to utilize extra RAM on VGA devices
Date: Mon, 26 Jan 2009 21:07:27 -0800 [thread overview]
Message-ID: <497E968F.3020708@nerdgrounds.com> (raw)
In-Reply-To: <5bdc1c8b0901261859g58a413e1x52208a6f2c1f9ccd@mail.gmail.com>
> Can the GPU use the data placed in your file system?
Assuming the GPU can access any part of VRAM, yes. Files created in
vramfs will always have content that exists somewhere in video ram. A
file you create never moves, and is always contiguous in memory. All
your program needs to direct the GPU to it is the block offset from the
start of VRAM, which can be obtained by an ioctl() or bmap().
I thought the best possible design would be for any process to create a
file in vramfs, and then direct the attention of whoever's managing the
GPU to that file (perhaps a user-space daemon), who could open the file
and use bmap or an ioctl to locate it and direct the GPU to operate on it.
I'd also like to point out the filesystem structures themselves are
never placed in VRAM on purpose. I'd hate for files to suddenly
disappear from the filesystem because of an errant GPU bug or pixel
shader gone amok; the worst that can happen by doing it that way is that
a bunch of files go blank or get filled with garbage and no harm done.
> Do you have strong control as to exactly how the data is mapped into VRAM?
Not exactly. When you create a file you get whatever free space is
available. However, vramfs does guarantee that your file is never
fragmented, never sparse, and will always exist for the life of the file
from it's offset in video ram to the offset plus the file size. I
believe I've written the code to be flexible enough however to allow
stronger control if needed.
> I'm thinking about parallel processing - Linux puts data there and then
> the GPU works on it to produce a result which Linux can eventually
> fetch.
>
Or multimedia uses too. I'd like to see this used by MPlayer or Xine
someday for example to make use of the MPEG-2 or H.264 hardware GPU
decoding that today's graphics cards support: Just feed in the H.264 in
one file and direct the GPU to spit out decoded video to another file,
which MPlayer would have memory-mapped and could directly do something
with it, -vf filters and all.
> - Mark
>
>
>
next prev parent reply other threads:[~2009-01-27 5:08 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-26 23:20 Vramfs: filesystem driver to utilize extra RAM on VGA devices Jonathan Campbell
2009-01-26 23:36 ` H. Peter Anvin
2009-01-26 23:50 ` Jonathan Campbell
2009-01-29 17:04 ` Peter W. Morreale
2009-01-29 17:30 ` Jonathan Campbell
2009-01-29 17:38 ` H. Peter Anvin
2009-01-30 3:19 ` Jonathan Campbell
2009-01-30 4:46 ` H. Peter Anvin
2009-01-30 5:20 ` Willy Tarreau
2009-01-30 5:25 ` H. Peter Anvin
2009-01-27 2:59 ` Mark Knecht
2009-01-27 4:44 ` Eric Anholt
2009-01-27 17:37 ` Mark Knecht
2009-01-27 21:23 ` Eric Anholt
2009-01-28 6:36 ` Jonathan Campbell
2009-01-28 7:05 ` Dave Airlie
2009-01-28 9:03 ` Jonathan Campbell
2009-01-28 9:42 ` Dave Airlie
2009-01-27 5:07 ` Jonathan Campbell [this message]
2009-01-27 18:18 ` Mark Knecht
[not found] ` <497F60A3.6020608@nerdgrounds.com>
2009-01-27 20:49 ` Mark Knecht
2009-01-27 21:15 ` Jonathan Campbell
2009-01-28 6:59 ` Trent Piepho
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=497E968F.3020708@nerdgrounds.com \
--to=jon@nerdgrounds.com \
--cc=linux-kernel@vger.kernel.org \
--cc=markknecht@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;
as well as URLs for NNTP newsgroup(s).