01:45gfxstrand[d]: Nah, codegen and NAK fault on the same address
01:54gfxstrand[d]: It's overrunning the VAB area
02:04gfxstrand[d]: snowycoder[d]: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35172
02:14gfxstrand[d]: Okay, another one where it fails with codegen, too
02:56gfxstrand[d]: The tessellation fails might be because vec3 loads don't actually work. Should be easy enough to fix.
02:57gfxstrand[d]: I've got a patch typed for that. I just need to wait until tomorrow to test it.
03:02mangodev[d]: gfxstrand[d]: wait *w h a t*
03:03mangodev[d]: how does the driver work if vec3's don't 😰
03:13gfxstrand[d]: You split them into a vec2 and a scalar
03:14gfxstrand[d]: It's 2 lines of code and 4 lines of comment. I just need to test it and verify it fixes the issue.
03:16gfxstrand[d]: And then I need to stop procrastinating and figure out why these memory model tests are falling. It's almost certainly an encoding bug but ugh....
03:38mhenning[d]: do you have L1$ enabled for globalmem? I think it's not coherent enough to be legal in general on kepler
03:40raket: is it possible to get 1920x1080@240hz to work on 780ti? 1920x1080@200hz works fine
03:57gfxstrand[d]: mhenning[d]: Not sure.
03:57gfxstrand[d]: I don't remember. You'd have to look at the registers.
04:02mhenning[d]: oh, I meant the cache flags on the instruction
08:15snowycoder[d]: gfxstrand[d]: Ohhhh, I never could have guessed that
08:19snowycoder[d]: gfxstrand[d]: Why do they even have the `.96` encoding if they do not work 0_o
08:19snowycoder[d]: Also, why are they the only tests to fail, I expect way more tests to load 3 consecutive attributes.
08:38karolherbst[d]: snowycoder[d]: it works on other gens
11:57gfxstrand[d]: mhenning[d]: Right. Yeah, it's not. Not for the full memory model, anyway.
11:58gfxstrand[d]: snowycoder[d]: I haven't actually confirmed. It's currently just a theory. Are you seeing those vec3 tessellation fails on Kepler B?
11:59snowycoder[d]: gfxstrand[d]: Same ones, yep
12:00gfxstrand[d]: Okay, cool. I'll throw you the patch once I have Kepler A passing.
12:01gfxstrand[d]: I'm avoiding my last image bug because the shaders are huge. 😢
12:01gfxstrand[d]: Maybe I can plug in a GK20x and compare?
12:02kar1m0[d]: snowycoder[d]: I will try to compile the commits again today
12:02kar1m0[d]: For testing them on kepler b
12:02kar1m0[d]: For some reason I can't compile them
12:02kar1m0[d]: Maybe something with missing dependencies
12:35gfxstrand[d]: snowycoder[d]: Got a tessellation fix in my nak/sm20-fixes branch. I'll wait for more to pile up before I marge.
13:20snowycoder[d]: kar1m0[d]: If you paste the error we can help you
13:20snowycoder[d]: gfxstrand[d]: I have a list of tests that don't pass yet, if you give me a list I can also try it out
14:22gfxstrand[d]: I'm mostly focused on SM20 but it's nice for this like that tessellation bug to look at SM32 as well. I've got one and a second PCI slot, I just have to dig around in the box and find it.
14:22gfxstrand[d]: It might be a 7080 Ti. 😂
14:24gfxstrand[d]: When I was backfilling my GPU collection, I was like "t/These things are so cheap! I might as well buy big ones." which for Kepler is kinda fine. But for Maxwell it means all of the power cables, none of the processing power. 😂
14:25kar1m0[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1376929184814989342/meson-log.txt?ex=68371cbb&is=6835cb3b&hm=7ac9787e2cf3194f53e89046915f6d0336d99c97ce0a617109a4a2227de60ef5&
14:25kar1m0[d]: snowycoder[d]
14:36kar1m0[d]: It's weird that I have alot of missing dependencies here
14:36kar1m0[d]: Like
14:36kar1m0[d]: Alot
14:38asdqueerfromeu[d]: kar1m0[d]: I see libdrm_intel is triggering the error here
14:42kar1m0[d]: asdqueerfromeu[d]: Which is fixed by downloading libdrm?
14:44asdqueerfromeu[d]: kar1m0[d]: I think you should disable some Meson options instead
14:47tiredchiku[d]: gfxstrand[d]: Faith time traveler :BlobhajShock:
14:50kar1m0[d]: tiredchiku[d]: Jokes on you I am using a 9090 ti super
15:03gfxstrand[d]: I've got a TITAN V in my box. The most useless Linux GPU ever.
15:03gfxstrand[d]: Okay, maybe not ever. But the most useless in the recent(ish) NVIDIA lineup, IMO.
15:05tiredchiku[d]: huh, why so
15:08mohamexiety[d]: well
15:08mohamexiety[d]: Volta was really only one (1) chip; GV100, and it was only sold for the Pro market
15:08mohamexiety[d]: additionally, while Volta added most of the changes that Turing had, it doesn't have the GSP
15:09mohamexiety[d]: which means that you can't really do much with it in the open stack
15:09mohamexiety[d]: mohamexiety[d]: while this means that there's really no user base for it
15:10mohamexiety[d]: the OG market for it long moved off of it as subsequent generations, especially Ampere, were _A LOT_ better that keeping Volta was just losing money. and it's too expensive for the normal user market. also it doesn't have any of the fancy things that Turing onwards do so really there's just no point to it
15:11mohamexiety[d]: actually there is one point I guess; if you want the last-not-super-expensive HBM GPU, and if you want the last-not-super-expensive FP64 GPU. since Volta actually did have 1:2 FP64 (all consumer NV GPUs are 1:64)
15:12mohamexiety[d]: but also it's getting deprecated in CUDA 13.0 so even that is going to be annoying long term
15:17mohamexiety[d]: you can make an argument that Maxwell and Pascal are useful because their userbase is huge. Kepler you can argue is useful because it's deprecated in the NV stack so having it get some support in another stack is nice. but Volta is just, it exists.
15:53snowycoder[d]: kar1m0[d]: I'm not home, but did you follow the compile guide? It tella you mostly every dependency you need
15:56gfxstrand[d]: snowycoder[d]: I'm seeing `dEQP-VK.memory_model.message_passing.core11.u32.coherent.fence_fence.atomicwrite.device.payload_local.buffer.guard_local.buffer.comp` fail on GK208
15:57gfxstrand[d]: Hrm... That seems to have nothing to do with surfaces. Maybe we're just setting cache flags wrong?
15:59gfxstrand[d]: Okay, I feel a little less crazy now
16:03gfxstrand[d]: I'm doing a Kepler B run now just for grins
16:03gfxstrand[d]: I think my remaining fails are the same between the two.
16:04gfxstrand[d]: And I think most of them fail with codegen, too
16:59karolherbst[d]: gfxstrand[d]: mupuf still have a bunch of GPUs in case you'll need more, but yeah...
17:02kar1m0[d]: tiredchiku[d]: the only difference between regular dkms and open dkms that I noticed is that now the gpu power cap I have now is 85w instead of 80w
17:03kar1m0[d]: I wonder if nouveau drivers power cap is better than of proprietary
17:03kar1m0[d]: though there is no way to check it I think
17:24kar1m0[d]: snowycoder[d]: I will look into it more tomorrow
17:33mupuf: gfxstrand[d]: you are not coming to.xdc this year, right? otherwise I could have brought you a couple
17:34gfxstrand[d]: I am
17:34mupuf: mohamexiety[d]: is there a chance you could make it?
17:34mupuf: gfxstrand[d]: sweeeeeeet!
17:35mupuf: then, I'll list what I have then you can ask what you want
17:35gfxstrand[d]: If we can figure out where to have it, I'd like to do some sort of nvk/nouveau hackathon thing the day or two before. Or if Valve is gonna do another thing, maybe we can just have an NVK room there
17:35mupuf: same goes for any Dev, really
17:35mupuf: could be cool, yeah!
17:35mohamexiety[d]: mupuf: I will know for sure in late June/early July not sure yet as I still need a visa and all that 😦
17:35mohamexiety[d]: I do want to tho!
17:36mupuf: 🤞
17:36asdqueerfromeu[d]: I might (or might not) be coming to XDC
18:36mhenning[d]: gfxstrand[d]: pls review https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35143
18:48mupuf: anyone else coming to.xdc?
19:02karolherbst: me probably
19:03mupuf: good
19:03mupuf: if anyone is planning on working on Kepler support for NVK, I think I still have most variants of it
19:08gfxstrand[d]: snowycoder[d]: I did a full Kepler B run and the two are now at parity.
19:18snowycoder[d]: gfxstrand[d]: I guess that srgb resolve still causes issues?
19:21understagezero: so today i accessed 24 indexes in a one next to another manner in calculator without a single mistake or wrong result gotten, so i skipped the last ones since i expect all the bank to work, after a sleep session i am ready to code.
20:02gfxstrand[d]: yes
20:03gfxstrand[d]: snowycoder[d]: ^^
20:05snowycoder[d]: gfxstrand[d]: That's my nemesis, I have no idea left
20:06gfxstrand[d]: ðŸ§
20:09gfxstrand[d]: Yeah, so we have some memory model tests that are still failing. Those are probably cache bits of some sort? Maybe membar? Not sure.
20:09gfxstrand[d]: Then there's the sRGB tests. I'll look at those next, I think.
20:10gfxstrand[d]: Then there's all these renderpass tests. Those are probably a cache flush on the NVK side. They fail with NAK on SM20 and SM32 and they also fail with codegen so I don't think it's a compiler issue
20:10gfxstrand[d]: For now focus on storage texel buffers so we can land images. I think that's the last blocker left.
20:31norandomtrouble: You've been now harassing me for 15 years in a row, i put on a public vote what to do with you, cause i have no idea , you likely will be captured and treated along with other estonians, committing that fraud, i care none of your illuminati states , you tried to kill me at foreign countries, you get handled, i am starting to connect to many powers about such retarded gangstalkers, and
20:31norandomtrouble: we will put you off consistently, you are entirely absurd people. After terror for couple of decades you demand taxes, critisize for no results by not having any on your own on the way :D hah, only results you got was my hard research. Your sexual content spammed into the worlds freaks is just horrible, i am unsure was there ever any real person interested of such freaks intrigues. It's
20:31norandomtrouble: aburd theatre you are joke artists.
20:36gfxstrand[d]: I bet kepler wants a sampler for texelfetch
20:36gfxstrand[d]: That would suck...
21:06gfxstrand[d]: tshikaboom: sRGB fixed in https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35190
21:06gfxstrand[d]: Now I just need to figure out these renderpass fails
21:09snowycoder[d]: gfxstrand[d]: What memory model tests? on my machine they all pass
21:10gfxstrand[d]: `dEQP-VK.memory_model.message_passing.core11.u32.coherent.fence_fence.atomicwrite.device.payload_local.buffer.guard_local.buffer.comp` is one
21:10tshikaboom[d]: gfxstrand[d]: I'm probably not the right recipient to this message, am I? 🙂
21:10gfxstrand[d]: tshikaboom[d]: No. Sorry. I have no idea how that autocomplete failed. 😂
21:10gfxstrand[d]: That was meant for snowycoder[d]
21:11snowycoder[d]: gfxstrand[d]: ```
21:11snowycoder[d]: Test case 'dEQP-VK.memory_model.message_passing.core11.u32.coherent.fence_fence.atomicwrite.device.payload_local.buffer.guard_local.buffer.comp'..
21:11snowycoder[d]: Pass (Pass)
21:11snowycoder[d]: :frog_thinkk:
21:14gfxstrand[d]: Fails on both Kepler A and Kepler B for me :blobcatnotlikethis:
21:14gfxstrand[d]: What chip do you have?
21:14gfxstrand[d]: I'm testing with GK208
21:14gfxstrand[d]: GT 635
21:15snowycoder[d]: `NVIDIA Corporation GK208B [GeForce GT 710] (rev a1)`
21:15snowycoder[d]: Oh that will be fun
21:15gfxstrand[d]: 208 vs. 208B Nice...
21:15gfxstrand[d]: FML
21:16snowycoder[d]: gfxstrand[d]: Fortified Memory Loads?😂
21:16gfxstrand[d]: Yes. That. Very much that. That's totally what I meant. 😅
21:40gfxstrand[d]: Okay, I have a patch that fixes all the rasterization tests except on which fails on GK208 but not GK106. :blobcatnotlikethis:
21:52snowycoder[d]: I've addressed the review comments and reworked texel buffers, now they should be more readable
22:01gfxstrand[d]: Okay. I'll read through it tomorrow and hopefully merge.
22:02gfxstrand[d]: Then I just need to figure out these last two bugs and do CTS runs.
22:02gfxstrand[d]: I kinda can't believe we're already at the "Do CTS runs stage. 🤯
22:03gfxstrand[d]: Once we land images, I'm ripping out codegen support from NVK.
22:04gfxstrand[d]: It's not helpful for these last two bugs, I don't think.
22:05gfxstrand[d]: I guess I could try the MM tests on codegen but I doubt it would help
22:44sonicadvance1[d]: Woo, delete the world.
22:47snowycoder[d]: gfxstrand[d]: We might have a more correct implementation than codegen, but we are still way slower.
22:47snowycoder[d]: I don't know how hard instruction scheduling will be.
22:47snowycoder[d]: (I'm thinking about the texdep insertion algorithm though)
23:05gfxstrand[d]: Yeah, but NVK+codegen is so broken as to be almost useless.
23:06gfxstrand[d]: Like, Kepler can't even survive a CTS run with codegen
23:06gfxstrand[d]: And I've done multiple full runs just today