Re: [RFC PATCH 0/6] Common preempt fences and semantics

2024-11-15 Thread Matthew Brost
On Thu, Nov 14, 2024 at 09:38:43AM +0100, Christian König wrote: > Am 13.11.24 um 16:34 schrieb Matthew Brost: > > > > > > > Now the ordering works inherently in dma-resv and the scheduler. > > > > > > > e.g. No > > > > > > > need to track the last completion fences explictly in preempt > > > > >

Re: [RFC PATCH 0/6] Common preempt fences and semantics

2024-11-14 Thread Christian König
Am 13.11.24 um 16:34 schrieb Matthew Brost: Now the ordering works inherently in dma-resv and the scheduler. e.g. No need to track the last completion fences explictly in preempt fences. I really don't think that this is a good approach. Explicitly keeping the last completion fence in the pre-em

Re: [RFC PATCH 0/6] Common preempt fences and semantics

2024-11-13 Thread Matthew Brost
On Wed, Nov 13, 2024 at 10:02:12AM +0100, Christian König wrote: > Am 13.11.24 um 03:30 schrieb Matthew Brost: > > [SNIP] > > > > > If you're using gpuvm, just call drm_gpuvm_resv_add_fence. I assume > > > > > AMD has a > > > > > similarly simple call. > > > > Nope, we try to avoid locking all BOs

Re: [RFC PATCH 0/6] Common preempt fences and semantics

2024-11-13 Thread Christian König
Am 13.11.24 um 03:30 schrieb Matthew Brost: [SNIP] If you're using gpuvm, just call drm_gpuvm_resv_add_fence. I assume AMD has a similarly simple call. Nope, we try to avoid locking all BOs in the VM as hard as we can. Why? Calling in to perform fence conversion shouldn't be all that frequent

Re: [RFC PATCH 0/6] Common preempt fences and semantics

2024-11-12 Thread Matthew Brost
On Tue, Nov 12, 2024 at 06:27:31PM -0800, Matthew Brost wrote: > On Tue, Nov 12, 2024 at 12:09:52PM +0100, Christian König wrote: > > Am 12.11.24 um 04:29 schrieb Matthew Brost: > > > On Mon, Nov 11, 2024 at 02:42:02PM +0100, Christian König wrote: > > > > Am 09.11.24 um 18:29 schrieb Matthew Brost

Re: [RFC PATCH 0/6] Common preempt fences and semantics

2024-11-12 Thread Matthew Brost
On Tue, Nov 12, 2024 at 12:09:52PM +0100, Christian König wrote: > Am 12.11.24 um 04:29 schrieb Matthew Brost: > > On Mon, Nov 11, 2024 at 02:42:02PM +0100, Christian König wrote: > > > Am 09.11.24 um 18:29 schrieb Matthew Brost: > > > > The motivation for this series comes from pending UMD submiss

Re: [RFC PATCH 0/6] Common preempt fences and semantics

2024-11-12 Thread Christian König
Am 12.11.24 um 04:29 schrieb Matthew Brost: On Mon, Nov 11, 2024 at 02:42:02PM +0100, Christian König wrote: Am 09.11.24 um 18:29 schrieb Matthew Brost: The motivation for this series comes from pending UMD submission work by AMD [1], ARM [3], and the Xe team, who are also beginning to look at

Re: [RFC PATCH 0/6] Common preempt fences and semantics

2024-11-11 Thread Matthew Brost
On Mon, Nov 11, 2024 at 02:42:02PM +0100, Christian König wrote: > Am 09.11.24 um 18:29 schrieb Matthew Brost: > > The motivation for this series comes from pending UMD submission work by > > AMD [1], ARM [3], and the Xe team, who are also beginning to look at > > this. Sima has suggested [4] some

Re: [RFC PATCH 0/6] Common preempt fences and semantics

2024-11-11 Thread Christian König
Am 09.11.24 um 18:29 schrieb Matthew Brost: The motivation for this series comes from pending UMD submission work by AMD [1], ARM [3], and the Xe team, who are also beginning to look at this. Sima has suggested [4] some common driver preemptive fences and semantics, which we all agree on. This is

[RFC PATCH 0/6] Common preempt fences and semantics

2024-11-09 Thread Matthew Brost
The motivation for this series comes from pending UMD submission work by AMD [1], ARM [3], and the Xe team, who are also beginning to look at this. Sima has suggested [4] some common driver preemptive fences and semantics, which we all agree on. This is the first attempt to implement them, based on