06:43 Company: with the new dmabuf-capable llvmpipe, every texture takes 2 fds instead of at most 1 in every other driver
06:43 Company: I learned that just now because one of our stresstests creates ~800 textures
06:47 airlied: can see that blowing up alright :-)
06:49 airlied: I wonder is the dup needed
09:34 daniels: tarceri: scroll up to where all the errors are ...
09:35 daniels: tarceri: (^f TypeError, for example)
11:41 tarceri: daniels: I guess I didn't word my question very well. It should be why is this suddenly failing?
11:42 tarceri: I don't really know why there are running, who set them up or why
11:42 tarceri: But its suddenly blocking merging
11:51 tarceri: Maybe the python 3.11 test instance is missing dependances? I really don't know much about how this is all setup. But it's failing running the generation scripts from piglit main, my MR just adds a shader_runner test, it doesn't touch any python code
11:57 tarceri: apologies for the poorly worded sentences, it been a long day and my brain is tired :P
12:11 daniels: tarceri: https://gitlab.freedesktop.org/mesa/piglit/-/merge_requests/946
12:16 tarceri: daniels: Thanks!
15:33 tzimmermann: sima, airlied, can you please merge https://lore.kernel.org/dri-devel/20240816084109.GA229316@localhost.localdomain/
15:39 tzimmermann: it's last weeks PR for drm-misc-next
18:33 tjaalton: airlied, demarchi: discussion about firmware groups died a year ago, do you still plan to work on it?
20:49 demarchi: tjaalton: what discussion?
20:51 demarchi: ahh... to put only the latest blob in the initramfs ... ?
21:32 airlied: tjaalton: yeah I stalled out I probably need to resume it as we have a need, but I failed to find a pretty way to do it, and the ugly way irks me, but maybe the ugly way is the only way
21:44 demarchi: airlied: what if we have a separate info to color code the blobs?
21:45 demarchi: this way we don't rely on the order and expect users of MODULE_FIRMWARE() to indicate the groups
21:47 airlied: demarchi: I sent out a second effort to just list the blobs a second time in order in a separate thing
21:49 demarchi: I have to refresh my head on that then... don't remember exactly the context
21:50 demarchi: airlied: is this the one ? https://lore.kernel.org/linux-modules/20230704025322.2623556-1-airlied@gmail.com/
21:51 airlied: yes that is what I called the ugly one
21:51 airlied: since we have to name each fw twice
21:51 airlied: the only sorta compromise I could come up with was a horrible macro stack
21:53 airlied: but that would have limits on the number of firmwares in a group due to to the ugly macro processing
21:55 airlied: by macro stack i mean something like https://codebrowser.dev/linux/linux/drivers/gpu/drm/nouveau/include/nvif/push.h.html#176
21:55 airlied: (not quite that ugly)
21:56 demarchi: I was actually thinking something like MODULE_FIRMWARE(fw, group, prio) and creating separate infos
21:56 airlied: but you'd have a MOD_FW_LIST1, MOD_FW_LIST2 and would have to keep expanding the macro every time you added a new fw
21:56 airlied: just not sure c preprocessor is up to it
21:56 demarchi: airlied: heheh... we use something similar to that macro stacking in xe_rtp
21:57 airlied: I also wanted to avoid making the dracut code too complex as well, it's pretty straightforward now
21:57 demarchi: airlied: could we hide the complexity in libkmod?
21:58 airlied: don't think so
21:59 airlied: the current interface is so simple and anything we do has to remain compatible
21:59 airlied: so has to keep emitting the old records, just how best to attach new information to them
21:59 airlied: with no ordering
21:59 airlied: since the kernel builds the list both ways depending on the compiler
22:03 airlied: I also hadn't looked into trying to hack modpost to do some of the work, that you suggested
22:11 DemiMarie: Are there any real-world circumstances where improper synchronization by a client can cause a compositor to get VK_ERROR_DEVICE_LOST?
22:26 DemiMarie: The Vulkan specification allows this, but it seems that real-world implementations provide stronger guarantees.
22:51 kisak: I might have missed a key detail ... but why does the GPU need to bootstrap in initramfs vs the full environment
22:54 kisak: my perception of reality was that initramfs only needed to bring up enough stuff so that the main system boot process had what it needed to get going, like assemble your encrypted raid and have the network up for remote filesystems and other fancy setups
22:59 Company: don't you need to show password dialogs for encryption keys and fancy things like that?
23:03 kisak: I'd expect something like efifb or simplefb for that