On 3 August 2016 at 13:33, Enrico Weigelt, metux IT consult enrico.weigelt@gr13.net wrote:
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
The thing isstuff looks generic until you go to use it, just abstract it in userspace.
Because no hw is the same once you go beyond that.
Video memory size means what? VRAM, GPU accessible system RAM, amount of CPU visible VRAM?
Dave.