[09:57] *** harrow has quit IRC (Quit: Leaving)
[16:03] *** prabhakarlad has left 
[16:11] <hverkuil> ndufresne: kbingham: re begin/end_cpu_access in vb2: I worked on that in the past but it never was finished. https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=vb2-cpu-access
[16:12] <hverkuil> I think sailus looked at this as well, but it never went anywhere.
[16:12] <ndufresne> hverkuil, thanks, I'll have a look
[16:13] <ndufresne> I got so much to learn still
[16:13] <ndufresne> hverkuil, am I thinking right the driver using videobuf2-vmalloc are the one doing CPU access ?
[16:13] <hverkuil> From what I remember it stalled on a few drivers that I did not know how to convert (i.e. how to correctly do the begin/end_cpu_access)
[16:15] <ndufresne> hverkuil, I was thinking that if this is the case, we could make begin/end implicit, but if we have driver using vmalloc and doing both, then you are right, we have to visit all drivers
[16:16] <ndufresne> best would be to have app the does just this, grab form v4l2 and render to drm, my only test case imply gstreamer atm
[16:17] <hverkuil> If a driver (any driver!) needs CPU access to a buffer, then it should call begin/end_cpu_access for the part of the buffer it needs CPU access to.
[16:17] <hverkuil> It is really irrelevant whether the driver uses vmalloc/dma=contig/dma-sg since it can always import dma-buf buffers, which can be anything.
[16:17] <ndufresne> hverkuil, btw, you added a check to make mem_ops->begin_cpu_access, this is wrong, the wrapper automatically stub it for the non-cacheable case
[16:18] <ndufresne> (to make it mandatory)
[16:18] <hverkuil> Note: when I looked at this in 2015 I noticed that many non-media driver made a mess of this as well.
[16:18] <ndufresne> hverkuil, for that yes, I was focus on vmalloc / short term solution, but I agree
[16:19] <ndufresne> Right now, it works with mesa, which apparently flush the case somehow, but UVC and VIVID images are completly useless if you give them to a drm driver
[16:19] <ndufresne> hverkuil, it felt that they added that after they introduce dmabuf, so no one thought about that
[16:20] <hverkuil> yeah, this was introduced later.
[16:20] <ndufresne> it's even a userspace breakage
[16:20] <ndufresne> in some ways
[16:21] <hverkuil> When using uvc/vivid with drm, you mean that's using dmabuf?
[16:21] <hverkuil> Who in that scenario creates the buffers? I assume drm? And v4l2 imports them?
[16:21] <ndufresne> importer or exported are both broken
[16:22] <ndufresne> the exporter does not flush it's cache, and drm importer don't do anything about it (as documented in the dma buf headers)
[16:22] <ndufresne> but the drm side will use a dma, not the CPU, and you get a mess on the screen
[16:23] <ndufresne> for the importer case, well uvc does not call begin/end, so the exporter (drm) is not aware that there is cached data on the CPU, and renders without this data
[16:23] <hverkuil> In the vmalloc case I don't think this has anything to do with begin/end_cpu_access (at least not the use-case this patch series of mine addresses).
[16:24] <ndufresne> well, it's complicated, very complicated
[16:24] <hverkuil> This sounds more like a bug in the dma-buf implementation of vmalloc. Which might in fact be solved by explicitly calling begin/end_cpu_access.
[16:24] <ndufresne> without being end, let's say you flush on DONE, but before giving it to DRM you want to overlay something in userspace
[16:25] <ndufresne> without begin/end, what the userspace leaves in cache won't be rendered
[16:25] <ndufresne> hverkuil, well, dmabuf from vmalloc have no being/end_cpu_access, so userspace no-op on that
[16:26] <ndufresne> hverkuil, but for vmalloc, my thinking was the, for importation, we'd do being on prepare, and end on done
[16:26] <ndufresne> hence me asking if that make sense, I don't see how a driver can use this allocator if it's not doing everything on CPU
[16:28] <ndufresne> (I should take more screenshot, on Xilinx Zynq Utra Scale, we could see exact 1 linear blob of 1M being wrong, the side of the cache, on Intel the cached part are all over)
[16:29] <hverkuil> I need to look at this when I am not jet-lagged :-)
[16:31] <ndufresne> hehe, I'd be very happy to have some help on that really
[16:31] <ndufresne> btw, the vb2_plane_begin_cpu_access() is a bit funky, also, how come it's missing a direction ? or READ/WRITE/RW ?
[16:32] <hverkuil> Remember: this patch series is from 2015. A lot of things have changed since that time.
[16:33] <ndufresne> right ;-P
[16:35] <ndufresne> hverkuil, one thing I didn't figure-out right yet, I see that some memory is being created as "non-cacheable" which is the case for our cma allocator, does it mean that when this memory is used, the CPU cache will not be used ? and does all CPU supports this ?
[16:36] <hverkuil> I think that is correct. I believe this is always supported, although it may be a NOP if the hardware is cache coherent (Intel I believe).
[16:40] <ndufresne> that reminds me sailus asked me to force the cma in uvc to see if the hides the issue ...
[16:40] <ndufresne> it should, but I think it's a good information to verify
[16:46] <ndufresne> hverkuil, so even though Intel is cache coherant, the Intel Scannout engine is not
[16:48] <hverkuil> ndufresne: I didn't know that. What's the point of making your hw cache coherent, except for one DMA engine? Weird. So I guess drm doesn't flush the cache for the buffers it wants t o scan out?
[16:54] <hverkuil> ndufresne: how can I test this on an Intel laptop/PC with vivid? If you can email me instructions, then I'll see if I can take a look on Monday.
[17:37] <ndufresne> hverkuil, what's your distro ?
[17:38] <ndufresne> it's currently a GStreamer pipeline, but as we keep finding bugs in there, I never know which version works, so I have to test it first ;-P
[17:44] <ndufresne> hverkuil, I'll send you simple instructions for now, and we'll see from there
[17:59] <hverkuil> ndufresne: debian testing
[18:03] <ndufresne> hverkuil, good, looks like GStreamer 1.12.4, you'll need packages  gstreamer1.0-plugins-good,  gstreamer1.0-plugins-bad and gstreamer1.0-tools
[18:03] <ndufresne> the rest is in the email I just sent you