07:53 mindnotatall: All my life, they been tryna keep me down, All this time. Never thought i make it out. They gonna break me , they gonna break me, no no, they gonna take me no. Trash you take nothing in this world, neither marts life, when you are always wrong not in million years. I just nominate three of your spies to get batted and we gonna treat those outlaws instead,
07:53 mindnotatall: so queue jumper exists indeed
07:54 mindnotatall: i got the access methods working, from there queue jumper is a little more work
11:40 Sid127: time to try out nvk gaming with steam's shader pre-caching
12:22 karolherbst: flashback when a game loaded for 5 minutes on nouveau before it had a shader cache, and 20 seconds with
19:12 Sid127: out of sheer curiosity
19:12 Sid127: what's our status on va-api?
19:24 karolherbst: terrible
19:30 fdobridge_: <t​om3026> @karolherbst or @airlied since you two are uber kernel hackers, you know of any MM kernel devs lurking around on irc that would mind getting questioned a bit about my dma_pool page allocation failure on boot on 6.7 and up? kinda pondering if im having hw/bios issues
19:30 fdobridge_: <k​arolherbst🐧🦀> on AMD?
19:31 fdobridge_: <t​om3026> yeah
19:33 fdobridge_: <k​arolherbst🐧🦀> agd5f, that's Alex Deucher
19:34 fdobridge_: <k​arolherbst🐧🦀> well.. if it's AMD related that is
19:36 fdobridge_: <t​om3026> well im a bit unsure at what parts of HW its relating to but its quite early in the boot process, https://gist.github.com/gulafaran/18d7e2f95287cd13a3e75a62270c3a4f can be "mitigated" or silenced with setting coherent_pool=1M . but its an ryzen 5800h cezanne laptop
19:36 fdobridge_: <k​arolherbst🐧🦀> mhhhhhhhhhhhhhhhhh
19:36 fdobridge_: <k​arolherbst🐧🦀> wait a second... I know that one
19:36 fdobridge_: <t​om3026> but i seem to be the only person on this planet getting it im suspecting local issues :p
19:37 fdobridge_: <k​arolherbst🐧🦀> @tom3026 https://gitlab.freedesktop.org/drm/amd/-/issues/3011 maybe?
19:37 fdobridge_: <k​arolherbst🐧🦀> does it happen under heavy memory pressure?
19:37 fdobridge_: <k​arolherbst🐧🦀> well ehh
19:37 fdobridge_: <k​arolherbst🐧🦀> more like this closed bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2912
19:38 fdobridge_: <k​arolherbst🐧🦀> I blame amdgpu, amdgpu devs disgagree 🙂
19:38 fdobridge_: <k​arolherbst🐧🦀> I blame amdgpu, amdgpu devs disagree 🙂 (edited)
19:38 fdobridge_:<k​arolherbst🐧🦀> but
19:39 fdobridge_: <k​arolherbst🐧🦀> I think there is something wrong with memory management and some users run into OOM situation on the GPU side
19:39 fdobridge_: <t​om3026> it happens straight up at boot when the kernel allocates a pool for atomic allocations
19:39 fdobridge_: <k​arolherbst🐧🦀> mhhh
19:39 fdobridge_: <k​arolherbst🐧🦀> I see...
19:39 fdobridge_: <k​arolherbst🐧🦀> so maybe a different bug then
19:41 airlied: do you have a lot of memory?
19:44 fdobridge_: <t​om3026> 32gb
19:44 fdobridge_: <t​om3026> i realized i wonder if it comes later if i dont put amdgpu in the initramfs hm
19:44 fdobridge_: <t​om3026> maybe it is somewhat related to what karol linked hm
19:45 fdobridge_: <k​arolherbst🐧🦀> would be strange tho
19:45 fdobridge_: <p​ixelcluster> ~~blaming userspace is a specialty~~
19:45 fdobridge_: <p​ixelcluster> ~~blaming userspace is a specialty of theirs it seems~~ (edited)
19:46 fdobridge_: <k​arolherbst🐧🦀> ~~don't worry, I just blame kernelspace, so it evens out~~
19:49 fdobridge_: <S​id> I'm just mad Resizable BAR has been part of the PCIe spec since 2010
19:49 fdobridge_: <S​id> and yet it's locked behind CPU/GPU configurations in 2024
19:50 fdobridge_: <t​om3026> wasnt there some wonky patches to do it anyways on linux?
19:51 fdobridge_: <S​id> nvidia still locks it on their gpus
19:52 fdobridge_: <S​id> behind presumably a vbios toggle
19:52 fdobridge_: <S​id> fOr 3000 sErIeS aNd aBoVe OnLy
19:53 fdobridge_: <k​arolherbst🐧🦀> I think Faith has a Turing doing rebar...
19:53 fdobridge_: <S​id> impossible
19:53 fdobridge_: <k​arolherbst🐧🦀> but I think the kernel driver can enable it anyway
19:53 fdobridge_: <k​arolherbst🐧🦀> $code_needed
19:53 fdobridge_: <k​arolherbst🐧🦀> there was somebody writing a patch against nvidias open driver even 😄
19:53 fdobridge_: <S​id> hm
19:53 fdobridge_: <t​om3026> https://github.com/JuliaComputing/nvidia-driver-pcie-rebar seems to have died off but
19:53 fdobridge_: <k​arolherbst🐧🦀> https://github.com/NVIDIA/open-gpu-kernel-modules/pull/3
19:54 fdobridge_: <S​id> I'd be quite interested in that I wanna mess around with it
19:54 fdobridge_: <t​om3026> there is also https://github.com/xCuri0/ReBarUEFI but dont blame me when it bricks 😄
19:54 fdobridge_: <k​arolherbst🐧🦀> `The use of goto is concerning to me.` best comment ever
19:54 fdobridge_: <S​id> I've already done all of this to patch support into my laptop's bios
19:54 fdobridge_: <S​id> fun part is
19:55 fdobridge_: <S​id> I managed to get my hands on an engineering bios for my laptop, and I did the patching *on that*
19:55 fdobridge_: <d​wlsalmeida> Hi all, I am poking around in the nouveau driver, can anyone enlighten me on the meaning of this line?
19:55 fdobridge_: <d​wlsalmeida>
19:55 fdobridge_: <d​wlsalmeida> ```
19:55 fdobridge_: <d​wlsalmeida> if (!runm || init->fb_ctxdma_handle == ~0 || init->tt_ctxdma_handle == ~0)
19:55 fdobridge_: <d​wlsalmeida> return nouveau_abi16_put(abi16, -EINVAL);
19:55 fdobridge_: <d​wlsalmeida> ```
19:55 fdobridge_: <S​id> so I have more options than the average Acer Nitro 7 user *and* patched in rebar support
19:55 fdobridge_: <S​id> but my GPU :\
19:55 fdobridge_: <k​arolherbst🐧🦀> pain
19:55 fdobridge_: <k​arolherbst🐧🦀> maybe it's your firmware then
19:55 fdobridge_: <k​arolherbst🐧🦀> enabled rebar in your uefi settings?
19:55 fdobridge_: <S​id> yup
19:56 fdobridge_: <S​id> I'm able to shrink my BAR
19:56 fdobridge_: <k​arolherbst🐧🦀> heh
19:56 fdobridge_: <S​id> but not push it beyond 256mb
19:56 fdobridge_: <k​arolherbst🐧🦀> tried `NVreg_EnableResizableBar=1` with nvidias open driver?
19:56 fdobridge_: <S​id> yup
19:56 fdobridge_: <S​id> I think e-e
19:56 fdobridge_: <k​arolherbst🐧🦀> mhhh
19:56 fdobridge_: <k​arolherbst🐧🦀> I'd double check
19:57 fdobridge_: <S​id> yup, I've got it enabled
19:57 fdobridge_: <S​id> ```
19:57 fdobridge_: <S​id> [sidpr@strogg ~]$ cat /etc/modprobe.d/chiku.conf
19:57 fdobridge_: <S​id> options snd_hda_intel power_save=1
19:57 fdobridge_: <S​id>
19:57 fdobridge_: <S​id> options iwlwifi power_save=1
19:57 fdobridge_: <S​id> options iwlwifi uapsd_disable=0
19:57 fdobridge_: <S​id> options iwlmvm power_scheme=3
19:57 fdobridge_: <S​id>
19:57 fdobridge_: <S​id> options nvidia_drm modeset=1
19:57 fdobridge_: <S​id> options nvidia NVreg_UsePageAttributeTable=1
19:57 fdobridge_: <S​id> options nvidia NVreg_InitializeSystemMemoryAllocations=0
19:57 fdobridge_: <S​id> options nvidia NVreg_EnableStreamMemOPs=1
19:57 fdobridge_: <S​id> options nvidia NVreg_RegistryDwords="OverrideMaxPerf=0x1"
19:57 fdobridge_: <S​id> options nvidia NVreg_DynamicPowerManagement=0x02
19:57 fdobridge_: <S​id> options nvidia NVreg_EnableGpuFirmware=1
19:57 fdobridge_: <S​id> options nvidia NVreg_EnableS0ixPowerManagement=1
19:57 fdobridge_: <S​id> options nvidia NVreg_EnableResizableBar=1
19:57 fdobridge_: <S​id> # options nvidia NVreg_PreserveVideoMemoryAllocations=1
19:57 fdobridge_: <S​id> options nvidia NVreg_TemporaryFilePath=/home/sidpr/.nvsuspend
19:57 fdobridge_: <S​id>
19:57 fdobridge_: <S​id> # blacklist uvcvideo
19:57 fdobridge_: <S​id> # blacklist nouveau
19:57 fdobridge_: <S​id> ```
19:57 fdobridge_: <S​id> preserve vmem alloc currently disabled because, well, it's broken on open kernel module
19:59 fdobridge_: <k​arolherbst🐧🦀> what does modinfo say
19:59 fdobridge_: <k​arolherbst🐧🦀> ehh..
19:59 fdobridge_: <k​arolherbst🐧🦀> procfs
20:00 fdobridge_: <t​om3026> https://www.nvidia.com/en-us/geforce/news/geforce-rtx-30-series-resizable-bar-support/ thats interesting so what doies the vbios have todo with the rebar hm
20:00 fdobridge_: <k​arolherbst🐧🦀> ehh sysfs actually
20:00 fdobridge_: <S​id> 🐸
20:00 fdobridge_: <S​id> where do I chec
20:00 fdobridge_: <S​id> where do I check (edited)
20:00 fdobridge_: <k​arolherbst🐧🦀> the kernel module deciding whether to enable it or not
20:01 fdobridge_: <k​arolherbst🐧🦀> `/sys/module/nvidia/parameters/` or something
20:01 fdobridge_: <k​arolherbst🐧🦀> not sure if it's even used for nvidia
20:01 fdobridge_: <S​id> ok gimme 10 mins
20:01 fdobridge_: <k​arolherbst🐧🦀> well.. with my 24GB VRAM GPU, I have a BAR of 256MB, sooo....
20:01 fdobridge_: <k​arolherbst🐧🦀> pain
20:01 fdobridge_: <k​arolherbst🐧🦀> never tried any of it yet
20:01 fdobridge_: <S​id> I've got a 6 gig gpu
20:01 fdobridge_: <S​id> :frog_gears:
20:01 fdobridge_: <k​arolherbst🐧🦀> but maybe with nouveau we can just enable it regardless
20:02 fdobridge_: <S​id> that'd be great honestly
20:02 fdobridge_: <k​arolherbst🐧🦀> ~~I also have a 48GB VRAM GPU, and a 32GB RAM desktop :ferrisCluelesser: ~~
20:02 fdobridge_: <S​id> here's what lspci -vv says
20:02 fdobridge_: <S​id> ```
20:02 fdobridge_: <S​id> Capabilities: [bb0 v1] Physical Resizable BAR
20:02 fdobridge_: <S​id> BAR 0: current size: 16MB, supported: 16MB
20:02 fdobridge_: <S​id> BAR 1: current size: 256MB, supported: 64MB 128MB 256MB
20:03 fdobridge_: <S​id> BAR 3: current size: 32MB, supported: 32MB
20:03 fdobridge_: <S​id> Kernel driver in use: nvidia
20:03 fdobridge_: <S​id> ```
20:03 fdobridge_: <S​id> I was on proprietary kernel module for a bit, just installing the open one again and I'll poke around /sys/module
20:04 fdobridge_: <k​arolherbst🐧🦀> mhh
20:09 fdobridge_: <S​id> uuugh
20:09 fdobridge_: <S​id> it doesn't wanna build
20:09 fdobridge_: <S​id> ```
20:09 fdobridge_: <S​id> /home/sidpr/Tools/packages/nvidia-all/src/open-gpu-kernel-modules-535.43.22/kernel-open/nvidia/libspdm_shash.c:90:26: error: implicit declaration of function ‘crypto_tfm_ctx_aligned’; did you mean ‘crypto_tfm_ctx_align’? [-Werror=implicit-function-declaration]
20:09 fdobridge_: <S​id> 90 | char *src_ipad = crypto_tfm_ctx_aligned(&src_tfm->base);
20:09 fdobridge_: <S​id> ```
20:11 fdobridge_: <S​id> I think that's removed from the kernel
20:11 fdobridge_: <S​id> let me try a different version
20:15 fdobridge_: <S​id> ok that built
20:25 fdobridge_: <S​id> yeah, even with open kernel module
20:25 fdobridge_: <S​id> ```
20:25 fdobridge_: <S​id> Capabilities: [bb0 v1] Physical Resizable BAR
20:25 fdobridge_: <S​id> BAR 0: current size: 16MB, supported: 16MB
20:25 fdobridge_: <S​id> BAR 1: current size: 256MB, supported: 64MB 128MB 256MB
20:25 fdobridge_: <S​id> BAR 3: current size: 32MB, supported: 32MB
20:25 fdobridge_: <S​id> Kernel driver in use: nvidia
20:25 fdobridge_: <S​id> ```
20:32 fdobridge_: <S​id> hm
20:32 fdobridge_: <S​id> actually
20:32 fdobridge_: <S​id> my bios may not have been modded correctly 🐸
20:39 fdobridge_: <S​id> oh `[ 0.617440] pci 0000:01:00.0: can't claim BAR 6 [mem 0xfff80000-0xffffffff pref]: no compatible bridge window`
21:06 fdobridge_: <S​id> @gfxstrand is this true
21:18 fdobridge_: <g​fxstrand> No. My Ampere REBARs just fine but not the Turing
21:19 fdobridge_: <S​id> yeah, that's what I recalled as well, since nv locks rebar behind a vbios toggle
21:32 fdobridge_: <k​arolherbst🐧🦀> ohh.. I see...
21:32 fdobridge_: <k​arolherbst🐧🦀> I think my ampere didn't rebar either tho
21:33 fdobridge_: <r​edsheep> Ampere does rebar on windows at least. Wonder why the left it locked out on turing, maybe just didn't want to update old parts of their drivers to account for it?
21:47 fdobridge_: <S​id> classic nv
21:48 fdobridge_: <S​id> trying to get as much money as possible out of their users
22:06 fdobridge_: <k​arolherbst🐧🦀> yeah.. I think one needs to do this vbios update thing or something.. dunno
22:09 fdobridge_: <r​edsheep> @gfxstrand Was there anything conclusive with what slows down the witness? Is it just doing weird shaders, or was it the occlusion? Even when rendering every single thing in the level it seems like 35 fps is still pretty slow
22:12 fdobridge_: <g​fxstrand> I haven't figured it out yet
22:12 fdobridge_: <g​fxstrand> Unfortunately, it crashes like mad in RenderDoc so it was kinda annoying to work on. 😭
22:12 fdobridge_: <g​fxstrand> IDK if that's because of the sparse stuff or something else.
22:13 fdobridge_: <r​edsheep> Oh, dang.
22:13 fdobridge_: <g​fxstrand> I do have a sense of where it's spending time, though.
22:14 fdobridge_: <g​fxstrand> The first couple render passes seem fine, like 3x faster than Intel. Then it goes super slow. I don't think it's occlusion unless they're doing query copies every draw call. I suspect we just have a really bad shader.
22:14 fdobridge_: <g​fxstrand> It's ubershader(ish) so we may be taking a wrong branch or something
22:17 fdobridge_: <r​edsheep> Makes sense, that could get pretty expensive.
22:22 fdobridge_: <r​edsheep> When I get some time I'll play around with renderdoc. Has it been working with with other games on NVK?
22:22 fdobridge_: <g​fxstrand> Yeah, typically.
22:23 fdobridge_: <g​fxstrand> It's entirely possible the crashes are an NVK bug of some sort. I didn't get much time on Friday to spend on it.
22:23 fdobridge_: <g​fxstrand> I ended up switching to trying to convert the whole driver towards DMA shader uploads to work around BAR limits. 😅
22:25 fdobridge_: <r​edsheep> Right, probably more worthwhile anyway given that limit probably isn't going away
23:20 katjosa: Making heat using graphics cards is an invention but there are cheaper ways to do it. And do get around of that you want to know my algorithm, the access method eliminates the smallest in the bank, and then goes to access all in descending order , so biggest value first is the access. hence the indexes/values of an offset and offsets of a bank come both with modulo arithmetic. And you append them from the header of the hash. queue jumping wh
23:20 katjosa: smaller than chassis or scaffolds has been made to
23:39 fdobridge_: <d​wlsalmeida> @airlied Dave, trying to run your vulkan video patches with fluster crashes here :/
23:39 fdobridge_: <d​wlsalmeida> isolated the issue down to nouveau_channel_new() returning -EINVAL so far
23:41 fdobridge_: <d​wlsalmeida> which gets propagated to `int ret = drmCommandWriteRead(dev->fd, DRM_NOUVEAU_CHANNEL_ALLOC, &req, sizeof(req));` in `nouveau_ws_vid_context_create`
23:42 fdobridge_: <d​wlsalmeida> my question here before I spend some significant time digging into this is: is this expected? I was under the impression that this was semi-working? but actually it's not progressing beyond `nvk_CreateDevice` here on a rtx2060
23:43 fdobridge_: <d​wlsalmeida> tried both linux 6.7.1 and 6.8-rc1 with your patch, if it matters, and both Lynne's branch for ffmpeg and Igalia's branch for gstreamer