Messages in this thread | | | Date | Tue, 27 Jan 2009 12:49:46 -0800 | Subject | Re: Vramfs: filesystem driver to utilize extra RAM on VGA devices | From | Mark Knecht <> |
| |
On Tue, Jan 27, 2009 at 11:29 AM, Jonathan Campbell <jon@nerdgrounds.com> wrote: > > On Mon, Jan 26, 2009 at 9:07 PM, Jonathan Campbell <jon@nerdgrounds.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? > > > That depends on the framebuffer driver. Some drivers like radeonfb don't > clear the VRAM on mode change, so they remain intact until stomped on by > fbcon or anyone else using /dev/fb0. However, vramfs creates a default > "framebuffer" file to occupy that region of VRAM for this reason, so as long > as the default file is large enough to cover any possible framebuffer you > could set up, and nobody reads/writes /dev/fb0 that far, the files will be > fine. Vramfs doesn't really need to interact much with the framebuffer > system. > > Again, filesystem structures are never stored in VRAM for this reason: so > that in the worst case scenario files are overwritten with bitmaps, garbage, > or cleared. No additional harm done. I wouldn't want the kernel oopses or > hangs associated with storing kernel structures there. > > I suppose vramfs could ask the kernel which framebuffer is attached to the > PCI device, and ask it the highest possible resolution and bits per pixel > count (not necessarily supported by the monitor, I mean highest possible > supported by the CRTC and DACs)
I think it unlikely that any audio engineer is going to purposely change screen resolutions while doing a mix so I'd not want you to complicate things for situations like that.
What would happen a lot I think is that while X is running someone might drop into the console to do something or switch to another desktop in Gnome or KDE. I suspect those aren't issues but it would be important not to corrupt any file system data when those happen. For instance, someone might run a GPU program on one desktop and then move to their main desktop for mixing, etc. None of that effects the size of framebuffers as far as I know.
If I was to build this and try it our (not saying I have time right now though) then as root how do I determine what size file system I can build? Do I run fdisk against /dev/fb0 and look at what portion is unallocated?
Thanks, Mark
| |