On Tue, Aug 2, 2016 at 5:43 PM, Enrico Weigelt, metux IT consult <enrico.weigelt@xxxxxxxx> wrote: > On 02.08.2016 16:04, Daniel Vetter wrote: > >> If you mean "add a generic hw-accelerated bitblt operation": This is not >> hw drm works. The generic kms stuff is about display only, with just very >> basic (hence "dumb") buffer allocation support in a generic way. > > Well, if it already does buffer allocation and mapping (which might > also involve copying around phyisical buffers), why not also add > copy-between-buffers ? except "dumb" buffers exist *only* for CPU rendered content, you cannot assume that a gpu can accelerate anything with them. They basically exist just for simple splash screens and fbcon >> If you mean "expose the dma engine I have here to userspace in >> driver-private ioctls with the trade-off logic between that, kms >> compositing using the display block and memcpy in userspace", then go >> ahead ;-) But if you do that, pls don't don't forget that for any uapi the >> drm subsytem requires correspoding open source userspace (in a real >> app/compositor, not just some toy test or something similar). > > I dont intent to add yet another specific driver and driver-specific > ioctl()s, but instead a generic interface. Such stuff needs kernel > support and kernel configuration anyways, so I'd like to keep it out > of userland's business. there is a reason that there is no generic gpu cmd submission ioctl. It is too much hw specific, and anyway it is only used by device specific userspace (ie. gl driver and/or xorg ddx) BR, -R > > --mtx > > _______________________________________________ > dri-devel mailing list > dri-devel@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
