All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Anholt <eric@anholt.net>
To: Mark Knecht <markknecht@gmail.com>
Cc: Jonathan Campbell <jon@nerdgrounds.com>,
	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 20:44:11 -0800	[thread overview]
Message-ID: <1233031451.4851.31.camel@gaiman> (raw)
In-Reply-To: <5bdc1c8b0901261859g58a413e1x52208a6f2c1f9ccd@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2766 bytes --]

On Mon, 2009-01-26 at 18:59 -0800, Mark Knecht wrote:
> On Mon, Jan 26, 2009 at 3:20 PM, Jonathan Campbell <jon@nerdgrounds.com> wrote:
> > Hey guys.
> > About a month ago while covered in the Seattle snowstorm I hacked together
> > this pseudofilesystem that might be of interest.
> >
> > I thought that this driver could solve two issues that I have:
> >
> > one, that today's graphics cards have relatively obscene amounts of RAM on
> > them even if you're not using it. If you're running it as a server and not
> > using it for 3D graphics, why not mount the VRAM on the graphics card as a
> > filesystem and store things there to get some extra space?
> >
> > two, if 3D hardware acceleration and access to GPU or texture memory could
> > be provided to user-space, one way to do it would be to provide sections of
> > VRAM as a filesystem that most languages (yes---even Perl!) could use to
> > work with todays graphics cards. They could treat the texture memory the way
> > they treat files in /dev/shm: read/write it for general access or mmap it
> > for direct manipulation. At least, it makes far more sense to me from a
> > programming point of view than to abstract it using specialized ioctls
> > through the DRI. It might make writing an OpenGL driver for this kind of
> > arrangement cleaner, too.
> >
> > http://www.nerdgrounds.com/vramfs-20090126-1458.tar.gz
> >
> > So far I've tested it against 2.6.25.17 and 2.6.28 on both x86 and x86_64
> > with reads, writes, directory creation, symlink creation, and mmap() and it
> > seems to work fine.
> > Just give it a range of memory on the bus, or the domain:bus:device:function
> > numbers of a VGA PCI device, and it will mount the VGA video RAM and allow
> > files to exist there.
> > As a special hack: you can also specify the size of the active framebuffer
> > console so that fbcon doesn't collide with this driver (unless you want to
> > see what your files look like splattered across your screen, ha). The active
> > VRAM area becomes a "sentinel" file named "framebuffer".
> >
> > What do you guys think?
> >
> > Jonathan Campbell
> > Impact Studio Pro
> >
> 
> Can the GPU use the data placed in your file system? Do you have
> strong control as to exactly how the data is mapped into VRAM? 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.

For that you want something like GEM, which is aware of the graphics
pipeline and the cache management necessary.  Wrapping a filesystem
around it shouldn't be hard, and would be of some use for debugging.

-- 
Eric Anholt
eric@anholt.net                         eric.anholt@intel.com



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

  reply	other threads:[~2009-01-27  4:44 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 [this message]
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
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=1233031451.4851.31.camel@gaiman \
    --to=eric@anholt.net \
    --cc=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 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.