On Thu, Apr 18, 2019 at 6:14 PM Paul Kocialkowski <paul.kocialkowski@xxxxxxxxxxx> wrote: > > Hi, > > On Thu, 2019-04-18 at 18:09 +0900, Tomasz Figa wrote: > > On Thu, Apr 18, 2019 at 5:55 PM Paul Kocialkowski > > <paul.kocialkowski@xxxxxxxxxxx> wrote: > > > Hi Daniel, > > > > > > On Thu, 2019-04-18 at 10:18 +0200, Daniel Vetter wrote: > > > > On Wed, Apr 17, 2019 at 08:10:15PM +0200, Paul Kocialkowski wrote: > > > > > Hi Nicolas, > > > > > > > > > > I'm detaching this thread from our V4L2 stateless decoding spec since > > > > > it has drifted off and would certainly be interesting to DRM folks as > > > > > well! > > > > > > > > > > For context: I was initially talking about writing up support for the > > > > > Allwinner 2D engine as a DRM render driver, where I'd like to be able > > > > > to batch jobs that affect the same destination buffer to only signal > > > > > the out fence once when the batch is done. We have a similar issue in > > > > > v4l2 where we'd like the destination buffer for a set of requests (each > > > > > covering one H264 slice) to be marked as done once the set was decoded. > > > > > > > > > Out of curiosity, what area did you find a 2D blitter useful for? > > The initial motivation is to bring up a DDX with that for platforms > that have 2D engines but no free software GPU drivers yet. > > I also have a personal project in the works where I'd like to implement > accelerated UI rendering in 2D. The idea is to avoid using GL entirely. > > That last point is in part because I have a GPU-less device that I want > to get going with mainline: http://linux-sunxi.org/F60_Action_Camera Okay, thanks. I feel like the typical DRM model with a render node and a userspace library would make sense for these specific use cases on these specific hardware platforms then. Hopefully the availability of open drivers for 3D engines continues to improve. Best regards, Tomasz
