[PATCH] drm/radeon: Add support for userspace fence waits

[Marek Olšák]

2012/2/1 Michel Dänzer <michel at daenzer.net>:
> On Die, 2012-01-31 at 22:08 +0100, Marek Olšák wrote:
>> 2012/1/31 Jerome Glisse <j.glisse at gmail.com>:
>> > On Tue, Jan 31, 2012 at 06:56:01PM +0100, Michel Dänzer wrote:
>> >> On Die, 2012-01-31 at 16:59 +0000, Simon Farnsworth wrote:
>> >> > Userspace currently busywaits for fences to complete; on my workload, this
>> >> > busywait consumes 10% of the available CPU time.
>> >> >
>> >> > Provide an ioctl so that userspace can wait for an EOP interrupt that
>> >> > corresponds to a previous EVENT_WRITE_EOP.
>> >> >
>> >> > Signed-off-by: Simon Farnsworth <simon.farnsworth at onelan.co.uk>
>> >> > ---
>> >> > I've been working on top of Jerome's tiling patches, so this doesn't apply
>> >> > directly on top of current upstream kernels. I can easily rebase to another
>> >> > version upon request - just point me to a git tree.
>> >> >
>> >> > My goal is to remove the sched_yield in Mesa's r600_fence_finish given up to
>> >> > date enough kernel; I hope, though, that the interface is clean enough for
>> >> > other users to extend it in the future (e.g. using compute rings).
>> >>
>> >> I'm afraid not: Unless I'm missing something, userspace can't know which
>> >> ring the kernel submitted the CS to, and the kernel can't guess which
>> >> ring userspace needs to wait for.
>> >
>> > iirc the plan was to add a return value to cs ioctl and add an ioctl to
>> > allow to wait on this return value. ie allowing userspace to wait on
>> > specific submited cs.
>>
>> You don't need a new API for that, r300g already does that. It adds a
>> dummy relocation and later uses GEM_WAIT_IDLE to wait for it. r600g
>> can be updated to do the same thing without kernel changes (besides,
>> we must support the old kernels as well, so this is a no-brainer).
>
> One minor problem being that this doesn't support a timeout without
> spinning. Shouldn't be relevant for Simon's problem though.
>
>
>> What would be much more useful is to be able to wait for a fence,
>> which can be in the middle of a CS. Now that's something that would
>> justify changes in the kernel interface.
>
> To take advantage of that, one would also need to change Gallium such
> that it's possible to get a fence without a flush.

There is PIPE_QUERY_GPU_FINISHED, which should be used for that
purpose. We already agreed in another discussion that this is the way
fences should be done in Gallium. It's just a matter of updating
st/mesa to use it.

Marek