On Mon, 2015-09-21 at 15:05 +0200, Christian König wrote: > In general a rather interesting idea and actually shouldn't be to > hard to implement. > > The crux is that allocating memory is device driver dependent, so > there isn't a general purpose API for doing so. > > Additional to that the CPU invisible VRAM is only accessible by the > GPU so you at least need to be able to submit DMA commands to copy > the data back and forth. > > For an experiment I suggest you do this with Radeon first and if that > works generalize from there. > Thanks for the feedback.  I've been studying the code, and it looks like everything I need for Radeon is in radeon_test.c.  As a proof of concept I'm going to initially hack it into an mtd device driver with static allocation through module params.
This is pushing my knowledge quite a bit.  Just to make sure I'm on the right track, this is what I'm attempting: - Grab the pointer to class drm (how? I really need some help here) - Walk the enumerated drm devices - For the specified drm card if it's radeon:  - use radeon_bo_create() to create a bo in RADEON_GEM_DOMAIN_VRAM of specified size  - create a bo in gtt for DMA to/from GPU memory For reads/writes DMA from/to card VRAM bo and copy from/to gtt bo and userspace I guess it would be easier to do this as an add-on to the radeon drm driver since it wouldn't require walking the drm devices to get the radeon_device pointer but it makes more sense to me to just add a reference count to the drm device as an external module. > Regards, > Christian. > > On 21.09.2015 13:33, Steven Newbury wrote: > > I have a mostly* headless server containing a Radeon discrete GPU. > >  It > > occured to me that having a GiB or two of high speed memory sitting > > unused is pretty wasteful. Not an original thought; indeed there's > > a > > Gentoo wiki which describes how to map the memory as a mtd device: > >  > > http://www.gentoo-wiki.info/TIP_Use_memory_on_video_card_as_swap > > > > There's also a driver (cudaram) written by Piotr JaroszyÅski which > > allocates memory through CUDA and maps it to a block device: > > > > http://blog.piotrj.org/2011/03/cudaram-block-device-exposing-nvidia > > .htm > > l > > > > The Gentoo method is extremely limited, and of course isn't exactly > > safe, although using pci-stub would probably help.  There's no > > arbitration between the DRM driver and the mtd phram driver.  Most > > of > > all, it can only expose the memory mapped into the PCI aperture, > > likely > > somewhat less than the full VMEM. > > > > The second method obviously requires the proprietary NVidia driver > > and > > an NVidia gfx card, but it's good proof of concept at utilising a > > driver managed buffer object as a block device. > > > > I'm looking into creating a volatile block device driver which > > allocates VMEM from DRM, what if any is the right API to use?  The > > DRM > > userspace API is well documented, but I'd like to make this a > > kernel > > module, so using a userspace API would seem inappropriate at best. > >  Ideally I'd like to create something like the bcache > > flash_vol_create > > interface except expose a /sys/fs/drm-block/card0/vol_create (where > > drm-block is a placeholder for the proposed driver name) for each > > DRM > > device in the system, and likewise persistence through udev. > > > > So is there an API I can (mis-)use for this?  Any suggestions? > > > > * There's a screen attached for maintainence, but it usually turned > > off. > > > > > > _______________________________________________ > > dri-devel mailing list > > dri-devel at lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/dri-devel > _______________________________________________ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150922/7865cd62/attachment.sig>
