03:38 airlied: dakr: actually splitting the lock worked, so I'll send out two patches to fix the object corruption
03:46 fdobridge: <a​irlied> @gfxstrand https://patchwork.freedesktop.org/patch/580696/ that is the proper patch (not much different to the one you are running)
03:46 fdobridge: <a​irlied> at least should kill that one bug, now I've got to work out the other painful one
03:50 fdobridge: <g​fxstrand> Cool
04:03 fdobridge: <S​id> hm, did I do something wrong..
04:03 fdobridge: <r​edsheep> I certainly did. Is it expected that installed mesa drivers are faster than ones that aren't installed?
04:03 fdobridge: <r​edsheep> Even when the build script involved is absolutely identical, save installing it?
04:06 fdobridge: <S​id> I don't see the patch I sent on dri-devel archives, hmm
04:06 fdobridge: <S​id> neither on patchwork
04:06 fdobridge: <a​irlied> yeah it probably got stuck in moderation
04:07 fdobridge: <a​irlied> I can just pull it from discord 😛
04:07 fdobridge: <r​edsheep> This performance testing is starting to make me seriously paranoid, I might have been wrong about the regression on 27840
04:07 fdobridge: <S​id> ah, moderation e-e
04:08 fdobridge: <S​id> hang on I'll reupload with better commit message
04:10 fdobridge: <r​edsheep> I don't know how I possibly could have foreseen that installing a driver would have a serious performance impact
04:10 fdobridge: <S​id> https://cdn.discordapp.com/attachments/1034184951790305330/1212975332986978304/0001-drm-nouveau-keep-DMA-buffers-required-for-suspend-re.patch?ex=65f3ca4f&is=65e1554f&hm=95d4b8a222f2b4431b8a3248dfafa114d92145c5a8a25bbd83430fdf1d8857d0&
04:11 fdobridge: <S​id> just some minor grammar changes that come from moving the Fixes bit down in the commit message
04:27 fdobridge: <r​edsheep> OK I am officially confused. Not only does the exact same commit yield higher performance by getting installed in The Talos Principle, the opposite is true in The Witness.
04:27 fdobridge: <r​edsheep>
04:27 fdobridge: <r​edsheep> The witness is markedly slower on an installed driver, again with exactly the same build parameters. Further, when doing more tightly comparable testing where you use two different non-installed builds with only 27840 as the variable under test the performance difference is so small it's not measurable in both games.
04:45 fdobridge: <r​edsheep> @gfxstrand Apparently my testing was tainted again ^
04:45 fdobridge: <r​edsheep>
04:45 fdobridge: <r​edsheep> Those numbers for 27840 were bogus, and I have absolutely no idea how. Does mesa load libraries at runtime that could be different depending on location or something? Maybe the phase of the moon?
04:47 fdobridge: <r​edsheep> The only thing I can possibly figure is that when I query my actual environment without specifying an icd path my vulkaninfo has one entry that says llvm, and another that does not... Maybe that matters?
04:48 fdobridge: <r​edsheep> Is llvm involved when using nvk at all?
04:49 fdobridge: <r​edsheep> https://cdn.discordapp.com/attachments/1034184951790305330/1212985004963926016/confusion.txt?ex=65f3d351&is=65e15e51&hm=5e9368b5a2e09484dd610a5674aeb75fb0d10b43c2bc273dc75d8b6f4feb4585&
04:50 fdobridge: <r​edsheep> If it isn't that llvm thing I fail to see how it's possible that specifying no icd vs specifying one built on the same commit could make a difference
04:57 fdobridge: <r​edsheep> I really wanted to work on calibrated timestamps tonight, instead I wasted all of my time trying to confirm I wasn't spouting nonsense numbers, and I was 😦
05:03 fdobridge: <g​fxstrand> The best way to make sure you're getting the driver you think you're getting is to set `VK_ICD_FILENAMES` directly. With that, the Vulkan loader will load the driver you specify and only the driver you specify.
05:04 fdobridge: <r​edsheep> Yeah I was under the mistaken impression that just matching commit was enough, I guess.
05:08 fdobridge: <r​edsheep> This might still be worth investigating further, if there's something in my environment that gets loaded when the ICD is not specified that can swing performance by nearly double in some cases then that's worth knowing about in detail.
05:26 fdobridge: <g​fxstrand> So, the LLVM thing is because in the 3rd one, you're getting both NVK and lavapipe. Apps should still be preferring NVK, though.
05:27 fdobridge: <r​edsheep> Ah, I see. Well there's probably no way lavapipe is fast enough to be competitive here, but I don't know if I know anything for sure anymore, maybe that is the issue.
05:32 fdobridge: <g​fxstrand> :blobcatnotlikethis:
05:37 fdobridge: <a​irlied> lavapipe dreams of one day being mistaken for a real life driver 😛
05:39 fdobridge: <g​fxstrand> https://tenor.com/view/im-in-your-dreams-gif-19262251
05:40 fdobridge: <r​edsheep> I wonder if there's any way I could be 100% certain that when I test running my session on zink that it's not just llvmpipe or lavapipe+zink
05:40 fdobridge: <r​edsheep> It would certainly explain it being so slow, even after damage got wired up
05:44 fdobridge: <g​fxstrand> Yeah, so the earlier version of that patch just completed an 18-thread CTS run with no flakes.
05:44 fdobridge: <g​fxstrand> You have no idea how happy this makes me.
05:45 fdobridge: <g​fxstrand> The IRQ thing does still seem to strike sometimes, though.
05:45 fdobridge: <g​fxstrand> Or maybe it's something else. IDK. All I know is that sometimes the GPU just goes out for a long lunch and never bothers to come back to the office.
05:52 fdobridge: <a​irlied> yeah I think that is the same as BAR eviction problem I can reproduce, all contexts get timed out and stuff never works again
05:53 fdobridge: <g​fxstrand> Still, With that locking patch I'm seeing more stability than I think I've ever seen. 💜 Good work!
05:54 fdobridge: <g​fxstrand> Still, With that locking patch I'm seeing more stability than I think I've ever seen so good work! (edited)
05:54 fdobridge: <r​edsheep> It seems VK_EXT_calibrated_timestamps was promoted to VK_KHR_calibrated_timestamps, so VK_KHR_calibrated_timestamps is what I actually need to implement to resolve issue 9625, right?
05:54 fdobridge: <g​fxstrand> Implement the KHR version of the entrypoing and then turn on both extensions
05:55 fdobridge: <g​fxstrand> The dispatch code will handle the entrypoint aliasing for you
06:57 fdobridge: <t​om3026> something on ada is wonky compared to ampere in kernel also btw, "nouveau 0000:01:00.0: gsp: cli:0xc1d00002 obj:0x00730000 ctrl cmd:0x00731341 failed: 0x0000ffff" 5-6 lines of those everytime im launching something on the dgpu. and once at boot and a few seconds/minutes after. same when closing said application, almost like its when its about to suspend/enter D3
06:57 fdobridge: <t​om3026> never saw those on the 3060 card
06:58 fdobridge: <r​edsheep> Any notable kernel parameters set? What kernel are you testing? I have seen similar errors but only pretty rarely with my ada card
06:59 fdobridge: <t​om3026> "initrd=\intel-ucode.img initrd=\initramfs-linux.img root=UUID="21d5e523-e1e7-46c3-924a-aa26bca1a2b2" rw mitigations=off audit=0 nowatchdog initcall_blacklist=simpledrm_platform_driver_init msr.allow_writes=on ibt=off srso=off split_lock_detect=off add_efi_memmap acpi_osi=linux tsx=on tsx_async_abort=off tsc=reliable nmi_watchdog=0 zswap.max_pool_percent=20 zswap.enabled=1 zswap.compressor=lz4 zswap.zpool=zsmalloc i915.mitigations=off i915.fa
07:00 fdobridge: <t​om3026> yes yes i know mitigations=off covers half of those, but it was a testing one by one incident and it all sticked. xD
07:00 fdobridge: <r​edsheep> pcie_aspm is the only one I see that seems like it could be relevant
07:00 fdobridge: <r​edsheep> I don't think I have that
07:01 fdobridge: <r​edsheep> Particularly since that has to do with power management that seems like a good place to start
07:29 fdobridge: <a​irlied> Those are just display port probes failing
07:29 fdobridge: <a​irlied> I should drop that debug
07:32 fdobridge: <t​om3026> makes sense since this has displayport and the other one didnt heh
07:33 fdobridge: <t​om3026> or well usb-c > adapter -> dp :p
08:56 fdobridge: <S​id> what does add_efi_memmap do?
08:59 fdobridge: <!​DodoNVK (she) 🇱🇹> I hope this isn't some ProtonDB-level option
08:59 fdobridge: <t​om3026> dont remember, old habits. something something about rebuilding some memory map and was required in old days when boot was borked on early efi systems
09:00 fdobridge: <t​om3026> "If the EFI memory map has additional entries not in the E820 map,
09:00 fdobridge: <t​om3026> you can include those entries in the kernels memory map of available
09:00 fdobridge: <t​om3026> physical RAM by using the following kernel command line parameter."
09:00 fdobridge: <t​om3026> now what that means no idea, im old. 😄
09:00 fdobridge: <S​id> I see
09:00 fdobridge: <S​id> asking because rebar broke on my setup recently lmfao
09:01 fdobridge: <S​id> gives me a `no space for [memory region`
09:01 fdobridge: <t​om3026> "add_efi_memmap include EFI memory map of available physical RAM"
09:01 fdobridge: <S​id> but works fine in a windows env
09:02 fdobridge: <t​om3026> does the efi perhaps contain some region of how much physical ram there is, linux does black magics and figure out that on its own. add efi memmap just makes the efi region matter too?
09:02 fdobridge: <t​om3026> no idea
09:02 fdobridge: <t​om3026> and old efi had protected sections that overlapped and all hell brooke loose? oh well its like 10 years ago heh
09:03 fdobridge: <S​id> fair, was just curious :>
09:05 fdobridge: <t​om3026> https://linux.kernel.narkive.com/wC0oPNmT/patch-2-2-x86-boot-only-pick-up-additional-efi-memmap-if-add-efi-memmap-flag 16y ago
09:05 fdobridge: <t​om3026> xD
09:06 fdobridge: <S​id> was just curious if it touches pci space at all, because afaik linux remaps pci regions on boot
09:10 fdobridge: <t​om3026> https://blog.fpmurphy.com/2012/08/uefi-memory-v-e820-memory.html seems to explain more but i havent fully grasped the idea yet. but yeah this was around the time when i fiddled with the thinkpad x230, corebooting and using tianocore for efi
09:10 fdobridge: <t​om3026> probably isnt needed unless dmesg shows some errors
09:11 fdobridge: <S​id> I feel like something in the pci driver changed
09:12 fdobridge: <S​id> which broke rebar for me
09:12 fdobridge: <S​id> but I'm in no mood to go bisect that...
09:17 fdobridge: <t​om3026> 6.7.6 with your patch applied :p
09:18 fdobridge: <S​id> nice!
09:18 fdobridge: <t​om3026> no i meant you should just go there see if rebar is actually an driver change bork or not
09:18 fdobridge: <S​id> my patch is in the mailing list (thanks dave!) and should land in 6.8-rc7
09:18 fdobridge: <S​id> oh
09:18 fdobridge: <t​om3026> but yeah i got it applied too heh
09:18 fdobridge: <S​id> I'm on 6.7.6 with my patch applied too, yes
09:18 fdobridge: <S​id> but
09:18 fdobridge: <S​id> that's a good idea, hm
09:19 fdobridge: <S​id> except I don't know when it broke, and afaik nouveau does not handle allocating bar region
09:19 fdobridge: <S​id> I think
09:19 fdobridge: <t​om3026> oh
09:20 fdobridge: <S​id> or the log line would be `nouveau` instead of `pci`
09:21 fdobridge: <S​id> `[ 0.604440] pci 0000:01:00.0: BAR 1 [mem size 0x200000000 64bit pref]: can't assign; no space`
09:21 fdobridge: <t​om3026> add_efi_memmap
09:21 fdobridge: <t​om3026> xD
09:22 fdobridge: <S​id> which is why I asked :D
09:23 fdobridge: <t​om3026> its the magic command from before the financial crisis of 2008 that solves all memory mappings, unless it doesnt.
09:30 fdobridge: <S​id> heh
09:32 fdobridge: <t​om3026> otherwise since your rebar is a hack, there is also pci=realloc , "reallocating PCI bridge resources if allocations done by BIOS are too small to accommodate resources required by all child devices"
09:32 fdobridge: <S​id> already using realloc, yeah
09:32 fdobridge: <t​om3026> ah okay
09:33 fdobridge: <S​id> not using realloc makes the GPU fail to initialize
09:33 fdobridge: <S​id> :>
09:33 fdobridge: <S​id> I'm just confused, because rebar reports correctly in Hiren's BootCD still
09:35 fdobridge: <t​om3026> 0x200000000 , is 8192mb so the question is why it thinks there is no space
09:35 fdobridge: <S​id> exactly my confusion
09:42 fdobridge: <t​om3026> https://github.com/torvalds/linux/blob/master/drivers/pci/setup-res.c#L355
09:43 fdobridge: <S​id> sadly
09:43 fdobridge: <S​id> `[ 0.604446] pci 0000:01:00.0: BAR 3 [mem size 0x02000000 64bit pref]: can't assign; no space
09:43 fdobridge: <S​id> [ 0.604448] pci 0000:01:00.0: BAR 3 [mem 0xfffffffffe000000-0xffffffffffffffff 64bit pref]: failed to assign`
09:44 fdobridge: <S​id> oh wait, wrong bar
09:44 fdobridge: <S​id> `[ 0.604440] pci 0000:01:00.0: BAR 1 [mem size 0x200000000 64bit pref]: can't assign; no space
09:44 fdobridge: <S​id> [ 0.604443] pci 0000:01:00.0: BAR 1 [mem 0xfffffffe00000000-0xffffffffffffffff 64bit pref]: failed to assign`
09:44 fdobridge: <S​id> for some reason it's also trying to allocate in a region outside my bus resource
09:45 fdobridge: <S​id> ```
09:45 fdobridge: <S​id> [ 0.214711] pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7 window]
09:45 fdobridge: <S​id> [ 0.214712] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff window]
09:45 fdobridge: <S​id> [ 0.214713] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window]
09:45 fdobridge: <S​id> [ 0.214714] pci_bus 0000:00: root bus resource [mem 0x8f800000-0xdfffffff window]
09:45 fdobridge: <S​id> [ 0.214715] pci_bus 0000:00: root bus resource [mem 0x66e800000-0x7fffffffff window]
09:45 fdobridge: <S​id> [ 0.214716] pci_bus 0000:00: root bus resource [mem 0xfc800000-0xfe7fffff window]
09:45 fdobridge: <S​id> [ 0.214717] pci_bus 0000:00: root bus resource [bus 00-fe]
09:45 fdobridge: <S​id> ```
09:45 fdobridge: <S​id> which didn't happen before!
09:46 fdobridge: <S​id> ...hm
09:46 fdobridge: <k​arolherbst🐧🦀> doesn't it retry a few times until it works?
09:46 fdobridge: <S​id> the mem regions only sum up to ~7.75 gigs
09:47 fdobridge: <S​id> no, it retries a few times then falls back to using the default bar size of 256mb
09:47 fdobridge: <k​arolherbst🐧🦀> ahh.. that's not great, but smells like an upstream PCI issue then
09:47 fdobridge: <k​arolherbst🐧🦀> or firmware being firmware
09:47 fdobridge: <k​arolherbst🐧🦀> though it works on windows, right?
09:47 fdobridge: <k​arolherbst🐧🦀> or the prop driver?
09:47 fdobridge: <S​id> works on windows
09:47 fdobridge: <k​arolherbst🐧🦀> I wonder if that's the difference actually
09:47 fdobridge: <S​id> not at all on linux
09:47 fdobridge: <k​arolherbst🐧🦀> like...
09:47 fdobridge: <S​id> not on prop, not nouveau
09:47 fdobridge: <k​arolherbst🐧🦀> the nvidia driver trying to reassign those bars
09:48 fdobridge: <k​arolherbst🐧🦀> huh...
09:48 fdobridge: <k​arolherbst🐧🦀> uhh
09:48 fdobridge: <k​arolherbst🐧🦀> I meant the open nvidia one though 😄
09:48 fdobridge: <S​id> on jan 23 it looked like this
09:48 fdobridge: <S​id> ```
09:48 fdobridge: <S​id> [ 0.499242] pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7 window]
09:48 fdobridge: <S​id> [ 0.499246] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff window]
09:48 fdobridge: <S​id> [ 0.499249] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window]
09:48 fdobridge: <S​id> [ 0.499251] pci_bus 0000:00: root bus resource [mem 0x8d800000-0xdfffffff window]
09:48 fdobridge: <S​id> [ 0.499253] pci_bus 0000:00: root bus resource [mem 0xfc800000-0xfe7fffff window]
09:48 fdobridge: <S​id> [ 0.499255] pci_bus 0000:00: root bus resource [bus 00-fe]
09:48 fdobridge: <S​id> ```
09:48 fdobridge: <S​id> which
09:48 fdobridge: <S​id> is still 1.38 gigs
09:48 fdobridge: <S​id> but
09:48 fdobridge: <k​arolherbst🐧🦀> I wonder if there is some randomness in play here
09:48 fdobridge: <S​id> the fact that it keeps changing pisses me off
09:49 fdobridge: <k​arolherbst🐧🦀> yeah.. sounds like something you ~~want to~~ should report upstream
09:50 fdobridge: <S​id> not karol trying to nerdsnipe me
09:50 fdobridge: <t​om3026> dmesg doesnt contain any "resource collision: [mem 0xSOMEADRESS-0xSOMEADRESS] conflicts" ?
09:51 fdobridge: <S​id> https://cdn.discordapp.com/attachments/1034184951790305330/1213060955898904626/dmesg.log?ex=65f41a0d&is=65e1a50d&hm=19fc8fa555efba39fb6a87536a6c6d146c092adb487ef03bbfb5e06c2addd481&
09:51 fdobridge: <S​id> not that I can find
09:55 fdobridge: <S​id> ~~also karol I don't think simply reporting will satisfy me anymore~~
09:59 fdobridge: <t​om3026> you are fast approaching kernel maintainer status 😄
09:59 fdobridge: <S​id> https://tenor.com/view/cat-funny-scared-screaming-cat-cute-gif-25233437
10:05 fdobridge: <h​untercz122> since when Sid is a kernel dev
10:06 fdobridge: <S​id> ~~since the recent nouveau suspend/resume regression~~
10:07 fdobridge: <S​id> tbh I was only gonna bisect and report with the problematic commit
10:07 fdobridge: <S​id> but the commit was small and easy to understand...
10:08 fdobridge: <S​id> @tom3026 for good measure I'm gonna reflash my modded bios
10:08 fdobridge: <S​id> in hopes it reverts everything to absolute default settings
10:08 fdobridge: <S​id> and slowly work from there
10:09 fdobridge: <S​id> first will try to get gpu-z to show correct bar size in HBCD
10:09 fdobridge: <S​id> then work on the linux side of things
10:33 fdobridge: <k​arolherbst🐧🦀> potential developers are also baited by fixing bugs they it themselves 😛
10:33 fdobridge: <k​arolherbst🐧🦀> *always
10:35 fdobridge: <k​arolherbst🐧🦀> ~~now that nouveau isn't experimental anymore, I should also start looking into using crates, like.. serde~~
10:42 fdobridge: <S​id> for sanity
10:42 fdobridge: <S​id> https://cdn.discordapp.com/attachments/1034184951790305330/1213073941791510539/dd479dd1-f0cc-4635-9039-4b9fe504f764.jpg?ex=65f42625&is=65e1b125&hm=25b5c65bab90fbb7e1aea25e7e9baddea6b07df2476d22a1de36d80b5863acac&
10:43 fdobridge: <S​id> that's in HBCD
10:43 fdobridge: <S​id> and now on linux
10:43 fdobridge: <S​id> ```
10:43 fdobridge: <S​id> 01:00.0 VGA compatible controller: NVIDIA Corporation TU116M [GeForce GTX 1660 Ti Mobile] (rev a1) (prog-if 00 [VGA controller])
10:43 fdobridge: <S​id> Subsystem: Acer Incorporated [ALI] TU116M [GeForce GTX 1660 Ti Mobile]
10:43 fdobridge: <S​id> ...
10:43 fdobridge: <S​id> Region 0: Memory at 40000000 (32-bit, non-prefetchable) [size=16M]
10:43 fdobridge: <S​id> Region 1: Memory at 4110000000 (64-bit, prefetchable) [size=256M]
10:43 fdobridge: <S​id> Region 3: Memory at 4100000000 (64-bit, prefetchable) [size=32M]
10:43 fdobridge: <S​id> ```
10:43 fdobridge: <S​id> ffs
10:44 fdobridge: <S​id> what was the kernel version on jan 24th 🐸
10:44 fdobridge: <S​id> 6.8 rc1
10:45 fdobridge: <S​id> :\
10:46 fdobridge: <S​id> why are the regions different 💢
10:47 fdobridge: <S​id> oh I was on 6.7.0
10:47 fdobridge: <S​id> great
11:15 fdobridge: <t​om3026> are you sure this ever worked on the blob?
11:16 fdobridge: <S​id> yes
11:18 fdobridge: <S​id> https://cdn.discordapp.com/attachments/1034184951790305330/1213082968084451339/rebar.png?ex=65f42e8d&is=65e1b98d&hm=14194b9dcf8c85214e20272b8a20c5026f7d392cd2f54b1a1f6a15cab007ee1f&
11:19 fdobridge: <S​id> 25th jan
11:19 fdobridge: <S​id> now I'm back on 6.7.0 (and still on 550.40.7) and it's still borken
11:19 fdobridge: <S​id> meaning it's something with my BIOS settings, maybe
11:19 fdobridge: <S​id> unless
11:20 fdobridge: <S​id> my root partition switching from ext4 to xfs and dropping the swapfile makes a difference
11:21 fdobridge: <r​hed0x> Alan Wake 2 works on NVK?
11:21 fdobridge: <r​hed0x> Or is that just a wallpaper?
11:21 fdobridge: <S​id> that's proprietary
11:21 fdobridge: <r​hed0x> oh
11:21 fdobridge: <S​id> sorry 😅
11:21 fdobridge: <S​id> not a wallpaper, no. game in windowed mode so I can have the terminal over it to monitor BAR usage
11:22 fdobridge: <t​om3026> from my little googling and understanding,
11:22 fdobridge: <t​om3026> ```
11:22 fdobridge: <t​om3026> [ 0.425255] pci_bus 0000:00: root bus resource [io 0-332 window]
11:22 fdobridge: <t​om3026> [ 0.425259] pci_bus 0000:00: root bus resource [io 332-65535 window]
11:22 fdobridge: <t​om3026> [ 0.425261] pci_bus 0000:00: root bus resource [mem 10-11 window]
11:23 fdobridge: <t​om3026> [ 0.425263] pci_bus 0000:00: root bus resource [mem 4096-4294967295 window]
11:23 fdobridge: <t​om3026> [ 0.425265] pci_bus 0000:00: root bus resource [mem 4096000000-549755813887 window]
11:23 fdobridge: <t​om3026> [ 0.425267] pci_bus 0000:00: root bus resource [mem 4244635648-4278190079 window]
11:23 fdobridge: <t​om3026> [ 0.425269] pci_bus 0000:00: root bus resource [bus 00-254]
11:23 fdobridge: <t​om3026>
11:23 fdobridge: <t​om3026> [ 0.603588] pci 0000:00:01.0: bridge window [mem 41943040-4278190079]: assigned
11:23 fdobridge: <t​om3026> [ 0.603595] pci 0000:00:15.0: BAR 0 [mem 42949672960-42949674007 64bit]: assigned
11:23 fdobridge: <t​om3026> [ 0.603867] pci 0000:00:15.1: BAR 0 [mem 42949674008-42949675055 64bit]: assigned
11:23 fdobridge: <t​om3026> [ 0.604140] pci 0000:00:1e.0: BAR 0 [mem 42949675056-42949676047 64bit]: assigned
11:23 fdobridge: <t​om3026> [ 0.604440] pci 0000:01:00.0: BAR 1 [mem size 214748364800 64bit pref]: can't assign; no space
11:23 fdobridge: <t​om3026> [ 0.604443] pci 0000:01:00.0: BAR 1 [mem 4294967295999990000-4294967295999999999 64bit pref]: failed to assign
11:23 fdobridge: <t​om3026> [ 0.604446] pci 0000:01:00.0: BAR 3 [mem size 33554432 64bit pref]: can't assign; no space
11:23 fdobridge: <t​om3026> [ 0.604448] pci 0000:01:00.0: BAR 3 [mem 4294967295990000000-4294967295999999999 64bit pref]: failed to assign
11:23 fdobridge: <t​om3026> [ 0.604451] pci 0000:01:00.0: BAR 0 [mem 41943040-42024959]: assigned
11:23 fdobridge: <t​om3026> [ 0.604457] pci 0000:01:00.0: ROM [mem 42024960-42268671 pref]: assigned
11:23 fdobridge: <t​om3026> [ 0.604459] pci 0000:01:00.1: BAR 0 [mem 42268672-42270719]: assigned
11:23 fdobridge: <t​om3026> [ 0.604465] pci 0000:01:00.3: BAR 0 [mem 42270720-42272767]: assigned
11:23 fdobridge: <t​om3026> ```
11:23 fdobridge: <t​om3026> converted hex to decimals :p, but yeah that BAR is going out of your root bus resource window, which is fetched from ACPI
11:24 fdobridge: <S​id> yeah, I did get that myself too 😅
11:24 fdobridge: <S​id> but now that I've gone back to the kernel/driver config that worked previously
11:24 fdobridge: <S​id> and it still doesn't work
11:24 fdobridge: <S​id> I can go poke around UEFI settings
11:25 fdobridge: <t​om3026> yeah acpi is more of bios/uefi problem
11:25 fdobridge: <t​om3026> or linux is just stricter with these things compared to windows
11:25 fdobridge: <S​id> linux is actually more lax
11:25 fdobridge: <t​om3026> oh derp its going out of acpi allowed window DENIED
11:25 fdobridge: <S​id> since we do ReBAR in kernel space
11:25 fdobridge: <S​id> instead of blindly following UEFI
11:26 fdobridge: <t​om3026> question is why it worked at all before tho
11:26 fdobridge: <t​om3026> heh
11:26 fdobridge: <S​id> heck, you can even boot with a modified DSDT without having to patch it into the driver
11:26 fdobridge: <S​id> s\/driver/firmware
11:29 fdobridge: <S​id> wtf
11:29 fdobridge: <S​id> just comparing output from lspci is also so different
11:30 fdobridge: <t​om3026> or did your bios restore itself in some failsafe manner lol
11:31 fdobridge: <t​om3026> or "restore default settings" overwrote those https://github.com/xCuri0/ReBarUEFI things this does
11:31 fdobridge: <S​id> I did do a manual reset
11:32 fdobridge: <t​om3026> ah okay
11:32 fdobridge: <S​id> I'm using a different thing, but yeah, did set the vars again
11:32 fdobridge: <S​id> https://github.com/terminatorul/nvstrapsrebar
11:32 fdobridge: <S​id> bios hasn't changed, only bios config
11:32 fdobridge: <S​id> and changing pci settings is scary D:
11:33 fdobridge: <S​id> memory regions are different, and
11:33 fdobridge: <S​id> interrupt pin A is being routed to a different IRQ
11:33 fdobridge: <S​id> what
11:34 fdobridge: <S​id> look
11:34 fdobridge: <S​id> https://www.diffchecker.com/GIgAClVE/
11:34 fdobridge: <S​id> left is old, right is new
11:35 fdobridge: <S​id> bios hours
11:36 fdobridge: <t​om3026> yeah i would say something with that nvstrapsrebar didnt apply correctly or configured right
11:36 fdobridge: <S​id> it's config'ed the same
11:37 fdobridge: <t​om3026> you should order a ada laptop
11:37 fdobridge: <t​om3026> 😄
11:37 fdobridge: <S​id> see that's a good solution
11:37 fdobridge: <S​id> but I do not have the money
11:38 fdobridge: <S​id> and if I had the money I'd get a desktop anyway
11:39 fdobridge: <!​DodoNVK (she) 🇱🇹> https://gitlab.freedesktop.org/mesa/mesa/-/issues/10719 🤔
11:40 fdobridge: <t​om3026> "Most people should choose the first menu option and press E to Enable auto-settings BAR size for Turing GPUs. " sounds interesting. so which way did you choose auto setting or manually setting a bar size?
11:40 fdobridge: <t​om3026> is it auto setting it on each reboot and fails 9 out of 10 times
11:40 fdobridge: <S​id> the recommended way, yeah
11:41 fdobridge: <S​id> I could change to manual
11:45 fdobridge: <t​om3026> dont hold me accountable for bricking it tho :blobcatnotlikethis:
11:45 fdobridge: <S​id> nah
11:45 fdobridge: <S​id> iGPU drives display
11:45 fdobridge: <S​id> I can always revert
11:55 fdobridge: <S​id> blegh
11:55 fdobridge: <t​om3026> didnt help? 😦
11:58 fdobridge: <S​id> nope
12:00 fdobridge: <t​om3026> i kinda cheated too btw https://i.imgur.com/uOjMG8v.png
12:00 fdobridge: <t​om3026> 😄
12:01 fdobridge: <t​om3026> did the resource regions change? tho
12:02 fdobridge: <p​ixelcluster> anyone want to take bets on how terribly wrong the output is
12:03 fdobridge: <t​om3026> 😄
12:03 fdobridge: <S​id> ....oh
12:03 fdobridge: <S​id> fuck me
12:04 fdobridge: <S​id> I'm so dumb
12:04 fdobridge: <S​id> https://cdn.discordapp.com/attachments/1034184951790305330/1213094588940681326/Screenshot_20240301-173437.png?ex=65f43960&is=65e1c460&hm=20a4760bc0dbc6fbef193894b59979364de43e6d217193155178e63131e476fb&
12:05 fdobridge: <S​id> guess what was happening...
12:06 fdobridge: <t​om3026> history is repeating itself
12:06 fdobridge: <S​id> yes
12:06 fdobridge: <S​id> I re-added the pci-pm config to minimize power draw a week or two ago
12:06 fdobridge: <S​id> among a lot more pci-pm tweaks
12:06 fdobridge: <S​id> among a lot more power related tweaks (edited)
12:07 fdobridge: <S​id> and completely forgot about rebar breaking if I set pci-pm rules via udev...
12:07 fdobridge: <S​id> I need to figure out a way to set those rules post-boot
12:08 fdobridge: <S​id> my experiments with power management were very successful
12:09 fdobridge: <S​id> I managed to take my laptop's idle drain down from I think ~13W to ~6W
12:09 fdobridge: <S​id> even dipping as low as 5.3W at some points
12:09 fdobridge: <t​om3026> yeah i went from 20w according to powertop to like 10-12 doing so aswell
12:09 fdobridge: <S​id> nono you don't get the sheer nonsense I pulled off
12:10 fdobridge: <S​id> GPU before: `LnkCtl: ASPM Disabled; RCB 64 bytes, LnkDisable- CommClk+`
12:10 fdobridge: <S​id> GPU after:
12:10 fdobridge: <S​id> ```
12:10 fdobridge: <S​id> LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes, LnkDisable- CommClk+
12:11 fdobridge: <S​id> ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-```
12:11 fdobridge: <S​id> *with working L1 substates*
12:11 fdobridge: <S​id> ```
12:11 fdobridge: <S​id> Capabilities: [258 v1] L1 PM Substates
12:11 fdobridge: <S​id> L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ L1_PM_Substates+
12:11 fdobridge: <S​id> PortCommonModeRestoreTime=255us PortTPowerOnTime=10us
12:11 fdobridge: <S​id> L1SubCtl1: PCI-PM_L1.2- PCI-PM_L1.1- ASPM_L1.2- ASPM_L1.1-
12:11 fdobridge: <S​id> T_CommonMode=0us LTR1.2_Threshold=0ns
12:11 fdobridge: <S​id> L1SubCtl2: T_PwrOn=10us
12:11 fdobridge: <S​id> ```
12:12 fdobridge: <S​id> I also force enabled ASPM right on the pci bridge
12:12 fdobridge: <S​id> and force enabled package c-states on the CPU
12:13 fdobridge: <S​id> because apparently Acer is *terrible* at configuring their laptops' UEFI firmware
12:13 fdobridge: <S​id> this is a *gaming laptop* that idles at ~5.5W
12:13 fdobridge: <S​id> :D
12:14 fdobridge: <S​id> ~~I'm basically treating this laptop like a desktop~~
12:15 fdobridge: <t​om3026> heh okay
12:15 fdobridge: <t​om3026> anyways udev rules can use GOTO
12:16 fdobridge: <t​om3026> ```
12:16 fdobridge: <t​om3026>
12:16 fdobridge: <t​om3026> ACTION=="add", SUBSYSTEM=="pci", ATTR{vendor}=="0x10de", GOTO="rule_end"
12:16 fdobridge: <t​om3026> ACTION=="bind", SUBSYSTEM=="pci", ATTR{vendor}=="0x10de", GOTO="rule_end"
12:16 fdobridge: <t​om3026> ACTION=="unbind", SUBSYSTEM=="pci", ATTR{vendor}=="0x10de", GOTO="rule_end"
12:16 fdobridge: <t​om3026>
12:16 fdobridge: <t​om3026> # Enable runtime PM for all pci devices
12:16 fdobridge: <t​om3026> SUBSYSTEM=="pci", ATTR{power/control}="auto"
12:16 fdobridge: <t​om3026>
12:16 fdobridge: <t​om3026> LABEL="rule_end"
12:16 fdobridge: <t​om3026> ```
12:16 fdobridge: <S​id> I don't wanna do that though, I wanna enable pci pm for every pci device
12:16 fdobridge: <S​id> just need a way to do it post boot 🐸
12:16 fdobridge: <t​om3026> and just manually set the things later in either a systemd service or just a bash script when booted in the /sys/blabla/power/control
12:17 fdobridge: <S​id> ...yeah
12:17 fdobridge: <S​id> but yes, like I said yesterday
12:17 fdobridge: <S​id> I'm a cursed child
12:17 fdobridge: <S​id> I do cursed things
12:18 fdobridge: <S​id> the only reason I'm not soldering in a newer CPU/GPU on this laptop is because I can't afford to perma-brick it
12:19 fdobridge: <t​om3026> you could do an egpu setup tho :p
12:19 fdobridge: <S​id> where's the fun in that :D
12:19 fdobridge: <t​om3026> i did that on my thinkpad x230
12:19 fdobridge: <S​id> and my laptop doesn't have a thunderbolt port
12:20 fdobridge: <t​om3026> well got a spare m.2 slot?
12:20 fdobridge: <S​id> both my m.2 slots are utilized, and attaching an eGPU to an m.2 will just turn it into a desktop
12:20 fdobridge: <t​om3026> yeah
12:21 fdobridge: <S​id> because then I'll have to leave the bottom plate open
12:24 fdobridge: <S​id> anyway, nice to see nouveau pick up rebar automatically on boot now
12:24 fdobridge: <S​id> back in january it only did that if the module was loaded after pci was done allocating the memory
12:24 fdobridge: <S​id> i.e if the module was loaded post boot
12:26 fdobridge: <t​om3026> oh well that was fun, what do we debug now?
12:26 fdobridge: <t​om3026> 😄
12:27 fdobridge: <S​id> *sweat*
12:27 fdobridge: <S​id> you're terrifying
12:38 fdobridge: <S​id> GPL seems to be crashing a lot of games, hm
12:39 fdobridge: <z​mike.> fwiw nv blob has historically had the most fails with glcts tessellation tests
12:40 fdobridge: <z​mike.> they've fixed most of them over the years by now, but it used to be quite a lot
12:40 fdobridge: <t​om3026> got a link to that suspen/resume finalized patch?
12:41 fdobridge: <t​om3026> fixing up this pkgbuild
12:41 fdobridge: <S​id> just a sec
12:41 fdobridge: <S​id> https://gitlab.freedesktop.org/drm/kernel/-/commit/f6ecfdad359a01c7fd8a3bcfde3ef0acdf107e6e
12:42 fdobridge: <t​om3026> thanks
12:43 fdobridge: <S​id> should be in rc7 :>
12:44 fdobridge: <S​id> wow we're hitting real regressions now
12:45 fdobridge: <S​id> even without GPL dirt rally crashes
12:47 fdobridge: <S​id> blasphemous, how did this get acked! /j
12:47 fdobridge: <S​id> https://cdn.discordapp.com/attachments/1034184951790305330/1213105255198232596/image.png?ex=65f4434f&is=65e1ce4f&hm=581d0fc8a9d00c55b08a49b74fe1b99c08191df99320d9f11b85d1fc659d0c3a&
12:57 fdobridge: <m​arysaka> gotta getch 'em all
13:12 fdobridge: <t​om3026> https://patchwork.freedesktop.org/patch/580696/ gfxstrand seemed to get less issues in the CTS with this, no idea if its in any of the -RC yet but im building it now
13:15 fdobridge: <S​id> not in the rc yet no
13:15 fdobridge: <S​id> let me know how it goes for you
13:16 fdobridge: <S​id> am gonna go read a book for a while
13:20 fdobridge: <S​id> because freedesktop.org hates me and won't let me fetch commits any quicker than 25KiB/s
13:22 fdobridge: <t​om3026> @airlied is it actually this https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c#L662 you meant is just a displayport "debug" message? because thats what im hitting, not the nvkm_debug(&gsp->subdev, "cli:0x%08x obj:0x%08x ctrl cmd:0x%08x argc:%d\n", client->object.handle, object->handle, cmd, argc); 20 lines below
14:12 fdobridge: <t​om3026> seems i can convert mom to nvk, sims4 runs rather well
14:12 fdobridge: <t​om3026> 😄
14:16 fdobridge: <S​id> @gfxstrand with calibrated timestamps, how do we wanna handle the upgrade it got from EXT to KHR
14:16 fdobridge: <S​id> am trying to implement it rn :>
14:19 fdobridge: <r​edsheep> ^
14:19 fdobridge: <m​ohamexiety> you enable both in the physical_device.c tables and implement the `KHR` version of the functions. the vulkan runtime handles the `EXT` <-> `KHR` thing when an app calls either of them
14:19 fdobridge: <S​id> I see, thank
14:25 fdobridge: <S​id> hmmmm I shouldn't have rm -rf'd the cts suite
14:44 fdobridge: <t​om3026> yeah runtime pm doesnt seem to work on nouveau
14:44 fdobridge: <t​om3026> 56w usage idling
14:44 fdobridge: <t​om3026> 😄
14:45 fdobridge: <!​DodoNVK (she) 🇱🇹> I got D3cold on nouveau
14:47 fdobridge: <t​om3026> how did you check that
15:04 fdobridge: <!​DodoNVK (she) 🇱🇹> By opening some sysfs nodes of course
15:11 fdobridge: <S​id> works on my machine
15:28 fdobridge: <g​fxstrand> @tiredchiku , this ☝🏻
15:57 fdobridge: <S​id> hm, this seems to require more understanding of the hardware than I have atm
15:57 fdobridge: <S​id> I'll tackle it tomorrow
16:01 fdobridge: <m​arysaka> How does people run Steam games with NVK atm? :aki_thonk:
16:02 fdobridge: <r​edsheep> Setting the icd in launch options before %command%
16:03 fdobridge: <S​id> which is an optional step if there's only one gpu on your system and is being driven by nouveau
16:03 fdobridge: <p​rop_energy_ball> hit play 🐸
16:03 fdobridge: <p​rop_energy_ball> I have nvk installed at system level
16:03 fdobridge: <p​rop_energy_ball> but you can `VK_ICD_FILENAMES=blah %command%`
16:04 fdobridge: <p​rop_energy_ball> I WILL **NEVER** USE VK_DRIVER_FILES
16:04 fdobridge: <S​id> king
16:04 fdobridge: <S​id> ...god damn it fdev
16:05 fdobridge: <S​id> steam copy
16:05 fdobridge: <S​id> https://cdn.discordapp.com/attachments/1034184951790305330/1213155050344550450/image.png?ex=65f471af&is=65e1fcaf&hm=7f6cdc5bd7200bbdb5fb7038879c0f84bf325e5340238e8e57192e1e1ce18e8c&
16:05 fdobridge: <S​id> launched from steam
16:05 fdobridge: <m​arysaka> Okay so nothing too fancy to do :SoniiPray:
16:05 fdobridge: <S​id> yup
16:06 fdobridge: <m​arysaka> (I'm not installing at the system level yet, and if I was I think I would make some package on copr)
16:06 fdobridge: <S​id> gee I wonder how I played for so long without the fdev account not owning the damn game, ***FDev***
16:06 fdobridge: <S​id> https://cdn.discordapp.com/attachments/1034184951790305330/1213155445045198899/image.png?ex=65f4720d&is=65e1fd0d&hm=42b93d71243dcb005b86e093b71b05ad0bb6ea0a68216bac88a3c939016b225f&
16:06 fdobridge: <S​id> s\/not owning/owning
16:14 fdobridge: <e​sdrastarsis> Why?
16:14 fdobridge: <S​id> https://tenor.com/view/abe-simpson-abe-simpson-cloud-yelling-cloud-angry-gif-12558964
16:14 fdobridge: <S​id> that's why
16:24 fdobridge: <w​aelunix> Day 2 of trying to get NVK working on my machine. Hopefully i don't face anymore NixOS-isms 🐸
16:27 fdobridge: <t​om3026> @gfxstrand for what its worth, sims 4 max settings ran beautiful on this 4080
16:28 fdobridge: <t​om3026> we should make a nvkdb as protondb
16:28 fdobridge: <t​om3026> what currently runs or not 😄
16:28 fdobridge: <S​id> it exists
16:28 fdobridge: <S​id> it's called #g
16:28 fdobridge: <S​id> uh
16:28 fdobridge: <S​id> #gayming Ctrl + f has: image
16:29 fdobridge: <S​id> :D
16:29 fdobridge: <t​om3026> 😄
16:29 fdobridge: <S​id> me: ok I've had a long day figuring stuff out with my laptop, time to relax and play a game for a bit
16:29 fdobridge: <S​id> also me:
16:30 fdobridge: <S​id> https://cdn.discordapp.com/attachments/1034184951790305330/1213161413820944504/image.png?ex=65f4779c&is=65e2029c&hm=195eb600351b4e859367f2c42bebdcdb61ba2100e8330e102a8df5a47593213f&
16:31 fdobridge: <g​fxstrand> What even is `VK_DRIVER_FILES`? I know it's some new thing that's supposed to replace `VK_ICD_FILENAMES` but does it actually have different semantics?
16:31 fdobridge: <S​id> no it's the same
16:31 fdobridge: <S​id> they're both interchangable in use
16:31 fdobridge: <p​rop_energy_ball> /shrug No, someone at LunarG woke up and decided to make an alias someday
16:31 fdobridge: <p​rop_energy_ball> I don't know why, or the rationale other than they started randomly saying `VK_ICD_FILENAMES` is deprecated
16:32 fdobridge: <p​rop_energy_ball> but VK_ICD_FILENAMES is a MUCH better name than DRIVER_FILES
16:32 fdobridge: <p​rop_energy_ball> so I don't get it =(
16:33 fdobridge: <S​id> elite dangerous does not seem to get past its planetary shader gen on nvk, regardless of GPL
16:34 fdobridge: <S​id> wine log from when it crashes
16:34 fdobridge: <S​id> https://cdn.discordapp.com/attachments/1034184951790305330/1213162336215638016/elitedangerousNVKcrash.log?ex=65f47878&is=65e20378&hm=8fe900a9bccbfe78f74e4e3a4a6cbd111f4855e13c033d5e42ce87ccbcf442fd&
16:34 fdobridge: <t​om3026> well VK_DRIVER_FILES can do wildcard matching on names
16:34 fdobridge: <t​om3026> "*NVIDIA*"
16:34 fdobridge: <t​om3026> uhm
16:34 fdobridge: <S​id> something something vkCreateComputePipelines exception
16:34 fdobridge: <g​fxstrand> Yeah and why would anyone want that?
16:34 fdobridge: <t​om3026> discord ate my wildcard
16:35 fdobridge: <S​id> to maybe pass both x86 and x86_64 libs while keeping it short, maybe
16:35 fdobridge: <g​fxstrand> Yeah, it's probably the compiler getting wedged on something. Annoying that it's not printing out an assert.
16:35 fdobridge: <g​fxstrand> You might be able to run with fossilize and extract the compute shaders and run outside of Wine.
16:35 fdobridge: <!​DodoNVK (she) 🇱🇹> Compile 64-bit NVK with debug symbols and take note of the library offset
16:35 fdobridge: <g​fxstrand> You might be able to run with fossilize and extract the compute shaders and compile those outside of Wine. (edited)
16:36 fdobridge: <S​id> I was gonna try running it with damavand first 😅
16:36 fdobridge: <!​DodoNVK (she) 🇱🇹> Compile 64-bit NVK with debug symbols and take note of the library offset (after crashing the game with debug symbols of course) (edited)
16:36 fdobridge: <g​fxstrand> In case anyone wonders what the current level of troll user requests is...
16:36 fdobridge: <g​fxstrand> https://cdn.discordapp.com/attachments/1034184951790305330/1213162959518302248/image.png?ex=65f4790d&is=65e2040d&hm=ad820aa2566b8888d572a622d2e7c255cbe14de7c7878a1b5138fd9a910b949b&
16:37 fdobridge: <t​om3026> 2025, nvk is now the first vulkan driver on windows xp!
16:37 fdobridge: <p​ac85> I'm afraid it wouldn't be the first
16:37 fdobridge: <S​id> damavand just does not
16:37 fdobridge: <S​id> oookay then
16:37 fdobridge: <!​DodoNVK (she) 🇱🇹> First Mesa XDDM driver (real)
16:38 fdobridge: <S​id> time to swap proton experimental from bleeding-edge to bleeding-edge-debug
16:38 fdobridge: <S​id> can someone go back and stop 2020 Sid from switching to linux 😅
16:39 fdobridge: <S​id> I'm sitting here on a friday night, while there's a cultural fest going on at my uni, trying to get more info on a foss driver crash
16:40 fdobridge: <S​id> would that be setting -Db_ndebug=true in the compile time options?
16:42 cwabbott: "machine, pls make driver / real fast like / w/ BIG features too, / play all my fav games, / also fancy upscaling with woosh on / Thanks, human / PS no bugs :)"
16:43 fdobridge: <t​om3026> might need !strip if on arch and makepkg
16:43 fdobridge: <S​id> did add that, yeah
16:51 fdobridge: <!​DodoNVK (she) 🇱🇹> I think that toggles the assertions
16:51 fdobridge: <S​id> good thing I enabled it then
16:51 fdobridge: <S​id> still waiting on proton to update though
16:51 fdobridge: <S​id> so I can get dxvk debug logs too
17:01 fdobridge: <S​id> well, I didn't get any assert (likely missing an env var for it), but I do have the last shader we tried to compile before crashing
17:01 fdobridge: <S​id> or, will, the shader hash
17:02 fdobridge: <S​id> ```
17:02 fdobridge: <S​id> debug: Compiling shader CS_1ca9cf8c2e7ca6f96b40305816bf1652c7c85025
17:02 fdobridge: <S​id> debug: Input Signature for - CS_1ca9cf8c2e7ca6f96b40305816bf1652c7c85025
17:02 fdobridge: <S​id> debug: Output Signature for - CS_1ca9cf8c2e7ca6f96b40305816bf1652c7c85025
17:02 fdobridge: <S​id> ```
17:02 fdobridge: <S​id> no further info
17:02 fdobridge: <S​id> let me try spoofing an amd card to see if those shaders work better
17:02 fdobridge: <S​id> because afaik ED ships different shaders for nv and amd
17:04 fdobridge: <S​id> nope
17:05 fdobridge: <!​DodoNVK (she) 🇱🇹> Do you still get the syscall_fault?
17:05 fdobridge: <S​id> if there's anything specific I have to do to make the assert print out, let me know
17:05 fdobridge: <S​id> yes
17:05 fdobridge: <!​DodoNVK (she) 🇱🇹> What's the library offset now?
17:06 fdobridge: <S​id> https://cdn.discordapp.com/attachments/1034184951790305330/1213170491712479322/hereSeeForYourselfIDunnoWhatToLookFor.log?ex=65f48010&is=65e20b10&hm=f218991936a4a79d62348c40834578776437bdb117bc72a75fc4ad60c233d9ec&
17:06 fdobridge: <S​id> 0x793557, I think?
17:06 fdobridge: <S​id> or is it 0x7c78c3393557
17:07 fdobridge: <!​DodoNVK (she) 🇱🇹> Can you do `objdump -D -Mintel -l libvulkan_nouveau.so > libvulkan_nouveau.txt`?
17:08 fdobridge: <S​id> sure can, just a sec
17:09 fdobridge: <S​id> guessing it's meant to take longer than a sec
17:10 fdobridge: <!​DodoNVK (she) 🇱🇹> Yes
17:10 fdobridge: <S​id> oh, spicy command
17:10 fdobridge: <S​id> laptop fans ramping up and down
17:10 fdobridge: <S​id> fun
17:22 fdobridge: <S​id> heckin chonk
17:22 fdobridge: <S​id> 340mb and still going
17:22 fdobridge: <S​id> oh well
17:23 fdobridge: <!​DodoNVK (she) 🇱🇹> That's a lot of debug symbols
17:24 fdobridge: <S​id> it's just your vulkan-nouveau-git pkgbuild but
17:24 fdobridge: <S​id> modified
17:32 fdobridge: <S​id> chonk
17:32 fdobridge: <S​id> even gzip -9'd it's 54mb
17:33 fdobridge: <S​id> 428mb uncompressed
17:33 fdobridge: <t​om3026> thats massive tho, using some high compression ratio on btrfs probably would reduce the gigabytes ~/dev uses of all the git repos lol
17:33 fdobridge: <S​id> let's try zstd -22
17:34 fdobridge: <S​id> I'm already using zstd -7 compression on zfs
17:34 fdobridge: <!​DodoNVK (she) 🇱🇹> Now search for 793557 in that file
17:36 fdobridge: <S​id> let's see if vscode is up to the task...
17:36 fdobridge: <S​id> oh
17:36 fdobridge: <S​id> es
17:36 fdobridge: <S​id> ` 793557: e8 d4 90 e2 ff call 5bc630 <_ZN4core4cell16RefCell$LT$T$GT$10borrow_mut17heca93d7b8ff06000E>`
17:37 fdobridge: <!​DodoNVK (she) 🇱🇹> Can you go to the line where you found this?
17:38 fdobridge: <S​id> as in?
17:39 fdobridge: <S​id> in the objdump generated txt?
17:39 fdobridge: <!​DodoNVK (she) 🇱🇹> Yes
17:39 fdobridge: <S​id> already on it, yeah
17:39 fdobridge: <!​DodoNVK (she) 🇱🇹> What comes after and before it?
17:40 fdobridge: <S​id> ```
17:40 fdobridge: <S​id> 79354a: 00
17:40 fdobridge: <S​id> 79354b: 48 8d 7c 08 30 lea rdi,[rax+rcx*1+0x30]
17:40 fdobridge: <S​id> 793550: 48 8d 35 49 10 9e 00 lea rsi,[rip+0x9e1049] # 11745a0 <_ZN4core3fmt2rt12USIZE_MARKER17hdc7ca105c6554142E+0xa1a8>
17:40 fdobridge: <S​id> 793557: e8 d4 90 e2 ff call 5bc630 <_ZN4core4cell16RefCell$LT$T$GT$10borrow_mut17heca93d7b8ff06000E>
17:40 fdobridge: <S​id> 79355c: 48 89 94 24 30 01 00 mov QWORD PTR [rsp+0x130],rdx
17:40 fdobridge: <S​id> 793563: 00
17:40 fdobridge: <S​id> ```
17:45 fdobridge: <S​id> I recognize
17:45 fdobridge: <S​id> x86 instructions
17:45 fdobridge: <S​id> but that's about it
17:45 fdobridge: <S​id> also this is with sparse MR built 🐸
17:49 fdobridge: <!​DodoNVK (she) 🇱🇹> Can you provide more context for this line?
17:52 fdobridge: <S​id> https://cdn.discordapp.com/attachments/1034184951790305330/1213182128364199986/context.log?ex=65f48ae7&is=65e215e7&hm=bb736a0679eb1b4b636d03cf167e9c62b650b752cf1d82d64589df5846ff726a&
17:57 fdobridge: <!​DodoNVK (she) 🇱🇹> So I guess the issue is in this line: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/nouveau/compiler/nak/repair_ssa.rs#L33
17:58 fdobridge: <S​id> possibly
18:18 fdobridge: <S​id> so
18:18 fdobridge: <S​id> news
18:19 fdobridge: <S​id> I can just disable start up shader warming for elite
18:25 fdobridge: <S​id> nvm it still does planetary
21:02 Sid127: ^C11h^C^C13e^C^C0l^C^C13l^C^C11o
21:02 Sid127: aw
21:03 Sid127: oh
21:04 fdobridge: <g​fxstrand> I think I figured out what's wrong with KHR-GL46.tessellation_shader.tessellation_control_to_tessellation_evaluation.gl_tessLevel and it falls thoroughly into the "thanks, I hate it" category
21:11 fdobridge: <r​edsheep> Which end of things is the issue on then? Zink, NVK, CTS?
21:14 fdobridge: <g​fxstrand> I think I need to whack a magic shader control bit
21:14 fdobridge: <g​fxstrand> I just don't know what bit
21:14 fdobridge: <g​fxstrand> @karolherbst who did you get an answer from the last time we did this?
21:15 fdobridge: <g​fxstrand> And can we get the rest of the bits?
21:15 fdobridge: <g​fxstrand> Jeff got quickly cagey
21:18 fdobridge: <k​arolherbst🐧🦀> John
21:18 fdobridge: <k​arolherbst🐧🦀> and uhm...
21:18 fdobridge: <k​arolherbst🐧🦀> Andy
21:19 fdobridge: <k​arolherbst🐧🦀> I'd write Andy first.. that reminds me.. I have to ping on the other things 😄
21:21 fdobridge: <g​fxstrand> Okay, I'll write Andy
21:25 fdobridge: <k​arolherbst🐧🦀> what evil bit do you try to figure out this time though?
21:33 fdobridge: <g​fxstrand> The one that disables OOB access exceptions
21:41 fdobridge: <k​arolherbst🐧🦀> mhhh
21:42 fdobridge: <k​arolherbst🐧🦀> yeah.. good idea to ask about it
21:42 fdobridge: <k​arolherbst🐧🦀> I just suspect the answer will require cursed things 😄
21:54 fdobridge: <g​fxstrand> I expect it's a single bit we have to set through FALCON again
21:55 fdobridge: <g​fxstrand> I may just start whacking bits and see what happens
21:59 fdobridge: <S​id> let's go! <https://github.com/torvalds/linux/commit/f6ecfdad359a01c7fd8a3bcfde3ef0acdf107e6e>
22:14 fdobridge: <g​fxstrand> @karolherbst What do the arguments to SET_PRIV_REG do? The first is the address, the third is a bit to set but what's the second?
22:14 fdobridge: <g​fxstrand> Or is the third a mask to modify and the second is the value to set?
22:14 fdobridge: <k​arolherbst🐧🦀> mask
22:15 fdobridge: <k​arolherbst🐧🦀> it's a mask to specify which bits to set
22:15 fdobridge: <k​arolherbst🐧🦀> so you can also set 0
22:15 fdobridge: <g​fxstrand> Okay, so it goes addr, bits, mask?
22:15 fdobridge: <S​id> out of sheer curiosity, I'm guessing we're working on getting nouveau overclocking/hwmon going over the sysfs interface?
22:16 fdobridge: <k​arolherbst🐧🦀> the way it's implemented in NVK it goes: value, mask, addr
22:16 fdobridge: <g​fxstrand> right, okay
22:16 fdobridge: <g​fxstrand> that makes sense
22:17 fdobridge: <k​arolherbst🐧🦀> the actual interface to the firmware is a bit more cursed
22:17 fdobridge: <k​arolherbst🐧🦀> I reordered it from how nvidia done it, because I could safe a temporary this way :ferrisUpsideDown:
22:18 fdobridge: <k​arolherbst🐧🦀> but anyway... the binary interface takes three values + the address as the trigger in `FALCON04`
22:19 fdobridge: <k​arolherbst🐧🦀> and what the first value does is kinda unknown, because it's 0
22:19 fdobridge: <k​arolherbst🐧🦀> but then you get the value and the mask
22:20 fdobridge: <k​arolherbst🐧🦀> maybe the first one is a mask of values to keep?
22:20 fdobridge: <k​arolherbst🐧🦀> *bits
22:20 fdobridge: <g​fxstrand> Yeah, that's fine
22:21 fdobridge: <g​fxstrand> Okay, so I've fuzzed it and it's none of the bits in that register
22:21 fdobridge: <g​fxstrand> Or at least it isn't just one bit in that register
22:22 fdobridge: <k​arolherbst🐧🦀> tried setting and unsetting?
22:32 fdobridge: <p​avlo_it_115> Nothing interesting =)
22:32 fdobridge: <p​avlo_it_115> Gn
22:32 fdobridge: <p​avlo_it_115> https://cdn.discordapp.com/attachments/1034184951790305330/1213252438568472636/image.png?ex=65f4cc62&is=65e25762&hm=8b75a2b5c4e1b75a8997692360304afa235aa35013d4f11f7bd9648b1d904a7e&
22:32 fdobridge: <h​untercz122> now you have something interesting for your CV
22:32 fdobridge: <p​avlo_it_115> Nothing interesting =)
22:32 fdobridge: <p​avlo_it_115> Good night all! (edited)
22:32 fdobridge: <p​avlo_it_115> https://cdn.discordapp.com/attachments/1034184951790305330/1213252438568472636/image.png?ex=65f4cc62&is=65e25762&hm=8b75a2b5c4e1b75a8997692360304afa235aa35013d4f11f7bd9648b1d904a7e&
22:32 fdobridge: <S​id> ...
22:32 fdobridge: <S​id> ooookay then
22:33 fdobridge: <g​fxstrand> @karolherbst I think I know what I'm looking for: #define gr_gpc0_tpc0_sm0_hww_warp_esr_report_mask_r() (0x00504728U)
22:33 fdobridge: <S​id> ah yes, moved 2 lines of code between functions on the linux kernel xD
22:33 fdobridge: <g​fxstrand> https://github.com/alliedvision/linux_nvidia_jetson/blob/4609206e6594f1eb21e43e69afa8974cf20cc096/kernel/nvgpu/drivers/gpu/nvgpu/include/nvgpu/hw/gv11b/hw_gr_gv11b.h#L1302C1-L1302C81
22:33 fdobridge: <g​fxstrand> So the question is where did they move the register...
22:35 fdobridge: <m​arysaka> There is some file similar for TU104 :aki_thonk: https://github.com/alliedvision/linux_nvidia_jetson/blob/4609206e6594f1eb21e43e69afa8974cf20cc096/kernel/nvgpu/drivers/gpu/nvgpu/include/nvgpu/hw/tu104/hw_gr_tu104.h#L1008
22:35 fdobridge: <g​fxstrand> Yeah, I'm looking at that now
22:38 fdobridge: <k​arolherbst🐧🦀> yeah.. that's part of the trap handler thing
22:38 fdobridge: <k​arolherbst🐧🦀> it's all a bit cursed to set up
22:39 fdobridge: <k​arolherbst🐧🦀> but this is also relevant for setting up the shader trap handler properly
22:39 fdobridge: <k​arolherbst🐧🦀> the thing is just, that those masks are not documented
22:39 fdobridge: <k​arolherbst🐧🦀> mhh...
22:39 fdobridge: <k​arolherbst🐧🦀> maybe that one actually ise
22:39 fdobridge: <k​arolherbst🐧🦀> *is
22:40 fdobridge: <k​arolherbst🐧🦀> wtf...
22:40 fdobridge: <k​arolherbst🐧🦀> @gfxstrand https://github.com/alliedvision/linux_nvidia_jetson/blob/4609206e6594f1eb21e43e69afa8974cf20cc096/kernel/nvgpu/drivers/gpu/nvgpu/include/nvgpu/hw/gv11b/hw_gr_gv11b.h#L1618 :ferrisUpsideDown:
22:41 fdobridge: <k​arolherbst🐧🦀> I haven't found this definition in any other repo
22:42 fdobridge: <k​arolherbst🐧🦀> can you whack it via the priv_reg macro?
22:43 fdobridge: <g​fxstrand> no
22:43 fdobridge: <g​fxstrand> At least it doesn't seem to do anything
22:43 fdobridge: <e​sdrastarsis> Like I said, theres nothing to discuss...
22:45 fdobridge: <k​arolherbst🐧🦀> I ask you to rethink how you interact with people there and to tone down your language
22:46 fdobridge: <p​avlo_it_115> 👍
22:46 fdobridge: <k​arolherbst🐧🦀> mhhh... yeah.. I don't really know what the kernel needs to set here and what userspace does
22:46 fdobridge: <k​arolherbst🐧🦀> you can look at priv_reg register maps somewhere in nvgpu
22:48 fdobridge: <k​arolherbst🐧🦀> uhhh...
22:48 fdobridge: <k​arolherbst🐧🦀> where was that..
22:49 fdobridge: <k​arolherbst🐧🦀> @gfxstrand `gv11b_gr_init_get_access_map` or `ga10b_gr_init_get_access_map`
22:49 fdobridge: <k​arolherbst🐧🦀> those are the regs we can probably all touch via the macro
22:49 fdobridge: <k​arolherbst🐧🦀> `gr_pri_gpcs_tpcs_sms_hww_warp_esr_report_mask` is _probably_ the one you need here
22:49 fdobridge: <k​arolherbst🐧🦀> which is `0x419ea8`
22:50 fdobridge: <k​arolherbst🐧🦀> `0x4188fc, /* gr_pri_gpcs_zcull_ctx_debug */` :ferrisUpsideDown:
22:50 fdobridge: <k​arolherbst🐧🦀> ` 0x419a04, /* gr_pri_gpcs_tpcs_tex_lod_dbg */`.. there are some goodies, if I just knew what they all do
22:53 fdobridge: <g​fxstrand> Yeah, I've tried `0x419ea8` bit 14
22:55 fdobridge: <g​fxstrand> I also tried `0x50472c`
22:58 fdobridge: <p​avlo_it_115> Am I pushing people too much, or am I being insolent?
22:59 fdobridge: <p​avlo_it_115> Am I pushing people too much, or am I being insolent?
22:59 fdobridge: <p​avlo_it_115> What exactly is the matter (edited)
23:02 fdobridge: <g​fxstrand> Annoying whoever NVIDIA has assigned to watch those issues isn't going to change their answer RE firmware and it is going to annoy one of the few people NVIDIA has facing the world of open-source.
23:03 fdobridge: <p​avlo_it_115> sorry..
23:04 fdobridge: <k​arolherbst🐧🦀> you are just very rude
23:04 fdobridge: <k​arolherbst🐧🦀> there
23:06 fdobridge: <g​fxstrand> Clearing most of the bits in that register doesn't seem to do anything. 😢
23:08 fdobridge: <p​avlo_it_115> https://cdn.discordapp.com/attachments/1034184951790305330/1213261486332313600/dc633f13e59990ab.png?ex=65f4d4cf&is=65e25fcf&hm=b52e23bcbe477f8b1a5d2dc068e340179df65cbf7f074253f2911ad1db0fcb52&
23:08 fdobridge: <p​avlo_it_115> https://tenor.com/view/facedown-face-down-watchdogs-frustration-gif-10398043
23:21 fdobridge: <r​edsheep> Are you still up against this block on calibrated timestamps? I've also been attempting this, so far mostly just by reading the other implementations since there seems to be no real documentation
23:22 fdobridge: <S​id> you can go ahead if you want to, I just had nothing to do and thought I'd take a crack at it
23:44 fdobridge: <g​fxstrand> I think I've got it!
23:45 fdobridge: <g​fxstrand> Yup. It was bit 14 after all
23:45 fdobridge: <g​fxstrand> I had a hack in the way
23:48 fdobridge: <k​arolherbst🐧🦀> nice
23:48 fdobridge: <k​arolherbst🐧🦀> via `0x419ea8` then?
23:48 fdobridge: <k​arolherbst🐧🦀> or the other reg?
23:54 fdobridge: <g​fxstrand> MR incoming
23:55 fdobridge: <r​edsheep> I wonder if that might fix heaven, it's uniquely heavy on tessellation. I will give it a try