00:01 gfxstrand[d]: Right now we're setting 0 (.ca or .wb) and it's fine.
00:05 gfxstrand[d]: Okay, I think I'm kinda happy with that MR now. I do need to test it on all the GPUs, though.
00:05 gfxstrand[d]: I'm 90% sure the Turing and Maxwell changes are safe but I'd hate to hose one of them.
01:01 karolherbst[d]: okay.. I think I figured out why RA is so bad at placing things for the coop matrix stuff... most of the phis begin with a zero initializer and RA just places the scalars first before doing anything, and then it's just bad no matter what, because the regs are already assigned... not sure if biasing RA to be smarter there helps that much, because the allocation of the vector might be split across
01:01 karolherbst[d]: several copies from a constant.
01:02 karolherbst[d]: and the copy rz are inserted by `to_cssa`
01:04 mangodev[d]: karolherbst[d]: i'm curious on what exactly a phi *is*
01:04 mangodev[d]: it seems like something useful to know, given a lot of recent changes have involved them
01:05 mangodev[d]: i remember it being shown as a hardware component in those blackwell diagrams?
01:09 mhenning[d]: karolherbst[d]: yeah, that's what the vector heuristic is for - writing to scalars that will be used in future vector instructions
01:09 mhenning[d]: again, it can't see past a phi or the current basic block right now
01:09 karolherbst[d]: though I'm not entirely sure when those values actually get assigned...
01:09 karolherbst[d]: yeah.. I'm aware, just trying to understand the code/RA first
01:10 mhenning[d]: sure
01:11 mhenning[d]: karolherbst[d]: registers get assigned in program order
01:11 mhenning[d]: mangodev[d]: phis are part of ssa https://en.wikipedia.org/wiki/Static_single-assignment_form
01:12 mhenning[d]: it's a bit in the weeds for compiler internals
01:13 karolherbst[d]: ohhh mhhh
01:13 karolherbst[d]: actually...
01:13 karolherbst[d]: it gets assigned whent he hmma is processed
01:13 karolherbst[d]: but for the vector source being allocated weirdly, `vec_killed` is true
01:17 karolherbst[d]: mhhh...
01:30 karolherbst[d]: maybe I'll add 500 debug prints to RA so it's easier to follow what's going on
01:32 karolherbst[d]: okay.. it happens as part of allocating hfma2
01:38 karolherbst[d]: mhhh
01:40 karolherbst[d]: okay.. I think the code I've been working on would actually fix this problem.. just need to finish it
09:46 alwayssucceed: now ten cells forms a bank, cause when stretching the base with increments of one we have 116 to 126 to get onto meeting first collision so offset is defined as multiplier *1 *2 the maximum value per cell. But it all depends on what are your goals towards worst access latency to do interbank accesses. But it's never fft cause that would put base ranges or offsets into square but we offset
09:46 alwayssucceed: those by mulipliers in contiguous field. So ten cells in a bank after which bank offset gets a new identifier is just ridiculously fast access by means you can in single intrinsic without flow index all of the elements of every cell of every bank. So in that pseudo access that would mean 126+72 at 196 offset starts a new bank of ten cells then at 196+72 which is now two times the max
09:46 alwayssucceed: added to the range is 3bank etc. That would mean tremendous memory with one sweep intrinsic something like loglogn access time on some i dunno still tiny storage. So hence what i brought up was it can not be in any terms discrete or fast fourier transform. so 1024 banks of 10cells is 1024*68or72 elements, so very old times i made hypothesis about that you can fit million of elements which
09:46 alwayssucceed: it does easily in max 72 domain. so the calculation there is pretty easy. 11264.00×72×5184 storage needed for accessing 11264 banks which means 11264*10 cells which means 112640*72 elements that brins as to 8million 110 thousand and eighty i.e 80. so 32bit variable can pack round about little over half a million packed 32bit values in real format which i have to calculate. it's max value
09:46 alwayssucceed: is somewhere between 10times larger than 72. Technically calculations are hence easy, procedures for access with fastest or lowest latency are very simple, but if you add iterations and bank exclusive accesses you will serialize as trade off of using less storage in the hash, but i prefer double packing i.e more rounds on fastest access than rolling ony of those time domains.
10:25 kar1m0[d]: What is bro yapping about
10:25 kar1m0[d]: Not reading allat
10:32 karolherbst[d]: yeah, just ignore it
12:18 gfxstrand[d]: karolherbst[d]: Any idea what's up with clang-devel.i686 in F42? dnf claims it conflicts with the x86_64 package so now I can't do 32-bit builds.
12:19 karolherbst[d]: yeah.. it's a fedora bug
12:20 karolherbst[d]: gfxstrand[d]: https://pagure.io/fesco/issue/3414
12:20 karolherbst[d]: looks like it's going to be fixed soonish (tm)
12:21 gfxstrand[d]: I guess I'm either spinning up a docker or just not submitting 32-bit for Kepler
12:24 karolherbst[d]: ~~just switch between the llvm versions or something~~
12:24 gfxstrand[d]: That sounds like a right pain in the ass but also totally possible
12:25 karolherbst[d]: I wonder if llvm-19 32 bit and llvm-20 64 bit can be installed at the same time...
12:25 karolherbst[d]: worst case, just switch between 32 and 64 devel packages... that should work and dnf has this allowerasing option
12:26 karolherbst[d]: gfxstrand[d]: alternatively, I can give you my build_llvm.sh script and then you just use a local build for 64 bit 😄
12:26 gfxstrand[d]: Or I could... just not
12:27 karolherbst[d]: hey, it only takes like 10 minutes to build on a competent machine
12:27 karolherbst[d]: builds first try, no questions asked
12:27 gfxstrand[d]: Or I could just submit 64-bit only. No one will care
12:28 gfxstrand[d]: And I'm pretty sure we don't have any kepler-only 32-bit bugs
12:28 karolherbst[d]: I wonder if the khronos conformance doc cares
12:28 gfxstrand[d]: It'll mean 32-bit drivers are technically not conformant or something
12:28 gfxstrand[d]: I don't think anyone cares
12:28 gfxstrand[d]: Last I checked, NVIDIA only submits on 64-bit
12:29 karolherbst[d]: worst case you say "oops" and at that time fedora already fixed their mess
12:29 gfxstrand[d]: Yup
12:29 gfxstrand[d]: And it's gonna be hard enough to get a complete run with random ctx timeouts
12:29 karolherbst[d]: ah yeah.. those random ctx timeouts...
12:29 karolherbst[d]: just shard enough or something
12:29 gfxstrand[d]: Only 2/4 shards completed last night
12:30 gfxstrand[d]: So now I'm running the other 2
12:30 karolherbst[d]: do 128 shards, then all will complete or something
12:30 karolherbst[d]: I know there is a funky timeout I was running into while running the GL cts
12:30 karolherbst[d]: and that only ever happens after like hours
12:33 gfxstrand[d]: I see these from time to time in my big multi-thread runs but they end up as flakes because of deqp-runner's retry
12:34 karolherbst[d]: yeah...
12:34 karolherbst[d]: no idea what's up with those
12:35 gfxstrand[d]: <a:shrug_anim:1096500513106841673>
12:35 karolherbst[d]: but if you run into those with nvk, it's kinda likely it's indeed a weirdo kernel issue
12:35 gfxstrand[d]: That's my assumption
12:35 karolherbst[d]: we do have known issues in regards to the context switching firmware
12:35 karolherbst[d]: and apparently using the blob one does resolve some of them sometimes
12:35 gfxstrand[d]: There's enough dmesg spam with MISALIGHED_ADDR and OOR_ADDR that it could just be overflowing some ring and choking.
12:36 karolherbst[d]: yeah.. possibly
12:36 karolherbst[d]: submitting to quickly and overflowing the ring buffer isn't really something we protect well against
12:36 karolherbst[d]: but who knows
12:36 karolherbst[d]: practically it doesn't matter enough to invest a month to track it down
12:37 gfxstrand[d]: And for today, all I care about is getting all 4 shards to complete
12:38 gfxstrand[d]: And I need to pop a Turing and a Maxwell into my other box and make sure my cache bits MR doesn't break either of those.
12:38 mangodev[d]: gfxstrand[d]: oh? is there a notable behavioral difference between 32 and 64 bit versions of the driver?
12:38 gfxstrand[d]: No
12:38 karolherbst[d]: it's kinda interesting that this issue doesn't really happy on Maxwell 1st gen
12:38 gfxstrand[d]: Sometimes you get 32-bit-only bugs but I don't think we've ever hit one of those with NVK.
12:39 gfxstrand[d]: karolherbst[d]: What issue? General instability? Yeah it does.
12:39 karolherbst[d]: mhhhhhhh
12:39 karolherbst[d]: and it's better on Maxwell 2nd gen?
12:39 gfxstrand[d]: IIRC, yes, but it's been a while.
12:40 karolherbst[d]: I mean.. that kinda checks out, because before 2nd gen Maxwell, we've written our own firmware for a bunch of stuff
12:40 karolherbst[d]: specifically context switching
12:40 gfxstrand[d]: Also, you're way less likely to screw up IRQs and hit race conditions in the driver if the GPU is idling.
12:40 karolherbst[d]: right..
12:41 karolherbst[d]: though I'd still assume that our context switching firmware has weirdo bugs in it, because if you screw up context switching you can see all sorts of weirdo issues
12:41 karolherbst[d]: I never bothered understanding the firmware, and I doubt anybody who did at some point either forgot all about it or moved on
12:43 gfxstrand[d]: That's kinda all of nouveau. 😢
12:44 gfxstrand[d]: Some knowledge areas have survived better than others and we've got good people now but still...
12:45 mangodev[d]: gfxstrand[d]: -# wdym "now" 🫠
12:54 snowycoder[d]: karolherbst[d]: Does the AMD driver have custom firmware too? or does it have blobs to load like GSP?
12:57 snowycoder[d]: also: I'm slowly working on texdep barrier insertion, my best guess is to copy the old code, it's kind of a mess but I cannot find better solutions for now.
12:57 snowycoder[d]: (It needs to find what instructions use the texture results across blocks, it could be easy in SSA, but we need it after Register Alloc.)
13:00 gfxstrand[d]: snowycoder[d]: Blobs like GSP. Except AMD actually kinda cares about the amdgpu kernel driver so it's maybe a bit of a better situation.
13:00 snowycoder[d]: Intel too I guess?
13:00 gfxstrand[d]: mangodev[d]: The nouveau community pretty much dried up until a few years ago. It was Ben and Karol part-time and that was about it.
13:01 gfxstrand[d]: snowycoder[d]: Yeah. Intel's probably about the same as AMD at this point.
13:01 mangodev[d]: gfxstrand[d]: fair point
13:01 mangodev[d]: explains nvc0's… *state*
13:02 gfxstrand[d]: And even before that, it was pretty fraught. Nouveau was a revolving door. People would come, they'd do good work, then they'd get hired to work on something else.
13:04 gfxstrand[d]: So there's a lot of pieces which no one understands because someone showed up, did amazing work, they merged it, and then that person vanished.
13:05 karolherbst[d]: burn-out doesn't make any of that any easier 🙃
13:05 gfxstrand[d]: Nope
13:05 karolherbst[d]: like the expectations were quite high and everything
13:05 gfxstrand[d]: Nor does fighting impossible fights like reclocking
13:06 karolherbst[d]: and then you at some point realize that and have to decide that you can't just sacrifice yourself for the cause, so yeah...
13:06 karolherbst[d]: heh
13:06 karolherbst[d]: reverse engineering the reclocking bits on kepler were fun tho, though others did the actual painful part that is memory reclocking
13:06 karolherbst[d]: but yeah...
13:07 karolherbst[d]: it's not something you can do with a project staffed with 1-2 full time persons in total
13:07 snowycoder[d]: karolherbst[d]: I'm amazed that they were reverse-engineered, that would be an awesome blog or talk.
13:07 snowycoder[d]: How many GPUs were blown up in the process?
13:08 karolherbst[d]: 0
13:08 karolherbst[d]: it's really hard to blow up nvidia gpus unless you know how to blow them up
13:08 karolherbst[d]: which.. uhm.. I know how, but like...
13:08 snowycoder[d]: Ahahahah
13:08 karolherbst[d]: once the GPU gets to hot, it just disconnect itself from the system and cease all operation
13:08 karolherbst[d]: but
13:08 karolherbst[d]: those thresholds are configurable
13:09 karolherbst[d]: *too hot
13:09 karolherbst[d]: those are all set up by an initialization script on the VBIOS and normally on normal GPUs those values are all sane
13:09 karolherbst[d]: but you can mess with them afterwards in the kernel if you really wanted to
13:10 karolherbst[d]: nvboost=2 kepler cards can reach those limits with furmark and then they just shutdown at some point
13:12 gfxstrand[d]: mohamexiety[d]: Did you ever get anywhere on the sparse fails?
13:13 mohamexiety[d]: gfxstrand[d]: not yet, sorry. caught a pretty bad cold and have been super brain fogged. the main thing I reached is that the code doesnt really touch the image view side of things at all, so it's not there
13:14 gfxstrand[d]: that's okay
13:14 mohamexiety[d]: but I am not sure where else it could be. they create an image and then copy it over, and then compare the output with the reference. our output is completely black so something goes wrong with the copy and it just doesn't copy anything
13:15 gfxstrand[d]: weird
13:15 gfxstrand[d]: I may take a look after a bit if I'm waiting for Kepler
13:16 gfxstrand[d]: I don't want to pull it out from under you but it's doubling the time of my CTS runs. 😂
13:43 karolherbst[d]: I just noticed I have a holiday today...
13:43 karolherbst[d]: and PTO tomorrow 🙃
15:03 gfxstrand[d]: Woo
15:30 mohamexiety[d]: gfxstrand[d]: something in general is wrong there tbh
15:31 mohamexiety[d]: they dont all fail, some pass and even those that pass run _very_ slow
15:31 mohamexiety[d]: like I left the whole test group running for an hour and it wasn't even done which is just :SufferingInside:
15:36 gfxstrand[d]: Sparse is so cursed for runtime
15:59 gfxstrand[d]: karolherbst[d]: Do you have docs for anything pre-Volta? If so, do you know what `LD.CI` does?
16:02 karolherbst[d]: nope and no idea
16:03 karolherbst[d]: maybe cache invalidate
16:03 karolherbst[d]: which options to exist on pre volta?
16:04 karolherbst[d]: they specify some of them in the PTX docs (even the old ones): https://docs.nvidia.com/cuda/archive/8.0/parallel-thread-execution/index.html#cache-operators
16:27 kar1m0[d]: has there been any thoughts about building a gui tool for nouveau drivers? similar to what nvidia has or that at least you can see info beyond just fps and gpu usage in games
16:27 kar1m0[d]: ?
16:28 gfxstrand[d]: We need to get that information out of the firmware first.
16:28 gfxstrand[d]: mangohud can display a lot more than it currently does with NVK. We just don't have the information for them.
16:31 kar1m0[d]: From what I remember it should be easier to do it for ada lovelace at least
16:31 kar1m0[d]: might be wrong though
16:33 fromslumsoutthere: 9 cells per bank btw and then the storage requirements were also bit off but the calculations for the packer are easy so the real storage used so 118+36=154 but it can scale below it by using upto division by four and generate the element of interests or selection elements as multiplies of four and add +1. So the implementation is simple. kar1m0[d] I blame Europe in this that we have
16:33 fromslumsoutthere: fecalists like karolherbst in the development of failure cycles. But you only look and listen to such fucking moron inspecting java feces traces to understand why failures are inherent and persistent in it's doings. Appareantly world thinks we should feed them with information and back up the real development so it can simply fart with it's colleagues of nonsense to our faces, so you
16:33 fromslumsoutthere: should never engage to any conversation with abortion leftover fecalists like karolherbst. Many times he had been sent away from lands like this, but one is suicidal like most of ones from this channel. We would have to deal with such by force generated. and kar1m0[d] you always get the same responses that distribution of reverse engineered firmware or it's readings is illegal.
16:34 kar1m0[d]: not reading allat
16:34 dwfreed: you can ignore it
16:34 mohamexiety[d]: kar1m0[d]: Turing onwards. I'll look into it when mtijanic is back from vacation and we get 6.16 rcs since that should have the newer GSP which should have all we need to get the proper counters/stats in a clean way. I cant promise I'll actually get it done but should have some info by then
16:39 kar1m0[d]: mohamexiety[d]: I will not use nouveau drivers in the near future on my main laptop, probably will install them during the summer
16:39 kar1m0[d]: nvidia dkms is a pain
16:40 kar1m0[d]: because now to switch to nouveau drivers I need to reinstall my whole os probably
16:40 dwfreed: not really
16:40 kar1m0[d]: so that I won't have any dependency conflicts, or driver ones
16:58 mhenning[d]: gfxstrand[d]: again, please review https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35143 when you have time. It's a 70% reduction in spills to memory from a fairly simple fix.
17:07 fartatfecalists: there is not alot to do with guys like kar1m0[d] for putin in a war, and no one is interested to kill those suicidal terrorists here similar to dwfreed and karolherbst, so they get to hang around at graphics channels farting and spewing inherent nonsense perpendicular to their brains capabilities, since once again abortion leftovers can not be utilized in elsewhere, they are NOP blame
17:07 fartatfecalists: hitler not to had been killing off retards.
17:08 fartatfecalists: those genes will be passed forward
17:19 gfxstrand[d]: mhenning[d]: I'll look in a few minutes. Sorry for the delay.
17:56 mangodev[d]: mhenning[d]: you're an absolute *saint*
17:56 mangodev[d]: thank you so much for the contributions as of late, i can barely imagine using this driver without them
17:56 mhenning[d]: aww thanks
17:56 mangodev[d]: two in a row is crazy
17:57 mangodev[d]: i use obsidian for note taking, and the first MR already made it *leagues* faster than before
17:57 mangodev[d]: TeX blocks render many times faster and scrolling is actually relatively smooth now
17:58 mangodev[d]: anti-aliasing and blur is also many times faster too
17:58 mangodev[d]: this upcoming MR should bring NVK close to expected speeds
17:58 gfxstrand[d]: Fixing the texture thing? Wow!
17:58 mangodev[d]: that too
17:59 mangodev[d]: i can relate to the kepler struggle, before i got my 1660S, i had a 660
17:59 mangodev[d]: still have it in a box somewhere, actually
18:00 mangodev[d]: has a broken fan though, bad bearing
18:01 mangodev[d]: i don't want to even fathom booting a desktop environment on such a weak card, but the work so far is amazing
18:01 mangodev[d]: especially since some of these changes help the whole codebase or find new issues
18:01 gfxstrand[d]: Ugh... `PHYSICAL_STACK_OVERFLOW`
18:02 mangodev[d]: gfxstrand[d]: what does that even *mean*
18:02 mangodev[d]: i'd assume that refers to physical memory but… as opposed to?
18:03 gfxstrand[d]: I think it means the control-flow stack overflowed but I'm not sure
18:03 mangodev[d]: oh
18:03 mangodev[d]: as in too big of a call stack?
18:03 gfxstrand[d]: Not really calls
18:03 gfxstrand[d]: On that hardware every if statement or loop pushes a stack
18:04 mangodev[d]: so does that mean too many nested branches?
18:04 mhenning[d]: gfxstrand[d]: I think this is correct
18:05 mangodev[d]: getting vulkan on such an old card at all is crazy, given the official drivers barely even support 1.1
18:07 karolherbst[d]: gfxstrand[d]: yeah... and there is a way to fix this error which is a pain and annoying, but doable
18:07 mangodev[d]: what's the oldest that's planned to go back with NVK? do you think Kepler or Fermi is the oldest you'll go, or are you masochists that'll try shooting for Tesla? curious question, no pressure
18:08 karolherbst[d]: it's the `SHADER_LOCAL_MEMORY_CRS_SIZE` and uhm.. what's the qmd one again?
18:08 mhenning[d]: Kepler is the oldest we've talked about
18:08 gfxstrand[d]: Yeah, we do that already for Maxwell but it's different on Kepler, I think.
18:08 mhenning[d]: I'd be against tesla in the same driver
18:08 karolherbst[d]: `SHADER_LOCAL_MEMORY_CRS_SIZE` 🙂
18:09 karolherbst[d]: mhh yeah.. could be that kepler has less on-chip space or something else...
18:09 mangodev[d]: mhenning[d]: feels like an nvc0 job
18:09 mangodev[d]: hasn't there been stated a reason why pre-fermi vulkan support is complicated?
18:10 karolherbst[d]: pre fermi is a massive pita
18:10 karolherbst[d]: for starters, images are compute only
18:10 gfxstrand[d]: I'm not particularly interested in support GPUs NVIDIA never did.
18:10 mhenning[d]: mangodev[d]: tesla is actually nv50, not nvc0
18:10 karolherbst[d]: tesla can't even support GL compute shaders in any sane way unless you like pain 😄
18:11 mangodev[d]: mhenning[d]: i'm honestly glad
18:11 mangodev[d]: to be honest, i don't like the sound of you practically wasting weeks of elbow grease for such a small userbase
18:11 mangodev[d]: mhenning[d]: oh yeah i forgot there isn't just one nouveau driver :|
18:11 karolherbst[d]: support kepler makes somewhat sense, supporting fermi makes sense if you want to delete nvc0, supporting tesla makes no sense
18:12 karolherbst[d]: the command buffer format is also different
18:12 mangodev[d]: mangodev[d]: iirc there's at least 3? at least according to gitlab issue tags
18:12 karolherbst[d]: yeah
18:13 mangodev[d]: karolherbst[d]: even fermi feels a little far-fetched
18:13 mangodev[d]: iirc kepler is the oldest with official vulkan support?
18:13 karolherbst[d]: with fermi support we could in theory go zink only for GL and delete the nvc0 driver
18:13 gfxstrand[d]: Fermi doesn't have bindless
18:14 karolherbst[d]: it could have if you like pain 😄
18:14 mangodev[d]: i could've sworn it was brought up somewhere that fermi nvk is *possible,* but a royal pain because of missing hardware features, meaning a spotty and heavily software-handled driver
18:14 mangodev[d]: i think gfxstrand was the one that said it
18:15 gfxstrand[d]: Once we land Kepler support, we may fork NVK in a couple years and leave pre-Turing behind.
18:15 mangodev[d]: gfxstrand[d]: yeah
18:15 gfxstrand[d]: Mostly so that we don't break it.
18:15 gfxstrand[d]: I've already hosed Maxwell a couple times without realizing it.
18:15 karolherbst[d]: sounds like a good idea
18:16 gfxstrand[d]: We don't have real CI for NVK. Even when Mesa CI gets added, it'll just be Ampere.
18:16 mangodev[d]: gfxstrand[d]: so nvk replaces nvc0?
18:16 kar1m0[d]: gfxstrand[d]: not alot of people use kepler today
18:16 kar1m0[d]: so makes sense
18:16 mangodev[d]: kar1m0[d]: i mean
18:16 mangodev[d]: the only way to tell is statistics
18:17 mangodev[d]: also keep in mind that many with older hardware use linux as a safe zone where they can still get software support
18:18 kar1m0[d]: I doubt those people need anything beyond basic gpu support
18:18 mangodev[d]: if not many use Kepler, even fewer use fermi, and by tesla, you've just gotta accept that you're in the paleolithic era in terms of gpu hardware, you're *barely* out of ffi territory
18:20 karolherbst[d]: the issue is more that maintaining/fixing the gl driver is pain
18:24 mangodev[d]: karolherbst[d]: yes
18:24 mangodev[d]: so at a certain point, you just have to accept that your GeForce 8800 GTX isn't going to be supported anymore because maintaining support for it is just a pain and benefits barely anyone at all
18:24 mangodev[d]: it sucks, but this is almost 20yo hardware we're talking about, and supporting something that can barely scrape by modern programs, nonetheless a modern driver is somewhat silly
18:25 mangodev[d]: tbf though, nouveau GL is already old, because it was hard to maintain for years
18:25 mangodev[d]: it's just begging for the sweet release of Amber™
18:28 mangodev[d]: gfxstrand[d]: pascal support is pretty important though
18:28 mangodev[d]: i have *yet* to meet a nvidia linux user that's on a gsp-era card :/
18:28 mangodev[d]: how do you plan to differentiate post-gsp and pre-gsp NVKs?
18:28 gfxstrand[d]: Yes you have. They're just not complaining.
18:29 dwfreed: heh
18:31 mangodev[d]: gfxstrand[d]: fair point
18:31 mangodev[d]: i have seen the reddit posts of 30 series laptop users being happy with the nvidia drivers (aside from the setup)
18:31 mangodev[d]: but most (if not all) linux users and want-to-be linux users on nvidia all use a pascal card, with the occasional maxwell card
18:31 mangodev[d]: i see why pascal and maxwell support alone was worth the announcement
18:33 mangodev[d]: could be sample bias, and tbf most users of older cards are probably already on linux because of the legacy support and community
18:34 gfxstrand[d]: Sample bias is a huge issue. People whose cards work don't make reddit threads.
18:34 gfxstrand[d]: Reddit threads get made by two kinds of poeple: Those that are super excited and fanboying and those who have something to complain about.
18:35 gfxstrand[d]: And the later category will never shut up.
18:35 kar1m0[d]: what is a gsp era card
18:35 gfxstrand[d]: Turing (2000-series and 16xx) and later
18:36 gfxstrand[d]: gfxstrand[d]: And I don't mean that in a derogatory way. People who are still rocking a 780 are probably still using that card for a reason. Financial, an aversion to e-waste, something. So they want it to work, damnit! And I get it.
18:36 kar1m0[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1377717372361768960/image.png?ex=6839faca&is=6838a94a&hm=3d42b6cd5e5302848e89574c96d295cd730040b5d2f92b6bae5e2ff506c69b24&
18:36 kar1m0[d]: gfxstrand[d]: uhm
18:37 gfxstrand[d]: Yeah, that's Ada, you're good.
18:37 mangodev[d]: kar1m0[d]: imagine having money in the 2020s
18:37 kar1m0[d]: mangodev[d]: I worked my ass off fo this laptop
18:38 mangodev[d]: kar1m0[d]: i'd guess so
18:38 mangodev[d]: those puppies are *expensive*
18:38 gfxstrand[d]: gfxstrand[d]: And the people who don't have a financial reason to still be on the 780 either accepted the blob drivers long ago or switched to an AMD card.
18:38 dwfreed: gfxstrand[d]: I have a kepler in an 11 year old laptop
18:38 gfxstrand[d]: But also, they could just be happily playing games and not writing Reddit threads.
18:39 gfxstrand[d]: dwfreed: I think I've got a laptop with a Fermi in it somewhere.
18:39 dwfreed: I do run it on the blob driver, though
18:39 gfxstrand[d]: Fermi + Sandy Bridge. A 100% cursed combination!
18:39 dwfreed: this is kepler + haswell
18:39 gfxstrand[d]: That's a lot less cursed
18:39 kar1m0[d]: dwfreed: my old laptop is 10 years old and has a kepler b
18:40 gfxstrand[d]: Most of my NVIDIA is PCI because I bought a bunch of cheap cards on ebay to back-fill my collection for testing.
18:40 mangodev[d]: gfxstrand[d]: or just don't have the need for new driver updates because they use emacs all day
18:40 mangodev[d]: ~~or the tech hippie type that seeks out purposefully old and weak hardware~~
18:41 mangodev[d]: something something "productivity" "minimalism" "my i3 config"
18:41 kar1m0[d]: there are also people who don't use gpus at all
18:42 kar1m0[d]: only use integrated graphics
18:42 dwfreed: I have one nvidia pcie card, I think it's 1600 series; it is not used because it was replaced with an AMD 5700 XT
18:43 mangodev[d]: dwfreed: i would shoot for an amd card if i had the spare cash because they have driver support
18:43 mangodev[d]: but they're expensive now, and at the rate i can build money, they're just going to get more out of reach
18:43 snowycoder[d]: kar1m0[d]: On mordern laptops integrated GPUs are crazy good
18:44 mangodev[d]: snowycoder[d]: strix halo:
18:44 mangodev[d]: (ik it doesn't really count because you could buy two gaming laptops for the price of the chip alone, but still)
18:44 kar1m0[d]: snowycoder[d]: true
18:44 dwfreed: mangodev[d]: with them no longer targeting the top end starting with the 9000 series, they should be more attainable generally; picking up a 9000 series when the next comes out should be pretty easy
18:46 kar1m0[d]: the only laptop that is fully amd is the asus a15
18:46 kar1m0[d]: though I would never use a fully amd laptop
18:46 kar1m0[d]: I saw the temperature tests on them
18:46 kar1m0[d]: and the cpu reaches 100 degrees celsius
18:47 kar1m0[d]: (it generally shouldn't be above 80-85)
18:49 gfxstrand[d]: My Lenovo x201s would hit 95 or 100
18:53 gfxstrand[d]: I also had to send it in 3 or 4 times because of heat-related issues, so...
18:54 kar1m0[d]: gfxstrand[d]: That's horrible
18:55 kar1m0[d]: I got around 80 degrees Celsius when I didn't have a cooling pad
18:55 kar1m0[d]: Now it rarely gets above 75
19:14 gfxstrand[d]: Yeah, anything over 70-80 is downright dangerous.
19:14 gfxstrand[d]: Even 80 is pushing it
19:17 dwfreed: I have an 8845HS running on the integrated graphics; temps don't hit 70 running stress-ng
19:17 dwfreed: 4.1 GHz all core clock
19:19 gfxstrand[d]: IDK what my Alienware hits but it gets warm
19:38 rinlovesyou[d]: running into a bunch of resolve errors when running `sudo ninja -C build/ install` after building
19:39 rinlovesyou[d]: error[E0425]: cannot find function `util_format_is_pure_integer` in this scope
19:39 rinlovesyou[d]: --> ../src/nouveau/nil/format.rs:58:18
19:39 rinlovesyou[d]: |
19:39 rinlovesyou[d]: 58 | unsafe { util_format_is_pure_integer((*self).into()) }
19:39 rinlovesyou[d]: | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ not found in this scope
19:39 rinlovesyou[d]: error: aborting due to 106 previous errors
19:41 mhenning[d]: rinlovesyou[d]: try doing a `nina clean` and then rebuild
19:41 rinlovesyou[d]: i'm already doing a full clean build by just deleting the build dir
19:42 mhenning[d]: that's odd then
19:43 mhenning[d]: is it possible you're running a different rustc between build and install?
19:44 airlied[d]: I normally go the full git clean -fdx at that point 😛
19:44 rinlovesyou[d]: i don't know how that would happen
19:45 mhenning[d]: rinlovesyou[d]: sudo might wipe certain env vars
19:45 rinlovesyou[d]: but that's never happened before so why would it now
19:46 rinlovesyou[d]: i never changed anything about rust on my system, just using rustup
19:46 rinlovesyou[d]: airlied[d]: still happening :')
19:46 anholt: try sudo -E, so you hopefully use the same rustc that rustup probably put in your homedir.
19:49 rinlovesyou[d]: anholt: that worked
19:49 rinlovesyou[d]: weird, this has never happened before
19:49 rinlovesyou[d]: thank you very much
19:56 airlied: TIL sudo -E
20:04 smartmarkov: They have scanners called xrf that stands for xray fluoroscence, where estonians have screwed me with those for years the technology primarly comes from siemens medical as well as industrial instruments europe wise, hitatchi manufactures those machines alike, they have had such things for several decades now, you point a scanner to the target it will resolve every substance in the victims
20:04 smartmarkov: body, and they start to milk certain people afterwards to cure born illies like dwfreed and karolherbst. it's as illegal by laws as all the Europe's actions have been but it's not sure it would be better in other ways yet to dump dealing with Europeans altogether.
22:07 gfxstrand[d]: One test failure
22:07 gfxstrand[d]: `dEQP-VK.rasterization.rasterization_order_attachment_access.depth.samples_1.multi_draw_barriers`
22:11 gfxstrand[d]: Unfortunately, this is one of those test cases where all the feedback you get is "failed"
22:14 gfxstrand[d]: I suppose it's possible we're getting early depth testing or something
22:14 gfxstrand[d]: Or that there's another cache we need to flush
22:17 gfxstrand[d]: `KILLS_PIXELS` is set so we really shouldn't be getting early depth
22:21 snowycoder[d]: I tried to setup a KernelA machine but if I enable modeset it black-screens -.-
22:43 gfxstrand[d]: That's a Kepler B fail
22:44 snowycoder[d]: snowycoder[d]: *KeplerA (GK104)
22:44 snowycoder[d]: In dmesg: "nouveau: [drm] Cannot find any crtc or sizes"
22:45 gfxstrand[d]: 😢
22:46 snowycoder[d]: Does the current nouveau drm driver still handle kepler video properly? (I'm using arch btw)
22:47 mhenning[d]: It's supposed to
22:50 mhenning[d]: (the kernel driver nominally supports back to the riva 128 circa 1997)
22:51 snowycoder[d]: I'll try to debug this when I can
22:51 snowycoder[d]: gfxstrand[d]: did you get video output on your kepler cards?
22:53 gfxstrand[d]: I think so?
22:54 gfxstrand[d]: I honestly haven't been paying attention. I just ssh
23:03 robotlooney: btw 192 to 72+36 so 84 indexes added all apart of each other by one. so 200 can split to 92 indexes etc. so this way it would fit perhaps more in fact, you would not need to raise the max for too often. so new elements per cell would be then 84to404 with 1step digits to be added together. and hence new storage requirements would be that number from previous calculations without
23:03 robotlooney: 21*84to404*(72+36) which is somewhere per bank already as 160million for a bank of 725k elements in those terms you can now fit 725thousand elements per bank (very approx will fire a loop tomorrow) and hence next bank is 320million then 640million then 880million, then already 1.6 billion, so that type of calculation gives us 5*700k so 3.5 million to be more fair perhaps. so maybe this so
23:03 robotlooney: the remaining one billlion can fit yet more more 1million elements so roughly 5million if used this way for 72 so we divide this by 4 roughly and get somewhere in range of slightly below 2million entries, my prediction before was somewhere close to that anyways, pretty much eyes closed so enough close. unsigned datatype there.
23:44 trailorpark_kid: it would be easier to do calculations with powers and have banks aligned to powers,but since the smallest ideal powers of twos representation formats distribution is unaligned from powers anyways for best space efficiency, then anyhow the 5million is likely somewhere as good as possible with the fastest access. But all this is mindblowing amount of memory that freaks like you do not
23:44 trailorpark_kid: even imagine. and since decoder/encoder is just going to be as fast as this access it's elected to double encode instead of seriliazing the colliding banks, from this work you see also why the world is upside down (including the fraud that bitcoin pushed) as evil as possible committed by quasimodo ill humans in majority and wars are not surprising or continous deaths of young people.
23:44 trailorpark_kid: After all it was so big secret which "i never knew" that they used my organs for human shit like you, and that they and you are all fraud committers.