00:00 fdobridge: <S​id> the AUR doesn't pull from there does it :D
00:01 fdobridge: <S​id> nouveau runpm is busted on 6.7.6...
00:02 fdobridge: <S​id> I wonder if it's that way even on -rc
00:02 fdobridge: <m​arysaka> busted in what way?
00:03 fdobridge: <m​arysaka> I had some issues on rc too I think without runpm=0 :aki_thonk:
00:03 fdobridge: <S​id> as in I have warnings/RIPs/stacktraces in my dmesg and the entire system freezes up as soon as I do anything DRM related
00:03 fdobridge: <S​id> never had to set runpm=0 before
00:05 fdobridge: <t​riang3l> though if I fail to upstream my future workaround (replace the exact `vk_pipeline_layout_ref` call in the common secondary command encoder with one for a more generic recounting base struct), I can just lie to the common `vk_pipeline_layout` that all my layouts have 0 sets… but that's ugly and a waste of 256 bytes per pipeline layout 🙃
00:05 fdobridge: <S​id> and even with runpm=0, zink on nvk leads to a system wide freeze
00:05 fdobridge: <t​riang3l> though if I fail to upstream my future workaround (replace the exact `vk_pipeline_layout_ref` call in the common secondary command buffer encoder with one for a more generic recounting base struct), I can just lie to the common `vk_pipeline_layout` that all my layouts have 0 sets… but that's ugly and a waste of 256 bytes per pipeline layout 🙃 (edited)
00:05 fdobridge: <S​id> though
00:05 fdobridge: <S​id> eventually the system manages to kill the app running on zink
00:07 fdobridge: <t​riang3l> though if I fail to upstream my future workaround (replace the exact `vk_pipeline_layout_ref` call in the common secondary command buffer encoder with one for a more generic refcounting base struct), I can just lie to the common `vk_pipeline_layout` that all my layouts have 0 sets… but that's ugly and a waste of 256 bytes per pipeline layout 🙃 (edited)
00:07 fdobridge: <S​id> @airlied just in case
00:07 fdobridge: <S​id> https://cdn.discordapp.com/attachments/1034184951790305330/1212189222874648607/dmesg.log?ex=65f0ee30&is=65de7930&hm=9b3a34c27f80fb3466f0f38e9e6aa159ab6fbada4db654369ce9679d5bd3fd7d&
00:09 fdobridge: <S​id> this log is from zink on nvk
00:10 fdobridge: <S​id> w/ runpm=0
00:13 fdobridge: <S​id> and here's one taken right after boot with runpm=1
00:13 fdobridge: <S​id> https://cdn.discordapp.com/attachments/1034184951790305330/1212190753745276939/dmesg-runpm.log?ex=65f0ef9d&is=65de7a9d&hm=694986855e9669ecb3e4121647c8fa1d19a912c79d845bb01f8e98729da16ac3&
00:27 fdobridge: <p​homes_> I just added Transport Fever 2 to the list of vulkan native games I test with. ~120 fps in menus and loading screen. 2-5 fps in game. Something to look into in the next days 🙂
00:50 fdobridge: <g​fxstrand> oh my...
00:54 fdobridge: <g​fxstrand> If someone wants to perf test something: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27840
01:49 fdobridge: <r​edsheep> I need @ mentions on these lol, went a whole hour of my life without knowing about something new to test
01:53 fdobridge: <a​irlied> @gfxstrand can you see if https://paste.centos.org/view/raw/4b6d6003 helps any 🙂
01:55 fdobridge: <a​irlied> actually might not, but might be worth seeing if it changes behaviour any
02:35 fdobridge: <r​edsheep> Hmm. That's not great, before I could really get into the testing I am seeing that on both that branch and on main heaven can't run on zink anymore ☹️
02:39 fdobridge: <a​irlied> crashes or misrenders?
02:39 fdobridge: <r​edsheep> Oh. So... nvk+zink just doesn't work, at all. It doesn't launch.
02:39 fdobridge: <r​edsheep> ```WARNING: NVK is not a conformant Vulkan implementation, testing use only.
02:39 fdobridge: <r​edsheep> DRI3 not available```
02:39 fdobridge: <r​edsheep>
02:39 fdobridge: <r​edsheep> This just spams over and over and over
02:53 fdobridge: <r​edsheep> I have tested 3 opengl applications now with the same result. @gfxstrand Any idea what might have regressed zink on nvk? I assume zink isn't just broken everywhere or it wouldn't have passed CI
02:57 fdobridge: <g​fxstrand> What? Uh... That's not good.
02:58 fdobridge: <g​fxstrand> Maybe I'm missing an EDS3 feature?
02:58 fdobridge: <g​fxstrand> Let me take a quick look
02:59 fdobridge: <a​irlied> Missing dri3 seems quite wierd
03:00 fdobridge: <m​henning> zink+nvk works here on main (glxgears and blender both work)
03:05 fdobridge: <r​edsheep> Keep in mind when I test I am always running my full session on main. Right now it's a plasma x11 session.
03:05 fdobridge: <r​edsheep> You might not see it if you aren't running your session on it, if this is some disaster with WSI
03:06 fdobridge: <m​henning> Sure, I just wanted to give a data point
03:15 fdobridge: <g​fxstrand> Heaven runs fine here except for the blue blink
03:15 fdobridge: <r​edsheep> Are you able to test your session on it?
03:16 fdobridge: <g​fxstrand> No, not easily
03:16 fdobridge: <g​fxstrand> But I really don't know what would have changed recently that would affect a compositor but not Heaven
03:16 fdobridge: <r​edsheep> Maybe put the icd path in /etc/environment?
03:16 fdobridge: <g​fxstrand> Do you have a known good sha? Can you bisect?
03:16 fdobridge: <r​edsheep> Well I never have before but I can try
03:17 fdobridge: <r​edsheep> It worked well a few days ago, I will try to find a good commit
03:18 fdobridge: <r​edsheep> Before I do, I tested that MR and it's a bit mixed. Without any zink stuff my only consistent tests are vkmark (no change), the witness (33 > 35 increase) and talos principle, which unfortunately regresses from 74 to 60 fps
03:23 fdobridge: <r​edsheep> I have to figure out booting my build before I can bisect... This is going to take a bit
03:26 fdobridge: <g​fxstrand> Hrm... I was hoping to get more out of The Witness. I still suspect queries somewhere. I just need to figure out where.
03:50 fdobridge: <g​fxstrand> I suspect it was either me merging some WSI extensions or shader object (though that one seems very odd)
03:51 fdobridge: <r​edsheep> I am about to start bisecting
03:52 fdobridge: <r​edsheep> It's a good thing I spent most of the last week learning how to actually use git
03:53 fdobridge: <g​fxstrand> 😁
04:37 fdobridge: <g​fxstrand> To be clear, I have no evidence whatsoever that this helps. I just was chatting with @marysaka about how the blob driver does that and how much of a PITA it is to emulate for Switch emulators. I figured they must have a reason so why not try it.
06:11 airlied: dakr: the nvkm client/object rbtree lacks locking doesn't it?
06:28 fdobridge: <S​id> then thar be dragons
06:28 fdobridge: <S​id> `==> dkms install --no-depmod zfs/2.2.99.r365.g8f2f6cd2ac -k 6.8.0-rc6-273-tkg-linux-caco`
06:29 fdobridge: <S​id> it completed successfully too
06:30 fdobridge: <S​id> nope, the runpm regression exists even on this one
06:32 fdobridge: <S​id> I take it back this is much worse
06:32 fdobridge: <S​id> even with runpm=0 I can't launch sway
06:35 fdobridge: <S​id> @airlied you might wanna look into this
06:42 fdobridge: <a​irlied> okay runpm=0 not working seems worse then
06:43 fdobridge: <S​id> I get the same stacktrace whether or not I use runpm=0
06:43 fdobridge: <S​id> on rc6
06:43 fdobridge: <S​id> building rc5 to make sure I didn't have the issue there
06:45 fdobridge: <S​id> same as this one
06:51 fdobridge: <r​hed0x> switch emulators have far bigger problems right now :(
07:04 fdobridge: <S​id> ...oh no it's a problem on rc5 too
07:05 fdobridge: <S​id> at least runpm=0 works on rc5
07:10 fdobridge: <S​id> rc4 time
07:27 fdobridge: <r​edsheep> I suppose I should give an update before I pass out for the night, right before I was about to bisect I decided to do a sanity check by just testing what was as best as I could figure a known working commit based on the timeline of my previous zink testing, and very oddly, that didn't work, so bisecting was pointless.
07:31 fdobridge: <r​edsheep> This sanity check led to many many MANY more sanity checks that slowly made it quite clear that there was no sanity to be found anywhere in the world. That concluded with me back on the previous kernel, 6.7.5, as well as using the AUR built packages I trust on versions that I manually verified. I validated that my environment was actually showing that the right commit was in use for everything, and yet the issue remained.
07:33 fdobridge: <r​edsheep> I am currently in the process of painstakingly putting my system packages back to exactly the state they were in when I was last 100% certain this was working, but that will have to wait until tomorrow to finish.
07:34 fdobridge: <r​edsheep> The weirdest part is it's only the a thing with x11, and not just plasma x11, it's broken on openbox too. The wayland session can use zink fine.
07:36 fdobridge: <r​edsheep> Aside from meson install, which I carefully and manually reversed, I haven't done anything weird except for updating my arch packages. It's probably an arch issue but if I put my packages back there and it's still broken I am completely out of ideas.
07:38 fdobridge: <r​edsheep> TL;DR: Whatever I have going on with my zink is either an arch issue, or I've somehow managed to break my install in a way I can't reverse.
07:44 fdobridge: <S​id> ok so
07:44 fdobridge: <S​id> somewhere between rc4 and rc6
07:44 fdobridge: <S​id> runpm regressed hard
07:44 fdobridge: <S​id> twice.
07:47 fdobridge: <S​id> so on https://github.com/torvalds/linux/commits/master/drivers/gpu/drm/nouveau it's somewhere between 9a0c32d6 and 72fa02fd
07:47 fdobridge: <S​id> unless, something else in the kernel is capable of breaking runpm
07:49 fdobridge: <S​id> `RIP: 0010:r535_gsp_fini+0x4d/0x360 [nouveau]`
07:49 fdobridge: <S​id> hm
08:38 fdobridge: <r​edsheep> Yeah, given the number of packages that updated for the first time since install, and therefore aren't in my cache, it's just not really possible to put my system back into the exact state it was in. If anybody has other ideas about how to debug what's going on with the looping failure to load zink that would be appreciated.
08:45 fdobridge: <t​om3026> "nvidia-gpu 0000:01:00.3: i2c timeout error e0000000" isnt that an error from one of nvidias blobs?
08:46 fdobridge: <t​om3026> https://www.kernel.org/doc/html/latest/i2c/busses/i2c-nvidia-gpu.html what happends if you just blacklist that badboy 😄
08:57 fdobridge: <S​id> makes no difference, only silences that log line
09:02 fdobridge: <S​id> https://github.com/torvalds/linux/commit/9a0c32d698c1d0c4a6f5642ac017da31febad1eb is likely breaking prime runpm
09:02 fdobridge: <S​id> gimme 30 mins and I can say for sure
09:03 fdobridge: <r​edsheep> I think I might just wipe my install entirely tomorrow and if the zink issue is gone then it's likely that something I did while messing with my own mesa build broke my install. If not, then knowing that a clean install+x11+nvk+zink doesn't work is also useful info.
09:22 fdobridge: <S​id> almost done...
09:27 fdobridge: <S​id> kernel debugging got me like
09:27 fdobridge: <S​id> https://xkcd.com/303/
09:28 fdobridge: <S​id> I've been reading a novel while this kernel builds
09:28 fdobridge: <S​id> ..for one reverted commit
09:36 fdobridge: <S​id> nope, time to revert one more :D
09:40 fdobridge: <S​id> 3 minutes of testing
09:40 fdobridge: <S​id> 30 minutes of compiling
09:43 fdobridge: <S​id> I hate this because even ccache doesn't help
09:43 fdobridge: <S​id> since ccache only works on identical sources for whatever reason
09:44 fdobridge: <S​id> so even one function change and ccache stops being used for the entire build, instead writing new cache
09:45 fdobridge: <S​id> if any of you know how to make ccache be used for this please let me know
09:49 fdobridge: <h​untercz122> since when eso and gpl got merged?
09:50 fdobridge: <S​id> about 12h ago
09:50 fdobridge: <S​id> 11*
09:52 fdobridge: <h​untercz122> and does it work little better than previously?
09:52 fdobridge: <h​untercz122> iirc month ago for me in Hat in Time it crashed after certain number
09:53 fdobridge: <S​id> dunno, haven't tested it myself
09:53 fdobridge: <S​id> got sidetracked with testing something else
09:54 fdobridge: <h​untercz122> if i get nvk running in fedora kinoite, then i could try to get a foz dump if that happens again
09:56 fdobridge: <S​id> ..kinoite? that's a new codename
09:56 fdobridge: <S​id> is it just another name for rawhide?
09:57 fdobridge: <h​untercz122> it's atomic fedora with kde plasma
09:57 fdobridge: <h​untercz122> fedora silverblue is with gnome
09:58 fdobridge: <h​untercz122> i like it ngl
09:59 fdobridge: <S​id> ah, silverblue but kde, got you
09:59 fdobridge: <h​untercz122> yeah
09:59 fdobridge: <S​id> anyway, I made a mistake when fixing this merge conflict
09:59 fdobridge: <S​id> so 25 mins into a build I get to change one word and start it again
09:59 fdobridge: <S​id> 🐸
10:00 fdobridge: <S​id> I need to stop using tkg build system for debug builds
10:00 fdobridge: <S​id> since I know for a fact kernels can do dirty builds
10:16 fdobridge: <t​om3026> @sid wut arent you using git bisect?
10:17 fdobridge: <S​id> not at the moment
10:17 fdobridge: <S​id> because based on the call trace and the commit history I had a hunch
10:17 fdobridge: <S​id> which was right
10:18 fdobridge: <t​om3026> oh okey
10:18 fdobridge: <S​id> I built rc4 with these 3 commits and ran into the bug
10:18 fdobridge: <S​id> https://cdn.discordapp.com/attachments/1034184951790305330/1212343060550389810/image.png?ex=65f17d75&is=65df0875&hm=e2221450e59390bbb2bd67930db5034f6d2d49e0df2842bd3d9ad2105fa2d95b&
10:18 fdobridge: <S​id> while plain rc4 didn't have it
10:18 fdobridge: <S​id> so
10:19 fdobridge: <S​id> well, afk for ~45 mins, I'll continue later
12:24 fdobridge: <S​id> so
12:24 fdobridge: <S​id> funny thing
12:25 fdobridge: <S​id> all those commits cause the regression
12:26 fdobridge: <S​id> I tried reverting them one by one on rc5
12:26 fdobridge: <S​id> and still ran into the issue
12:27 fdobridge: <S​id> I tried applying `don't fini` separately, `don't fini + omit`, and all three together
12:27 fdobridge: <S​id> and ran into the issue every time
12:27 fdobridge: <S​id> so now I'm gonna try reverting all three together
12:28 fdobridge: <S​id> and hope I don't run into it, because if I do I will lose my mind 🐸
12:32 fdobridge: <z​mike.> damn that's a big overnight merge
12:32 fdobridge: <z​mike.> now I gotta retest everything
12:39 fdobridge: <k​arolherbst🐧🦀> okay.. so what's this `VM_BIND` thing everyone is talking about and how would I use it? :ferrisCluelesser:
12:48 fdobridge: <S​id> ...wtf
13:23 fdobridge: <S​id> damn
13:23 fdobridge: <S​id> who would've thought the build scripts I used for kernels... 3-odd years ago would come in handy today
14:08 fdobridge: <z​mike.> no glcts regressions \o/
14:08 fdobridge: <z​mike.> this util_vma free crash is insane though
14:08 fdobridge: <z​mike.> I can't believe nobody else can repro
14:08 fdobridge: <g​fxstrand> 🥳
14:09 fdobridge: <g​fxstrand> I haven't tried yet. I think today is going to be Zink fixing day
14:09 fdobridge: <z​mike.> ooo
14:09 fdobridge: <g​fxstrand> That and trying to merge sparse if we can
14:09 fdobridge: <z​mike.> brave
14:09 fdobridge: <g​fxstrand> I just landed GPL and ESO in one MR. I have no fear!
14:13 fdobridge: <z​mike.> truly you must not
14:18 fdobridge: <z​mike.> `KHR-GLES3.copy_tex_image_conversions.forbidden*` fails might be a good place to start since they fail on nv blob too
14:34 fdobridge: <S​id> fuck yes
14:34 fdobridge: <S​id> `Build completed in 2 minute(s) and 31 seconds.`
14:34 fdobridge: <S​id> >:]
14:40 fdobridge: <z​mike.> think I managed to fix airlied's buffer alignment issue...
15:02 meymar: it might be correct as to what scala does, imagine you take a modulo from the set based of some constants and division is the base. you always come out with ascending type of order as to what to add the base to allocate one or two elements for an example, and you only need to know the count of the set in such case. https://github.com/scala/scala/blob/v2.12.1/src/library/scala/collection/BitSetLike.scala where as the inner pos is supervision they took
15:02 meymar: 64 as the step though. Now you can just remove the remainder out of another set.
15:29 fdobridge: <z​mike.> :stressheadache: I broke another case
15:43 fdobridge: <z​mike.> nope just another cts bug
15:44 fdobridge: <g​fxstrand> 🤡
15:47 fdobridge: <z​mike.> it turns out literally nobody has ever run glcts on an implementation without BAR
15:59 fdobridge: <p​rop_energy_ball> not having any BAR is def going to be problematic
15:59 fdobridge: <p​rop_energy_ball> across the board
15:59 fdobridge: <g​fxstrand> @airlied is working on it
16:00 fdobridge: <g​fxstrand> Once we have the kinks worked out, I'll happily enable BAR on everything back to Maxwell.
16:00 fdobridge: <g​fxstrand> It may be in its own heap to encourage apps to keep BAR pressure down but we should be able to turn it on.
16:01 fdobridge: <k​arolherbst🐧🦀> @gfxstrand soo.. do I `VM_BIND` correctly, that the only difference is, that once you allocate the VM via `DRM_NOUVEAU_VM_INIT` userspace is responsible for assigning an address via `DRM_NOUVEAU_VM_BIND` or is there anything else to it?
16:01 fdobridge: <p​rop_energy_ball> wishful thinking =)
16:01 fdobridge: <g​fxstrand> You're also required to use the new subit API.
16:01 fdobridge: <k​arolherbst🐧🦀> will `DRM_NOUVEAU_GEM_NEW` still assign an address or is that `0`?
16:01 fdobridge: <k​arolherbst🐧🦀> mhhhhh
16:01 fdobridge: <g​fxstrand> Keeping bar usage down? Yeah, I know.
16:02 fdobridge: <g​fxstrand> No, it doesn't assign you an address. BOs are not automatically mapped in the GPU VA at all.
16:02 fdobridge: <p​rop_energy_ball> gamescope only needs it because I am lazy and didnt want to write a staging fallback
16:02 fdobridge: <!​DodoNVK (she) 🇱🇹> How about Kepler? 🐸
16:02 fdobridge: <g​fxstrand> Oh, and you no longer have implicit sync, either. That'll be fun to sort out.
16:02 fdobridge: <k​arolherbst🐧🦀> okay, so `GEM_NEW` changes once the process allocated a vm via `DRM_NOUVEAU_VM_INIT`
16:02 fdobridge: <k​arolherbst🐧🦀> or uhm.. the fd I guess
16:03 fdobridge: <g​fxstrand> @airlied and I have a theory on Kepler. We're thinking that we may not be setting up the PTEs correctly and that kepler is tiling our maps. That would be consistent with the very weird tiling behavior I was seeing as well as with the Kepler-only WSI issues.
16:03 fdobridge: <g​fxstrand> Yup. It goes into a new mode where, apart from getparam, you basically have an entirely new UAPI
16:03 fdobridge: <k​arolherbst🐧🦀> but yeah.. I have to see how easy it would be to map the libdrm push interface on top of the new submit API
16:03 fdobridge: <k​arolherbst🐧🦀> what abbout channel/subchannel allocation?
16:04 fdobridge: <g​fxstrand> You could write a "allocate in system ram" fallback. 😛
16:04 fdobridge: <g​fxstrand> That's also the same
16:04 fdobridge: <k​arolherbst🐧🦀> okay
16:04 fdobridge: <k​arolherbst🐧🦀> that's not too bad then I hope
16:11 fdobridge: <g​fxstrand> The hard part will be implicit sync
16:22 fdobridge: <p​avlo_it_115> Day 2. Trying to build /VK-GL-CTS/external/vulkancts/scripts/build_mustpass.py. The assembly stops at the 1132 point. It says -
16:22 fdobridge: <p​avlo_it_115> ```
16:22 fdobridge: <p​avlo_it_115> /VK-GL-CTS/external/vulkancts/modules/vulkan/descriptor_indexing/vktDescriptorSetsIndexingTests.cpp:4640:1: fatal error: error writing to /tmp/cczGxsBK.s: Not enough space on device```
16:22 fdobridge: <p​avlo_it_115> 🤔
16:24 fdobridge: <p​avlo_it_115> Day 2. Trying to build /VK-GL-CTS/external/vulkancts/scripts/build_mustpass.py. The assembly stops at the 1132 point. It says -
16:24 fdobridge: <p​avlo_it_115> ```
16:24 fdobridge: <p​avlo_it_115> /VK-GL-CTS/external/vulkancts/modules/vulkan/descriptor_indexing/vktDescriptorSetsIndexingTests.cpp:4640:1: fatal error: error writing to /tmp/cczGxsBK.s: Not enough space on device```
16:24 fdobridge: <p​avlo_it_115> But I have about 50GB of space available (edited)
16:26 fdobridge: <g​fxstrand> @zmike. my quick try failed to repro !10654 as well. 😢 Valgrind didn't even tell me anything.
16:26 fdobridge: <g​fxstrand> You don't need to run build_mustpass.py
16:27 fdobridge: <g​fxstrand> Just run `external/fetch_sources.py`, `cmake`, and then build it.
16:27 fdobridge: <p​avlo_it_115> I have already build cts
16:27 fdobridge: <k​arolherbst🐧🦀> okay.. I already hit the first bug :ferrisUpsideDown:
16:28 fdobridge: <p​avlo_it_115> According to the instructions, you need to specify these command line options
16:28 fdobridge: <p​avlo_it_115> https://cdn.discordapp.com/attachments/1034184951790305330/1212436273281892452/1b3b06160ac4207a.png?ex=65f1d445&is=65df5f45&hm=2398072f46dc0d1adfb4b285d6254d970fde06c5b94f99f76ba29840573552f2&
16:29 fdobridge: <g​fxstrand> That's only for if you're doing a formal conformance submission run
16:30 fdobridge: <g​fxstrand> Most of the time, I use deqp-runner which makes it all run parallel
16:30 fdobridge: <p​rop_energy_ball> storing planes for gpu scanout and huge 3D LUTs with tetrahedral interp in system ram sounds terrifying
16:31 fdobridge: <p​avlo_it_115> In short, it complains about the --deqp-caselist-file=vk-default.txt that there he did not find the first line in the file and I went to build build_mustpass.py
16:31 fdobridge: <p​avlo_it_115> In short, it complains about the --deqp-caselist-file=vk-default.txt that there he did not find the first line in the file and I went to build "build_mustpass.py" (edited)
16:32 fdobridge: <g​fxstrand> Yeah, that's maybe not a good idea.
16:32 fdobridge: <g​fxstrand> I've literally never run `build_mustpass.py`
16:32 fdobridge: <p​avlo_it_115> Thank you, but what parameter should I put there?
16:33 fdobridge: <p​avlo_it_115> [any|none|amber]
16:33 fdobridge: <g​fxstrand> In where?
16:33 fdobridge: <g​fxstrand> You can just run `./deqp-vk`
16:33 fdobridge: <p​avlo_it_115> Oh..
16:33 fdobridge: <g​fxstrand> Or `./deqp-vk -n TEST_NAME` if you have a particular test you want to run
16:34 fdobridge: <p​avlo_it_115> Well, you just said it and I decided to see what was here
16:34 fdobridge: <p​avlo_it_115> https://cdn.discordapp.com/attachments/1034184951790305330/1212437744882688010/7075ca7e0431a2a2.png?ex=65f1d5a4&is=65df60a4&hm=417b6a77b877a6656c3e4b7791b91607b616055e529ba7257c3e1122e9d43984&
16:35 fdobridge: <g​fxstrand> Oh, don't worry about that flag
16:35 fdobridge: <g​fxstrand> I mean deqp-runner from https://gitlab.freedesktop.org/anholt/deqp-runner
16:35 fdobridge: <p​avlo_it_115> 😅
16:43 fdobridge: <k​arolherbst🐧🦀> okay.. so there are `VM_BIND` cleanup problems
16:43 fdobridge: <k​arolherbst🐧🦀> is it safe to use with 6.7?
16:43 fdobridge: <z​mike.> I don't understand how nobody else can repro this 🤔
16:44 karolherbst_: dakr, airlied: so it seems if you call DRM_NOUVEAU_VM_INIT and then just terminate the process, the kernel dead locks inside `drm_postclose`
16:44 karolherbst_: at least with 6.7.5
16:44 fdobridge: <z​mike.> also speaking of deqp-runner it'd be cool if we had someone looking at the issues there since I don't think anholt is going to be doing any work on it in the future
16:45 karolherbst: is this issue known to you and is there a fix for that?
16:46 fdobridge: <g​fxstrand> Oh, that's fun...
16:46 karolherbst: mhh.. maybe I should write a simple reproducer
16:47 fdobridge: <k​arolherbst🐧🦀> yeah.. and something we should figure out before moving the GL driver over, because what happened here is, that I ran into the assert inside `glsl_type_singleton_decref`, the process hangs forever and at some point the intel side stops displaying :ferrisUpsideDown:
16:48 fdobridge: <k​arolherbst🐧🦀> like.. the old pushbuf ioctl returned an error and nouveau doesn't increase the ref early enough
16:48 fdobridge: <k​arolherbst🐧🦀> anyway
16:48 fdobridge: <k​arolherbst🐧🦀> I shouldn't develop on my working machine 😄
16:48 fdobridge: <k​arolherbst🐧🦀> or uhm.. run the stuff
16:49 fdobridge: <k​arolherbst🐧🦀> let's see if I can figure out where it hangs
16:58 fdobridge: <z​mike.> 🤕
16:58 fdobridge: <z​mike.> @gfxstrand I think it's time to get out your boxing gloves
16:59 fdobridge: <z​mike.> 🥊
16:59 fdobridge: <g​fxstrand> Oh?
17:00 fdobridge: <z​mike.> ARB_shader_image_load_store requires that you support multisample-typed images in shaders
17:00 fdobridge: <z​mike.> not necessarily running those shaders
17:00 fdobridge: <z​mike.> but compiling them
17:00 fdobridge: <g​fxstrand> Wait, what?
17:00 fdobridge: <g​fxstrand> 😭
17:00 fdobridge: <z​mike.> yup
17:00 fdobridge: <z​mike.> KHR-GL46.gl_spirv.spirv_validation_capabilities_test enforces this, which is why it crashes
17:01 fdobridge: <z​mike.> arguably some base ARB_shader_image_load_store test should hit it too, but that's whatever
17:01 fdobridge: <g​fxstrand> That shouldn't be too hard. I probably just need to drop some asserts.
17:01 fdobridge: <z​mike.> yes
17:01 fdobridge: <z​mike.> exactly that
17:01 fdobridge: <g​fxstrand> Makes me sad, though, because I don't like compiling code I can't run
17:01 fdobridge: <z​mike.> I think probably for now you can just say "if I get this dim, the shader will not be used"
17:01 fdobridge: <g​fxstrand> How do I tell Zink to stop threading shader compiles?
17:01 fdobridge: <z​mike.> ZINK_DEBUG=nobgc
17:02 fdobridge: <g​fxstrand> 👍🏻
17:04 fdobridge: <g​fxstrand> Oh, good... This tessellation test is compiling 30 tessellation shaders. I wonder which one is the problem.
17:05 karolherbst: dakr, airlied: another thing: https://gist.githubusercontent.com/karolherbst/a20eb0f937a06ed6aabe2ac2ca3d11b5/raw/9cd8b1dc5894872d0eeebbee3dd0fdd28bb576bc/gistfile1.txt
17:05 fdobridge: <z​mike.> if you find annoying tests like that, add to https://gitlab.khronos.org/Tracker/vk-gl-cts/-/issues/3467
17:05 karolherbst: but also.. why am I on a debug kernel now...
17:06 Sid127: does anyone know how to auto-trigger dkms for a kernel I installed using `make module_install`
17:06 fdobridge: <k​arolherbst🐧🦀> @gfxstrand when do you want the modifier situation figured out? for 24.1?
17:07 fdobridge: <z​mike.> also you can do ZINK_DEBUG=noopt to disable optimized pipelines after precompile; so nobgc,noopt and you get single variant sync shader compile
17:08 fdobridge: <g​fxstrand> I think my plan of just not enabling modifiers for WSI is good enough for now. If distros run Zink, they can carry a 1-line patch to enable the bit.
17:09 fdobridge: <k​arolherbst🐧🦀> okay
17:09 fdobridge: <g​fxstrand> Okay, only 32 tessellation shaders with `noopt`
17:10 fdobridge: <k​arolherbst🐧🦀> I'll probably setup my desktop for VM_BIND development next week then, because tomorrow I have other plans and then it's already friday :ferrisUpsideDown:
17:10 fdobridge: <k​arolherbst🐧🦀> might just clean up the moving libdrm_nouveau into mesa part this week and get that landed as this might just be the biggest part here anyway
17:11 fdobridge: <k​arolherbst🐧🦀> and get those missing uapi bits into the header as well
17:21 fdobridge: <m​arysaka> Should be ready for review again :SoniiPray:
17:22 fdobridge: <p​avlo_it_115> @gfxstrand And how did you start writing the NVK driver? What documentation did you use or something similar? I just want to delve into it and fully understand it
17:22 fdobridge: <k​arolherbst🐧🦀> :ferrisUpsideDown:
17:23 fdobridge: <k​arolherbst🐧🦀> am I lucky that I won't have to answer that question
17:23 fdobridge: <p​avlo_it_115> I understand that I've already bored you all = ), but I want to learn how to do it
17:24 fdobridge: <S​id> experience
17:24 fdobridge: <S​id> faith has been writing driver code for much longer than NVK has been a thing
17:26 fdobridge: <S​id> the thing is, you can't really implement most functions without understanding how the hardware works...
17:26 fdobridge: <S​id> you *could* somewhat learn how it works by reading what's already there though
17:26 fdobridge: <g​fxstrand> I referenced the old nouveau GL driver some. Having headers from NVIDIA with method and bitfield names has been super helpful.
17:27 fdobridge: <g​fxstrand> As far as the rest of it... I'm the person everyone else in Mesa copies and pastes from to write their drivers. 😅
17:28 fdobridge: <g​fxstrand> I've been writing Vulkan drivers since before Vulkan was a thing. 😄
17:28 fdobridge: <S​id> I knew you were working on/with intel drivers before this, but I didn't know for how long :D
17:28 fdobridge: <S​id> tbh I still think what pac85 suggested was a good approach
17:28 fdobridge: <S​id> learn some graphics programming first, then attempt driver code
17:29 fdobridge: <k​arolherbst🐧🦀> it always kinda depends on the person
17:29 fdobridge: <S​id> that too
17:29 fdobridge: <g​fxstrand> Yeah, the Intel driver was developed in tandem with the Vulkan spec and I was working on both sides (driver and spec) for about 9 months before Vulkan 1.0 was released.
17:29 fdobridge: <S​id> figures, I did see your name on some very old spec man pages
17:29 fdobridge: <p​ixelcluster> i also followed the graphics programming -> driver programming path
17:29 fdobridge: <g​fxstrand> Eh, knowing graphics programming isn't necessary to write drivers. They're actually fairly different skillsets.
17:30 fdobridge: <p​ixelcluster> in fact, I think around the time vulkan 1.0 released i was tinkering around in unity trying to figure out what this stupid "vertex" thing was
17:30 fdobridge: <p​ixelcluster> :D
17:30 fdobridge: <g​fxstrand> But it is good to have at least a decent high-level understanding of graphics APIs, how they flow, and what they're trying to do.
17:30 fdobridge: <S​id> vulkan 1.0, 16th feb 2016...
17:31 fdobridge: <S​id> back in 2016 I was dual booting win8 and ubuntu on a shitty hp pavilion
17:32 fdobridge: <S​id> to explore what exactly this "linux" thing was
17:32 fdobridge: <g​fxstrand> Y'all are making me feel old. 😂
17:32 fdobridge: <S​id> didn't really care for code or foss or whatever back then
17:32 fdobridge: <S​id> simpler times
17:32 fdobridge: <S​id> well
17:33 fdobridge: <S​id> back in 2016 I was in the 8th grade :>
17:33 fdobridge: <S​id> sorry faith :P
17:34 fdobridge: <S​id> when vk 1.0 released I was actually still in the 7th grade..
17:34 fdobridge: <r​edsheep> Does this make it more obvious what is happening with my zink? In particular ```Error: couldn't find RGB GLX visual or fbconfig```
17:34 fdobridge: <r​edsheep> https://cdn.discordapp.com/attachments/1034184951790305330/1212452874462957568/cursedZink.txt?ex=65f1e3bb&is=65df6ebb&hm=212e360691d124a1848e9675a7a099f7ba0185a4e4cb2647487d619b86d20bee&
17:35 fdobridge: <t​om3026> im 35 if that helps.
17:35 fdobridge:<S​id> is 20
17:35 fdobridge: <t​om3026> i was around bugging karolherbst when the 780ti was the top of the line
17:35 fdobridge: <t​om3026> 😄
17:35 fdobridge: <r​edsheep> 27 here and I already feel plenty old
17:35 fdobridge: <S​id> afaik pixelcluster is younger than I am
17:35 fdobridge: <p​ixelcluster> i'm 18 :3
17:36 fdobridge: <!​DodoNVK (she) 🇱🇹> Is that code still available?
17:37 fdobridge: <k​arolherbst🐧🦀> in git probably?
17:37 fdobridge: <g​fxstrand> Yeah, it's called the Intel Vulkan driver. The git history goes back 9 months before the spec was released. We did an actual merge (one of like 3 in Mesa's history) to maintain the history.
17:38 fdobridge: <g​fxstrand> Not really...
17:38 fdobridge: <k​arolherbst🐧🦀> how old
17:38 fdobridge: <k​arolherbst🐧🦀> :ferrisUpsideDown:
17:38 fdobridge: <t​om3026> you cant be much further
17:38 fdobridge: <g​fxstrand> It's totally okay, though. I love how many younger people we have in here and the energy that's forming around NVK. I don't mind at all.
17:38 fdobridge: <k​arolherbst🐧🦀> I'm not, but you are still older 😛
17:39 fdobridge: <t​om3026> haha oh well im winning something then
17:39 fdobridge: <t​om3026> AND YOU CANT CATCH ME
17:39 fdobridge: <S​id> I wish I had the time to learn this side of programming
17:39 fdobridge: <k​arolherbst🐧🦀> do it like I do
17:39 fdobridge: <k​arolherbst🐧🦀> jump straight into it being oblivious of everything
17:40 fdobridge: <S​id> I never really learned how to read code, so doing that will only really end up frustrating me
17:40 fdobridge: <g​fxstrand> You've got plenty of time.
17:40 fdobridge: <S​id> and, well, physics major + irl stuff keeps me from putting in much time
17:40 fdobridge: <k​arolherbst🐧🦀> well... I kinda started to program around 14/15 doing HTML/JS stuff 😄
17:41 fdobridge: <S​id> I can write semi-competent code in various languages, but
17:41 fdobridge: <S​id> this is a bit too low level for my current understanding
17:41 fdobridge: <k​arolherbst🐧🦀> ahh, so like me when I started to dive into nouveau :ferrisUpsideDown:
17:41 fdobridge: <t​om3026> where did imirkin go btw
17:41 fdobridge: <S​id> and I still can barely do frontend
17:41 fdobridge: <z​mike.> practically down to zero
17:41 fdobridge: <k​arolherbst🐧🦀> you want the PR story or the real story?
17:41 fdobridge: <g​fxstrand> Yeah, Java to graphics drivers was quite the jump. 😅
17:41 fdobridge: <p​avlo_it_115> I understand you :)
17:41 fdobridge: <k​arolherbst🐧🦀> I did some C/C++ tho in my spare time kinda
17:41 fdobridge: <t​om3026> oh idk i just remember him being the guru back then with nouveau stuff, havent seen him around heh
17:41 fdobridge: <S​id> so I contribute in the way I know I can
17:42 fdobridge: <k​arolherbst🐧🦀> more ObjC than C, but still
17:42 fdobridge: <S​id> which is wait for kernels to build for longer than it takes to reproduce a bug :D
17:42 fdobridge: <S​id> ~~and bother dave about them until he caves in and fixes it~~
17:42 fdobridge: <t​riang3l> For me it's game porting > console emulation > driver development (and game GPU work submission development at work)… The second is why things like rasterization rules, subPixelPrecisionBits and rounding directions are unusually important to me probably compared to all of the games industry 🥵
17:42 fdobridge: <g​fxstrand> Honestly, testing stuff out, bisecting, reproducing bugs, etc. is actually really helpful.
17:42 fdobridge: <S​id> oh I know
17:42 fdobridge: <m​arysaka> I was doing uuuumm Java bytecode injection at 15 *for that one game*
17:43 fdobridge: <S​id> I still wanna contribute in a "bigger" way for personal satisfaction though
17:43 fdobridge: <g​fxstrand> Even just posting screenshots of games running does wonders for moral
17:43 fdobridge: <S​id> fwiw
17:43 fdobridge: <g​fxstrand> Yeah, I get that. One day you will.
17:43 fdobridge: <S​id> as soon as sparse residency lands I'm jumping to nvk full time
17:43 fdobridge: <S​id> with nvidia being the side driver
17:43 fdobridge: <g​fxstrand> No pressure on @mohamexiety , then. 😅
17:44 fdobridge: <g​fxstrand> Actually, I think we can probably land it once the two of us decide to give up on YCbCr.
17:44 fdobridge: <m​arysaka> *needs to play her games and test on NVK*
17:44 fdobridge: <m​ohamexiety> yeaaah 😂
17:44 fdobridge: <S​id> as soon as quake champions gets going, nvidia can rest
17:44 fdobridge: <t​riang3l> Are there even really opportunities for getting that feeling in the world at this moment? 🐸 Maybe in PS4/PS5 emulation, Turnip on A4xx… and :triangle_nvk: on Tesla
17:44 fdobridge: <S​id> since I play that one in tournaments as well
17:44 fdobridge: <S​id> everything else I don't mind putting on hold
17:45 fdobridge: <k​arolherbst🐧🦀> I had the same thought today :ferrisUpsideDown:
17:45 fdobridge: <S​id> I wonder how well sable runs on nvk..
17:45 fdobridge: <g​fxstrand> Oh, I exclusively game on consoles where I'm not on the hook for fixing bugs. That way gaming and work don't mix too badly.
17:46 fdobridge: <S​id> that's fair
17:46 fdobridge: <S​id> meanwhile I'm considering applying to a gamedev studio as contract QA
17:46 fdobridge: <m​arysaka> My PS5 is taking dust 😅
17:46 fdobridge: <t​riang3l> Kind of why I like Counter-Strike now
17:46 fdobridge: <t​riang3l> Kind of why I like Counter-Strike now 🐦 (edited)
17:46 fdobridge: <r​hed0x> CS2 works, that covers most of my gaming 🙃
17:46 fdobridge: <z​mike.> you illegally merged GPL without enabling VK_KHR_pipeline_library :fullheadache:
17:46 fdobridge: <g​fxstrand> Go for it if you want to.
17:46 fdobridge: <t​riang3l> I still die a lot, so I can code while gaming
17:47 fdobridge: <g​fxstrand> Wait, what? 🤦🏻‍♀️
17:47 fdobridge: <S​id> I just really want some source of income so I can spend on my hobbies and stuff better
17:47 fdobridge: <z​mike.> I assume you just forgot to set the bit
17:47 fdobridge: <S​id> and can feel like less of a burden on my aging parents
17:47 fdobridge: <S​id> not even expecting very much rn
17:48 fdobridge: <S​id> even 50-100 eurodollars a month will go a long way
17:48 fdobridge: <!​DodoNVK (she) 🇱🇹> Isn't that for 🔦 stuff?
17:49 fdobridge: <z​mike.> tf is 🔦
17:49 fdobridge: <r​hed0x> rt
17:49 fdobridge: <z​mike.> oh
17:49 fdobridge: <r​hed0x> @asdqueerfromeu https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VK_EXT_graphics_pipeline_library.html
17:49 fdobridge: <z​mike.> :hypertensionheadache:
17:49 fdobridge: <r​hed0x> also dependency there
17:49 fdobridge: <k​arolherbst🐧🦀> :ferrisCowboyRTX:
17:50 fdobridge: <S​id> woa
17:50 fdobridge: <S​id> forgot to set localmodconfig in my build env
17:50 fdobridge: <!​DodoNVK (she) 🇱🇹> GPL in DXVK worked without that extension though
17:50 fdobridge: <g​fxstrand> Okay, let me fix that quick.
17:50 fdobridge: <S​id> almost built the full kernel :D
17:50 fdobridge: <t​riang3l> Assert generation time? :cursedgears:
17:50 fdobridge: <t​riang3l> Though nothing stops drivers from setting up extensions after initializing the device base
17:51 fdobridge: <t​riang3l> Though nothing stops drivers from setting up extensions after initializing the physical device base (edited)
17:51 fdobridge: <r​hed0x> because that extension doesnt really do much on its own
17:51 fdobridge: <r​hed0x> and dxvk doesnt care whether its present
17:52 fdobridge: <p​ixelcluster> it really isn't useful for anything on its own
17:52 fdobridge: <p​ixelcluster> it really isn't useful for anything at all on its own (edited)
17:52 fdobridge: <t​riang3l> Who would win? Huge merge request for :triangle_nvk:, or one smol VK_PIPELINE_CREATE_LIBRARY_BIT_KHR?
17:52 fdobridge: <t​riang3l> a bit more useful than VK_NV_low_latency :frog_gears:
17:53 fdobridge: <p​ixelcluster> on its own? nah
17:53 fdobridge: <g​fxstrand> I'm just surprised this didn't trigger a CTS failure
17:53 fdobridge: <g​fxstrand> Or maybe it did but it was in that one test that always fails whenever you do new stuff so I didn't notice.
17:53 fdobridge: <m​arysaka> Actually I technically play more on switch than PC :nya_panic:
17:54 fdobridge: <S​id> dump your games
17:54 fdobridge: <S​id> test ryujinx/yuzu
17:54 fdobridge: <S​id> :D
17:54 fdobridge: <p​ixelcluster> the only console I have here (besides the deck ig) is a switch and it’s collecting dust :)
17:54 fdobridge: <r​hed0x> maybe not the best time for that right now... 🐸
17:54 fdobridge: <S​id> well maybe not yuzu now..
17:54 fdobridge: <g​fxstrand> That'll be fixed in about an hour. I added it to my "we're a real Vulkan driver now" MR.
17:54 fdobridge: <S​id> wait
17:55 fdobridge: <r​hed0x> @gfxstrand forget about consoles, how many gpus do you have lying around? :)
17:55 fdobridge: <S​id> we're a real vulkan driver in an hour? :O
17:55 fdobridge: <S​id> how do the zoomers say it, uh
17:55 fdobridge: <S​id> based, yes
17:56 fdobridge: <S​id> ||I don't understand gen-z lingo very much despite being gen-z myself||
17:56 fdobridge: <g​fxstrand> I've got like 8 different NVIDIA generations, 4 or 5 Intel, 3 or 4 different Mali, a Qualcomm, and most of the raspberry pis.
17:56 fdobridge: <g​fxstrand> Oh, and one AMD, two if you count my deck.
17:57 fdobridge: <g​fxstrand> Oh, and one AMD, two if you count my deck, and 4 if you count playstations. (edited)
17:57 fdobridge: <r​hed0x> i have my ampere card in active use, a 1070 in the box of that and a steam deck
17:57 fdobridge: <r​hed0x> ye and 2 playstations
17:57 fdobridge: <a​irlied> @zmike is util_vma crash the same something shits on the stack and it crashes randomly in device teardown?
17:57 fdobridge: <z​mike.> yes
17:58 fdobridge: <z​mike.> I have a new repro case but it takes a while so I'm looking for other ones
17:58 fdobridge: <a​irlied> I can reproduce the crashes because something shits on the stack in device teardown just not in util_vma
17:58 fdobridge: <a​irlied> but it involves running a lot of CTS tests that are alow
17:58 fdobridge: <z​mike.> yes
17:58 fdobridge: <z​mike.> that's what I'm experiencing
17:58 fdobridge: <z​mike.> trying all my caselists now to see if I can find one that's faster
17:59 fdobridge:<f​ooishbar> raises (1 << 56) eyebrows
18:00 fdobridge: <S​id> :|
18:00 fdobridge: <S​id> zfs dkms builds when I install 6.8-rc6 using linux-tkg pkgbuild
18:00 fdobridge: <S​id> but fails when I build it on the rc6 I built and installed manually
18:00 fdobridge: <S​id> wat
18:00 fdobridge: <g​fxstrand> Meanwhile, I'm trying to look at this tessellation hang between juggling other things.
18:00 fdobridge: <r​edsheep> And now I know how to not build the entire kernel... My poor cpu every time I was testing kernel patches :blobcatnotlikethis:
18:01 fdobridge: <g​fxstrand> It's an OOB which are usually pretty easy to find but there are 16 variants and the GL CTS is decidedly unhelpful in its reporting.
18:01 fdobridge: <a​irlied> @karolherbst I could possibly be persauded to let the old exec path work with vm bind
18:01 fdobridge: <S​id> I stopped using the pkgbuild because it was annoying to rebuild the whole thing from scratch for one commit
18:01 fdobridge: <z​mike.> usually I end up editing the cts case to only run a single iteration
18:02 fdobridge: <k​arolherbst🐧🦀> yeah.. no idea how painful the new one would be for the GL driver, let me find out next week or so
18:02 fdobridge: <a​irlied> at least for GL I think you can just allocate the BO and immediately allocate the VM space for it until you get to sparse
18:02 fdobridge: <k​arolherbst🐧🦀> yeah..
18:02 fdobridge: <k​arolherbst🐧🦀> that was my plan
18:02 fdobridge: <S​id> and because I already had an old build script lying around to build flashable kernel zips for android devices :D
18:02 fdobridge: <k​arolherbst🐧🦀> @airlied what's the main reason to disable the old submit path with VM_BIND?
18:02 fdobridge: <S​id> well, I guess I'll start this bisect
18:03 fdobridge: <a​irlied> because we don't want to use the old submit path with vm bind
18:03 fdobridge: <k​arolherbst🐧🦀> mhhh
18:03 fdobridge: <a​irlied> I've no actual idea if it can be made work
18:03 fdobridge: <k​arolherbst🐧🦀> yeah, maybe we both look into those things and then discuss next week
18:04 fdobridge: <k​arolherbst🐧🦀> if it's trivial on the kernel side, I won't have to rework the gl driver, which I guess might be required...
18:04 fdobridge: <k​arolherbst🐧🦀> not sure how easy it would be to layer the old on top of the new one
18:04 fdobridge: <S​id> oh, I see
18:04 fdobridge: <S​id> I'm ahead of rc6 tag
18:04 fdobridge: <S​id> makes sense
18:04 fdobridge: <a​irlied> well the new one has no relocations etc
18:04 fdobridge: <S​id> pain `Bisecting: 411 revisions left to test after this (roughly 9 steps)`
18:05 fdobridge: <S​id> except
18:05 fdobridge: <g​fxstrand> Relocations aren't important but implicit sync is
18:05 fdobridge: <g​fxstrand> That's the big pain for doing nouveau GL on the VM_BIND path
18:05 fdobridge: <k​arolherbst🐧🦀> mhhhh, that's not a problem
18:05 fdobridge: <k​arolherbst🐧🦀> the old could still return ENOSYS if you submit with relocs
18:06 fdobridge: <k​arolherbst🐧🦀> that's just for nv30
18:06 fdobridge: <a​irlied> yeah you'd have to hack the kernel to let the new path run and see what explodes, now I look at it, it'll probably explode unfortunately
18:07 fdobridge: <k​arolherbst🐧🦀> @airlied does the VM_BIND ioctl have any gpu chipset checks?
18:07 fdobridge: <k​arolherbst🐧🦀> because it should just fail on pre nv50 GPUs
18:07 fdobridge: <k​arolherbst🐧🦀> not sure if nv50 should work, because that's 32 bit pointers
18:08 fdobridge: <a​irlied> yeah we should fail VM_INIT on pre-nvc0 I think
18:09 fdobridge: <a​irlied> we probably don't
18:09 fdobridge: <k​arolherbst🐧🦀> yeah.. not that I plan to use VM_BIND there, but the kernel should still bail
18:10 fdobridge: <z​mike.> @airlied `KHR-GL46.tessellation_shader.vertex.vertex_spacing` is the one
18:10 fdobridge: <k​arolherbst🐧🦀> @airlied also.. I need those things added to UAPI: https://gitlab.freedesktop.org/karolherbst/mesa/-/blob/nouveau/libdrm_import/src/gallium/winsys/nouveau/drm/nouveau.h?ref_type=heads#L202-220
18:10 fdobridge: <z​mike.> or at least this test running in any caselist triggers the crash on exit
18:11 fdobridge: <k​arolherbst🐧🦀> @airlied `NVE0_FIFO_ENGINE_GR` are hardcoded values in https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/nouveau/nouveau_abi16.c?h=v6.8-rc6#n312
18:12 fdobridge: <k​arolherbst🐧🦀> should I write and send a patch for that?
18:12 fdobridge: <a​irlied> yeah might be nice to clean it up, I had to hack that to get nvdec to work
18:12 fdobridge: <k​arolherbst🐧🦀> yeah...
18:12 fdobridge: <k​arolherbst🐧🦀> I cleaned up that part of libdrm, because it's just.. uhhh
18:12 fdobridge: <k​arolherbst🐧🦀> hard to follow
18:13 fdobridge: <k​arolherbst🐧🦀> but the code in the MR should be a way better source to look up how things work
18:13 fdobridge: <k​arolherbst🐧🦀> on all gens with all their funky features
18:13 fdobridge: <g​fxstrand> Including by itself?
18:13 fdobridge: <z​mike.> yes
18:14 fdobridge: <a​irlied> nice, does it device lost?
18:14 fdobridge: <z​mike.> no
18:14 fdobridge: <z​mike.> have there been any people looking to get involved who know rust but not drivers?
18:15 fdobridge: <z​mike.> because we really could use some active deqp-runner development
18:15 fdobridge: <z​mike.> it would be massively helpful for everyone in mesa
18:15 fdobridge: <g​fxstrand> @fooishbar asked me to keep an eye on it but IDK if I've got the time to do it all myself.
18:16 fdobridge: <r​hed0x> before I open the MR, nested_command_buffer is really just a matter of reporting support for the extension and the associated features, right?
18:17 fdobridge: <r​hed0x> its just copying pushbufs across, so it should just work
18:17 fdobridge: <r​hed0x> ExceuteCommandBuffers its just copying pushbufs across, so it should just work (edited)
18:17 fdobridge: <r​hed0x> ExceuteCommandBuffers is just copying pushbufs across, so it should just work (edited)
18:17 fdobridge: <g​fxstrand> Probably? There may be some cases of SECONDARY that should be ! PRIMARY or vice versa
18:17 fdobridge: <S​id> you know, installing kernels and running dkms manually feels really wrong...
18:18 fdobridge: <S​id> kernels outside of a package manager, I mean 😅
18:18 fdobridge: <S​id> but hey
18:18 fdobridge: <S​id> one step closer to Linux From Scratch
18:18 fdobridge: <g​fxstrand> I can't wait until I can start running kernels from a package manager again. 😢
18:18 fdobridge: <f​ooishbar> give me a wishlist and it’ll happen
18:18 fdobridge: <f​ooishbar> but it needs a @gfxstrand to review and land
18:18 fdobridge: <S​id> so far all the testing I did was while building using makepkg
18:19 fdobridge: <z​mike.> there's already tickets open on the repo for everything
18:19 fdobridge: <g​fxstrand> Do you have some magic CTS configuration flags? I still can't repro.
18:19 fdobridge: <z​mike.> no?
18:19 fdobridge: <z​mike.> just normal surfaceless config
18:19 fdobridge: <z​mike.> though I don't imagine that's related
18:19 fdobridge: <g​fxstrand> I can try to rebuild surfaceless
18:20 fdobridge: <z​mike.> I can probably test non-surfaceless faster
18:20 fdobridge: <z​mike.> after lunch
18:20 fdobridge: <g​fxstrand> Is there a flag to run surfaceless or do I have to rebuild?
18:20 fdobridge:<g​fxstrand> doesn't do GL anymore
18:20 fdobridge: <z​mike.> rebuild
18:20 fdobridge: <k​arolherbst🐧🦀> in the glcts?
18:21 fdobridge: <k​arolherbst🐧🦀> yeah
18:21 fdobridge: <z​mike.> I wonder if I could abuse 🪑 powers to have someone rewrite that so it doesn't need a rebuild...
18:22 fdobridge: <r​hed0x> theres only 2 mentions of secondary/primary in the code, looks fine to me
18:22 fdobridge: <g​fxstrand> Just file a ticket and use magic Valve powers to make it happen
18:22 fdobridge: <z​mike.> magic valve powers only apply to vkcts
18:23 fdobridge: <z​mike.> for glcts I need 🪑
18:25 fdobridge: <t​om3026> uhm anyone has an idea what package provides "dep_syn = dependency('syn'," seems i havent built nouveau in a while or im just missing deps since the water accident
18:25 fdobridge: <t​om3026> in arch.
18:26 fdobridge: <g​fxstrand> Okay, building surfaceless now
18:26 fdobridge: <!​DodoNVK (she) 🇱🇹> `--force-fallback-for=syn` should be good enough
18:27 fdobridge: <t​om3026> ah missed that bit, seems your package had it heh
18:28 fdobridge: <r​hed0x> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27856 here goes nothing
18:30 fdobridge: <g​fxstrand> Thanks!
18:30 fdobridge: <r​hed0x> this still seemed too easy, now I'm waiting for someone to dig up some edge case reason for why one of the features isnt supported or something like that🤔
18:31 fdobridge: <z​mike.> @gfxstrand I tested the egl/glx build just now and it still crashes
18:31 fdobridge: <g​fxstrand> 😭
18:31 fdobridge: <g​fxstrand> Well, I want surfaceless anyway
18:31 fdobridge: <z​mike.> tbh easiest way to find a repro case for this is probably to just run cts and look at the crashes that aren't in my baseline
18:32 fdobridge: <z​mike.> maybe it's different for everyone depending on cpu or something
18:32 fdobridge: <a​irlied> @zmike. so valgrind shows nothing?
18:33 fdobridge: <z​mike.> let me tell you in 6 years when it finishes
18:34 fdobridge: <r​hed0x> nice, GPL seems to work fine. I tried it in Crysis 2 remastered and there wasn't any stuttering to compile shaders
18:34 fdobridge: <r​hed0x> the game is incredibly slow but aside from that works fine
18:35 fdobridge: <S​id> this is weird
18:35 fdobridge: <S​id> why does zfs dkms succeed on linux-tkg 6.8-rc6 but fail on my 6.8-rc4
18:36 fdobridge: <S​id> I know the officially supported kernel is only upto 6.7, but
18:36 fdobridge: <S​id> I'm bisecting this only because it completed successfully there
18:38 fdobridge: <r​edsheep> You might want to mention issue #10688 here
18:38 fdobridge: <r​hed0x> ah right
18:39 fdobridge: <S​id> ...
18:39 fdobridge: <S​id> wtf
18:39 fdobridge: <S​id> if I point dkms to linux-tkg's headers it works???
18:39 fdobridge: <S​id> :|
18:40 fdobridge: <S​id> why did that compile zfs successfully... `sudo dkms install -k 6.8-rc4-debug zfs -v 2.2.99.r365.g8f2f6cd2ac --kernelsourcedir=/usr/lib/modules/6.8.0-rc6-273-tkg-linux-caco/build/`
18:40 fdobridge: <S​id> I'm so confused
18:41 fdobridge: <S​id> whatever
18:41 fdobridge: <z​mike.> ```
18:41 fdobridge: <z​mike.> ==141384== Jump to the invalid address stated on the next line
18:41 fdobridge: <z​mike.> ==141384== at 0x20A3D0: ???
18:41 fdobridge: <z​mike.> ==141384== by 0xEA9F76C: nouveau_ws_free_vma (nouveau_bo.c:121)
18:41 fdobridge: <z​mike.> ==141384== by 0xEA9FFB0: nouveau_ws_bo_destroy (nouveau_bo.c:352)
18:41 fdobridge: <z​mike.> ==141384== by 0xE671AF0: nvk_heap_finish (nvk_heap.c:59)
18:41 fdobridge: <z​mike.> ==141384== by 0xE66C5A6: nvk_DestroyDevice (nvk_device.c:317)
18:41 fdobridge: <z​mike.> ==141384== by 0xE2617DA: ??? (in /usr/lib64/libvulkan.so.1.3.268)
18:41 fdobridge: <z​mike.> ==141384== by 0xE2727EF: vkDestroyDevice (in /usr/lib64/libvulkan.so.1.3.268)
18:41 fdobridge: <z​mike.> ==141384== by 0x6501762: zink_destroy_screen (zink_screen.c:1608)
18:41 fdobridge: <z​mike.> ==141384== by 0x5760539: dri_release_screen (dri_screen.c:562)
18:41 fdobridge: <z​mike.> ==141384== by 0x57605A7: dri_destroy_screen (dri_screen.c:577)
18:41 fdobridge: <z​mike.> ==141384== by 0x5760D06: driDestroyScreen (dri_util.c:230)
18:41 fdobridge: <z​mike.> ==141384== by 0x5593DCF: driswDestroyScreen (drisw_glx.c:798)
18:41 fdobridge: <z​mike.> ==141384== by 0x559A15B: FreeScreenConfigs (glxext.c:235)
18:41 fdobridge: <z​mike.> ==141384== by 0x559A256: glx_display_free (glxext.c:276)
18:41 fdobridge: <z​mike.> ==141384== by 0x559A3DB: __glXCloseDisplay (glxext.c:325)
18:41 fdobridge: <z​mike.> ==141384== by 0x4952A61: XCloseDisplay (ClDisplay.c:65)
18:41 fdobridge: <z​mike.> ==141384== by 0x20BC63: ???
18:41 fdobridge: <z​mike.> ==141384== by 0x51A01EF: ???
18:41 fdobridge: <z​mike.> ==141384== by 0x20F998: ???
18:41 fdobridge: <z​mike.> ==141384== by 0x51A01EF: ???
18:41 fdobridge: <z​mike.> ==141384== by 0xF3CBD7: ??? (in /home/zmike/src/VK-GL-CTS/egl/external/openglcts/modules/glcts)
18:41 fdobridge: <z​mike.> ==141384== by 0x51A0FA7: ???
18:41 fdobridge: <z​mike.> ==141384== by 0x51A0FA7: ???
18:41 fdobridge: <z​mike.> ==141384== by 0x1490DC6F: ???
18:41 fdobridge: <z​mike.> ==141384== by 0x28D36BD: ??? (in /home/zmike/src/VK-GL-CTS/egl/external/openglcts/modules/glcts)
18:41 fdobridge: <z​mike.> ==141384== by 0x519CAFF: ???
18:42 fdobridge: <z​mike.> ==141384== by 0x51A1AFF: ???
18:42 fdobridge: <z​mike.> ==141384== by 0x51A1AFF: ???
18:42 fdobridge: <z​mike.> ==141384== by 0x22E5F0: ???
18:42 fdobridge: <z​mike.> not the most useful
18:45 fdobridge: <g​fxstrand> Wait, what? Why is `nouveau_ws_free_vma()` jumping to random addresses?!?
18:45 fdobridge: <g​fxstrand> Or is the return pointer somehow getting screwed up?
18:45 fdobridge: <g​fxstrand> Did you run with `--track-origins=yes`
18:47 fdobridge: <z​mike.> yes
18:47 fdobridge: <z​mike.> it's stack corruption
18:47 fdobridge: <z​mike.> somewhere
18:48 fdobridge: <g​fxstrand> This is why we should just rewrite everything in Rust. 😛
18:49 fdobridge: <S​id> yay `Bisecting: 183 revisions left to test after this (roughly 8 steps)`
18:49 fdobridge: <z​mike.> smh just write better code
18:49 fdobridge: <S​id> also that zfs module compiled but didn't load on boot
18:50 fdobridge: <g​fxstrand> Hey! I got a segfault!
18:51 fdobridge: <z​mike.> !
18:51 fdobridge: <g​fxstrand> Surfaceless vs. surfaced does seem to have something to do with it.
18:51 fdobridge: <g​fxstrand> That or I just needed a rebuild
18:51 fdobridge: <z​mike.> bizare
18:51 fdobridge: <z​mike.> cuz it crashes in both for me
18:51 fdobridge: <z​mike.> but happy to have you crashing with me
18:52 fdobridge: <g​fxstrand> drm... No, I just don't know how to run the CTS
18:53 fdobridge: <g​fxstrand> Okay, yeah, not crashing. 😢
18:53 fdobridge: <z​mike.> :fullheadache:
18:54 fdobridge: <z​mike.> what about this caselist
18:54 fdobridge: <z​mike.> ```
18:54 fdobridge: <z​mike.> KHR-GL46.sepshaderobjs.ProgUniformAPI
18:54 fdobridge: <z​mike.> KHR-GL46.sample_variables.mask.rgba8i.samples_1.mask_6
18:54 fdobridge: <z​mike.> KHR-GL46.shader_multisample_interpolation.render.interpolate_at_centroid.rgba8.samples_1
18:54 fdobridge: <z​mike.> KHR-GL46.tessellation_shader.vertex.vertex_ordering
18:54 fdobridge: <z​mike.> KHR-GL46.texture_border_clamp.Texture2DR32UI
18:54 fdobridge: <z​mike.> KHR-GL46.direct_state_access.textures_buffer_rgba16ui
18:54 fdobridge: <z​mike.> ```
18:54 fdobridge: <z​mike.> `GTFRunTest: FAIL`
18:54 fdobridge: <z​mike.> THANKS CTS
18:54 fdobridge: <z​mike.> SO HELPFUL
18:55 fdobridge: <r​edsheep> Is it normal to have failed attempts at loading zink loop like this? I hate to keep asking for help on this but I feel like if I reinstall without learning anything I am likely to break this again and end up right back at broken zink
18:55 fdobridge: <S​id> I'm so glad I moved to this build script
18:55 fdobridge: <S​id> `Build completed in 6 minute(s) and 53 seconds.`
18:55 fdobridge: <r​edsheep> It's possible this happened while setting things up to build mesa myself but I have no idea how. I have inspected what the install script does and best I can figure it shouldn't cause this.
18:57 fdobridge: <r​edsheep> I undid the work of meson install by giving it a destination directory, and based on what it populated I deleted stuff from /var/local, and that changed nothing.
18:58 fdobridge: <p​avlo_it_115> Judging by the news and your business here. How do I understand hardware GL will no longer evolve?
18:58 fdobridge: <p​avlo_it_115> Judging by the news and your chat here. How do I understand hardware GL will no longer evolve? (edited)
18:58 fdobridge: <p​avlo_it_115> Judging by the news and your messages here. How do I understand hardware GL will no longer evolve? (edited)
19:00 fdobridge: <t​riang3l> Vulkan is the new Gallium 🙃
19:00 fdobridge: <r​edsheep> Melts in your mouth, not in your hand
19:01 fdobridge: <t​riang3l> (I mean the backend interface… not the 🥵 usage tracking stuff, that thing itself needs Gallium over Vulkan aka Zink)
19:14 fdobridge: <p​avlo_it_115> Judging by the news and your messages here. How do I understand hardware nouveau GL will no longer evolve? (edited)
19:14 fdobridge: <p​avlo_it_115> I meant the nvc0 driver
19:19 fdobridge: <z​mike.> think I just fixed all the stencil fails...
19:19 fdobridge: <z​mike.> this is a good day.
19:24 fdobridge: <a​irlied> reminds me someone should work out s8 support
19:28 fdobridge: <g​fxstrand> Yeah...
19:42 fdobridge: <S​id> started with 481 revisions
19:42 fdobridge: <S​id> currently have 55 left
19:42 fdobridge: <S​id> this bisect is going well
19:42 Lyude: karolherbst: any chance you might know of an easy way to get bindgen or some other tool I could use in the kernel to take https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/drm/drm_fourcc.h#n114 and generate an enum from all of the DRM_FORMAT_* macros there? It seems like bindgen doesn't pick up on them by default because of the fourcc_code() macro
19:45 karolherbst: Lyude: no idea how to make bindgen generate an enum for them, but if bindgen doesn't pick up anything automatically, then you'll need to add `--allowlist-var` declerations
19:46 karolherbst: the bindgens rust API might allow to group those to an enum, but I haven't looked into that yet
19:46 karolherbst: I just now that the rust API allows for more things
19:47 Lyude: yeah - I went through it a bit although I unfortunately haven't found anything in there yet that seems like it would fit this case
19:47 karolherbst: have tu checked out the rust API?
19:47 Lyude: karolherbst: a bit - but it seemed like it mostly mirrored the cli
19:47 Lyude: I think there is one thing for generating a callback that can becalled on macro functions though
19:48 Lyude: https://docs.rs/bindgen/latest/bindgen/callbacks/trait.ParseCallbacks.html#method.func_macro but it's not super clear on how to use it
19:48 karolherbst: yeah.. there are some things not exposed to the cli interface
19:49 karolherbst: Lyude: I think you need str_macro for DRM_FORMAT_ though
19:49 karolherbst: though dunno...
19:49 karolherbst: I think it just gives you the tokens anyway
19:49 karolherbst: or huh..
19:50 karolherbst: maybe func_macro would be the right thing here...
19:52 Lyude: I guess I just need to figure out how the heck to actually use this from kbuild then
19:52 fdobridge: <z​mike.> is multisampled stencil texture read supposed to work?
19:52 fdobridge: <z​mike.> is multisampled stencil sampling supposed to work? (edited)
19:53 karolherbst: Lyude: the rust API? I think you'd write a tool you would invoke on the header instead of bindgen or something
19:53 fdobridge: <a​irlied> one for @gfxstrand I assume if vk cts tests it then it works 😛
19:53 Lyude: karolherbst: and that tool presumably uses the bindgen api right?
19:53 karolherbst: yeah
19:53 karolherbst: normally in rust you'd use that inside the build.rs file
19:54 Lyude: mhm, yeah I'm familiar with that bit
19:54 Lyude: very much wish we had an equivalent in the kernel
19:54 karolherbst: maybe others already have some code to turn definitions like that into an enum
19:55 Lyude: mhm - I'm hoping at some point someone gets back to me on zulip since I asked about this ther
19:55 karolherbst: yeah.. I'd also kinda want to know, because it could actually help with some stuff
19:58 karolherbst: Lyude: the only problem with rust enums like that is, that it's UB if that enum ever gets an invalid value from the C side
19:58 Lyude: yeah that's fine. tbh it doesn't even have to be an enum, just anything that I could import that as would be helpful
19:59 karolherbst: so e.g. if new userspace sends an modifier from a future kernel, you have to check first f that value can be represented by that enum
19:59 karolherbst: Lyude: right.. for importing you should be able to use allowlist-var DRM_FORMAT_.*
20:00 karolherbst: and then you get it as constants
20:00 Lyude: karolherbst: why would that help though? I'm fairly sure that would just disable generation for anything other than DRM_FORMAT_.*? or am I misunderstanding what it does
20:00 karolherbst: it shouldn't disable anything
20:01 karolherbst: it just pulls in more things
20:01 Lyude: huh, any reason those things wouldn't already just be pulled in? since by default I think the kernel just has bindgen pull in everything
20:01 karolherbst: mhhhh
20:01 karolherbst: no idea?
20:02 karolherbst: I never used bindgen to pull in everything
20:02 Lyude: "If we specify allowlisting rules, then bindgen will only generate bindings to types, functions, and global variables that match the allowlisting rules, or are transitively used by a definition that matches them." from https://rust-lang.github.io/rust-bindgen/allowlisting.html
20:02 Lyude: $(obj)/bindings/bindings_helpers_generated.rs: private bindgen_target_flags = \
20:02 Lyude: --blocklist-type '.*' --allowlist-var '' \
20:02 Lyude: --allowlist-function 'rust_helper_.*'
20:02 karolherbst: I'm very explicit about those things: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/gallium/frontends/rusticl/meson.build?ref_type=heads#L322
20:04 karolherbst: Lyude: mhh yeah dunno... maybe the header isn't reachable from the bindgen input header?
20:04 Lyude: it definitely should be, I made sure it's included explicitly
20:04 Sid127: dirty builds are so much nicer than using makepkg/pkgbuild
20:04 Sid127: `Build completed in 3 minute(s) and 17 seconds.`
20:05 fdobridge: <z​mike.> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27859 fixes all the stencil fails except `GTF-GL46.gtf44.GL31Tests.texture_stencil8.texture_stencil8_gl44` which seems like an nvk bug
20:05 karolherbst: Lyude: maybe invoke bindgen on that header yourself and play around with the args and see what happens
20:06 fdobridge: <a​irlied> I thinbk the stencil 8 bug would be fixed by us exposing stencil 8, but maybe is possible to fix with the fallback
20:07 fdobridge: <z​mike.> what stencil 8 bug?
20:07 fdobridge: <a​irlied> the one you linked about two sentences ago
20:08 fdobridge: <z​mike.> oh ok
20:08 fdobridge: <z​mike.> idk, stencil fallback seems to be working fine for all other cases
20:08 fdobridge: <a​irlied> I expect zink is used to impl that expose S8_UINT
20:08 fdobridge: <a​irlied> and we don't but we should
20:08 fdobridge: <z​mike.> 🤔
20:08 fdobridge: <z​mike.> don't think that's the issue
20:08 fdobridge: <z​mike.> or at least I don't see any S8_UINT here
20:08 fdobridge: <z​mike.> I don't think...
20:09 fdobridge: <a​irlied> other than the one you linked above 🙂
20:09 fdobridge: <z​mike.> oh
20:09 fdobridge: <z​mike.> yeah ok maybe
20:12 fdobridge: <z​mike.> it's only the multisampled stencil case that's failing here
20:12 fdobridge: <a​irlied> yeah so that could have some wierd interaction when you use d24s8 for s8
20:13 fdobridge: <z​mike.> I'm gonna leave that to an S8 expert 😛
20:14 fdobridge: <a​irlied> I made an attempt at s8 previously but ran into the fact I've no idea why nvidia treat it differently 😛
20:14 fdobridge: <z​mike.> or at least I can't see anything that zink might be doing wrong
20:14 fdobridge: <z​mike.> in the not-actually-s8 case
20:16 fdobridge: <g​fxstrand> It's supposed to, yes.
20:16 fdobridge: <z​mike.> hmm
20:16 fdobridge: <g​fxstrand> That doesn't mean we aren't flubbing it, though.
20:16 fdobridge: <z​mike.> looks like there's ~5 big test groups still failing on glcts, then another couple bespoke issues and then all versions are passing
20:16 fdobridge: <g​fxstrand> I find that a bit unlikely given that stencil MSAA resolves work, though.
20:17 fdobridge: <z​mike.> I just spent a while inspecting this, and it's just doing some stencil fallback awfulness -> stencil sample
20:17 fdobridge: <z​mike.> which is the same thing the rest of the tests in this case do except this time it's multisampled
20:18 fdobridge: <z​mike.> anyway probably not the most urgent bug out of the remaining ones
20:19 fdobridge: <a​irlied> could disable s8_uint on radv/lvp and see if it reproduces I suppose
20:23 fdobridge: <z​mike.> ughhhh I hate you for being right 🤕
20:23 fdobridge: <z​mike.> it's stencil fallback
20:23 fdobridge: <g​fxstrand> 😭
20:24 fdobridge: <z​mike.> stencil fallback + no s8, more specifically
20:28 fdobridge: <g​fxstrand> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27860
20:28 fdobridge: <g​fxstrand> That'll fix pipeline library
20:28 fdobridge: <S​id> getting closer `Bisecting: 7 revisions left to test after this (roughly 3 steps)`
20:29 fdobridge: <z​mike.> nice!
20:30 fdobridge: <m​ohamexiety> @airlied heyy. how expensive are vm_bind ops? in my sparse residency impl, I split the subresource into rows and bind each row separately, pushing out a different op for each row even if they're contiguous. is it worth coalescing them if I can detect that they're contiguous?
20:32 fdobridge: <a​irlied> it's probably fine until we see it show up on in a profiler
20:32 fdobridge: <m​ohamexiety> yeah. I did cook up a quick something that should do this but I didn't notice a difference in CTS runs, but those are also fairly small sized and simple
20:32 fdobridge: <a​irlied> as long as they are all in a single submit
20:33 fdobridge: <a​irlied> get FH5 running then worry about it 😛
20:33 fdobridge: <m​ohamexiety> haha fair
20:35 fdobridge: <g​fxstrand> Woo! NVK is now a real Vulkan driver. Officially.
20:35 fdobridge: <g​fxstrand> Woo! NVK is now a real Vulkan driver. Officially. 🥳 (edited)
20:37 fdobridge: <m​ohamexiety> let's goooo
20:39 fdobridge: <g​fxstrand> https://www.collabora.com/news-and-blog/news-and-events/nvk-is-now-ready-for-prime-time.html
20:41 fdobridge: <r​hed0x> quick question: how do I run the CTS?
20:41 fdobridge: <r​hed0x> I've built it now
20:41 fdobridge: <!​DodoNVK (she) 🇱🇹> Or FH4
20:42 fdobridge: <p​ixelcluster> `cd build/external/vulkancts/modules/vulkan; ./deqp-vk -n "<your test name here>"`
20:42 fdobridge: <a​irlied> Does fh4 use sparse?
20:42 fdobridge: <m​ohamexiety> `./deqp-vk -n $TESTNAME` inside `$CTSDIR/build/external/vulkancts/modules/vulkan`
20:42 fdobridge: <a​irlied> Thought it was fh5
20:43 fdobridge: <m​ohamexiety> wait fh5 needs sparse?
20:43 fdobridge: <m​ohamexiety> if so, the branch is basically done. if someone has it they can try it now
20:43 fdobridge: <a​irlied> Pretty sure fh5 was the big baddie on radv for sparse
20:43 fdobridge: <m​ohamexiety> I only know of Devour from @huntercz122
20:44 fdobridge: <!​DodoNVK (she) 🇱🇹> I know both are D3D12 games
20:44 fdobridge: <S​id> even quake champions seems to need sparse
20:44 fdobridge: <S​id> ^
20:44 fdobridge: <S​id> I can try that in a bit
20:44 fdobridge: <a​irlied> We weren't talking about d3d12 though so wondering why you brought up the out of context
20:45 fdobridge: <a​irlied> I think fh5 does nearly everything with sparse bindings, I know valve had to fix amdgpu kernel module to deal with it
20:46 fdobridge: <r​hed0x> is there also some clever way to run a bunch of tests at once or do i have to painstakingly call it one by one with the test names
20:46 fdobridge: <m​ohamexiety> it supports wildcards
20:46 fdobridge: <m​ohamexiety> e.g.:
20:46 fdobridge: <m​ohamexiety> `./deqp-vk -n dEQP-VK.sparse_resources.image_sparse_memory_aliasing.* --deqp-vk-device-id=1`
20:46 fdobridge: <a​irlied> https://lore.kernel.org/lkml/12f8f138-302d-83d8-3d10-4036400d5482@amd.com/
20:47 fdobridge: <m​ohamexiety> for more sophisticated runs you can use deqp-runner too. you can pass to that one a case list with a bunch of different tests and it runs them. also multithreaded support and a few other goodies
20:50 fdobridge: <g​fxstrand> Oh, the other thing we need to do for sparse is that we really need to make it so that the bind_ops array can grow. Right now we have a max of 4096 ops or something. Apps are going to blow past that.
20:51 fdobridge: <m​ohamexiety> that thread is interesting 😮
20:51 fdobridge: <m​ohamexiety> thanks!
20:52 fdobridge: <!​DodoNVK (she) 🇱🇹> Literally kernel lore
20:52 fdobridge: <m​ohamexiety> damn
20:52 fdobridge: <m​ohamexiety> > On of the most demanding ones is Forza Horizon 5. The general approach
20:52 fdobridge: <m​ohamexiety> > of that game seems to be to allocate 64GiB of address space (equals 16
20:52 fdobridge: <m​ohamexiety> > million 4kiB pages) and then mmap() whatever data it needs into that
20:52 fdobridge: <m​ohamexiety> > self managed space, assuming that every 4KiB page is individually
20:52 fdobridge: <m​ohamexiety> > mapable to a different location.
20:53 fdobridge: <z​mike.> practically instant https://www.phoronix.com/news/Mesa-NVK-Vulkan-Conformant
20:54 fdobridge: <S​id> wtf
20:54 fdobridge: <p​ixelcluster> he probably had everything prepared because he saw the mr being opened?
20:54 fdobridge: <p​ixelcluster> just waited for it to get merged to actually post
20:54 fdobridge: <m​ohamexiety> yeah I'd guess so too given how fast this popped lol
20:54 fdobridge: <r​edsheep> Might have seen the conformance too
20:55 fdobridge: <m​arysaka> I need a bottle to open /s
20:55 fdobridge: <S​id> same
21:02 fdobridge: <r​hed0x> even had that photo prepared :o
21:04 Sid127: so
21:04 Sid127: either dirty building for a bisect is not a good approach
21:04 Sid127: or I went wrong somewhere while bisecting
21:04 Sid127: or the runpm bug ACTUALLY arises from a random non-nouveau commit...
21:05 Sid127: hmmmmmmmm
21:07 fdobridge: <r​edsheep> I think he's used that before
21:07 fdobridge: <r​hed0x> yeah probably
21:09 Lyude: karolherbst: so it seems like bindgen just completely entirely ignores any kind of macro definition that isn't a constant
21:09 fdobridge: <S​id> git bisect says this is the commit causing runpm bug: https://github.com/torvalds/linux/commit/bc4cbc9d260ba8358ca63662919f4bb223cb603b
21:09 fdobridge: <S​id> which
21:09 fdobridge: <S​id> I call bullshit
21:10 karolherbst: Lyude: mhhhh
21:12 karolherbst: Lyude: I have an idea.. and you won't like it :D
21:12 karolherbst: gimme a sec
21:13 Lyude: if it's a shell script i've been thinking of that
21:13 Lyude: because this is very obnoxious and silly
21:13 karolherbst: worse
21:13 Lyude: not processing basic macros like this which should be entirely evaluatable compile-time is a pretty enormous oversight
21:16 Lyude: https://github.com/rust-lang/rust-bindgen/issues/753 :(
21:16 Lyude: opened in 2017
21:16 karolherbst: I think the problem is, that it's not that simple
21:16 karolherbst: like...
21:16 Lyude: yeah I guess I should have assumed as much...
21:16 karolherbst: clang can't figure that out in itself
21:16 karolherbst: soooo
21:16 karolherbst: here is my idea:
21:17 karolherbst: like..
21:17 karolherbst: you just need C variables to get thoes values assigned
21:17 fdobridge: <S​id> time to rebisect I guess
21:18 karolherbst: but apparently parsing that file is also pain
21:18 fdobridge: <S​id> just gotta confirm the one commit I marked good was actually good or not...
21:18 karolherbst: ohh actually...
21:19 Lyude: if bindgen could just hand me some magic thing with bindgen-cli to let me write code to do a search/replace on the contents of macros that would certainly fix this, and i'd be fine with that
21:19 Lyude: trying to do that myself with bindgen's rust api would require getting kbuild to actually call whatever tool that is which, is a lot of work :(
21:20 karolherbst: almost done 🙃
21:22 fdobridge: <S​id> ok, internet says dirty builds are fine while bisecting, meaning, I made a dumb
21:22 fdobridge: <S​id> which is extremely believable
21:24 karolherbst: Lyude: for format in $(grep 'fourcc_code' include/uapi/drm/drm_fourcc.h | grep -v '#define fourcc_code' | tr '\t' ' ' | cut -d' ' -f2); do echo "u64 RUST_$format = $format;"; done
21:24 karolherbst: and then build a header with that
21:24 karolherbst: and bindgen should parse that if you include the drm_fourcc.h file
21:26 Lyude: gotcha haha, shell script it is (you'd need to change the '#define fourcc_code' bit though)
21:27 karolherbst: I was wondering if pushing it through `cpp` would do anything
21:27 karolherbst: but it just uhh.. doesn't help
21:27 Lyude: yeah I think it's just going to be easier to skip bindgen alltogether here until it's fixed/forever because i get the feeling that bug might not be fixed
21:28 karolherbst: I mean..
21:28 karolherbst: you still need to parse the value then
21:30 Lyude: not if I just define a const fn called fourcc_code() :)
21:30 karolherbst: :D
21:30 karolherbst: fair enough
21:39 karolherbst: Lyude: https://gist.github.com/karolherbst/b3ea5df263fee735b4129c68db58233f
21:39 karolherbst: pub const RUST_DRM_FORMAT_YVU444: __u64 = 875714137;
21:40 karolherbst: probably won't need the cpp call there...
21:40 fdobridge: <S​id> ok, re-checked the bisect
21:40 fdobridge: <S​id> I didn't mark any commit wrong
21:41 Lyude: i think we'd still need to figure out how to pipe the kernel's arguments for bindgen and possibly cpp though?
21:41 karolherbst: Lyude: https://gist.github.com/karolherbst/b3ea5df263fee735b4129c68db58233f
21:42 karolherbst: but yeah.. no idea how to integrate that into the kernel build system :D
21:42 Lyude: honestly that's why I'm thinking I might just do search replace :P
21:43 karolherbst: btw.. there are rust crates to parse C code 🙃
21:43 karolherbst: like.. as in using them through macros
21:43 Lyude: tbh i'm surprised libclang isn't able to handle this in the first place
21:45 karolherbst: mhhh
21:45 karolherbst: I think the problem is, it just doesn't do it at all
21:45 karolherbst: because that's up to cpp
21:45 Lyude: C...
21:45 Lyude: what am i gonna do with you c
21:46 karolherbst: with cpp the output of my script looks like this:
21:46 karolherbst: __u64 RUST_DRM_FORMAT_YVU444 = ((__u32)('Y') | ((__u32)('V') << 8) | ((__u32)('2') << 16) | ((__u32)('4') << 24));
21:46 karolherbst: so.. yeah...
21:52 Sid127: well, I feel like git bisect wasted my time
21:52 Sid127: so I'm gonna go become a hermit in the nearest mountains
21:53 karolherbst: Sid127: don't worry, the worst kernel bisect I did took 3 days and the last iteration had 100 skips
21:53 Lyude: yeah i've had many failed git bisects
21:54 Lyude: the worst ones are when you think you have reproducing behavior but realize it's not actually consistent once you keep getting different bisect results for the same range of commits :(
21:54 Sid127: I know for a fact rc4's tag does not have the issue
21:54 Sid127: and rc5 does
21:56 Sid127: maybe it's the fact I tried between rc4 and rc6 instead
21:57 Sid127: idk, I'll try it again tomorrow
21:57 Sid127: maybe
21:57 Sid127: though
21:57 Sid127: applying just three commits together on top of rc4 reintroduces the bug
21:58 fdobridge: <S​id> https://cdn.discordapp.com/attachments/1034184951790305330/1212519096642703421/image.png?ex=65f22168&is=65dfac68&hm=6d0017336b88fcf1ce9e3ce4adc7be84e9b7fad505572ca7f7d32f7f8986672f&
21:58 Sid127: those three ^
21:58 Sid127: but reverting all three on rc6 does not fix it
21:59 Sid127: maybe I'll try reverting them three on rc5
21:59 Sid127: idk
22:02 Lyude: i think i'll try to figure this out later and do work chores, somehow that's more motivationally appealing atm then trying to figure out how on earth to get kbuild to call this lmao
22:28 fdobridge: <r​hed0x> 2/3 beginner issues done :)
22:42 fdobridge: <m​ohamexiety> nice!
22:43 fdobridge: <r​edsheep> I'll try to do the timestamp one to get one on the board, bad timing on my install or mesa being messed up
22:43 fdobridge: <r​edsheep> At this rate you'll beat me to it though
22:45 fdobridge: <r​hed0x> i can leave that to you if you wanna do it
23:19 fdobridge: <r​edsheep> Uuuggggggghhhhh I found what was blowing up my zink really bad, guess I didn't pay close enough attention to https://www.supergoodcode.com/preemptive/
23:20 fdobridge: <r​edsheep> I did a bios update, which reset everything in my bios, and I forgot to turn my iGPU back off, so xf86-video-amdgpu started destroying everything. Either removing that package, or disabling my iGPU gets my zink working again.
23:22 fdobridge: <r​edsheep> I fell prey to one of the classic blunders, I went in against xf86-video-amdgpu when death was on the line. At least it wasn't a land war in Asia.
23:25 fdobridge: <r​edsheep> No idea if the princess bride is well known outside the US so I might sound like a crazy person. Anyway now I can finally get to all the testing I wanted to do.