[00:26:50 CEST] <philipl> Lynne: hi [14:04:20 CEST] <durandal_1707> STOP MOVING SWSCALE INTO LAVC [14:04:30 CEST] <durandal_1707> JUST STOP!!! [14:13:30 CEST] <cone-300> ffmpeg 03Paul B Mahol 07master:79d14a3cc8e9: avfilter/vf_v360: remove intermediate variables [14:13:31 CEST] <cone-300> ffmpeg 03Paul B Mahol 07master:51a2f02117df: avfilter/vf_v360: add fixed pixel padding options [15:28:18 CEST] <Lynne> durandal_1707: I was wondering if I'm the only one seeing that patch for what it was, as usual [15:31:09 CEST] <durandal_1707> Lynne: what's blocking vulkan pushing to master? [15:32:15 CEST] <JEEB> I think he was just tired of bikeshedding etc [15:32:40 CEST] <durandal_1707> i did not noticed any [16:18:36 CEST] <Lynne> who's tired of bikeshedding? [18:14:13 CEST] <kierank> durandal_1707: I AGREE [18:14:16 CEST] <kierank> BUT BIG CORPORATES DO THIS [18:18:30 CEST] <kierank> durandal_1707: I support you [18:18:43 CEST] <BBB> huh? [18:26:51 CEST] <kierank> BBB: there's a guy trying to merge colourspace conversion into an encoder [18:26:57 CEST] <kierank> that old chestnut [18:33:00 CEST] <cone-504> ffmpeg 03Andreas Rheinhardt 07master:25a501b5287b: avutil/opt: Fix type specifier [18:33:00 CEST] <cone-504> ffmpeg 03Michael Niedermayer 07master:0e8b7709a92a: avcodec/sunrast: Fix return type for "unsupported (compression) type" [18:33:00 CEST] <cone-504> ffmpeg 03Michael Niedermayer 07master:0728d644973c: avcodec/sunrast: Fix indention [19:15:36 CEST] <BBB> kierank: lol [19:15:44 CEST] <BBB> kierank: one of these stupid game codecs again? [19:15:47 CEST] <BBB> or a real codec this time? [19:15:48 CEST] <kierank> BBB: no, v210 [19:16:02 CEST] <BBB> is v210 even a codec? [19:16:13 CEST] <BBB> it's just a particular way of writing 422-10bit, right? [19:17:10 CEST] <kierank> yes [19:17:29 CEST] <kierank> debatable whether it's a codec or a pixel format [19:18:30 CEST] <BBB> i see patch now [19:18:34 CEST] <BBB> that's fun [19:18:40 CEST] <BBB> big name, expert, important [19:18:44 CEST] <BBB> all the buzzwords [19:18:46 CEST] <BBB> <3 [19:32:16 CEST] <cone-504> ffmpeg 03Paul B Mahol 07master:05a2ce932654: avformat/y4m: do not try to seek if pts is less than 0 [19:57:45 CEST] <cone-504> ffmpeg 03Paul B Mahol 07master:b4d2bea64722: avfilter/v360: reduce size of some struct members [20:49:51 CEST] <philipl> Lynne: I've been taking a look at map_to_cuda [20:49:59 CEST] <philipl> jkqxz: Could use your thoughts on this one. [20:50:42 CEST] <philipl> We want to map a vulkan hw frame to cuda. Due to a vulkan image not mapping to the same thing as what PIX_FMT_CUDA represents, we can't directly map and need to do a gpu side copy. [20:50:52 CEST] <philipl> So far so good. Lynne wrote this for going from cuda to vulkan. [20:52:11 CEST] <philipl> So, we need to allocate the dst frame from a cuda device context. The approach I've started with is to support deriving a cuda context from a vulkan context and then doing a hwmap=derive_device=cuda in the filter chain. [20:53:00 CEST] <philipl> So when I get to the map callback, I want to do av_hwframe_get_buffer, but because the cuda context is derived, it actually triggers an infinite recursion as it tries to go back to the source context to map the frame. [20:53:24 CEST] <philipl> So I want a non-derived cuda context where av_hwframe_get_buffer actually allocates. [20:54:06 CEST] <philipl> but of course I also want to make sure the cuda context is on the same physical device as the vulkan context or none of this works. [20:54:11 CEST] <philipl> Is there a way to get what I want? [22:17:22 CEST] <Lynne> philipl: sounds good, the way I did it in the vulkan hwcontext was to just manually reinitialize the internal frames pool in the map function in case it isn't [22:17:55 CEST] <Lynne> avhwdevice* are always initialized properly and that's all that's needed to init the frames pool, but I'm not sure how it is for cuda [22:20:47 CEST] <Lynne> btw why does cuda have the concept of mipmaps when its purely a compute API? [22:27:32 CEST] <philipl> Lynne: I guess because they expect to interact with textures. That basic concept has been in the language since very early on. [22:27:46 CEST] <philipl> Given that, I don't know why the interop is so awkward. [22:37:33 CEST] <cone-504> ffmpeg 03Paul B Mahol 07master:a8925d264a95: avfilter/vf_v360: fix mercator_to_xyz() [22:37:34 CEST] <cone-504> ffmpeg 03Paul B Mahol 07master:043038ea56ab: avfilter/vf_v360: fix xyz_to_mercator() [22:37:35 CEST] <cone-504> ffmpeg 03Paul B Mahol 07master:4ba45a95df1b: avfilter/vf_v360: adjust h for mercator input/output [22:38:13 CEST] <philipl> Lynne: Yeah, you can init the vulkan pool using private functions. The equivalent cuda context calls are also private. [22:38:36 CEST] <philipl> And we can't easily implement map in the cuda context because it depends on the vulkan images being initialised correctly with all the export flags, etc. [22:38:53 CEST] <philipl> Might have to brute force it and add a cuda helper to do pool init from the outside. [22:40:02 CEST] <Lynne> are you talking about initing the cuda pool with vulkan frames? [22:40:33 CEST] <Lynne> if the vulkan->cuda interop is in the cuda hwcontext there's nothing private it should need outside of the cuda hwcontext [22:41:53 CEST] <philipl> Lynne: Yeah, if I was to implement in the interop in the cuda hwcontext, I'd be able to init the pool just fine, but we couldn't guarantee that the vulkan frames were exportable. [22:42:13 CEST] <philipl> So I think we really still want the interop in the vulkan hwcontext, but then I need a way to init the cuda context's pool. [22:42:42 CEST] <philipl> Basically, I need a helper that I call to 'un-derive' the context so it uses its own allocator. [22:52:41 CEST] <Lynne> philipl: if they're not exportable then you should just error out [22:53:39 CEST] <Lynne> users can always create a avhwframescontext for vulkan themselves, with usage flags or a queue that does not permit exporting [22:54:33 CEST] <Lynne> but if you need to export internal cuda stuff for use in vulkan, you can put them in hwcontext_cuda_internal.h as we already use that for cuda->vulkan device deriving [22:55:03 CEST] <philipl> Lynne: yeah, so that's basically my plan. [22:58:34 CEST] <jkqxz> It sounds like what you want isn't really mapping as currently defined by the API. [22:58:38 CEST] <jkqxz> If the destination is just any CUDA frame with the right properties, can you derive the device followed by making a new CUDA frames context and then use transfer? [22:59:19 CEST] <jkqxz> (That case could be added to the hwmap filter if wanted.) [22:59:48 CEST] <philipl> jkqxz: Yeah, it's not really mapping. It's really a transfer, but I'm not sure how you set that up to work as-is. 'hwmap' is the only way to indicate a shift from one context to another right? [22:59:58 CEST] <philipl> We sort of need a hwtransfer filter right? [23:01:09 CEST] <jkqxz> That would work. [23:01:11 CEST] <philipl> jkqxz: so right now, I've implemented derive_device in hwcontext_cuda and then have a 'hwmap=derive_device=cuda' filter which triggers the map operation on the hwcontext_vulkan side. [23:01:47 CEST] <philipl> At the time the map is called, there's already a dervied hwframesctx which won't work. I'm not sure where I'd interpose to fix that. [23:01:49 CEST] <jkqxz> Adding it to the hwmap filter might be nice for filter graphs, but it sounds like the API-level part does need to be different. [23:01:59 CEST] <philipl> Perhaps that is not worth it and I should just write the hwtransfer filter. [23:03:09 CEST] <philipl> The brute force thing to do is have some 'underive' function that would clear the source_frames and re-init the context. [23:03:19 CEST] <philipl> which is rather silly [23:05:02 CEST] <jkqxz> Do you even want the mapping semantics from the outside? (Specifically, the behaviour where it will copy back a writable mapping when you unmap.) [23:05:17 CEST] <philipl> No [23:06:24 CEST] <philipl> The only realistic pipelines here are nvdec -> vulkan filters -> non-nvidia sink, and nvdec -> vulkan filters -> nvenc. It's all one way transfers. [23:06:53 CEST] <philipl> and due to the interop limitations, each hand off is a GPU copy [23:07:22 CEST] <philipl> but highly invasive on the vulkan hwcontext due to having a bunch of cuda-side state that must be carried with the frames. [23:10:35 CEST] <philipl> Would it do the right thing if transfer_data_from implemented a cuda path and then we added a format=cuda to the filter chain before nvenc? [23:11:06 CEST] <philipl> I guess probably not due to lack of correctly initialised dst frame [23:11:43 CEST] <jkqxz> There isn't any auto-hwtransfer anywhere. A hwupload could do it? [23:13:49 CEST] <philipl> Yeah, if the hwupload accepts the vulkan pix fmt, which it won't today. [23:13:54 CEST] <philipl> I can experiment. [23:14:34 CEST] <jkqxz> I guess you want hwtransfer which is basically identical to hwupload except accepts different input formats? Or something like that. [23:14:39 CEST] <philipl> Yeah [23:14:53 CEST] <philipl> This seems like it might lead somewhere useful. [23:15:10 CEST] <philipl> but I have to take a break now. Will come back to it later. [23:35:30 CEST] <mkver> jkqxz: Can you take a look at these two patches: http://ffmpeg.org/pipermail/ffmpeg-devel/2019-September/249814.html They are in response to ticket #8126. [00:00:01 CEST] --- Mon Sep 23 2019