| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| *** | tdebrouw' changes his alias to tdebrouw | [12:40] |
| .................................................................................................................. (idle for 9h28mn) | ||
| jthomas__ | Good day! Can anyone point me towards information about overlaying two different USB webcam streams to become one output stream? | [22:08] |
| hverkuil | pinchartl: can you take a look at this patch series when you have some time? http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/87869 | [09:28] |
| pinchartl | hverkuil: yes, it's in my inbox :-) | [09:30] |
| ............................................ (idle for 3h38mn) | ||
| sailus | hverkuil: Heippa! | [13:08] |
| hverkuil | sailus: hallo! | [13:08] |
| sailus | How are you doing? | [13:09] |
| hverkuil | good, thanks | [13:09] |
| sailus | Would you have time to discuss media entity naming some time next Monday?
pinchartl is expected to join as well. | [13:10] |
| hverkuil | that shouldn't be a problem. | [13:11] |
| sailus | Any preference on time? | [13:12] |
| hverkuil | no, I've nothing specific for that day. | [13:12] |
| sailus | 11:00 Finnish time?
Meaning 10:00 Norwegian. | [13:12] |
| hverkuil | No problem. | [13:13] |
| sailus | Good. Let's start then.
Thanks! Have a nice week-end! :) | [13:13] |
| hverkuil | you too! | [13:14] |
| .................... (idle for 1h39mn) | ||
| lyakh | hverkuil: pinchartl: remember yesterday's discussion regarding image corruption
I've got a work-around and it doesn't look good for VB2 from what I can see... if I flush caches after dequeuing the buffer, using clflush asm instruction, then corruption disappears | [14:53] |
| jberaud | lyakh: sorry to interrupt but why did you flush the cache when dequeuing instead of flushing it when queuing? | [14:56] |
| lyakh | jberaud: what's happening is, that V4L writes data to the buffer through caches. so, if then you read the buffer through cache too, e.g. using the virtual address - all will be fine
however if you pass the buffer to a HW unit - GPU, mem2mem, whatever some data from V4L is still in cache and not in memory | [14:57] |
| pinchartl | v4l writes data to the buffer through caches ?? | [14:57] |
| lyakh | so, that sink HW will get real data in RAM, not from cache | [14:58] |
| pinchartl | are you using a usb device ? | [14:58] |
| lyakh | pinchartl: looks like that. yes, UVC
jberaud: so, by flushing caches I force image data from V4L to RAM | [14:58] |
| pinchartl | that makes more sense
shouldn't it be the responsibility of the GPU to flush caches ? or rather the GPU driver | [14:59] |
| lyakh | then the sink gets correct data | [14:59] |
| pinchartl | I thought GPUs on Intel platforms were dma coherent | [15:00] |
| lyakh | pinchartl: not the GPU driver as such - as a sink. it kinda expects data already in RAM, why waste time on flushes? | [15:00] |
| pinchartl | there's no cache snooping ?
it shouldn't expect data to be in physical memory, no if you create a texture buffer, fill it using the CPU in userspace, and pass it to the GPU then you'll have the same problem | [15:00] |
| lyakh | pinchartl: wouldn't you have to flash caches when creating buffers?
what if you create buffers by a different HW instance, so, no cache flushing is required why should the GPU try to do it anyway? snooping - no idea... I'd rather not dive into amd64 memory arch details ;) pinchartl: but why are you saying, that that makes sense? Isn't data written to buffers directly by USB DMA? is that happening through caches? | [15:02] |
| robstr | hi | [15:05] |
| pinchartl | the uvc driver memcpy()ies data to v4l buffers | [15:16] |
| lyakh | pinchartl: huh...
ok... is it valid? what's the V4L API guarantee - that the data is in buffer+caches or in RAM? | [15:21] |
| pinchartl | I don't think v4l makes any guarantee in that regard | [15:23] |
| lyakh | but how are you supposed to pass buffers to mem2mem devices? | [15:23] |
| *** | robstr has quit IRC (Quit: robstr) | [15:24] |
| pinchartl | devices are supposed to clean caches when a buffer is queued
when you dequeue a buffer v4l ensures that data will be visible to the cpu but it makes no guarantee regarding data is visible to other devices | [15:25] |
| .............. (idle for 1h8mn) | ||
| lyakh | hverkuil: mchehab: do you agree, that V4L doesn't guarantee the data being written to RAM? | [16:34] |
| stormer | lyakh: you mean does not guaranty v4l2_buffers are mappable ? | [16:38] |
| pinchartl | stormer: when you DQBUF, is data from the buffer supposed to be visible to the whole system, or only to the CPU ?
i.e. is cache supposed to be cleaned, or can the data reside in cache only ? | [16:39] |
| stormer | It depends
if I have called mmap, it should flush the cache, if I don't (e.g. I have a DMABUF) it should not | [16:41] |
| pinchartl | have we ever guaranteed that ? | [16:42] |
| stormer | If we where to flush on mmap, we would break pretty much all existing code
since what they do is REQBUFS / QUERYBUFS / mmap(), and then start streaming wihtout ever calling mmap | [16:42] |
| hverkuil | My understanding is that the data can reside in the cache only, but when such a buffer is passed on to another hw device, that driver is supposed to flush the caches. Same for v4l, doing a QBUF to an output device should cause a cache flush. | [16:43] |
| jberaud | hverkuil: I agree with that | [16:43] |
| pinchartl | hverkuil: that's my opinion too | [16:43] |
| stormer | but then userspace will get random data depending on which CPU it is running no ? | [16:44] |
| hverkuil | I don't know what will happen if you used USERPTR with addresses to physical contiguous memory.
I would not be surprised at all if that fails since that's a horrible, horrible hack. DMABUF should do the right thing. | [16:44] |
| pinchartl | stormer: no. DQBUF should guarantee that data is visible to the CPU | [16:44] |
| stormer | pinchartl: you first comment was asking if DQBUF guaranty that | [16:45] |
| hitchcock.freenode.net | (notice) [freenode-info] channel flooding and no channel staff around to help? Please check with freenode support: http://freenode.net/faq.shtml#gettinghelp | [16:54] |
| lyakh | hverkuil: USERPTR, yes | [16:55] |
| pinchartl | iive: that's how I understand it too | [16:55] |
| iive | :) | [16:56] |
| hverkuil | lyakh: I've no idea if that does the right thing w.r.t. cache flushing. | [16:56] |
| lyakh | I actually tend to agree, that as long as a CPU address is used to access buffers we only should guarantee, that the CPU sees the data correctly. So, in case of DMABUF it would be different - DQBUF would return data in RAM. If we think, that this isn't _immediately_ obvious, maybe it would be a good idea to document this ambiguity somewhere :) | [16:57] |
| stormer | stormer getting even more confused | [16:58] |
| pinchartl | iive: do you know how that works with VIVT caches, as kernel and userspace mappings have different virtual addresses ?
lyakh: I'm not even sure to agree with that to be honest | [16:58] |
| iive | no idea. | [16:59] |
| lyakh | pinchartl: with what? that with DMABUF the data should be in RAM? well, I don't know details there. Aren't there flags for cacheable? Maybe then you don't need to guarantee coherency either... is that your doubt? | [17:00] |
| stormer | lyakh: in case of MMAP -> USERPTR, I think flushing goes on QBUF, as DQBUF aims the CPU, for DMABUF this is delegated to map() I guess | [17:00] |
| pinchartl | lyakh: yes, the DMABUF case | [17:00] |
| lyakh | stormer: why do you want to flush on QBUF (on capture devices)? Maybe invalidate?
pinchartl: ok, yes, so, even more options ;) | [17:01] |
| stormer | lyakh: right, direction matter, when I say MMAP -> USERPTR, I means CAPTURE -> OUTPUT | [17:02] |
| pinchartl | caches are an implementation "detail", what matters here is data visibility to the agents in the system
and what guarantees DQBUF provides regarding visibility | [17:02] |
| stormer | also, I guess this is conditional to tones of other thing, you probably won't flush if you do a CPU copy in kernel (e.g CODA with it's ring buffer) | [17:02] |
| pinchartl | those guarantees then imply cache operations, but that's not the main point
traditionally, v4l syncs buffers between cpu and device at qbuf and dqbuf time dqbuf ensures that data is visible by the cpu | [17:02] |
| hverkuil | lyakh: so you capture a frame by giving v4l2 a USERPTR to physically contiguous memory, and then you give it to which device? Whatever device you give it to has to flush the caches since vb2 will not do that. | [17:03] |
| pinchartl | which might involve flushing caches on the device side for instance, it's not only about the cpu cache
so when you queue the buffer to another device, that device is supposed to handle the cpu to device sync | [17:04] |
| stormer | (so that's the use case USERPTR capture -> MMAP output) | [17:04] |
| pinchartl | however, with dmabuf, the whole point is to avoid mappings and cache handling in the device to device case | [17:04] |
| stormer | e.g. UVC -> HW encoder | [17:04] |
| lyakh | hverkuil: yeah... almost... there's also an unmap between DQBUF and passing the buffer on to the consumer. I think that unmap should flush caches actually, since it's destroying the mapping | [17:04] |
| pinchartl | if the source is a device, that's simple
if the source is the cpu, that's a case we might not have thought about oops, haven't noticed it was late already I need to run, sorry I'll be back a bit later | [17:05] |
| lyakh | lyakh runs away too | [17:06] |
| pinchartl | uvcvideo uses vb2_plane_vaddr()
which could map the buffer to kernelspace but there's no unmap there anyway, bbl | [17:07] |
| hverkuil | pinchartl: that's actually a potential bug when using dmabuf. It's fixed here for dmabuf: http://git.linuxtv.org/cgit.cgi/hverkuil/media_tree.git/log/?h=vb2-prep5
haven't had time to fully finalize that patch series. it replaces vb2_plane_vaddr with explicit begin/end_cpu_access calls. | [17:10] |
| ..... (idle for 24mn) | ||
| jthomas__ | Good day! Can anyone point me towards information about overlaying two different USB webcam streams to become one output stream? | [17:35] |
| devinheitmueller | jthomas__: You generally wouldn't do that in the driver layer. You would have to write an app to do that. | [17:36] |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |