00:22 keithboltzman: if the order reliability will succeed, than division by two is both data bank assembly and access time well avoidable. cause the division by two is just half the index of the access appended to double value and that subtracted from 128. for example 256-144=112/2=56 so 256-144-56=56 128-56=72, so on access there are two values fetched 72 and 27 aka 144 and 56 after access was successful,
00:22 keithboltzman: but i am not sure if the access order reliability succeeds. I am starting to fire up the compiler over long time, calculator age is over now.
04:09 QbY: Hey everyone, Apologies for the off-topic message, but this is critical. Please download and save a copy of https://Histwo.github.io/lostOne.txt. Emailing a copy to yourself or others will create timestamped proof that it was in the public domain before the event described within. This file helps expose a political conspiracy that has already taken far too many lives and is about to escalate on a massive scale. Every saved copy
04:09 QbY: matters. Please don’t ignore this—your action could help save thousands. I'm literally surrounded by cloaked (invisible) gov and CIA. They are actively killing any of my communications, served Microsoft with an NSL for my email. The NSA folks watching me, do not know what I'm using. So.... Please help me and Atlanta. Thank you.
06:02 llyyr: why does this channel attract so many people like this
06:03 airlied: one of the largest channels on oftc
09:25 K900: dcbaker have you had another chance to look at https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33890 ?
10:56 tarocards_for: seems my manic episodes are never ending, i would not be surprised if the order never works out, why would not anyone else expose more memory alike otherwise? The depchain earlier giving some success, i do not think it does anything to preserve the correct order of those elements, it would need more work which might as well fail altogether in the end. I am doing stupid things.
11:42 ircusernine: i filtered out that only two solutions were ever doing something. nannybusiness and tramandtroll in logs, i lost my energy to test them for bigger order preserving sequences.
12:26 nandersalis: I do not understand how to get more indexes without stretching the base very high, and hence have way higher inputs without collisions. so indexes start to go tremendously big going towards the max mem location storage capacity aka word length. One way is to access in tiles but that would add latency. so you access several 115 indexes, but one has base slightly higher , which would
12:26 nandersalis: translate the index more to 116 instead, and next iteration you access 115 from the tile etc. It's getting too complex, i will lose the battle on data compression i think, but i am getting some momentum, as i have more money to use next months.
15:00 accessgrantmeth: in calculator i got 64registers compressed into one memory location, rest of the testing needs to be compilation based, and the testing to stuff more into hash goes more complex.
15:01 accessgrantmeth: i just do not seem to understand how to address more yet entirely.
15:34 accessgrantmeth: but another way to think is when one has collision, it would be the same value anyhow that one gets (so it appears in case of tramandtroll), another view is how many accesses is wanted to be done, so all elements or one should be stable in very high compression rates, but anything in between might get anomalies., cause the order that they would appear needs handling. the obvious thing
15:34 accessgrantmeth: what most do is to keep some os like supporting structures per hash. so if you would access sequential the thing you already accessed might be removed, depending on what access pattern or methology you chose.
16:28 alyssa: hmm, so the v1 asahi uapi has a submit ioctl containing a command count and points to an array of command structs, and each command struct has a payload size and points to a payload
16:28 alyssa: wondering if it would make sense to flatten that?
16:28 alyssa: instead have submit point to a little "kernel command stream", where each command has a fixed size header followed by variable payload
16:29 alyssa: less pointer chasing (and just 1 big copy_from_user instead of N for N commands)
16:29 alyssa: although idk if it's precedented
16:46 pac85: Looking at your code it seems like you need to pass a lot more stuff to the kernel than other drivers so I guess it makes sense it needs unique design?
16:49 alyssa: pac85: Yep
16:50 alyssa: Imaginapple is uniquely annoying here
16:50 alyssa: and Apple doubly so because we don't control the firmware
16:50 alyssa: (Imagination made a bunch of firmware changes to hide this in their mainline uapi. their downstream one is similar to ours.)
16:50 alyssa: frankbinns: ^
16:50 alyssa: cc
16:51 pac85: Uhm wonder what IMG does upstream. Do they just not need all the info anymore?
16:54 alyssa: it's plumbed straight from userspace -> firmware
16:55 alyssa: which relies on a stable firmware abi
16:55 alyssa: which apple does not give us
16:56 pac85: uh I see makes sense, so kmd needs to hide the instability for asahi
16:56 alyssa: bingo
17:30 zmike: I've started working to flatten out pipe_surface pointers, in pipe_framebuffer_state and I'm starting to wonder whether this is actually feasible
17:30 zmike: it's a lot more work than I expected
17:48 mareko: oh definitely
17:49 alyssa: since when has zmike ever backed down from a challenge
17:51 zmike: sweatytowelguy
17:55 zmike: I got zink to build with it as a test
17:56 lampswitchedon: likely yeah i am severely ill in all ways, but this table i talked about which gives me results, nannybusiness gives similar results in shorter procedures, so this is tramandtroll that i paste here. 89+89+210-420=-32 -32+210+89+89=356 -32+210+89+89+210=566 566-356-356=-146 566-420=146
17:56 lampswitchedon: 89+89+210-210=178 178+89+89=356 178+89+210+89+210=776 776-356-356=64 420-64=356-89*4=0
17:56 lampswitchedon: 86+86+200-400=-28 -28+200+86+86=344 -28+200+200+86+86=544 544-344-344=-144 544-400=144
17:56 lampswitchedon: 86+86+200-200=172 172+86+86=344 172+86+200+86+200=744 744-344-344=56 400-56=344-86*4=0
17:56 zmike: it was non-trivial but I think maybe there's a path to getting everyone using the same basic formula
17:56 zmike: and then everyone can clean up their drivers from there to whatever is more optimal
17:59 alyssa: yay!
18:17 goldinpocketX: so how that get's to results 86 is index 120 so 136-61-61=14+max72 in pseudo, so 89 is similarly 115 so 141-62-62=17+72=89 so for 120 index 200, comes as 256-72+16 and for 210 for 115 as 256-72+26, and you start to piece and puzzle those into those procedures consistently, and gives back the filtered selection bitshifted by four places. 14 if 72 is removed and 17 if 72 is similarly
18:17 goldinpocketX: removed. so 61+61=122 which comes as 136-14 and 62+62=124 which comes as 141-17. now there is a need for more work to address deeper than some one bank.
19:08 protestenviron: now there are some combinations and we can get onto logics, if base is incrementing, the value max per bank is larger, hence the distance subtraced from max remains the same result, as before, however the 210 or 200 coeff would enlarge, which seems like perfect way of filtering, and if there is collision, that is going to be the very same value , there is some magic behind that
19:08 protestenviron: accidental fluke imo, it seems crazy efficient but requires a whole lot of testing yet more, maybe after years of testing we could release something but at the moment i can not guarantee anything, but would say it looks very interesting.
19:47 sumeriangod: yeah maybe both would rise, which is yet bit more logical as per example 115+72+257=444 514-444=70+257+115=885-768=117 70+72=142 4*257=1028-885=143-62-62=19 so 256-72+28=212 where 28 is 885+115=1000 1028-1000=28 but i do not understand why 257-230 now yields 27, some core programming issue, that next power is -1 of last so likely 27 is more correct so 256-72+27=211 whatever.
20:05 arkadiandevil: the whole point is that when some testing is yet landed it could address so much memory that it makes everyone sick at best :D. The procedure reminds hardware gates to some degree, and appears to take care of things by filtering some bitshifted cancel outs, which is why it might even be reliable to some degree.
20:07 arkadiandevil: but the operating system access methology read write, reindex, read sequential and all such patterns i do not know well, which is where some more knowledged person could help us by commenting on something.
20:16 airlied: zmike: I've tried that before and given up
20:16 airlied: that TODO in pipe_surface was written in simpler times :-)
20:16 zmike: airlied: which todo?
20:17 airlied: whatever the one that says width/height will go away
20:17 zmike: oh
20:17 zmike: I already did that though
20:17 airlied: yeah I know, now I'm worried :-)
20:17 zmike: that one wasn't too bad
20:19 airlied: I thought those were use for non-fb rendering or whatever that thing is called
20:20 zmike: near as I can tell they're mainly used for shortcutting having to manually call u_minify
20:21 airlied: ah GL_ARB_framebuffer_no_attachments stuff
20:21 airlied: but maybe not
20:21 zmike: ah
20:21 zmike: yeah no, not used for that at all
20:24 airlied: I assume you've ran this locally and resized a window a bunch of times :-)
20:24 airlied: because CI will not cover that I don't think
20:28 zmike: yeah seemed fine to me
20:28 zmike: there's no functional changes here
20:30 airlied: I just pointed out one actual functional change on the MR
20:32 airlied: otherwise it seems fine
20:33 zmike: hm
20:33 zmike: technically those checks were invalid anyway since it's legal for drivers to adjust for e.g., blocksize
20:34 zmike: this MR effectively says "geometry is not a property of pipe_surface"
20:34 zmike: so you create one surface for a resource on a given format/mip/layer and that's it
20:34 airlied: there are also cases in lavapipe that smell iffy
20:35 airlied: the surface w/h do not come from the resource
20:35 airlied: they come from the API
20:35 zmike: right, they're based on the additional params
20:36 airlied: I kinda feel adding the pipe_surface_sizes then adding a bunch of asserts all over first and seeing if something explodes might be a better way to stage this
20:36 airlied: I think a full VK CTS run might catch something on lvp
20:44 zmike: I'm skeptical of your skepticism considering those values aren't actually used, and the zink job would surely have failed if there was an issue with something as simple as framebuffer ops
20:45 zmike: but I'm also not planning to land it until later in the week, so there's ample time to test
20:47 realdroneoperator: I do not think anyone was ever having interest in what i tried to prove either. But if i follow the current memory management code correctly
20:48 airlied: zmike: at least remove all the dead code in lavapipe in the patch series so you can see the fallout
20:49 zmike: which dead code are you referring to
20:52 airlied: those functions that take width/height and do nothing with them
20:52 zmike: ah
20:53 zmike: well sure, I can delete some params
20:55 zmike: but you can see that llvmpipe never even used these struct members
20:55 zmike: mostly they just get pointlessly propagated
20:55 zmike: the real values are taken from the fb state
20:59 airlied: indeed maybe we just don't care what the frontend passes in (which is probably a bug somewhere)
21:04 airlied: I think u_blitter is where it matters if it does
21:04 zmike: there was one function there where I had to manually add width/height params
21:05 zmike: but otherwise it was the same
21:05 airlied: no where it matters that the values from the frontend are passed in
21:05 airlied: and they won't match the resource
21:05 zmike: right, I'm saying I had to manually pass values through
21:50 bestpeanutbutter: was that even consistent enough? mattst88: if you fire up a calclulator or some c/c++ code and get me some feedback on the thing or minor discussion about the procedures, I might and probably will leave from those channels. Though i am incredibly lonely and need to talk or write to avoid going around the country to start killing terrorists, but if i get some feedback that might help
21:50 bestpeanutbutter: me to stay quiet, so far out of series of hundreds of attempts 2methods have materialized and seem to be giving results, i got the nannybusiness method also to work. but those are the only ones, and i'd be shocked if someone found that those do not function like needed, cause all the series of proofs materialized into those, and i would currently bet theyd be a great start, but
21:50 bestpeanutbutter: indeed i have been so sick that maybe the chip deluded me out, but i hope not. I have not been able to find a mistake from those two.
23:14 ifeelunentire: now you want stupidest guy on earth to stay or what? Mood fluctuation, well there is easily spottable mistake in the table, you can not eliminate this way, i end up eliminating both that way or have unknown unmanageable value in the hash. I offered the my deal to matt. But there might be a way to cause a pure distance multiplies subtracted from values manipulated, so i remember it
23:14 ifeelunentire: should come out as 32 and 64, which yet more subtracted from 210 and 420 would yield twice and four times the stuff needed. But this is very likely called wavelet transform. And is probably known in the art, it's little bit similar to fourier transform.