On Thu, Aug 20, 2015 at 2:48 AM, Thomas Hellstrom <thellstrom@xxxxxxxxxx> wrote: > Hi, Tiago! > > On 08/20/2015 12:33 AM, Tiago Vignatti wrote: >> Hey Thomas, you haven't answered my email about making SYNC_* mandatory: >> >> http://lists.freedesktop.org/archives/dri-devel/2015-August/088376.html > > Hmm, for some reason it doesn't show up in my mail app, but I found it > in the archives. An attempt to explain the situation from the vmwgfx > perspective. > > The fact that the interface is generic means that people will start > using it for the zero-copy case. There has been a couple of more or less > hackish attempts to do this before, and if it's a _driver_ interface we > don't need to be that careful but if it is a _generic_ interface we need > to be very careful to make it fit *all* the hardware out there and that > we make all potential users use the interface in a way that conforms > with the interface specification. > > What will happen otherwise is that apps written for coherent fast > hardware might, for example, ignore calling the SYNC api, just because > the app writer only cared about his own hardware on which the app works > fine. That would fail miserably if the same app was run on incoherent > hardware, or the incoherent hardware driver maintainers would be forced > to base an implementation on page-faults which would be very slow. > > So assume the following use case: An app updates a 10x10 area using the > CPU on a 1600x1200 dma-buf, and it will then use the dma-buf for > texturing. On some hardware the dma-buf might be tiled in a very > specific way, on vmwgfx the dma-buf is a GPU buffer on the host, only > accessible using DMA. On vmwgfx the SYNC operation must carry out a > 10x10 DMA from the host GPU buffer to a guest CPU buffer before the CPU > write and a DMA back again after the write, before GPU usage. On the > tiled architecture the SYNC operation must untile before CPU access and > probably tile again before GPU access. > > If we now have a one-dimensional SYNC api, in this particular case we'd > either need to sync a far too large area (1600x10) or call SYNC 10 times > before writing, and then again after writing. If the app forgot to call > SYNC we must error. just curious, but couldn't you batch up the 10 10x1 sync's? BR, -R > > So to summarize, the fact that the interface is generic IMO means: > > 1) Any user must be able to make valid assumptions about the internal > format of the dma-buf. (untiled, color format, stride etc.) > 2) Any user *must* call SYNC before and after CPU access. On coherent > architectures, the SYNC is a NULL operation anyway, and that should be > documented somewhere so that maintainers of drivers of uncoherent > architectures have somewhere to point their fingers. > 3) Driver-specific implementations must be allowed to error (segfault) > if SYNC has not been used. > 4) The use-case stated above clearly shows the benefit of a > 2-dimensional sync interface (we want to sync the 10x10 region), but > what if someone in the future wants to use this interface for a 3D > texture? Will a 2D sync suffice? Can we make the SYNC interface > extendable in a way that an enum sync_type member defines the layout of > the argument, and initially we implement only 1d, 2d sync, leaving 3d > for the future? > > Also, I agree there is probably no good way to generically implement an > error if SYNC has not been called. That needs to be left as an option to > drivers. > > Thanks, > Thomas > > > _______________________________________________ > dri-devel mailing list > dri-devel@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
