00:01 Sid127: HdkR: from a "proton guy": We pretend to be Pascal for anything that doesn't use NV prop driver
00:02 HdkR: Interesting
00:03 Sid127: that is if nvapi is enabled for that game across all vendors
00:03 fdobridge: <g​fxstrand> Sid127: No, I'm still trying to figure out why it breaks subgroups
00:03 fdobridge: <g​fxstrand> This is proving to be a nasty debug
00:03 Sid127: logic being: Hopefully this should be enough to stop games from trying anything like DLSS.
00:03 Sid127: oh, it breaks something else?
00:03 Sid127: hm
00:04 Sid127: should I continue to include the mr in my build ^^'
00:04 fdobridge: <g​fxstrand> 🤷🏻‍♀️
00:04 fdobridge: <g​fxstrand> 🤷
00:05 fdobridge: <g​fxstrand> IDK
00:05 fdobridge: <g​fxstrand> (Sorry, the bridge doesn't like emoji)
00:05 Sid127: the bridge handles most emoji fine tbh
00:05 fdobridge: <g​fxstrand> Not shrugs, aparently
00:06 Sid127: yeah, that one got posted twice
00:06 fdobridge: <k​arolherbst🐧🦀> it's just those emoji composition things
00:06 Sid127: yup
00:06 fdobridge: <k​arolherbst🐧🦀> 🦀
00:06 Sid127: once as 🤷🏻‍ and once as 🤷
00:06 fdobridge: <g​fxstrand> I'm seeing ??? in IRSSI any time someone posts an emoji from DIscord
00:06 Sid127: but the penguin and crab in karol's nick come across fine every time
00:07 fdobridge: <k​arolherbst🐧🦀> sounds like a client problem on your side
00:07 Sid127: gfxstrand: that just sounds like a client problem, yeah
00:07 fdobridge: <g​fxstrand> IRSSI is fine if they're just unicode characters
00:07 Sid127: I've got emoji working in weechat
00:07 HdkR: karolherbst: Is the NVIF ioctl architecture non-specific?
00:07 fdobridge: <g​fxstrand> Maybe it's using some emoji IRC extension? IDK
00:07 fdobridge: <k​arolherbst🐧🦀> well.. all those emojis are unicode characters
00:07 fdobridge: <g​fxstrand> Yeah, I know
00:07 Sid127: ^
00:07 fdobridge: <k​arolherbst🐧🦀> but maybe it doesn't support unicode properly
00:07 fdobridge: <k​arolherbst🐧🦀> well.. apparently
00:07 fdobridge: <k​arolherbst🐧🦀> or maybe you have to install some fonts?
00:08 Sid127: I do have noto color emoji installed
00:08 fdobridge: <k​arolherbst🐧🦀> anyway..it works in my client, which is konversation
00:08 Sid127: works on weechat in kitty
00:08 fdobridge: <g​fxstrand> In any case, IDK if you'll notice any actual breakage from the OOR addr thing except it apparently torches the CTS for me.
00:09 fdobridge: <g​fxstrand> But I think I'm pretty much done for today
00:11 Sid127: well, elite dangerous still gets stuck on that shader on current head +
00:11 Sid127: uh
00:11 Sid127: 27927 yes
00:12 Sid127: time to try current head without any mrs
00:20 fdobridge: <g​fxstrand> Well, I learned at least one thing today: OOR address doesn't seem to affect subgroups on Maxwell
00:20 fdobridge: <g​fxstrand> I need to do a bit more back-end fixing to be 100% sure but the test I was looking at seem fine
00:28 fdobridge: <S​id> 27927 does not make a difference to elite dangerous getting stuck on a shader
00:29 fdobridge: <S​id> @gfxstrand based on debug log and offsets, the issue there arises here: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/nouveau/compiler/nak/repair_ssa.rs#L33
00:30 fdobridge: <S​id> which, I believe, should also be the same for all the regressions we're seeing after GPL got merged, though I haven't confirmed
00:36 fdobridge: <S​id> why is gitlab ui so difficult to nagivate...
00:37 fdobridge: <S​id> does NVK_USE_NAK=0 still exists
00:37 fdobridge: <S​id> or did that get ripped out
00:38 fdobridge: <S​id> oh well
00:38 fdobridge: <k​arolherbst🐧🦀> it still exists
00:38 fdobridge: <S​id> it just causes dxvk to fail to create a device now
00:38 fdobridge: <S​id> unless I also need to disable shader cache with it
00:39 fdobridge: <m​henning> It disables some extensions which might be required for dxvk
00:39 fdobridge: <k​arolherbst🐧🦀> probably?
00:39 fdobridge: <S​id> oh
00:39 fdobridge: <S​id> well, let me test elite with damavand then
00:39 fdobridge: <S​id> to confirm if this is an nvk thing or an nvk/dxvk interation thing
00:40 fdobridge: <m​henning> Want to try elite with https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27995 ?
00:40 fdobridge: <S​id> I can type I promise
00:40 fdobridge: <S​id> sure, gimme 10 mins
00:41 fdobridge: <m​henning> And if that doesn't work, it would be helpful if you could post `.foz` files somewhere
00:41 fdobridge: <S​id> I hope you also want me to test games that actually work :3
00:42 fdobridge: <S​id> I still dunno how to create .foz files tbf
00:42 fdobridge: <S​id> I could do gfxrecon though
00:43 fdobridge: <S​id> ..or just learn how to capture .foz
00:46 fdobridge: <m​henning> If it's a steam game, it already creates .foz files for you as part of shader pre-caching
00:46 fdobridge: <S​id> I have that disabled
00:47 fdobridge: <S​id> since it doesn't work correctly on multi-gpu systems like mine
00:47 fdobridge: <m​henning> if it's not, you just need to install fossilize and set an env var
00:47 fdobridge: <S​id> always compiles for the iGPU...
00:48 fdobridge: <S​id> I mean
00:48 fdobridge: <S​id> I know how to work around that, but
00:48 fdobridge: <S​id> since I still hope between nvidia and nvk, it deletes the cache every time the driver changes
00:48 fdobridge: <S​id> s\/hope/hop
00:50 fdobridge: <S​id> generating foz
00:54 fdobridge: <S​id> where
00:54 fdobridge: <S​id> where's the generated file, hm
00:55 fdobridge: <S​id> found it
00:56 fdobridge: <S​id> for reference, this is with commit `d1cf01dc5275bf058ae6d59a27ba1967e7edc3bc` with !27995 applied on top
00:56 fdobridge: <S​id> https://cdn.discordapp.com/attachments/1034184951790305330/1214738249780826172/fossilize.08567ef583281dd7.1.foz?ex=65fa3427&is=65e7bf27&hm=8d1eb37933fb9497a9c820b46b1200a4282f97e3c3c39021a68befeb6dd01c39&
00:58 fdobridge: <S​id> if ya need anything else, let me know :>
01:32 fdobridge: <m​henning> @tiredchiku Okay, I can;t reproduce the problem with that .foz file. Maybe with the standalone (non-steam) layer and either FOSSILIZE_DUMP_SIGSEGV=1 or FOSSILIZE_DUMP_SYNC=1 the dump would capture it?
01:33 fdobridge: <S​id> I'm using the non-steam layer, yes
01:33 fdobridge: <S​id> fossilize-git off the aur
01:33 fdobridge: <S​id> I'll try those in a bit thougj
01:34 fdobridge: <S​id> having brekkie rn
02:43 fdobridge: <a​irlied> @karolherbst there are some docs on the kernel side https://www.kernel.org/doc/html/latest/gpu/driver-uapi.html#vm-bind-exec-uapi
02:43 fdobridge: <a​irlied> you probably don't have to care about async vm binds for GL
02:54 fdobridge: <g​fxstrand> That's believable. Do we have a trace or something I can repro with?
03:22 fdobridge: <g​fxstrand> Oh, I see the .foz
03:23 fdobridge: <g​fxstrand> I should review and merge some of @mhenning's MRs
03:25 fdobridge: <g​fxstrand> Also, SM50 NAK is hitting the point where it needs some real compiler engineering.
03:25 fdobridge: <S​id> I can provide any kind of trace
03:25 fdobridge: <S​id> .foz, .gfxr, apitrace...
03:26 fdobridge: <S​id> what do you prefer :D
03:26 fdobridge: <g​fxstrand> (Not that the previous work wasn't real. It's just that the problems I'm most commonly hitting now aren't just a missing instruction. They need more heavy duty work.)
03:26 fdobridge: <g​fxstrand> Let me try the above .foz
03:27 fdobridge: <S​id> fwiw it may not have captured the thingy like mhenning said
03:27 fdobridge: <g​fxstrand> Yeah, I can replay that one just fine on nvk main
03:27 fdobridge: <S​id> and am afk for about 20 mins more but can recapture after
03:27 fdobridge: <g​fxstrand> Okay
03:27 fdobridge: <g​fxstrand> It's getting late here so I probably won't be able to look until tomorrow.
03:27 fdobridge: <S​id> might go for gfxreconstruct instead tbh
03:28 fdobridge: <g​fxstrand> Once you capture, could you verify with fossilize-replay that it crashes the same way as the game?
03:28 fdobridge: <S​id> will do
03:28 fdobridge: <g​fxstrand> That works, too. .foz is a lot smaller and easier to throw around, though.
03:28 fdobridge: <S​id> yeah
03:28 fdobridge: <g​fxstrand> And easier to debug
03:28 fdobridge: <S​id> but I feel like gfxr is more comprehensive with what it captures
03:30 fdobridge: <S​id> because as it stands, this game gets stuck, rendering freezes, wine spams illegal access exception about 8 times, and the game just exits to desktop after that
03:33 fdobridge: <S​id> dodo helped me use the debug symbols to identify the source of the stickyness
03:36 fdobridge: <S​id> i.e. where it's getting stuck
03:50 fdobridge: <S​id> yeah, can't get it to crash even with the env vars set
03:50 fdobridge: <S​id> time for gfxr
03:57 fdobridge: <S​id> wat
03:57 fdobridge: <S​id> gfxr is unable to replay
03:57 fdobridge: <S​id> a capture I made 5 minutes ago
03:57 fdobridge: <S​id> because of
03:57 fdobridge: <S​id> ```
03:57 fdobridge: <S​id> [gfxrecon] WARNING - Extension VK_KHR_get_physical_device_properties2 is not supported by the replay device and may cause issues during attempted replay
03:57 fdobridge: <S​id> [gfxrecon] WARNING - Extension VK_EXT_image_drm_format_modifier is not supported by the replay device and may cause issues during attempted replay
03:57 fdobridge: <S​id> [gfxrecon] FATAL - API call at index: 115 thread: 3 vkCreateDevice returned error value VK_ERROR_EXTENSION_NOT_PRESENT that does not match the result from the capture file: VK_SUCCESS. Replay cannot continue.
03:57 fdobridge: <S​id> [gfxrecon] WARNING - Rendering was restricted to surface index 0, but a surface was never created for that index; replay created 0 surface(s)
03:57 fdobridge: <S​id> Replay has encountered a fatal error and cannot continue: the specified extension does not exist```
03:57 fdobridge: <S​id> amazing
03:59 fdobridge: <S​id> ok, --remove-unsupported did it
04:02 fdobridge: <S​id> what's a .csa file
04:02 fdobridge: <S​id> I can pull the shaders from the game's install dir
04:02 fdobridge: <S​id> but they're in .csa files
04:05 fdobridge: <S​id> I'm dumb
04:05 fdobridge: <S​id> I'm so dumb
04:05 fdobridge: <S​id> I should've made the .foz in an env where the game is able to load to mm
04:26 fdobridge: <a​irlied> @zmike. @gfxstrand looks like the nvk heap code is what is killing the stack
04:27 fdobridge: <g​fxstrand> That's possible
04:27 fdobridge: <S​id> ok no matter what I do I am unable to get this shader to go stuck in a replay
04:30 fdobridge: <g​fxstrand> 😭
04:31 fdobridge: <S​id> well
04:31 fdobridge: <S​id> I could do d3dretrace in wine as a last ditch effort
04:31 fdobridge: <S​id> capture on nv proprietary
04:31 fdobridge: <S​id> and replay on nvk
04:31 fdobridge: <S​id> but that's about the same as just... running the game :D
04:32 fdobridge: <S​id> I'll try d3dretrace in the evening
04:37 fdobridge: <a​irlied> it helps if you only unmap bos you've mapped I think
04:39 fdobridge: <S​id> hmmmmm
04:40 fdobridge: <S​id> ```
04:40 fdobridge: <S​id> 1256.798:0108:011c:fixme:uiautomation:msaa_provider_GetPatternProvider Unimplemented patternId 10002
04:40 fdobridge: <S​id> 1256.798:0108:011c:fixme:uiautomation:base_hwnd_provider_GetPatternProvider 000000000135C290, 10002, 0000000001A2F8A0: stub
04:40 fdobridge: <S​id> 1256.799:0108:011c:fixme:oleacc:find_class_data unhandled window class: L"#32769"
04:40 fdobridge: <S​id> ```
04:40 fdobridge: <S​id> msaa provider?
04:43 fdobridge: <a​irlied> @gfxstrand @zmike. https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28006
04:44 fdobridge: <a​irlied> so today was the day, I was too tired to be smart, so just broke gdb on every munmap and checked what it was unmapping
05:07 fdobridge: <S​id> in some positive news
05:07 fdobridge: <S​id> dirt rally 1 stutters are almost gone now that GPL's been merged
05:09 fdobridge: <g​fxstrand> Spicy! 🌶️
05:10 fdobridge: <S​id> https://cdn.discordapp.com/attachments/1034184951790305330/1214802322794745867/image.png?ex=65fa6fd3&is=65e7fad3&hm=c21b24da496bbe29dbb27faefcdb60e7d77918d54ba884428b656191a46ae1b5&
05:10 fdobridge: <g​fxstrand> I'm a little surprised glibc lets you unmap the null page.
05:12 fdobridge: <a​irlied> munmap has no errors on unmapped pages
05:12 fdobridge: <a​irlied> it's actually a page up around 0x400000 we hit
05:13 fdobridge: <a​irlied> " It is not an error if the indicated range does not contain any mapped pages."
05:13 fdobridge: <g​fxstrand> Right
05:13 fdobridge: <g​fxstrand> Good catch
05:14 fdobridge: <g​fxstrand> Yet more reasons I don't like writing drivers in C...
08:15 fdobridge: <t​om3026> seems to have crashed, your car is upside down.
09:04 fdobridge: <r​hed0x> bad driver 🥁
09:09 fdobridge: <r​edsheep> Has anybody else tested the new tf2 x64 beta? It seems to really blow things up, like forces me to reboot kind of bad
09:10 fdobridge: <r​edsheep> Systemd soft reboot is enough, so it doesn't lock the kernel, but the way it scrambles my display is really interesting
09:13 fdobridge: <r​edsheep> Nothing at all in dmesg so seems like it's probably an nvk issue
09:13 fdobridge: <r​hed0x> that uses DXVK internally
09:13 fdobridge: <r​edsheep> Right
09:14 fdobridge: <r​edsheep> I haven't found anything interesting as output from steam or the game when I run from terminal. It all seems to think things are fine, but the display the game goes to scrambles and eventually disconnects
09:16 fdobridge: <r​edsheep> Come to think of it, if the display ends up disconnecting that sounds more like a kernel issue or even firmware issue. Whatever it is isn't something getting logged to dmesg by default though.
09:20 fdobridge: <r​edsheep> Hmm yep I was on the right track, it seems to be something with modesetting. If I run the game with -windowed it works fine. I suppose it's possible I am seeing an issue that has nothing to do with nouveau at all.
09:23 fdobridge: <S​id> the benchmark mode loves going off track after it finishes 😅
09:28 fdobridge: <!​DodoNVK (she) 🇱🇹> Here's what Vita3K tries to access on NVK:
09:28 fdobridge: <!​DodoNVK (she) 🇱🇹> `7ffe43415000-7ffe93996000 rw-s 113400000 00:05 889 /dev/dri/renderD129`
09:28 fdobridge: <!​DodoNVK (she) 🇱🇹>
09:28 fdobridge: <!​DodoNVK (she) 🇱🇹> Here's RADV for comparison:
09:28 fdobridge: <!​DodoNVK (she) 🇱🇹> `7fff43000000-7fffa1b2b000 rw-p 00000000 00:00 0`
09:50 fdobridge: <!​DodoNVK (she) 🇱🇹> I had to disable the memory mapping to make Vita3K work (the page table is problematic for some reason)
09:50 fdobridge: <!​DodoNVK (she) 🇱🇹> https://cdn.discordapp.com/attachments/1034184951790305330/1214872819922640907/Screenshot_20240306_114242.png?ex=65fab17b&is=65e83c7b&hm=dfec57d973bf850b8dee1b138ca95745d9c44896ea1ce1c3dfa370b1870c899d&
09:59 fdobridge: <!​DodoNVK (she) 🇱🇹> So I guess EXT_external_memory_host should be implemented to fix this properly 🐸
10:42 fdobridge: <a​irlied> Does the app use host ptrs?
10:43 fdobridge: <!​DodoNVK (she) 🇱🇹> I guess it uses them when EXT_external_memory_host is available
10:57 fdobridge: <k​arolherbst🐧🦀> @airlied @gfxstrand pulled in updated uapi headers here (there are also changes to NVK), so please review as I'm done with testing :D: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27853
10:59 fdobridge: <k​arolherbst🐧🦀> and I think we should land it independent from moving to `VM_BIND` anyway
11:00 fdobridge: <k​arolherbst🐧🦀> not necessarily needing a review for the gallium side of things, though checking if I messed up would be good, though at this point I highly doubt it
11:01 fdobridge: <S​id> does it need testing on tu116
11:01 fdobridge: <S​id> and prime render setup
11:01 fdobridge: <k​arolherbst🐧🦀> tu116 is fine
11:01 fdobridge: <k​arolherbst🐧🦀> I'm more concerned about breaking something in the vdpau/vaapi area, but even that should be good
11:02 fdobridge: <!​DodoNVK (she) 🇱🇹> Does it even work?
11:02 fdobridge: <k​arolherbst🐧🦀> users claim it does
11:02 fdobridge: <k​arolherbst🐧🦀> or rather, they file bugs if it regresses or so
11:04 fdobridge: <S​id> well, I just wanna make myself helpful
11:10 fdobridge: <!​DodoNVK (she) 🇱🇹> This doesn't have hostptr stuff, right?
11:54 fdobridge: <S​id> ```
11:54 fdobridge: <S​id> memoryPriority
11:54 fdobridge: <S​id> fragmentShaderSampleInterlock
11:54 fdobridge: <S​id> fragmentShaderPixelInterlock
11:54 fdobridge: <S​id> ```
11:55 fdobridge: <S​id> what are we missing for these features?
11:55 fdobridge: <r​hed0x> interlock is probably a lot of painful nak work
11:56 fdobridge: <S​id> what about memPrio
11:56 fdobridge: <r​hed0x> isnt there an MR for that?
11:56 fdobridge: <S​id> :o
12:01 fdobridge: <S​id> there is not
12:01 fdobridge: <S​id> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests?scope=all&state=opened&label_name[]=NVK
12:11 fdobridge: <d​adschoorse> I mean, I doubt their hardware is as insane as vega 🐸
12:12 fdobridge: <m​arysaka> I found the interlock bit in the SPH but didn't really dig much how it works
12:13 fdobridge: <m​arysaka> Maybe it's similar to Maxwell, I think I have some notes somewhere about that from some years ago
12:18 fdobridge: <S​id> @rhed0x is there a way to disable interlock in dxvk, for testing purposes
12:20 fdobridge: <r​hed0x> step 1: do nothing because there isnt a single d3d11 game that uses the feature
12:20 fdobridge: <r​hed0x> 🐸
12:21 fdobridge: <S​id> well
12:22 fdobridge: <S​id> why does this quake champions gfxr complain about it missing then 🤔
12:22 fdobridge: <S​id> when on dxvk
12:22 fdobridge: <r​hed0x> huh
12:22 fdobridge: <r​hed0x> logs?
12:22 fdobridge: <S​id> game launches fine on damavand
12:22 fdobridge: <r​hed0x> ah wait, gfxr
12:22 fdobridge: <S​id> https://discord.com/channels/1033216351990456371/1171505720349446276/1212888278978797578
12:23 fdobridge: <r​hed0x> dxvk might still enable the extension
12:23 fdobridge: <!​DodoNVK (she) 🇱🇹> You have to modify the DXVK code or use a Vulkan layer
12:23 fdobridge: <S​id> remove-unsupported still doesn't make it play
12:23 fdobridge: <r​hed0x> ` enabled.extFragmentShaderInterlock.fragmentShaderSampleInterlock = supported.extFragmentShaderInterlock.fragmentShaderSampleInterlock;`
12:23 fdobridge: <r​hed0x> yeah, gfxr probably doesnt like that
12:23 fdobridge: <r​hed0x> you'd have to modify the dxvk source code though
12:23 fdobridge: <S​id> ..hm
12:23 fdobridge: <S​id> tbh
12:24 fdobridge: <S​id> the game does launch on damavand
12:24 fdobridge: <z​mike.> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
12:24 fdobridge: <S​id> and with ziNVK, iirc
12:24 fdobridge: <S​id> just nir dxvk
12:24 fdobridge: <S​id> not*
12:24 fdobridge: <r​hed0x> do you want to get a GFXR with prop to debug it?
12:26 fdobridge: <S​id> I probably should, yeah
12:26 fdobridge: <S​id> will do in about an hour
12:26 fdobridge: <S​id> have one last class for the day
12:31 fdobridge: <!​DodoNVK (she) 🇱🇹> Here's a hack for this 🍩
12:31 fdobridge: <!​DodoNVK (she) 🇱🇹> https://cdn.discordapp.com/attachments/1034184951790305330/1214913121328828456/nvk-disable-bda-hack.diff?ex=65fad704&is=65e86204&hm=d3f9f0a356dba90904517fccf1f2d0a91cf5fdf53311d1922563282be6c67f2d&
12:33 fdobridge: <!​DodoNVK (she) 🇱🇹> https://cdn.discordapp.com/attachments/1034184951790305330/1214913691498184734/nvk-disable-bda-hack2.diff?ex=65fad78c&is=65e8628c&hm=459342449a4aaec06f52674bf96244938c048266519ab2fa9ae60d609a7aabc9&
13:47 sadmoments: Khmer politicians will kill your terrorists one by one due to harming their locations and business incomes , and in computing you are as big of a scum as in terror. You get what you were coming after not, you will be entirely torn.
13:58 sadmoments: We place ultimatum to your abuse parasites on our locations, if khmer powers do not execute those, no tourist will ever visit them.
13:59 fdobridge: <S​id> I imagine this'll be helpful for testing
13:59 fdobridge: <S​id> https://github.com/doitsujin/dxvk/commit/0414bbe2d5d5ee0df027731a91f251312ca84cf4
14:08 fdobridge: <g​fxstrand> Yeah, I'll give it a read. It's not like I'm making progress on my bug anyway. 🙄
14:10 fdobridge: <k​arolherbst🐧🦀> :blobcatnotlikethis:
14:10 fdobridge: <k​arolherbst🐧🦀> thanks
14:12 fdobridge: <g​fxstrand> IDK how painful but yeah
14:13 fdobridge: <g​fxstrand> That needs kernel API. I don't remember if I have a tracker issue for it or not.
14:15 fdobridge: <t​om3026> might be useful i bet things might go bonkers if you start a game using dlss and similiar that was working through the nvapi "shim" heh
14:16 fdobridge: <k​arolherbst🐧🦀> I think I'll ignore syncobjs for now and just implement `EXEC` so I make some progress today :ferrisUpsideDown:
14:16 fdobridge: <S​id> I couldn't find one
14:17 fdobridge: <!​DodoNVK (she) 🇱🇹> Is there a list of all kernel-side nouveau TODOs?
14:47 fdobridge: <g​fxstrand> Yes! I have a "kernel api" tag that gets applied to all the issues so you can filter for that
14:48 fdobridge: <g​fxstrand> See https://gitlab.freedesktop.org/mesa/mesa/-/issues/9640 as an example
14:49 fdobridge: <g​fxstrand> 👆🏻 👆🏻
15:00 fdobridge: <k​arolherbst🐧🦀> next: using `VM_BIND` :ferrisUpsideDown: seems like mapping the old exec UAPI on top of the new one is "possible", but all this bo tracking I have no idea what to do about atm... Like what libdrm did was to update if a bo was used for writing/reading based on the result of the old exec UAPI
15:02 fdobridge: <k​arolherbst🐧🦀> ohh actually.. it's only relevant for `bo_wait` and that's going to be different
15:02 fdobridge: <k​arolherbst🐧🦀> nice...
15:04 fdobridge: <S​id> hmmm, gitlab search being mean to me then :\
15:09 fdobridge: <S​id> @mohamexiety I realized I did a big dumb the other day
15:09 fdobridge: <S​id> while testing the sparse MR
15:09 fdobridge: <S​id> I didn't really test a workload that absolutely needed sparse: vkd3d-proton
15:10 fdobridge: <m​ohamexiety> it's probably not going to work because there are other requirements that are missing
15:11 fdobridge: <S​id> ...like?
15:11 fdobridge: <m​ohamexiety> I don't remember
15:11 fdobridge: <S​id> descriptor buffers are optional to vkd3d-proton
15:11 fdobridge: <S​id> and if faith is to be believed this is all we're missing for it
15:11 fdobridge: <m​ohamexiety> but p much all d3d12 games render black minus the UI so I don't think sparse will help much
15:11 fdobridge: <S​id> hm, yeah
15:11 fdobridge: <m​ohamexiety> you can try it I guess
15:12 fdobridge: <S​id> am compiling as we speak :3
15:12 fdobridge: <S​id> were you able to look into the sparse-breaks-zink thing?
15:14 fdobridge: <m​ohamexiety> yeah, it's a fairly silly mistake. I just forgot to push, will do so in a bit
15:15 fdobridge: <S​id> okie <3
15:18 fdobridge: <S​id> our rebar logic is broken
15:19 fdobridge: <S​id> I need to set VKD3D_CONFIG=no_upload_hvv for it to load into the main menu
15:19 fdobridge: <S​id> else it complains about not enough video memory
15:19 fdobridge: <S​id> `no_upload_hvv - Blocks any attempt to use host-visible VRAM (large/resizable BAR) for the UPLOAD heap. May free up vital VRAM in certain critical situations, at cost of lower GPU performance. A fraction of VRAM is reserved for resizable BAR allocations either way, so it should not be a real issue even on lower VRAM cards.`
15:22 fdobridge: <m​ohamexiety> I don't remember if that landed or not, but we don't really expose a BAR yet
15:24 fdobridge: <S​id> well, vkd3d-proton tries to access it, so I assume it did land
15:24 fdobridge: <S​id> `39487.290:0130:0134:info:vkd3d-proton:vkd3d_memory_info_upload_hvv_memory_properties: Topology: No more than 1 device local heap, assuming ReBAR-style access. Using DEVICE_LOCAL | HOST_COHERENT for UPLOAD.`
15:31 fdobridge: <k​arolherbst🐧🦀> okay... I'm sure it works on first try...
15:33 fdobridge: <S​id> oh noooo
15:33 fdobridge: <S​id> amid evil regressed 😭
15:33 fdobridge: <S​id> used to load me into map while rendering black
15:33 fdobridge: <S​id> now it loads into main menu and goes black
15:46 fdobridge: <k​arolherbst🐧🦀> okay! my `VM_BIND` branch is enough to execute glxinfo. Sadly glxgears gives me a black window 😄
15:46 fdobridge: <S​id> what about with zink
15:47 fdobridge: <k​arolherbst🐧🦀> ohh.. it's `bo_wait` not working.. figures
15:48 fdobridge: <k​arolherbst🐧🦀> I mean.. we can go both ways for now. I don't think it's really that much of a deal to use VM_BIND... the question is just how much of the gl driver needs to change, if not at all, then it doesn't matter much
15:49 fdobridge: <k​arolherbst🐧🦀> but I think I have a solution for `bo_wait`, I just attach the syncobj from the submission to the bos and wait on that?
16:21 fdobridge: <z​mike.> anyone looking at `KHR-GL46.direct_state_access.framebuffers_texture_layer_attachment`
16:25 fdobridge: <g​fxstrand> @karolherbst Do we have a way of getting real GPU names?
16:26 fdobridge: <k​arolherbst🐧🦀> I don't think so
16:26 fdobridge: <g​fxstrand> lspci gets a name
16:26 fdobridge: <k​arolherbst🐧🦀> sure, but that's from a database file
16:27 fdobridge: <g​fxstrand> Can we scrape that database?
16:27 fdobridge: <t​om3026> https://pci-ids.ucw.cz/v2.2/pci.ids
16:27 fdobridge: <k​arolherbst🐧🦀> libpciaccess has an API for that, no?
16:27 fdobridge: <k​arolherbst🐧🦀> or how does lspci do it?
16:27 fdobridge: <k​arolherbst🐧🦀> I mean.. we could do the same, it's just not very realible
16:27 fdobridge: <k​arolherbst🐧🦀> but also better than nothing
16:29 fdobridge: <t​om3026> https://github.com/pciutils/pciutils/blob/master/lib/names.c#L126
16:30 fdobridge: <g​fxstrand> Yeah, looks like it does.
16:30 fdobridge: <t​om3026> or can you just depend on libpciaccess and use it directly? 😛
16:31 fdobridge: <z​mike.> this is the only other case in glcts that hangs
16:31 fdobridge: <S​id> here's the database https://github.com/pciutils/pciutils/blob/master/pci.ids
16:31 fdobridge: <S​id> in the upstream source, that is
16:32 fdobridge: <g​fxstrand> Looks like libdrm already requires libpciaccess so we may as well
16:32 fdobridge: <t​om3026> its fetched from https://pci-ids.ucw.cz/
16:32 fdobridge: <S​id> hm
16:32 fdobridge: <S​id> oh well, all the same then :D
16:32 fdobridge: <t​om3026> https://github.com/pciutils/pciutils/blob/master/update-pciids.sh :p
16:32 fdobridge: <t​om3026> then its very easy heh
16:35 fdobridge: <!​DodoNVK (she) 🇱🇹> AMD does this instead: https://gitlab.freedesktop.org/mesa/drm/-/blob/main/data/amdgpu.ids
16:36 fdobridge: <t​riang3l> This doesn't have revision IDs though, does Nvidia use them at all for different graphics cards with the same device ID?
16:37 fdobridge: <t​riang3l> on AMD for some reason the revision ID apparently even has some effect on texture tiling as it's somehow used in addrlib 🥵
16:37 fdobridge: <g​fxstrand> Maybe? Without docs, we don't know
16:38 fdobridge: <g​fxstrand> My objective is to get something more useful to users than GA106
16:38 fdobridge: <g​fxstrand> And to have listed in vulkaninfo.org
16:38 fdobridge: <t​riang3l> (including for some mip-related bug on some Evergreen if I recall correctly, not sure if it's actually hit in GL/Vulkan though :frog_gears:)
16:38 fdobridge: <g​fxstrand> Intel has a bunch of rev-specific workarounds too, annoyingly
16:38 fdobridge: <t​om3026> dont think the open nvidia kernel driver hecks for revisions either if im not reading this bigass array wrong
16:38 fdobridge: <t​om3026> *checks
16:42 fdobridge: <t​om3026> https://github.com/NVIDIA/open-gpu-kernel-modules/blob/476bd34534a9389eedff73464d3f2fa5912f09ae/src/nvidia/generated/g_nv_name_released.h#L179 https://github.com/NVIDIA/open-gpu-kernel-modules/blob/476bd34534a9389eedff73464d3f2fa5912f09ae/src/nvidia/arch/nvalloc/unix/src/osapi.c#L3359 , just iterate over it, match devid/vendorid/subsystemid and return same name for them all and not much other use of that array in there
16:42 fdobridge: <g​fxstrand> Ugh... This API is not what I want...
16:43 fdobridge: <!​DodoNVK (she) 🇱🇹> Should GPU metrics support (and hwmon for GSP too) be reported to drm/nouveau instead?
16:43 fdobridge: <t​riang3l> This is a weird list, some AMD Cedar GPUs are listed as Redwood
16:44 fdobridge: <k​arolherbst🐧🦀> the kernel doesn't like my execs with the sync objs 🥲
16:44 fdobridge: <t​riang3l> ah, no, it's some subsystem ID
16:44 fdobridge: <t​om3026> well im not sure who composes that list but its what we all use heh
16:44 fdobridge: <t​om3026> oh ok
16:45 fdobridge: <g​fxstrand> Maybe we should just pull that header. Looks like it goes back to Maxwell A. @karolherbst , thoughts?
16:45 fdobridge: <g​fxstrand> I'm going to see if I can get that list to work
16:45 fdobridge: <S​id> pull it
16:45 fdobridge: <t​riang3l> Yeah, that thing seems more or less correct, and more detailed than `r600_pci_ids.h`. Like Cedar's mobile variant (which needs all the same settings in things like shaders, not sure about texture tiling) is named Park
16:46 fdobridge: <k​arolherbst🐧🦀> yeah, probably a good idea
16:46 fdobridge: <S​id> relying on nv's headers is better than pulling from a third party source
16:48 fdobridge: <k​arolherbst🐧🦀> uhhh
16:48 fdobridge: <k​arolherbst🐧🦀> why is `set.h` such a pain to use
16:48 fdobridge: <S​id> rewrite it
16:48 fdobridge: <S​id> 😈
16:49 fdobridge: <k​arolherbst🐧🦀> maybe I just wait on the same syncobj multiple times and don't care
16:50 fdobridge: <t​riang3l> Pre-`qsort` it (in Python) and `bsearch`… or compute hashes in Python :evil_gears:
16:51 fdobridge: <t​riang3l> oh, that's not for the device ID list :frog_gears:
16:51 fdobridge: <k​arolherbst🐧🦀> yeah, it's not 😄
16:52 fdobridge: <k​arolherbst🐧🦀> mhhh
16:53 fdobridge: <k​arolherbst🐧🦀> it still black, but at least it's submitting stuff...
16:53 fdobridge: <k​arolherbst🐧🦀> I'm sure my code is completely right, must be a kernel bug!1!!
16:54 fdobridge: <k​arolherbst🐧🦀> it's funky that it renders 822 frames every 5.4 seconds
16:57 Sid127: !!1!!1!
16:59 fdobridge: <k​arolherbst🐧🦀> ohh.. I'm submitting trash apparently.. I wonder what's wrong
16:59 fdobridge: <k​arolherbst🐧🦀> `nouveau 0000:01:00.0: gr: DATA_ERROR 0000000d [BEGIN_END_ACTIVE] ch 7 [059f348000 glxgears[4367]] subc 0 class c597 mthd 1700 data ffffffff`
17:00 fdobridge: <k​arolherbst🐧🦀> ohh wait...
17:00 fdobridge: <k​arolherbst🐧🦀> I probably also have to fix `bo_map` 🥲
17:00 fdobridge: <k​arolherbst🐧🦀> 😄
17:01 fdobridge: <k​arolherbst🐧🦀> mhh.. maybe I don't...
17:02 fdobridge: <k​arolherbst🐧🦀> @gfxstrand mind taking a quick look to check if I missed anything obvious? https://gitlab.freedesktop.org/karolherbst/mesa/-/commit/d32e7647b96bb125ace6b43ba9a0530bd6f9e9bb
17:02 fdobridge: <S​id> should I play a game
17:02 fdobridge: <k​arolherbst🐧🦀> maybe I should limit to a 32 bit vm for now to rule out weird pointer bugs
17:03 fdobridge: <S​id> or should I capture traces for debugging
17:03 fdobridge: <S​id> hmmmmmmmmmmmmmm
17:03 Sid127: devil on your shoulder here: capture traces
17:16 fdobridge: <k​arolherbst🐧🦀> @gfxstrand btw, I have now access to the nvidia bug thingy 😄
17:17 fdobridge: <S​id> o
17:19 fdobridge: <p​rop_energy_ball> https://cdn.discordapp.com/attachments/1034184951790305330/1214985785191698484/sddefault.png?ex=65fb1ab0&is=65e8a5b0&hm=308ebdfc6fc74d2ed67a5b185e8aecdce0d4fe9449925fa3dc96342ace863925&
17:19 fdobridge: <p​rop_energy_ball> don't ask why i had this image on my desktop
17:20 fdobridge: <g​fxstrand> Yay!
17:20 fdobridge: <k​arolherbst🐧🦀> I think they still work on creating a proper category for our stuff, but yeah... it's progressing 🙂
17:20 fdobridge: <S​id> nice
17:21 fdobridge: <k​arolherbst🐧🦀> now I have the power to annoy nvidia with the first 1000 bugs I'm gonna file
17:22 fdobridge: <k​arolherbst🐧🦀> but anyway.. mhh what's wrong with my vm_bind thing, it all looks totally perfect and I'm also totally not leaking syncobjs
17:23 fdobridge: <k​arolherbst🐧🦀> maybe I should allocate one per bo...
17:25 fdobridge: <k​arolherbst🐧🦀> mhh but that wouldn't work, because I can't really use one on both sides
17:37 fdobridge: <g​fxstrand> https://vulkan.gpuinfo.org/displayreport.php?id=28783
17:38 fdobridge: <m​ohamexiety> yay!
17:40 fdobridge: <t​riang3l> Having NVK referred to in the device name should make showing its progress off on vulkan.gpuinfo.org easier :happy_gears:
17:41 fdobridge: <m​ohamexiety> think the driver ID does that, no? mesa's is fairly distinct from NVIDIA's
17:41 fdobridge: <g​fxstrand> Yes, that's what driverID is for
17:41 fdobridge: <g​fxstrand> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28024 is the MR
17:41 fdobridge: <t​riang3l> Yeah, I think we should add that column to that website
17:43 fdobridge: <g​fxstrand> Yeah, let me poke Sascha about that
17:44 fdobridge: <t​riang3l> so it doesn't look like a report from Nvidia Detonator from 2002 :frog_gears:
17:49 fdobridge: <g​fxstrand> I pinged Sascha
17:50 fdobridge: <g​fxstrand> Also, I'm submitting them under my name so you can find my reports here: https://vulkan.gpuinfo.org/listreports.php?submitter=Faith%20Ekstrand
17:51 fdobridge: <g​fxstrand> Unfortunately, there's no security whatsoever on that so someone can submit utter bullshit and claim it came from me.
17:51 fdobridge: <g​fxstrand> But as long as no one abuses it, that should be a "yeah, this is real" reports list
17:52 fdobridge: <t​riang3l> What also makes me _sweat_ when I browse it, by the way, is that for the Android hell it displays phone/tablet names instead of GPU names :cursedgears:
17:53 fdobridge: <p​rop_energy_ball> `with Max-Q Design`
17:54 fdobridge: <p​rop_energy_ball> fuck it
17:55 fdobridge: <g​fxstrand> Yeah, that gave me pause, too. 😅
17:55 fdobridge: <J​oshie with Max-Q Design> `gfxtrand with Max-Q Design` when?
17:55 fdobridge: <h​untercz122> what's even max-q design?
17:55 fdobridge: <h​untercz122> i avoided them when i was buying laptop back in 2019
17:55 fdobridge: <J​oshie with Max-Q Design> `gfxstrand with Max-Q Design` when? (edited)
17:55 fdobridge: <d​adschoorse> low power
17:56 fdobridge: <J​oshie with Max-Q Design> Maybe you are more `Ada Generation Laptop GPU`
17:56 fdobridge: <g​fxstrand> The official NVIDIA thing says "4060 laptop GPU"
17:56 fdobridge: <S​id> I feel like MX350
17:56 fdobridge: <d​adschoorse> at least no random tm like the old amd list 🐸
17:56 fdobridge: <S​id> :>
17:56 fdobridge: <g​fxstrand> Whether or not your Q's are maxed is left for you to figure out.
17:57 fdobridge: <J​oshie with Max-Q Design> ~~it's actually about whether encoding is always max Qp`
17:57 fdobridge: <J​oshie with Max-Q Design> ~~it's actually about whether encoding is always max Qp~~ (edited)
17:57 fdobridge: <J​oshie with Max-Q Design> LOL
17:57 fdobridge: <J​oshie with Max-Q Design> god
17:57 fdobridge: <J​oshie with Max-Q Design> that was funny
17:57 fdobridge: <t​riang3l> Should I report HD 5xxx as AMD, ATI, or both? 🥵
17:57 fdobridge: <d​adschoorse> just get the name from libdrm?
17:58 fdobridge: <t​riang3l> libdrm_radeon doesn't have names 🤷‍♂️
17:58 fdobridge: <d​adschoorse> meme driver
17:58 fdobridge: <S​id> AMD ATI Radeom™ HD 5xxx
17:59 fdobridge: <S​id> NVIDIA 3DFX GeForce RTX 50xx when
17:59 fdobridge: <h​untercz122> zink Vulkan 1.3 (NVIDIA GeForce RTX 2060 with Max-Q Design)
17:59 fdobridge: <h​untercz122> we need to go longer
18:00 fdobridge: <t​riang3l> Hmmm, I thought that was their OpenGL device naming, but they actually switched from ATI to AMD for 5xxx at some point in their Windows OpenGL driver
18:00 fdobridge: <m​ohamexiety> my HD 5450 says ATI/AMD on the PCB iirc
18:00 fdobridge: <S​id> you forgot the Super Ti XTX
18:00 fdobridge: <d​adschoorse> what wasn't funny was how long it took them to get approval for that trivial cleanup 🐸
18:01 fdobridge: <S​id> NVIDIA 3DFX GeForce RTX 5000 Super Ti Charles Babbage Generation
18:01 fdobridge: <S​id> real
18:01 fdobridge: <J​oshie with Max-Q Design> uwu gfx card when
18:01 fdobridge: <J​oshie with Max-Q Design> NVIDIA RTX 7000 Super Ti Hatsune Miku Twerking UwU Edition
18:02 fdobridge: <J​oshie with Max-Q Design> https://cdn.discordapp.com/attachments/1034184951790305330/1214996485343551508/thank-you-senpai-v0-mooa711lo4oa1.png?ex=65fb24a7&is=65e8afa7&hm=adf6aab77422b2addbe93dcf6b5bfc9205e7003fb3aea829c4f6653b2209e447&
18:02 fdobridge: <m​ohamexiety> got you my man
18:02 fdobridge: <m​ohamexiety> https://cdn.discordapp.com/attachments/1034184951790305330/1214996621796839496/image.png?ex=65fb24c8&is=65e8afc8&hm=a74834ed6ec8e97912f554b2ff09226dbb02a2b1da25ecc81ee051137bbeea56&
18:02 fdobridge: <d​adschoorse> needs more jpeg
18:02 fdobridge: <t​riang3l> Apple ImgTec VideoLogic M3 Max GPU
18:03 fdobridge: <S​id> I kinda wanna send something like that to the LKML as a joke
18:03 fdobridge: <p​ac85> That's owo not uwu
18:03 fdobridge: <!​DodoNVK (she) 🇱🇹> Am I a Q-maxxer?
18:04 fdobridge: <t​riang3l> and Qualcomm AMD ATI Adreno 750
18:04 fdobridge: <h​untercz122> D3D12 (Qualcomm AMD ATI Adreno 750)
18:04 fdobridge: <t​riang3l> + Imageon
18:04 fdobridge: <!​DodoNVK (she) 🇱🇹> This issue is no longer up I think
18:05 fdobridge: <t​riang3l> I actually wish they ported their D3D11 driver to Android and layered Vulkan on top of its internals instead of releasing that meme driver with `independentBlend = VK_FALSE`
18:06 fdobridge: <t​riang3l> probably will be the only truly mandatory feature in Xenia
18:07 fdobridge: <t​riang3l> unless I implement depth/stencil save/restore for doing separate draws for each color attachment
18:10 fdobridge: <p​ac85> Why do you ask for a meme thing one change of the current meme thing
18:10 fdobridge: <p​ac85> Why do you ask for a meme thing in change of the current meme thing (edited)
18:23 fdobridge: <t​om3026> @gfxstrand was that MR supposed to bring in nvk: Return os_page_size for minMemoryMapAlignment while its a seperate MR https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28019
18:24 fdobridge: <t​om3026> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28024/commits
18:27 fdobridge: <k​arolherbst🐧🦀> mhh yeah.. something isn't right with the push buffers on the GPU's side...
18:31 fdobridge: <g​fxstrand> Unless the merge queue goes out-of-order, it's fine
18:32 fdobridge: <z​mike.> is it a sparse queue ?
18:32 fdobridge: <t​om3026> i thought it would complain like "Reversed (or previously applied) patch detected! Assume -R? [n]" but okay :p
18:37 Lyude: karolherbst: feel free to give it a shot!
18:38 karolherbst: the core bits are already wired up for intel I assume?
18:38 Lyude: also - I found another kepler (it's either kepler or fermi, will have to double check) GPU I have that I completely forgot I had :)
18:38 Lyude: karolherbst: not sure tbh
18:38 karolherbst: funky
18:38 fdobridge: <g​fxstrand> Yeah, sometimes it complains. I dropped the `minMemoryMapAlignment` patch
18:38 fdobridge: <g​fxstrand> Yeah, sometimes it complains. I dropped the `minMemoryMapAlignment` patch just in case (edited)
18:39 fdobridge: <t​om3026> https://tenor.com/view/i-can-be-useful-parker-posey-dr-smith-effective-helpful-gif-16230408
18:39 fdobridge: <t​om3026> okay
18:40 karolherbst: I'm sure it won't be too terrible to support :D
18:53 fdobridge: <b​ylaws> They've done the first part of that already! Check the WSA image in their driver packages
19:04 fdobridge: <v​alentineburley> Hi, I have a commit to enable VK_KHR_shader_subgroup_uniform_control_flow to address <https://gitlab.freedesktop.org/mesa/mesa/-/issues/9622>.
19:04 fdobridge: <v​alentineburley> I will open a MR when my verification request is accepted.
19:04 fdobridge: <v​alentineburley>
19:04 fdobridge: <v​alentineburley> A quick scan at gpuinfo.org indicates that this is Volta+ only, so I should only enable it for `info->cls_eng3d >= VOLTA_A`, right? I only have my Turing to test.
19:06 fdobridge: <!​DodoNVK (she) 🇱🇹> Volta is a weird mixture of Pascal and Turing features
19:06 fdobridge: <z​mike.> @karolherbst if you have nouveau GL driver available, does it pass KHR-GLES3.copy_tex_image_conversions.forbidden.cubemap_negx_cubemap_negx
19:07 fdobridge: <z​mike.> I think I just discovered that mesa doesn't fully implement restrictions on texture copies
19:08 fdobridge: <k​arolherbst🐧🦀> it fails
19:08 fdobridge: <z​mike.> :stressheadache: :migraine: :hypertensionheadache: :fullheadache:
19:08 fdobridge: <k​arolherbst🐧🦀> this time I feel you
19:09 fdobridge: <z​mike.> I think these only pass on other drivers because they don't support enough formats to fail
19:09 fdobridge: <k​arolherbst🐧🦀> 😄
19:09 fdobridge: <!​DodoNVK (she) 🇱🇹> But anyway setting that to Volta should be a safe bet until someone gets some older hardware to test
19:09 fdobridge: <k​arolherbst🐧🦀> pain
19:09 fdobridge: <v​alentineburley> All right, thanks
19:11 fdobridge: <z​mike.> and mesa also doesn't correctly implement the differences between GL and ES 🤕
19:11 fdobridge: <z​mike.> triangles were a mistake.
19:14 fdobridge: <k​arolherbst🐧🦀> ahhh.. why am I spending 90% of the time debugging C problems 🥲
19:14 fdobridge: <k​arolherbst🐧🦀> let's do polylines instead
19:16 fdobridge: <k​arolherbst🐧🦀> anyway.. something is not right with the push buffers I submit via `EXEC`. @gfxstrand is there anything special I have to take into account? Like allocating the bos a special way or unmapping them or anything strange?
19:18 fdobridge: <k​arolherbst🐧🦀> maybe my waits aren't working and I messed up syncobjs? mhh..
19:18 fdobridge: <g​fxstrand> Nope
19:18 fdobridge: <g​fxstrand> You just give address ranges
19:18 fdobridge: <k​arolherbst🐧🦀> mhhh
19:19 fdobridge: <k​arolherbst🐧🦀> maybe I should pass in `DRM_NOUVEAU_EXEC_PUSH_NO_PREFETCH`?
19:20 fdobridge: <k​arolherbst🐧🦀> though I think the first submissions are fine...
19:20 fdobridge: <k​arolherbst🐧🦀> maybe something else is just going horribly wrong
19:23 fdobridge: <k​arolherbst🐧🦀> mhhh...
19:23 fdobridge: <k​arolherbst🐧🦀> yeah.. it makes no sense
19:24 fdobridge: <k​arolherbst🐧🦀> ahahahahahhhhhhhhhh
19:28 fdobridge: <r​inlovesyou> time to oxidize? :dogkek:
19:29 fdobridge: <k​arolherbst🐧🦀> .......
19:29 fdobridge: <k​arolherbst🐧🦀> I think I found it ...
19:29 fdobridge: <k​arolherbst🐧🦀> @gfxstrand you don't want to know what I did incorrectly 😄
19:31 fdobridge: <k​arolherbst🐧🦀> I used the bos size instead of how much commands were added...
20:02 fdobridge: <g​fxstrand> oops
20:06 fdobridge: <k​arolherbst🐧🦀> still doesn't work, but I'll figure it out tomorrow...
20:13 fdobridge: <k​arolherbst🐧🦀> okay.. found another problem in my code 😄
20:14 fdobridge: <k​arolherbst🐧🦀> this time I didn't apply the internal offset of the internally tracked buffers in`nouveau_push`
20:15 fdobridge: <k​arolherbst🐧🦀> mhh.. still all black
20:59 fdobridge: <z​mike.> huh I think I might have accidentally fixed a ton of tests with this
20:59 fdobridge: <z​mike.> it's a good day.
21:00 fdobridge: <d​adschoorse> I thought a good day is when you spend all day in khronos meetings? 🐸
21:01 fdobridge: <z​mike.> I did that earlier too
21:39 fdobridge: <z​mike.> cool I fixed the majority of the remaining nvk fails on glcts
21:39 fdobridge: <z​mike.> less than 20 left
21:39 fdobridge: <g​fxstrand> 🎉
21:40 fdobridge: <z​mike.> looks like ~5 on GL and ~10 on ES
21:40 fdobridge: <z​mike.> the ES ones are like 3 bugs total
21:40 fdobridge: <z​mike.> mostly multisample
21:41 fdobridge: <!​DodoNVK (she) 🇱🇹> turnip-level speed
21:41 fdobridge: <z​mike.> no, danylo works at the speed of light
21:56 fdobridge: <a​irlied> @gfxstrand I wonder if importing nvidia's supported gpus json file has enough infoi
21:57 fdobridge: <S​id> enough info about?
21:57 fdobridge: <a​irlied> like proper names mapped to pci id
21:57 fdobridge: <g​fxstrand> There/s a json file?
21:57 fdobridge: <g​fxstrand> There's a json file? (edited)
21:58 fdobridge: <a​irlied> though maybe it's only in the run distribution
21:58 fdobridge: <a​irlied> and not their kernel driver
21:58 fdobridge: <g​fxstrand> Where is this json file?
22:01 fdobridge: <a​irlied> dang it's only in the run files
22:01 fdobridge: <k​arolherbst🐧🦀> what license would it be under anyway :ferrisUpsideDown:
22:01 fdobridge: <a​irlied> it has a separate license
22:01 fdobridge: <a​irlied> looks MITish
22:02 fdobridge: <a​irlied> but yeah it has to be extracted from the .run I can't see it anywhere else
22:02 fdobridge: <g​fxstrand> I should probably have double checked licenses before pulling the kernel header into Mesa. 😬
22:02 fdobridge: <k​arolherbst🐧🦀> I mean.. that can be done once an nvidia release
22:02 fdobridge: <k​arolherbst🐧🦀> ogk is gpl, no?
22:03 Lyude: btw, about to take a break for a bit so I can see how well GSP currently works with nouveau but- I think I'm basically at the point all of the rust bindings I have so far for KMS should like, actually be safe :D
22:03 fdobridge: <g​fxstrand> OGK is MIT
22:03 fdobridge: <a​irlied> no it's MIT, but this has it's own LICENSE file
22:03 fdobridge: <k​arolherbst🐧🦀> iohh
22:03 fdobridge: <k​arolherbst🐧🦀> interesting
22:03 karolherbst: Lyude: nice
22:03 fdobridge: <g​fxstrand> I should probably paste that license at the top of the header but then it's a pain to sycn
22:04 fdobridge: <a​irlied> or just drop both into a separate directory
22:04 Lyude: karolherbst: btw something I did actually learn along the way - you can actually cast pointers between types rust and ffi types using as instead of using container_of!(), since you can use #[repr(C)] to tell the compiler not to reorder types
22:05 karolherbst: Lyude: sure, but that's like "you gotta be careful" area :P
22:06 Lyude: karolherbst: mhm, careful can also just be a build assert though if you really need :P
22:06 karolherbst: but yeah.. offset at 0 usually has its own perf advantages, which often just don't relaly matter
22:06 karolherbst: yeah
22:06 fdobridge: <S​id> couldn't find the .json here either
22:06 fdobridge: <S​id> https://github.com/NVIDIA/nvidia-installer
22:06 karolherbst: or just use container_of and it optimizes to + 0x0 :P
22:06 Lyude: the main reason I've been using it is because it actually makes it a lot easier if the ffi type you're trying to use is behind some abstraction type
22:06 karolherbst: you can also just have cast methods on the type
22:07 karolherbst: like.. implemeting From or so
22:07 karolherbst: thought that's a pain on pointers
22:08 Lyude: yes - but those are still a bit painful to implement if you have to say, go from bindings::drm_connector → Opaque<drm_connector> → *const Connector<T> → Box<Connector<T>>
22:09 karolherbst: right...
22:09 karolherbst: though to get the box you still have to call a function, could call a function doing the entire chain instead
22:10 Lyude: eh - I do also provide a function as well :)
22:10 karolherbst: fair enough
22:21 fdobridge: <a​irlied> @karolherbst you may have to use the ioctl to associate sync with bos for implicit sync to work, the ioctl name escapes me right now
22:21 fdobridge: <k​arolherbst🐧🦀> ahhh
22:21 fdobridge: <k​arolherbst🐧🦀> but I'm not doing implicit sync atm...
22:22 fdobridge: <k​arolherbst🐧🦀> but I also have no idea what's going wrong, all I know is that the rendering is black 😦
22:22 fdobridge: <a​irlied> I assume whatever you are presenting to is using implicit sync
22:23 fdobridge: <k​arolherbst🐧🦀> ohhh
22:23 fdobridge: <k​arolherbst🐧🦀> that might be
22:23 fdobridge: <k​arolherbst🐧🦀> I haven't looked at any of that yet. I've tried running some CTS stuff, but that ran into ENOMEM issues 🥲
22:24 fdobridge: <a​irlied> IMPORT/EXPORT_SYNC are probably what to grep for in mesa
22:24 fdobridge: <a​irlied> iris at least uses them
22:25 fdobridge: <k​arolherbst🐧🦀> yeah.. I'll check it out tomorrow, thanks for the pointers. I think the core bits are all good at this point, just don't really know what's up with the enomem.. and also how I manage syncobjects is quite annoying
22:26 fdobridge: <k​arolherbst🐧🦀> I really should attach it to the fence instead
22:44 fdobridge: <g​fxstrand> It's in the run files but it has an actual license and it's basically MIT
22:44 fdobridge: <g​fxstrand> So we can use it.
22:46 fdobridge: <S​id> I am bringing this up again now that some of you are here
22:47 fdobridge: <S​id> nvk trying to use rebar results in an out of video memory error
22:47 fdobridge: <S​id> from gfxrecon: `[gfxrecon] FATAL - API call at index: 104 thread: 1 vkCreateDevice returned error value VK_ERROR_OUT_OF_DEVICE_MEMORY that does not match the result from the capture file: VK_SUCCESS. Replay cannot continue.`
22:47 fdobridge: <S​id> log from vkd3d-proton
22:47 fdobridge: <S​id> `39487.290:0130:0134:info:vkd3d-proton:vkd3d_memory_info_upload_hvv_memory_properties: Topology: No more than 1 device local heap, assuming ReBAR-style access. Using DEVICE_LOCAL | HOST_COHERENT for UPLOAD.`
22:47 fdobridge: <S​id> using VKD3D_CONFIG=no_upload_hvv makes the error go away
22:48 fdobridge: <S​id> `no_upload_hvv - Blocks any attempt to use host-visible VRAM (large/resizable BAR) for the UPLOAD heap. May free up vital VRAM in certain critical situations, at cost of lower GPU performance.`
22:48 fdobridge: <S​id> sadly no way to work around it except disable ReBAR outside of vkd3d-proton
22:57 Lyude: airlied: is there anything special I have to do to get nvk setup on a fedora machine? (e.g. are we already building it in our mesa, etc.?)
22:58 fdobridge: <S​id> fedora 40 builds it by default afaik
22:58 Lyude: yay thank you
22:59 fdobridge: <g​fxstrand> Actually, it's not MIT. It's something weird and bespoke which might give distros heartburn
23:00 fdobridge: <S​id> faith you might find this interesting
23:00 fdobridge: <S​id> I'm trying to find the commit where we did the rebar thingy to try and revert it
23:00 fdobridge: <S​id> for testing purpose
23:04 fdobridge: <S​id> found it
23:04 fdobridge: <S​id> !26622
23:12 fdobridge: <S​id> huh
23:12 fdobridge: <S​id> curious
23:13 fdobridge: <S​id> reverting that MR fixes the OOVMem errors for vkd3d-proton but not gfxrecon
23:15 airlied: Lyude: if you have a 6.7 kernel then self builds should run fine, but also f40 has it packaged
23:16 Lyude: yeah sounds like I might just jump to f40 then
23:23 fdobridge: <k​arolherbst🐧🦀> @airlied well.. OpenCL works 🥲
23:23 fdobridge: <S​id> one step closer to cuda
23:25 fdobridge: <k​arolherbst🐧🦀> but mhh
23:25 fdobridge: <k​arolherbst🐧🦀> something is not entirely right
23:25 Lyude: some day it'd be nice to see if I we could actually like, come up with some sort of kernel interface to let people write code for bindgen
23:25 karolherbst: yeah.. but that means adding stuff to Kbuild :P
23:26 karolherbst: or did you mean like something else?
23:26 fdobridge: <S​id> it feels so weird
23:26 fdobridge: <S​id> trying to read faith's code and finding the source of an error
23:27 fdobridge: <k​arolherbst🐧🦀> yeah...
23:27 fdobridge: <k​arolherbst🐧🦀> sometimes is up with allocating textures or something
23:32 fdobridge: <S​id> ok so
23:32 fdobridge: <S​id> this is funny
23:32 fdobridge: <S​id> https://cdn.discordapp.com/attachments/1034184951790305330/1215079666654773258/image.png?ex=65fb721f&is=65e8fd1f&hm=4b3e4301c2e5bed515cedfc22aa470bad77923eeac1927ed7025966f8d406936&
23:33 fdobridge: <a​irlied> @karolherbst got a branch I can glance at?
23:33 fdobridge: <S​id> this happens even when I force nvk to do shader uploads via the upload queue regardless
23:34 fdobridge: <S​id> I think
23:34 fdobridge: <S​id> let me try something else..
23:34 fdobridge: <k​arolherbst🐧🦀> https://gitlab.freedesktop.org/karolherbst/mesa/-/tree/nouveau/vm_bind
23:34 fdobridge: <k​arolherbst🐧🦀> it's mostly there, so I won't mind if you finish it all up 😄
23:35 fdobridge: <k​arolherbst🐧🦀> there are a few hacks here and there, but whatever
23:35 fdobridge: <S​id> unless this game is using the 32 bit driver
23:35 fdobridge: <a​irlied> @karolherbst are any gem object creations failing?
23:35 fdobridge: <S​id> ok it is not
23:35 fdobridge: <k​arolherbst🐧🦀> mhh... in the out of memory case at some point I think
23:35 fdobridge: <a​irlied> I can't remember if we blocked things with the kind bits set
23:35 fdobridge: <k​arolherbst🐧🦀> but like not with glxgears
23:36 fdobridge: <k​arolherbst🐧🦀> I kept finding bugs in my impl, so I assume there are more things not quite right.. but uhh
23:36 fdobridge: <k​arolherbst🐧🦀> no idea what at this point
23:38 fdobridge: <S​id> bleh
23:38 fdobridge: <S​id> I'll poke around this tomorrow
23:41 fdobridge: <a​irlied> I'll give it a spin and see if I can spot anything obiviously wrong
23:44 fdobridge: <S​id> ```
23:44 fdobridge: <S​id> 3151.916:0130:01f4:warn:vkd3d-proton:vkd3d_allocate_device_memory: Memory allocation failed, falling back to system memory.
23:44 fdobridge: <S​id> 3151.916:0130:01f4:err:vkd3d-proton:vkd3d_allocate_device_memory: Failed to allocate device memory (size 4194304, type_flags 0x7, type_mask 0x6).
23:44 fdobridge: <S​id> ```
23:44 fdobridge: <S​id> cause for oom error
23:46 fdobridge: <a​irlied> @karolherbst https://paste.centos.org/view/32c0371f helps a bit
23:46 fdobridge: <k​arolherbst🐧🦀> mhhhh
23:47 fdobridge: <k​arolherbst🐧🦀> I guess that makes sense
23:47 fdobridge: <k​arolherbst🐧🦀> so glxgears starts to display something?
23:49 fdobridge: <a​irlied> https://paste.centos.org/view/e0e6c544
23:49 fdobridge: <a​irlied> is better, but depth buffers fail to allocate
23:51 fdobridge: <k​arolherbst🐧🦀> ohh
23:51 fdobridge: <k​arolherbst🐧🦀> those are the ones failing
23:51 fdobridge: <k​arolherbst🐧🦀> I haven't checked that out yet, but yeah.. makes sense
23:52 fdobridge: <S​id> hm
23:52 fdobridge: <S​id> is our hw closer to AMD or Intel
23:52 fdobridge: <S​id> (for calibrated timestamps)
23:59 Lyude: https://gitlab.freedesktop.org/lyudess/linux/-/tree/rvkms/ pushed my latest work