Re: [RFC] Request API

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Mar 22, 2018 at 11:47 PM, Tomasz Figa <tfiga@xxxxxxxxxxxx> wrote:
> Hi Hans,
>
> On Thu, Mar 22, 2018 at 11:18 PM, Hans Verkuil <hverkuil@xxxxxxxxx> wrote:
>> - If due to performance reasons we will have to allocate/queue/reinit multiple
>>   requests with a single ioctl, then we will have to add new ioctls to the
>>   media device. At this moment in time it is not clear that this is really
>>   needed and it certainly isn't needed for the stateless codec support that
>>   we are looking at now.
>
> 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

Forgot to mention that this could be easily added on top of the simple
UAPI, so the added advantage would be the ability to start with
something simple and then extend with this functionality, if it is
really necessary.

Best regards,
Tomasz



[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux