On Wed, Apr 27, 2011 at 11:12 PM, Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx> wrote: > On Wed, 27 Apr 2011 14:19:05 +0200 Daniel Vetter <daniel@xxxxxxxx> wrote: >> Imo the real problem with formats is stride restrictions and other hw >> restrictions (tiling, ...). >> ARM/v4l people seem to want that to be in the kernel so that they can >> e.g. dma decoded >> video streams directly to the gpu (also for other stuff). Perhaps we >> want to extend the >> create_dumb_gem_object ioctl for that use case, but I'm not too >> convinced that this belongs >> into the kernel. > > I think it's a bit like handling tiling formats; for the most part the > kernel doesn't care because it's not reading or writing the data, but > it does need to know the format when programming certain regs. So I > don't think we can avoid having surface format information passed in > when creating an fb for an overlay. And if we do that we may as well > enumerate the types we support when overlay info is fetched to make > portability for app code a little easier. I agree with your design ;-) My above comment was just in the light of the ARM unified memory management discussion where some people seem to want to move a complete buffer format description beast into the kernel (like v4l already has). I think for gpus that'd get out of hand quickly and format/layout arbitrage code should life in userspace. -Daniel -- Daniel Vetter daniel.vetter@xxxxxxxx - +41 (0) 79 364 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
