03:20ishitatsuyuki: bb2045, did you check that the shaders pass Vulkan validation?
03:20ishitatsuyuki: (+spirv-val maybe)
03:20ishitatsuyuki: If it still fails NIR validation, please report an issue with the shader attached
03:21ishitatsuyuki: Ideally, a Fossilize pipeline so it can be replayed right away; see https://github.com/ValveSoftware/Fossilize and set export FOSSILIZE_DUMP_SYNC=1
04:02bb2045: ishitatsuyuki: The shaders pass spirv-val as long as --scalar-block-layout is specified (I'm using scalar block layouts).
04:03bb2045: There are three Vulkan validation errors- however, I think the only validation errors being reported may actually be bugs in Vulkan's validation layers.
04:03bb2045: VK_EXT_mesh_shader is a relatively new extension, after all.
04:04bb2045: In Vulkan SDK v1.3.231.1, the potential bugs can be found at: core_validation.cpp:2374, core_validation.cpp:2401, and core_validation.cpp:2406.
04:05bb2045: In short, Vulkan's validation checks for VK_NV_mesh_shader, VK_SHADER_STAGE_TASK_BIT_NV, and VK_SHADER_STAGE_MESH_BIT_NV...
04:05bb2045: ...and does not check for the VK_EXT_mesh_shader equivalents, resulting in the three validation errors.
04:06bb2045: I can confirm using gdb that Vulkan's validation treats the "mesh shading extension" as not enabled...
04:07bb2045: ...because although vk_ext_mesh_shader = kEnabledByCreateinfo, vk_nv_mesh_shader = kNotEnabled, and on core_validation.cpp:2374, only vk_nv_mesh_shader is checked for.
04:08bb2045: If someone might could kindly confirm that I'm not crazy, I would be happy to report an issue with the shader(s) attached (and hopefully a Fossilize pipeline as well as long as I can figure that out :) )
08:26MrCooper: nanonyme: Mesa's issues with LTO are fairly random, I wouldn't try too hard to make sense of it
08:26airlied: or be prepared to try really hard and file gcc bugs :-P
08:27HdkR: Or clang bugs :)
08:27MrCooper: actually I do think it's more likely to be Mesa issues, the ODR violations are a good lead
08:29airlied: MrCooper: in theory we have a directive to build with LTO for one of our supported OSes :-P
08:31MrCooper: I've been trying to help move things in the right direction to make that possible
08:48airlied: one of the coprs used to use LTO builds, but he did a lot of bumps along the way
09:53MrCooper: karolherbst: is there a good way to get meson 1.0.0 on F37?
10:02HdkR: `python3 -m pip install meson
10:03HdkR: git clone https://github.com/mesonbuild/meson.git is also good :)
10:09MrCooper: thanks, wouldn't really call those "good" though
10:27dottedmag: MrCooper: If you don't like these, you can get https://github.com/mesonbuild/meson/releases/download/1.0.0/meson-1.0.0.tar.gz, unpack and run :)
10:27dottedmag:hides
10:33HdkR: Roughly equivalent to a clone
10:47MrCooper: yeah, moving in the wrong direction :)
10:49emersion: at least it's not `curl http://mesonbuild.com/random-script | sudo sh`
10:54MrCooper: haha, indeed
12:09karolherbst: MrCooper: pip is probably the best
12:09MrCooper: I think I'll pass on building rusticl on that machine for now then
14:00hays: if you can do it as a pip then you can venv it which is kinda nice
14:00hays: i would not do that to system python if it can be avoided
14:02hays: python -m venv venv && source venv/bin/activate && pip install meson ?
14:03hays: ^maybe that needs to be python3 depending on system
14:04hays: and you might need some packages depending on system, like python3-venv or such
14:27orbea: rust-1.67.0 trying to bootstrap itself... https://termbin.com/9rnb (friendly reminder how others suffer because of the rust hype)
14:28orbea: (note its already resolved, but amazing failure for a release, how does this happen even?)
14:36karolherbst: orbea: what's the point of that comment tho?
14:37karolherbst: updated compiler breaking things? Hell, that never happened with C and gcc !!11!!1!!
14:38orbea: they broke backwards compatiblity to the point of a rust version not being able to bootstrap itself (same version) in a minor version update
14:39karolherbst: same stuff happens with gcc constantly
14:39orbea: never seen it happen, but say it does, I wouldn't like that either
14:39karolherbst: right
14:39karolherbst: bugs happen
14:40karolherbst: I mean.. I think most people are up for alternatives, but.. atm there doesn't exist none, so....
14:40karolherbst: *any
14:40ajax: i like how wanting to use a language that eliminates entire categories that one has been fighting for multiple decades counts as "hype"
14:41orbea: by hype I mean everyone adopting beta software that is clearly not ready
14:41karolherbst: well..
14:41karolherbst: android reduced their rate of CVEs by adopting Rust
14:41karolherbst: "just saying"
14:42karolherbst: C must be really terrible if it gets outperformed by beta software
14:42daniels: can we please not have this argument here again
14:42daniels: Hacker News and Phoronix forums already cover these kinds of things well enough
14:42karolherbst: right
14:43emersion: thanks
14:43ajax: fair enough, i'll adjust my /ignores
14:43orbea: rude...
14:44orbea: i'll drop it, but its entirely on-topic to talk about how adopting a software stack is consisently a source of pain for many people
14:45psykose: i don't think it's very on topic actually
14:45karolherbst: last comment: it's not, it's _your_ choice of bootstraping rust yourself. Most (~99%) just use whatever package they get or rustup
14:46karolherbst: don't assume your problems are that of anybody else
14:57DemiMarie: Would it be possible to have some sort of sound NIR validation and backend fuzzing?
14:58karolherbst: we do have nir validation, but no fuzzing
14:59karolherbst: in case you hit cases where a nir pass is generating invalid nir, but nir_validate doesn't spot it, please report this or fix nir_validate to catch those
15:07karolherbst: but not really sure how to implement backend fuzzing :/
15:08karolherbst: DemiMarie: ohh I have an idea.. could run shader-db through AFL
15:08karolherbst: I did this in the past to fix some glsl parser bugs
15:09karolherbst: (and to primarily find them)
16:24Company: MrCooper: I still have 2 questions from our recent GTK fencing adventures:
16:24Company: 1. is there a way to wwrite code that triggers issues with wrong use of GLsync - like wait()ing in the wrong palce etc?
16:25Company: 2. what's a usecase for WaitClientSync()?
17:28Ristovski: ... interesting: https://bpa.st/raw/QJZIM (Ryzen 5700G, data from `smu_cmn_get_metrics_table` dumped via bpftrace since not all fields get exposed)
17:30Ristovski: I really wonder what "ApuPower" _actually_ is because its value doesn't make sense to me
17:31MrCooper: Company: 1. not sure how it could be tested, since the GL implementation may hide the issue; 2. maybe for testing if the fence has signalled (with timeout 0)? Can't think of any other use case offhand
17:35emersion: Company: one way to test would be to implement the ext which disables implicit sync in Mesa
17:36Company: MrCooper: (2) is mostly relevant so I can be sure that whatever I do, a WaitSync() is enough and I don't need a client sync
17:36MrCooper: emersion: it's not related to implicit sync
17:37emersion: and then submit a job which takes a long time to draw, e.g. like the one in weston-simple-dmabuf-egl --mandelbrot
17:38MrCooper: Company: WaitSync is enough for synchronizing GPU execution, ClientWaitSync is for synchronously waiting with the CPU
17:42Company: yeah - recent questions were about shared data stuff - like glGetTexImage() or ReadPixels()
17:42Company: which is a corner case where each one could be necessary in theory, especially for semi-knowledgable people like me
17:45MrCooper: WaitSync should be enough for those as well, though doing ClientWaitSync first shouldn't hurt that much, since they are synchronous anyway (except when using PBO for the pack buffer with ReadPixels)
17:51MrCooper: emersion: if it was about implicit sync, the issue wouldn't have manifested itself with radeonsi, so we might still be blissfully ignorant of it :)
17:52emersion: sorry, i was missing context here
17:54DemiMarie: karolherbst: the reason I brought this up is that WebGL and WebGPU expose parts of Mesa to untrusted input from the Internet, so those parts had better be secure.
17:54agd5f: Ristovski, APU power and dGPU power are used for smartshift.
18:17Ristovski: agd5f: But what are the actual values? On APUs, `dGpuPower` is zero and `ApuPower` doesn't really correlate to anything
18:24Ristovski: agd5f: See my comment on https://gitlab.freedesktop.org/drm/amd/-/issues/2321, the SMU indeed is shared according to the data I got
18:26Ristovski: tl;dr: even though I found a way to get some new metrics you usually cant get access to via sensors, there indeed seems to be no way to get an isolated iGPU power usage on APUs
18:26Ristovski: you could _kinda_ base it on VDDCR_SOC but that includes other stuff as well
19:40X512: What is Tegra? Is it significantly diffenent from nVidia?
19:44HdkR: X512: Tegra is NVIDIA's ARM SoC brand. Tegra 4 and older used an older GPU that used to be part of nforce chipsets. Tegra K1 and above use a GPU based on their desktop counterparts
19:45X512: I see Tegra GPU code in libdrm. Is there an open source client driver code counterpart?
19:47HdkR: https://gitlab.freedesktop.org/mesa/mesa/-/tree/main/src/gallium/drivers/tegra
19:53jenatali: Looks like Lima runners are out to lunch?
20:01agd5f: Ristovski, see the driver. IIRC, it's just used to provide an idea how much of the power headroom is being used by the APU vs the dGPU
20:04daniels: jenatali: yeah you can have my Ab for a disable
20:04daniels: I noticed it earlier but decided that making lunch was far more important
20:04jenatali: daniels: Thanks, on it
20:06jenatali: !20995 going straight to Marge
20:07anholt: thanks!
20:07Ristovski: agd5f: It should be returning APU power in watts, except in that case the value should match CurrentSocketPower (on APUs) but it does not (though it does get close, to ~3W under/over). Unless there is some sort of timing difference in the SMU which causes the discrepancy.
20:08Ristovski: What I find very unfortunate is how none of the metrics are documented enough to the point where someone could draw concrete conclusions on what the values actually represent and how they are calculated in the first place
20:09jenatali: Wish there was a way to just use the passing result from the rest of the jobs to avoid having to re-run everything to merge a change after that disable goes through
20:47FLHerne: karolherbst: https://nouveau.freedesktop.org/FAQ.html#index20h3 <- I think this is outdated now?
20:47FLHerne: isn't nouveau used for 3D on more recent Tegras
20:55karolherbst: ohhh.. I think this was for the older tegras
20:55karolherbst: do you want to rephrase it or shall I?
21:05karolherbst: https://gitlab.freedesktop.org/nouveau/wiki/-/merge_requests/26
21:07karolherbst: uhh.. that markdown parsing failed... lemme...
21:08X512: How KMS connector is attached to CRTC with libdrm.so API?
21:09emersion: via an atomic commit
21:15X512: What object attributes of atomic commit?
21:18emersion: CRTC_ID on each connector
21:18emersion: object prop*
21:20X512: Encoders not needed?
21:21emersion: nope
21:21emersion: you can get started with https://git.sr.ht/~emersion/foss-north-kms
21:27FLHerne: karolherbst: I'm no expert, just noticed it after reading the discussion a few lines up
21:28FLHerne: so you'd better, because I don't know the correct info, just that that didn't look right
21:30FLHerne: MR text LGTM
21:39bb2045: ishitatsuyuki: Reported an issue with the shader attached as well as the fossilized pipeline, let me know if anything else is needed. https://gitlab.freedesktop.org/mesa/mesa/-/issues/8197
22:09hays: I compiled mesa3d-demos and I just got one binary. is there a broader set of demos available somewhere else, or do I need to troubleshoot my build?
22:10airlied: hays: the latter
22:10hays: running on embedded system with EGL/GLES
22:11hays: hrm.. ok
22:11airlied: need freeglut or something like that usually
22:14hays: hmm requires GL.. maybe there's just not that many EGL demos
22:19hays: not sure what EGLUT is
22:20HdkR: egl glut, it's in the demos repo itself
22:23airlied: ah yeah there is't a huge amount of egl/gles demos
22:24HdkR: es2gears and es2tri is all anyone needs
22:33hays: yeah i think i can use gears pretty effectively to figure out why this dumb vendor driver is segfaulting es2gears and why wlroots can't create a backend
22:38HdkR: "dumb vendor driver" is fairly indicative of the problem :)
22:55Lyude: MrCooper: I am, just going to let AMD handle that and have them ask me for help if they need it
22:57Lyude: I'm burnt out enough with 2171, and now that someone's written fixes from AMD my hope is just that they'll be able to figure out the rest of the remaining issues and contact me if there really are more problems
22:58Lyude: (i even remember the gitlab issue id off the top of my head, don't like that...)
23:10airlied: Lyude: hey skeggsb sent some fixes out to dri-devel, can you guide them in misc-fixes?
23:11Lyude: airlied: sure thing, what's the topic of the email?
23:11airlied: Lyude: https://lore.kernel.org/dri-devel/20230130223715.1831509-1-bskeggs@redhat.com/T/#t