On Wed, Jul 31, 2019 at 1:19 PM Christian König
wrote:
>
> Am 31.07.19 um 12:39 schrieb Daniel Vetter:
> > On Wed, Jul 31, 2019 at 11:44 AM Christian König
> > wrote:
> >> Am 31.07.19 um 11:12 schrieb Daniel Vetter:
> >>> [SNIP]
> >>> I think I brought this up before, but new top-post for a clean
Am 31.07.19 um 12:39 schrieb Daniel Vetter:
On Wed, Jul 31, 2019 at 11:44 AM Christian König
wrote:
Am 31.07.19 um 11:12 schrieb Daniel Vetter:
[SNIP]
I think I brought this up before, but new top-post for a clean start.
Use-case I have in mind is something like amdkfd's model, where you have
On Wed, Jul 31, 2019 at 11:44 AM Christian König
wrote:
>
> Am 31.07.19 um 11:12 schrieb Daniel Vetter:
> > [SNIP]
> > I think I brought this up before, but new top-post for a clean start.
> >
> > Use-case I have in mind is something like amdkfd's model, where you have a
> > list of buffers (per c
Am 31.07.19 um 11:12 schrieb Daniel Vetter:
[SNIP]
I think I brought this up before, but new top-post for a clean start.
Use-case I have in mind is something like amdkfd's model, where you have a
list of buffers (per context or whatever) that you always need to have
present. Idea is to also use
On Wed, Jun 26, 2019 at 02:23:05PM +0200, Christian König wrote:
> On the exporter side we add optional explicit pinning callbacks. If those
> callbacks are implemented the framework no longer caches sg tables and the
> map/unmap callbacks are always called with the lock of the reservation object
>
On Fri, Jul 19, 2019 at 12:05:36PM +, Koenig, Christian wrote:
> Am 19.07.19 um 11:31 schrieb Daniel Vetter:
> > On Fri, Jul 19, 2019 at 09:14:05AM +, Koenig, Christian wrote:
> >> Am 19.07.19 um 10:57 schrieb Daniel Vetter:
> >>> On Tue, Jul 16, 2019 at 04:21:53PM +0200, Christian König wr
Am 19.07.19 um 11:31 schrieb Daniel Vetter:
> On Fri, Jul 19, 2019 at 09:14:05AM +, Koenig, Christian wrote:
>> Am 19.07.19 um 10:57 schrieb Daniel Vetter:
>>> On Tue, Jul 16, 2019 at 04:21:53PM +0200, Christian König wrote:
Am 26.06.19 um 14:29 schrieb Daniel Vetter:
[SNIP]
>>> Well
On Fri, Jul 19, 2019 at 09:14:05AM +, Koenig, Christian wrote:
> Am 19.07.19 um 10:57 schrieb Daniel Vetter:
> > On Tue, Jul 16, 2019 at 04:21:53PM +0200, Christian König wrote:
> >> Am 26.06.19 um 14:29 schrieb Daniel Vetter:
> >>> On Wed, Jun 26, 2019 at 02:23:05PM +0200, Christian König wrot
Am 19.07.19 um 10:57 schrieb Daniel Vetter:
> On Tue, Jul 16, 2019 at 04:21:53PM +0200, Christian König wrote:
>> Am 26.06.19 um 14:29 schrieb Daniel Vetter:
>>> On Wed, Jun 26, 2019 at 02:23:05PM +0200, Christian König wrote:
>>> [SNIP]
>>> Also I looked at CI results and stuff, I guess you indeed
On Tue, Jul 16, 2019 at 04:21:53PM +0200, Christian König wrote:
> Am 26.06.19 um 14:29 schrieb Daniel Vetter:
> > On Wed, Jun 26, 2019 at 02:23:05PM +0200, Christian König wrote:
> > > On the exporter side we add optional explicit pinning callbacks. If those
> > > callbacks are implemented the fra
Am 26.06.19 um 14:29 schrieb Daniel Vetter:
On Wed, Jun 26, 2019 at 02:23:05PM +0200, Christian König wrote:
On the exporter side we add optional explicit pinning callbacks. If those
callbacks are implemented the framework no longer caches sg tables and the
map/unmap callbacks are always called
On Wed, Jun 26, 2019 at 02:23:05PM +0200, Christian König wrote:
> On the exporter side we add optional explicit pinning callbacks. If those
> callbacks are implemented the framework no longer caches sg tables and the
> map/unmap callbacks are always called with the lock of the reservation object
>
On the exporter side we add optional explicit pinning callbacks. If those
callbacks are implemented the framework no longer caches sg tables and the
map/unmap callbacks are always called with the lock of the reservation object
held.
On the importer side we add an optional invalidate callback. This
13 matches
Mail list logo
