00:27 snowycoder[d]: Gitlab is down, maybe tomorrow :/
01:10 lru: how do I convert kernel logs from a hang into useful knowledge?
01:13 lru: for example, a recent crash/hang started with this in the logs: https://pastebin.com/hGwN7yQu
01:19 gfxstrand[d]: snowycoder[d]: Oh, that's totally fine. I kinda figured you would. No need to have one commit per op.
01:30 lru: under drivers/gpu/drm/nouveau/nvkm/engine/ what does gr stand for?
01:33 gfxstrand[d]: lru: That actually already contains some good stuff. Looks like maybe a Tesla GPU?
01:34 gfxstrand[d]: Though that's a weird method/class to fail
01:34 lru: gfxstrand[d]: yeah, mine is a NVA8, GT218, in a Thinkpad T510
01:34 lru: it's not the only place to fail for me
01:35 lru: I have plenty of logs to share with anyone interested :-)
01:36 lru: I'm using it with the nouveau/nva8_fuc084 firmware loaded
01:36 gfxstrand[d]: File a bug and put what you know in it. That's a pretty old GPU but maybe someone can take a look one of these days.
01:37 lru: thanks!
01:38 lru: the Bugs.html page says to file 2D bugs differently than 3D... how do I know what mine is?
01:39 gfxstrand[d]: It's a 3D bug
01:39 gfxstrand[d]: Well... it's either 3D or kernel
01:39 gfxstrand[d]: Actually...
01:39 gfxstrand[d]: That GPU is old enough it might be 2D
01:40 lru: maybe file it under kernel drm/nouveau and hope?
01:40 gfxstrand[d]: File it as 3D for now and someone can move the bug if it's in the wrong spot. It's all on gitlab these days so we can move stuff pretty easily
01:40 gfxstrand[d]: That works too
01:40 lru: ok
01:40 lru: thanks
01:49 orowith2os[d]: the gt218 is 3d, I think
01:52 lru: odd thing is I'm not doing anything 3D that I know of....usually just hanging while using the firefox browser
01:53 lru: https://gitlab.freedesktop.org/ is timing out for me
01:59 orowith2os[d]: apparently gitlab is down, don't worry about it for now
01:59 orowith2os[d]: does it go wonky with wayland?
01:59 orowith2os[d]: what xorg ddx are you using?
02:07 lru: orowith2os[d]: I have not tried wayland yet... how do I find out the xorg info for you?
02:08 lru: I'm running Debian Bookworm
02:09 orowith2os[d]: list out the xorg drivers you have installed
02:09 orowith2os[d]: that should be enough
02:09 orowith2os[d]: it should be the modesetting driver
02:15 lru: looks likeI have them all installed, trying to figure out which one gets used
02:19 orowith2os[d]: just uninstall the nouveau and modesetting ones separately, the docs around the ddx stuff is annoying
02:19 orowith2os[d]: you might be able to find something in journalctl
02:20 lru: /var/log/X.org shows modesetting_drv.so loaded first,then fbdev_drv.so, then vesa_drv.so
02:21 orowith2os[d]: welp, that's a big womp
02:21 lru: modeset then sets up DRI2: DRI driver: nouveau, VDPAU driver: nouveau
02:30 pavlo_kozlenko[d]: https://discord.com/channels/1033216351990456371/1034184951790305330/1184266284121215088
02:31 pavlo_kozlenko[d]: I also have a freezes with the GT 240.
03:11 mangodev[d]: is it just me, or does firefox have a tendency to spontaneously combust on latest nvk?
03:12 mangodev[d]: usually happens when i scroll and multiple tabs are open
03:12 mangodev[d]: although that could just be sample bias because i don't often have just one tab open
03:13 mangodev[d]: but it definitely happens on scroll
03:13 mangodev[d]: and only sometimes
03:13 lru: mangodev[d]: I've noticed on Debian Bookworm on my old system, things tend to hang with firefox, yes
03:13 mangodev[d]: lru: mine's not a hang, it's an outright instant crash
03:13 mangodev[d]: and only on down scroll
03:13 lru: interesting
03:14 mangodev[d]: and happens more often with multiple tabs open
03:14 mangodev[d]: because when it has crashed, there's often 5+ tabs open, haven't had it crash with 1 or 2 open
03:14 lru: mangodev[d]: I've reported this a while ago: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1099740 but I don't know if it is just firefox, or some combination of kernel / X / Firefox factors
03:15 mangodev[d]: there's also the issue of discord's renderer regularly silent-crashing on nvk, there's some way that discord is using react that nvk doesn't like, seems unique to nvk because not even proprietary nvidia has the issue
03:16 mangodev[d]: i'm bringing up "the way that discord uses react" because it even happens on unofficial clients, so it's not the way that the official client uses electron
03:16 mangodev[d]: it doesn't happen on other electron apps, so it can't be electron (or at least it's not the sole problem)
03:17 mangodev[d]: seems to happen more frequently when webrtc is in use, although that could just be by coincedence
03:19 mangodev[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1363715839966056670/image.png?ex=68070ad8&is=6805b958&hm=6c84c7986e55365c580b63df08c0faa5182153b5d59a94c2836b66e05e1a9bef&
03:19 mangodev[d]: this is slightly concerning
03:21 mangodev[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1363716181164294154/image.png?ex=68070b2a&is=6805b9aa&hm=428068448c07165ea5304c094c608214c370e5c70b97980afdcd62eb3b239333&
03:21 mangodev[d]: mangodev[d]: this is the stack trace of the issue thread
03:23 mangodev[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1363716622367330587/image.png?ex=68070b93&is=6805ba13&hm=ea6f59bc9299bb6b8abe34dd673d09496373497d42324648a192638ae1798958&
03:23 mangodev[d]: this also isn't good
03:26 mangodev[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1363717378571112669/image.png?ex=68070c47&is=6805bac7&hm=53b74ad5760091991c7eefc2b076bd6316b017ce7c6aaaa7a9d835cf7b109037&
03:27 mangodev[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1363717674567467220/image.png?ex=68070c8e&is=6805bb0e&hm=887920dc99e60382e82f075a696f4539910d19aeb715cbff913ef506517dee61&
03:27 mangodev[d]: this may be useful as well
03:27 mangodev[d]: using an alt client due to screenshare crashes on official, but happens on official as well
03:29 mangodev[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1363718135055908925/image.png?ex=68070cfc&is=6805bb7c&hm=55b7a989505057e3c3029f7ff49b15d1b6c30e72f45012b6b6b4452795592f03&
03:29 mangodev[d]: mangodev[d]: uh oh
03:29 gfxstrand[d]: mangodev[d]: There's not a known issue with that, no. It seemed pretty stable last time I tried it.
03:30 mangodev[d]: gfxstrand[d]: i think https://discord.com/channels/1033216351990456371/1034184951790305330/1363718225229123624 should be the crash from firefox (the actual issue at least)
03:30 mangodev[d]: hard to tell because journalctl log doesn't have a ton of info about it
03:30 gfxstrand[d]: Is there something in dmesg? Crashing in the ioctl itself is weird.
03:33 gfxstrand[d]: This is all a little concerning because users are getting switched to Zink this release and I thought we had most of the kinks worked out. 😰
03:34 mangodev[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1363719391556145284/image.png?ex=68070e27&is=6805bca7&hm=c24267ae1298afd984737b93d70d85a7aa4dfd265053db0f48840667a78bb800&
03:34 mangodev[d]: gfxstrand[d]: well i found the electron crashes
03:34 gfxstrand[d]: mangodev[d]: Is that the stack trace for electron?
03:34 mangodev[d]: gfxstrand[d]: that's from dmesg
03:35 mangodev[d]: no other errors in dmesg 🙃
03:35 mangodev[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1363719826329047284/image.png?ex=68070e8f&is=6805bd0f&hm=58277dbed5f398176ea682a6ccd3d800a66bc33fdcbff9913eb52873a4d81b58&
03:35 mangodev[d]: other than this from boot, but i had this on official/proprietary as well
03:36 gfxstrand[d]: Yeah, so it's definitely a segfault. Can you get a stack trace? Preferably something with debug info so I can get a better sense of what's crashing?
03:37 mangodev[d]: gfxstrand[d]: how would i do that? firefox doesn't seem willing to snitch the crash reason so far
03:41 mangodev[d]: also weird question
03:41 mangodev[d]: is there a way to get a live-updating view of journalctl? currently, in order to see new logs, i have to run it again
03:42 matt_schwartz[d]: `-f`
03:46 mangodev[d]: okay, i'll try seeing what the kde failures are from
03:46 mangodev[d]: maybe it's from spectacle?
03:46 mangodev[d]: because spectacle is laggy as hell
03:48 mangodev[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1363722958484406302/image.png?ex=6807117a&is=6805bffa&hm=e63c5e7d052c393396940d72381cad0e6fe254f770c38e4c8dda8f69f8aeeca2&
03:48 mangodev[d]: nah, i don't see how that would cause constant lag
04:04 mangodev[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1363726969040142498/image.png?ex=68071536&is=6805c3b6&hm=a5740fdf54724da671d625b190683ab410ea4082f183676ba0623722f7f194ac&
04:04 mangodev[d]: hmmmmmm
04:04 mangodev[d]: seems to happen whenever i tab out of firefox for a bit and immediately start scrolling
04:04 mangodev[d]: is this a sign of some type of leak?
04:04 mangodev[d]: no this isn't a crash, but a stutter
04:08 mangodev[d]: gfxstrand[d]: wait
04:08 mangodev[d]: for the firefox crash or electron crash? that screenshot of the dmesg electron segfault, there's nothing for firefox in there
04:12 mangodev[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1363729202024808539/image.png?ex=6807174a&is=6805c5ca&hm=fa80b2c57c4aeefdfa71194a52306bbceca05c9e1022bed73079a0b63efb35ae&
04:12 mangodev[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1363729202343579648/image.png?ex=6807174a&is=6805c5ca&hm=fe0f9a44c9578d97b0c5d4de169d4051badace8c1a2502c88e2f785946cc459f&
04:12 mangodev[d]: got the crash
04:12 mangodev[d]: not very helpful though, no stack trace
04:14 mangodev[d]: wait a minute
04:14 mangodev[d]: gfxstrand[d]: here's the crash report, maybe this can help https://crash-stats.mozilla.org/report/index/87707f8d-76bc-430d-a397-b893d0250421
04:18 mangodev[d]: LMAOOOO
04:18 mangodev[d]: crashed when viewing the crash report
04:20 mangodev[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1363731107421360318/image.png?ex=68071910&is=6805c790&hm=0ebe2fc448496f62c326e053c4a381ec652c716b1b8654df8ad172703a9e5d59&
04:20 mangodev[d]: here's the crashing thread
04:22 mangodev[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1363731480857284710/image.png?ex=68071969&is=6805c7e9&hm=9defaa6900af8a84efcabca2669bca439bc635bc63f5502c09ba0091defecf67&
04:22 mangodev[d]: although this does seem to be reciprocated across other threads, but sometimes with a `cfi` trust value
04:28 gfxstrand[d]: Uh... That appears to be Zink on top of the proprietary driver
04:28 gfxstrand[d]: Wait no
04:29 gfxstrand[d]: They're basing that on the vendor ID not driver ID
04:30 gfxstrand[d]: Yeah, I didn't think that gives me enough information.
04:51 mangodev[d]: gfxstrand[d]: damn
04:51 mangodev[d]: idk how to get more information out of firefox, they're really secretive about crashes fsr
04:52 gfxstrand[d]: You can potentially run it with gdb and force the GPU to be in-process.
04:53 mangodev[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1363739277476888689/image.png?ex=680720ac&is=6805cf2c&hm=8e617703c501b5f3143e8ab157ce385a6bb23bf161698a2622ad26fe8668ed66&
04:53 mangodev[d]: are you kidding me mozilla
04:53 gfxstrand[d]: But I don't remember the flag for that off hand
04:53 mangodev[d]: gfxstrand[d]: maybe? haven't toyed with gdb before though (though it'd be very useful to learn how to use)
04:54 mangodev[d]: also update: zed works better than vscode on kde wayland nvk (who would've thought :P)
04:54 mangodev[d]: native vulkan will do that for you ig
04:56 mangodev[d]: works flawless, although i have a suspicion that the obscene lag on window resize is either an nvk or zink issue (as similar happens to *any* window when screensharing)
04:57 pavlo_kozlenko[d]: mangodev[d]: Why is he even touching vulkan?
04:57 mangodev[d]: pavlo_kozlenko[d]: i don't think it is (unless chromium/electron is doing so for it, iirc chromium has a vulkan renderer)
04:59 orowith2os[d]: pavlo_kozlenko[d]: they're not, zink is
05:00 orowith2os[d]: chromium shouldn't default to vulkan iirc
05:02 orowith2os[d]: yeah, just installed, default is opengl
05:03 orowith2os[d]: oh my. angle on zink on radv. that's quite fun.
05:13 mangodev[d]: orowith2os[d]: hmmmm
05:13 mangodev[d]: is there a way to force it to vk mode?
05:14 orowith2os[d]: something something `--enable-features=VaapiVideoDecoder,VaapiIgnoreDriverChecks,Vulkan,DefaultANGLEVulkan,VulkanFromANGLE`
11:57 goodtimetakesthings: The info that i dragged to the channel is extraordinary good...now I do not know how i got there, just like i have not been in my body lately, when you had pissed me off for years. Samewise the case of the artics expedition with military , some admiral or general said , i am unsure as to what happened, but it felt like i was not driving that airplane anymore.
14:54 x512[m]: I found out that Nvidia KMD use virtual mapping for PCI BAR. Virtual PCI BAR address range is allocated when performing CPU mapping.
14:55 gfxstrand[d]: That'd be nice....
16:38 behindthebars: I found out that sequences can be either growing or decreasing order per continue. it's easy to get smallest value per increasing order, and higest value per decreasing order. But unfortunately they can not alternate well i.e being something cross or in the middle of the mentioned. I remember some south-african mentioning that MILL CPU is a stackless architecture where as there are more
16:38 behindthebars: of those similar known projects. However sequences can be delta encoded , so first is some value, second value is some value+first value, third is some value + second value, hence you can say that first value can not be bigger than second nor can second be bigger than third. This is delta not fibonacci sequence. Fibonacci means that each value in sequence is the sum of two previous
16:38 behindthebars: values, obviously except the first two of them. But delta would mean sum of last value and itself. Imo fibonacci sequences curve is hence sharper. it goes high very fast.
16:39 magic_rb[d]: äääääödöocäeüöenctoyd,tgödc,ibdbüüryectygtio
16:56 dwfreed: O.o
16:56 karolherbst: looks like a cat
16:57 karolherbst: magic_rb[d] on the IRC side we still see your message :D
16:57 magic_rb[d]: yeah i know
16:57 magic_rb[d]: its the fucking whatever the yubi does if you hold it
16:58 karolherbst[d]: ahh
18:02 letmehackcrack: You all wan't to brag with your abuse like no one understands that you are total abuse LGBT rights pushing trash in life, you get what you deserve, everything has been fraud as of what you have done. The ancient case was fraud, where you failed to down me with the explosive, like you want to prove, that Russians bombed their own land, well i guess not! They were abuse mindill retards
18:02 letmehackcrack: like you. The sequences can not work without ordering, the best method , is variable format encoding, where you start 1024 entries in double encoded format mode, then push as next bank a shifted format, that is only padded to be bigger, just a bit, and as first cell in the bank, push the indices for the decoder, so it can make a bigger value from new format pushed. So decreasing order is
18:02 letmehackcrack: the main thing, not increasing. You start off by say 500k where next is 496k on 64bit arch, delta coded if first number was max, next is 4k+next value if happens to be max, it's 8k if you store a max again, you will have 8k+8k=16k so 16kilodigits in decimal for the first three, if you store max again 16+16k+4k next one is 36k digits in decimal. for only four maximum values. it should be
18:02 letmehackcrack: in unordered terms only 16k, for such stuff one can decode differently so upon reaching unordered sequence to say one million in decimal you may decide to double encode the bank and delta encode it so 10million divided by 4000 aka 4k decimal digits is 2500 elements per bank. that is the beauty of pagetables after all this means only 2500memory locations. however if you do not have those,
18:02 letmehackcrack: you go in a register like i started 36k maximum possible on element 4, and double encode the bank without using OS arrays. Either way just fuck off. Dog you fuck off, you are being cracked up soon with most of the others, like the deluded airlied scammer fucking scammer.
18:55 snowycoder[d]: Sm32 branch is rebased on main and reordered to match ir.rs!
18:55 snowycoder[d]: gfxstrand[d]
19:00 jaredfreewill1: You think as delta encoding is very insignifficant, actually it's not for christ sakes, when it is combined with other wisdom, it's entirely fine. You think i do not have anything other to do, than deal with LGBT porn abusers in estonia and cambodia, who are fucking thieves ontop pushing their rights like i was president of something? I was held 6times behind locks for fraudsters who do
19:00 jaredfreewill1: not even understand anything about algorithms pretending to be someone special here. Well once you get jailed you will be unlike me beaten to death in your ward or cell and in mental insitution you do not survive a single day. And explosive saga well you get bombed heavy , heavy shelling you receive soon anyways, i am not interested of your demands such as who i go out with whether i
19:00 jaredfreewill1: want to be in relationship is not your or rape framer thieve issue!!!!!!!!!!! Your are idiots. I do not want that anus like laura tornado or her crocodile angry fuck gloria, those are disgusting human shit to me, and i warned people, youll have to shoot those or you ain't gonna be ok from the head, or you have to stay away from such people, and everyone did according to the pictures of
19:00 jaredfreewill1: that tourism location, how can such freaks be popular. Real monsters, like it ever was about LGBT that i am so against, it's such disgusting terrorists what i am against.
19:40 gfxstrand[d]: snowycoder[d]: Cool. I'll try to review tomorrow
21:11 airlied[d]: I found a hopper system, I wonder if I can get it to boot nouveau
21:45 mohamexiety[d]: after some trying with turing, seems the relevant things that change are: `shared_memory_size` and `target_sm_config_shared_mem_size`
21:45 mohamexiety[d]: with ada*
21:46 mohamexiety[d]: not sure it's a safe assumption that these two are the same thing that changes with blackwell
21:46 mohamexiety[d]: but I am at loss as to what the latter header stands for tbh
21:48 mhenning[d]: The occupancy parts of the header weren't around on turing. I think they were introduced in ampere?
21:48 mohamexiety[d]: one thing of note: if I change both local size _and_ shared mem size to match, the latter header mostly doesn't change (only changes with 1024)
21:48 mohamexiety[d]: if I change only shared mem size the latter header changes
21:48 mohamexiety[d]: mhenning[d]: yeah I meant ada; too tired, sorry
21:48 mohamexiety[d]: I don't even have a turing
21:48 mhenning[d]: ah, that makes more sense
21:50 mohamexiety[d]: mohamexiety[d]: the behavior matches with the blackwell data. the upper bytes only change if I keep local size constant. they don't change if I change local size to match shared memory size, except with 1024
21:52 mohamexiety[d]: so I guess I can with reasonable confidence say that the lower bytes are shared mem size and upper bytes are whatever `target_sm_config_shared_mem_size` represents :thonk:
21:52 mohamexiety[d]: now the thing I am hung up on is what it represents
21:54 mohamexiety[d]: (since the goal in the end is to write the qmd fill in code so I will need to calculate this. on the other hand we currently dont fill it in anyways so maybe it's not important?)
21:56 mhenning[d]: Yeah, for anything we don't fill in on ada, I'd try just leaving it blank for blackwell.
21:57 mhenning[d]: some of them might come back to bite us later so we really should try to understand what all of the header bits do, but that can probably be a separate project from blackwell
21:58 mhenning[d]: or alternatively, you could work on filling those in on ada for a bit and then return to blackwell later
21:58 mohamexiety[d]: yeah I am noticing _a lot_ more stuff is being filled on prop
21:59 mohamexiety[d]: mhenning[d]: yeah I want to take a look at that as well (also the way we upload qmd/shader could be an interesting avenue to look into too since prop does things a lot differently). ideally I want basic compute to work on blackwell soon so trying to work towards that first though
22:01 mhenning[d]: I'm not so worried about how exactly we upload qmds or shaders, my guess is that neither of those is a bottleneck so as long as it works we're fine
22:02 mhenning[d]: I'm more worried about some of the header fields - `occupancy` in particular sounds like it could possibly be performance critical and we might be tanking performance by ignoring it
22:02 mohamexiety[d]: yeah there are quite a few occupancy fields
22:03 mohamexiety[d]: now the thing left for blackwell is cbuf/shader pointers :thonk:
22:04 mohamexiety[d]: oh also actually, may need to figure out how the shared mem size is actually represented in blackwell
22:04 mohamexiety[d]: with the ada QMD, it's just outright written. 1024 is 0x400, etc
22:04 mohamexiety[d]: mohamexiety[d]: with blackwell there's some indirection
22:06 mhenning[d]: Yeah, they might be enum values now
22:07 gfxstrand[d]: airlied[d]: It would be nice to know if theQMD code I typed blind works.
22:07 mhenning[d]: https://docs.nvidia.com/cuda/blackwell-tuning-guide/index.html#unified-shared-memory-l1-texture-cache lists carveout sizes for blackwell if that's helpful
22:08 mohamexiety[d]: yeah they're the same as ada and older
22:08 mohamexiety[d]: though this is something I was curious about actually
22:08 mohamexiety[d]: so on anything not CUDA, you're limited to 48KiB. with CUDA you can adjust the carveout
22:09 airlied[d]: kernel might need some work, seems to timeout on context creation
22:09 mohamexiety[d]: now question is, is the QMD also sent alongside pure compute workloads like CUDA or is it just for D3D12/Vk compute?
22:10 mohamexiety[d]: in other words, should I think about the bigger carveouts when thinking about how it will all look packed in the header or not
22:10 airlied[d]: yes cuda uses it
22:10 mohamexiety[d]: ah ok
22:10 mohamexiety[d]: thanks!
22:11 mhenning[d]: gfxstrand[d]: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34644 feels like an important fix when you get a chance to review
22:16 skeggsb9778[d]: airlied[d]: gh100? does it fail the engine tests or just userspace?
22:22 gfxstrand[d]: mhenning[d]: Assigned marge. Thanks!@
22:27 airlied[d]: skeggsb9778[d]: seems to boot fine with your branch, first userspace wait seems to timeout
22:28 airlied[d]: so it could be a bug in nvk I suppose
22:28 skeggsb9778[d]: could you throw me the gsp logs? seems likely it's something userspace side
22:28 skeggsb9778[d]: the engine tests test basic submission and fences work at least a little
22:29 airlied[d]: https://people.freedesktop.org/~airlied/scratch/gh100logs.tar.gz but I'll get back to in a couple of hours and do some proper checks on what we submit
22:32 skeggsb9778[d]: that's from my current branch with 570.133.07?
22:32 skeggsb9778[d]: i can't decode logrm for some reason
22:35 skeggsb9778[d]: nvm - pebkac/mondayitis
22:36 mohamexiety[d]: I wonder if gh100 will require more work on nvk side since afaik it's missing some gfx stuff entirely :thonk:
22:36 mohamexiety[d]: but at the same time the whitepaper does say that some TPCs are fully gfx capable so maybe not?
22:37 skeggsb9778[d]: airlied[d]: yeah, i don't see anything helpful there either unfortunately
22:38 mohamexiety[d]: gfxstrand[d]: could you give me some advice on no. 2 from the API side of things? I am a bit confused how I could wire it/set it up in Vk
22:47 gfxstrand[d]: Basically just modify the test to make two shaders and two pipelines and then do `vkCmdDispatch()` 3 times, ABA
22:47 gfxstrand[d]: Don't worry too much about the push constants thing. I don't even know if that's necessary to get what we're looking for
22:48 orangecolors: this new method is just an evolution of the previous , those that now say that hashed unordered sequence can be accessed as to how needed, are probably correct, cause i demonstrated that, though i have not reached to there entirely yet on IRC i was planning to do that soon, this stuff is highly long lifetimework but from the examples that boils down to 116 is as said 58 and 58 or 36+80,
22:48 orangecolors: you are free to do anything with the base 1024-116-112-256-112-256-144=28.... and 4 i showed too this was little different 450+58+144+256+112=1020 it's not very flexible however until you stretch the stuff a bit, right now it can capture in pseudo anything between 28 and 4 and 172 you mess around with arithmetic over those, but delta encoding succeeds on several other ways , it's so long
22:48 orangecolors: story, i have too much work yet to do on those.
22:53 mohamexiety[d]: gfxstrand[d]: alright, thanks a lot! I'll try different push constants as well just in case. the part I was getting hung up on was I thought only one pipeline, but I had misunderstood