05:30cubanismo[d]: Uhg. Now that the blackwell format modifiers have landed, I realize the compressed modifiers have some weird corner cases when considering Tegra. Normal NV desktop GPUs can't compress system memory surfaces, and sharing video memory surfaces between GPUs does... weird stuff regarding compression, but Tegra can compress system memory and potentially share that surface with a desktop GPU. The
05:30cubanismo[d]: desktop GPU wouldn't be able to access the compression metadata though and would fail to map it in as comrpessed. I'm not sure whether that's sufficient deterence, or whether the modifiers should encode that incompatibility somehow. Seems like maybe it's yet another thing the capability stuff from the unified memory allocator designs would cover (explicitly advertise the memory spaces a given
05:30cubanismo[d]: mapping/layout/usage is compatible with)
14:10gfxstrand[d]: cubanismo[d]: As long as HdkR doesn't plug a 5090 into his Thor...
14:11gfxstrand[d]: Who am I kidding. We both know he will! 🤣
14:18jja2000[d]: I think Henry finally somewhat gave up
14:18jja2000[d]: He's now only sending the telegram link on matrix and nome of the stuff around it
14:25karolherbst[d]: who is Henry? And what telegram links
15:02mohamexiety[d]: gfxstrand[d]: sadly it looks like NV blocked that off. it just doesn't have the exposed slots to do that
15:02mohamexiety[d]: jury's still out on the IGX Thor though if that will allow that hehe
15:03mohamexiety[d]: but yeah I am really interested in how transparent compression can work across devices tbh, it sounds like a mess
15:03mohamexiety[d]: AMD when they went for transparent compression ended up just disabling it: https://lists.freedesktop.org/archives/amd-gfx/2025-November/133516.html
15:14jja2000[d]: karolherbst[d]: Exactly...
15:14jja2000[d]: No it's the matrix spammer I mentioned earlier.
15:15jja2000[d]: mohamexiety[d]: Mankind has succeeded in shoving pcie devices in pcie holes no matter the formfactor
15:17pac85[d]: Just take a hacksaw to it
15:45unityversatile: well the code is about to get implemented soon. Such things as removing collision sequences, is managed by removing the carried combinations stem out of the way, so we design a collision to take place on say mor than 8buts first time, cause world designs all alu operations based of +- ones which are basic blocks or say trampoline for very arithmetic or logical operation we know up to date., so after the worm eats itself the spectrum range
15:45unityversatile: is being jumped at so that means so it adds weights at them, and final calculation is in the range of, so choosing of the answer is automatic per non-collided bits per field which are presented via sums of the power representatives that are designed to remove high entropy, i.e they remove the stem and permute the mutant. to the range of highest bits in, so carry is removing now based of collision modifiers and adding based of non colliding
15:45unityversatile: ones and add is used by encoder while remove is done at runtime and applicable or consistent compatible with encoder. so adding can only add in range of everything pass through to the result that was not colliding in the format. Such super computer needs some work but in general is not harder than your current work which is somewhat pointless. so best example is the deepest decoder range which belongs to the sum of maximum bits not
15:45unityversatile: colliding being a multiplier to the equivalent storage requirement + linear algebra offsets for answers transitions/jumps and indexes and operand separation id.. I fear you'd always understood how it works for long due to me, and want to use my own code or good favor forwarded with good intentions against me, because i only tried to help you not talking about wrong things and doing wrong things overall which would in case of that committed
15:45unityversatile: consitently with other terror to me complicate my own life too.
15:52f_: karolherbst: hi there
16:06unityversatile: I have been ass sure with people who do wrong things,if you are willing to strive towards better behavior, i am willing to work with you in any of this what i had engineered with good intentions that no one gets harmed.
16:53cubanismo[d]: mohamexiety[d]: Our compression doesn't pretend it works across devices. The way it works just only makes sense for local access to local memory, which sucks, because compressing system memory on a dGPU naively seems like it'd be very desirable.
16:55cubanismo[d]: There are some weird corner cases, but it's easiest to just think about it as not a thing.
16:57cubanismo[d]: And yes, looking forward to someone trying to plug a 5090 into a Thor somehow. Also scary: What if someone decided to build a system with two Tegra CPUs on it. I don't know if the chips actually support that anyway, but it'd be a nightmare for compression management.
17:40mohamexiety[d]: cubanismo[d]: yeah compressing system memory stuff would be really convenient but I can understand the complications with that (especially given all the ways you can put stuff in system memory). thinking more about things though it feels like device -> device shouldn't be too bad from a HW standpoint. if the DMA engines have comp/decomp logic, the sender would decompress on send, and then the
17:40mohamexiety[d]: receiver when compress on receiving. I am probably forgetting a lot of little details but in theory this could be sufficient. I think.
17:41mohamexiety[d]: (that assumes sending/receiving though, not e.g. one device looking at another's memory)
17:48jannau: vulkan compute works on a rtx 3060 in M2 mac pro with 16k page size and a couple trivial changes in open-gpu-kernel-modules. no display out and no vulkan rendering
17:50jannau: I'm not volunteering for fixing 16K CPU page size in nouveau
18:06cubanismo[d]: That's with the proprietary drivers you mean?
18:07cubanismo[d]: It's interesting that Vulkan compute would work but graphics doesn't.
18:23jannau: yes, with the proprietary driver. modeset works. I didn't realize that I had to enable atomic modeset
18:25jannau: it only half works though, renders only the cursor, possibly another page size issue
18:26cubanismo[d]: Are you sure graphics doesn't work, or is it just that you can't see it?
18:26cubanismo[d]: i.e., busted display.
18:28jannau: display seems to be fine. it shows up in kwin's desplay config and the cursor works as expected over a black background
18:29jannau: windows (partially) moved to the second display are not visible
18:34HdkR: gfxstrand[d]: I'm more likely to plug a 6090 in to Thor :)
18:35jannau: could be cross GPU issue, `vkcube --wsi display` works on the 3060 connected display
18:35HdkR: IGX Thor also ships with an RTX Pro 5000/6000, so it'll definitely happen.
18:41jannau: rendering and display works now after restarting kwin. I think I loaded nvidia-drm with modeset=1 only after kwin was already running
18:42mohamexiety[d]: oh huh missed that. nice!
19:52mhenning[d]: gfxstrand[d]: For https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36336 would we typically wait for the kernel patch to hit Linus' tree, or is drm-misc-fixes enough for the userspace side to merge?
20:24cubanismo[d]: jannau: Ah, cool. That's a relief to hear.
20:24cubanismo[d]: Pretty cool too. I doubt we've ever tested on that platform.
20:27jannau: I doubt that as well. As far as I'm aware this is the only apple silicon mac pro running linux with PCIe
20:29jannau: there are still some page size issues: https://paste.debian.net/1405062/ but nothing blows up
20:29airlied[d]: mhenning[d]: Its in drm-fixes now so fine to merge usually
20:30cubanismo[d]: What's annoying is (assuming various paths just don't puke and bail out), we'll still be using 4 4k PTEs on the GPU for those 16k pages.
20:32jannau: the minimal changes I'm using are in https://paste.debian.net/1405065/
20:32cubanismo[d]: Is that MR sufficient for GBM too? I forgot whether all the layers of GBM's DRI backend will unwind through Zink, or if it needs something updated separately.
20:32cubanismo[d]: (For https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36336)
20:33cubanismo[d]: I'm surprised it gets so far with jus that change
20:41mhenning[d]: I don't think there's any card-specific modifier stuff in zink
20:42jannau: me too. The "the system page size can be larger" comment in rm_page_size.h was encouraging to just try adding 16K
20:55cubanismo[d]: mhenning[d]: Yeah, but it pulls modifiers from NVK for e.g., EGL.
20:56cubanismo[d]: I guess GBM must get them from there or DRM-KMS, because kmscube worked without further changes in my testing.
20:57gfxstrand[d]: mhenning[d]: Any official DRM branch is fine. The important thing is that it's a real branch that gets merged, not something that gets rebased.
20:58gfxstrand[d]: cubanismo[d]: Yeah, GBM gets them from NVK
20:58mhenning[d]: Right, I think that one's ready to go in then? I updated the header
21:12gfxstrand[d]: We should have something in the commit message that says what branch and what commit it was updated from
21:12gfxstrand[d]: You can see examples if you `git log include/drm-uapi`
21:20mhenning[d]: gfxstrand[d]: added
23:49cubanismo[d]: Grr.
23:49cubanismo[d]: This is not going to work right with e.g., NV12
23:50cubanismo[d]: Did we talk about that? You only get one format modifier per format, but NV12 is an 8bpp plane + a packed/16bpp plane.
23:51cubanismo[d]: The hardware layout is going to be different for each plane when you break out the aspects.
23:54cubanismo[d]: gfxstrand[d]: In case you have thoughts. ^^
23:57religiousmess: dviola: btw we are talking about scrubs i.e thieves also, who commit identity fraud and make conspiracy to worlds hidden donors with their agreements. There is absolutely no way how this type of brutal and amoral amoral leftovers gang could be useful to anyone who are after achievements in programming. They are inside my computer every day screwing everything up as of with intentions not
23:57religiousmess: to be responsible of their actions of fraud.here every such member and country of such members can be banned. Xorg protocol does that over tcp here. So don't worry real systems can not be intruded into.
23:57cubanismo[d]: I think someone (the hardware or the software) is going to have to get lied to about the layout when using modifiers + packed planar surfaces.
23:58cubanismo[d]: Well, the driver or the app I guess. The hardware behavior is immutable.