lkml.org 
[lkml]   [2019]   [Aug]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 0/2] A General Accelerator Framework, WarpDrive
    On Thu, Aug 15, 2019 at 01:04:24PM -0400, Jerome Glisse wrote:
    > Date: Thu, 15 Aug 2019 13:04:24 -0400
    > From: Jerome Glisse <jglisse@redhat.com>
    > To: Zhangfei Gao <zhangfei.gao@linaro.org>
    > CC: linux-accelerators@lists.ozlabs.org, Greg Kroah-Hartman
    > <gregkh@linuxfoundation.org>, linux-kernel@vger.kernel.org, Arnd Bergmann
    > <arnd@arndb.de>
    > Subject: Re: [PATCH 0/2] A General Accelerator Framework, WarpDrive
    > User-Agent: Mutt/1.11.3 (2019-02-01)
    > Message-ID: <20190815170424.GA30916@redhat.com>
    >
    > On Wed, Aug 14, 2019 at 05:34:23PM +0800, Zhangfei Gao wrote:
    > > *WarpDrive* is a general accelerator framework for the user application to
    > > access the hardware without going through the kernel in data path.
    > >
    > > WarpDrive is the name for the whole framework. The component in kernel
    > > is called uacce, meaning "Unified/User-space-access-intended Accelerator
    > > Framework". It makes use of the capability of IOMMU to maintain a
    > > unified virtual address space between the hardware and the process.
    > >
    > > WarpDrive is intended to be used with Jean Philippe Brucker's SVA
    > > patchset[1], which enables IO side page fault and PASID support.
    > > We have keep verifying with Jean's sva/current [2]
    > > We also keep verifying with Eric's SMMUv3 Nested Stage patch [3]
    > >
    > > This series and related zip & qm driver as well as dummy driver for qemu test:
    > > https://github.com/Linaro/linux-kernel-warpdrive/tree/5.3-rc1-warpdrive-v1
    > > zip driver already been upstreamed.
    > > zip supporting uacce will be the next step.
    > >
    > > The library and user application:
    > > https://github.com/Linaro/warpdrive/tree/wdprd-v1-current
    >
    > Do we want a new framework ? I think that is the first question that
    > should be answer here. Accelerator are in many forms and so far they
    > never have been enough commonality to create a framework, even GPUs
    > with the drm is an example of that, drm only offer share framework
    > for the modesetting part of the GPU (as thankfully monitor connector
    > are not specific to GPU brands :))
    >
    > FPGA is another example the only common code expose to userspace is
    > about bitstream management AFAIK.
    >
    > I would argue that a framework should only be created once there is
    > enough devices with same userspace API. Meanwhile you can provide
    > in kernel helper that allow driver to expose same API. If after a
    > while we have enough device driver which all use that same in kernel
    > helpers API then it will a good time to introduce a new framework.
    > Meanwhile this will allow individual device driver to tinker with
    > their API and maybe get to something useful to more devices in the
    > end.
    >
    > Note that what i propose also allow userspace code sharing for all
    > driver that use the same in kernel helper.
    >
    > Cheers,
    > Jérôme

    Hi, Jerome, I explain the idea here: https://zhuanlan.zhihu.com/p/79680889. We
    think this is a comment requirement for eveybody. Hope this can help the
    discussion. Thanks

    --
    -Kenneth(Hisilicon)

    \
     
     \ /
      Last update: 2019-08-26 06:17    [W:7.915 / U:0.064 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site