03:08 mareko: zmike: MESA_SHADER_CAPTURE_PATH dumps the shader from KHR-GL46.gpu_shader_fp64.fp64.state_query, MESA_GLSL doesn't work for some reason
03:09 mareko: zmike: the shadow compare test was supposed to be NEVER
03:10 mareko: zmike: dEQP-GLES31.functional.geometry_shading.query.referenced_by_geometry_shader should expect that a uniform in GS is referenced by GS, instead it should expect that the uniform might be moved to FS and check both
03:11 mareko: zmike: *dEQP-GLES31.functional.geometry_shading.query.referenced_by_geometry_shader shouldn't expect that a uniform in GS is referenced by GS, instead it should expect that the uniform might be moved to FS and check GS and FS
03:14 airlied: mareko: for fp64 is that a fixed function mesa shader then
03:14 airlied: ?
03:57 mareko: airlied: no
07:10 airlied: arrgh qcom got a vulkan ext and didn't update their struct types
07:12 HdkR: Is it a good extension at least?
07:15 airlied: multiview per render area
07:15 airlied: no idea :-P
07:21 pjakobsson: igt git broken?
07:22 pjakobsson: I cannot clone
09:34 tjaalton: when is 23.0.1 going to be released? it's four weeks since .0
09:35 ccr: [20:59] <dcbaker> PSA: I am working on the next meas 23.0 stable release, the situation with the CI is slowing things down. I'll be cutting the release as soon as possible
09:35 tjaalton: alright, thanks
10:32 javierm: tzimmermann: I think we already dicussed this, but would like to pick your brain for https://bugzilla.redhat.com/show_bug.cgi?id=2176782
10:33 javierm: tzimmermann: the problem is user expectations, it seems they expect that simpledrm would work even when booting on BIOS without passing a vga=$mode option
10:33 javierm: I believe you said that we could add a vesadrm driver if someone wanted to query and set the VGA mode?
10:34 javierm: anyways, for X11 of course works because there's an user-space VGA driver there, but not for wayland compositors that require a dri device
10:34 javierm: tzimmermann: we were discussing with jfalempe and believe that the workaround could be to add a "vga=normal" cmdline param for the "basic graphics mode" boot entry
10:35 javierm: what do you think?
10:35 javierm: s/user-space VGA driver/user-space VESA driver
10:40 zmike: mareko: ah okay, thanks
10:55 javierm: jfalempe: https://bugzilla.redhat.com/show_bug.cgi?id=2176782#c15, I'll try to type a patch for the anaconda installer to do this
10:58 MrCooper: can I get a review for https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21781 "ci: Enable LTO for fedora-release job"?
11:10 zmike: mareko: re: dEQP-GLES31.functional.geometry_shading.query.referenced where in the spec does it allow uniforms to be promoted to the next stage?
11:15 gawin: for being able to run CTS via ssh the target should be null? (like gbm for piglit)
11:16 zmike: surfaceless
11:16 zmike: mareko: I see now for the state_query one; which uniforms are you able to eliminate?
11:19 gawin: thx
11:24 tzimmermann: javierm, i'll be around later today to discuss
11:25 javierm: tzimmermann: sure, no rush. Thanks!
11:42 zmike: can I get an ack on this trace patch https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21609
11:42 zmike: literally anyone
11:59 psykose: i heard some wind blow by and shout "go zmike merge the patch!"
11:59 psykose: does that count
11:59 zmike: it does not
12:20 gawin: seems like amd moved docs to gpuopen (yesterday or today)
12:51 jfalempe: javierm, thanks for taking care of that.
12:52 javierm: jfalempe: yw
13:12 mareko: zmike: all uniforms that are unused are eliminated; if a shader writes a uniform into a shader output and that output isn't used in the next stage, the output is removed and uniforms become unused, but if the output IS used in the next stage, Mesa moves the uniform to the next stage and replaces the input load with a uniform load and removes the input and output
13:14 mareko: for uniforms to be propagated to the next stage, the outputs must store the uniform as-is, e.g. "output = uniform;" is propagated, but "output = uniform * 2;" isn't propagated, but may be propagated once we implement it
13:18 mareko: Vulkan could propagate any UBO loads across shaders easily if all shaders share the same descriptor list
13:21 zmike: mareko: unused=eliminated sure, but if I'm not mistaken the geometry shader case uses the uniform to write gl_Position
13:21 zmike: so I'm wondering how you're promoting that into the fs
13:22 zmike: or is this another case where MESA_GLSL=source isn't showing me the real shaders
13:22 mareko: gl_Position isn't touched with GS->FS
13:23 zmike: so then how is it you're eliminating the uniform load in the gs?
13:24 mareko: zmike: actually, it's not the GS
13:25 mareko: zmike: u_position is moved from VS to GS, and the test expects GS to return 0 for the referenced query, but it returns 1
13:25 mareko: gl_Position has no meaning in VS->GS as is treated like VARn
13:26 zmike: right, okay, I think I misunderstood what you were saying initially
13:26 mareko: I think I described it incorrectly initially
13:27 zmike: it looks like the test expects GS to return 1
13:27 mareko: for u_position?
13:27 zmike: yes
13:28 zmike: Query GL_REFERENCED_BY_GEOMETRY_SHADER, got 1 value(s), value[0] = GL_TRUE
13:28 zmike: is the test output
13:28 zmike: err
13:28 zmike: oh I see, this is u_offset
13:29 zmike: okay, I will fix this
13:29 mareko: Description="Unreferenced uniform u_position" .... Query GL_REFERENCED_BY_GEOMETRY_SHADER, got 1 value(s), value[0] = GL_TRUE .... Error, expected GL_FALSE.
13:29 zmike: yeah I was looking at u_offset
13:29 zmike: my mistake
13:31 mareko: it would be silly if the spec required us to return what the original source code contains
13:33 zmike: easy to fix
13:34 zmike: for the state_query one I wanted to know which uniforms you were seeing problems with so I can write a commit log
13:37 zmike: mareko: in addition, do you have any ideas for doing late selection for global glthread enablement? basically I want to 1) enable it globally 2) disable for big.LITTLE arch in some cases (tbd) 3) apply driconf glthread disables/enables
13:38 zmike: sort of in that order of precedence
14:33 tzimmermann: javierm, i read through that bug report. this only happens on bios systems, AFAICT?
14:36 javierm: tzimmermann: correct
14:37 javierm: for EFI it doesn't happen because the EFI firmware provides a framebuffer through the EFI-GOP runtime service
14:37 tzimmermann: javierm, your bootloader should set the videomode via vesa
14:38 javierm: tzimmermann: is that the gfxmode=keep in grub config or ?
14:39 javierm: tzimmermann: but yes, I mentioned that if either the bootloader (or the kernel via vga=$mode) set a framebuffer, then simpledrm will pick it
14:40 tzimmermann: javierm, it's a number of things: load_video ; set gfxmode=<mode> ; set gfxpayload=keep
14:41 tzimmermann: i don't think that the kernel needs patching. i have such a system (x86-64 + BIOS) and it runs simpledrm
14:42 tzimmermann: javierm, qemu is also a bios-system. does your cd image work with qemu?
14:42 tzimmermann: in 64-bit mode
14:43 tzimmermann: IIRC, grub runs in 32-bit or even real mode. so it can use vesa. only later the kernel switches to 64-bit
14:43 javierm: tzimmermann: good question. I'll test that
14:43 javierm: it may be that the fedora grub config is the problem then
14:43 javierm: tzimmermann: thanks for the pointer. I'll add that info to the BZ after testing in a legacy BIOS VM
14:44 javierm: tzimmermann: the set gfxmode=<mode> is something that the Suse installer sets or ?
14:44 tzimmermann: maybe these users can experiment with the grub settings while they boot
14:45 javierm: tzimmermann: yeah, question is how to get that by default instead of needing a custom grub config
14:45 javierm: that's why I thought that maybe for the "Safe graphics mode" (that AFAIK sets "nomodeset") it could add a vga=normal
14:45 javierm: or vga=ask if the user wants to choose a mode
14:46 tzimmermann: javierm, do you use grub on the cd? i think suse uses soemthing else
14:46 javierm: tzimmermann: right, fedora also uses syslinux I believe
14:46 javierm: but I was going to test installing a system and then testing booting with the safe graphics mode
14:47 tzimmermann: javierm, ok. same here
14:47 tzimmermann: that's a different story then: it may not select the correct vesa mode. but it should allow for vga=
14:48 tzimmermann: could users set this on the command line
14:48 javierm: tzimmermann: yeah, with vga= it should work
14:48 tzimmermann: IIRC there are options to configure video output on suse installers
14:49 javierm: is just that users were expecting it to work without anything setting a vesa mode, but as explained in the ticket that wasn't the case for vesafb either
14:49 javierm: that is, before it was vgacon -> fbcon using fbdev emulation of the native DRM
14:49 javierm: and for X11 it only worked due Xorg having a VESA user-space driver. So I don't know why they thought that simpledrm would be different
14:51 javierm: tzimmermann: thanks for your thoughts. I'll look at the bootloader story w.r.t VESA mode setting
14:51 tzimmermann: javierm, i'd tell them to try vga=318 to get 1024x768-16
14:51 tzimmermann: see https://www.kernel.org/doc/html/latest/fb/vesafb.html
14:51 tzimmermann: i'm not sure if that really works on 64-bit systems, but it's worth trying
14:53 tzimmermann: you *cannot* use vga= with grub2. it'll tell you to use gfxmode= and gfxpayload=keep
15:00 javierm: tzimmermann: really? I thought that you could change
15:00 tzimmermann: javierm, grub2 complains that vga= is deprecated. it insists on using its own settings instead
15:00 tzimmermann: but syslinux still supports vga=
15:01 tzimmermann: grub2 configures video output and hands it over to the kernel
15:03 tzimmermann: the linux kernel handles vga= very early in the booting. when it still runs in real mode. i'm not sure how this interacts with the boot loader
15:03 tzimmermann: so maybe there's some magic behind vga= that grub2 devs don't want to support any longer
15:06 tzimmermann: javierm, IIRC boot_params comes from the boot loader. and the screen_info comes from that. it's later interpreted by the sysfb code https://elixir.bootlin.com/linux/latest/source/arch/x86/kernel/setup.c#L910
15:07 tzimmermann: https://elixir.bootlin.com/linux/latest/source/drivers/firmware/sysfb.c#L74
15:14 mareko: zmike: not sure what you mean, also why not do thread pinning for big.LITTLE?
15:14 zmike: mareko: I've created https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21926 to solve big.LITTLE; the issue isn't pinning, it's just having too many threads
15:15 zmike: I tried pinning initially, but having the thread active is too much
15:17 mareko: zmike: I would just turn off glthread at its initialization and keep gallium out of
15:17 mareko: it
15:18 zmike: mareko: the issue is that it's still good in some very select cases
15:18 zmike: for source games, for example, it's still faster somehow
15:19 zmike: otherwise yes, it would be simpler to just add this bit into dri_context.c
15:20 mareko: I would just add it the big.LITTLE logic into glthread.c with an option override from driconf
15:20 zmike: hm
15:20 zmike: I'm not entirely sure what that would look like?
15:21 mareko: _mesa_glthread_init can fail, so make it fail for big.LITTLE if ctx->st->options doesn't override it
15:22 zmike: hm st->options doesn't seem to have a glthread member so I guess I'd have to add that too
15:23 mareko: it's just for driconf options
15:23 mareko: I wouldn't mess with the pipe loader for glthread
15:23 zmike: I agree, I'd rather not
15:24 zmike: maybe I'm not understanding what you mean after all...how can I determine whether the app is enabling glthread vs the driver from st->options
15:25 mareko: you mean driconf vs driver
15:25 zmike: yeah
15:25 zmike: that
15:25 jenatali: I think he's suggesting a new driconf option to override the big.LITTLE defaults for glthread
15:25 jenatali: That would only be set per-app
15:26 mareko: drivers only set the default value of mesa_glthread and driconf only overrides it for apps, it's not possible to split that right now
15:26 mareko: well it technically is possible with some extra work
15:27 zmike: driconf in general makes my head hurt
15:27 zmike: basically I want to set the default value based on big.LITTLE and then have driconf apply on top of that
15:27 mareko: or make the driver default a PIPE_CAP, and call _mesa_glthread_init if CAP || driconf
15:27 zmike: hm
15:28 zmike: that's terrible but probably less terrible than involving the loader
15:29 zmike: though that wouldn't handle cases where driconf disables glthread
15:29 zmike: since driconf would be false by default?
15:29 jenatali: Seems like driconf should be an enum
15:30 robmur01: zmike: FWIW, peeking at that PR out of curiosity, I wouldn't rely on any kind of consistent CPU ordering with big.LITTLE. At least not on Arm ;)
15:30 jenatali: Override to false, override to true, override to true even for big.LITTLE
15:30 zmike: robmur01: yeah I figured, it's just a proof of concept atm
15:30 zmike: but thx for the info
15:32 zmike: jenatali: and yes, as usual a tristate bool would solve all problems
15:32 robmur01: ideally there should be a "capacity" figure exposed somewhere which is really the indicator you want, lemme check...
15:33 robmur01: ah yes, /sys/devices/system/cpu/cpuX/cpu_capacity - that should represent the kernel's internal measure of big.LITTLEness
15:33 zmike: oh cool
15:34 zmike: thanks for the tip
15:34 robmur01: beware yet again, though, that there may be more than just two values - we have "mid" CPUs now too :(
15:34 mareko: using those DRI_CONF definitions is also not fun, see how radeonsi defines its driconf options and defaults in si_debug_options.h
15:36 zmike: maybe a stupid idea, but I wonder if I could just inline all the u_cpu calls into the driinfo header and have it evaluate that on init?
15:38 mareko: you need C++ for that
15:39 mareko: the macros are just structure definitions, I think C doesn't allow function calls there
15:39 zmike: yeah, but if only
15:44 zmike: mareko: your glthread_init disablement idea also doesn't seem like it would handle the default=disable,driconf=enable case 🤔
16:02 javierm: tzimmermann: sorry, I was on a medical appointment. Yes but IIRC the arch/x86 early code can override it with vga=
16:02 javierm: I'll check the code later
16:02 javierm: tzimmermann: and thanks!
16:02 tzimmermann: yw
16:26 enunes: I'm a bit confused by the CI announcement in gitlab fdo, my runner seems to still be picking jobs running in mesa/mesa and people's forks, do I need to make the change in that referenced issue otherwise it will stop picking jobs soon?
16:35 MrCooper: enunes: I'd ask bentiss on #freedesktop
16:37 anholt: enunes: if you don't make the change on your runner, then if they get past our first-pass filtering then they might attack your runner.
16:37 anholt: if you don't make the change, your runner stays open for all
16:42 enunes: anholt: ok I see, thanks for the clarification
17:23 Lynne: hmm, p_dual_src_export_gfx11 has some issues
17:35 Lynne: either I can't replicate it anymore, or the size of the fourth definition is not 2
17:38 Lynne: nope, the size of the fourth definition is definitely not 2, but it's still an sgpr, weird
17:46 Lynne: I think the issue is that bld.def(bld.lm) somehow returns an incorrect sgpr def, but I can't look through the abstractions to trace it
17:48 Lynne: hakzsam: any ideas or should I post an issue?
17:49 pendingchaos: why would it be an issue that the size isn't 2? a size of 1 is normal for wave32
17:54 jenatali: Ugh
17:54 jenatali: Someone broke the Windows build
17:55 pixelcluster: how even? isn't that checked in CI?
17:55 zmike: I hope it was me
17:56 jenatali: Windows CI is temporariliy disabled...
17:56 jenatali: It was https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6156. Added a pthread.h include in common code
17:56 pixelcluster: oof
17:57 jenatali: Agreed
18:02 anarsoul: jenatali: although I don't see pthread.h in https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6156.patch
18:02 jenatali: anarsoul: Sorry, it started pulling in the wsi_common_queue.h on Windows, which includes pthread references
18:05 jenatali: There's also the DRM fourcc header it pulls in...
18:07 Lynne: pendingchaos: ah, right, I had RADV_PERFTEST=pswave32 enabled, disabling it fixes the error
18:07 Lynne: overriding the check to allow it doesn't revel any issues _at a glance_
18:26 eric_engestrom: Venemo: just wanted to say thanks for going through all the issues and labelling them :)
18:26 eric_engestrom: it's giving me a bunch of emails to read, but it's very useful to actually see all these issues I missed
18:27 Venemo: eric_engestrom: sorry about the spam
18:27 jenatali: +1
18:27 eric_engestrom: no worries, I think of it as emails I should've received a long time ago but they got "delayed" :P
18:28 Venemo: I think most of us (myself included) look at labeled issues and the issues without labels just fall through the cracks
18:28 Venemo: the more issues there are without labels, the more likely they are to become buried
18:29 Venemo: there are 4 issues remaining without labels, I'm not really sure what to do with those
19:07 zmike: tag them as ci and say the crypto miners did it
19:08 ccr: "I'm not saying it was {aliens | crypto miners} .. but it was {aliens | crypto miners}."
19:30 Venemo: lol zmike :)
19:34 anholt: mupuf: keywords-gfx10-navi21-1 looks dead
19:35 anholt: last two jobs failing in the reboot loop to boot the machine
19:49 anholt: maybe not just that one https://gitlab.freedesktop.org/mesa/mesa/-/jobs/38142601
19:59 Lynne: Venemo: PR updated
20:00 Lynne: btw if you rebase your mesh shader PR on main, I could test it right now
20:00 Venemo: Lynne: can you assign 21934 to marge bot or do you need me to do that for you? also, out of curiosity why do you use pswave32?
20:01 Venemo: Lynne: which mesh shader MR do you mean?
20:02 Lynne: !21409
20:03 Lynne: I use pswave32 for really no reason at all but to test it, and to claim I have every single non-debugging perftest flag on
20:03 Venemo: I see
20:03 Venemo: are you aware it decreases performance?
20:04 Lynne: no, is it not like the other wave32 flags, which are used only if needed?
20:05 Venemo: what do you mean?
20:06 Venemo: all wave32 flags will switch the corresponding stage to use wave32 mode (with the exception of CS for a case when it may cause game bugs)
20:09 Lynne: yeah, come to think of it, I didn't really check, but w/e
20:10 Lynne: (no I do remember, checking, but I must've misunderstood from reading the source)
20:11 Venemo: Lynne: I've rebased 21409 for you now, it was a clean rebase just 1 patch needed to be changed (a function was moved to a different file)
20:12 Venemo: Lynne: regarding Wave32, we currently only use it by default for ray tracing shaders on RDNA2, we have some plans for using it by default in some other cases but we never took the time to do that, we only have the perf test flags which just crudely switch this mode on for that stage and that's it.
20:21 Lynne: thanks, I'll test it
20:21 Lynne: btw, I can't assign it to margebot, I'm not a dev
20:22 Lynne: you'll have to do that
20:25 Lynne: Venemo: I get quite a bit "Undefs can only be used in certain operands: v2: %21 = buffer_load_dwordx2" prints with !21409
20:25 Lynne: and "Undefs can only be used in certain operands: v1: %296 = tbuffer_load_format_x" + ..format_xy
20:25 Venemo: Lynne: interesting, I didn't get that last time I tried...
20:25 Venemo: how do you repro that?
20:27 Lynne: I just use proton to launch a game
20:27 Lynne: pretty much everything seems to trigger it
20:29 Lynne: yup, doesn't happen without your PR
20:29 Venemo: ah, probably a mistake in one of the buffer patches
20:52 Venemo: Lynne: should be fixed now. btw what game are you testing with? afaik there is none that uses mesh shaders
21:34 Lynne: Venemo: yup, that works
21:37 Lynne: I thought DXVK used it
22:29 Venemo: Lynne: for what?
22:35 Lynne: actually, it's vkd3d that supports it