07:52 airlied: gfxstrand: gdb takes a wierd path that we might have screwed up
09:31 Venemo: MrCooper: can you please stop?
09:32 MrCooper: you mean stop sharing my opinion based on decades of experience working on GPU drivers? I'm afraid I'll have to politely decline
09:33 MrCooper: I'm trying to help you find the real issue
09:34 Venemo: your reply on the gitlab is both inaccurate and unhelpful
09:34 MrCooper: I obviously disagree on both counts
09:34 MrCooper: it points you toward the real issue
09:35 Venemo: the BO is not evicted when the background is visible. otherwise how else could mutter draw the background?
09:35 MrCooper: I explained that
09:35 Venemo: no you didn't
09:35 MrCooper: the huge BO is only used for generating the screen-sized copies, not directly for drawing the background
09:36 Venemo: (1) it will not evict the screen-sized copies when the background is visible, (2) you are right that the huge BO can be evicted but it shouldn't even be kept in system RAM because it's a waste of system RAM
09:38 MrCooper: that's going off on a tangent, not part of "mutter's BOs are keeping app BOs out of VRAM" anymore
09:40 Venemo: I can cross out that sentence if you think that isn't the case
09:41 MrCooper: the rest boils down to "drawing stuff requires memory"
09:42 Venemo: no, the rest boils down to "don't waste RAM"
10:49 Company: could you continue arguing but stop hating so that I can keep learning?
10:49 Company: when to cache textures vs when to evict has been a question I've never had a good answer for
11:07 MrCooper: I'm defending myself against IMHO unjustified attacks
11:09 Venemo: Company: the kernel (specifically, the vm manager in amdgpu) will evict BOs from VRAM when you are using too much VRAM, in order to make space for things that actually need to be in VRAM. when there is not enough, it will try to make a guess and decide what is better to have in VRAM and what isn't. this will happen before every submission, to make sure each submission has the resources that it needs available
11:10 Company: my interest here is mainly with applications that are in the background
11:11 Company: if you have a maximized GTK app open elsewhere, we will have a swapchain and that's 4 (I think) images with full size
11:11 Company: At what point does it make sense to get rid of that swapchain?
11:12 Venemo: I don't know if the kernel is aware of whether the the application is in the background or not (or even, has a GUI or not). AFAIU when an app draws something, ie. submits commands to the GPU, then the VM manager makes a decision on which BOs need to be in VRAM and moves them on demand
11:13 Company: I also have no idea how expensive it is to create a swapchain vs swapping back in the images
11:14 Venemo: assuming that GTK is smart and doesn't redraw its GUI unnecessarily, then it is possible that a background app's BOs are all evicted
11:14 Venemo: I don't know the answer to your swapchain question
11:15 Company: I also have no idea how useful any of this would be
11:15 Company: I know some people have tons of windows open all the time, which would result in tons of swapchains
11:16 Company: and on a 4k monitor, each maximized swapchain is ~100MB
11:17 Company: and when you start gaming, you're probably not alt-tabbing back for a long time and would like to use your memory for the game
11:17 Company: but then, nobody has ever complained...
11:19 Venemo: in that case the kernel can probably evict those, and they will stay in GTT until those apps want to draw something again
11:20 Company: that reminds me
11:20 Venemo: I know that's a vague answer but I haven't studied the topic in more detail
11:20 Venemo: maybe MrCooper can help fill in the blanks here
11:20 Company: there's a VkSwapChain extension that allows allocating the images on-demand
11:20 Company: but Mesa doesn't implement that
11:22 Company: VK_SWAPCHAIN_CREATE_DEFERRED_MEMORY_ALLOCATION_BIT_KHR
11:31 mupuf: leio: FYI, the amdgpu.dcdebugmask=0x810 did not solve the underrun
11:33 mupuf: I'll need to compile a kernel with your patch, but I may switch to dcdebugmask=0x2 first though
11:35 zamundaaa[m]: Company: You do have the suspended hint on Wayland, which you could use to destroy the swapchain
11:35 Company: yeah - but should I?
11:35 zamundaaa[m]: Would need testing to make sure you don't cause a lot of lag when the user starts seeing all the windows again
12:20 tzimmermann: jfalempe, if you have a moment today, could you look at https://lore.kernel.org/dri-devel/20251024073626.129032-1-tzimmermann@suse.de/ . it's an additional fix for the recent ast BMC issues. here's hope to include it in this week's -misc-fixes
12:47 lumag: daniels, robclark: I'm gettign "No space left on device" emails from freedreno@ Mailman.
12:58 emersion: eh
12:59 emersion: it's that time of the year again
13:02 emersion: looking
13:03 soreau: is there no prune script on a cronjob? :P
13:04 emersion: you need to select what kind of user data to delete
13:24 leio: mupuf: i think you wanted to highlight someone else
13:24 mupuf: leio: oops, yes, sorry!
13:25 mupuf: lileo: FYI, the amdgpu.dcdebugmask=0x810 did not solve the underrun
13:33 fomys: Is dri-devel broken?
13:33 MrCooper: Company: GTK by default waits for the previous presentation to complete before working on the next frame, doesn't it? If so, it shouldn't need 4 swapchain images, 3 or even 2 should suffice
13:34 fomys: I just tried to send a series and I got a "Undelivered Main Returned to Sender" from MAILER-DAEMON@freedesktop.org with python error
13:34 fomys: <dri-devel@lists.freedesktop.org>: Command died with status 1: "/var/lib/mailman/mail/mailman post dri-devel". Command output: Traceback (most recent call last): File "/var/lib/mailman/scripts/post", line 69, in <module> main() File "/var/lib/mailman/scripts/post", line 64, in main tolist=1, _plaintext=1) File "/var/lib/mailman/Mailman/Queue/Switchboard.py", line 138, in enqueue fp.write(msgsave) IOError: [Errno 28] No space
13:37 soreau: emersion: ah, so it requires an entity with the ability to reason
13:37 soreau: so much for AI automation..
13:51 emersion: fomys: should be better now
13:54 jani: anyone up for some displayid quirk review, fixes stuff for both amd and intel? https://lore.kernel.org/r/cover.1761681968.git.jani.nikula@intel.com
14:01 zmike: mareko: fixed https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38134
14:09 fomys: emersion: Thanks, I will resend the series!
14:45 Company: MrCooper: I think I used 4 because there were cases where the 4th was sometimes used - maybe on X11?
14:45 Company: MrCooper: but I decided it's not my problem, I set 4 and use VK_SWAPCHAIN_CREATE_DEFERRED_MEMORY_ALLOCATION_BIT_KHR and then the driver can decide what to do about it
15:04 Venemo: Company: can't you query the suggested swapchain image count?
15:04 Company: there's a min/max but I don't think there's a suggested one
15:38 glehmann: the minimum is pretty much that
17:06 glehmann: can someone explain to me I have to let msvc bully me into not using xor on bools https://gitlab.freedesktop.org/mesa/mesa/-/jobs/86927620
17:08 glehmann: I guess I have to make the code unreadable again just to get this through CI
17:14 mareko: jenatali: hi, any idea why https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38100 crashes d3d12 with piglit test spec@arb_gpu_shader5@arb_gpu_shader5-emitstreamvertex_nodraw ?
17:16 mareko: a backtrace / call stack of the crash would be useful
17:17 karolherbst: glehmann: feels like a compiler bug.. unless "bool" is not a "bool"
17:18 karolherbst: ohh wait..
17:18 glehmann: nah the issue is that bool ^ bool gets promoted to int ^ int in C++
17:18 karolherbst: is ^ an integer xor always?
17:18 karolherbst: ... right...
17:18 glehmann: but as long as all inputs are bools, that doesn't matter
17:18 karolherbst: it's the same as !=, no?
17:19 glehmann: yes, but in this context ^ is just much more fitting
17:19 karolherbst: yeah...
17:19 glehmann: also a != b != c looks stupid, a ^ b ^ c does not
17:20 karolherbst: yeah....
17:20 karolherbst: well
17:20 karolherbst: could be worse
17:20 glehmann: well, yes
17:21 glehmann: but every compiler will also try to get you to add parenthesis around !=
17:22 glehmann: and that's really silly if all I want is a ternary xor
17:24 Company: #define ^ !=
17:26 karolherbst: ^^ to make it a boolean xor (it makes even sense)
18:16 alyssa: karolherbst: makin a happy face thinking about boolean algebra ^^
20:28 mlankhorst: patchwork down? https://patchwork.freedesktop.org/project/intel-xe/series/ gives 502
21:05 mareko: zmike: zink now crashes differently but only if the shader cache is enabled, so at least it's usable without it
21:05 zmike: hm I didn't see that