00:32 alyssa: whoops just deleted 200 lines of turnip
00:33 HdkR: That's a lean turnip right there
08:31 ayaka_: I want to buy a second computer as the development platform for video codec and display. I have had a amd b450 mainboard
08:32 ayaka_: but it seems that AMD GPU only supports a video plane in a crtc?
08:32 ayaka_: intel platform would be a better choice here?
08:36 MrCooper: ayaka_: FWIW, drm_info lists only one overlay plane per CRTC for the iGPU in a Whiskey Lake laptop, looks more or less equivalent to an AMD GPU
08:37 ayaka_: I only saw AMD GPU supports nv12 (no tile) in primary plane
08:40 ayaka_: while, intel .format = DRM_FORMAT_NV12, .num_planes = 4
08:42 ayaka_: the intel gpu I have is Arc A380(Iris Xe), I think I could get at least two video planes in a crtc?
08:47 emersion: you can check drmdb
08:50 ayaka_: I would check your page
08:56 ayaka_: it is surprise that nvidia-drm also support video plane in overlay type of planes
09:01 ayaka_: but "The NVIDIA DRM KMS implementation does not yet register an overlay plane: only primary and cursor planes are currently provided."
09:01 ayaka_: https://download.nvidia.com/XFree86/Linux-x86_64/525.89.02/README/kms.html
09:02 ayaka_: maybe the intel would be the only choice unless I count those arm platforms in
10:54 karolherbst: jenatali: ... so the CL CTS expects empty strings for api kernel_attributes (that kernel introspection stuff)... :D
10:54 karolherbst: ehh
10:54 karolherbst: when using the spir-v compilation mode
10:55 karolherbst: let me dig into the spec to see if there is something funky
10:56 karolherbst: "For kernels not created from OpenCL C source and the clCreateProgramWithSource API call the string returned from this query will be empty." for the CL_KERNEL_ATTRIBUTES thing.. *sigh* oh well
11:13 karolherbst: gfxstrand: any last opinions/ideas on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20161/diffs?commit_id=1fb38736db222c4b834803e47fc68cd2d765007e ? Kind of want to merge _something_ so I can move forward on radeonsi enablement
13:18 tomba: I have been looking at adding DisplayPort MST support to an embedded SoC, which has a display controller (4 crtcs and planes, parallel output) and a separate DP bridge. The details are still a bit fuzzy to me, but if I gather it right, with MST, the display controller driver has also to support MST, not just the DP bridge. Is that correct?
14:16 alyssa: mesa_shader_cache over 1GiB, yikes T_T
14:17 alyssa: guess I should really disable shader cache for CTS runs..
15:15 alyssa: debian-armhf just caught some non-portable format specifiers that snuck into an MR
15:15 alyssa: Thank you Margie :-)
15:32 jenatali: karolherbst: At some point I need to get back to trying to get the CL CTS to pass 100%
15:33 agd5f: tomba, yes, the display IP needs to support MST
15:33 jani: mripard: ack on https://lore.kernel.org/r/20230207143337.2126678-1-jani.nikula@intel.com with the assumption you'll send a fixes pull request this week?
15:33 jenatali: With LLVM 15 that should cut down a lot of time spent compiling trivial test kernels, and I've learned a lot about things that WARP and D3D in general did differently than other Khronos APIs
15:38 alyssa: jenatali: relatable
15:43 jenatali: And we have new features now in DXIL that I can take advantage of to cut down on the amount of lowering I have to do (for some drivers, anyway)
16:03 mripard: jani: yep, go ahead
16:18 tomba: agd5f: I meant the Linux driver. At the moment the display controller driver doesn't know or care about what's outside its outputs.
16:20 karolherbst: jenatali: yeah... what were the biggest todos?
16:20 jenatali: Just debugging failures
16:21 karolherbst: with zink I also got 99.5% close btw
16:21 jenatali: We had every test case passing on at least one driver across our ecosystem, but no individual driver hit 100%
16:21 karolherbst: heh
16:21 jenatali: And for a layered driver Khronos wants 2 100% logs
16:21 karolherbst: oof
16:21 jenatali: Yeah. We hit that for GL3.3, but I haven't tried to go back and get that for GL4.1 or 4.2 either
16:21 karolherbst: wondering how that would look like for rusticl if I pass it on real hw + one vulkan driver :D
16:22 karolherbst: ahh yeah.. GL4.x will be pain
16:22 jenatali: Well rusticl's not a layered driver on its own. You'd get conformance for each individual hardware that you run on - and then rusticl+zink would be considered layered
16:23 karolherbst: right...
16:23 karolherbst: we are generating cursed SPIR-V anyway
16:23 karolherbst: at least I think it doesn't count if we generate spir-v with vec16 and vulkan drivers just eat it :D
16:23 jenatali: That reminds me, have you tried LLVM's built-in SPIR-V backend instead of the translator yet?
16:23 karolherbst: not yet
16:27 jenatali: I'm sitting at 99.8% for VK1.2 on our software rasterizer though, so that's cool. Getting those last passes will be... challenging
16:27 karolherbst: yeah.. the first 90% are always the easiest ones
16:27 jenatali: And then trying to get a second 100% pass will also be fun
16:27 jenatali: Yeah. Been having fun spec lawyering about how texture sampler addressing works and how it's technically different between the D3D and Vulkan specs...
16:29 karolherbst: uhhhh
16:29 alyssa: the first 99.8% is easy
16:29 alyssa: it's the last 99.8% that's hard
16:30 jenatali: Yep
17:09 jani: imre: I think with the acks you could just apply the series https://lore.kernel.org/r/87bkm1x0dk.fsf@intel.com to drm-intel-next-fixes, and IIUC tzimmermann will send a pull request to drm-next later this week
17:09 jani: *sorry* I meant drm-misc-next-fixes
17:10 imre: jani, ok, thanks
17:10 jani: at times I'd like an edit button in irc
17:28 jenatali: Cough Matrix cough
17:39 alyssa: giggle
17:40 tzimmermann: jani, imre, -fixes is for fixes. this looks like a feature
17:40 tzimmermann: so i'd rather not take it
17:41 tzimmermann: unless it fixes an urgent bug in drm-next
17:50 imre: tzimmermann: it is a fix
18:08 cwabbott: dschuermann_: so, I've hit a problem trying to use divergence analysis in ir3, specifically for determining whether a branch is divergent or not
18:10 cwabbott: we have a flag for when a branch possibly reconverges, and it seems like we could use divergence analysis to help figure out where to place the flags
18:10 cwabbott: it's mostly working, but there's one graphicsfuzz test, dEQP-VK.graphicsfuzz.call-if-while-switch that's not working
18:11 cwabbott: the test has a loop where the induction variable is derived from something that's ultimately derived from an undef (or more precisely from an uninitialized read from an array)
18:13 cwabbott: I haven't analysed it yet but I assume that the initial value doesn't matter i.e. the loop trip count doesn't matter
18:14 cwabbott: but... even if it doesn't matter, it's still different per thread and there needs to be the proper reconvergence marked etc.
18:15 cwabbott: but, divergence analysis just assumes it's convergent and we don't insert any reconvergence point at the end of the loop and the test fails (probably due to only some of the threads getting to the end)
18:30 jani: tzimmermann: what imre said. it's broken in 6.1 and 6.2, let's not skip 6.3 too
18:31 alyssa: cwabbott: out of interest, does that.. matter?
18:31 alyssa: setting the reconvergence flag properly, I mean
18:31 jani: tzimmermann: arguably it's better to merge via drm-misc-next-fixes during the merge window than postpone to -rc1
18:32 alyssa: Bifrost has the same mechanism, but setting the flag when there's no reconvergence is supposed to be free in terms of cycle count (though there's maybe a power cost)
18:32 cwabbott: not sure, but I need it for other things anyway
18:33 alyssa: ah
18:34 cwabbott: I need to know when branches fall through for using the qcom version of amd's sGPR's
18:34 cwabbott: and that's intimately related to the reconvergence flag
19:11 tzimmermann: imre, jani, if it's broken in 6.1 already, shouldn't it go through drm-misc-fixes?
19:26 jani: tzimmermann: this was discussed a while back in irc. in theory it should, but we're at -rc8
19:26 jani: while back = last week
19:27 tzimmermann: jani, well, then put it in drm-misc-next-fixes. no objections from my side
19:27 jani: tzimmermann: thanks. imre, please go ahead
19:27 imre: okay
20:28 alyssa: cwabbott: follow up question, how much do sgpr's help if you have preambles?
20:28 alyssa: I guess some subgroup ops are helped
20:28 cwabbott: well, that's what I was planning to find out :)
20:28 alyssa: fair enough
21:26 DemiMarie: jani: then CC stable
21:52 vsyrjala: DemiMarie: cc:stable was never in doubt. the question was how to actually get those fixes into linus tree (and thus stable releases) in a timely fashion, without risk to 6.2 at this late stage. and the solution is to get them in during 6.3 merge window
22:11 javierm: vsyrjala: agreed, that what I did for a fix that recently pushed to drm-misc-next
22:11 javierm: vsyrjala: I thought that it would be risky to push it to -fixes at this late stage in the -rc cycle
22:12 javierm: getting into 6.3 and then letting the stable folks to cherry-pick seemed like the best option