00:00gfxstrand[d]: "BIOS is updating LED firmware..." I'm glad we're updating all the important things. 🙃
00:00redsheep[d]: How could you live without perfectly updated RGB firmware
00:00gfxstrand[d]: Are there any good Linux utilities for RGB lighting?
00:01orowith2os[d]: Openrgb
00:01orowith2os[d]: That's usually the go-to
00:26mhenning[d]: gfxstrand[d]: I moved my initramfs onto my root partition, for this reason
00:30mhenning[d]: mhenning[d]: also, as an update to this, I was reading the graph wrong 🤦♀️ apparently x axis is number of api calls, not wall time, so ignore what I said about it earlier
00:47phomes_[d]: does issues like this make sense or not? https://gitlab.freedesktop.org/mesa/mesa/-/issues/12480
00:49gfxstrand[d]: Sure. Though why NAK doesn't already fold that, I'm not sure.
00:51gfxstrand[d]: That looks like a copy propagation bug.
00:52phomes_[d]: I would love to debug or provide a patch but maybe this is more obvious/easy for others. This is yet a new area where I am just learning as I go 🙂
01:06mhenning[d]: Yeah, I was aware that that was missing, but I haven't had time to look at it more closely
01:08mhenning[d]: gfxstrand[d]: Do we typically want to do that kind of folding in copy-prop? There are some cases that are tricky once we get into NAK ir eg. an i64 negate can be folded into a 64-bit add, but doing so is annoying after the 64-bit add has been lowered into two instructions.
01:20gfxstrand[d]: Yeah, 64-bit is a pain but 32-bit should work already. We just have a bug.
01:55phomes_[d]: thank you for the hint in the issue mhenning[d] I will try to see if I can figure out a fix tomorrow
08:55freestyleallowed: always right beside you. You know i am genuinly good person, but those things i have is not worth talking so publicly, i do not know for a fact but i think army of Russian federation and United states of america , they seem to have this technology.
08:57freestyleallowed: Especially Americans who after the English start made most of the computing and semiconductor tricks to realm of what we have today, it's all basing on their heroics, they did nothing to block lonely assholes like me.
09:56Jasper[m]: what
12:18dwlsalmeida[d]: avhe[d]: did you write the ffmpeg nvdec for non-tegra stuff too?
12:19dwlsalmeida[d]: the number of surfaces requested is completely broken
12:19dwlsalmeida[d]: lots of streams requiring 40+ surfaces, this makes their driver fail
12:22dwlsalmeida[d]: it's requesting `sps->num_reorder_pics` extra surfaces, on top of 16 for the dpb, and a few scratch ones
12:32avhe[d]: dwlsalmeida[d]: No, I think that is mostly philipl
12:33avhe[d]: You should be able to contact them on libera.chat #ffmpeg-devel (or send an email to the mailing list)
12:34dwlsalmeida[d]: yeah, I'll let them know
12:34dwlsalmeida[d]: it prints a message telling you to reduce the number of threads, but threads==1 doesn't fix it either
12:35dwlsalmeida[d]: only manually patching to request a lower number of surfaces will do
12:35avhe[d]: When you say the driver fails, is that nvidia or nvidia-open?
12:36dwlsalmeida[d]: nvidia
12:36dwlsalmeida[d]: it seems to have a hard limit of 32 surfaces per context
12:36avhe[d]: So this should be a pretty common setup, strange that it never got a fix
12:56ndufresne: (remind me I need to drop this 32 limit in the v4l2 code I maintain)
13:03avhe[d]: dwlsalmeida[d]: do you have a sample for this? I can give it a try on my setup
13:03avhe[d]: I believe I'm currently on nvidia-open but at least this will give you another data point
13:03dwlsalmeida[d]: try anything from Fluster really
13:05dwlsalmeida[d]: I think philipl himself wrote a warning on top of where the context is created, warning that >32 surfaces would crash
13:05dwlsalmeida[d]: he just forgot to make sure >32 surfaces are not requested
13:05dwlsalmeida[d]: lol
13:06dwlsalmeida[d]: ret = nvdec_decoder_create(&ctx->decoder, frames_ctx->device_ref, ¶ms, avctx);
13:06dwlsalmeida[d]: if (ret < 0) {
13:06dwlsalmeida[d]: if (params.ulNumDecodeSurfaces > 32) {
13:06dwlsalmeida[d]: av_log(avctx, AV_LOG_WARNING, "Using more than 32 (%d) decode surfaces might cause nvdec to fail.\n",
13:06dwlsalmeida[d]: (int)params.ulNumDecodeSurfaces);
13:06dwlsalmeida[d]: av_log(avctx, AV_LOG_WARNING, "Try lowering the amount of threads. Using %d right now.\n",
13:06dwlsalmeida[d]: avctx->thread_count);
13:06dwlsalmeida[d]: }
13:06dwlsalmeida[d]: av_buffer_unref(&real_hw_frames_ref);
13:06dwlsalmeida[d]: return ret;
13:06dwlsalmeida[d]: }
13:07dwlsalmeida[d]: just check how much this function will compute:
13:07dwlsalmeida[d]: static int nvdec_h264_frame_params(AVCodecContext *avctx,
13:07dwlsalmeida[d]: AVBufferRef *hw_frames_ctx)
13:07dwlsalmeida[d]: {
13:07dwlsalmeida[d]: const H264Context *h = avctx->priv_data;
13:08dwlsalmeida[d]: const SPS *sps = h->ps.sps;
13:08dwlsalmeida[d]: return ff_nvdec_frame_params(avctx, hw_frames_ctx, sps->ref_frame_count + sps->num_reorder_frames, 0);
13:08dwlsalmeida[d]: }
13:08dwlsalmeida[d]: It's more than 32 surfaces often
13:08dwlsalmeida[d]: A simple fix, I believe, is to remove sps->num_reorder_frames from the count
13:08dwlsalmeida[d]: as I assume the picture will be in the DPB if it hasn't been output yet
13:09dwlsalmeida[d]: this hw_frames_ctx is also dependent on the number of threads IIRC, so depending on your CPU, it can also be a problem
13:10dwlsalmeida[d]: but I guess this can be solved using `-threads N`, unlike `num_reorder_frames` which depends on stream parameters instead
13:50avhe[d]: dwlsalmeida[d]: the wording also suggests it might work... maybe only on windows?
13:54avhe[d]: dwlsalmeida[d]: you can also try with the h264_cuvid decoder
13:54avhe[d]: this uses nvidia's parser libraries instead of ffmpeg's
14:37dwlsalmeida[d]: Can somebody help me figure out the tile buffer layout?
14:37dwlsalmeida[d]: width is 1, height is 1, start is 0, and end is 0x05a1
14:37dwlsalmeida[d]: ```
14:37dwlsalmeida[d]: AV1 Tile Sizes: 2522191ad229df3f
14:37dwlsalmeida[d]: 0x000000: 00000101 05a10000 00000000 00000000
14:37dwlsalmeida[d]: getting a bit confused with the endianess here
14:38dwlsalmeida[d]: I assume
14:38dwlsalmeida[d]: #[repr(packed)]
14:38dwlsalmeida[d]: #[derive(Clone, Copy, Default)]
14:38dwlsalmeida[d]: struct TileInfo {
14:38dwlsalmeida[d]: padding: [u8; 2],
14:38dwlsalmeida[d]: width_in_sbs: u8,
14:38dwlsalmeida[d]: height_in_sbs: u8,
14:39dwlsalmeida[d]: tile_end: u32
14:39dwlsalmeida[d]: tile_start: u32,
14:39dwlsalmeida[d]: }
14:47OftenTimeConsuming: Recent updates has made things more stable for the 780, but there's still a libgallium crash after about 40 minutes in any game; https://termbin.com/n8vj
14:53OftenTimeConsuming: Looks like I've compiled speed-dreams-2 with the address sanitiser and it gets something; https://termbin.com/819q
14:55OftenTimeConsuming: https://termbin.com/4x4h
15:06karolherbst: mhh yeah.. I think there is a data race somewhere
15:06OftenTimeConsuming: 6 of them at the same time probably/
15:06dwlsalmeida[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1329829236558659645/ffmpeg_logs.zip?ex=678bc37d&is=678a71fd&hm=c0e721bc2035740c12125a829ccb37ec7ffc86cd69994c43363f2c6bbbaf70f5&
15:06dwlsalmeida[d]: skeggsb9778[d]: skeggsb9778[d] Ben, can you help out again?
15:06dwlsalmeida[d]: my branch still doesn't work with ffmpeg, but works h.264 and h.265 work perfectly with GStreamer.
15:06dwlsalmeida[d]: Still getting the channel killed, i.e.:
15:06dwlsalmeida[d]: [ 5452.523689] nouveau 0000:01:00.0: gsp: rc engn:00000013 chid:40 type:68 scope:1 part:233
15:06dwlsalmeida[d]: [ 5452.523695] nouveau 0000:01:00.0: fifo:c01000:0005:0028:[ffmpeg[18792]] errored - disabling channel
15:06dwlsalmeida[d]: [ 5452.523698] nouveau 0000:01:00.0: ffmpeg[18792]: channel 40 killed!
15:06dwlsalmeida[d]: I've attached the firmware logs, do you mind going through them if you have the time?
17:00Lynne: dwlsalmeida[d]: what's the issue?
17:02dwlsalmeida[d]: Lynne: for now, it crashes the firmware, i.e.:
17:02dwlsalmeida[d]: [ 5452.523689] nouveau 0000:01:00.0: gsp: rc engn:00000013 chid:40 type:68 scope:1 part:233
17:02dwlsalmeida[d]: [ 5452.523695] nouveau 0000:01:00.0: fifo:c01000:0005:0028:[ffmpeg[18792]] errored - disabling channel
17:02dwlsalmeida[d]: [ 5452.523698] nouveau 0000:01:00.0: ffmpeg[18792]: channel 40 killed!
17:02dwlsalmeida[d]: I am still investigating, but it's good to have you around regardless
17:03Lynne: could be the way we reset the decoder at the start
17:03Lynne: zero units, no frames
17:03Lynne: could be threading related too