00:05zmike: tarceri: if you were coming to XDC I would buy you a beer or ten
00:05zmike: you deserve a round of applause
00:28tarceri: lol, long way to travel for 10 beers but tempting haha
00:54kode54: I have a MSI motherboard, and it has an iGPU option called "Hybrid Graphics" and I have no idea what it's for
00:54kode54: I don't even know if it has any meaning under Linux
00:55kode54: I just know when I attempted it, I only had one GPU visible to Linux
01:00airlied: usually that manes turn on the igpu and the dgpu
01:20karolherbst: sooo.. SVM done on radeonsi as well 🙃
01:25airlied: karolherbst: nice
01:25karolherbst: in theory it should also work cross vendor cross device, but I need to fix memory for multiple dev context first 🙃
01:26karolherbst: but hey.. it's still two weeks
02:56Company: kode54: there's CPUs with builtin igpus (I have one) and if I enable hybrid graphics the bios enables both my igpu and dgpu - if I don't the igpu is invisible to the OS
02:56kode54: if I enable hybrid graphics, there's only one gpu visible to the host os
02:57kode54: if I don't, and set initiate to IGD and UMA Auto, both are visible
02:57Company: maybe your bios is doing something else then?
02:57kode54: it's some special MSI bullcrap
02:58kode54: they also still insist on calling 64 bit PCI addressing "Cryptocurrency Mining mode"
02:59kode54: at least they now turn it on by default, as well as ReBAR
03:04Company: kode54: https://www.msi.com/blog/msi-discrete-graphics-mode-explained explains it the opposite way, especially with that image: https://storage-asset.msi.com/global/picture/news/2021/nb/3d-mark-20210615-2.jpg
03:04Company: but what do I know what the bios does
03:05kode54: well, I don't know what the option does really other than their explanation
03:05kode54: I just know that when I turned it on, I couldn't see both GPUs from Linux, only the dGPU
03:06kode54: this is a desktop system, too
03:36DavidHeidelberg: mareko: Ack :)
09:37luc: Hi, what happens to the bo's gpuva after a dma-buf is exported? Does it need to reestablish the gpu page table for its importer?
09:38dolphin: luc: can you elaborate on the question?
09:40dolphin: when you export the dma-buf, you essentially share the dma addresses, so page table setup is on the responsibility of the consumer/importer
09:43luc: are dma addresses(gpu va iiuc) valid both in the exporter and importer processes?
09:44dolphin: ah, not at all, the dma addresses are only known by kernel behind the scenes
09:44dolphin: if you have mapped the dma-buf to CPU memory, that address is completely private to that process
09:45dolphin: dma addresses are physical addresses
09:45dolphin: virtual addresses that are used by CPU process and GPU workloads, get automatically translated by kernel drivers/hardware
09:46dolphin: you will never know what the actual physical addresses are, virtual addresses can be unique per address space
09:50luc: i know that bo's cpu virtual addresses are unique in exporter and importer processes, but what about gpu virtual addresses? are they different in exporter and importer processes?
09:52dolphin: that would be dependent on the GPU driver and the application, so there's no guarantee
09:55dolphin: most drivers allow the user to choose the virtual address when they bind the dma-buf, so the two processes would have to use IPC to agree
10:00luc: thanks very much
18:46austriancoder: is nir_intrinsic_image_size comparable to glsl's textureSize(..) or nir's texop txs?
18:53glehmann: nir_intrinsic_image_size is imageSize and nir_texop_txs is textureSize
19:03glehmann: so yes they do the same thing, just for different descriptor types (sampled image vs storage image)
19:06austriancoder: glehmann: thanks
21:35Curan: @airlied @karolherbst I hate pinging you here, but if you could give me a Rb (or direction where to take it) on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31364 "soonish", I'd appreciate it, since I'll be without (stable) internet for a bit soon. And I'd love to finish this – seemingly – simple MR before I'am away. Thanks for having a look!