00:00 fdobridge_: <T​om^> il see what i can get running on nvk
00:00 fdobridge_: <k​arolherbst🐧🦀> prolly way less, but would be good to be able to compare
00:01 fdobridge_: <k​arolherbst🐧🦀> or maybe not..
00:01 fdobridge_: <k​arolherbst🐧🦀> mhh
00:08 fdobridge_: <a​irlied> I ran unigine on zink on nvk last week
00:09 fdobridge_: <a​irlied> heaven ran i think, but was some misrendering unless I disabled one tickbox
00:09 fdobridge_: <k​arolherbst🐧🦀> compared performance to gl?
00:13 fdobridge_: <a​irlied> just eyeballing fps, but 20-30fps with nvc0 vs 50-60+ fps with zink/nvk
00:13 fdobridge_: <k​arolherbst🐧🦀> interesting
00:13 fdobridge_: <k​arolherbst🐧🦀> ~~guess we can torch nvc0 already~~
00:14 fdobridge_: <a​irlied> ah I had to turn off ambient occlusion
00:15 fdobridge_: <a​irlied> to get it to not misrender under zink/nvk
00:15 fdobridge_: <a​irlied> I also think fullscreen mode didn't go great with zink
00:16 fdobridge_: <k​arolherbst🐧🦀> I see...
00:20 fdobridge_: <a​irlied> I'll run heaven bench mode now
00:27 fdobridge_: <a​irlied> actually didn't come out vastly different with a full bench
00:28 fdobridge_: <a​irlied> 25.9, 652, 13.5, 72.5
00:28 fdobridge_: <a​irlied> 32.8, 827, 7.7, 69.4
00:28 fdobridge_: <a​irlied> fps, score, min, max
00:29 fdobridge_: <T​om^> hm havent tried zink, is it just an env var to do so?
00:30 fdobridge_: <r​edsheep> I am working on building with 26615 and 26622 to test heaven with and without zink right now
00:30 fdobridge_: <r​edsheep> All you need is MESA_LOADER_DRIVER_OVERRIDE=zink, right?
00:31 fdobridge_: <a​irlied> yes that and the vulkan ICD pointed to the right place
00:33 fdobridge_: <T​om^> MESA_LOADER_DRIVER_OVERRIDE=zink DRI_PRIME=1 VK_LOADER_DRIVERS_SELECT=*nouveau* glxinfo , segmention fault
00:36 fdobridge_: <a​irlied> I've been explicity setting the ICD path, but I haven't tried in a DRI_PRIME scenario yet
00:38 fdobridge_: <T​om^> vkcube spins on nvk but seems zink,glxgears segfaults i could build with a bit more debug symbols and make a bug report. but first some nvk testing! 😄
00:48 fdobridge_: <g​fxstrand> Which is which?
00:54 fdobridge_: <a​irlied> second line is zink/nvk
00:54 fdobridge_: <g​fxstrand> Nice
00:54 fdobridge_: <g​fxstrand> Time to disable pre-Turing nouveau GL?
00:54 fdobridge_: <g​fxstrand> I'm joking of course. Let's land NVK for F40 and do that for F41
00:55 fdobridge_: <g​fxstrand> Swapping out the *entire* graphics stack in one release feels like a bit much.
00:56 fdobridge_: <a​irlied> I think once @zmike comes back we can nail down the last few bits, I'd like to get GL CTS passing completely
00:57 fdobridge_: <g​fxstrand> Yeah
01:25 fdobridge_: <T​om^> cool counter strike 2 runs with ~55-60 on the vulkan renderer
01:26 fdobridge_: <T​om^> nvk is officially cs2 compatible 🙂
01:30 fdobridge_: <p​avlo_it_115> 👏
02:27 fdobridge_: <r​edsheep> Ok finally managed to fight through conflicts building with 26622 on the vulkan-nouveau-git aur package, 26615 was hopeless to fix for a git noob like me
02:28 fdobridge_: <r​edsheep> With the loop unrolling and whatever else has merged since Sunday I went from 100 fps in talos to 122 from the same spot
02:52 fdobridge_: <r​edsheep> Here's a 4090 doing heaven with the same settings mentioned earlier, I am a little surprised to only be just over 2x the performance of a 1650... I am still trying with zink but it's failing for me. Might need to try drm-misc-fixes, I am just on 6.7rc5 without patches right now
02:52 fdobridge_: <r​edsheep> https://cdn.discordapp.com/attachments/1034184951790305330/1184326934780444683/image.png?ex=658b9168&is=65791c68&hm=d3326fa34b4a113a334a8ae3fbd3f639968ba1d323e9aefbc0d61d6a01815c34&
03:13 Liver_K: airlied: The nouveau DDX didn't fix it
03:25 fdobridge_: <r​edsheep> Hmm. I went to drm-misc-fixes and even still zink fails to load at all, can't even run glxgears. Is there some patch everyone else is using to fix zink, or is it just not yet working on NV192? I put an icd path and everything
03:25 fdobridge_: <g​fxstrand> Yeah, I think we still have quite a bit of unnecessary stalling in the driver. That's something we'll need to work on. It's hard to make those big GPUs go fast when you're stalling like mad.
04:01 airlied: Liver_K: ouch, got the xorg log from that?
04:03 Liver_K: One minute
04:28 Liver_K: airlied: https://0x0.st/H3dK.log.old
04:49 airlied: Liver_K: okay not many other ideas then
04:58 Liver_K: :/
05:11 soreau: is wayland not an option?
05:11 Liver_K: No
05:13 soreau: why not?
05:14 Liver_K: Why would I take the time to explain that? Nouveau is meant to run on X, I am curious about what's going wrong is all
05:18 soreau: have you tried different wm's?
05:19 airlied: you could try adding Option "Accel" "none" to xorg.conf device section
05:19 soreau: airlied: ouch?
05:19 airlied: that will turn off some stuff you might want, but I think is should fix wm rendering
05:20 Liver_K: Alright I will try that next
15:38 fdobridge_: <g​fxstrand> Something funny is going wrong with LDC.
15:39 fdobridge_: <g​fxstrand> Maybe variable latency instructions don't like waiting on variable latency instructions?
15:47 fdobridge_: <k​arolherbst🐧🦀> mhh
15:47 fdobridge_: <k​arolherbst🐧🦀> it should be okay as long as you set up the scoreboard barrier correctly
15:48 fdobridge_: <k​arolherbst🐧🦀> @gfxstrand if you want, I can craft an CLC example doing that and you can check how nvidia sets it all up
15:49 fdobridge_: <k​arolherbst🐧🦀> so what instructions is this about? LDC and?
15:51 fdobridge_: <g​fxstrand> LDC followed by `ld.global` with the result of the LDC feeding into the address.
15:51 fdobridge_: <g​fxstrand> ```
15:51 fdobridge_: <g​fxstrand> block 0 L0 [] -> {
15:51 fdobridge_: <g​fxstrand> r0 = ipa.constant r0 a[0x90] rZ // delay=1 wr:0
15:51 fdobridge_: <g​fxstrand> r1 = mov 0x4 // delay=15
15:51 fdobridge_: <g​fxstrand> r0 = shf.l.w.i32 r0 rZ r1 // delay=15 wt=000001
15:51 fdobridge_: <g​fxstrand> r2 = ldc.b32 c[0x1][r0] // delay=1 rd:0 wr:1
15:51 fdobridge_: <g​fxstrand> r3 = ldc.b32 c[0x1][r0+0x4] // delay=1 rd:2 wr:3
15:51 fdobridge_: <g​fxstrand> r4..8 = ld.global.a64.strong.sys.b128 [r2..4+0x10] // delay=1 wt=001010 rd:1 wr:3
15:51 fdobridge_: <g​fxstrand> r3 = mov r7 // delay=1 wt=001010
15:51 fdobridge_: <g​fxstrand> r2 = mov r6 // delay=1
15:51 fdobridge_: <g​fxstrand> r1 = mov r5 // delay=1
15:51 fdobridge_: <g​fxstrand> r0 = mov r4 // delay=14 wt=000100
15:51 fdobridge_: <g​fxstrand> exit // delay=1 wt=000001
15:51 fdobridge_: <g​fxstrand> ```
15:51 fdobridge_: <k​arolherbst🐧🦀> ahh
15:52 fdobridge_: <g​fxstrand> That's not working
15:52 fdobridge_: <g​fxstrand> Which... what the hell?!?
15:52 fdobridge_: <g​fxstrand> That or I'm missing some sort of barrier on the command streamer side
15:54 fdobridge_: <k​arolherbst🐧🦀> mhh interesting...
15:54 fdobridge_: <k​arolherbst🐧🦀> nvidia puts a `MOV` between the `LDC` and `LDG`...
15:54 fdobridge_: <k​arolherbst🐧🦀> https://gist.githubusercontent.com/karolherbst/1a4514043ee0f9196e2f43ffc02f017c/raw/ee34737cbbae6d1138484cefe38edd958d924f2f/gistfile1.txt
15:54 fdobridge_: <k​arolherbst🐧🦀> ehh wait
15:54 fdobridge_: <k​arolherbst🐧🦀> could be because of RA
15:55 fdobridge_: <k​arolherbst🐧🦀> yeah.. my bad
15:55 fdobridge_: <k​arolherbst🐧🦀> but it's kinda weird...
15:56 fdobridge_: <k​arolherbst🐧🦀> yeah.. no
15:56 fdobridge_: <k​arolherbst🐧🦀> I didn't mess up
15:56 fdobridge_: <k​arolherbst🐧🦀> nvidia really moves the value from R2..3 to R4..5
15:57 fdobridge_: <k​arolherbst🐧🦀> and funny enough it uses `MOV` _and_`IMAD.MOV` 🙂
15:57 fdobridge_: <k​arolherbst🐧🦀> so I guess that's faster this way
15:59 fdobridge_: <k​arolherbst🐧🦀> ohh
15:59 fdobridge_: <k​arolherbst🐧🦀> I was able to get rid of it
15:59 fdobridge_: <m​henning> @gfxstrand I think we just need to wait another cycle
15:59 fdobridge_: <k​arolherbst🐧🦀> https://gist.githubusercontent.com/karolherbst/717866a0fff3f8e956fce27148614391/raw/e646c035deddb34d30ce2b1bb5d03ba68f1b2437/gistfile1.txt
16:00 fdobridge_: <k​arolherbst🐧🦀> @gfxstrand ^^
16:00 fdobridge_: <k​arolherbst🐧🦀> yeah
16:00 fdobridge_: <k​arolherbst🐧🦀> delay=1 is wrong
16:00 fdobridge_: <k​arolherbst🐧🦀> barrier need at least 2
16:00 fdobridge_: <k​arolherbst🐧🦀> let me check..
16:01 fdobridge_: <m​henning> See `src/nouveau/codegen/nv50_ir_emit_gm107.cpp` line 4026
16:01 fdobridge_: <g​fxstrand> Oh, okay
16:01 fdobridge_: <g​fxstrand> So we need to wait 2 and then barrier
16:02 fdobridge_: <m​henning> Yeah, the barrier isn't valid on the first cycle
16:03 montjoie: hello I have tested nouveau on a GeForce GT 1030 and got a crash https://paste.debian.net/1300973/
16:04 fdobridge_: <k​arolherbst🐧🦀> it's funny that `DEPBAR` has a minimum wait of 4 🙂
16:04 montjoie: If I can do anything to help bring up nouveau on this card...
16:05 fdobridge_: <g​fxstrand> This explains so many things...
16:06 fdobridge_: <k​arolherbst🐧🦀> yeah.. that scoreboarding stuff is all funky
16:06 fdobridge_: <k​arolherbst🐧🦀> predicates also behave different from gprs
16:06 fdobridge_: <k​arolherbst🐧🦀> also .HI/.LO ops
16:07 fdobridge_: <k​arolherbst🐧🦀> HI source are read two cycles later
16:07 fdobridge_: <k​arolherbst🐧🦀> do what you will with that information 😄
16:07 fdobridge_: <k​arolherbst🐧🦀> (and also written two cycles later)
16:08 fdobridge_: <k​arolherbst🐧🦀> ehh.. not .HI/.LO.. I meant .WIDE
16:08 fdobridge_: <k​arolherbst🐧🦀> so `IMAD.WIDE` adds an implicit stall of 2, meaning you can reduce the latency by 2
16:09 fdobridge_: <k​arolherbst🐧🦀> it's all very funky
16:12 fdobridge_: <g​fxstrand> ```
16:12 fdobridge_: <g​fxstrand> block 0 L0 [] -> {
16:12 fdobridge_: <g​fxstrand> r0 = ipa.constant r0 a[0x90] rZ // delay=1 wr:0
16:12 fdobridge_: <g​fxstrand> r1 = mov 0x4 // delay=6
16:12 fdobridge_: <g​fxstrand> r0 = shf.l.w.i32 r0 rZ r1 // delay=6 wt=000001
16:12 fdobridge_: <g​fxstrand> r2 = ldc.b32 c[0x1][r0] // delay=1 rd:0 wr:1
16:12 fdobridge_: <g​fxstrand> r3 = ldc.b32 c[0x1][r0+0x4] // delay=2 rd:2 wr:3
16:12 fdobridge_: <g​fxstrand> r4..8 = ld.global.a64.strong.sys.b128 [r2..4+0x10] // delay=2 wt=001010 rd:1 wr:3
16:12 fdobridge_: <g​fxstrand> r3 = mov r7 // delay=1 wt=001010
16:12 fdobridge_: <g​fxstrand> r2 = mov r6 // delay=1
16:12 fdobridge_: <g​fxstrand> r1 = mov r5 // delay=1
16:12 fdobridge_: <g​fxstrand> r0 = mov r4 // delay=5 wt=000100
16:12 fdobridge_: <g​fxstrand> exit // delay=1 wt=000001
16:12 fdobridge_: <g​fxstrand> } -> []
16:12 fdobridge_: <g​fxstrand> ```
16:13 fdobridge_: <k​arolherbst🐧🦀> did you check the scoreboard of what nvidia generates btw? because I haven't 🙂
16:16 fdobridge_: <g​fxstrand> No
16:17 fdobridge_: <g​fxstrand> I really need to write a python wrapper around the disassembler that dumps out scoreboard info.
16:17 fdobridge_: <k​arolherbst🐧🦀> I kinda hate the scoreboard stuff, but is that even correct?
16:18 fdobridge_: <k​arolherbst🐧🦀> because the ld has to wait on the 1 and 3 barrier
16:20 fdobridge_: <k​arolherbst🐧🦀> btw
16:20 fdobridge_: <k​arolherbst🐧🦀> you can also combine them
16:20 fdobridge_: <!​DodoNVK (she) 🇱🇹> What does scoreboard mean here?
16:20 fdobridge_: <m​henning> I've been using the one here: https://github.com/daadaada/turingas/blob/master/tools/disasm.py
16:20 fdobridge_: <k​arolherbst🐧🦀> so both `ldc` could signal wr:1
16:20 fdobridge_: <k​arolherbst🐧🦀> and then the ld waits on the both
16:21 fdobridge_: <m​henning> wt=001010 is already waiting on the 1 and 3 barrier
16:22 fdobridge_: <k​arolherbst🐧🦀> ohhhhhh
16:22 fdobridge_: <k​arolherbst🐧🦀> duh...
16:22 fdobridge_: <k​arolherbst🐧🦀> yeah.. my bad
16:22 fdobridge_: <k​arolherbst🐧🦀> but
16:22 fdobridge_: <k​arolherbst🐧🦀> anyway
16:22 fdobridge_: <k​arolherbst🐧🦀> you only need to emit one here 😄
16:22 fdobridge_: <k​arolherbst🐧🦀> it's kinda funky, but you could omit the one from the first `ldc`
16:24 fdobridge_: <k​arolherbst🐧🦀> but that's scoreboarding optimization and isn't really important
16:24 fdobridge_: <k​arolherbst🐧🦀> just makes you use less barriers
16:24 fdobridge_: <g​fxstrand> This is from the blob:
16:24 fdobridge_: <g​fxstrand> ```
16:24 fdobridge_: <g​fxstrand> /*0020*/ LDC.64 R4, c[0x2][R4] ; /* 0x0080000004047b82 */
16:24 fdobridge_: <g​fxstrand> /* 0x000e240000000a00 */
16:24 fdobridge_: <g​fxstrand> /*0030*/ LDG.E.128.MMIO.GPU R0, [R4+0x10] ; /* 0x0000100004007381 */
16:24 fdobridge_: <g​fxstrand> /* 0x001fe200001f0d00 */
16:24 fdobridge_: <g​fxstrand> ```
16:24 fdobridge_: <g​fxstrand> The first one is `.yld`, `delay=2`, `wr=1`
16:24 fdobridge_: <g​fxstrand> Second one is `.yld`, `delay=1`, `wt=0b000001`
16:25 fdobridge_: <g​fxstrand> So... basically what I'm doing. 😩
16:26 fdobridge_: <k​arolherbst🐧🦀> yeah.. I couldn't find the spot in the docs I have
16:26 fdobridge_: <g​fxstrand> And, yeah, I'm using too many deps. I need a sort of dep dead-code of sorts.
16:26 fdobridge_: <g​fxstrand> Really, I need to build an actual dependency graph and sort of RA it.
16:26 fdobridge_: <k​arolherbst🐧🦀> I think you can assume stuff finish in order in regards to the units they run on
16:27 fdobridge_: <k​arolherbst🐧🦀> so you can even elimiate waits on deps if you can prove an earlier instruction already fulfilled the req
16:27 fdobridge_: <g​fxstrand> Yeah, I just need to write the code to do that.
16:27 fdobridge_: <k​arolherbst🐧🦀> they use 2 on the ldc tho
16:28 fdobridge_: <g​fxstrand> So do I and it's still failing
16:28 fdobridge_: <k​arolherbst🐧🦀> I have to find the spot it explains the additinoal delay..
16:28 fdobridge_: <k​arolherbst🐧🦀> ohh...
16:28 fdobridge_: <g​fxstrand> Unless I need `delay=2` on both of them.
16:28 fdobridge_: <k​arolherbst🐧🦀> does it work with serial? I guess so?
16:29 fdobridge_: <g​fxstrand> No it doesn't
16:29 fdobridge_: <k​arolherbst🐧🦀> the delay 1 on the first ldc looks kinda weird...
16:30 fdobridge_: <k​arolherbst🐧🦀> also your movs are all weird
16:30 fdobridge_: <k​arolherbst🐧🦀> what is serial doing anyway?
16:31 fdobridge_: <g​fxstrand> Oh, serial hangs...
16:31 fdobridge_: <k​arolherbst🐧🦀> ahh ...
16:32 fdobridge_: <k​arolherbst🐧🦀> btw
16:33 fdobridge_: <k​arolherbst🐧🦀> mhh let me verify I understand the wait thing correctly...
16:36 fdobridge_: <k​arolherbst🐧🦀> okay.. found it
16:37 fdobridge_: <k​arolherbst🐧🦀> WAR hazards from fixed latency write to variable read needs a 2 cycle wait
16:37 fdobridge_: <k​arolherbst🐧🦀> WAW hazard in the same case as well
16:40 fdobridge_: <k​arolherbst🐧🦀> uhh, but that's like for independent stuff and just to ensure things happen in order (and not like a previous instruction writes after a following one)
16:40 fdobridge_: <k​arolherbst🐧🦀> ```
16:40 fdobridge_: <k​arolherbst🐧🦀> r3 = ldc.b32 c[0x1][r0+0x4] // delay=2 rd:2 wr:3
16:40 fdobridge_: <k​arolherbst🐧🦀> r4..8 = ld.global.a64.strong.sys.b128 [r2..4+0x10] // delay=2 wt=001010 rd:1 wr:3
16:40 fdobridge_: <k​arolherbst🐧🦀> r3 = mov r7 // delay=1 wt=001010
16:40 fdobridge_: <k​arolherbst🐧🦀> ```
16:41 fdobridge_: <k​arolherbst🐧🦀>
16:41 fdobridge_: <k​arolherbst🐧🦀> so in theory the mov could happen _before_ the two loads
16:41 fdobridge_: <k​arolherbst🐧🦀> ehh wait
16:41 fdobridge_: <k​arolherbst🐧🦀> only if it has a different source
16:41 fdobridge_: <k​arolherbst🐧🦀> (and doesn't wait on the ld)
16:42 fdobridge_: <k​arolherbst🐧🦀> okay.. but now what about consuming/generating barriers
16:45 fdobridge_: <k​arolherbst🐧🦀> ohh
16:45 fdobridge_: <k​arolherbst🐧🦀> found it
16:46 fdobridge_: <k​arolherbst🐧🦀> @gfxstrand sooo.. the minimum latency between a barrier generator and the first consumer needs to be at least 2
16:49 fdobridge_: <k​arolherbst🐧🦀> but in your output `r3 = mov r7 // delay=1 wt=001010` also is totally weird
16:49 fdobridge_: <k​arolherbst🐧🦀> the following movs also have weird scoreboards
16:50 fdobridge_: <k​arolherbst🐧🦀> also.. nvidia seems to user longer waits with exit, but no idea what that's all about
16:57 fdobridge_: <k​arolherbst🐧🦀> I hate scoreboarding, it was simpler when the hardware did it for us :ferrisUpsideDown:
17:18 fdobridge_: <g​fxstrand> Isn't that what I'm doing?
17:18 fdobridge_: <g​fxstrand> I mean, I think there are some issues with WaR but I think I'm kinda already doing that?!?
17:45 fdobridge_: <k​arolherbst🐧🦀> yeah... from a quick look it kinda looks "okay", just the movs are weird
17:45 fdobridge_: <k​arolherbst🐧🦀> and not sure what the exit is supposed to do there
18:03 fdobridge_: <k​arolherbst🐧🦀> uhh
18:03 fdobridge_: <k​arolherbst🐧🦀> @gfxstrand is that still the current code? because the movs are definetly wrong..
18:05 fdobridge_: <k​arolherbst🐧🦀> but uhh
18:05 fdobridge_: <k​arolherbst🐧🦀> ahhh
18:05 fdobridge_: <k​arolherbst🐧🦀> pain
18:07 fdobridge_: <k​arolherbst🐧🦀> I wonder if the second mov can mess things up.. the `mov r6` one
19:06 montjoie: hello I have tested nouveau on a GeForce GT 1030 and got a crash https://paste.debian.net/1300973/
19:06 montjoie: If I can do anything to help bring up nouveau on this card...
19:19 fdobridge_: <p​avlo_it_115> when and under what circumstances does the failure occur?
19:19 fdobridge_: <p​avlo_it_115> at system startup?
19:27 montjoie: yes just after login when I did a modprobre nouveau
19:28 fdobridge_: <p​avlo_it_115> and why do it? just remove nvidia drivers
19:28 fdobridge_: <p​avlo_it_115> nouveau will pull itself up if it is not in the black list
19:32 montjoie: nvidia driver was not loaded
19:32 fdobridge_: <p​avlo_it_115> what distribution do you have? Debian?
19:33 montjoie: gentoo
19:33 fdobridge_: <p​avlo_it_115> omg
19:33 fdobridge_: <g​fxstrand> Yeah, I'm rewriting my deps pass again. 😅
19:33 fdobridge_: <p​avlo_it_115> Well, I have no experience with Ghent
19:34 fdobridge_: <p​avlo_it_115> and it makes no sense to use nouveau on the pascal architecture.
19:34 fdobridge_: <p​avlo_it_115> it's not worth it
19:34 montjoie: I have problem with nvidia driver, I expected nouveau to fix them
19:35 fdobridge_: <p​avlo_it_115> Which exactly?
19:35 montjoie: I use multiple X display, when switching from one to another, I got black screen freeze for some time before it work again
19:36 DodoGTA: montjole: I think you need linux-firmware
19:38 montjoie: I already have it, some firmware got loaded in the log
19:39 DodoGTA: montjole: I don't see gr being loaded though 🤔️
19:45 montjoie: it seems no firmware is installed, I will retry with them
19:45 montjoie: anyway, nouveau should not crash...
19:49 karolherbst: montjoie: that crash isn't inside nouveau though
19:50 karolherbst: it's more like a warning saying that some developer messed up
19:50 karolherbst: which could have been us though
19:51 montjoie: no other driver was probing at that time so heavy chance of related to nouveau
19:51 karolherbst: could be, but it is still not a crash
19:52 montjoie: anyway, I found also that the gentoo patch for printing loading of firmare is misleading
19:52 karolherbst: and installing firmware is the way to make nouveau load on your machine, fixing that warning doesn't help you in any way
19:52 karolherbst: montjoie: what patch?
19:52 montjoie: the message suggest the loading is successfull, it wasnt but this is unrelated to the problem
19:53 montjoie: it is a gentoo kernel specific
19:53 karolherbst: mhhh
19:53 karolherbst: those messages simply state that a file is being loaded (and found), not that the driver accepted it
19:54 karolherbst: "acr: firmware unavailable" this is kinda concerning, as this indicates something went wrong
19:54 karolherbst: montjoie: are you using an initramfs or module built into the kernel binary?
19:54 montjoie: no initramfs, nouveau is module
19:55 karolherbst: heh.. wait a sceond
19:57 karolherbst: ah no, everything is alright, kinda wondered why I'm missing firmware files on may laptop..
19:57 karolherbst: montjoie: mind sharing the output of `ls /usr/lib/firmware/nvidia/gp108/*/`
19:58 montjoie: I have no nvidia firmware at all
19:58 karolherbst: ohh wait...
19:58 karolherbst: it's 6.1
19:58 karolherbst: montjoie: yeah.. then it won't work
19:59 montjoie: it is why I hate the loading firmware message, I believed to have it but forgot the previous cleaning of unused firmware...
19:59 karolherbst: not using the firmware is unsupported from our end
19:59 montjoie: no problem on that
19:59 montjoie: I will retry with them
20:00 karolherbst: it could be that if only some firmware files are there that the driver ends up in a weird state, which might explain the warning showing up
20:00 montjoie: yeah the screen was stuck after that
20:01 karolherbst: I see
21:13 fdobridge_: <p​homes_> was this caused my patch?
21:21 fdobridge_: <g​fxstrand> It was caused by my first attempt at fixing it. I fixed it harder. 😂
22:09 fdobridge_: <p​avlo_it_115> Officially, the NVK driver supports vulakn 1.1 specifications, but in vulkaninfo I see that vulkan version is 1.3. Part of the functions required for vulkan 1 software (processed on the processor)?
22:09 fdobridge_: <p​avlo_it_115> Officially, the NVK driver supports vulakn 1.1 specifications, but in vulkaninfo I see that vulkan version is 1.3. Part of the functions required for vulkan 1.3 software (processed on the processor)? (edited)
22:10 fdobridge_: <p​avlo_it_115> Is it just a stub to get dxvk etc to work?
22:27 fdobridge_: <a​irlied> are you confusing instance version with driver version?
22:38 fdobridge_: <p​avlo_it_115> Officially, the NVK driver supports vulakn 1.1 specifications, but in vulkaninfo I see that vulkan version is 1.3. Part of the functions required for vulkan 1.3 software processed on the processor? (edited)