12:37 sima: agd5f, did some backmerge and conflict handling for your -next pull, please check
12:37 sima: tzimmermann, I also pulled in -rc5, iirc you wanted that, so if agd5f has nothing to complain about the amd conflicts you can backmerge
12:41 tzimmermann: sima, great. thanks a lot
12:45 sima: tzimmermann, note that I left out an -xe pull with some ttm changes, but those will get reverted so I think -next has all core/cross-driver things in-flight now
12:48 sima: yeehaw, more amdgpu conflicts in drm-tip rebuilding
12:49 sima: airlied, ^^ also backmerge of -rc655
12:49 sima: *rc5
12:54 sima: ok drm-tip is now also sorted
13:26 Company: I found a new superpower yesterday: Because GL has no versioning, I can install F40 Mesa packages into F41 just fine
13:37 kwizart: Company, I think fedora has built some static build options for mesa for some reason (maybe an attempt for use in distro agnostic manner, like flatpak)
13:39 Company: I'm a big fan because it means I can quickly do regression tests against 24.1 without compiling anything
13:40 MrCooper: it's generally expected that older Mesa builds work on newer distros, the other way around may not work though
13:42 MrCooper: Company: OTOH "meson devenv" allows doing so without installing anything, I guess which is preferable depends on circumstances and/or taste
13:48 Company: what's the process for fixes to end up in stable releases? Is that documented somewhere?
13:48 Company: I'm wondering if https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30839 needs and labels or so to end up in 24.2.1
13:55 MrCooper: for regressions, the Fixes: tag is all that's needed
13:56 MrCooper: otherwise "Cc: mesa-stable"
13:57 MrCooper: both commits in that MR have Fixes: tags, so all you need to do is lean back and watch the release manager(s) do their job
14:04 jadahl: MrCooper: newer mesas need to work on older distros, at least when they come in a sandbox
14:05 MrCooper: sure, I mean the bare-metal case
14:05 MrCooper: newer builds may depend on things not available in the older distro
14:15 DemiMarie: MrCooper: can I build a newer Mesa package for an older distro? Think Debian backport.
14:15 MrCooper: yeah, also not what this is about
14:15 DemiMarie: MrCooper: good to know, thanks!
14:16 MrCooper: it's about installing packages from a different distro version
14:22 bbhtt: hi, can someone please take a look at https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30673?
14:58 gfxstrand: woah! C23 got typeof()
14:59 zmike: wat
14:59 gfxstrand: https://learn.microsoft.com/en-us/cpp/c-language/typeof-c?view=msvc-170
14:59 gfxstrand: It's in MSVC now
14:59 zmike: impossible
14:59 gfxstrand: If you have a really new version, anyway
15:05 Lynne: yup, c23 is great, compiler support is still a bit lagging though, had to write my third or fourth meson+python .bin to .h program because #embed is still missing
15:22 gfxstrand: jenatali: How tightly are we chasing new MSVC? Looks like we've had typeof since March or so.
15:23 glehmann: what do you want to use it for?
15:23 gfxstrand: It's useful for all sorts of stuff. Basically any time you want to make a C macro typesafe.
15:23 gfxstrand: In this particular case, I want to make an auto-dlsym() macro
15:24 gfxstrand: I don't care about C23 everywhere. I want to be able to depend on __GNU_SOURCE__ || C23
15:24 gfxstrand: It's just MSVC that's refused to implement typeof()
15:31 jenatali: gfxstrand: what do you mean "we've had"?
15:32 jenatali: Oh I just scrolled up
15:33 jenatali: I'm about to head to the office, I'll try to see what versions we've got available on our internal build runners we use for releases. We're usually pretty up to date though
15:49 jenatali: gfxstrand: Internally we've got 19.41.34120 which has it. Looks like Mesa CI containers are using 19.29.30154, which does not. You won't get pushback from me bumping the min VS version to 17.9. Not sure there's any other MSVC stakeholders these days?
15:54 jenatali: Based on the comments in that doc, we probably want to stick with __typeof__ until we actually start requiring C23 though
15:54 gfxstrand: cool
15:54 gfxstrand: Yeah, __typeof__ is fine
15:55 jenatali: I'll send a MR to rebuild the Windows containers, that should pull in a new enough version of VS
15:58 gfxstrand: \o/
15:59 jenatali: Hm. They were rebuilt in July, that should be new enough... must be something else using an old one, one moment
16:00 jenatali: Ah right, when Yonggang updated to VS2022 there were problems with using the latest build tools that I couldn't reproduce. I think I actually did fix those recently though, something with NaNs and bad SSE codegen in optimized builds. Let's try that...
16:07 gfxstrand: I'm not gonna run around sticking __typeof__() everywhere just yet but it's good to know that we can soon.
16:09 jenatali: Yeah, I'm just happy to be able to remove one more "MSVC holding us back" thing
16:19 jenatali: gfxstrand: Assuming !30877 builds/runs the Windows jobs successfully, we should be good to go
17:01 sima: agd5f, https://lore.kernel.org/dri-devel/20240823075331.GE1049718@ZenIV/ want me to pull this directly into drm-next?
17:01 sima: if so pls ack
17:09 sima: emersion, pq https://lore.kernel.org/dri-devel/20240822172338.698922-1-jfalempe@redhat.com/ suddenly very expensive addfb2
17:09 sima: (I think this is the first, but not entirely sure)
17:46 jenatali: Hm. Somehow this broke Vulkan fp16?
18:09 jenatali: https://mesa.pages.freedesktop.org/-/mesa/-/jobs/62805261/artifacts/results/dEQP-VK.spirv_assembly.instruction.graphics.float16.arithmetic_1.fmax_vert.xml
18:09 jenatali: FMax between -inf and 0 should return 0, but the test is claiming expectation is +inf? Amazing...
18:26 biju: Hi, I see the below message in todays next for panfrost driver. Is it expected?
18:26 biju: panfrost 11840000.gpu: gpu sched timeout, js=1, config=0x7b00, status=0x0, head=0x6116140, tail=0x6116140, sched_job=0000000048bfa259
18:26 biju: [ 32.507714] panfrost 11840000.gpu: Panfrost Dump: BO has no sgt, cannot dump
19:12 demarchi: tursulin_: since you worked in the fdinfo tests for i915... could you take a look in the first patch of this series: https://patchwork.freedesktop.org/series/137824/
20:19 karolherbst: is there a restriction how many mipmap levels a texture can have in OpenGL/gallium?
20:20 jenatali: karolherbst: 15 I think
20:20 jenatali: log2(16K dimensions)
20:22 karolherbst: yeah.. that would be an implicit restriction
20:23 jenatali: gfxstrand: I think there's an MSVC regression that broke deqp :( https://gitlab.freedesktop.org/mesa/mesa/-/jobs/62810427. If we need typeof sooner then we can baseline these fails but I'd like to try to dig in more and see what's going on
20:23 karolherbst: sadly cl_khr_mipmap_image doesn't state anything in this regard...
20:23 jenatali: The "expected" results in these log files look wrong to me
20:23 airlied: karolherbst: it's tied to max texture size
20:23 karolherbst: okay
20:24 airlied: no need for a separate limit
20:24 karolherbst: then I'll probably do the same
20:24 karolherbst: airlied: the full range is supported? like until you hit 1x1x1 as the mipmap size? Or is that more explicit than that?
20:25 airlied: yes all the levels until you hit 1x1
20:25 karolherbst: okay
20:25 karolherbst: so log2(max_size) or something
20:25 karolherbst: +-1 or so
20:25 airlied: oh mesa has MAX_TEXTURE_LEVELS define
20:25 karolherbst: ohhh..
20:26 karolherbst: maybe I just use that one then...
20:26 airlied: and gallium has PIPE_MAX_TEXTURE_LEVELS which is different :-P
20:26 karolherbst: of course..
20:27 airlied: but yeah key it off the max size
20:27 karolherbst: the spec is also weird, because num_mip_levels 0 == 1 or something and 2 means "texture + 1 mipmap level" 🙃
20:31 jenatali: airlied: I wonder if gallium supports 32k textures where GL only supports 16k?
20:31 karolherbst: it does
20:32 jenatali: Ah that'd explain the difference
20:32 karolherbst: some hw can even support 64k as long as it's not msaa
20:32 karolherbst: and I think freedreno wanted ti bumped to support bigger CL images
20:33 karolherbst: but at some point we'll have to bump some int types, because you can't really do more than 32k with 16 bit
20:34 karolherbst: which reminds me.. I also want to support buffers bigger than 2GiB...
20:34 jenatali: The problem we run into in D3D land is maintaining 8 bits of subtexel precision in a 16.8 fixed point
20:35 karolherbst: oof
21:23 DemiMarie: jenatali: does anyone really use texture min/max instances?
21:24 jenatali: Hm?
21:24 DemiMarie: Some form of sampler that DirectX specifies that Apple GPUs don't implement and which cannot reasonably be emulated.
21:26 jenatali: Oh, min/max sampling
21:26 jenatali: Yes, I've definitely seen it used
21:27 DemiMarie: Is there a way to emulate it?
21:30 jenatali: Not performantly
21:30 DemiMarie: What are the non-performant ways?
21:30 DemiMarie: And how common is it?
21:38 jenatali: IIRC the place I saw it was in some depth downsampling thing for volumetric fog in Doom Eternal. To emulate it you'd have to sample all of the texture taps and do the min/max in shader code. Which means you'd have to recompile the shader based on knowledge of the filter mode... which is really hard
21:39 DemiMarie: Could it be done with a branch in the shader itself?
21:47 jenatali: Probably
23:44 emersion: sima, hm that's not great… it's in the test commit codepath