10:55airlied: dcbaker: is there a 20.3.x release coming? will https://gitlab.freedesktop.org/mesa/mesa/-/issues/2678 be in it?
11:00austriancoder: pendingchaos: do you have an example for a direct load that cause out-of-bounds access?
11:02pendingchaos: I don't know of any application with a direct load that causes out-of-bounds access
11:09austriancoder: pendingchaos: regarding the flag idea.. should the new flag supersede indirect_load_ok?
11:35daniels: vsyrjala: ^ Bichon above is yet another GitLab CLI
15:21Sumera[m]: melissawen, danvet: I tried adding virtual_hw mode as a module: https://github.com/Sylfrena/linux/commit/9e8ad6ec1a8cdd32d0c08fcf85d17ebf78480633
15:21Sumera[m]: and here's the patch: https://paste.ubuntu.com/p/9g6rvzzjSk/
15:22Sumera[m]: so, virtual_hw passes all tests(expect cursor-size-change) but it's not working for the normal, with vblank mode
15:23Sumera[m]: and I am not sure where I am going wrong :/
15:23dcbaker: airlied: yes, i need to get both a 20.x and 21.x release out. Probably won't happen today as it's super icy here and I'll be home with the little guys
15:25danvet: Sumera[m], patch looks good
15:25danvet: I think there's a small issue in the vkms_create function
15:25danvet: I think you now no longer set irq_enabled = true when not in virtual_hw mode
15:25danvet: and that probably breaks that normal mode?
15:26Sumera[m]: danvet: ah,yes! I entirely assumed it would do that by itself <facepalm>
15:26Sumera[m]: thanks, I will correct that
15:26danvet: I think otherwise looks good
15:27danvet: so fix that one, retest normal mode to make sure it's not broken
15:27danvet: split out all the debug patch (maybe in a local patch, or drop it)
15:27danvet: and then submit with changelog and everything?
15:27bnieuwenhuizen: if I want to create a test for an AMDGPU specific ioctl what is the best place to put it? IGT or libdrm (_amdgpu) or something else entirely ?
15:27danvet: maybe triple check that the patch you're submitting really still works, to make sure you didn't drop any important piece accidentally
15:27danvet:been there way too many times
15:28Sumera[m]: danvet: also, another thing- everytime I use virtual_hw mode, and try to remove the module, my system freezes
15:28danvet: bnieuwenhuizen, there's a bikeshed, amd has a lot of them in libdrm, imo stuff it into igt
15:28danvet: I don't think either is really tested in any kind of CI, definitely nothing public
15:28Sumera[m]: danvet, yep will test it all again plus clean up the random printks and comments
15:28bnieuwenhuizen: well, half the point is so that I don't have to point them at a non-supported Vulkan driver :)
15:29bnieuwenhuizen: CI is bonus
15:29Sumera[m]: what's a good way to link an image here?
15:29danvet: just link, irc doesn't really do images
15:30Sumera[m]: oh, actually since it was text mode and it froze- I could only take a photo ;-;
15:31danvet: Sumera[m], oh missed your comment that it freezes on unload
15:31danvet: Sumera[m], so after rebooting nothing has made it into logfiles?
15:32danvet: also can you try to log in with ssh or virtual console maybe?
15:32danvet: probably something going boom on unload which just crashes your kernel
15:33danvet: so we'd need to get the last few dmesg lines out somehow
15:34danvet: Sumera[m], oh just noticed, the drm_vblank_init() like we also need to put behind a conditional I think?
15:34danvet: in vkms_create()
15:35danvet: but not sure whether that could result in fireworks on unload or not
15:35danvet: woth a try
15:42Sumera[m]: danvet: so this is what is happening https://pasteboard.co/JOuejVU.jpg
15:45danvet: hm yeah there's a bug there
15:45danvet: Sumera[m], so something is still enabling our hrtimer
15:45Sumera[m]: hm maybe it is related to the drm_vblank_init part
15:45danvet: which then blows up, because the vblank stuff isn't really set up somehow
15:46danvet: I think ...
15:46danvet: so I think we need to search the vkms code for some hrtimer enable somewhere
15:46Sumera[m]: but why would it do that while removing the module?
15:46danvet: or maybe it's just the drm_vblank_init
15:46danvet: no idea
15:46Sumera[m]: alright, I will try some sleuthing and get back to you
15:47danvet: it could be that atomic helpers get confused and think vblank is supported
15:47danvet: but inconsistently
15:47danvet: and so only in some specific cases they try to enable it
16:02Sumera[m]: danvet: it is coming from vkms_enable_vblank in vkms_crtc.c I think
16:03danvet: but you if that out for virtual mode
16:03danvet: Sumera[m], drm_atomic_helper.c also does some automatic vblank handling
16:03Sumera[m]: which is called in the atomic hook...somewhere
16:03danvet: and that might get confused with the drm_vblank_init still in there
16:04Sumera[m]: yeah, that's probably the case
16:13alyssa: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4304 I read this as Dark Age of Canterlot
16:33zmike:tries GALLIUM_TRACE for the first time
16:47MrCooper: the trace layer tends to rot, probably will until it's tested in CI
17:18dcbaker: Mershl: tomorrow or Wednesday at the latest
17:20sailus: Would someone be perhaps interested in reviewing this: https://lore.kernel.org/linux-media/YCqoQMQPWVOzEN%2F%2F@alley/T/#m12866ab5a0f731a3d9ec4c1981c93ad2e876cb4f
17:20sailus: It'd be nice to merge it through the printk tree.
17:21sailus: danvet: ^
17:24danvet: sailus, I think this needs at least a topic branch to avoid the worst pain with conflicts
17:24danvet: maybe just for the drm patches
17:24danvet: otherwise thx a lot for doing this, unfortunately I'm burried
17:24danvet: but I think tzimmermann is looking for reviewers for stuff too
17:25danvet: tzimmermann could also do the topic branch wrestling if someone needs to do this from our side
17:29sailus: I think this could also go through the DRM tree once the first patch makes it there through the printk tree. It's not urgent.
17:29sailus: And you're welcome. :-)
17:44danvet: sailus, well since it's missing 5.12 topic branch sounds better to me tbh
17:44danvet: otherwise we have to wait another full cycle
17:44danvet: could also do topic branch just for the one prep patch, and then pull that into each subsystem (printk, drm, media)
17:44danvet: if that works'
17:55Sumera[m]: danvet: so I tried https://paste.ubuntu.com/p/NWCjpXHr4M/ and it solved the vblank tests failing and the kernel crashing errors
17:56danvet: Sumera[m], yay, success!
17:56Sumera[m]: however, for the normal mode a lot of kms_cursor_crc tests started failing
17:56Sumera[m]: and all kms_cursor_crc tests and one writeback_check_output failed for virtual_hw enabled
17:57Sumera[m]: danvet: i wish, but there's still some insidious bug in there
17:57Sumera[m]: so, then I took out the drm_vblank_init out of the condition loop
17:58Sumera[m]: and current state:
17:58Sumera[m]: for virtual_hw enabled, all tests pass but things crash on removing the module
17:59Sumera[m]: for normal mode, majority kms_cursor_crc tests fail
18:00Sumera[m]: I think the failing tests may have more to do with the tests rather than the vkms driver changes
18:01Sumera[m]: as for the crashing, pretty sure drm_vblank_init is doing some funny stuff and calling vblank_simulate somehow ;-;
18:15tzimmermann: sailus, it's getting late here. i'll send you a review tomorrow
18:15tzimmermann: the code looks nice AFAICS
21:57Lyude: Are drm bridges usually only attached to an encoder once during a drm device's lifetime?
22:38robclark: Lyude: *probably*.. a bridge isn't usually a hot-pluggable thing... although I suppose there could be some muxing (in theory, not aware of anyone doing this) upstream of the bridge..
22:48zmike: mareko: I think I got what you wanted in the clamp series now? if not then I have no idea
23:22anholt:finds an ugly corner of mesa, with incorrect docs, and I wrote them.
23:23anholt: jekstrand, mareko: opinions requested: what should num_ssbos mean in a shader info? my opinion would be "maximum binding point accessed plus one"
23:25anholt: the case I'm looking at is a deqp with an ssbo blockD at binding point 3. our num_ssbo is 4 because we're just summing up the number of array slots for used ssbos.
23:27jekstrand: anholt: In Vulkan, it's meaningless. It's pretty much a boolean.
23:27jekstrand: anholt: In GL, Uh... Not sure. I think we may still use it in i965 for something and I think there it means number of bindings.
23:27anholt: jekstrand: would "zero means no SSBOs are used" be true for vulkan?
23:28jekstrand: anholt: Yes
23:28jekstrand: Well, more like "no ssbo use is declared" which is different from actual use
23:28anholt: we use num_ssbos to decide on the binding point to stick lowered atomics at, so it end up mattering quite a bit for GL
23:29bnieuwenhuizen: don't forget BDA for Vulkan :)
23:29jekstrand: I think for GL, having it mean "max binding + 1" seems reasonable
23:29airlied: maybe we can fix num_textures next
23:29airlied: and textures_used
23:30zmike: anholt: I've been using num_ssbos as literally the number of ssbos
23:32zmike: though I guess, upon review of my usage, this is essentially conflated with binding points as well since they're very similar...