On Thu, Nov 12, 2020 at 08:11:02PM -0800, John Stultz wrote: > On Thu, Nov 12, 2020 at 1:32 AM Daniel Vetter <daniel@xxxxxxxx> wrote: > > On Thu, Nov 12, 2020 at 11:09:04AM +0530, Sumit Semwal wrote: > > > On Tue, 10 Nov 2020 at 09:19, John Stultz <john.stultz@xxxxxxxxxx> wrote: > > > > > > > > Hey All, > > > > So just wanted to send my last revision of my patch series > > > > of performance optimizations to the dma-buf system heap. > > > > > > Thanks very much for your patches - I think the first 5 patches look good to me. > > > > > > I know there was a bit of discussion over adding a new system-uncached > > > heap v/s using a flag to identify that; I think I prefer the separate > > > heap idea, but lets ask one last time if any one else has any real > > > objections to it. > > > > > > Daniel, Christian: any comments from your side on this? > > > > I do wonder a bit where the userspace stack for this all is, since tuning > > allocators without a full stack is fairly pointless. dma-buf heaps is a > > bit in a limbo situation here it feels like. > > As mentioned in the system-uncached patch: > Pending opensource users of this code include: > * AOSP HiKey960 gralloc: > - https://android-review.googlesource.com/c/device/linaro/hikey/+/1399519 > - Visibly improves performance over the system heap > * AOSP Codec2 (possibly, needs more review): > - https://android-review.googlesource.com/c/platform/frameworks/av/+/1360640/17/media/codec2/vndk/C2DmaBufAllocator.cpp#325 > > Additionally both the HiKey, HiKey960 grallocs and Codec2 are already > able to use the current dmabuf heaps instead of ION. > > So I'm not sure what you mean by limbo, other than it being in a > transition state where the interface is upstream and we're working on > moving vendors to it from ION (which is staged to be dropped in 5.11). > Part of that work is making sure we don't regress the performance > expectations. The mesa thing below, since if we test this with some downstream kernel drivers or at least non-mesa userspace I'm somewhat worried we're just creating a nice split world between the android gfx world and the mesa/linux desktop gfx world. But then that's kinda how android rolls, so *shrug* > > Plus I'm vary of anything related to leaking this kind of stuff beyond the > > dma-api because dma api maintainers don't like us doing that. But > > personally no concern on that front really, gpus need this. It's just that > > we do need solid justification I think if we land this. Hence back to > > first point. > > > > Ideally first point comes in the form of benchmarking on android together > > with a mesa driver (or mesa + some v4l driver or whatever it takes to > > actually show the benefits, I have no idea). > > Tying it with mesa is a little tough as the grallocs for mesa devices > usually use gbm (gralloc.gbm or gralloc.minigbm). Swapping the > allocation path for dmabuf heaps there gets a little complex as last I > tried that (when trying to get HiKey working with Lima graphics, as > gbm wouldn't allocate the contiguous buffers required by the display), > I ran into issues with the drm_hwcomposer and mesa expecting the gbm > private handle metadata in the buffer when it was passed in. > > But I might take a look at it again. I got a bit lost digging through > the mesa gbm allocation paths last time. > > I'll also try to see if I can find a benchmark for the codec2 code > (using dmabuf heaps with and without the uncached heap) on on db845c > (w/ mesa), as that is already working and I suspect that might be > close to what you're looking for. tbh I think trying to push for this long term is the best we can hope for. Media is also a lot more *meh* since it's deeply fragmented and a lot less of it upstream than on the gles/display side. I think confirming that this at least doesn't horrible blow up on a gralloc/gbm+mesa stack would be useful I think. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
