08:07 tzimmermann: jfalempe, thanks for the reviews
08:08 jfalempe: tzimmermann: you're welcome, sorry I should have done it earlier
08:09 tzimmermann: jfalempe, from shixiong's reply and from what i've found in the ast docs, i think we can finally solve the BMC problem. there's only officially one physical connector on each board: DP, DVI, VGA (my test board is an exception for, well, testing). and the BMC mirrors whatever is shown on that output. so we can model this as a single encoder+connector with brigdes in between. that will keep userspace happy and also
08:09 tzimmermann: integrate the BMC correctly. the BMC connector would go away.
08:09 tzimmermann: i have a similar prototype for mgag200, which appears to work
08:13 jfalempe: ok that looks fine
08:13 tzimmermann: i'm a bit tired of the BMC saga :)
08:13 tzimmermann: i'm going to put patch 1 into -misc-fixes
08:14 tzimmermann: the others will thne go into drm-misc-next later this week
08:22 sima: mripard, apologies for pushing a fix to drm-misc-next-fixes, wasn't entirely awake .-/
08:22 mripard: sima: yeah, that surprised me a bit :)
08:22 mripard: I took it into drm-misc-fixes, so it's no big deal
08:23 sima: thx
08:23 sima: tzimmermann, jfalempe there's no use-case for disabling the bmc I guess, so unconditionally enabling it is fine?
08:23 mripard: sima: I've also disabled push access to drm-misc-next-fixes in gitlab as a test
08:23 sima: ah yeah good idea
08:24 mripard: only for developpers though, so maintainers can still do it
08:24 sima: uh
08:24 tzimmermann: sima, it currently is enabled unconditionally
08:24 mripard: ie, you still can push if you're not fully awaken :)
08:25 tzimmermann: sima, the HW docs are a bit unclear, whether the BMC scanout can really be disabled
08:25 tzimmermann: even if we wanted
08:30 sima: yeah I guess then there's really no benefit in the explicit bmc connector, and only trouble
08:32 tzimmermann: sima, we had the additional BMC connector to make userspace keep the display enabled if there's no physical monitor present. didn't workout entirely :/
08:33 tzimmermann: sima, BTW i do have a patch to improve the kernel console's handling of mirrored outputs. shall i still send it?
08:33 tzimmermann: for mirrored outputs, the DRM client only picks 1024x768
08:34 tzimmermann: with the patch, it would look for a better/higher resolution
08:36 sima: tzimmermann, I think improving the fbcon clone logic is a good idea no matter what
08:36 tzimmermann: ok
08:36 sima: and yeah I guess that "real output disconnected, keep bmc alive" is a real use that would break if the bmc connector goes away
08:46 tzimmermann: sima, as long as the physical connector is still connected, it should work. in my mgag200-based prototype, on unplugging the monitor i clear the edid and install some default display modes. the connector is then in "BMC mode". incrementing the connector's epoch_counter generates a hotplug even for clients. appears to work nicely
08:47 tzimmermann: that is a bit more complicated for ast, but not fundamentally different
08:48 sima: hm this feels a bit silly, since it's essentially hand-rolling clone mode but not using the uapi
08:48 sima: otoh *shrug*
08:48 sima: especially when you can't shut off the bmc anyway
09:11 jfalempe: tzimmermann: sorry I was in a meeting. yes having better display mode, when the physical connector is unplugged is a good thing.
09:12 tzimmermann: i'll prepare something
09:13 jfalempe: sima, tzimmermann: I'm working on a drm_log, which uses drm_client api,I will send an RFC when it's a bit more polished.
09:13 tzimmermann: ok, sure
09:13 jfalempe: that way we can bypass fbcon/vt completely at boot.
09:17 jfalempe: I've made a small demo here https://people.redhat.com/jfalempe/drm_log/drm_log_draft_preview.webm
09:23 Ristovski: nice
14:24 DodoGTA: Why does drmSyncobjWait() use a signed integer for the timeout?
15:50 jenatali: Demi: You need WDDM on Windows, it can't just be a proprietary KMD model
15:51 jenatali: Demi: See https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24223
16:15 mareko: zmike: any luck making llvmpipe work with dril? glxinfo succeeds though without any double-buffered visuals it seems, and glxgears prints: Error: couldn't get an RGB, Double-buffered visual
16:16 zmike: mareko: uhhhh you mean like running xorg on llvmpipe?
16:19 zmike: or just using llvmpipe in general
16:31 mareko: zmike: xorg on llvmpipe
16:31 zmike: mareko: how are you starting it?
16:31 mareko: zmike: modprobe.blacklist=amdgpu on the kernel command line is one way
16:32 zmike: hmm
16:32 zmike: okay yeah I see it
16:32 zmike: fixing...
16:32 mareko: in reality, I have the wrong firmware version for my GPU, so amdgpu doesn't load, same effect
16:33 zmike: still a good catch
16:39 zmike: mareko: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30426
16:45 Company: zmike: while you're looking at llvmpipe - what's the state with llvmpipe and it using dmabufs on Wayland?
16:45 zmike: should work
16:45 Company: I was looking at that again because I want to convince GTK CI to create dmabufs
16:45 zmike: err
16:45 zmike: well, it should work at some point before 24.3
16:46 zmike: functionally it's all there but EGL has to catch up
16:46 Company: so I can look at mesa git and liberally steal code to create my own dmabufs for testing
16:46 zmike: which I have done, but unfortunately (some say) there is no way for me to push directly to main without review or testing
16:46 zmike: not as of yet
16:46 Company: right, once Marge agrees with you
16:47 Company: does that require specific kernels?
16:47 zmike: probably
16:47 zmike: but nothing esoteric
16:48 Company: it's all a question of what I need to tell our sysadmins
16:48 zmike: you need udmabuf enabled
16:48 Company: so that it works in whatever CI setup we use - and that I have exactly zero clue about
17:23 eric_engestrom: jenatali: does anything in https://gitlab.freedesktop.org/mesa/mesa/-/compare/3f31d50201454cba1f9689076908c02b924b69ed...d2efe26a520e279f0df33e603dda83cac636fcff look like it would cause `unknown file: error: SEH exception with code 0xc0000005 thrown in the test body.` in clc_compiler_test (on 24.1)? https://gitlab.freedesktop.org/mesa/mesa/-/jobs/61693786
17:23 eric_engestrom: I've retried the job a few times to see if it's a flake, but it's got a 100% reproduction rate, so something really is causing this in one of these changes
17:23 eric_engestrom: /cc karolherbst since it's most likely one of your commits
17:23 eric_engestrom: I have to go now, but tomorrow I'll start bisecting (always fun doing that by pushing to the CI), but I'm hoping one of you will see something I don't so that I don't have to do this 🙏
17:25 jenatali: eric_engestrom: I don't see f05b7225a331a72d7ff97c68b08b171fc31d3ce8 picked up?
17:26 jenatali: It was also part of 29896
17:26 eric_engestrom: hmm
17:28 eric_engestrom: looks like a bug in pick-ui (the release maintainer tool), it didn't pick that commit as nominated for backport
17:28 jenatali: Weird. It's got "Cc: mesa-stable"
17:28 karolherbst: I hope it's not due to the otherwise empty commit message
17:28 jenatali: I wonder if it's a line endings problem since I probably authored it on Windows with \r\n :P
17:29 karolherbst: ...
17:29 karolherbst: that would be a good one
17:29 eric_engestrom: yeah, the commit message looks right
17:29 eric_engestrom: oh
17:29 eric_engestrom: I don't know how to check that
17:29 eric_engestrom: the line ending thing
17:30 eric_engestrom: but yeah, that could be the issue
17:35 eric_engestrom: `git log -1 --format=%b f05b7225a331a72d7ff97c68b08b171fc31d3ce8 | xxd` shows a normal \n without \r, so I don't think commit messages have the line ending issue
17:35 eric_engestrom: I'll look into it more tomorrow, but now I have to go
17:35 jenatali: Yeah I was trying to see that too
17:35 jenatali: Anyways that's the missing commit
17:35 eric_engestrom: thank you both for your very quick help!
17:36 eric_engestrom: I have pushed that commit to the branch now so we'll know in a few minutes whether that's the fix: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/61694388
17:36 karolherbst: I hope you won't end up with "uhh, we are missing 100 commits never backported"
17:39 eric_engestrom: yup, that fix works 💪
17:39 eric_engestrom: karolherbst: yeah, that's my worry and that's why I want to figure out what went wrong so that I can grep for what other commits have hit that bug
17:45 eric_engestrom: oh, the commit parsing side actually did get the `cc: stable` and marked it for backport
17:45 eric_engestrom: so it's a bug in the ui part of the tool
17:45 jenatali: Oh fun
17:45 eric_engestrom: so at least fixing that will suddenly show all matching commits
20:25 DarkShadow44: is there a way to make mesa give an error message if it fails to compile a shader, preferably with details?
20:26 jenatali: DarkShadow44: https://docs.mesa3d.org/shading.html#envvars. MESA_GLSL=errors will dump errors to stderr
20:30 DarkShadow44: Like "MESA_GLSL=errors /bin/wine x.exe"? Because that doesn't print anything, but if I do an apitrace that will show shader compile errors
20:30 jenatali: Oh I don't know how wine/stderr interact
20:43 gfxstrand: dcbaker: Have we ever gotten a solution for include!() something from the builddir?
20:46 dcbaker: gfxstrand: I can't remember now, did `structured_sources` solve that or did we decide that wasn't sufficient?
20:46 dcbaker: https://mesonbuild.com/Rust.html#mixing-generated-and-static-sources
20:48 gfxstrand: Oh, maybe?
20:54 DarkShadow44: Shouldn't "MESA_GLSL=dump ./factorio" also dump the shaders? Because it does nothing
21:03 Company: are those env vars available when compiling a release build?
21:03 Company: I tried using NIR_DEBUG recently on some default machine and it didn't work
21:05 jenatali: Yep
21:06 jenatali: I don't see any #if wrapping around the logic that queries the env var or handling of GLSL_REPORT_ERRORS
21:09 Company: jenatali: I nominate https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/mesa/main/errors.c#L314
21:09 DarkShadow44: I had it work once, and how without anything changed it doesn't work again >_>
21:09 jenatali: ... oh
21:11 jenatali: Why is that using _mesa_debug instead of _mesa_error?
21:11 jenatali: DarkShadow44: Use dump_on_error which is apparently not documented in that list, but uses something that should work on a retail build
21:12 jenatali: Oh it also needs MESA_DEBUG=1
21:14 DarkShadow44: ah, so "MESA_GLSL=dump ./factorio" only works when the shader is not in .cache/mesa_shader_cache
21:14 DarkShadow44: is that a bug...?
21:14 Sachiel: no
21:14 Sachiel: MESA_SHADER_CACHE_DISABLE=1\
21:16 DarkShadow44: okay, thanks
21:16 Company: DarkShadow44: debug env vars are always blackmagic for developers (for large projects it's even a subset of at most 2-3 people), so it's expected that you need some obscure knowledge to use them right
21:17 Company: and once you know it, you remember the magic incantation of env vars and put them in some document somewhere
21:17 jenatali: "Some document somewhere" = public documentation?
21:17 Company: they tend to change from time to time
21:18 Company: mesa's docs are a good intro, but not complete enough for the more obscure stuff
21:18 Company: "your driver needs to use the frob subsystem for this to work"
21:20 Company: I'm not complaining btw - I think it's by design that things work that way, and not just in MEsa
21:24 DarkShadow44: dump_on_error isn't doing anything either
21:24 DarkShadow44: yeah, it's not exactly easy
21:24 jenatali: DarkShadow44: Did you also include MESA_DEBUG=1?
21:24 DarkShadow44: no
21:25 jenatali: "Oh it also needs MESA_DEBUG=1"
21:26 DarkShadow44: yes, yes it does. Thanks for your patience, it finally works :)
21:28 DarkShadow44: This does mean error in line 32, right? https://pastebin.com/73jwCB7m
21:30 Company: yeah
21:30 Company: it probably wants 1.0 and not 1
21:30 Company: because 1 is an integer
21:30 Company: GL transforms that automatically, GLES bugs out
21:31 Company: iirc
21:32 jenatali: Or is it complaining about vec4 * vec4?
21:32 jenatali: I can't quite tell which one line 32 is
21:36 DarkShadow44: it's the texColor *= (1.0 - Intensity);
21:36 HdkR: `debug env vars are always blackmagic for developers` My project even programatically generates documentation for environment variables and no one knows how to find them :D
21:39 DarkShadow44: is this a known bug, something I should report or a buggy program?
21:47 jenatali: Company: /* Prior to GLSL 1.20, there are no implicit conversions */
21:47 jenatali: So the problem is that the shader doesn't explicitly declare a GLSL version I guess
22:25 alyssa: HdkR: wait what
22:26 HdkR: alyssa: Knowledge is power
22:27 HdkR: `man fex` and search for the `ENVIRONMENT` section
22:27 Company: jenatali: my shaders have #version 320 es and they complain about it
22:28 jenatali: 🤷 I was just reading the code comment
22:28 HdkR: GLES also doesn't get implicit conversion unless you explicitly enable the extension for it
22:28 Company: and I just removed a ".0" from one of my shaders and tried ;)
22:29 HdkR: https://registry.khronos.org/OpenGL/extensions/EXT/EXT_shader_implicit_conversions.txt this thing, which I still think is a mistake :)
22:29 Company: HdkR: and because it's GLES, there will be one driver somewhere that doesn't implement it
22:29 HdkR: Of course
22:30 Company: coverage: 5.76%
22:30 HdkR: Most drivers don't support that extension even
22:30 HdkR: yep
22:30 Company: so only mesa probably ;)
22:31 Company: pvr and Adreno 740/750 apparently
22:31 HdkR: Late extension in the GLES lifespan, people are expected to shuffle off to vulkan now :P
22:32 Company: or as Mutter devs said at GUADEC: "There are currently no plans"
22:33 Company: our switch has been surprisingly painless btw
22:33 Company: but so far it's only nightlies, we'll see what happens once it hits releases
22:34 Company: worst problem is dmabuf support, because Vulkan is picky
22:34 Company: and because there's sometimes mismatches between EGL and Vulkan
22:35 Company: where EGL picks a new format that the Vulkan driver has no support for
22:39 alyssa: HdkR: woah!