01:56 oneforall2: so any idea whats causing this? https://0x0.st/Xgno.0.log is it mesa ?
04:22 Lynne: airlied: nice
04:39 Lynne: zmike: I get a segfault in load_buffer_descriptor on line 159 running glxgears over zink here
04:44 Lynne: and ACO errors+crash after disabling descriptor buffers while running firefox
04:46 Lynne: disabling both shader object and descriptor buffers does make it run, yay!
04:53 Lynne: with terrible sync issues, and if I look at it the wrong way or dare to pry my eyes away it crashes
04:55 Lynne: vaapi over vulkan does run pretty flawlessly in mpv at least, though I can't get firefox to start using vaapi even after modifying about:config when it does run at all
05:39 llyyr: the vaapi over vulkan PR segfaults in vlVaQueryImageFormats for me
05:39 llyyr: with mpv*
05:56 airlied: llyyr: on what vulkan driver?
05:56 llyyr: radv
05:57 llyyr: I'll link the backtrace one sec
05:57 llyyr: airlied: https://0x0.st/XEHh.txt
05:58 airlied: llyyr: you have video available in vulkaninfo?
05:59 llyyr: yes
06:00 airlied: wierd seems to be missing zink_is_video_format_supported which doesn't make much sense since it's always set
06:12 llyyr: I rebuilt mesa after doing a --wipe and it doesn't segfault anymore
06:13 llyyr: It still doesn't work though because >[vo/gpu/vaapi/vaapi] libva: Trying to open /opt/mesa/lib64/dri/radeonsi_drv_video.so
06:13 llyyr: even though I set LIBVA_DRVIER_NAME=zink RADV_PERFTEST=video_decode MESA_LOADER_DRIVER_OVERRIDE=zink
06:14 airlied: you misspelt DRIVER
06:14 llyyr: erm
06:14 airlied: assuming you didn't just misspell it here :-)
06:16 llyyr: uses zink now but still fails https://0x0.st/XEXz.txt
06:17 llyyr: I guess we just don't support nv12 yet?
06:18 Lynne: works here though, weird
06:18 airlied: does vainfo -a show anything?
06:19 airlied: I think a radv error code changed at some point
06:19 airlied: and I'm not covering both
06:20 airlied: nope seems to cover the old and new ones
06:20 Lynne: *doesn't seem to work now, or maybe it never did
06:21 llyyr: LIBVA_DRIVER_NAME=zink MESA_LOADER_DRIVER_OVERRIDE=zink doesn't work, it claims to support no surface formats while just LIBVA_DRIVER_NAME=zink does work and offers all the usual surface formats
06:22 airlied: the problem with driver override is it overides your GL as well
06:24 llyyr: hmm I thought vaapi over zink was supposed to work together with the zink gl driver, if it's not then that makes sense I guess
06:24 airlied: it should work, just one more thing to take notice off :-)
06:25 airlied:goes to check a late fix didn't break it
06:25 llyyr: also "LIBVA_DRIVER_NAME=zink vainfo" claims to support hevc, vp9 and av1 as well so I'm not sure its right
06:26 llyyr: the vainfo output looks suspiciously similar to what I get with radeonsi, even though it's definitely probing zink "libva info: Trying to open /opt/mesa/lib64/dri/zink_drv_video.so"
06:27 airlied: yeah that is picking up radeonsi
06:29 airlied: there was a ret ignored fix I shoved in I think broke it
06:35 airlied:will track it down
06:55 airlied: okay it seems quite broken, and zmike changes from last couple of days look to not have been tested
07:00 airlied: zmike: all the clear stuff is broken on radv, and some of the other changes
07:10 airlied:hides blogpost until I have some more time :-)
07:28 MrCooper: Mis012[m]: it also needs the CPU for presentation
07:38 Company: do you guys have some kind of file format for dmabufs in any of your testsuites?
07:39 Company: I want to be able to test certain combinations of values passed to eglCreateImage() and vkCreateImage(), but I'm not sure how to best store that
10:01 emersion: i just store raw bytes
10:02 emersion: and metadata in the filename
10:12 Company: i wondered about that, but there's a bit much metadata for multiplane dmabufs
10:13 Company: the closest thing I came up with would be a HTTP dump - headers for the metadata and then followed by the data
10:14 Company: but all of this need me to write tools to en/decode them
10:15 Company: that's why I was hoping for an existing solution
13:35 DemiMarie: Company: Some way to fuzz multiplane dmabufs would be awesome.
13:36 DemiMarie: That part of Mesa is a security boundary, so any incorrect acceptance of a dmabuf is a security vulnerability.
14:10 Company: DemiMarie: I'd be more worried about security of non-linear modifiers, but yes, multiplane dmabufs is also a special interest of mine
14:11 Company: though I care about it because the EGL API doesn't allow any colorspace, so getting that part right is important
14:14 DemiMarie: Company: What are your security concerns with nonlinear modifiers?
14:15 DemiMarie: I'd considered forcing linear modifiers, but was told there would be a 4x performance hit to both producer and consumer.
14:26 Company: DemiMarie: it's internal to the drivers, so producer == consumer, and nobody is gonna check those things for security concerns
14:27 DemiMarie: Company: is there an efficient way to do a copy to linear and back?
14:36 Company: no
14:40 DemiMarie: I thought there was some trick with compute shaders
14:40 MrCooper: if gbm_bo_map isn't as efficient as possible, it's a Mesa driver issue
14:43 DemiMarie: MrCooper: That function has to copy to CPU-accessible memory. I want to stay on the GPU.
14:43 MrCooper: I don't get the point of that, given the GPU performance hit with linear
14:46 DemiMarie: MrCooper: reducing PCIe bus roundtrips
14:47 MrCooper: I mean I don't get why you want linear buffers on the GPU
15:02 DemiMarie: MrCooper: because I can validate their parameters when a security boundary is crossed.
15:27 DemiMarie: The other option is to do an image to image blit and hope that the impact of a problem is limited to a proxy crash or out of bounds read in a process that doesn't have any secrets worth extracting.
15:58 Company: DemiMarie: you can always do a copy into a regular buffer and copy back into an image later
15:58 Company: but it's all gonna be copies
16:12 MrCooper: which would read the same out-of-bounds contents anyway, wouldn't they?
16:13 Company: you can send the buffer to the host
16:17 MrCooper: not sure what you mean; my point is that if the tiled buffer is too small, the copy to a linear buffer may read contents outside of the tiled buffer and store them in the linear buffer, so they're still leaked
16:18 MrCooper: so it's not clear what's gained from the copy / linear buffer
16:18 Company: I was assuming that that operation happens in the client, so the client can't leak anything - of course that assumes that the gpu does proper process isolation
16:20 MrCooper: the premise is that something receives a tiled buffer which is too small for all reads within the claimed dimensions to land inside the buffer
16:21 MrCooper: or maybe the idea is to only accept linear there, in which case sorry for the noise
16:22 Company: my question is who guarantees that accesses to such a buffer are secure
16:23 Company: and it's easier to avoid issues if the buffer is simple and the format is common
17:21 ngcortes: NB: intel mesa CI will be down until tuesday afternoon (10/8/2024) for a poweroff at Jones Farm. We will notify everyone once it's back online.
17:50 DavidHeidelberg: karolherbst: could we discuss the texture size bump to 4096 or what is it now to 65535x65535 to match proprietary drivers on XDC, what do you think?
17:51 karolherbst: probably
17:52 karolherbst: I think it's 32k atm though
17:52 karolherbst: though there isn't really much to discuss, it just requires changing gallium interfaces, because a lot of things are signed 16 bit values
17:52 karolherbst: and that needs to be fixed before
17:52 karolherbst: the same problem exists for buffers bigger than 2GiB
17:54 karolherbst: like everything taking a pipe_box
17:54 karolherbst: like vaxryy
17:54 karolherbst: ...
17:54 karolherbst: copy&paste fail 🙃
17:55 karolherbst: resource_copy_region
17:57 karolherbst: DavidHeidelberg: alternativly everything could be emulated with shaders...
18:01 benjaminl: I'm a bit confused about the nir_lower_multiview pass. It's currently disabled if the shader contains memory writes, but doesn't care about control barriers. I'm not sure why memory writes are a problem, but it seems like it could deadlock with barriers?
18:23 DavidHeidelberg: karolherbst: but marek already bumped the pipebox ints :)
18:23 DemiMarie: Company MrCooper: my thought is that doing the copy in a proxy will ensure that bad buffers either crash the proxy or leak data from the proxy, but can't leak data from other guests. The proxy doesn't have any sensitive information of its own that can be leaked.
18:24 karolherbst: DavidHeidelberg: also for depth?
18:24 karolherbst: though...
18:24 karolherbst: mhh
18:24 karolherbst: that might not matter actually...
18:24 karolherbst: mhhhh
18:24 DavidHeidelberg: Yup
18:24 karolherbst: yeah 32 bit numbers should be fine...
18:24 DavidHeidelberg: I was thinking we just agree on how and push it when we're there
18:25 karolherbst: I don't think there is anything preventing that then, except dealing with sampled/mipmapped stuff potentially?
18:25 karolherbst: the higher sizes are for plain images, or can they be mipmapped?
18:25 karolherbst: sampled one don't matter, because CL can't create them no matter what, only import them
19:19 alyssa: 16k is hw limit on agx
19:25 dj-death: was angle updated on CI in the last week?
19:56 zmike: glcts update
20:01 dj-death: hmm okay
20:01 dj-death: a bunch of 3d tests started fail on the EXT_host_image_copy MR
20:01 dj-death: but only on angle