10:05stsquad: could a kernel change have broken this: vkr: vkAllocateMemory resulted in CS error
10:10digetx: stsquad: very unlikely
10:11stsquad: digetx: how can I trace where the failure is coming from?
10:17digetx: set env VIRGL_LOG_LEVEL=info on host, run guest app with strace to see which ioctl fails
10:23stsquad: digetx: in the guest I just see a bunch of DRM_IOCTL_VIRTGPU_EXECBUFFERs and then GEM_CLOSE
10:24stsquad: http://paste.debian.net/1337418
10:24stsquad: digetx: ^ thats on the host side
10:24stsquad: vulkaninfo --summary shows to VirtIO-GPU Venus - one Intel one LLVM
10:25stsquad: but vkmark can't find a suitable Vulkan device - I'm confused about the VK_KHR_wayland_surface extension though, that doesn't appear in the list in virglrenderer
10:30digetx: you should have same vk extensions as on x86 guest
10:52stsquad: digetx the host vulkaninfo certainly doesn't match the guest one
10:53stsquad:checks his x86 guest
10:55stsquad: huh
10:55stsquad: ok vkmark is running ok on the x86 guest
11:07digetx: host shouldn't match
11:21ManMower: mripard: I'm having some trouble with HDMI. my test machine can set an hdr metadata (drm) infoframe, but then it is forever stuck in HDR display mode. I can't find the path that should clear the infoframe. I've tried adding infoframe->set = false; at the top of hdmi_generate_hdr_infoframe() and that makes things happen, but I'm wondering if a) is that the right thing to do, and b) would any of the
11:21ManMower: other infoframes need the same thing?
11:31stsquad: digetx: hmm I'm wondering if the trixie virlgrenderer build is just missing venus?
11:33digetx: trixie shouldn't have venus, afaict; maybe sid has it
12:20stsquad: digetx I got mjt to update it a week or so ago. But maybe it was just the version bump
12:21stsquad: https://tracker.debian.org/pkg/virglrenderer
12:24stsquad: should be built
12:24stsquad: ifneq (armel, ${DEB_HOST_ARCH})
12:24stsquad: # vulkan requires 32bit atomic ints, armel lacks one (#1021861)
12:24stsquad: configure-opts += \
12:24stsquad: -Drender-server=true \
12:24stsquad: -Drender-server-worker=process \
12:24stsquad: -Dvenus=true
12:24stsquad: endif
14:27alyssa: mareko: u_blitter seems to be leaking framebuffers on context destroy. Is this a known bug / affecting all drivers?
14:34stsquad: digetx: it looks like in some cases it just silently fails to exec virglrenderer
14:34stsquad: proxy: proxy server with pid 1383963proxy: failed to exec /usr/libexec/virgl_render_server: No such file or directory--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_KILLED, si_pid=1383963, si_uid=1000, si_status=SIGSEGV, si_utime=0, si_stime=0}
14:44alyssa: apparently not all drivers affected, that's good I guess
14:58digetx: stsquad: do you have that server file?
15:01digetx: my local virglrenderer is built with -Drender-server-worker=thread, not sure I ever checked the process mode with QEMU
15:03digetx: it indeed works with x86 guest, never tried arm
15:03digetx: in general, it should work on arm with no issues
15:05digetx: mean haven't tried arm with process, with thread it worked
15:06digetx: everything should be the same as few weeks ago when you tested venus with amd card and intel igpu
15:06stsquad: digetx: the above was fixed by installing virgl-server - still fails to start vkmark though
15:07stsquad: digetx: now I'm testing against the packages in trixie
15:07stsquad: digetx: and with the current HEAD of the kernel with kvm/next merged
15:07eric_engestrom: mareko: I'm afraid I can't help you with the traces job because 1) I'm barely familiar with the traces tests, 2) that one is running on crosvm, which adds two layers of complexity I'm not familiar with, and 3) I don't have any time left this year, I'm about to be offline in a couple of hours until january :]
15:07stsquad: so trying to work out what has broken
15:07digetx: should work as before
15:08eric_engestrom: mareko: my advice would be to ask daniels who'll probably either know the answer or know who to ask
15:11stsquad: digetx: should being the operative word... the problem is when things break its not immediately obvious where the breakage may be. things seem fragile
15:13digetx: that is a common theme with graphics virtualization :) it will improve over time as more stuff is upstreamed and stabilized
15:15digetx: is it still failing with vkAllocateMemory?
15:19digetx: I'll try to reproduce if you won't fix it
16:49llyyr: does anyone have any ideas for https://gitlab.freedesktop.org/mesa/mesa/-/issues/12198 ? it currently breaks users of VK_KHR_display on any system with llvmpipe present
16:50llyyr: in the past GetPhysicalDeviceSurfaceSupportKHR would just say llvmpipe doesn't support the surface and the client would move on, but now it segfaults
16:51stsquad: digetx: certainly with my arm test image on trixie with -device virtio-gpu-gl-pci,hostmem=4G,blob=on,venus=on vkmark doesn't see any valid devices, even though vulkaninfo does while complaining about VK_KHR_wayland_surface failing
16:52stsquad: digetx: what are you running on your host?
16:52stsquad:is running his trixie through toolbox, but host vkmark works fine so the dri node is visible
17:21digetx: my hosts are fedora, gentoo and archlinux
17:22digetx: if you running vkmark with wayland and wayland doesn't work properly, it well explain why there no device found
17:23digetx: you have checked both wl and x11, have you?
20:13banderasamigo: I specifically learned as to how to explain better. But still i am continuing to do more tests, I do have new specification to execution side or era.
20:14banderasamigo: but i won't be explaining this anymore, since i use the time to write code instead.
22:24cwabbott: for vulkan RT, is it supposed to happen that when a closest hit shader traces a ray, all of the information about the original intersection (ray origin & direction, hit kind, etc. etc.) is clobbered and overwritten with the new intersection?
22:24cwabbott: that seems to be what intel is doing, but I'm not sure what the justification is
22:24cwabbott: or if I'm missing some pass somewhere that pulls all these intrinsics to to the top
22:54dj-death: cwabbott: it's not overwritten on intel
22:55dj-death: cwabbott: there is 2 different structure, one for the setup, the other for the hit info
22:58dj-death: cwabbott: any idea when you'll be able to merge the common framework stuff?
23:04mareko: eric_engestrom: understood
23:04mareko: I wonder if daniels is on vacation :)
23:24daniels: mareko: not on holiday but a bit underwater - I had a quick look and I think I know how to fix it but it’ll take a couple of days before I can get to it - if it’s in your way please just kill those traces for now and assign an issue to me to fix