03:34 neatversion: I was stupid anyway, so gpio writes are conditional, they can not be treated without separate pass, if branching is already separate, so what to do is, have the globals memory stretched to twice the size in hash, just knowing the mask is at higher value, you can shrink the empty space by adding to that offset which needs to be the highest of them all, so in other words globals get dynamically appended, but their content is referencing
03:34 neatversion: the structures like register banks after elimination
04:04 mupuf: the radeonsi-gl jobs need to be trimmed down: they run in 20-25 minutes when things go well, at push on 45 when a retry is attempted. That's too high and almost got my MR on an otherwise-idle system to run over the 1h mark
04:04 mupuf: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/49739031 is the worst-offending job
04:04 mupuf: DavidHeidelberg: do you know who I should contact here?
04:05 mupuf: Additionally, we probably should not be running radeonsi testing when modifying expectations for radv. That part should be easy to fix
04:06 mupuf: and ci-fairy seem like it could do with more retries and shorter timeouts
04:09 neatversion: Dynamic branches can be handled, I think I was tired to land such a contradictive sentence, branching is controlled by data dependence graph i.e incoming data path, however yes it can be done, Gini does it too but I try again to make it even shorter, and since all other code works, there's nothing than jackpot to left to be targeted anyways.
04:24 neatversion: Most interesting is that it really does not care as to when things get added in case you do some offset/index combination linear algebra, it just permutes things back in place at any time you eliminate correct values, but having globals or gpio at different sizes allows you to separate them to be loaded in from dma and written back from dma, that's the approach needed.
04:47 neatversion: Also ioctl concern was real, when malloc can be transformed to any local pool allocator, than ioctl can not be, it needs to make the same call
04:49 neatversion: And that has to be done on CPU, demangler can not achieve this on dma either, cause dma on CPU has no scratch access to registers
05:07 neatversion: Hence technically templeos writer, Sarah Sharp, and this systemd guy, are all correct, as much as or the more in userspace the better it is on modern computing. That would perform lot better, so to call me terry, his only flaw was fighting the linuxwall , nv35 driver did lots in userspace too, it really died out perhaps too, terry was very intelligent otherwise , he was very correct, but I ain't gonna put up a fight, it's just clear
05:07 neatversion: that women are whores and the particular monster was only gold digging at me and ordered by other dorks to finish me off, not much I fight there my people ban her all and her other humiliators, it's not a fight I just do not give any pennies to them.
05:16 neatversion: I actually assume that there are some projects that take Linux kernel and just make libraryos or realtime os libs out of them.
05:18 neatversion: Normally you'd be restricted to gpl there due to those, but anyhow solver based transformations really do not have any laws to cling to
05:56 dj-death: people are aware of the trace problems on CI with "502 Bad Gateway" ?
06:39 daniels: 7:35 AM <daniels> dj-death: it’s been reported on #freedesktop, yeah
06:39 daniels: dj-death: it’s been reported on #freedesktop, yeah
06:49 dj-death: daniels: thanks, would that be okay to disable the traces for now?
06:51 DavidHeidelberg: dj-death: sure :(
06:52 DavidHeidelberg: dj-death: can you disable also traces mentioned in Alyssa MR?
06:53 DavidHeidelberg: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25497/diffs?commit_id=a0ee217750109fec5a5d8ac35da58790f1d9c71a (it needs one include dot fix for some a618-performance job)
06:53 dj-death: sure
06:55 dj-death: MR updated
07:01 DavidHeidelberg: dj-death: ".a618-traces" in "a618-traces-performance"
07:03 dj-death: I bet it's everywhere
07:30 daniels: well yeah, if we can’t access the s3 server, then everything which touches it needs to be killed
07:35 DavidHeidelberg: dj-death: bentiss fixed it, should be working
07:37 dj-death: DavidHeidelberg: nice, thanks
10:46 MrCooper: is there a proper way to check a plane's current state without using drm_atomic_get_plane_state?
11:10 linkmauve: Hi, how do you trigger the various GPU errors that can happen on i915?
11:10 linkmauve: Ideally only for one process of my choice.
11:11 linkmauve: But a full GPU reset could also be useful to test against.
11:22 mlankhorst: Look at IGT?
11:25 linkmauve: intel_gpu_abrt?
11:36 linkmauve: Ah, it uses /sys/class/drm/card1/device/reset according to tests/device_reset.c
11:37 linkmauve: Also /sys/class/drm/card1/device/power
11:37 linkmauve: Thanks, this was helpful. :)
11:38 linkmauve: Is there a way to create a per-context or per-process fault instead of a global GPU reset?
11:49 linkmauve: Haha, writing to /sys/class/drm/card1/device/reset made my whole screen not display anything, and the wifi was disconnected as well, I guess it crashed more than what I actually wanted. ^^'
12:17 karolherbst: kisak: what's the quickest way to get https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/nvidia?id=2e92a49f90f73c8edc44b25c6e669d5e70893c90 backported into debian/ubuntu? We get repeated bug reports and apparently nobody seems willing enough to file a downstream bug report
12:17 karolherbst: (and I'm not willing either anyway)
12:54 alyssa: bbrezillon: man I would've loved https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25498 for pan_indirect...
12:54 alyssa: kusma: ^^
12:56 kusma: Yeah, looks interesting
12:59 karolherbst: funky
13:00 alyssa: thanks :)
13:00 alyssa: it's not really opencl..
13:01 alyssa: there's no CL API, no kernel stuff whatsoever, and no libclc (to keep you from shooting your feet)
13:01 karolherbst: yeah, fair
13:01 alyssa: mostly just that CL is the magic word to compile big exisitng C code (like genxml) to NIR libraries
13:02 alyssa: and CL C is massively closer to cpu C than glsl/hlsl/etc are
13:02 karolherbst: commenting on some of the `SPV_` extension stuff.. we kinda need a better way of letting all of mesa know what we support... but uhh.. whatever, you can read the comment once I post it
13:02 alyssa: that's probably copypasta from intel_clc
13:02 karolherbst: yeah
13:02 alyssa: (glsl doesn't even support enums.............)
13:03 alyssa: and glsl + bda is really ugly imho.. and mesa glsl doesn't support bda so it'd be glslang... so since we need CL anyway, might as well get real pointers out of the deal...
13:03 karolherbst: right... though without bda it's even worse
13:03 alyssa: ye
13:04 alyssa: aesthetically this seems much better than the glslang stuff radv does
13:04 karolherbst: rusticl on zink even requires bda, because without it, it's just pain
13:05 karolherbst: I should also wire up the atomic float stuff in rusticl, I think there are CL extensions for it...
13:05 karolherbst: also.. do we support all of SPV_INTEL_subgroups?
13:06 karolherbst: seems like we don't handle SubgroupImageBlockIOINTEL
13:06 alyssa: iunno
13:08 HdkR: How soon until clc supports C++? :>
13:08 karolherbst: uhhhh
13:08 karolherbst: pain
13:09 karolherbst: alyssa: btw, there is also this idea I have in regards to libclc pre compiling and moving it into the mesa build system, but that could be pain and could mean we might end up compiling spirv to cached nir per generation of GPU or something. But I'm not sure if that's even a good idea, because the few seconds on initial startup isn't that expensive
13:09 karolherbst: just on my raspberry pi 4 with libasan enabled it takes like 5 minutes :D
13:11 alyssa: karolherbst: sure
13:12 alyssa: mostly i looked at the use cases for driver clc and concluded if you hit libclc for anything you're holding it wrong
13:12 alyssa: so made a deliberate choice not to link libclc
13:12 alyssa: oh no. no gamma functions. what shall i do
13:13 karolherbst: yeah, that fair. It's just that with all the static code we compile at runtime, it might also make sense to move some into mesa compile time, I just don't think it's really worth it for now
13:13 karolherbst: I'm mostly wondering if we'll ever do that
13:17 karolherbst: alyssa: one thing _some_ drivers might run into: fma. If the driver sets `lower_ffma32`, we'd call into the libclc ffma function
13:17 karolherbst: *fma instead of `nir_ffma`
13:19 karolherbst: might want to pass in `-cl-mad-enable` as well..
13:19 karolherbst: so fmad can be optimized to ffma
13:20 kisak: morning karolherbst, sorry, I don't have any influence in that direction. tjaalton would be one step closer to maybe knowing where to ask about that.
13:20 karolherbst: kisak: okay.. I'm mostly just getting tired teeling the 5th user to file a downstream bug and nothing happens except more users running into the exact same bug :(
13:22 kisak: maybe try direct comms with Juerg Haefliger <juerg.haefliger@canonical.com> from https://changelogs.ubuntu.com/changelogs/pool/main/l/linux-firmware/linux-firmware_20220329.git681281e4-0ubuntu3.18/changelog ?
13:23 karolherbst: yeah.. hopefully that works, trying to contact Juerg directly later then
13:33 alyssa: karolherbst: those drivers shouldn't call fma then
13:34 alyssa: holding it wrong
13:35 HdkR: Foot, meet gun
13:41 Lynne: alyssa: with some macros, glsl+bda is at least tolerable
13:42 Lynne: plus, who know, one day we may get untyped pointers which would make it easier
13:42 alyssa: Lynne: why would I settle though? :)
13:43 alyssa: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25498/diffs?commit_id=e4f9d04931385acf971ffdb9950871f29330f64b
13:43 alyssa: this is downright magical
13:43 alyssa: ~seamless integration of significant existing C code for the CPU with the gpu comiler
13:43 dj-death: alyssa: really nice
13:43 dj-death: alyssa: I'll try to move the anv internal shaders to that
13:43 alyssa: dj-death: :-D
13:44 alyssa: dj-death: there are a few genxml patches that could probably we cleaned up but yeah
13:44 dj-death: that should get rid of the glslang dependency and give some pretty nice flexibility
13:44 alyssa: also, cold take, but glsl is terrible to write in
13:45 dj-death: better than NIR, cold take...
13:45 alyssa: no implicit coercion between "1" and "1u" is just mean
13:45 alyssa: clc gets what I actually wanted -- writing real C code
13:47 alyssa: hopefully review isn't too terrible lol
13:48 dj-death: main problem is time ;)
13:50 alyssa: yep
13:50 alyssa: maybe i'll xdcnerdsnipe it
13:52 tjaalton: kisak, karolherbst: the backport has been pending for more testing on jammy-proposed, ready to move to updates now
13:58 tjaalton: too bad that the guy who spams upstream is failing to verify the fix on our side
14:00 tjaalton: and in fact this one was not in jammy-proposed, only lunar, and is not moving because no-one being able to verify it
14:21 kchibisov: I'd assume this is a valib bug report for regression https://github.com/alacritty/alacritty/issues/7260 ?
14:21 kchibisov: I'm just not familiar with r300/r400, so not sure what to expect from them.
15:09 karolherbst: tjaalton: I see
15:10 karolherbst: tjaalton: well.. all I can say is, that those firmware files are fixing real issues and should be rolled out asap
15:10 FLHerne: kchibisov: valid bug, best-efforts but people do care for them
15:10 karolherbst: it's the 5th bug report on this, and always caused by those files not being updated
15:11 karolherbst: anyway, not using the updated firmware files won't give you any upstream support, because it's just a waste of time from upstream pov
15:17 karolherbst: tjaalton: anyway.. the linked deb file doesn't contain the upstream firmware files, so I guess you should just talk it out with that user and explain how to test a fixed build
15:17 tjaalton: yeah he hijacked another bug
15:17 tjaalton: and is asking for something else really
15:18 karolherbst: mhh?
15:19 karolherbst: what bug do you mean?
15:19 tjaalton: 2e92a49f90 fixed it for the original (ubuntu bug) submitter
15:19 karolherbst: ahh, I see
15:20 karolherbst: anyway, I hope you all be able to figure it out and how to get the fixes shipped to all users
15:20 tjaalton: as long as the original submitter would reply after ~2 weeks :)
15:20 karolherbst: well, I can tell you that there won't be upstream support without those updates
15:20 tjaalton: and not this nonsense pingpong with lassi :P
15:20 tjaalton: sure
15:20 tjaalton: I'm not asking for that
15:20 karolherbst: just ship them, it's wasting our time that users don't use them
15:21 karolherbst: or rather don't have them
15:21 tjaalton: we have policies for stable updates
15:21 karolherbst: yeah, I don't care
15:21 karolherbst: it's critical to have those files, I can't really phrase it any differently
15:22 karolherbst: I'm tired of having to tell users that they should tell their distribution (whatever debian/ubuntu version) that those files aren't backported
15:22 karolherbst: leave a comment with "upstream says those files _must_ be backported" if that helps
15:23 karolherbst: just get those files to users
15:25 kchibisov: FLHerne: I guess I'll just forward this bug.
15:27 FLHerne: I had a quick look and couldn't spot any commit that looks obviously relevant, should be easily bisectable though
15:27 kchibisov: Yeah, but I don't think the person can bisect...
15:49 emersion: i feel like DRM shim would be easier to implement by overridding some of the libdrm functions, rather than libc
15:50 emersion: at least for some of the stuff in there
16:15 alyssa: pendingchaos: is this expected to vectorize? https://rosenzweig.io/vec-may.txt
16:18 pendingchaos: alyssa: no, I think the casts are messing it up
16:18 alyssa: ack
16:18 alyssa: I rewrote my shader and now it's vectorizing
16:18 alyssa: so.. pebkac
16:18 alyssa: ?
16:18 alyssa: LO
16:18 alyssa: :P
16:18 pendingchaos: I don't think that NIR could be vectorized without no_unsigned_wrap on the 32-bit additions
16:19 pendingchaos: (the current load/store vectorizer won't vectorize even with no_unsigned_wrap)
16:30 zmike:again accidentally types nir_ssa_def
16:30 dj-death: heh
16:31 zmike: the muscle memory is too strong
16:32 glehmann: typedef nir_def nir_ssa_def; when?
16:32 bnieuwenhuizen: any time you add it
16:39 Wallbraker: zmike: Have fun! https://gitlab.freedesktop.org/mesa/mesa/-/issues/9921
16:42 zmike: Wallbraker: I've got an easy fix for you
16:42 zmike: just stop using that app
16:42 Wallbraker: Hah, well it's Monado which is day job, so can't really avoid it. :p
16:43 zmike: I'd be happy to give you a reference to a number of reputable software firms that are hiring if it means you'll close that ticket
16:46 Wallbraker: I'm pretty happy here, and in general races should be avoided. :p
16:48 zmike: damn, looks like I'll have to try to fix it
16:54 Wallbraker: Hehe
16:54 alyssa: pendingchaos: nod
16:55 Wallbraker: So I tried with vkcube but it doesn't open on the correct screen for some reason. What I think happens is that whatever code we have in Monado causes the compositor to move the window between one monitor and the other, and the window is resized.
16:56 Wallbraker: Just reverting that commit on the 23.2 branch fixes the issue for me.
16:56 zmike: I don't understand how that commit could be causing your issue
16:57 Wallbraker: Me neither
16:57 Wallbraker: Might be a race
17:11 Wallbraker: Yeah it's a *fun* race, without the patch reverted if I do the geometry getting twice with a `sleep(1);` in between them I can get:
17:11 Wallbraker: x11_surface_get_capabilities: Extent 1080 800
17:11 Wallbraker: x11_surface_get_capabilities: Extent 1440 800
17:17 Wallbraker: Beginning to doubt it's a mesa bug.
17:20 Wallbraker: zmike: I think I'm going to close the issue, the issue seems to be in my particular setup and that Monado only does one frame in that particular setup (waiting for clients). And it does that in just the wrong amount of time while `gnome-shell` is trying to work out on which screen the window is and has it sized wrong.
17:21 zmike: 🙏
17:21 zmike: the ghost of ajax was with me today
17:21 Wallbraker: Haha
17:22 Wallbraker: But gosh was it a head scratcher that my window got corruption if I added specialisation to my vertex shader or not.
17:22 zmike: 🤔
17:23 Wallbraker: But I could reproduce it with adding a sleep in the same function, so yeah, a race. But if I make it produce more frames it corrects itself when it get a VK_SUBOPTIMAL_KHR from DRI3.
18:35 robert_mader: Hi! I wanted to ask if there are any Intel kernel driver devs around here? There seems to be bug that currently breaks direct-scanout of certain YUV formats (specifically NV12 and P010) in certain cases and I wondered who could be a good person to talk to about this (or where a good place for filing issues for stuff like this is). More context: https://gitlab.gnome.org/GNOME/mutter/-/issues/3031
18:38 airlied: vsyrjala: ^
18:47 mlankhorst: robert_mader: I'm curious
18:50 robert_mader: mlankhorst: As mentioned in the issue my current suspicion is that NV12/P010 (i.e. multi-plane formats) are broken on the primary plane for some reason.
20:55 yrlf: Another intel-related question: I have a Gemini Lake Refresh device with UHD Graphics 605 (GLK 3) that has a really strange modesetting bug
20:56 yrlf: when KMS is enabled, the screen has strange vertical lines at regular intervals, and you can't read anything
20:56 yrlf: this is maintained even when modesetting happens, e.g. starting something graphical like X11 or a Wayland Compositor
20:57 yrlf: the only thing that seems to fix it is deactivating the CRTC with DRM (set CRTC_ID of the connector to 0, set MODE_ID to 0, set ACTIVE to 0)
20:58 yrlf: this is the glitchy screen: https://i.stack.imgur.com/8YbhH.jpg
20:58 yrlf: and this is my hacky DRM program to "fix" it: https://paste.debian.net/1293841
20:59 yrlf: I guess the intel driver is somehow borking the initial modeset, but I don't know exactly what happens there, since I haven't worked with the kernel much yet
20:59 yrlf: after the "fix" with yeeting the CRTC, everything works fine, and future modesets work properly, even through suspend
22:20 FLHerne: is there an equivalent of INTEL_NO_HW for r300g? I thought there was but can't find it
22:21 anholt: drm-shim would skip execution.
22:21 FLHerne: oh, right