linux-kernel - Re: Vramfs: filesystem driver to utilize extra RAM on VGA devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5bdc1c8b0901271018k7603e413o92de334e8d28d1d7@mail.gmail.com>
Date:	Tue, 27 Jan 2009 10:18:12 -0800
From:	Mark Knecht <markknecht@...il.com>
To:	Jonathan Campbell <jon@...dgrounds.com>
Cc:	Linux Kernel List <linux-kernel@...r.kernel.org>
Subject: Re: Vramfs: filesystem driver to utilize extra RAM on VGA devices

On Mon, Jan 26, 2009 at 9:07 PM, Jonathan Campbell <jon@...dgrounds.com> wrote:
>
>> 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.
>

Yep, as I said in the response to Eric a number of us had talked in
the past about using the GPU for some audio operations that are just
too CPU intensive - reverb, multi-band compressors, etc. See Jamin as
an example of a great app that brings most DAW type boxes to their
knees.

http://jamin.sourceforge.net/en/about.html

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

So what happens to the file system if the user changes screen
resolution, color depth, etc.? There must be features to manage stuff
like that?

- Mark
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/