00:07gfxstrand: cmarcelo: By inspection
00:10gfxstrand: cmarcelo: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25483
00:10gfxstrand: cmarcelo: I'm gonna run CI on it quick to see if anything blows up
00:11gfxstrand: I suspect we've just gotten lucky here because glslang always puts the patch decoration first
09:55linkmauve: “00:01:49 karolherbst> do we still have GPUs without MMUs produced today?”, my Mali400 says hi.
09:55linkmauve: My countless* Mali4xx.
10:00HdkR: The billions of Utgard devices that refuse to accept G31 in to their life
10:05linkmauve: I got my very first non-Utgard Mali GPU two months ago…
10:05linkmauve: A G52 which I haven’t had the time to test yet.
10:53yrlf: i have a question about a weird graphics issue I found that is likely DRM/DRI/modesetting related, and I have been directed to here since people suspect it's a driver bug
10:55yrlf: I have an Onda Oliver Book; a small Intel Gemini Lake refresh convertible with a DSI connector and (I think?) LVDS panel; i915 completely breaks what is displayed on the screen when it enables modesetting, nomodeset works
10:56yrlf: when modesetting is enabled, the screen stays broken until I *start and exit* sway (specifically sway, weston or X11 doesn't work), then modesetting works fine
10:57yrlf: I have some log dumps and a dump of drm_info before and after fixing the mode with sway
10:58yrlf: my suspicion is that the initial modeset by i915 somehow fails to set the mode correctly, though I don't know how to debug that
11:19yrlf: Okay I might have botched the terminology about panel types; at least, linux lists a DSI-1 device that is the one being used, and it's an LCD panel
13:40kisak: Looks like mesa 23.2.1 made it through the build farm without anything strange. RUSTICL survives another point release.
14:17karolherbst: nice
14:18karolherbst: kisak: fyi, I'll depend on meson-1.3 on the next release, probably. also I'm considering bumping the rustc version. What version is currently available to you?
14:20kisak: meson is something I can bump in kisak-mesa-build-deps currently ~0.61.2 or newer ( https://launchpad.net/~kisak/+archive/ubuntu/kisak-mesa-build-deps/+packages )
14:23kisak: rustc debian packaging is unlike anything I've seen in debian packaging and not something I'm going to bump. https://packages.ubuntu.com/search?keywords=rustc&searchon=names&suite=all§ion=all looks like 1.41.0 is the oldest with Focal arm
14:23kisak: oh right, n/m, I'm not building rusticl on Focal, so 1.66.1 or newer.
14:24kisak: 1.58.1 on Jammy arm ...
14:25kisak: err, where's that coffee, it's 1.66.1 on Jammy arm (updates channel)
15:50Lynne: I found a document mentioning that constants can be given to shaders by also embedding them in descriptor buffers
15:52Lynne: how does this work? you just assume that e.g. a structure has some size (skipping vkGetDescriptorSetLayoutSizeEXT) and you just bind it like anything else to a set binding?
16:26karolherbst: kisak: there is a rustc-mozilla package
16:26karolherbst: used for firefox
16:27karolherbst: I wonder if it's on 1.65 already everywhere or something
16:35kisak: looks like rustc-mozilla is Debian only, and maybe https://launchpad.net/~ubuntu-mozilla-security/+archive/ubuntu/rust-updates is the Ubuntu counterpart. Bindgen mashed up against that is an open question I'm not able to answer.
16:36An0num0us: how does the glsl ir in mesa represent switch statements? I do not see any instructions which would directly represent the statement or which could perform jumps
17:12karolherbst: An0num0us: if else ladders
17:32DemiMarie: karolherbst: is it a binary tree?
17:33karolherbst: mhhhhh, it's not
17:33karolherbst: but maybe that wouldn't be such a bad idea
17:34karolherbst: actually, that's probably always a win
17:35DemiMarie: Yup
17:35DemiMarie:wonders if one could write a compiler for a GPU, that runs on the GPU
17:35karolherbst: DemiMarie: it's kinda pointless to do though
17:35karolherbst: or adds complexity you don't want to have
17:36karolherbst: most drivers cache compiled code anyway
17:36karolherbst: and most games do a "shader precompilation/caching" step when loading
17:37karolherbst: also, nobody wants to rewrite all the existing code :D
17:39HdkR: It would of course also be ridiculously inefficient since you're running hugely scalarized code. You're not going to be able to run 32k threads of shader compiler
17:40karolherbst: could potentially tokenize in parallel
17:40karolherbst: but the problem also is that you don't have an API for "compile those 2000 shaders"
17:43HdkR: Create an extension just to try and improve fossilize compile times. Since that batches the world :D
17:58karolherbst: then we still have to figure out how to parallise the compiler :D
18:13DemiMarie: karolherbst: Modern query-based compilers can already use multiple cores, but I’m not sure if they can use 32k threads.
18:13HdkR: 32k with no stack space mind you
18:14HdkR: Might be a bit tricky
18:16DemiMarie: Where is the best place to follow virtio-GPU’s Xen, AMD, and Intel ports?
18:17DemiMarie: I’m going to be adding GPU acceleration to Qubes using virtio-GPU native contexts so this is rather important :)