04:37 airlied: linkmauve: its not optional
08:50 linkmauve: airlied, what is it used for? In Touhou aside from the offset glitch I saw no issue with nine built without swrast.
08:50 linkmauve: As in, it both builds and runs.
15:09 orbea: why does mesa have countless -Wimplicit-fallthrough warnings with clang? Its to the point I cant see any other warnings hiding in the compile output.
15:09 orbea: *clang10
15:09 orbea: certainly wasnt like this until recently
15:16 udovdh: hello
15:17 udovdh: a while ago I mentioned this problem here: https://pastebin.com/F8TZM8R2
15:17 udovdh: it occurs when playing a 4000x3000 mp4 on my AMD Ryzen 5 3400G with Radeon Vega Graphics
15:17 udovdh: I played with mpv options
15:18 udovdh: mpv -hwdec=auto file.mp4 crashes the gpu so that a reboot is needed
15:18 udovdh: mpv -hwdec=auto -vo=gpu file.mp4 does play the file OK
15:20 udovdh: mp4 logs: https://pastebin.com/630WQKT7
15:22 bnieuwenhuizen: udovdh: if you don't specify -vo=gpu, what is the default output mechanism?
15:22 udovdh: is that in my latest paste?
15:23 udovdh: it uses vo/vdpau
15:23 udovdh: and it does not complain about Unsupported sw format: yuvj422p when using -vo=gpu
15:24 udovdh: in the problem case I see [autoconvert] Converting yuvj422p -> uyvy422
15:24 udovdh: in the good case: VO: [gpu] 4000x3000 yuvj422p
15:25 udovdh: so it is a bit of a bug in mesa/kernel/etc and (!) a 'workaround' with different options to avoid the issue and use the hardware more efficiently, I guess?
15:26 udovdh: so what is different between vo[gpu] and vo/vdpau?
15:26 udovdh: different api I guess but which is used in gpu?
15:31 orbea: udovdh: you might want to use vaapi with amd instead.
15:35 udovdh: will that work better? in what way(s)? I do hope those options will not make it crash again
15:35 udovdh: mpv thinks the gpu option is OK enough (see complaints in problem case)
15:36 orbea: my understanding is that vdpau has been largely abandoned by nvidia and mpv
15:36 udovdh: vo=gpu is the preferred choice in any case
15:36 udovdh: that is what it logs
15:36 orbea: yea, and vo=vdpau is not supported well in mpv, vo=gpu is preferred like you say
15:37 udovdh: [vo/gpu] Loading hwdec driver 'vaapi-egl'
15:38 udovdh: that is what I find when using more verbose logging
15:38 udovdh: so gpu makes it choose vaapi-egl...
15:39 udovdh: but also: [vd] Using software decoding.
15:43 udovdh: more verbose log: https://pastebin.com/Y4pHzDES
15:43 udovdh: how can I make it use hw decoding and not crash?
15:47 orbea: you could try hwdec-codecs=all too
15:49 udovdh: will try
15:50 orbea: i think mpv upstream prefers not using hwdec though...
15:52 udovdh: https://pastebin.com/hVschdfR
15:52 udovdh: is that because of yuvj422p? how do I force it to use the gpu?
15:53 orbea: might be a question better for #mpv at this point
15:54 udovdh: I could reencode the video to a different format, perhaps with more bits per channel and x265?
15:54 udovdh: would that help?
15:54 orbea: it might :shrug:
15:54 udovdh: ok thanks
15:57 udovdh: vlc gives same effects as mpv problem case but does not crash
15:57 udovdh: [00007ff4d0c79010] avcodec decoder: Using G3DVL VDPAU Driver Shared Library version 1.0 for hardware decoding
15:58 udovdh: [h264 @ 0x7ff4d0c9ad80] Failed setup for format vdpau: hwaccel initialisation returned error.
15:58 udovdh: [00007ff4d0c79010] avcodec decoder error: existing hardware acceleration cannot be reused
16:20 karolherbst: jenatali: btw.. it seems like we do indeed support offsets on NV natively.. there are some fields which sound like that "CTA_RASTER_WIDTH_RESUME... and PROGRAM_OFFSET"
16:20 jenatali: Huh, cool
16:21 karolherbst: yeah.. when I get time to look into it :D
16:21 karolherbst: sadly we only get names from nvidia, no documentation :/
16:22 karolherbst: mhh.. PROGRAM_OFFSET vanished with turing.. oh well
17:31 robclark: bnieuwenhuizen: fwiw I've updated https://gitlab.freedesktop.org/mesa/mesa/-/issues/3262 with a couple more steps, and I *think* I have skqp running properly now.. skqp run still going but at least it seems to detect a fail or two now..
19:52 airlied: linkmauve: i assume its a non optional part of d3d9 api
22:26 malice: How do I disable freesync with radv?
22:29 emersion: freesync/vrr is managed by the display part (amdgpu)
22:30 emersion: it's unrelated to the rendering part (radv)
22:30 emersion: it depends which display server you're running
22:39 bnieuwenhuizen: malice: emersion: assuming you're using X11 (does anything wayland have freesync support yet?), either disable in the X11 config or pass the adaptive_sync=false environment variable to the Vulkan app
22:43 malice: Ah, env var, thx
22:43 malice: emersion: Well, with normal opengl apps, driconf adaptive_sync false thing works :P
22:44 bnieuwenhuizen: malice: well, you can also set it in the driconf
22:44 malice: driver="radv"? Or?
22:44 bnieuwenhuizen: oh let me check
22:44 malice: Already have it for driver="radeonsi", the adriconf gui doesn't really reflect it tho
22:44 bnieuwenhuizen: yup, should be radv
22:45 bnieuwenhuizen: (or driver-less)
22:48 emersion: >does anything wayland have freesync support yet?
22:48 emersion: yes, sway does
22:48 emersion: and doesn't require lame mesa blacklists
22:48 emersion: or even mesa support at all
22:48 bnieuwenhuizen: emersion: cool! what do you use to decide whether to enable freesync?
22:49 emersion: we just enable it, always
22:49 bnieuwenhuizen: uh, what about non-games? won't that result in a lot of flicker?
22:49 emersion: flickering is a driver bug, as discussed on the ML
22:50 bnieuwenhuizen: emersion: where?
22:50 emersion: also, because wayland buffer submission works differently than X11, it causes less issues
22:50 bnieuwenhuizen: hmm, different how?
22:50 emersion: https://lists.freedesktop.org/archives/dri-devel/2020-March/258940.html
22:52 emersion: xorg directly renders to the front buffer by default and doesn't guarantee there will be page-flips at all
22:53 emersion: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/457#note_542185
22:55 bnieuwenhuizen: hmm, I'd say that is separate from flicker but a valid concern indeed, thank for the info!
22:55 emersion: interested in hearing more thoughts about this, if you have ideas :)
22:56 emersion: note that we still don't handle the hardware cursor issue well
22:56 emersion: (it's a tricky issue)
22:57 bnieuwenhuizen: honestly it is a bit out of my depth having never tried any fressync monitor and hence I have no clue how bad things are or are not