05:49glehmann: > ../src/amd/compiler/instruction_selection/aco_isel_setup.cpp(372): error C7555: use of designated initializers requires at least '/std:c++20'
05:50glehmann: I thought we used c++20 for msvc now, or is this an aco specific issue?
05:58glehmann: looks like the msvc cpp version overrides were removed at some point, ugh
05:59glehmann: I guess I will have to init structs the caveman way then
07:26MrCooper: daniels: not sure dumb BOs really make sense for render-only drivers though, since by definition they cannot be used for HW rendering
07:29jannau: render only drivers like panthor, panfrost and asahi don't implement .dumb_buffer atm
08:06mlankhorst: jfalempe: I'm having troubles finding reviewers for the xe vram panic patch, can you take one more look at it, then https://www.kernel.org/doc/html/latest/process/submitting-patches.html#reviewer-s-statement-of-oversight and upgrade your acked-by to reviewed-by?
08:53MrCooper: is there any KMS UAPI (other than a modeset :) which allows user space to know that a mode not advertised by the kernel can't possibly work under any circumstances?
10:13jfalempe: mlankhorst: sure, it looks to me, you can upgrade my acked-by to a reviwed-by. I'm trying to find that mail, but feel free to make the change anyway.
10:23jfalempe: mlankhorst: done, I'm not subscribed to the intel-xe mailing list, that's why it took me some time to find it.
13:48ukleinek:suggests to upgrade jfalempe to a reviewed-by instead </nitpick>
13:49ukleinek: s/jfalempe/&'s acked-by/
13:57mlankhorst: MrCooper: are you excluding atomic TRY_ONLY | ALLOW_MODESET atomic commit?
14:04MrCooper: mlankhorst: yes, the context is the Xorg modesetting driver
14:07mlankhorst: I don't think that is actually possible to know for certain than
14:07MrCooper: consistent with my own findings so far, thanks
14:07mlankhorst: It's far easier to prove a positive (this mode can be used in this configuration)
14:08MrCooper: right, the modesetting driver trying to set each mode it automatically adds during startup wouldn't be great UX though :)
14:15mlankhorst: TRY_ONLY commit doesn't commit the mode to hardware, just checks if the state is allowed
14:15MrCooper: I know, but the modesetting driver doesn't use atomic
14:16mlankhorst: Still not fixed? :(
14:16MrCooper: nope, kernel even had to take away its toy
14:16mlankhorst: Still doable by setting atomic to 2, iirc, if it's ever fixed at least
14:17MrCooper: (also, this is about RHEL 9, which is stuck with xserver 1.20)
14:18MrCooper: setting it to 2 just gives you all the breakage again
14:18mlankhorst: Yeah exactly..
14:20mlankhorst: cam just report, then say sorry can't set it?
14:21MrCooper: you mean setting it to 2 just for testing the modes, then stop using atomic?
14:22mlankhorst: That could work yes
14:24MrCooper: not really keen on bothering with such a hack, I suspect it'll boil down to some kind of documentation instead, just wanted to check just in case if there's a straightforward solution I'd missed
19:54gfxstrand: Ugh... Why did we have to make vkQueuePresent() support multiple swapchains...
19:54gfxstrand: *sob*
19:56zmike: VK_EXT_single_queue_presentation
19:58zzyiwei: what's context here? just curious ; )
19:59gfxstrand: I'm trying to make vkQueuePresent() not vkQueueSubmit() if it doesn't have to to avoid a bit over over-sync that's apparently murdering panvk.
19:59gfxstrand: It's a mess
19:59gfxstrand: And I'm very sure the AMD internal blit queue thing is busted.
19:59gfxstrand: It's fine if you only use one swapchain, which is what everyone on the planet does, but not if you have 2.
20:00gfxstrand: We're very good at software.
20:00gfxstrand: :D
20:02zzyiwei: oh..yeah. TIL there're multiple swapchains in a single present info xD
20:02gfxstrand: And the best part? There's only one set of semaphores which means we have to be REALLY careful to not double wait. (-:
20:10gfxstrand: I think there's a way to save it
20:18zzyiwei: M swapchain number of cached internal semaphores to do the 1->M trick to feed each swapchain?
20:18gfxstrand: Yeah, that's what we'll have to do
20:20zzyiwei: for your mentioned _best part_...my silence was me checking what Android was doing in the loader, and it's busted. Hooray!!
20:21gfxstrand: :D
20:21zzyiwei: Going to file a bug for them to fix...
20:21zzyiwei: xD
20:21gfxstrand: Fortunately, for Android, it's all sync_file and that doesn't have all of the same single-wait rules. You can just dup() them like mad.
20:27gfxstrand: zzyiwei: Any chance you could implement QueueSubmit2 on top of QueueSubmit in venus? This would all be a lot easier if I could switch WSI to QueueSubmit2()
20:30gfxstrand: Ugh... Venus doesn't use vk_sync. :'(
20:32zzyiwei: yeah...that has been the biggest tech debt in venus. It's probably time to bump the kernel requirement for venus, and migrate it over to drm syncobj + vdrm
20:33gfxstrand: syncobj has been around for a while
20:33gfxstrand: IDK how long vdrm has supported it but it's been around a while
20:33zzyiwei: it was on someone's plate, but got deferred..deferred..deferred..and towards maintenance mode
20:34gfxstrand: yeah
20:34gfxstrand: I remember chatting with people at XDC about it 2 or 3 years ago
20:34gfxstrand: These things happen. ¯\_(ツ)_/¯
20:35gfxstrand: I think I can do everything I need without it
20:38zzyiwei: thanks!! It's up on my personal list of todos
21:24zzyiwei: gfxstrand: for the sync2-to-1 layering of the few wsi usages (queue submit and pipeline barrier), venus is able to layer it based on whether renderer side has sync2 support. I can hack up something if that makes common wsi happier.
21:40zzyiwei: (to avoid an extra trampoline jump for hw drivers, it's worth it i think. Will cc you once the mr is up)
22:11zzyiwei: For the wait semaphore thing, I checked the spec again. In the section 7.4.3. Semaphore State Requirements for Wait Operations, the spec says "There must be no other queue waiting on the same binary semaphore when the operation executes.". Maybe the spec allows it for binary sempahores as long as it's the same VkQueue. Let me keep reading..
22:14gfxstrand: No, binary semaphores have to have a 1:1 relationship between signals and waits
22:14gfxstrand: You can't multi-wait
22:18zzyiwei: Yes, that matches my impression. Also there's a NOTE section in 7.4.2. Semaphore Waiting
22:20zzyiwei: K...android wsi impl is indeed busted for multi swapchain then. Bug filed.