On 08/25/2015 06:30 AM, Thomas Hellstrom wrote:
On 08/25/2015 11:02 AM, Daniel Vetter wrote:
I really feel like any kind of multi-range flush interface is feature
bloat, and if we do it then we should only do it later on when there's a
clear need for it.
IMO all the use-cases so far that wanted to do this have been 2D
updates. and having only a 1D sync will most probably scare people away
from this interface.
Afaiui dma-buf mmap will mostly be used for up/downloads, which means
there will be some explicit copy involved somewhere anyway. So similar to
userptr usage. And for those most often you just slurp in a linear block
and then let the blitter rearrange it, at least on i915.
Also thus far the consensus was that dma-buf doesn't care/know about
content layout, adding strides/bytes/whatever does bend this quite a bit.
I think with a 2D interface, the stride only applies to the sync
operation itself and is only a parameter for that sync operation.
Whether we should have multiple regions or not is not a big deal for me,
but I think at least a 2D sync is crucial.
Right now only omap, ion and udl-fb make use of begin{,end}_cpu_access()
dma-buf interface, but it's curious that none uses those 1-d parameters
(start and len). So in that sense it seems that the tendency is to
feature bloat the API if we do the 2-d additions.
OTOH we're talking about a different usage of dma-buf right now, so the
driver might actually start to use in fact that API. That said, I
thought it was somewhat simple to turn the common code into 2-d, cause,
as I pointed in the other email, we'd be pushing the whole
responsibility of dealing with the regions and so on to the driver
implementors.
Thomas, any comments in the dma_buf_begin_cpu_access() new API I showed?
Maybe I should just clean up here the draft and sent it to the ML :)
Tiago
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
