00:26fdobridge_: <gfxstrand> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26617
04:14fdobridge_: <gfxstrand> Okay, so it looks like ldc doesn't like to do indirects with anything but 8 and 32-bit. 64-bit throws misaligned addr and I've had problems with 16-bit, too.
04:15fdobridge_: <gfxstrand> @karolherbst Do you have docs that could put a finer point on that understanding?
04:25fdobridge_: <gfxstrand> @asdqueerfromeu FYI: I just made you a Reporter in Mesa so you can now apply labels to issues (not sure about MRs) and you're a bit easier to tag. IDK how useful that'll be but you've been trying out and reporting enough stuff that it seemed like a good idea.
04:25fdobridge_: <gfxstrand> @asdqueerfromeu FYI: I just made you a "Reporter" in Mesa so you can now apply labels to issues (not sure about MRs) and you're a bit easier to tag. IDK how useful that'll be but you've been trying out and reporting enough stuff that it seemed like a good idea. (edited)
05:24fdobridge_: <gfxstrand> Okay, now I'm very confused. More misaligned addr errors and all my LDCs are `ldc.b32`. 🙃
05:28fdobridge_: <gfxstrand> Ugh... Okay, it appears that I have an instruction dep bug. `NAK_DEBUG=serialize` makes some of my problems go away. 😩
05:36fdobridge_: <gfxstrand> Maybe instructions that read cbufs have variable latency?
05:46fdobridge_: <gfxstrand> That doesn't seem to fix it. Maybe something weird with LDC? IDK.
05:47fdobridge_: <gfxstrand> Bumping all latencies to 15 doesn't do anything either
07:04fdobridge_: <!DodoNVK (she) 🇱🇹> Does nouveau KMD support cache snooping? :nouveau:
07:05fdobridge_: <!DodoNVK (she) 🇱🇹> Apparently it's needed for memory to be both cached and coherent
07:13fdobridge_: <!DodoNVK (she) 🇱🇹> More precisely I get `ROBUST_CHANNEL_FIFO_ERROR_MMU_ERR_FLT`
07:15fdobridge_: <!DodoNVK (she) 🇱🇹> :cursedgears:
07:15fdobridge_: <!DodoNVK (she) 🇱🇹> https://cdn.discordapp.com/attachments/1034184951790305330/1183305926200004668/message.txt?ex=6587da85&is=65756585&hm=7b523cccb8137d730e3cbc3a59f208c2fccd17a004cbfe1553f87e89df7c3408&
07:36diagonal3x: There are open course MIT lectures, now one interesting lecture there is a data structure called van Emde Boas trees, i also looked FFT, awesome academics teacher is doing them on board and the lectures are recorded with video.
07:50diagonal3x: So we can do a lot yet with memory and performance, it looks similar to fusion and sardine trees. So you can insert delete and successor query
08:03fdobridge_: <!DodoNVK (she) 🇱🇹> The test that causes it is `test_uav_counter_null_behavior_dxbc` (and the `dxil` version too)
08:28fdobridge_: <!DodoNVK (she) 🇱🇹> Here's a singlethreaded test run (for some reason I don't get a CPU hang anymore)
08:28fdobridge_: <!DodoNVK (she) 🇱🇹> https://cdn.discordapp.com/attachments/1034184951790305330/1183324229601599508/message.txt?ex=6587eb91&is=65757691&hm=b079ae2de936a6d628664c23844fbbb1f632b973f089b1931886b78b285a2dff&
09:27diagonal3x: i am on 50 min of that lecture, but that is just for data access, my version is algorithmic structures, it generates the data access constants, and the time is logloglogu imo, cause there isn't any not even one recursive call, but they explain that lowestbound is loglogu or n
09:28diagonal3x: its inherent to the time complexity, they just assume we are working on arrays
09:41diagonal3x: cause operation system is indeed working on array , so that makes sense, cause it just handles gazillion of structures and it just iterates over program counter anyhow
09:41diagonal3x: so lower bound in time complexity is the one they introduced which is loglogn
10:07diagonal3x: https://en.wikipedia.org/wiki/Fusion_tree actually 2014 they already had logµn time
10:08diagonal3x: but this is not yet reflected on this lecture
10:09diagonal3x: 7 years ago was that lecture so 2016, two years earlier they proposed a new time domain access
11:26fdobridge_: <karolherbst🐧🦀> sadly no
12:43fdobridge_: <karolherbst🐧🦀> however.. I have examples of `LDC.64` using registers
12:44fdobridge_: <karolherbst🐧🦀> ehh wait.. they use `RZ` there.. mhh
12:46fdobridge_: <karolherbst🐧🦀> @gfxstrand actually... I'll play around with OpenCL to PTX to SASS stuff as this should make it easy to figure out what they are doing there :ferrisUpsideDown:
12:51fdobridge_: <karolherbst🐧🦀> `LDC.64.IL R2, c[0x0][R2]`
12:51fdobridge_: <karolherbst🐧🦀> `LDC.U16.IL R5, c[0x0][R0]`
12:52fdobridge_: <karolherbst🐧🦀> `LDC.U16.IL R5, c[0x0][R5+0x6]`
12:53fdobridge_: <karolherbst🐧🦀> `LDC.64.IL R2, c[0x0][R2+0x18]`
12:53fdobridge_: <karolherbst🐧🦀> that's all what nvidia produces
13:22fdobridge_: <karolherbst🐧🦀> okay.. vulkaninfo at least doesn't crash on volta
13:23fdobridge_: <!DodoNVK (she) 🇱🇹> Now try the cube
13:23fdobridge_: <karolherbst🐧🦀> I just go straight to the VTS
13:23fdobridge_: <karolherbst🐧🦀> *CTS
13:24fdobridge_: <karolherbst🐧🦀> mhh `Error: Finding QPA test start delimiter for dEQP-VK.info.device`
13:24fdobridge_: <!DodoNVK (she) 🇱🇹> Vendor Test Suite 🐸
13:24fdobridge_: <karolherbst🐧🦀> maybe I shall try the cube first
13:25fdobridge_: <karolherbst🐧🦀> okay uhhh
13:25fdobridge_: <karolherbst🐧🦀> I think GL is broken 🥲
13:25fdobridge_: <karolherbst🐧🦀> or uhm...
13:25fdobridge_: <karolherbst🐧🦀> maybe it's kms
13:25fdobridge_: <karolherbst🐧🦀> everything is yellow 😄
13:25fdobridge_: <karolherbst🐧🦀> the heck
13:26fdobridge_: <karolherbst🐧🦀> yeah.. okay.. kernel bug
13:27fdobridge_: <karolherbst🐧🦀> let's try 6.5 and 6.4 just to be sure
13:27fdobridge_: <karolherbst🐧🦀> funky...
13:28fdobridge_: <karolherbst🐧🦀> it's also yellow on 6.5 and 6.4
13:28fdobridge_: <karolherbst🐧🦀> but it's okay in grub
13:28fdobridge_: <karolherbst🐧🦀> *sigh*
13:29karolherbst: airlied, Lyude: kms is entirely broken on my GV100, like.. it's all yellow :)
13:29karolherbst: like... not solid yellow, but just well.. only yellow
13:38fdobridge_: <karolherbst🐧🦀> anyway.. the CTS doesn't run with the runner...
14:05diagonal3x: http://web.stanford.edu/class/archive/cs/cs166/cs166.1196/lectures/16/Small16.pdf stanford deals with it too,they call patricia codes such compression. But i go step further i pack alus too.
14:21diagonal3x: I think that is a bit party ruining to go straight into highest performance, but it gives benefits too for users,people are bored they want to communicate and hold down to some set of dogmas. HOWEVER i try to roll public domain implementation of everything and make a product.
15:17fdobridge_: <gfxstrand> Well, there's two directions snooping can go. I think generally PCI devices can snoop the host CPU cache. IDK if nouveau is maps them that way, though. If so, GART memory should be both host visible and host cached. Then there's where the host can see through GPU caches. I think only Intel can do that.
15:19fdobridge_: <gfxstrand> Wait, what?!? Those are all the sizes I've had trouble with. 😭
15:29fdobridge_: <!DodoNVK (she) 🇱🇹> I wanted to set both HOST_CACHED and HOST_COHERENT flags for the GTT heap
15:32fdobridge_: <gfxstrand> Yeah, I'm not sure we can.
15:35fdobridge_: <gfxstrand> Well, we probably get a write-combined map which isn't quite the same as fully cached.
15:35fdobridge_: <gfxstrand> We really should have a memory property for write-combined but we don't.
15:36fdobridge_: <!DodoNVK (she) 🇱🇹> So should I make two memory types for GTT (one with HOST_VISIBLE_BIT and HOST_COHERENT_BIT and the other with HOST_VISIBLE_BIT and HOST_CACHED_BIT)? 🐸
15:36fdobridge_: <gfxstrand> WC maps are coherent, fast to write and slow AF to read. They're what you want for data upload.
15:37fdobridge_: <!DodoNVK (she) 🇱🇹> RADV sets HOST_VISIBLE, HOST_CACHED and HOST_COHERENT bits for the GTT memory type
15:38fdobridge_: <gfxstrand> For GART memory, we want CACHED+VISIBLE+COHERENT.
15:39fdobridge_: <gfxstrand> (assuming system memory BOs are cached which I'm pretty sure they are. We should double-check with @airlied or dakr, though )
15:41fdobridge_: <gfxstrand> For VRAM, I think we can say VISIBLE+COHERENT but we probably want two different types, one with host and one without and set the MMAP flag when allocating accordingly.
15:42fdobridge_: <gfxstrand> (assuming system memory BOs are cached which I'm pretty sure they are. We should double-check with @airlied or dakr, though) (edited)
15:42fdobridge_: <!DodoNVK (she) 🇱🇹> gamescope needs VISIBLE and DEVICE_LOCAL memory (while vkd3d-proton needs VISIBLE and CACHED memory)
15:43fdobridge_: <gfxstrand> Yeah, I think the above should satisfy both. DXVK really wants DEVICE_LOCAL+VISIBLE, too. Data uploads will go way faster if we turn that on.
15:44fdobridge_: <!DodoNVK (she) 🇱🇹> I added the CACHED bit to the GTT type and vkd3d-proton tests have much less failures
16:05fdobridge_: <!DodoNVK (she) 🇱🇹> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26621
16:12fdobridge_: <gfxstrand> @asdqueerfromeu Beat me by 6 minutes
16:12fdobridge_: <gfxstrand> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26622
16:16fdobridge_: <gfxstrand> As for tegra, I honestly have no idea. It's not a PCI device so IDK what the snooping story is. A lot of iGPUs need uncached memory but sometimes they can snoop. I'll need to chat with dakr and @airlied about it. I've pinged them on my MR and hopefully we can get our story straight.
16:16fdobridge_: <gfxstrand> @asdqueerfromeu It's long past time we sorted out heaps so thanks for bringing it up again.
16:17HdkR: Tegra changes depending on the SoC
16:17fdobridge_: <gfxstrand> Of course it does
16:17HdkR: Some of the newer ones can have the GPU snoop the CPU caches, but not the other way around
16:17fdobridge_: <gfxstrand> Do we have that information exposed through the UAPI somehow so we can configure the bits properly?
16:18fdobridge_: <gfxstrand> Yeah, I didn't figure. Only Intel is crazy enough to have a shared cache.
16:18fdobridge_: <gfxstrand> Which is aweseom, BTW. It's one of the few really nice things about working on Intel GPUs.
16:18HdkR: You /might/ get lucky with Orin, but does anyone actually care about that SoC? :)
16:19HdkR: Grace is probably coherent both ways, but no consumer is buying that
16:19fdobridge_: <gfxstrand> What I want is the ability to control snooped vs. uncached. We want uncached for more "device local" things and cached for mapped things.
16:20fdobridge_: <gfxstrand> That makes sense for a compute-focused SoC.
16:20HdkR: Hopefully when you program the MMIO those bits are controlled explicitly
16:20HdkR: er...IOMMU
16:21fdobridge_: <gfxstrand> Yeah, and NVK isn't really advertised as working on Tegra right now so I'm not too worried about it.
16:21fdobridge_: <gfxstrand> I should probably throw Tegra behind the BROKEN_VULKAN_DRIVER flag
16:22HdkR: Only support the Tegra X1 and you've already covered 90% of the userbase :P
16:23fdobridge_: <!DodoNVK (she) 🇱🇹> The Nintendo Switch definitely increases userbase a lot
16:24fdobridge_: <gfxstrand> Yeah. I want to support Tegra eventually. Just not today.
16:25fdobridge_: <karolherbst🐧🦀> did you try it with `.IL`?
16:25fdobridge_: <karolherbst🐧🦀> at this point, everything can be relevant 😄
16:25fdobridge_: <karolherbst🐧🦀> maybe there are some mmio regs we also have to flip.. or something on the header... or maybe compute is different?
16:25fdobridge_: <karolherbst🐧🦀> who knows
16:26fdobridge_: <gfxstrand> Yeah. I think I need to sort out my instruction deps bug first
16:28fdobridge_: <karolherbst🐧🦀> also.. might be worth putting an `iand` in front of those `LDC` just to verify the alignment is indeed correct
16:29fdobridge_: <karolherbst🐧🦀> @gfxstrand anyway, any idea why deqp-runner refuses to run? Also.. in case it's a CTS thing, what git commit are you on?
16:29fdobridge_: <gfxstrand> Are you setting `NVK_I_WANT_A_BROKEN_VULKAN_DRIVER=1`?
16:30fdobridge_: <gfxstrand> I'm on `vulkan-cts-1.3.7.0`
16:30fdobridge_: <karolherbst🐧🦀> I do
16:31fdobridge_: <gfxstrand> Does `./deqp-vk -n dEQP-VK.api.smoke.triangle` work?
16:31fdobridge_: <karolherbst🐧🦀> let's try that tag and see if it works
16:32fdobridge_: <karolherbst🐧🦀> ~~no~~ yes
16:32fdobridge_: <karolherbst🐧🦀> `assertion failed: sm >= 75`... but that's the part I will deal with 😄
16:32fdobridge_: <gfxstrand> hehe
16:32fdobridge_: <karolherbst🐧🦀> but yeah.. that's on gfxstrand/nvk/volta
16:33fdobridge_: <gfxstrand> I think most `sm >= 75` can become `sm >= 70` except for the parts about UGPRs.
16:33fdobridge_: <gfxstrand> Oh, and Volta doesn't have IMnMx for some reason
16:33fdobridge_: <karolherbst🐧🦀> yeah.... I'll figure all those things out 🙂
16:35fdobridge_: <gfxstrand> Hrm... I don't think the CTS is liking that branch... IDK why. It's not like we don't mmap VRAM all over the driver internally.
16:36fdobridge_: <gfxstrand> Maybe we're hitting BAR limits that the kernel doesn't know how to handle gracefully?
16:44fdobridge_: <karolherbst🐧🦀> @gfxstrand mhhh.. same error when running the tag you are using..
16:44fdobridge_: <karolherbst🐧🦀> I'm sure it's something silly and me running it through SSH...
16:46fdobridge_: <karolherbst🐧🦀> ehh wait
16:47fdobridge_: <karolherbst🐧🦀> it was something silly 🙂
16:47fdobridge_: <karolherbst🐧🦀> @gfxstrand I used the GL deqp runner instead of the vk one 🥲
16:47fdobridge_: <karolherbst🐧🦀> (in my script)
16:48fdobridge_: <karolherbst🐧🦀> it "works": `Pass: 5, Crash: 45, Skip: 450, Duration: 31, Remaining: 70:00:46`
16:49fdobridge_: <karolherbst🐧🦀> dmesg going crazy with that assert fixed 🥲
16:50fdobridge_: <karolherbst🐧🦀> I suspect it's the shader header thing...
16:56fdobridge_: <karolherbst🐧🦀> okay.. works with codegen
16:58fdobridge_: <karolherbst🐧🦀> @gfxstrand Volta uses the old header format btw
16:58fdobridge_: <karolherbst🐧🦀> meaning its size is 0x50, not 0x80
17:01fdobridge_: <karolherbst🐧🦀> @marysaka are the shader header changes extractable from your nak maxwell support stuff?
17:02fdobridge_: <karolherbst🐧🦀> would be a good idea to land those independently as volta needs it 🙂
17:02fdobridge_: <marysaka> didn't Faith merged the branch in main now?
17:02fdobridge_: <karolherbst🐧🦀> ohh..
17:02fdobridge_: <marysaka> but I don't think I have any specific changes for Maxwell on SPH :aki_thonk:
17:02fdobridge_: <karolherbst🐧🦀> maybe I need to rebase faiths volta branch then
17:02fdobridge_: <karolherbst🐧🦀> size and offset
17:02fdobridge_: <karolherbst🐧🦀> the shader instructions need to be aligned, not the header 🙂
17:03fdobridge_: <karolherbst🐧🦀> uhhh.. I have to disable clippy with nak :blobcatnotlikethis:
17:05fdobridge_: <!DodoNVK (she) 🇱🇹> gamescope needs the KHR_present_id/wait stuff (this should be easy but requires adding DRI option support)
17:07fdobridge_: <!DodoNVK (she) 🇱🇹> :cursedgears:
17:07fdobridge_: <!DodoNVK (she) 🇱🇹> https://cdn.discordapp.com/attachments/1034184951790305330/1183454980414382202/Screenshot_20231210_190623.png?ex=65886556&is=6575f056&hm=4d353424071d0a519d9f594b38b996b0e1b05fcc3a823a3167495bd2feb1d3e4&
17:07fdobridge_: <karolherbst🐧🦀> @marysaka but yeah.. it's in main 🙂
17:08fdobridge_: <esdrastarsis> @prop_energy_ball
17:09fdobridge_: <prop_energy_ball> well that's in common code
17:09fdobridge_: <prop_energy_ball> you just need plasma 6 etc
17:09fdobridge_: <prop_energy_ball> you just need plasma 6 for that (edited)
17:10fdobridge_: <!DodoNVK (she) 🇱🇹> I'm on Plasma 5
17:11Lyude: karolherbst: i can look into it, not super surprised
17:12Lyude: really few people have access to gv100
17:12Lyude: or at least ones who would run nouveau on a desktop :P
17:15karolherbst: :D
17:26fdobridge_: <prop_energy_ball> probably needs some stuff for foreign queue transitions or whatever
17:26fdobridge_: <prop_energy_ball> although that looks suspiciously linear
17:26fdobridge_: <prop_energy_ball> so perhaps modifiers arent hooked up too?
17:27fdobridge_: <gfxstrand> I don't think much actually changes there. Just the version. All the stuff after 0x50 should be zero pre-Turing anyway. It's just used for barycentrics and stuff like that.
17:28fdobridge_: <karolherbst🐧🦀> it's needed for proper alignment of the shader
17:28fdobridge_: <karolherbst🐧🦀> but yeah...
17:28fdobridge_: <karolherbst🐧🦀> I rebased your branch on main and will go from there
17:32fdobridge_: <karolherbst🐧🦀> mhh now I'm getting ILLEGAL_INSTR_ENCODING: ')
17:33fdobridge_: <!DodoNVK (she) 🇱🇹> NVK doesn't really use the NVIDIA-specific modifiers (and they can't be used anyway in PRIME setups)
17:33fdobridge_: <karolherbst🐧🦀> @gfxstrand what env vars do I have for debugging?
17:34fdobridge_: <karolherbst🐧🦀> (and could somebody document them inside `envvars.rst`
17:34fdobridge_: <karolherbst🐧🦀> )
17:34fdobridge_: <gfxstrand> `NAK_DEBUG=print`
17:35fdobridge_: <gfxstrand> There's also `serialize` but I don't think that changed between Volta and Turing.
17:37fdobridge_: <!DodoNVK (she) 🇱🇹> If I use my AMD GPU to run gamescope and NVIDIA GPU to run vkcube then vkcube looks fine
17:37fdobridge_: <gfxstrand> Yeah, I have a very old branch for modifiers. @mohamexiety is going to work on it after he gets sparse working.
17:37fdobridge_: <prop_energy_ball> cool
17:38fdobridge_: <gfxstrand> I think I already got most of the typing but it's been a bit since I've looked at the branch. The big hole is render to linear.
17:38fdobridge_: <prop_energy_ball> When you get modifiers + foreign queue working properly you will have officially beaten the NVIDIA driver in terms of being able to actually run SteamOS
17:38fdobridge_: <prop_energy_ball> which is kinda depressing
17:39fdobridge_: <karolherbst🐧🦀> yeah... it's the header :ferrisUpsideDown:
17:39fdobridge_: <mohamexiety> is it a matter of the hardware not playing well with that stuff, or is it that they simply don't care?
17:39fdobridge_: <prop_energy_ball> Maybe I should peep at HDR signalling for nouveau if it isn't already done
17:39fdobridge_: <gfxstrand> I'm hopeful that having NVK be competent will finally let the lookout graphics stack move forward easier. Even though I'm sure NVIDIA will try to hold on to their blob, NVK is going to give us a hell of a lot more leverage.
17:39fdobridge_: <prop_energy_ball> There are bugs and I am guessing they are low priority
17:40fdobridge_: <gfxstrand> I'm hopeful that having NVK be competent will finally let the Linux graphics stack move forward easier. Even though I'm sure NVIDIA will try to hold on to their blob, NVK is going to give us a hell of a lot more leverage. (edited)
17:40fdobridge_: <prop_energy_ball> My last email said they fixed stuff in the latest Vulkan dev driver, but the foreign queue transition stuff still seems broken
17:40fdobridge_: <prop_energy_ball> (to be clear foreign queue transitions are only broken on async compute queues on the blob driver)
17:41fdobridge_: <!DodoNVK (she) 🇱🇹> I wonder if we can beat them at CUDA too
17:42fdobridge_: <gfxstrand> Like, distro can reasonably say, "Yeah, we're going to ship $FEATURE" without really worrying about breaking shit for NVIDIA blob users. Suddenly it becomes NVIDIA's problem to support all the things, not our problem to work around them.
17:42fdobridge_: <karolherbst🐧🦀> `nvdisasm error : Unrecognized operation for functional unit 'uC' at address 0x00000110` pain
17:42fdobridge_: <karolherbst🐧🦀> `IMNMX.U32 R8, R1, 0xffff, PT ;` 😄
17:42fdobridge_: <karolherbst🐧🦀> okay
17:42fdobridge_: <karolherbst🐧🦀> yeah soo the rebase actually fixed that
17:42fdobridge_: <karolherbst🐧🦀> just need to lower min/max
17:43fdobridge_: <gfxstrand> That'll do it. 😂 There might be NIR lowering or you can just emit the two instructions.
17:43fdobridge_: <mohamexiety> yup. and NVK working well would take most gamers away from the blob anyways
17:43fdobridge_: <karolherbst🐧🦀> yeah, I'll see what we can do
17:43fdobridge_: <karolherbst🐧🦀> but yeah.. the rebase fixed the header being too big issue or something
17:44fdobridge_: <karolherbst🐧🦀> there is `FMNMX` 🥲
17:45fdobridge_: <prop_energy_ball> I wonder how much adjustment the vblankmanager in Gamescope is going to need to work on nouveau nicely
17:45fdobridge_: <gfxstrand> Of course, that assumes that NVK is competent. If games are still 2x as fast on the blob, people will still use it. 🫤
17:45fdobridge_: <prop_energy_ball> AMDGPU needs a scary amount of redzone
17:46fdobridge_: <prop_energy_ball> So if nouveau ends up needing more that'd be scary 🐸
17:46fdobridge_: <gfxstrand> To be fair, that one is more instructions to emulate.
17:46fdobridge_: <prop_energy_ball> So if nouveau ends up needing more that'd be scary 🐸 But I have not tested (edited)
17:46fdobridge_: <karolherbst🐧🦀> yeah..
17:46fdobridge_: <gfxstrand> Only one more instruction but still
17:46fdobridge_: <karolherbst🐧🦀> sooo uhm... does anybody else needs imin/imax lowering?
17:47fdobridge_: <karolherbst🐧🦀> 😄
17:47fdobridge_: <karolherbst🐧🦀> *need
17:47fdobridge_: <karolherbst🐧🦀> intel has it in the backend...
17:49fdobridge_: <karolherbst🐧🦀> ohh bifrost as a nir_lower_algebraic thing for it
17:49fdobridge_: <karolherbst🐧🦀> *has
17:49fdobridge_: <karolherbst🐧🦀> (for 8 bit)
17:50fdobridge_: <karolherbst🐧🦀> @gfxstrand mind if we add a nak specific lower algebric thing or do you want this into global nir straight away?
17:50fdobridge_: <karolherbst🐧🦀> or lowering inside nak?
17:51fdobridge_: <gfxstrand> We should probably have a nak-specific algebraic thing. You can move the fmul needed by sin/cos to it while you're at it.
17:51fdobridge_: <karolherbst🐧🦀> okay
17:52fdobridge_: <gfxstrand> IDK if we can plumb the nak_shader into it, though. 🤔
17:53fdobridge_: <gfxstrand> For now you might need to have it generate a volta-specific pass for immmx. 🙃
17:53fdobridge_: <gfxstrand> But that's easy
17:53fdobridge_: <karolherbst🐧🦀> I was thinking of passing the sm as an option
17:54fdobridge_: <karolherbst🐧🦀> or a custom struct
17:54fdobridge_: <karolherbst🐧🦀> depending on if we want the logic to be inside the lowering pass or whoever calls it
17:54fdobridge_: <gfxstrand> I don't remember what plumbing we have for that. I'd be open to adding a thing to let backends pass extra parameters if we don't already.
17:55fdobridge_: <karolherbst🐧🦀> mhhh... good question..
17:55fdobridge_: <karolherbst🐧🦀> yeah.. there isn't, but that should be trivial to add
17:55fdobridge_: <gfxstrand> It looks like there is no such thing but it'd be really easy to add
17:55fdobridge_: <karolherbst🐧🦀> :ferrisUpsideDown:
17:56HdkR: Annoy open source driver developers by deleating this one simple instruction :)
17:56fdobridge_: <gfxstrand> Just make it default to `[]` or something so we don't have to change everything everywhere.
17:56fdobridge_: <karolherbst🐧🦀> yeah
17:57fdobridge_: <gfxstrand> And then pass a `const struct nak_compiler *nak`
17:57fdobridge_: <karolherbst🐧🦀> but honestly, which other vendor changes their ISA 7 times :ferrisUpsideDown:
17:57fdobridge_: <gfxstrand> Have you seen Intel?
17:57fdobridge_: <gfxstrand> Or Arm?
17:57fdobridge_: <karolherbst🐧🦀> I meant like complete new encodings
17:57fdobridge_: <gfxstrand> Have you seen Intel? Or Arm?
17:57fdobridge_: <karolherbst🐧🦀> tehcnically nvidia has like 30 isas
17:57fdobridge_: <karolherbst🐧🦀> (versions)
17:58fdobridge_: <gfxstrand> Intel has totally changed encodings 4 or 5 times and that doesn't count vec4.
17:58fdobridge_: <karolherbst🐧🦀> yeah, nvidia did it more often 😄
17:58fdobridge_: <karolherbst🐧🦀> but fair
17:58fdobridge_: <gfxstrand> And every version has new region restrictions, often backwards-incompatible, and sometimes varying by SKU.
17:58fdobridge_: <karolherbst🐧🦀> though the ISA kinda stayed similar enough
17:59fdobridge_: <gfxstrand> Trust me, NVIDIA is a nice ISA.
17:59fdobridge_: <karolherbst🐧🦀> 😄
17:59fdobridge_: <karolherbst🐧🦀> fair enough
17:59fdobridge_: <gfxstrand> Panfrost has 4 compilers and that's just for like 5 hardware versions.
18:00fdobridge_: <gfxstrand> Not 4 different encoding back-ends. 4 different compilers.
18:00HdkR: Just don't look at the old NVIDIA ISAs :D
18:00fdobridge_: <gfxstrand> Oh, I'm sure I don't want to look at anything from the GT 7000 days
18:01fdobridge_: <!DodoNVK (she) 🇱🇹> :triangle_nvk:
18:01fdobridge_: <!DodoNVK (she) 🇱🇹> https://cdn.discordapp.com/attachments/1034184951790305330/1183468537122132150/Screenshot_20231210_195950.png?ex=658871f7&is=6575fcf7&hm=5365753495d0db3bac598ee5a4488af1c63216a9551acb67593989125182f651&
18:04HdkR: Only ever look at Maxwell and newer and it'll be smooth sailing
18:06fdobridge_: <karolherbst🐧🦀> pain
18:06fdobridge_: <karolherbst🐧🦀> yeah soo.. we have two compilers :ferrisUpsideDown:
18:06fdobridge_: <karolherbst🐧🦀> one pre nv50 and one nv50+
18:06fdobridge_: <karolherbst🐧🦀> it was uhhh.. a vec ISA obviously
18:06fdobridge_: <karolherbst🐧🦀> however
18:07fdobridge_: <karolherbst🐧🦀> nvidia going fully scalar in 2006 was kinda ground breaking for the time 😄
18:10fdobridge_: <karolherbst🐧🦀> mhhhh
18:11fdobridge_: <!DodoNVK (she) 🇱🇹> So was my 9500 GT futuristic?
18:11fdobridge_: <butterflies> CUDA 0.7 public beta
18:12fdobridge_: <butterflies> early CUDA also had an interpreter publicly shipped with it
18:12fdobridge_: <butterflies> so you didn't have to have a GPU to prototype programs
18:12fdobridge_: <butterflies> NVIDIA got rid of that quite quickly though
18:13fdobridge_: <karolherbst🐧🦀> NOOOOO
18:13fdobridge_: <karolherbst🐧🦀> god dammit
18:14fdobridge_: <karolherbst🐧🦀> I have to make a late algebraic lowering pass...
18:14fdobridge_: <karolherbst🐧🦀> what a pain
18:15fdobridge_: <karolherbst🐧🦀> opt_algebraic reverted my totally working imin/imax lowering 🥲
18:16fdobridge_: <karolherbst🐧🦀> `Pass (Pass)` :3
18:16fdobridge_: <karolherbst🐧🦀> let's gooo!
18:19fdobridge_: <karolherbst🐧🦀> `Pass: 176, Fail: 52, Crash: 93, Skip: 1679, Duration: 2:09, Remaining: 71:48:20` mhh
18:19fdobridge_: <karolherbst🐧🦀> @gfxstrand running into `ALU srcs must be legalized explicitly` a lot
18:21fdobridge_: <gfxstrand> There's probably something that's not getting lowered. What op is triggering it?
18:24fdobridge_: <karolherbst🐧🦀> gdb is crashing 🥲
18:24fdobridge_: <karolherbst🐧🦀> imul, but: https://gist.github.com/karolherbst/888dd576a11a3f64e0e92fe856a23826
18:27fdobridge_: <karolherbst🐧🦀> mhh actually...
18:27fdobridge_: <karolherbst🐧🦀> shouldn't that have become imad?
18:29fdobridge_: <karolherbst🐧🦀> ohh yeah
18:29fdobridge_: <karolherbst🐧🦀> 😄
18:30fdobridge_: <karolherbst🐧🦀> `if self.sm() > 70 {`
18:30fdobridge_: <karolherbst🐧🦀> 🥲
18:32fdobridge_: <karolherbst🐧🦀> okay,.. that's better 😄
18:33fdobridge_: <karolherbst🐧🦀> I think I'm ready for a proper CTS run now
18:35fdobridge_: <karolherbst🐧🦀> still getting tons of `OOR_REG`... mhh
18:35fdobridge_: <karolherbst🐧🦀> maybe compute is busted
18:37fdobridge_: <karolherbst🐧🦀> `Pass: 142, Fail: 68, Crash: 23, Skip: 1266, Flake: 1, Duration: 5:14, Remaining: 232:00:04`
18:38fdobridge_: <karolherbst🐧🦀> yeah.. compute is broken
18:38fdobridge_: <karolherbst🐧🦀> that has to wait until after dinner
19:01fdobridge_: <airlied> Lyude: I gave Ajax a Volta, you might need to get it off him
19:15RedSheep: I am not sure I'm in the right place, but I have been testing my 4090 with kernel 6.7rc4 to see what is left for me to be able to daily drive the open source drivers now that GSP firmware is a thing, and I haven't had any luck getting it to run my displays at 4k120. I am able to run 120hz on AMD and the nvidia blob, but I'm not sure if that rules out my distro or DE being at fault.
19:16RedSheep: What should I check, or where should I open an issue, if that would make sense to do?
19:26fdobridge_: <karolherbst🐧🦀> mhhhh
19:26fdobridge_: <karolherbst🐧🦀> the shader uses r16 at most, but setting 17 regs does't work.. but 18 does
19:31fdobridge_: <karolherbst🐧🦀> now we are talking...
19:31fdobridge_: <karolherbst🐧🦀> @gfxstrand `Pass: 388, Crash: 7, Skip: 2105, Duration: 13, Remaining: 5:59:40` and the crash is the indirect compute assert
19:33fdobridge_: <karolherbst🐧🦀> `Pass: 5303, Crash: 97, Skip: 29600, Duration: 2:14, Remaining: 4:12:19` and dmesg is still clean
19:34fdobridge_: <karolherbst🐧🦀> maybe I should run with more threads than just with 4? 😄
19:34fdobridge_: <gfxstrand> Volta probably needs the +2 as well. It doesn't have UGPRs AFAIK but it may still reserve them.
19:35fdobridge_: <gfxstrand> Or maybe it has them. 🤷🏻♀️
19:35fdobridge_: <karolherbst🐧🦀> yeah, that's what I decided to do
19:35fdobridge_: <karolherbst🐧🦀> and is also what we do in gallium
19:35fdobridge_: <karolherbst🐧🦀> anyway.. the only thing left seems to be indirect dispatch
19:36diagonal3x: So that example should work so: you add biggest power to value and it's inverse, so that one busts, removing the power again from both results and summing together guarantees a range half of max to max -1 , so in other words removing that biggest power once more, you know that inverse is larger, and can use subtract to subtract a constant to later compensate after stashing this to value, but this gets you the smaller value always which can
19:36diagonal3x: be focal value or inverse, now final riddle is to understand which one it was
19:36fdobridge_: <karolherbst🐧🦀> let's toast this GPU
19:36fdobridge_: <karolherbst🐧🦀> 20 threads lets go
19:37fdobridge_: <karolherbst🐧🦀> not a lot faster `Pass: 5066, Crash: 90, Skip: 28344, Duration: 59, Remaining: 1:56:55` 😄
19:41fdobridge_: <karolherbst🐧🦀> kinda pain volta uses the old macro stuff :ferrisUpsideDown:
19:42fdobridge_: <karolherbst🐧🦀> @gfxstrand what's the problem with indirect compute pre turing? just the macro running out of regs or the mme being less capable?
19:43fdobridge_: <gfxstrand> The MME can't multiply so we can't get the counters right.
19:43fdobridge_: <karolherbst🐧🦀> oof
19:44fdobridge_: <gfxstrand> IDK how NVIDIA does it
19:44fdobridge_: <karolherbst🐧🦀> I'd say we should get the counters wrong and still do indirects :ferrisUpsideDown:
19:44fdobridge_: <gfxstrand> Maybe repeated add?
19:44fdobridge_: <karolherbst🐧🦀> mhhhhhh
19:44fdobridge_: <gfxstrand> Yeah, that's probably fine for now
19:45fdobridge_: <karolherbst🐧🦀> yeah.. at least we test indirects this way
19:46fdobridge_: <gfxstrand> The other thing I've considered is sticking an atomic at the start of the shader that increments a bit of memory.
19:53fdobridge_: <gfxstrand> Or just fire off a compute shader that preprocesses the indirect draw buffer and do it in a shader.
19:54fdobridge_: <karolherbst🐧🦀> mhhh... maybe @marysaka could dump what nvidia is doing and take a look?
19:55fdobridge_: <karolherbst🐧🦀> `Pass: 117516, Fail: 9, Crash: 1872, Warn: 1, Skip: 653102, Duration: 19:15, Remaining: 1:20:09` btw
20:22fdobridge_: <marysaka> there is an MR opened by @lucidawnamberaeonjaharmonia I think
20:23fdobridge_: <marysaka> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26230
21:08diagonal2x: from that point the solution is easy, you had the value before inverting, you subtract from that (the number you know that came larger) and earlier you added 1, 1 is mapped to answer smaller all other values are mapped for bigger, so that one got solved , and now if all modules get combined there is an engine of super execution. So no sign, no wrap around, no control flow, no over/under flow handling, and only sub/add its still able to
21:08diagonal2x: compress everything.
21:19fdobridge_: <phomes_> the patch with HOST_CACHED_BIT lets X4 Foundations start and shows the intro. It initially shows a garbled image and crashes quickly after the intro, but at least it starts now
21:19fdobridge_: <phomes_> https://cdn.discordapp.com/attachments/1034184951790305330/1183518482336333824/Screenshot_from_2023-12-10_22-13-26.png?ex=6588a07a&is=65762b7a&hm=502663bfc857e2378c4ea0cd22737bd00b96e6e366f81e087eb88bfafbd48d04&
21:48fdobridge_: <karolherbst🐧🦀> run is almost done: `Pass: 557801, Fail: 45, Crash: 9090, Warn: 4, Skip: 3112051, Timeout: 1, Flake: 8, Duration: 1:33:14, Remaining: 7:51` :ferrisBongo:
21:52fdobridge_: <karolherbst🐧🦀> oh no...
21:52fdobridge_: <karolherbst🐧🦀> the GPU died...
21:55fdobridge_: <karolherbst🐧🦀> mhhh
21:55fdobridge_: <karolherbst🐧🦀> or rather something dead-locked
21:55fdobridge_: <karolherbst🐧🦀> well.. the GPU is also toast
22:27fdobridge_: <karolherbst🐧🦀> @gfxstrand pushed my changes to the nouveau branch and I think the code is more or less ready to be reviewed. I'll try to figure out the remaining issues over the next week
22:28fdobridge_: <karolherbst🐧🦀> the optional params to nir_algebraic wasn't even painful
22:59fdobridge_: <esdrastarsis> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26626
22:59fdobridge_: <esdrastarsis> moar perf
22:59fdobridge_: <karolherbst🐧🦀> yo
23:00fdobridge_: <karolherbst🐧🦀> maybe 32 is a bit too aggressive, but okay 🙂
23:08fdobridge_: <mhenning> Oh, I just picked 32 because it seems like the most common value other drivers use for max_unroll_iterations
23:08fdobridge_: <mhenning> I don't actually have an opinion there - we could set it lower if you think it's justified
23:08fdobridge_: <karolherbst🐧🦀> ohh no, it's fine I think...
23:09fdobridge_: <karolherbst🐧🦀> that reminds me... nak misses an important optimization :ferrisUpsideDown:
23:09fdobridge_: <karolherbst🐧🦀> lowering cfg to predication
23:09fdobridge_: <karolherbst🐧🦀> so instead of doing if/else branches, just predicate both sides
23:09fdobridge_: <karolherbst🐧🦀> or is nak already doing that?
23:09fdobridge_: <mhenning> it isn't doing that yet
23:10fdobridge_: <mhenning> At some point the sched code was a little sketchy for predicates but that might have been fixed
23:10fdobridge_: <karolherbst🐧🦀> I see
23:12fdobridge_: <mhenning> If you switch to predication, you presumably also don't want to emit reconvergence but we currently do that in nir so you'd either need to find and delete the reconvergence ops or find a way to avoid emitting them in the first place
23:12fdobridge_: <karolherbst🐧🦀> yeah.. that's the idea
23:13fdobridge_: <karolherbst🐧🦀> in codegen the pass flattening cfg kills the reconvergence ops
23:13fdobridge_: <mhenning> Yeah, I've seen that and I'm not the biggest fan of how it works out in terms of tracking down the ops to delete
23:14fdobridge_: <karolherbst🐧🦀> 🙂
23:14fdobridge_: <karolherbst🐧🦀> yeah.. same
23:14fdobridge_: <karolherbst🐧🦀> I think all those opts should happen first
23:14fdobridge_: <karolherbst🐧🦀> then we decide if reconvergence is needed and where
23:14fdobridge_: <karolherbst🐧🦀> we also don't always have to reconvergence anyway
23:16fdobridge_: <mhenning> Yeah, the pass for inserting them is already reasonably smart, just imo it should happen later than it currently does
23:21fdobridge_: <karolherbst🐧🦀> Num GPRs: 4 *doubt*
23:21fdobridge_: <karolherbst🐧🦀> https://gist.githubusercontent.com/karolherbst/eee3d0f37bc2e695d2b52a9cffbf54ee/raw/1aadc0524fb8914632399b15ef3204f7855976d8/gistfile1.txt
23:22fdobridge_: <karolherbst🐧🦀> ohh wait...
23:22fdobridge_: <karolherbst🐧🦀> I forgot to do something
23:25fdobridge_: <karolherbst🐧🦀> found it
23:32fdobridge_: <karolherbst🐧🦀> anyway.. another run..
23:37fdobridge_: <gfxstrand> Yeah, I've been meaning to do that. 😅 Last I checked it failed some CTS tests.
23:37fdobridge_: <gfxstrand> They might be fixed by https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26526 but I haven't gotten around to checking.
23:38fdobridge_: <gfxstrand> Should be fixable
23:39fdobridge_: <karolherbst🐧🦀> @gfxstrand soo.. volta hits all those vertex robustness issues 🥲
23:39fdobridge_: <karolherbst🐧🦀> or was it vertex buffer?
23:39fdobridge_: <gfxstrand> Oh fun...
23:39fdobridge_: <karolherbst🐧🦀> like the thing....
23:39fdobridge_: <mhenning> There's another patch in that MR that fixes the test failures
23:39fdobridge_: <gfxstrand> Oh, cool
23:39fdobridge_: <karolherbst🐧🦀> anyway... I forgot to reduce the gprs from 255 to 253 for volta 🥲
23:39fdobridge_: <karolherbst🐧🦀> nak might want to make sure that stuff doesn't overflow
23:40fdobridge_: <gfxstrand> Oh drp... Texture indices.
23:41fdobridge_: <gfxstrand> NIR doesn't know that NV clamps.
23:41fdobridge_: <karolherbst🐧🦀> `max(4, s.info.num_gprs + 2)` where `num_gprs` was 255, so that wrapped to 4
23:41fdobridge_: <gfxstrand> I've been meaning to wire up the conversation intrinsic we made for CL. That would let us communicate that.
23:41fdobridge_: <karolherbst🐧🦀> do we have a good plan on how to handle those kinda fails if `checked_add` is used as it returns `Option`?
23:41fdobridge_: <karolherbst🐧🦀> ohh yeah.. big mood
23:43fdobridge_: <mhenning> Oh, is there already an intrinsic? I looked for something in the algebraic ops and didn't see what we needed
23:44fdobridge_: <gfxstrand> Yeah, there's an intrinsic that has all the bells and whistles. I think we can implement basically all of it in hardware.
23:44fdobridge_: <gfxstrand> I just haven't wired it up. GL and Vulkan don't generate it. Only OpenCL.
23:45fdobridge_: <karolherbst🐧🦀> well.. not all combinations, but yeah
23:45fdobridge_: <karolherbst🐧🦀> at least the rounding modes all exist
23:45fdobridge_: <karolherbst🐧🦀> sometimes the hw is a bit picky
23:47fdobridge_: <karolherbst🐧🦀> `Pass: 70840, Fail: 3, Crash: 1160, Skip: 394997, Duration: 14:35, Remaining: 1:50:05` okay that looks a bit more promising