00:05 DemiMarie: karolherbst: Is that why AMD GPUs have problems in Qubes sometimes?
00:06 gfxstrand: Oh, good, my patch contains at least one line that's at least 130 characters. Should be acceptible. :)
00:06 karolherbst: DemiMarie: well.. if one VM crashes the GPU then yeah, but I thought Qubes doesn't allow acceleration in VMs yet?
00:07 Sachiel: gfxstrand: pretty sure I've seen lines indented by 130 characters
00:07 karolherbst: but it could be that rebooting the GPU VM could run into a state where amdgpu can't boot the GPU? mhh.. maybe?
00:07 karolherbst: every driver has different rules anyway :D
00:07 DemiMarie: karolherbst: we don’t (yet — hoping to fix that), but we *do* run with the IOMMU on all the time
00:07 karolherbst: ahh
00:07 gfxstrand: Sachiel: I'm up to 150 now. :)
00:07 karolherbst: yeah.. that can be quite buggy
00:08 DemiMarie: karolherbst: any reason to not have IOMMU on in CI?
00:08 karolherbst: it's buggy?
00:08 DemiMarie: then fix it :P
00:08 karolherbst: yeah well.. ask AMD :P
00:09 DemiMarie: Are you from AMD?
00:09 karolherbst: no
00:09 DemiMarie: Ah
00:13 DemiMarie: AMD iGPU pass-through runs into at least two other problems IIUC:
00:13 DemiMarie: 1. The GPU needs a specific subset of physical memory, but there is no way for the guest to ask Xen for that specific memory.
00:13 DemiMarie: 2. Unprivileged guests cannot be given access to the AMD-SP (for extremely obvious reasons), but the AMD GPU driver requires it!
00:13 DemiMarie: Are both of those accurate?
00:14 Ristovski: Speaking of AMD, I wonder if the "More than 1GB of UMA size on APUs gives better perf on Windows" is also the case on linux
00:21 gfxstrand: jenatali: MR made
00:21 gfxstrand: jenatali: That took way too long
00:21 gfxstrand: Well, gerrit CL, rather
00:21 jenatali: gfxstrand: Thanks!
00:22 gfxstrand: Way too much time spent all to write 2 lines of code
00:22 gfxstrand: Oh, well
00:22 jenatali: Heh
00:22 gfxstrand: New vulkan driver authors everywhere will thank me, I gues.s
00:22 jenatali: I should've tried to fix it when I debugged it months ago
00:22 gfxstrand: jenatali: I'm just glad you spoke up.
00:22 jenatali: But instead I just flipped on 1.1 to make the failures go away
00:22 gfxstrand: hehe
00:23 jenatali: We'll, glad I could help
00:24 gfxstrand:is debating rsyncing this to the NVK test box
00:25 jenatali: gfxstrand: Btw, I used NVK as a source of inspiration for how to implement VK_EXT_descriptor_indexing, so thank you for that
00:25 gfxstrand: :D
00:26 jenatali: Still have to type it up, but at least I have a plan now
00:26 gfxstrand: jenatali: Given that D3D12 is basically the NVIDIA descriptor model, uh, yeah...
00:26 jenatali: Yeah...
00:26 jenatali: Except we cap our sampler limit at 2048 because static samplers is a hybrid with AMD, and our design apparently favors them and makes NV do weird things
00:27 gfxstrand: Yeah, AMD is a bit wonky there
00:31 gfxstrand: Really, all the hardware is wonky and it sucks
00:31 gfxstrand: I wish hardware would stop being wonky
00:31 jenatali: Amen
00:31 gfxstrand: Like, I 100% understand every single design decision that went into getting Intel, AMD, NVIDIA, and the others where they are today
00:31 gfxstrand: But ugh.....
00:31 gfxstrand: See also my blog post on the topic.
00:32 jenatali: Yep, I have
00:34 gfxstrand: And now that NVIDIA supports non-uniform image/sampler pairs, there's no way they're going to take on an AMD-like model without a serious hardware re-design.
00:34 gfxstrand: And there's no way AMD would go backwards and do more heaps like NV.
00:34 jenatali: Yep
00:35 gfxstrand: The most that I could see happening is convincing NVIDIA to make their heaps bigger and do a separate u32 for images vs. samplers.
00:36 gfxstrand: That'd let the heap cover 128GB worth of VA which should be enough to pretend it's pointers
00:38 gfxstrand: Ok, let's see if this new CTS build kills my NVK box
00:38 gfxstrand: Haven't updated my CTS branch in about 6 months
08:48 mareko: "gfxstrand> jenatali: Given that D3D12 is basically the NVIDIA descriptor model" ... except D3D12 is unofficially a fork of AMD Mantle
09:20 glehmann: mareko: but d3d12's descriptor model is not similar to mantle at all
09:21 glehmann: not even vulkan's descriptor model as flexible as mantle, you can have linked lists of descriptor sets in mantle
11:25 karolherbst: I have a problem and the current solution means "you have to rebuild mesa on every single clang update"
12:20 karolherbst: gfxstrand: this lower_io patches already ends up being a huge mess.. so apparently for GL and bindless textures it's expected to get lowered for ubos :(
12:22 karolherbst: (but bindless textures are ultimately broken anyway, just nobody bothered fixing it all up for real)
12:27 karolherbst: could also add a check against uniform in the patch :')
13:20 jenatali: mareko: Some bits of D3D12 took inspiration from Mantle, but resource binding was not one of them
14:20 mareko: D3D12 might have motivated AMD to give Mantle to Khronos
15:39 Lynne: https://0x0.st/Hs-X.jpg I think dx12 took a little bit more from mantle than insipration
15:43 ccr: :P
16:30 jenatali: I don't think that doc on the right ever existed... Need to check the wayback machine for the URL
16:43 jenatali: Yeah, can't find any evidence it ever existed. The only hits for that text are coming up in reference to that screenshot. Prettttttty sure it's doctored
16:43 jenatali: FWIW D3D12 was already in development when Mantle was announced/released
18:11 karolherbst: gfxstrand: new version of the patch which doesn't cause any regressions: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20161/diffs?commit_id=55e0c9463cc3c0a13042136274438bcebbabdb33
18:11 karolherbst: ehhh
18:11 karolherbst: yes
18:53 Lynne: jenatall: I found this link https://msdn.microsoft.com/en-us/library/dn899122 which apparently had information in it years ago but was apparently removed later
18:53 Lynne: the wayback machine hadn't indexed it
18:53 Lynne: so I'm still on the fence whether it was faked or not
18:55 siddh: Hi, can anyone take a look at these DRM logging patches: https://lore.kernel.org/lkml/cover.1673269059.git.code@siddh.me/
18:55 siddh: I had sent them last month, though it seems like people did not get time to review some of them. Please let me know if anything is wrong with them. Thanks.
22:02 alyssa: shaving 4000+ instructions off a dEQP test is always a nice feel :p