04:02 mareko: I think it may be worth getting rid of our NIR opt loops and replacing them with the minimum number of passes that make progress + NIR_PASS_ASSERT_NO_PROGRESS for all the opt passes we would run in a loop
10:59 Lynne: why are uploads and downloads so slow on nvk?
10:59 Lynne: they're the same speed as nvidia's binary drivers, but nvidia's binary drivers have some sort of hack which makes host image copies actually normal speed
11:00 Lynne: not even mapping host memory and using it directly gives good performance
11:35 MrCooper: Lynne: FWIW, with direct mapping of host memory, CPU reads are kind of expected to be slow, and CPU writes require write-combining to be fast
11:36 Lynne: in this particular case, I'm not reading from the CPU, I just have a shader which reads data from a host memory pointer and copies it/does nothing
11:39 Lynne: I max out at only about 1gb/s, while host image copy on nvidia's binary drivers and a single copy can do this easily 100x faster and more
12:10 pq: Which side is "host" and what's the other side called?
12:13 glehmann: pq: host=cpu, device=gpu
12:16 pq: thanks
12:20 pq: Lynne, maybe nvidia has a dedicated copy engine in hardware? They used to, but it's been many years since I last read anything about nvidia.
13:23 Lynne: pq: they have a transfer queue
13:23 Lynne: it's just as slow
13:24 Lynne: https://code.ffmpeg.org/FFmpeg/FFmpeg/src/commit/0742a932ce05d724a8a0178dfafeaff58f52715e/libavcodec/vulkan_dpx.c#L53 is the kind of stuff I have to do
14:00 umbramalison: Hi I thought I had moved on from the proprietary vivante gpu stack (gcnano) for an stm32mp157 to etnaviv and upstream mesa. But i've hit something with cog (wpewebkit) because it calls eglCreateWaylandBufferFromImageWL. IIUC, this is not implemented in the mesa EGL layer for etnaviv. Does anyone know a bit more about this? is there a solution for cog and etnaviv or is it back to the blob? thanks
14:03 K900: EGL_WL_create_wayland_buffer_from_image has been dropped in Mesa
14:03 K900: You probably need a newer webkitgtk version
14:06 umbramalison: K900 I was told it was reintroduced in 24.1.0 (ChatGPT) I'll verify that now. I'm using quite recent, 2.48.3 wpewebkit and latest wpebackend-fdo 1.16.1. Mesa 25.2.7
14:06 K900: I would not trust ChatGPT for ... anything, really
14:08 K900: But also looks like the extension is indeed there in current Mesa, but it also looks like it's not at all device specific
14:08 K900: So you need to figure out what is actually failing and why
14:09 umbramalison: interesting. thank you
14:11 daniels: it was removed and then un-removed; I think what you're missing is -Dlegacy-wayland=bind-wayland-display during the build, as the feature is deprecated in Mesa and will be gladly removed whenever the new WPE platform API ships
14:13 umbramalison: daniels... that looks like renewed hope to me. thank you
14:14 DragoonAethis: FYI: Intel kernel CI is having a bad time today, expect more downtime until tomorrow and/or a very long queue.
14:32 umbramalison: daniels - that fixed it. thank you
14:34 daniels: np
14:39 mahkoh: why does EGL_WL_create_wayland_buffer_from_image depend on bind_wl_display?
14:46 daniels: it's not a hard dependency, but it was easy enough to bundle both together as a separate config option, given that the original use of create_wayland_buffer_from_image is bind_wayland_display
14:47 daniels: if you want to change what the build option is called, feel free to take it up with the release managers and distro people and talk about the benefit of things being more intellectually pure outweighs the downside of making people change their build options
14:48 soreau: daniels: if they complain, just tell them you sed so :P
15:06 mahkoh: It neither a hard nor a soft dependency. If I just move all of the ifdefs to not include that API everything compiles even with bind_wl_display itself disabled.