block device backed by DRM buffer object

[Steven Newbury]

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>