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