Hi Nicolas, > > There is one use case that isn't covered here that we really need to move > forward on RPi4/5 is cores that can execute multiple task at once. > > In the case of Argon HEVC decoder on the Pi, the Entropy decoder and the > Rescontruction is ran in parallel, but the two function are using the same > trigger/irq pair. > > In short, we need to be able to (if there is enough data in the vb2 queue) to > schedule two consecutive jobs at once. On a timeline: > > -----------------------------------------------------> > [entropy0][no decoder] > [entropy1][decode0] > [entropy2][decode1] > > Perhaps it already fits in the RFC, but it wasn't expressed clearly as a use > case. For real-time reason, its not really driver responsibility to wait for > buffers to be queued, and a no-op can happen in any of the two functions. Also, > I believe you can mix entropy decoding from one stream, while decoding a frame > from another stream (another video session / m2m ctx). > > Nicolas > I assume that the cores can be programmed separately, and that you can find which of the two cores is now idle when processing the interrupt? i.e.: this is effectively the same scenario we have with Mediatek vcodec? If so, this is already covered. Basically, whenever a core is done with a job, that will signal the pipeline to try and make progress. i.e: you push `entropy0` and `entropy1` at the beginning of the pipeline, that will cause the entropy decoder to start running. Whenever the entropy decoder is done, it will try to schedule the reconstruction core with `decode0` and start working on `entropy1`. When the reconstruction core is done, it will push `decode0` to the pipeline’s output queue and grab `decode1` (from the queue it shares with the upstream core) to work on. That way, all cores run concurrently, so long as there is work to do. — Daniel
