On 03.08.2016 01:12, Rob Clark wrote: Hi, >> 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. Exactly my usecase: having no (usable) GPU at all, but a an sdma controller - or even better: an IPU - which can do the bitblt. (maybe even w/ colorspace conversion, rotation, etc) There might be GPUs which can also do that - and in that case it should be done by the GPU. > They basically exist just for simple splash screens and fbcon Or when you dont have an (usable) GPU at all ? > there is a reason that there is no generic gpu cmd submission ioctl. > It is too much hw specific, Sure, but I'm not going to use an GPU at all, but different hw. > and anyway it is only used by device > specific userspace (ie. gl driver and/or xorg ddx) Actually, on my targets I neither have gl nor xorg, and I'd like to keep userland generic. I'd hate to hate to have lots of hw-specific cairo-backends when I'll have to touch the kernel anyways, in order to use smda or ipu. By the way: while hacking a bit on mesa (backporting to Trusty), I came around separate hw-specific calls for retrieving the video memory size. Seems to be a really common thing ... is there any hw that does not have such thing ? Couldn't that be an generic ioctl() ? I somewhat got the strange feeling that anything that goes beyond very trivial dumb framebuffer has hw-specific ioctl's ;-o --mtx _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
