From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?Christian_K=c3=b6nig?= Subject: Re: block device backed by DRM buffer object Date: Mon, 21 Sep 2015 15:05:31 +0200 Message-ID: <5600009B.6060909@vodafone.de> References: <1442835186.12687.26.camel@snewbury.org.uk> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0874975036==" Return-path: Received: from pegasos-out.vodafone.de (pegasos-out.vodafone.de [80.84.1.38]) by gabe.freedesktop.org (Postfix) with ESMTP id 37B156E32E for ; Mon, 21 Sep 2015 06:05:44 -0700 (PDT) In-Reply-To: <1442835186.12687.26.camel@snewbury.org.uk> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Steven Newbury , dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org This is a multi-part message in MIME format. --===============0874975036== Content-Type: multipart/alternative; boundary="------------080803060404050309070809" This is a multi-part message in MIME format. --------------080803060404050309070809 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable In general a rather interesting idea and actually shouldn't be to hard=20 to implement. The crux is that allocating memory is device driver dependent, so there=20 isn't a general purpose API for doing so. Additional to that the CPU invisible VRAM is only accessible by the GPU=20 so you at least need to be able to submit DMA commands to copy the data=20 back and forth. For an experiment I suggest you do this with Radeon first and if that=20 works generalize from there. 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: > =20 > http://www.gentoo-wiki.info/TIP_Use_memory_on_video_card_as_swap > > There's also a driver (cudaram) written by Piotr Jaroszy=C5=84ski 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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel --------------080803060404050309070809 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
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.

Regards,
Christian.

On 21.09.2015 13:33, Steven Newbury wrote:
I have a mostly* headless server containing a Radeon=
 discrete GPU. =C2=A0It
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:
=C2=A0
http://www.gentoo-wiki.info/TIP_Use_m=
emory_on_video_card_as_swap

There's also a driver (cudaram) written by Piotr Jaroszy=C5=84ski 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. =C2=A0There's no
arbitration between the DRM driver and the mtd phram driver. =C2=A0Most o=
f
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? =C2=A0The D=
RM
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.
=C2=A0Ideally I'd like to create something like the bcache flash_vol_crea=
te
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? =C2=A0Any suggestions?

* There's a screen attached for maintainence, but it usually turned
off.


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/=
dri-devel

--------------080803060404050309070809-- --===============0874975036== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHA6Ly9saXN0 cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK --===============0874975036==--