linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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
>
>
>   


  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).