00:06mohamexiety[d]: huh is this new? i just rebased on latest 6.18 tree
00:06mohamexiety[d]: make[3]: *** No rule to make target 'kernel.sbat', needed by 'arch/x86/boot/compressed/sbat.o'. Stop.
00:06mohamexiety[d]: make[3]: *** Waiting for unfinished jobs....
00:06mohamexiety[d]: `make clean` doesnt fix it
02:01zmike[d]: who knew deleting so much old code would move the industry forward
02:40sonicadvance1[d]: `+758 −1,446` old code removal wee
02:45gfxstrand[d]: Ah, the joy of building the CTS on a tiny arm SoC. The OOM killer...
02:52sonicadvance1[d]: Then you add a huge swap and watch it crawl with its even slower IO 😄
02:52gfxstrand[d]: Or I `ninja -j1` and go to bed.
06:53marysaka[d]: mhenning[d]: For your comment on tiled cache: it's all guessed but I'm 99% certain of the behaviors of each element I named based on my note from NVN and retesting I did last week-end (by tracing command buffers on Switch)
06:53marysaka[d]: For the case of `TILED_CACHE_INVALIDATE_TEXTURE_DATA_CACHE`, it is used in barriers when doing a barrier on tiles (`TILED_CACHE_BARRIER`) or fragment (`PIXEL_SHADER_BARRIER`) otherwise it will generate an `INVALIDATE_TEXTURE_DATA_CACHE_NO_WFI` for other "stages"
06:53marysaka[d]: There are also explicit discard of color and depth/stencil apis that generate `TILED_CACHE_DISCARD_SURFACE`, same goes for flush of tile cache `TILED_CACHE_FLUSH`
07:19marysaka[d]: (forgot to mention this is for a barrier on images otherwise it doesn't generate any invalidate tex data)
07:56monkey: say command (test all channels)
09:05jja2000[d]: steel01[d]: do you have a tree anywhere with your collection of Tegra related patches? It's kinda unclear to me what got merged and what didn't
11:28snowycoder[d]: mhenning[d]: gfxstrand[d] For discard-rects, what if instead of a custom macro that needs scratch memory we use SHADOW_RAM_CONTROL_MODE?
11:28snowycoder[d]: Using PASSTHROUGH and then REPLAY should disable DISCARD_RECTS only for clears, while re-using the old value after the clear is done
11:28snowycoder[d]: Could it work?
11:45gfxstrand[d]: Not sure. We need to understand it better.
12:47gfxstrand[d]: gfxstrand[d]: Yay! It built. Maybe tonight I can build it for 32-bit. :frog_upside_down:
12:51gfxstrand[d]: Test case 'dEQP-VK.api.smoke.triangle'..
12:51gfxstrand[d]: Pass (Rendering succeeded)
12:51gfxstrand[d]: DONE!
12:51gfxstrand[d]: Test run totals:
12:51gfxstrand[d]: Passed: 1/1 (100.0%)
12:51gfxstrand[d]: Failed: 0/1 (0.0%)
12:51gfxstrand[d]: Not supported: 0/1 (0.0%)
12:51gfxstrand[d]: Warnings: 0/1 (0.0%)
12:51gfxstrand[d]: Waived: 0/1 (0.0%)
12:53gfxstrand[d]: Building deqp-runner. Then I'm going to kick off a 10% run and see how bad this mess is.
12:55gfxstrand[d]: I know I screwed up at least some of it. I had to rebase across some pretty substantial driver changes.
12:58marysaka[d]: Still nice <a:vibrate:1066802555981672650>
13:09gfxstrand[d]: Okay. dEQP run started. Off to the office!
13:14jja2000[d]: Ohhhh good luck!
13:17gfxstrand[d]: `Pass: 1331, Fail: 4, Crash: 16, Skip: 1621, Timeout: 1, Flake: 27, Duration: 7:42, Remaining: 12:02:30`
13:17gfxstrand[d]: Not totally horrible so far
13:17gfxstrand[d]: Queries seem a bit busted but that's fixable.
13:22marysaka[d]: don't forget to turn off coredumps maybe just in case :maxpoeSweat:
13:53gfxstrand[d]: Ooh. Right!
13:53gfxstrand[d]: dEQP has a lot of core to dump. :blobcatnotlikethis:
15:24snowycoder[d]: marysaka[d]: envyhooks panics with the new nvidia drivers (580.95.05) on a cryptic error (no backtrace unfortunately)
15:24snowycoder[d]: thread 'blocking-2' panicked at library/std/src/sys/process/mod.rs:58:17:
15:24snowycoder[d]: called `Result::unwrap()` on an `Err` value: Os { code: 14, kind: Uncategorized, message: "Bad address" }
15:25marysaka[d]: snowycoder[d]: it was tested on 580.82.09 at max
15:25marysaka[d]: you might need to update the submodule for openrm and rebuild it
15:55mohamexiety[d]: it worked on my end for 580.95 fwiw
16:00snowycoder[d]: Huh, my system might be broken then
16:00mohamexiety[d]: did you update the submodule?
16:00snowycoder[d]: Yep
16:01mohamexiety[d]: maybe what i was looking at didnt touch the broken stuff then.. not sure
16:03marysaka[d]: what are you testing on btw?
16:03marysaka[d]: also maybe a debug only issue :aki_thonk:
16:04mhenning[d]: marysaka[d]: Yeah, I've been specifically trying to reverse engineer PIXEL_SHADER_BARRIER enough that we could use it in our pipeline barrier implementation. Unfortunately the proprietary driver's behavior is kind of bizarre so I'm having trouble figuring out the semantics
16:05mhenning[d]: Specifically, I'm seeing a NVB097_PIXEL_SHADER_BARRIER + mthd 0f74 for pipeline barriers src VK_PIPELINE_STAGE_2_COLOR_ATTACHMENT_OUTPUT_BIT -> dst VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT + VK_ACCESS_2_SHADER_STORAGE_READ_BIT which is why I suspect 0f74 also flushes globalmem
16:06mhenning[d]: Also, fwiw, I'm not sure if omitting `_NO_WFI` from the name of 0f74 is meant to signify that it does a WFI, but it definitely doesn't WFI in my testing
16:10marysaka[d]: mhenning[d]: I think we should figure out the driver key to completely disable tiled cache on NVIDIA blobs, I'm sure they have one...
16:10marysaka[d]: because the behavior with and without it might be completely different
16:10mhenning[d]: snowycoder[d]: Do you know what that does? I don't know what that does.
16:11snowycoder[d]: marysaka[d]: Mmmh, only my vulkan app has problems :/
16:11snowycoder[d]: Will debug
16:11marysaka[d]: snowycoder[d]: is it written in rust...?
16:11snowycoder[d]: marysaka[d]: Nope, c++ with vk-bootstrap
16:12marysaka[d]: okay so I can rule out conflict between two rust apps :maxpoeSweat:
16:14snowycoder[d]: mhenning[d]: I have some documentation that I extracted from Faith, Mary and Karol at the conference, we're not 100% sure though
16:16snowycoder[d]: marysaka[d]: Actually, it seems to have some dependency on glycin, a rust lib
16:17snowycoder[d]: vkcube works :/
16:17snowycoder[d]: Welp, I'm stealing another testbed
16:20jja2000[d]: gfxstrand[d]: Is there anything I need to try on GP10B? I may need to get a kernel going with all the loose patches steel01[d] made first.
16:21marysaka[d]: snowycoder[d]: just before that try to build envyhooks in release just in case
16:21marysaka[d]: marysaka[d]: https://github.com/Orbmu2k/nvidiaProfileInspector/blob/985af53a27d9c605b42459b8840ad8a7c824ee40/nspector/Reference.xml#L2013 I am going to poke this a bit
16:48steel01[d]: jja2000[d]: https://gitlab.incom.co/CM-Shield/android_device_nvidia_tegra-common/-/issues/33
16:48steel01[d]: I've been trying to keep this page up to date with what's merged and what isn't. I think it should be currently up to date. I don't have a mainline tree with everything though, no. Just an android gki 6.12 one. Which probably isn't what you want.
16:50gfxstrand[d]: jja2000[d]: That and my branch
16:51jja2000[d]: steel01[d]: A semi-updated list of ML threads is already extremely helpful. I've been holding off on fixing my Pixel C pmOS package because of lacking motivation (and the fact some important stuff, which I lack the knowledge to fix, was broken upstream anyway).
16:51jja2000[d]: gfxstrand[d]: Alright, I may or may not try some stuff on GM20B and GP10B between now and sunday.
17:21karolherbst[d]: nvidia uses `LDC.IL` for ptx `ld.const` 🥲
17:22karolherbst[d]: which is kinda interesting
17:22karolherbst[d]: oh that reminds me, I wanted to use ULDC for load_global_const...
17:27gfxstrand[d]: Interesting
17:33karolherbst[d]: mhhhhhh
17:33karolherbst[d]: it's even weirder
17:33karolherbst[d]: if the base comes from a ".ptr .const" kernel parameter it compiles to `LDC.IL`, but if it comes from a raw value, it ends up compiling to `LDC [0x3][...]`
17:35karolherbst[d]: I need to figure out const arguments properly at some point, but this is kinda cursed
17:36karolherbst[d]: but what makes me curious about this is, that there is no way in ptx then to have a "raw" pointer to constant memory...
18:36mhenning[d]: snowycoder[d]: fwiw, I suspect it would be easier to write an mme marcro, since the semantics of those are already pretty well understood
18:38snowycoder[d]: mhenning[d]: The macro should read if DR is enabled in shadow-mem, if there's a clear (from parameter?) and update the real mthd, right?
18:39snowycoder[d]: I didn't want to add any MME code in the fast-case (nobody uses DR from what I can see)
18:40mhenning[d]: Yeah, pretty much.
18:41snowycoder[d]: tbf, I wanted to write hardware tests for MME shadow-ram, so it would catch two birds with one stone.
18:41snowycoder[d]: But yeah, macro would be easier
18:41mhenning[d]: There's already an mme macro for clears so that could possibly even do the disable / enable around the clears
18:41snowycoder[d]: If I add it to that macro it would be executed even when discard-rectangles feature is disabled though
18:42mhenning[d]: Setting the DR state would become a macro call then to update scratch and emit the actual method
18:43mhenning[d]: snowycoder[d]: You can branch in the macro
18:43mhenning[d]: if scratch_dr_enabled {
18:43mhenning[d]: disable dr
18:43mhenning[d]: }
18:43mhenning[d]: clear
18:43mhenning[d]: if scratch_dr_enabled {
18:43mhenning[d]: enable dr
18:43mhenning[d]: }
18:44snowycoder[d]: I was worried about performance, the feature is nearly unused, I don't want to slow down clears just for that
18:45mhenning[d]: I don't think that the MME is typically a bottleneck but I don't know for sure
18:46snowycoder[d]: No idea either 🤷♂️
18:46snowycoder[d]: Let's go with that though
18:48snowycoder[d]: My idea with shadow-ram is:
18:48snowycoder[d]: PASSTHROUGH should write the mthd without writing the shadow counterpart.
18:48snowycoder[d]: REPLAY should write the method ignoring the parameter passed from CPU, using instead the parameter stored in the counterpart.
18:48snowycoder[d]: TRACK (the default?) writes the method and the counterpart.
18:48snowycoder[d]: So it should act as our shadow ram thingy, just built-in the hardware
18:49snowycoder[d]: I remember nvidia-proper playing with shadow-ram, but I lost the traces, I'm trying to have them again (and learn to properly read dumps in the meantime)
18:50mhenning[d]: Yeah, that sounds like it could work as long as we know that's actually how it works
18:51snowycoder[d]: We can optimize later, after we write the proper hw tests.
18:51snowycoder[d]: Thanks for the help!
19:38gfxstrand[d]: `Pass: 123450, Fail: 549, Crash: 1438, Skip: 155892, Timeout: 13, Flake: 2581, Duration: 4:42:14, Remaining: 0`
19:38gfxstrand[d]: That was 10% of the CTS, so 40h for a full run.
19:42steel01[d]: On gm20b?
19:42gfxstrand[d]: yup
19:43steel01[d]: That's a lot more passing that I would have hoped for on first run.
19:43gfxstrand[d]: We don't suck. :transtada128x128:
19:43snowycoder[d]: snowycoder[d]: ```
19:43snowycoder[d]: [0x0000003a] HDR 80020049 subch 0 IMMD
19:43snowycoder[d]: mthd 0124 NV9097_SET_MME_SHADOW_RAM_CONTROL
19:43snowycoder[d]: .MODE = METHOD_PASSTHROUGH
19:43snowycoder[d]: [0x0000003b] HDR 80000653 subch 0 IMMD
19:43snowycoder[d]: mthd 194c NV9097_SET_WINDOW_CLIP_ENABLE
19:43snowycoder[d]: .V = FALSE
19:43snowycoder[d]: [0x0000003c] HDR 800003ed subch 0 IMMD
19:43snowycoder[d]: mthd 0fb4 NVB197_SET_TIR
19:43snowycoder[d]: .MODE = DISABLED
19:43snowycoder[d]: [0x0000003d] HDR 80010049 subch 0 IMMD
19:43snowycoder[d]: mthd 0124 NV9097_SET_MME_SHADOW_RAM_CONTROL
19:43snowycoder[d]: .MODE = METHOD_TRACK_WITH_FILTER
19:43snowycoder[d]: [0x0000003e] HDR 20040360 subch 0 NINC
19:43snowycoder[d]: mthd 0d80 NV9097_SET_COLOR_CLEAR_VALUE(0)
19:43snowycoder[d]: .V = (0x0)
19:43snowycoder[d]: mthd 0d84 NV9097_SET_COLOR_CLEAR_VALUE(1)
19:43snowycoder[d]: .V = (0x0)
19:43snowycoder[d]: mthd 0d88 NV9097_SET_COLOR_CLEAR_VALUE(2)
19:43snowycoder[d]: .V = (0x0)
19:43snowycoder[d]: mthd 0d8c NV9097_SET_COLOR_CLEAR_VALUE(3)
19:43snowycoder[d]: .V = (0x3f800000)
19:43snowycoder[d]: [0x00000043] HDR 80000574 subch 0 IMMD
19:43snowycoder[d]: mthd 15d0 NV9097_SET_ANTI_ALIAS
19:43snowycoder[d]: .SAMPLES = MODE_1X1
19:43snowycoder[d]: [0x00000044] HDR 200101e9 subch 0 NINC
19:43snowycoder[d]: mthd 07a4 NVCE97_SET_COLOR_ZERO_BANDWIDTH_CLEAR
19:43snowycoder[d]: .SLOT_DISABLE_MASK = (0x0)
19:43snowycoder[d]: [0x00000046] HDR a0030e76 subch 0 1INC
19:43snowycoder[d]: mthd 39d8 NV9097_CALL_MME_MACRO(59)
19:43snowycoder[d]: .V = (0x3c)
19:44snowycoder[d]: mthd 39dc NV9097_CALL_MME_DATA(59)
19:44snowycoder[d]: .V = (0x0)
19:44snowycoder[d]: mthd 39dc NV9097_CALL_MME_DATA(59)
19:44snowycoder[d]: .V = (0x1)
19:44snowycoder[d]: [0x0000004a] HDR 800003e0 subch 0 IMMD
19:44snowycoder[d]: mthd 0f80 unknown method
19:44snowycoder[d]: .VALUE = 0x0
19:44snowycoder[d]: [0x0000004b] HDR 80030049 subch 0 IMMD
19:44snowycoder[d]: mthd 0124 NV9097_SET_MME_SHADOW_RAM_CONTROL
19:44snowycoder[d]: .MODE = METHOD_REPLAY
19:44snowycoder[d]: [0x0000004c] HDR 80000653 subch 0 IMMD
19:44snowycoder[d]: mthd 194c NV9097_SET_WINDOW_CLIP_ENABLE
19:44snowycoder[d]: .V = FALSE
19:44snowycoder[d]: [0x0000004d] HDR 800003ed subch 0 IMMD
19:44snowycoder[d]: mthd 0fb4 NVB197_SET_TIR
19:44snowycoder[d]: .MODE = DISABLED
19:44snowycoder[d]: [0x0000004e] HDR 80010049 subch 0 IMMD
19:44snowycoder[d]: mthd 0124 NV9097_SET_MME_SHADOW_RAM_CONTROL
19:44snowycoder[d]: .MODE = METHOD_TRACK_WITH_FILTER
19:44snowycoder[d]: AHAHAH YES!
19:44snowycoder[d]: nv-prop does exactly that.
19:44snowycoder[d]: also with a TIR (??)
19:44snowycoder[d]: gfxstrand[d]: What are the failing cases?
19:45gfxstrand[d]: I've got a whole folder of them
19:45gfxstrand[d]: Looks like a bunch of z/s tests and a bunch of XFB query tests
19:45gfxstrand[d]: Those are the big categories
19:45steel01[d]: The followup question is: do those also fail on the matching desktop arch?
19:45gfxstrand[d]: no
19:46gfxstrand[d]: desktop passes basically 100%
19:46steel01[d]: Oh, now that's... interesting.
20:08airlied[d]: queries failing usually sounds like a coherency issue
20:37gfxstrand[d]: It is
20:41gfxstrand[d]: According to Mary, coherent maps are just busted on nouveau
20:42gfxstrand[d]: NGL uses them but when we try from NVK, they blow up
20:44gfxstrand[d]: Okay, this is gonna suck but I think I have a plan
20:50airlied[d]: I spent a bit of timing trying to bring up GH100 before and got stuck in the whole coherency code and lost my way
21:13hiendrichkrauss: That is because you do not have solution to the topest of calculation and you are trying too heavy to get there, but i already have it makes you anxious even more if you comitted real crimes against me, which i do not know, but overall i think you are enough intelligent, and would wish you a great life otherwise, todays computers are overengineered but yet still tremendously capable,
21:13hiendrichkrauss: and to be fair and honest, since i used gnome-calculator which is nearly brilliant software to get to all of my breakthroughs and this connects to others code directly that i used to get there, cause let's be honest endless scrollable memory, you got to be really underdeveloped to not get there or occupied with too many other complex tasks, which is sad fact where my lines have started
21:13hiendrichkrauss: military actions against you for presenting your reverse psychology in the nature, but i can not save you cause it's not up to me anymore cause i can not save myself if i keep trolling you, and i can not tell the direct truth either that is too painful, if you could control with fear the comments and actions you land against me, so i do not have to present myself as handycap and mindill
21:13hiendrichkrauss: due to the fact that i do not want you get killed so bad, would take enourmous tragical burden off of my account, since i need to earn instead of saving your lives and i can not do that while playing a moran or acting as crazy idiot.
21:24jja2000[d]: Welcome back anonymous Markov Chain
21:27dwfreed: sadly, not Markov
21:51mickeygreinholt: Fraud prevention is a moral based military actions, and we are not talking about not releasing more powerful code, people suspect you are involved in tyranny and conspiracy against me, and masses with real indications based of my organs showing weird signs of interacting with tyran type of terror that persistently lands against a star resident on planet earth, my bones are pushing out
21:51mickeygreinholt: from weird junctions, my dick had started to shorten and such jokes, where as abortion leftovers in europe call me by names of wanker obnoxiously so i have not found a place to stay out or intact from their scams. If we elaborate using my genes and modifying my body against nature connects to you, whoch is obvious you are this year facing a battle that you can not win, since you chose
21:51mickeygreinholt: an incorrect guy who is the most abused god in the world. You end up getting killed off one after another one by one. There is a reason why most abused guy has gotten to 42years of age, cause i have lines too to tell that you lebesque integral is just a joke according to my standards as to how hard i work, and people gotta learn half of their lives to get to be so smart, and most of the
21:51mickeygreinholt: time i have had hard abuse so i did it all with half the time shorter cause i had that much less quality time due to your tyranny around my places, and this is true you ain't gonna survive our missiles.
21:51mickeygreinholt: I also think that general public should not get my code, and will not get it either.
21:54gfxstrand[d]: I love how he's always rambling about how none of us are good enough for his code. If only we wouldn't be good enough for his rants.
21:55mhenning[d]: For those of you with time for review, I'd like to land at least the first 4 or so commits of https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37671 before branchpoint on wednesday so review would be appreciated
21:57marysaka[d]: going to try to look at it more tomorrow
22:12airlied: just wish we had the github link to all the code
22:29madleengreen: I spent already 30minutes or more to tell you are not so dumb, i suspect as a programmer you have similar code to mine, how can you say so careless thing, do you classify or categorize yourself as general public, a toxic daemon or devil, just cause you are employed as top end programmer? Military has this code for years, cosmo scientists have powerful formulas , i have them too of
22:29madleengreen: course,so should you have it, but releasing that to wild animals classified as gray mass, narcissists, isn't just going to turn out well, which is where the key moments of my short maths is where i can not help the general public with, to let them have a power to finish me even better than the 50previous attempts where i survived, about you i do not know how you can bend my words so bad as
22:29madleengreen: to how gfxstrand did it again, but i meant absolutely different , i suppose you could have it if you have none yourself, but you can not realease it to the masses, it's not going to turn out well that way. I founded a company where i do projects where all those bits are defended very deeply, and can not be exposed through you to the general public, how hard is that to read? Just be serious
22:29madleengreen: stop with all the absurd you carelessly release, you seem like wearing a skirt, which is your business to do as born man, otherwise according to the cards, you should have the capability to be honest as well as restrictive but respect me as much as not to just release a total absurd at me everywhere. I said i am going to defend those bits well and i only said that FPGA's mass manufactured
22:29madleengreen: by US companies now merged with intel and amd would perform just that mad that they are meant to extinct human kind already.
22:29madleengreen: Those are so badass chips and work is few to get there, but they are also CGRA's or FPGAs or AI tensor cores generically easy to manufacture, but US has already done that, its mad what they are capable of doing too, the tech is so capable need minor modifications only , the security to fuzz out the projects code or mission such as powerplants code, is the most complex, it's just that
22:29madleengreen: general public can not have this as important measure to prevent chaos.
22:29madleengreen: Linux is best we have today and you are important programmers, how are you general public?
22:35gfxstrand[d]: Okay, I think I've got queries sorted.
22:36gfxstrand[d]: That was a bit of a mess.
22:36HdkR: \o/
22:36gfxstrand[d]: And requires us to use an entirely different query pool layout on tegra. :frog_upside_down:
22:37gfxstrand[d]: Kicking off another run and walking home
23:04karolherbst[d]: gfxstrand[d]: why did you wrote your own lowering for `inclusive_scan` in nak and not used `nir_lower_subgroups` for it? I don't really see an obvious difference in the code?
23:05gfxstrand[d]: Who wrote the lower_subgroups code and when?
23:05karolherbst[d]: Connor like 6 years ago
23:06karolherbst[d]: ehh
23:06karolherbst[d]: maybe not
23:06karolherbst[d]: ohh Alyssa copied your code and added it there like last year 🙃
23:07gfxstrand[d]: There's your reason. 😝
23:09gfxstrand[d]: Feel free to switch NAK over and test it.
23:10karolherbst[d]: I might need it but only the scan bits...
23:11karolherbst[d]: or maybe I also need the clustered reduce stuff...
23:13gfxstrand[d]: If you can trigger the NVIDIA implementation, it'll be ever so slightly better because they use some of the extra bits in shelf and predication. But it's like 10%.
23:13karolherbst[d]: yeah uhm.. how do I explain this, nvidia doesn't implement CL subgroups 🙃
23:14gfxstrand[d]: Well, no, but the whole point is to implement stuff Nvidia doesn't.
23:14karolherbst[d]: right
23:16mhenning[d]: gfxstrand[d]: yeah, using SHFL.BFLY and SHFL.UP in the nak implementation is on my todo list
23:17karolherbst[d]: ohh that reminds me
23:18mhenning[d]: karolherbst[d]: I'm pretty sure there's an implementation of equivalent functionality I was REing at some point. If it's not in PTX then it should be there in CUDA C++
23:19jja2000[d]: gfxstrand[d]: Very nice
23:20karolherbst[d]: mhenning[d]: yeah.. PTX only has the shfl and redux.sync stuff
23:20karolherbst[d]: and vote/ballot
23:20karolherbst[d]: mhh and match
23:21mhenning[d]: yeah, I think that makes it pretty close to the actual machine code then
23:22mhenning[d]: could probably share the code with NAK
23:24karolherbst[d]: wished I'd knew what inclusive and exclusive scan are supposed to be doing 🙃
23:25mhenning[d]: you mean what nvidia generates for it?
23:29karolherbst[d]: no, like what those ops are supposed to be doing anyway
23:30mhenning[d]: oh, there's docs, aren't there?
23:30mhenning[d]: inclusive/exclusive just toggles whether you include the current thread
23:32karolherbst[d]: right.. but then you also have redux which is doing the same?
23:32karolherbst[d]: *reduce
23:33karolherbst[d]: anyway, seems I pass the tests anyway
23:33mhenning[d]: grep for InclusiveScan in the spirv spec
23:33mhenning[d]: reduce returns the same value in all threads
23:34karolherbst[d]: ohh
23:35karolherbst[d]: anyway, the lowered code is a mess so I hope we can do better 😄
23:35mhenning[d]: yeah, we definitely can do a bit better
23:36mhenning[d]: although even nvidia can end up emitting sequences of ~10 instructions for some of those operations
23:36karolherbst[d]: ohh.. uhmm..
23:38gfxstrand[d]: `Pass: 47592, Fail: 51, Crash: 6, Skip: 57722, Flake: 129, Duration: 1:00:21, Remaining: 1:42:04`
23:38karolherbst[d]: I mean I'd be happy with 10 instructions atm 😄
23:38karolherbst[d]: `sub_group_broadcast(long)` *sigh*
23:38karolherbst[d]: how do I lowering those on 64 bit ints 😄
23:40mhenning[d]: I think there's common nir code that lowers the 64-bit ones?
23:40mhenning[d]: or at least, I don't think nak needs to handle that case.
23:41karolherbst[d]: ohh `nir_lower_bit_size` can do it
23:44karolherbst[d]: mhh
23:44karolherbst[d]: maybe it can only convert up...
23:45karolherbst[d]: ahh it's part of int64
23:57nicolosramsey: I came back to report my mistake on firmware bug designed cause of my spam directly targeting my computer, cause i finally after rolling back from original usb sticks understood that the design of macbook is special and one dislodged cable did all of those symptoms, i never seen such wiring before on mobo. but now my final text of today aboud windows kits. kvm vt-x emulation fine, xen
23:57nicolosramsey: fine paravirtual all good so far, mono i was stunned completely about how they got things so far that nuget just fetches all the libraries needed in csharp or visual c++ and in cambodia i built a whole os type of things from those libraries , then i started to fall under serious attacks, and this computer i no longer have, i did a lot of work there after what i am very confident but you
23:57nicolosramsey: talk about wine as addiction which is just suicidal, it's sea of bugs i suppose we could all fix in three years time anyone from here would be capable of that, but how stupid would that be, to spend that time when you already have all the previous which are all functional. You must be bored to do things like that and world state is dramatic you should find easier solutions during dense
23:57nicolosramsey: times, i am not sure what to make out of this, i never use wine and all usages have been so bad experiences. The code about apica i saw through before already back times, but i never implemented it, some slavic programmer did that, and do not do those things again like on osdev you start to rant about supremacy over eastern people, and expect after numbers of killings on their own
23:57nicolosramsey: previously taken territory things to turn out fine. The number of killed russians was so bad before the war ever started, and based of what you have done to russians or politicians or osdev residents, putin is not even outlaw or narcissist unfortunately.
23:58nicolosramsey: it was likely his hardest devision of his career to shake with mentally bad mood cause of the war that was just unavoidable.