00:05 karolherbst[d]: needs Vulkan 1.3 features I guess?
00:05 karolherbst[d]: I see `minSubgroupSize` and `maxSubgroupSize` 🥲
00:06 karolherbst[d]: maybe I just go ahead and fix it all up
00:08 karolherbst[d]: just need to get my head around how it all fits together
01:45 gfxstrand[d]: It needs VK_EXT_subgroup_size_control
01:45 gfxstrand[d]: and maybe some KHR_shader_executable_properties
01:59 gfxstrand[d]: Looks like everything passed! I'm running the verification script on the package now then I'll upload it.
02:51 gfxstrand[d]: Well, I would have uploaded it except the Khronos website says my POST is too big. I've e-mailed the webmaster and he'll probably have to fix an apache or nginx config somewhere and then I'll be able to upload it.
02:55 airlied[d]: too much logging or just the amount of tests makes it larger than something than previously?
02:57 gfxstrand[d]: I think the server config got messed up. It's no different from the Kepler submissions that went through fine. I've hit his issue before. James will fix it.
02:57 gfxstrand[d]: https://forums.developer.nvidia.com/t/unix-graphics-feature-deprecation-schedule/60588
02:57 gfxstrand[d]: It's official. Nvidia is dropping everything pre-Turing.
03:03 HdkR: Oh wow, Volta as well
03:03 airlied: anything that needs the closed kernel driver
03:04 HdkR: ah right, pre-GSP stuff.
03:07 gfxstrand[d]: Eh, dropping Volta also improves a bunch of other stuff on the userspace side. No more crappy MME.
03:07 gfxstrand[d]: And you get to assume bindless cbufs
03:08 gfxstrand[d]: And you get to delete all the pre-Turing image handling which isn't a massive win but it's non-zero code.
08:21 zmike[d]: Nooooooooo my 1080!
08:31 mohamexiety[d]: YouTube told me the 1080Ti is going to be relevant in 2035 :Clownsive:
08:47 asdqueerfromeu[d]: gfxstrand[d]: How about modern DXVK at least? 🐸
09:17 huntercz122[d]: Forever stuck at 1.10.3 🐸
09:27 blisto[d]: rip
12:42 misyltoad[d]: mohamexiety[d]: Youtube told me that about the Titan
15:14 mangodev[d]: gfxstrand[d]: i mean
15:14 mangodev[d]: this is pretty much giving extra way for the two NVKs you were talking about before, right?
15:24 gfxstrand[d]: Yeah, there may be value in us cutting as well but I want to get the older hardware in better shape first
15:31 mangodev[d]: gfxstrand[d]: how do you think the split is going to go? would there be a substantial effort in splitting them? or would it effectively be deleting some files
15:32 mangodev[d]: also, how would having two drivers for the same vendor exactly work? afaik the only drivers like that are the Mali drivers, and *maybe* Intel integrated if you count HASVK
15:56 gfxstrand[d]: You just duplicate the directory, maybe sed the files to change the prefix, make the two drivers enumerate on disjoint sets of hardware, and then start deleting code.
16:03 mhenning[d]: mangodev[d]: on the gl side we have nvc0/nv50/nv30
16:06 mhenning[d]: gfxstrand[d]: I'm not convinced on splitting them. With nv50/nvc0 I did a lot of "write the same bug fix twice on near-identical copied code" and I'd rather not get into the same situation with nvk
16:07 gfxstrand[d]: I don't want to unless we think nvk needs a significant rewrite that isn't compatible with old hardware. As long as we can gracefully degrade from one to the next, we'll keep doing that.
16:10 mhenning[d]: yeah, for now they've been fit in a common framework and I'd prefer to keep it that way unless there's a need for a rewrite like that
16:24 karolherbst[d]: the nv50/nvc0 split kinda made sense because the entire command buffer layout is entirely different
16:24 karolherbst[d]: though
16:24 karolherbst[d]: the way it was split was maybe not ideal
18:25 marysaka[d]: Not entirely sure if that is the right place to put (might be better really right before vectorize) buuut https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35869
19:29 snowycoder[d]: I would really like to keep old support in and have some kind of automated testing.
19:29 snowycoder[d]: It seems hard to align the two versions in different directories if we ever want to.
20:54 marysaka[d]: marysaka[d]: now properly doing the thing I wanted to change :maxpoeSweat:
20:54 marysaka[d]: Still quite curious on why there was such a code diff with just constant folding early in the optimization loop tho
21:49 gfxstrand[d]: snowycoder[d]: No one is saying we're gonna split any time soon. One project is usually easier to maintain than two.
22:37 airlied[d]: Do we have any rust utils in mesa that are built and executed at build time, like we use python for, or should I just use python to generate rust 🙂
22:43 mhenning[d]: nak does have some proc macros (not sure what you have in mind)
22:44 airlied[d]: I was going to take a run at making a bunch of csv files for the latency category -> war/raw numbers, but using proc_macro seems like a too large hammer, vs just generating rust and including it
22:48 mhenning[d]: Oh, for tables I used a normal macro for some test data from a csv in the zcull stuff which I think worked reasonably well https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33861/diffs?commit_id=8ee9ba704d0d983ab3e39d119cedd2bdc528c34d#0ea5d2c4d86573a64ea962d001d3caf4e74dcde5_0_227
22:49 mhenning[d]: but yeah we can do that or we can use a python script like nil_format_table_gen does
22:49 airlied[d]: the tables aren't that clean though
22:50 mhenning[d]: well, macros are pretty flexible
22:50 mhenning[d]: but also I don't know exactly what you have in mind
22:51 airlied[d]: yeah flexible vs hard to debug 🙂
22:54 airlied[d]: https://paste.centos.org/view/raw/dc576335
22:54 airlied[d]: taking that and making the match reader/writer code
22:57 airlied[d]: might just python it and see how far I get
22:59 mhenning[d]: yeah, python might be a better bet for that