03:09 NekoMay: agd5f_: So if I get an MI25, I can still run things like BOINC tasks or whatever, it'll all still just work? Will it ever stop working?
03:10 NekoMay: I just want to be certain before dropping cash on one
03:10 NekoMay: lol
12:52 haasn: amdgpu: The CS has been rejected, see dmesg for more information (-14).
12:52 haasn: [Feb18 13:52] [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Failed to process the buffer list -14!
12:52 haasn: what does this mean?
13:05 bnieuwenhuizen: haasn: most likely a buffer being used in the submitted cmdbuffers that has already been freed
13:21 haasn: I get it from ffmpeg, not sure how exactly to reproduce or get a stacktrace at the time of failure
13:55 haasn: hurr I can just `break fprintf`
13:57 haasn: that breaks on the thread worker though, doesn't give me the callback of when that VkCommandBuffer was submitted to the queue
15:14 haasn: hrm seems to no longer happen on ffmpeg upstream vulkan dev branch
15:14 haasn: I'll chalk it up to some strange race condition in that code
20:44 towo`: hi, after random time watching iptv or video with mpv, the whole xserver resets with the following errors in dmesg: https://paste.debian.net/1271238/
20:44 towo`: what could be the cause and what can i do?
20:46 kzd: anyone have experience here troubleshooting usage of the usb-c displayport outputs on RDNA cards? (RDNA3 is what I have but Know RDNA2 ref models had em too)
21:14 soreau: towo`: It looks like a gpu reset. You might try a different kernel
21:15 towo`: soreau: i've tryed 6.0.x, 6.1.x and at the moment 6.2-rc8
21:15 towo`: it's allways there
21:15 soreau: towo`: it kinda looks like https://gitlab.freedesktop.org/mesa/mesa/-/issues/7026
21:17 towo`: maybe, but in iptv its not yuv420p
21:17 towo`: it can be mpeg2 or h263 (i think for hd content)
21:18 towo`: the question is, is it the kernel or mesa, because mesa 22.x, 23.0-rc and 23.1-git doesn't matter
21:20 towo`: Some days the problem does not occur.
21:20 towo`: on the same hardware and kernel/mesa
21:21 towo`: i've never seen that problem on gaming and if i don't use any videoplayer, the system runs without problem
21:33 jarthur: towo` you got the latest firmware for the cards installed?
21:35 towo`: jarthur: yes, fom firmware git
21:44 jarthur: towo` alright, cool, that bug report is using H.264 as the video format being decoded when the problem hits and there's a good chance that's the same with your IPTV stream. I would also suspect this IPTV stream uses Y′CbCr with 4:2:0 chroma subsampling like in the example.
21:44 jarthur: ffmpeg calls Y′CbCr w/ 4:2:0 chroma subsampling "yuv420p". In ffmpeg, "format" is not so much stream format like H.264 but instead referring to the light samples represented. The stream format would have been specified by specifying the encoder with something like -codec:v libx264 but in this case it was left out so it went with the default, which is libx264 if available.
21:45 jarthur: You could try pressing "i" during playback of one of the streams to see if any of this information is available.
21:47 towo`: it happens with mpeg2video and h264 i don't see more its smplayer as frontend
21:48 jarthur: Alright, in both the mpeg2video and h264 cases, note whatever the "i" display shows under video, especially if it's mentioning "hwdec".
21:49 towo`: i does not show anything in smplayer
21:50 jarthur: oh, sorry, you said you're using smplayer. You might be able to look in the View/mpv log for "hwdec"
21:50 jarthur: But either way, probably worth gathering relevant info and adding your anecdote to the bug report.
21:53 towo`: pixelformat is indeed yuv420p
21:54 towo`: on h264 stream
21:55 jarthur: cool
22:02 towo`: and also fpr mpeg2viedo
22:02 towo`: s/fpr/for
22:02 towo`: grr
22:02 towo`: and also for mpeg2video
22:02 towo`: so