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]

Date:	Tue, 27 Jan 2009 13:23:34 -0800
From:	Eric Anholt <eric@...olt.net>
To:	Mark Knecht <markknecht@...il.com>
Cc:	Jonathan Campbell <jon@...dgrounds.com>,
	Linux Kernel List <linux-kernel@...r.kernel.org>
Subject: Re: Vramfs: filesystem driver to utilize extra RAM on VGA devices

On Tue, 2009-01-27 at 09:37 -0800, Mark Knecht wrote:
> On Mon, Jan 26, 2009 at 8:44 PM, Eric Anholt <eric@...olt.net> wrote:
> > On Mon, 2009-01-26 at 18:59 -0800, Mark Knecht wrote:
> <SNIP>
> >> >
> >>
> >> 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
> 
> Right. I agree. However over time a number of us in the pro-audio area
> have thought about using the GPU for things like building complex
> reverb convolutions in real-time. Lots of parallelism in the math.
> These machines are not typically very graphically intensive and the
> VRAM on the cards isn't required but it's there. Somehow being able to
> get data in and out of the VRAM using standard file commands, letting
> something like GEM do the work, and then getting the data back seems
> appealing.

The way you want do that is using OpenGL to put your data in textures
and framebuffer objects, and render them.  With KMS, we'll be able to
support EGL even on the console so you can do the work without having an
X environment set up.

The problem with vramfs as a basis for GPU offload is that most GPU
tasks end up at some point exceeding the size of available
aperture/VRAM.  So you need code that manages loading buffer objects in
and out on demand, managing the execution pipeline and GPU and CPU
caches as required.  We have that with GEM already.

Remember, writing data to an aperture isn't the hard part of offloading
to the GPU, programming the GPU is.  That's why you use OpenGL or
another abstraction to do it.

-- 
Eric Anholt
eric@...olt.net                         eric.anholt@...el.com



Download attachment "signature.asc" of type "application/pgp-signature" (198 bytes)