01:21 alyssa: bfe vs bitfield_extract, everyone's favourite NIR topic
01:30 HdkR: alyssa: bfe and the x86 people can just learn to love it.
01:31 HdkR: BMI/TBM on x86 side calls it bextr if you wanted to go that route :P
02:51 airlied: Lynne: radv on it's way to marge bot
02:54 Lynne: nice
02:54 Lynne: I want vulkan decode in ffmpeg 6.0, but release is in no more than a week or two, and it's not a small amount of code to review
02:56 Lynne: and I still have to fix cuda interop (if it's even possible), drm interop (probably 100% broken) and fix the vulkan filters
02:56 airlied: Lynne: are you going to ship the av1 stuff or just leave that in a branch?
02:56 Lynne: I think I'll ship it and hide it behind an experimental flag
02:57 Lynne: btw you should signal the codec header version in all your PRs
02:57 airlied: I think anv support is going to need some changes, and there are some I think I'd like to make for radv anyways
02:57 airlied: ah yes that might help sync up
02:57 Lynne: okay, I'll skip it
02:57 airlied: I think there are some derived values it would be just easier to get from the decoder than have the hw driver work them out again
02:58 Lynne: which ones? the slice numbers?
02:59 airlied: the two that have popped up so far are frame_restortation_types and skip mode frames
02:59 airlied: also cdef strengths
03:00 airlied: once I get anv to do a few more frames I'll maybe try and sort out the bits that make sense
03:00 airlied: there might be some value around segmentation_enabled processing
03:07 Lynne: I'd rather not modify anything in the Std structs, the segmentation stuff is a few lines at most to derive
03:08 airlied: Lynne: I think the ext/khr will want to change those though
03:08 airlied: since the point of vulkan is to expose the hw interfaces
03:09 airlied: but I'm now into writing code to get relative distances which seems a bit outside what I should be doing in the driver
03:14 Lynne: the Std headers seem to be directly matching from the codecs
03:14 Lynne: the Vk codec structs would be a better place for that
03:14 airlied: okay you mean put that info outside the av1 std? indeed that might work
03:16 airlied: Lynne: I think the other ask though for 264/5 was to drop anything that wasn't required/exposed by hw
03:18 airlied: so we'd probably drop things from the std headers if we didn't see uses for them
03:19 airlied: at the point where the gpu doesn't hang on frame 2, just produces garbage :-
03:19 airlied: :-P
03:32 Lynne: it's not garbage, it's art
03:32 Lynne: sadly the av1 spec doesn't understand art, just correct decoding
03:54 airlied: Lynne: okay intel hw has a bit of a nasty I expect we need to handle outside vulkan, it wants all the reference order hints for all the reference frames at the time they were decoded
04:15 Lynne: the skip mode's derived from that
04:16 Lynne: can we send that over, or does the hw derive it by itself?
05:44 airlied: need to send it over
09:46 jfalempe: tzimmermann, I found a regression in AST driver, after the conversion to shmem.
09:46 jfalempe: the screen is garbage from the remote access on some systems.
09:47 jfalempe: I think there is a missing PAGE_SHIFT in the "start addr" calculation.
09:47 jfalempe: I've a patch to fix this.
09:48 jfalempe: before: https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/ast/ast_mode.c#L607
09:48 jfalempe: and gpu_addr is the pci base address with a << PAGE_SHIFT : https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_gem_vram_helper.c#L277
09:49 jfalempe: after: https://elixir.bootlin.com/linux/v6.2-rc7/source/drivers/gpu/drm/ast/ast_mode.c#L684
09:49 jfalempe: and ast->plane_offset is the pci start address without << PAGE_SHIFT.
10:06 wv: Hello, I'm on imx53 with mesa/freedreno/recent kernel. But now and then (twice a day), I hit a black screen. Dmesg showing me: [drm:drm_atomic_helper_wait_for_flip_done] *ERROR* [CRTC:36:crtc-0] flip_done timed out
10:06 wv: Anyone has an idea?
10:20 lynxeye: wv: I didn't touch a i.MX53 in quite a while. The IPU is notorious for sporadic lockups when it's programmed in a way that isn't to its liking.
10:26 pal1000: dcbaker: I nominate 1e0adac84a17d43721a5249d82c9959880115c92 for backport to 23.0. 22.3 doesn't need it. It fixes dozen build with DirectX headers latest version. It's the last piece needed to close https://gitlab.freedesktop.org/mesa/mesa/-/issues/8147
10:53 x512: Are Wlroots Vulkan renderer production ready or still not optimal?
10:53 wv: lynxeye: Well, locking up is not such an issue, if it would be able to recover without having to reboot the whole system
10:55 wv: The issue does not seem to happen on 5.10 btw
10:56 emersion: x512: still experimental
10:57 x512: emersion: Any known issues?
10:58 emersion: 0.16.x still force-enables the validation layers
10:58 emersion: master doesn't anymore
10:58 emersion: master should be usable for day-to-day use i think
10:58 emersion: i'm currently working on switching to vulkan compute, so expect some more churn
11:01 lynxeye: wv: Yea, sadly once the IPU is wedged trying to recover might cause more harm like full system lockups, so we never really tried to do that.
11:02 lynxeye: wv: Any chance you could try to bisect the issue? I know that's really annoying with those sporadic issues, but I also don't see any major changes in the IPU driver since 5.10, which would explain those issues.
11:10 wv: lynxeye: bisecting between linux 5.10 and 5.15 seems a huge task, and hoping that the issue actually resides in the kernel... I think I'll try some other option first, as having kernel 5.10 in my recent build and check if it's realy kernel related
11:10 wv: of bumping kernel to 6.x, to see if it's solved in some magical way ;-)
11:11 mlankhorst: flip_done timeout might point to a vblank change, maybe some changes inside drm itself then
11:18 lynxeye: mlankhorst: Might be related to DRM core change, which is why I asked for bisect. But then not firing any vblank IRQs anymore is the usual symptom of the IPU locking up, so flip_done timeout is kind of expected in that case.
12:18 mlankhorst: ah indeed
13:31 narmstrong: tzimmermann: mripard: Geert reported https://lore.kernel.org/all/20230124104548.3234554-1-dmitry.baryshkov@linaro.org/ doesn't appear anymore on next while it has been applied on 2023-01-26 before -rc6, seems it missed drm-misc-next-2023-01-26 PR
13:32 narmstrong: tzimmermann: mripard: how can this be fixes ? cherry-pick them on drm-misc-next-fixes ?
13:42 mripard: narmstrong: it's not in next anymore because the merge window is close and we branched out drm-misc-next
13:43 mripard: it's still in drm-misc-next, where it was originally applied, and will be part of 6.4
13:43 mripard: why do you want to merge it as a fix?
13:43 narmstrong: mripard: well it's fixes fixing commits that were in drm-misc-next
13:44 narmstrong: mripard: drm-misc-next wasn't closed at the time I applied them, and drm-misc-next-fixes wasn't opened yet
13:45 mripard: ah, I misread your mail
13:46 mripard: I guess you applied it pretty much when Thomas was doing the PR
13:47 mripard: and since it was the last one for 6.3, well, you missed it :)
13:47 narmstrong: the drm-misc-next black hole !
13:47 mripard: even though it kind of sucks, I guess the easiest solution is to cherry-pick it into drm-misc-next-fixes yeah
13:47 mripard: well, it's not lost
13:48 mripard: like I said, it's now targeting 6.4
13:48 narmstrong: no but the bug will subsist until v6.4-rc1 is tagged, which is quite far away
13:57 tzimmermann: narmstrong, do you have a git commit? we can cherry-pick then
14:01 narmstrong: tzimmermann: https://cgit.freedesktop.org/drm/drm-misc/commit/?id=cbf143b282c64e59559cc8351c0b5b1ab4bbdcbe & https://cgit.freedesktop.org/drm/drm-misc/commit/?id=d33a54e3991dfce88b4fc6d9c3360951c2c5660d
14:54 tzimmermann: narmstrong, done
14:55 narmstrong: tzimmermann: thx!
15:04 MrCooper: I wonder why MR Label Maker didn't like https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21021
15:10 eric_engestrom: MrCooper: looks like that file isn't in https://gitlab.freedesktop.org/freedesktop/mr-label-maker/-/blob/main/mr_label_maker/mesa.py#L285-287; feel free to add it :)
16:13 alyssa:tries to remmeber how VK_ICD works
16:20 alyssa: answer: the daily double
16:20 alyssa: i mean
16:20 alyssa: MESA_VK_IGNORE_CONFORMANCE_WARNING=1 PAN_I_WANT_A_BROKEN_VULKAN_DRIVER=1 VK_ICD_FILENAMES=/home/alyssa/panfrost_devenv_icd.aarch64.json EGL_PLATFORM=surfaceless PANVK_MESA_DEBUG=sync ./deqp-vk --deqp-surface-type=pbuffer --deqp-visibility=hidden --deqp-gl-config-name=rgba8888d24s8ms0 --deqp-surface-width=256 --deqp-surface-height=256 --deqp-log-images=disable
16:36 dcbaker: @pal1000: pulled
17:43 jenatali: Ugh. I hate building LLVM
18:02 Lynne: I know someone who used to bisect llvm on arm SoCs
18:02 jenatali: D:
18:03 Lynne: he now got access to a 168 core arm server monster that compiles llvm in 3 minutes, he earned it
18:04 alyssa: lol
18:06 Lynne: 2U machine that's so loud, it dominates everything in a friend's server room, and when it spins up, he has to put noise cancelling headphones when he's in the next room, with the door closed
18:06 jenatali: I'm racing against CI right now. I think CI's going to win...
18:06 alyssa: mood
18:08 HdkR: Ampere Altra in a 4U with silent cooling would be sick
18:09 ccr: Lynne, does he have his own nuclear powerplant for it, too? :P
18:11 Lynne: at least it can't possibly draw more than a 4090
18:15 ccr: heh
18:17 jenatali: Finally: Elapsed 47:38.052
18:18 alyssa: nice
19:08 jenatali: Ugh. nir_opt_deref is throwing away alignment info with LLVM 15, great
19:15 alyssa: womp
19:28 jenatali: :O once I fixed that though, the unit test that was timing out at like 180s is running in 6s
19:29 zmike: hooray
19:29 zmike: one more ci flake resolved
19:43 anholt_: jenatali: \o/
20:04 Lynne: airlied: could you look into host-mapping? I've still got only one GPU to test on
20:06 airlied: Lynne: didn't I send you the fixes?
20:07 Lynne: yeah, but they were hacky
20:07 airlied: but that's the solution
20:07 airlied: I'm not sure what the correct answer on the ffmpeg side would be
20:07 airlied: the radv code as merged should have all the driver side fixes
20:08 Lynne: could you post the link again?
20:08 Lynne: btw, I think we should still try to go for stabilizing the av1 extension enough to include it in the ffmpeg release in ~2 weeks
20:09 airlied: https://paste.centos.org/view/1040ddce
20:17 airlied: Lynne: my honest opinion to fix host alloc is probably avoid the realloc pat
20:17 airlied: path
20:17 airlied: and get an aligned malloc working
20:28 airlied: Lynne: I created https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21173
20:28 airlied: so we can track discussions on the AV1 provisional spec
20:29 airlied: I'd like to at least have working radv and anv support before we solidify it, hopefully this week
20:31 daniels: jenatali: that’s awesome, thanks a lot for fixing that
20:32 jenatali: daniels: A bit of a coincidence, but a good one :)
20:33 jenatali: Looks like it breaks intel-clc though...
20:56 jenatali: dj-death: Would you be able to help look at https://gitlab.freedesktop.org/mesa/mesa/-/jobs/36008804#L2327 ?
21:03 dj-death: jenatali: is it just failing on the gitlab CI?
21:04 dj-death: can't see an error in the logs
21:04 jenatali: I linked to a failed line, it's the Intel CL compiler failing during the Mesa build
21:05 jenatali: Hitting an assertion while building a deref follower
21:05 dj-death: looks more like a nir issue
21:06 jenatali: Right
21:06 dj-death: jenatali: it's https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21168 ?
21:06 jenatali: Yeah, the nir patch there required to avoid a regression in our CL stack...
21:07 dj-death: building
21:07 jenatali: Thanks!
21:07 dj-death: although my build picked up llvm14
21:08 jenatali: That should be fine? I expect it can still repro, since I think it's the nir patch that's causing problems. I'm only changing the Windows side to use llvm15
21:08 dj-death: ok reproduced
21:10 dj-death: nir_lower_vars_to_ssa failing
21:11 dj-death: apparently it can't deal with casts?
21:12 dj-death: yeah, you change is affect opt_remove_cast_cast
21:12 dj-death: which probably would have removed them
21:13 jenatali: Right, it was removing too much
21:13 jenatali: I had a uint, getting cast to (uint *) with align info, and then to (uint *) with no align info. It was causing that second cast to point straight to the uint, but threw away the align info
21:15 jenatali: dj-death: I also use vars_to_ssa though, and I don't see that building a deref follower. Am I missing that?
21:18 dj-death: jenatali: your change seems to introduce patterns like this :
21:18 dj-death: vec1 64 ssa_18 = deref_cast (uint8_t *)ssa_16 (global uint8_t) /* ptr_stride=1, align_mul=0, align_offset=0 */
21:18 dj-death: vec1 64 ssa_19 = deref_cast (uint8_t *)ssa_18 (global uint8_t) /* ptr_stride=1, align_mul=8, align_offset=0 */
21:18 dj-death: doesn't look valid to me
21:18 dj-death: maybe I'm wrong
21:18 jenatali: Hm. I see
21:19 dj-death: maybe it's valid
21:19 jenatali: Seems valid, but it'd be better if that optimization did run
21:19 jenatali: I think I just need to remove that first early-out on it and just keep the align-preserving aspect
21:22 dj-death: I guess in the case of cast, the last one only matters
21:23 dj-death: but yeah maybe do a MAX2() of the alignment?
21:25 jenatali: Right, an earlier opt should make sure that the last one either has 0 alignment, or else it has a stricter alignment already
21:25 jenatali: So, I think this should be fine
21:31 jenatali: Ok yeah just carrying through alignment while removing casts is enough, looks like everyone's happy now with !21168