00:04hakzsam: cmarcelo: hi, yes, I can check this on monday for sure
02:00tuxayo: Hi :)
02:01tuxayo: I'm testing upcoming Vulkan support for the 0ad libre game. My GPUs are an HD 4000 (gen7 ivy bridge) and an AMD 7950 (GCN 1.0) so basically the firsts Intel and AMD GPUs with Vulkan support (but incomplete/unofficial!). Right at the frontier in the middle of the minefield, so I should get a lot of trouble :D 💥 Then the devs will see how to handle these dodgy GPUs ^^"
02:01tuxayo: Anyway, with my HD 4000 I got on launch that I don't have support for VK_KHR_surface, but mesa matrix doesn't mention anything about partial support (like gen8+, hsw, etc) so where can I find for sure whether the HD 4000 should support or not VK_KHR_surface?
02:04kisak: with mesa 22.3 Ivybridge vulkan support split away from ANV into hasvk. That's where to look for Vulkan on that generation going forward.
02:10kisak: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/intel/vulkan_hasvk/anv_device.c#L161 seems unconditionally enabled. You sure hasvk is being used and can render to the display?
02:15tuxayo: Thanks kisak , I was trying to find where the split put the files.
02:15tuxayo: > You sure hasvk is being used and can render to the display?
02:15tuxayo: I can run vkcube and veloren (unplayable FPS of course) so I can definitely get vk stuff on my display.
02:15tuxayo: I have Mesa 22.3.3 so it could only be hasvk that is used I guess? (only one GPU on the system)
02:26mareko: or lavapipe
02:27tuxayo: I found about vulkaninfo! (I tried vkinfo but not vulkaninfo). So :
02:27tuxayo: Instance Extensions: count = 20
02:27tuxayo: [...]
02:27tuxayo: VK_KHR_surface : extension revision 25
02:27tuxayo: That might it's supported right?
02:27mareko: yes
02:27tuxayo: > or lavapipe
02:27tuxayo: oh right, maybe I have it by default somehow
02:34tuxayo:tries to find how to which driver is used when running something
02:34tuxayo: *how to know
02:34tuxayo: That's still relevant to be sure hasvk is used, right?
02:36tuxayo: I'm running the AppImage build of the dev branch of the game. So it might mess up which driver/lib are used compared to directly running the game.
02:49tuxayo: I found out about Vulkan Hardware Capability Viewer, ran the locally compiled version and the AppImage version and both don't list it.
02:49tuxayo: It might not be reliable. https://vulkan.gpuinfo.org/listextensions.php show only 0.16% of devices in the DB support it. Which seems wrong.
02:54tuxayo: Will keep digging, thanks for the help all :)
04:03cmarcelo: hakzsam: thanks!
04:26hays: can someone here help me out to explain exactly the relationship between libEGL.so and libwayland-egl.so? it seems that GPU vendors are on the hool to provide libwayland-egl.so (maybe?) but wayland also generates this .so as part of the compilation process
04:26hays: s/hool/hook
04:27hays: I feel like im missing a concept in terms of the graphics stack
10:25hays: It does appear the wayland-egl is essential for proper functioning of wayland.. I thought perhaps there might be a way to run without it
10:25hays: (based on this https://upload.wikimedia.org/wikipedia/commons/thumb/2/2d/The_Linux_Graphics_Stack_and_glamor.svg/2880px-The_Linux_Graphics_Stack_and_glamor.svg.png)
10:27hays: but then this graphic, which maybe is meant as a more detailed view--shows the wayland-egl.so https://upload.wikimedia.org/wikipedia/commons/a/a7/Wayland_display_server_protocol.svg
10:34X512: libwayland-egl.so provides an API for using EGL with Wayland. It contains installable interfaces actually implemented in EGL drivers such as Mesa.
10:35X512: libwayland-egl.so is one of reasons why Wayland application using EGL can't be fully implemented in Rust.
10:53dottedmag: hays: Out of curiousity, what are symbols exported by wayland-egl.so.1 from Mali?
10:54hays: dottedmag: I am not sure exactly how to determine that
10:54dottedmag: hays: readelf -sW
10:56hays: one sec-- in over my head a bit and don't want to ask uninteresting questions if possible
10:59hays: dottedmag: so.. I barely understand the readelf output. but I think the answer is that Mali doesn't name wayland-egl.so for any symbol table entry
10:59hays: there's stuff like this -- 10: 0000000000000000 0 FUNC GLOBAL DEFAULT UND dup@GLIBC_2.17 (2)
11:00dottedmag: hays: pls upload the output somewhere, say, to paste.debian.net
11:00hays: and stuff like this 28: 0000000000000000 0 FUNC GLOBAL DEFAULT UND wl_resource_set_implementation
11:00hays: ok
11:00hays: https://termbin.com/ettt
11:02hays: maybe interesting is grep wl_egl?
11:02dottedmag: Thanks. So this is a real library with a lot of code inside, not a wrapper like Mesa's one.
11:02hays: this is libmali.so
11:02hays: so yeah it supposedly does it all
11:03dottedmag: Aha. And what's in their libwayland-egl.so?
11:03hays: there are six functions in that readelf with name wl_egl*
11:03hays: so my guess its is those 6 functions
11:04hays: wl_egl_window_{release,retain,destroy,get_attached_size,create,resize}
11:05hays: so the intent I believe is to symlink libwayland-egl.so to this library
11:07hays: and maybe that works.. im in the process of grasping at straws trying to figure out why launching sway causes seatd to hang in kernel space --possibly waiting for IO from /dev/dri/card0
11:11kennylevinsen: last thing you shared was sway segfaulting
11:13kennylevinsen: hays: seatd sits idle in a poll most of the time, so waiting in the kernel is normal
11:13hays: yes but not responding to kill -9 is abnormal
11:14hays: which happens after sway talks to it the first time
11:15hays: so something happens--i don't know what--when sway tries to get a resource from seatd that causes sway to segfault and seatd to go into state "D"
11:16kennylevinsen: that is true and suggests kernel issues, but unless sway is waiting for seatd then those might not be related
11:16hays: which forgive me if you know this already--is: "State "D" indicates Uninterruptible sleep generally related to IO."
11:17hays: sway seems to segfault immediately and only hangs the second, third, fourth time it tries to talk to seatd, which I assume is not saying anything back
11:17hays: first time: segfault.. after that it sits there and segfaults after a Ctrl-C
11:17hays: precisely what "driver" in kernel space does a proprietary driver like mali need?
11:18kennylevinsen: debug the first segfault. If your driver is borked, maybe seatd hangs on the drm ioctls later?
11:18hays: do i need to recompile seatd with debug symbols
11:19hays: and run it with gdb?
11:20kennylevinsen: To see where it hangs, sure - but I think you should debug the sway segfault first as that is a clear crash
11:22hays: yeah ive tried but there is no backtrace
11:23hays: gdb --args sway, run, bt shows nothing
11:24kennylevinsen: then single-step to the crash. You can break at libseat_open_device and step from there.
11:43MrCooper: nanonyme: some issues with glthread are bugs in Mesa, some are bugs in the GL API user; each case needs separate investigation
11:52X512: In theory wayland-egl.so is generic hardware-independent library.
12:37daniels: yes, in older versions each EGL library provided its own implementation, but now libwayland has its own. the two are compatible so you just need to replace the Wayland one with the Mali one … or use Panfrost
12:51X512: 2023 year now and vendor lib[E]GL.so still exists...
12:52X512: Use of glvnd should be enforced in distros I think.
12:52HdkR: If you're using the vendored Mali blob then libGL doesn't exist ;)
12:53X512: Mali blob don't use glvnd?
12:55HdkR: Well they don't support GL, so no reason to provide libGL
12:56HdkR: I've never actually thought about how glvnd works in that situation
12:58X512: glvnd have 2 parts with their own set of drivers: for GLX and for EGL.
13:57hays: daniels: Panfrost not available yet
13:58hays: they are working on it though--im stuck with rockchip-mali until that work completes
13:59hays: ok yeah disabling wayland EGL--as the rockchip buildroot does--doesn't work because it looks like wayland creates some header files that are needed
13:59hays: so my previous delete strategy seems right
14:01hays: still left with mystery of seatd--I'll get into gdb when I can to see what I can see
14:18daniels: hays: ah right, gen10
14:20hays: this blob makefile is comically complicated
14:22hays: anyhoo thanks for the discussion on architecture it helped clarify some things
14:28daniels: np
14:30doomjoshuaboy: hi guys i am having a problem compiling mesa with zink on a mac os arm64 and the xcb/xcb.h, i already installed the hombrew stuff on it but still doesnt help. can anyone please tell me what to do also i am a developer of zandronum and opengl screwed zandronum up because of some opengl deprecated so i thought mesa could help with it
15:07nanonyme: airlied, FWIW, we found out disabling LTO fixed dthe problem. So this https://gitlab.freedesktop.org/mesa/mesa/-/issues/7806 is probably quite wide-spread issue
15:08nanonyme: Seems to affect quite large amounts of AMD hardware
15:09nanonyme: MrCooper, glthread was red herring. We tried disabling it, it had no impact. There is a separate glthread bug, yes.
15:09kisak: nanonyme: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6911 is probably the issue report you want to keep an eye on
15:18hays: For those curious it seems like mali blob is at least supposed to work with wayland's version of wayland-egl.so: https://patchwork.ozlabs.org/project/buildroot/patch/20220924210221.1490924-1-thomas.petazzoni@bootlin.com/
15:18nanonyme: Okay, well, sounds like we will disable LTO for Mesa for now, it should allow doing further updates and hardware enablements
15:25MrCooper: yes, LTO is known unsafe for Mesa ATM
15:30nanonyme: MrCooper, there wouldn't by any chance be information if these LTO issues are all with GCC12? There are other libraries as well (dav1d) which are suffering of incorrect code generated by GCC 12 LTO (to the extent of crashes)
15:33X512: MrCooper: Why? Mesa use come undefined behavior code?
15:36jenatali: Since at least in some cases it's caused by adding more drivers to the build, it sounds like I correct folding of different static functions with the same name
15:36jenatali: Incorrect*
15:37MrCooper: nanonyme X512: the reasons are unclear, the best lead so far is the thread starting at https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20375#note_1732688
15:41ishitatsuyuki: which drivers are concerned with the LTO issue?
15:41X512: Some question about EGL: should context be selected when eglSwapBuffers is called?
15:46nanonyme: Yeah. But thanks for confirmation. We will proceed with release maybe next week with LTO disabled. Apparently there's quite a few RDNA 3 users already that need their hardware supported :)
15:46nanonyme: (that is, it was good to find out it was related to LTO, not LLVM 15 bump)
15:56MrCooper: X512: yes, eglSwapBuffers requires a current context (and the swapped surface to be bound to that context), in contrast to glXSwapBuffers
17:28nanonyme: Does AMD RDNA 3 use radeonsi or Zink?
17:31X512: RADV -> Zink path work for at least Radeon SI+ GPUs.
17:31X512: Don't know about Gallium radeonsi driver.
17:32kisak: mesa/radeonsi 22.2+ supports RDNA3
17:39nanonyme: Okay, that doesn't explain then why the corruption only seemed to be happening for users of older chipsets
17:41kisak: if you're just now moving to llvm 15, then the RDNA3 users could have been on llvmpipe
17:41kisak: ^ with llvm 14.0
17:48nanonyme: kisak, well, they reported the didn't have properly functioning GL until LLVM 15 update. And they didn't see the corruption.
17:48nanonyme: Sample size is not large
17:49nanonyme: It of course could be mere coincidence if some codepath used by RDNA 3 in radeonsi was less broken than for older ones...
17:50kisak: the intent of my last comment was just to highlight that mesa 22.2+ needed to be built against llvm 15 for the RDNA3 support to get turned on.
17:51nanonyme: Sure. We had LLVM 14 + Mesa 22.3.2 (which worked with LTO) and then updated to LLVM 15 + Mesa 22.3.3 (which broke for everyone else but these RDNA 3 users with LTO)
17:53nanonyme: Separately rebuilding everything with LLVM 14 was not enough to get rid of corruption with LTO.
17:53nanonyme: (that is, Mesa with LTO)
18:41Ristovski: Hmm, why do amdgpu HW block IPs have multiple "segments"? What does that even mean, I can't find any docs
18:42X512: Do you mean instance ID? It seems not used yet.
18:43Ristovski: X512: I'm talking about this: https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/amd/include/renoir_ip_offset.h#L198 (note line)
18:43Ristovski: I am not sure which base to use for reading registers (via `debug/dri/0/amdgpu_regs`)
18:45Ristovski: The instance ID is used for certain IPs, for example `ip_discovery/die/0/CLKA/` has `0, 1, 2`
18:46Ristovski: but then each instance itself has multiple base addresses (in the case of CLKA, two "segments" for each instance)