On Fri, Mar 23, 2018 at 6:33 PM, Sakari Ailus <sakari.ailus@xxxxxx> wrote:
>> >>> An alternative, maybe a bit crazy, idea would be to allow adding
>> >>> MEDIA_REQUEST_IOC_QUEUE ioctl to the request itself. This would be
>> >>> similar to the idea of indirect command buffers in the graphics (GPU)
>> >>> land. It could for example look like this:
>> >>>
>> >>> // One time initialization
>> >>> bulk_fd = ioctl(..., MEDIA_IOC_REQUEST_ALLOC, ...);
>> >>> for (i = 0; i < N; ++i) {
>> >>> fd[i] = ioctl(..., MEDIA_IOC_REQUEST_ALLOC, ...);
>> >>> // Add some state
>> >>> ioctl(fd[i], MEDIA_IOC_REQUEST_QUEUE, { .request = bulk_fd });
>> >>> }
>> >>>
>> >>> // Do some work
>> >>>
>> >>> ioctl(bulk_fd, MEDIA_IOC_REQUEST_QUEUE); // Queues all the requests at once
>> >>
>> >> That doesn't reduce the number of ioctl calls :-)
>> >
>> > Depends on what cases we are talking about. If we have cases of
>> > queuing the same (big) sets of requests multiple time, then only for
>> > the first time all the ioctls would be needed. Next time, one only
>> > needs to queue the bulk_fd.
>> >
>> > Personally, I don't have any good use case that would involve queuing
>> > many requests instantly and would be affected by the number of ioctls,
>> > though.
>>
>> Sakari gave the example of 10 cameras running at 60 fps, thus generating
>> a very large amount of request ioctls.
>>
>> But this doesn't apply to stateless codecs, so for now this is something
>> for the future.
>
> I think get real benefit from being able to queue multiple requests at a
> time only when you don't need a ton of IOCTLs to construct those requests
> first. I.e. that means moving constructing the requests to Media device as
> well. That's something for the future indeed, and I don't think it's
> realistic to think we'd be there any time soon.
That wouldn't be even Media. Constructing the requests would have to
be moved to userspace, with requests being more like command buffers,
arrays of state objects.
Best regards,
Tomasz
