00:49kode54: huh
00:49kode54: iris doesn't enable glthreads anyway
01:10kode54: MrCooper: I see artifacting on gnome-shell and kwin_wayland, with the Xe KMD, and there's no glthreads involved
01:10kode54: unless they're overriding it with their own internal use of environment variables
01:12kode54: though I do need to rebuild my mesa
08:47MrCooper: kode54: probably a separate issue
08:55MrCooper: kode54: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22544 might help for artifacts with xe
08:55kode54: I already have mesa-git built after that was merged
10:05Vanfanel: Hi. I am deciding on a SOC and RK3588 seems a good choice, but MESA support is a must.
10:05Vanfanel: Is official MALI G610 support coming to MESA?
10:09psykose: buy around what exists not what theoretically might show up or not
10:09psykose: currently it is not supported
10:09psykose: (for the "must" part)
10:26Vanfanel: <psykose> "buy around what exists not..." <- That's indeed a very good advice. Looking at MESA commits, I don't see anything related to G610 anyway.
11:03daniels: Vanfanel: it’s being actively worked on; branches are available but unmerged
11:15psykose: also tangentially the whole rk3588 is not quite there yet for mainline, so you'd have to use the 5.10 vendor kernel with it for most things on the board (even sdcard last i checked)
11:40daniels: psykose: SD/MMC was merged afaik
11:41daniels: display is still out-of-tree atm
11:43psykose: daniels: yep, it was, just some caveats https://gitlab.collabora.com/hardware-enablement/rockchip-3588/notes-for-rockchip-3588/-/blob/main/mainline-status.md
11:44psykose: incidentally my girlfriend just bought a rockpi 5b before checking any of this at all
11:44psykose: (quite funny)
15:38cwabbott: gfxstrand: the more I work with it, the more I'm convinced the `vk_graphics_pipeline_state` design where everything has to be in an indirectly-allocated struct was a mistake
15:38cwabbott: tracking dynamic instead of set state was probably also a mistake
15:39cwabbott: there have been a few cases where I just wanna split out a few pieces from an indirect struct and I can't because of the design
15:40cwabbott: like the one I'm hitting now is `vi->bindings_valid`, which is the only part of the vertex state that turnip actually needs in `vk_graphics_pipeline_state` (the rest is precompiled)
15:42cwabbott: apparently I was accidentally including the entire vertex input state in pipeline libraries even though it's been precompiled, which isn't what I wanted, and in trying to fix that I realized that it's impossible to do because of the design
16:03Vanfanel: <daniels> "Vanfanel: it’s being actively..." <- Hmm, do you mean Panfork? I fear that will never be merged, there's a strange story behind it but I believe it won't be developed further
16:04Vanfanel: if there are other branches I would love to hear from them :)
16:04daniels: Vanfanel: no, panfork will never be merged and I’m not sure if it’s still being developed or not. there’s work against upstream Panfrost tho
16:04Vanfanel: (i meant forks, sorry)
16:04Vanfanel: daniels: ah!! Very good news then, really! :)
16:05daniels: https://gitlab.freedesktop.org/bbrezillon/linux and https://gitlab.freedesktop.org/bbrezillon/mesa
16:08Vanfanel: Thanks Daniels for these links! :)
16:08daniels: np :)
16:09Vanfanel: In the first link, the one to look for is pancsf branch, right?
16:10cwabbott: gfxstrand: if we fixed that, we could probably also move the view_mask and a few of the pipeline flags to the top-level `vk_graphics_pipeline_state` and remove all the ugly "non-complete" renderpass state stuff
16:15daniels: Vanfanel: yep
19:08Vanfanel: <daniels> "Vanfanel: yep" <- Can you please point me to the right kernel to go with it? I guess it has to be some kind of midstream kernel...
21:45Guest2117: question about the d3d12 backend: what d3d "feature level" capability is required from the hardware for OpenGL 3.3?
21:48jenatali: No special requirements. 4.1 is available for all D3D GPUs, you only start to need optional stuff if you want 4.2 (and eventually beyond)
21:48kisak: Roughly, DirectX 10 era hardware and OpenGL 3 hardware are the same thing, but there can be edge cases, and the Windows drivers might have missing features from the driver vendor. (I don't know much about the Windows driver landscape.)
21:51jenatali: Specifically, typed UAV (storage image) load for a bunch of formats is needed for 4.2. for 4.3 you need the newly-added format casting but, but we haven't hooked that up to the Mesa driver yet
21:51kisak: jenatali: right, but I expect that there's a minimum compatible version from each hardware vendor, and that same vendor most likely isn't doing updates to GL3 era hardware.
21:51jenatali: (contributions welcome :P)
21:51kisak: (driver version)
21:52jenatali: kisak: D3D12's min-spec is so far beyond GL3. All D3D12 drivers are capable of supporting our mapping layer at 4.1
21:57jenatali: Guest2117: FYI in case you didn't see without being tagged
21:59Guest2117: jenatali: thanks. I'm just wondering if this thing will run on pre-D3D12 era hardware (that can do GL 4.2+)
21:59Guest2117: something like a GTX 680 or (more importantly) older intel iGPUs
22:00jenatali: It needs a D3D12 driver, which means at least feature level 11
22:00Guest2117: i see
22:00jenatali: For NV that's Fermi, for Intel it's Broadwell
22:03Guest2117: jenatali: is ivybridge (HD4000) not FL11? IIRC Mesa can do GL 4.something with it
22:04jenatali: Intel never shipped DX12 drivers before Haswell, and they recently disabled those drivers leaving Broadwell as the oldest supported gen
22:04Guest2117: :(
22:05Guest2117: i guess vulkan drivers for zink isn't even worth asking about
22:06jenatali: Someone could probably build a d3d11-based backend for 3.3 but the lack of swizzles on sampler views would be... Oof
22:06kisak: ^which aligns with what I was trying to say about minimum vendor driver version being the important detail.
22:07Guest2117: i was looking forward to replacing ANGLE for my windows builds. It's a nightmare to build (typical googleware)
22:07Guest2117: >lack of swizzles
22:07Guest2117: oh yeah
22:07Guest2117: they gutted those from WebGL for that reason LOL
22:08jenatali: I think that's the only real feature we use from 12 that's not in 11 in that backend
22:08Guest2117: what's funny is, i think ANGLE emulates them somehow anyway. probably not very optimally
22:09jenatali: Probably not. Probably shader recompilation
22:09Guest2117: works well enough for me
22:11jenatali: Guest2117: oh just saw your zink comment, yeah I think the same gens apply for Vulkab
22:11jenatali: Vulkan*