Re: [PATCH 1/2] drm/ttm: add a way to bo_wait for either the last read or last write

From: Thomas Hellstrom <thomas@shipmail.org>
To: "Marek Olšák" <maraeo@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 1/2] drm/ttm: add a way to bo_wait for either the last read or last write
Date: Sat, 08 Oct 2011 10:14:43 +0200	[thread overview]
Message-ID: <4E900673.7000100@shipmail.org> (raw)
In-Reply-To: <CAAxE2A6VQksEfyU0YVH_vHjNaE+yy2uHY4PAFCYYkFJcTBXmNw@mail.gmail.com>

On 10/07/2011 11:30 PM, Marek Olšák wrote:
> On Fri, Oct 7, 2011 at 3:38 PM, Jerome Glisse<j.glisse@gmail.com>  wrote:
>    
>> I should have look at the patch long ago ... anyway i think a better
>> approach would be to expose fence id as 64bits unsigned to each
>> userspace client. I was thinking of mapping a page readonly (same page
>> as the one gpu write back) at somespecific offset in drm file (bit
>> like sarea but readonly so no lock). Each time userspace submit a
>> command stream it would get the fence id associated with the command
>> stream. It would then be up to userspace to track btw read or write
>> and do appropriate things. The kernel code would be simple (biggest
>> issue is finding an offset we can use for that), it would be fast as
>> no round trip to kernel to know the last fence.
>>
>> Each fence seq would be valid only for a specific ring (only future
>> gpu impacted here, maybe cayman).
>>
>> So no change to ttm, just change to radeon to return fence seq and to
>> move to an unsigned 64. Issue would be when gpu write back is
>> disabled, then we would either need userspace to call somethings like
>> bo wait or to other ioctl to get the kernel to update the copy, copy
>> would be updated in the irq handler too so at least it get updated
>> anytime something enable irq.
>>      
> I am having a hard time understanding what you are saying.
>
> Anyway, I had some read and write usage tracking in the radeon winsys.
> That worked well for driver-private resources, but it was a total fail
> for the ones shared with the DDX. I needed this bo_wait optimization
> to work with multiple processes. That's the whole point why I am doing
> this in the kernel.
>
> Marek
>    
At one XDS meeting in Cambridge an IMHO questionable decision was taken to
try to keep synchronization operations like this in user-space, 
communicating necessary
info among involved components. In this case you'd then need to send 
fence sequences
down the DRI2 protocol to the winsys.

However, if you at one point want to do user-space suballocation of 
kernel buffers,
that's something you need to do anyway, because the kernel is not aware 
that user-space fences
the suballocations separately.

/Thomas

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