00:06 Sid127: :D
00:57 Lyude: haven't had a chance yet to rebase things against the new branch but: just updated and cleaned my current WIP for rvkms a bit: https://gitlab.freedesktop.org/lyudess/linux/-/commits/rvkms
00:58 Lyude: it even has an example of fancy privileged smart pointers for ensuring Sync :)
02:03 fdobridge: <g​fxstrand> @karolherbst What does the predicate source on LOP3 do?
03:32 fdobridge: <g​fxstrand> All this from `uint(subgroupAll(gl_FragCoord.x > 100));`
03:32 fdobridge: <g​fxstrand> https://cdn.discordapp.com/attachments/1034184951790305330/1214415177080901723/message.txt?ex=65f90744&is=65e69244&hm=a9c4b07b776d261734f5133fe327c19756b65f5f1c1b9cb6a3bde4211d31382d&
03:37 fdobridge: <g​fxstrand> Like, why are they doing `(ballot & all) == all`?
03:37 fdobridge: <g​fxstrand> Also, what's with the function calls that never happen?
03:57 fdobridge: <m​henning> yeah, that compiler output is unhinged
03:57 fdobridge: <m​henning> I guess they proved an if condition was always true sometime after their last chance to remove unreachable blocks?
08:17 fdobridge: <S​id> is PTX to NIR actually required or is it something we wanna do
08:17 fdobridge: <S​id> like, is it not possible to pass PTX to the gpu directly?
08:43 fdobridge: <S​id> am just curious
09:22 fdobridge: <b​utterflies> PTX is an intermediate language. You need to compile it to SASS to use it
09:23 fdobridge: <S​id> oh
09:23 fdobridge: <S​id> so how would PTX to NIR work
09:23 fdobridge: <b​utterflies> IR to IR translation
09:23 fdobridge: <b​utterflies> then compilation from NIR to SASS or... even other GPU vendors
09:25 fdobridge: <S​id> so ptx to nir is desirable only if we wanna do cuda/dlss on other vendors
09:26 fdobridge: <S​id> I see
09:26 fdobridge: <b​utterflies> also desirable otherwise to leverage the existing NIR -> SASS compiler in mesa
09:29 fdobridge: <S​id> right, makes sense
09:29 fdobridge: <S​id> less workload
09:42 fdobridge: <k​arolherbst🐧🦀> gets factored into the result via the specified operation
09:43 fdobridge: <k​arolherbst🐧🦀> like.. you can have `.AND`, `.OR`, `.XOR` and `.PASS_B` modifiers
09:44 fdobridge: <k​arolherbst🐧🦀> and there is a destination predicate
09:44 fdobridge: <k​arolherbst🐧🦀> the output pred is the result compared against 0
09:45 fdobridge: <k​arolherbst🐧🦀> and then combined with the input predicate
09:45 fdobridge: <k​arolherbst🐧🦀> according to the mode specified
09:45 fdobridge: <k​arolherbst🐧🦀> ehh wait
09:45 fdobridge: <k​arolherbst🐧🦀> the pred have their own mode
09:46 fdobridge: <k​arolherbst🐧🦀> `.POR` (default) and `.PAND`
09:46 fdobridge: <k​arolherbst🐧🦀> ohhh
09:46 fdobridge: <k​arolherbst🐧🦀> the doc also says when it's useful to use this
09:47 fdobridge: <k​arolherbst🐧🦀> you can use it for bittest
09:47 fdobridge: <k​arolherbst🐧🦀> like... if you only need the result as a pred, it's one `LOP3` operation
09:48 fdobridge: <k​arolherbst🐧🦀> and you know if your bitmask is set
09:48 fdobridge: <k​arolherbst🐧🦀> or whatever/however you check for bits
09:49 fdobridge: <k​arolherbst🐧🦀> e.g. `LOP3.AND.PAND Pa, Rz, Ra, 0x1, PT` would tell you if bit 0 is set
09:49 fdobridge: <k​arolherbst🐧🦀> and the input pred becomes relevant if you do it on e.g. a 64 bit value
09:49 fdobridge: <k​arolherbst🐧🦀> or bigger bitmask
09:50 fdobridge: <k​arolherbst🐧🦀> like.. it would be super useful for `bitset.h` on the GPU 😄
13:50 fdobridge: <!​DodoNVK (she) 🇱🇹> Has anyone looked into implementing VK_NV_raw_access_chains for :triangle_nvk:?
14:09 fdobridge: <z​mike.> I did it
14:09 fdobridge: <z​mike.> I solved stencil fallback.
14:09 fdobridge: <S​id> 👀
14:10 fdobridge: <r​hed0x> and we're all proud of you
14:54 fdobridge: <g​fxstrand> Shouldn't be that hard. It's just a bit of spirv_to_nir work. Also, there's nothing really NV about it.
14:55 fdobridge: <g​fxstrand> Shouldn't be that hard. It's just a bit of spirv_to_nir work. Also, there's nothing really NV about it. We could do it for everyone. (edited)
14:56 fdobridge: <r​hed0x> does HW from other vendors benefit from it?
14:56 fdobridge: <r​hed0x> AMD doesnt
14:56 fdobridge: <r​hed0x> what about intel?
14:59 fdobridge: <k​arolherbst🐧🦀> isn't it mostly a CPU side optimization?
15:01 fdobridge: <g​fxstrand> I think it's mostly to optimize bounds checks
15:01 fdobridge: <k​arolherbst🐧🦀> ohh.. yeah, that might help on nvidia
15:07 fdobridge: <r​hed0x> it adds a spirv extension and a Vulkan feature struct to check support and enable it
15:07 fdobridge: <r​hed0x> it adds a spirv instruction and a Vulkan feature struct to check support and enable it (edited)
15:07 fdobridge: <r​hed0x> thats it
15:07 fdobridge: <k​arolherbst🐧🦀> sure, but if the spir-v is easier to generate/parse
15:09 fdobridge: <r​hed0x> ah thats what you mean
15:10 fdobridge: <z​mike.> hmm I updated my mesa and now I'm getting a ton of `ERROR - dEQP error: glcts: ../src/vulkan/runtime/vk_pipeline.c:1395: vk_graphics_pipeline_compile_shaders: Assertion memcmp(&stage->shader->pipeline.cache_key, &shaders[i]->pipeline.cache_key, sizeof(shaders[i]->pipeline.cache_key)) == 0' failed.`
15:10 fdobridge: <z​mike.> :stressheadache:
15:16 fdobridge: <d​adschoorse> mobile hw with only bda like agx and mali, I guess
15:35 fdobridge:<z​mike.> files a regression ticket
15:38 fdobridge: <z​mike.> somebody did a thinko https://gitlab.freedesktop.org/mesa/mesa/-/issues/10752
15:39 fdobridge: <z​mike.> spoiler: it was @gfxstrand
15:40 fdobridge: <t​riang3l> why derive from `vk_pipeline` in the first place though :frog_gears:
15:41 fdobridge: <g​fxstrand> Okay, I'll try to fix it today. That assert is there for a reason so I expect there's a bug somewhere else that it's catching.
15:42 fdobridge: <z​mike.> I'll revert locally for now
15:51 fdobridge: <k​arolherbst🐧🦀> maybe I'm getting to more VM_BIND development today :ferrisUpsideDown:
15:51 fdobridge: <k​arolherbst🐧🦀> @airlied have you looked into how painful it would be to allow VM_BIND with legacy submission?
15:56 fdobridge: <!​DodoNVK (she) 🇱🇹> I just spotted `OpLdTram` 🚊🚡
16:46 fdobridge: <k​arolherbst🐧🦀> mhhh.. using the new exec also requires to use SYNCOBJ... fun
16:48 fdobridge: <k​arolherbst🐧🦀> could I use syncobj with the old exec ioctl? At least for bo_wait
16:50 fdobridge: <k​arolherbst🐧🦀> I wonder what would happen if I ignore all of it and just submit stuff 😄
17:31 fdobridge: <z​mike.> oooh I got a lot of XPASS today in my piglit run
17:33 fdobridge: <!​DodoNVK (she) 🇱🇹> I did all of this just to get rid of the dead_code statements inside NAK :ferris:
17:33 fdobridge: <!​DodoNVK (she) 🇱🇹> https://cdn.discordapp.com/attachments/1034184951790305330/1214626899834306622/message.diff?ex=65f9cc73&is=65e75773&hm=e378ec1e7799e8e0821d73e730293b17e8ee1ad62de80880e18ca7609b4f4ed8&
17:37 fdobridge: <z​mike.> has anything changed with array texture handling lately?
17:39 fdobridge: <z​mike.> oh I see, it's probably A8
17:46 fdobridge: <!​DodoNVK (she) 🇱🇹> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27991
17:50 fdobridge: <d​adschoorse> removing functional asm code just because it's not used seems wrong to me, but I guess rust knows better
17:53 fdobridge: <k​arolherbst🐧🦀> yeah.. I don't think we should remove any of that...
17:53 fdobridge: <k​arolherbst🐧🦀> well..
17:53 fdobridge: <k​arolherbst🐧🦀> depends
17:54 fdobridge: <k​arolherbst🐧🦀> all the encoding bits should remain
17:55 fdobridge: <!​DodoNVK (she) 🇱🇹> Rust's dead_code strictness says otherwise
17:56 fdobridge: <k​arolherbst🐧🦀> what dead_code strictness?
17:56 fdobridge: <z​mike.> landmark day: nvk is under 1000 total fails across cts+piglit
17:57 fdobridge: <k​arolherbst🐧🦀> those `dead_code` decls are there for a reason...
18:03 fdobridge: <!​DodoNVK (she) 🇱🇹> It considers enum values that are partially used as "dead_code"
18:05 fdobridge: <k​arolherbst🐧🦀> then mark them as such so the compiler doesn't complain?
18:05 fdobridge: <k​arolherbst🐧🦀> can't we just declare the entire enum as such?
18:22 fdobridge: <p​rop_energy_ball> i think we have had the discussion about "cleanups for the sake of cleanups" more than enough
18:23 fdobridge: <p​rop_energy_ball> i am not Faith, but when people do MRs like that to my projects it always ticks me off
18:23 fdobridge: <p​rop_energy_ball> dead code is usually not dead... stuff is usually there for a reason and you just dont know those reasons
18:23 fdobridge: <k​arolherbst🐧🦀> especially if the code is already marked in such a way to disable the compiler warning
18:24 fdobridge: <g​fxstrand> Ugh... I can't repro. 😭
18:25 fdobridge: <z​mike.> `MESA_SHADER_CACHE_DISABLE=1 ZINK_DEBUG=noopt` ?
18:25 fdobridge: <z​mike.> it triggers on practically everything for me
18:25 fdobridge: <z​mike.> with or without env
18:26 fdobridge: <g​fxstrand> I believe you
18:26 fdobridge: <g​fxstrand> Are you on a Zink branch that might affect it?
18:27 fdobridge: <z​mike.> I tested on main
18:31 fdobridge:<z​mike.> always tests on main for vulkan driver bugs
18:32 fdobridge: <t​riang3l> That's what comments are supposed to fix 🙃
18:32 fdobridge: <t​riang3l> That's what comments are supposed to fix 🐸 (edited)
18:33 fdobridge: <g​fxstrand> That's exactly what `#[dead_code]` means, no? It indicates that yes, I know this thing is dead but I want to keep it anyway.
18:33 fdobridge: <g​fxstrand> Do I need to write a book explaining every one of them?
18:33 fdobridge: <z​mike.> focus
18:34 fdobridge: <t​riang3l> I usually write a book explaining every NIR pass invocation 🥵
18:34 fdobridge: <g​fxstrand> I'm very confused. @mhenning said he saw it all over the Vulkan CTS but I'm not seeing it at all.
18:35 fdobridge: <t​riang3l> But nobody else knows _why_ that dead code is actually not dead, that's the issue
18:35 fdobridge: <z​mike.> are YOU on the right branch?
18:35 fdobridge: <!​DodoNVK (she) 🇱🇹> *she
18:35 fdobridge: <t​riang3l> Kind of like leaving `// FIXME: look at git blame and contact the creator on Discord`
18:36 fdobridge: <g​fxstrand> Sorry. Didn't know. I will update my brain.
18:36 fdobridge: <t​riang3l> Kind of like leaving `// FIXME: look at git blame and contact the creator on Discord to ask what's broken` (edited)
18:37 fdobridge: <g​fxstrand> Pretty sure... I've re-built like 3 times now and torched install directories
18:38 fdobridge: <g​fxstrand> @zmike. Are you building with GCC or clang? Also, are you 32 or 64-bit?
18:40 fdobridge: <z​mike.> I unreverted my revert and now I can't repro anymore?
18:40 fdobridge: <z​mike.> and also it no longer triggers on main
18:40 fdobridge: <z​mike.> did you just hack me?
18:40 fdobridge: <z​mike.> have I been pwned?
18:40 fdobridge: <g​fxstrand> No, I swear!
18:40 fdobridge: <g​fxstrand> I hate caches
18:40 fdobridge: <z​mike.> ok good, because that was a test and I'm still getting it
18:40 fdobridge: <g​fxstrand> 😛
18:40 fdobridge: <z​mike.> ```
18:40 fdobridge: <z​mike.> ERROR - dEQP error: glcts: ../src/vulkan/runtime/vk_pipeline.c:1395: vk_graphics_pipeline_compile_shaders: Assertion `memcmp(&stage->shader->pipeline.cache_key, &shaders[i]->pipeline.cache_key, sizeof(shaders[i]->pipeline.cache_key)) == 0' failed.
18:40 fdobridge: <z​mike.> ERROR - Test dEQP-GLES31.functional.separate_shader.interface.same_location_vertex_smooth_fragment_smooth: Crash: See "new-run-nvk/c11.r2.log"
18:40 fdobridge: <z​mike.> ```
18:41 fdobridge: <z​mike.> maybe caselist...
18:41 fdobridge: <g​fxstrand> Yeah, can you repro with one test is the next question
18:42 fdobridge: <z​mike.> great news
18:42 fdobridge: <z​mike.> I can't repro with a single test or the caselist
18:42 fdobridge: <z​mike.> but any time I run cts I get spammed by a billion crashes
18:42 fdobridge: <g​fxstrand> Dr
18:42 fdobridge: <g​fxstrand> Ugh... I found it. 🙄 (edited)
18:43 fdobridge: <z​mike.> I knew you would
18:46 fdobridge: <z​mike.> @airlied is this week gonna be the week that insane stack smashing thing gets fixed?
18:52 fdobridge: <z​mike.> ugh my piglit was out of date and I think that's gonna result in a lot of passes when I do another run
18:52 fdobridge: <g​fxstrand> Read the comment on compile(). The driver is expected to consume the NIR, regardless of whether or not the compile succeeds.
18:53 fdobridge: <g​fxstrand> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27993
18:55 fdobridge: <z​mike.> testing
18:56 fdobridge: <z​mike.> yeah lgtm
19:00 fdobridge: <z​mike.> @gfxstrand while you're on gitlab maybe you want to ack my nvk MR
19:06 fdobridge: <t​riang3l> Oh, yes, I've just checked it for the second time, and yeah, that `ralloc_free` in `vk_common_CreateShadersEXT` is called only for `vk_shader_to_nir` failures, while the `op->compile` and the `ralloc_free` are in separate if/else branches
20:30 HdkR: Is there a minimum rustc version for nvk? I'm getting a bunch of "cannot find function in this scope" errors
20:31 HdkR: "unresolved import 'nak_bindings'" at the start
20:32 fdobridge: <g​fxstrand> Odd
20:32 fdobridge: <g​fxstrand> There is but meson should be checking and failing on you if you don't have it
20:33 DodoGTA: HdkR: Does this only happen with 32-bit build?
20:33 fdobridge: <g​fxstrand> Oh, yeah, 32-bit builds are a whole thing
20:33 HdkR: I'm only building AArch64
20:33 fdobridge: <g​fxstrand> Cross-builds in general are
20:33 fdobridge: <g​fxstrand> They work but the failure modes are... odd.
20:33 DodoGTA: HdkR: Do you have bindgen installed?
20:34 fdobridge: <g​fxstrand> You need to have rustc and rust flags in your cross file
20:34 HdkR: I'm not cross compiling
20:34 HdkR: Looks like bindgen is installed
20:34 fdobridge: <g​fxstrand> Here's my x86 cross file
20:34 fdobridge: <g​fxstrand> https://cdn.discordapp.com/attachments/1034184951790305330/1214672431776669708/x86.cross?ex=65f9f6db&is=65e781db&hm=dfdfc93fa15593731af8e340438b08c696a8326cb02e1b4e049fd7dd528b2af7&
20:34 fdobridge: <g​fxstrand> Are you doing a 32-bit build on a 64-bit system?
20:34 HdkR: I'm building AArch64 on an AArch64 system.
20:35 DodoGTA: HdkR: Can you run `which bindgen`?
20:35 fdobridge: <g​fxstrand> Hrm...
20:35 HdkR: ryanh@buildbot-orin-2:mesa$ which bindgen
20:35 HdkR: /usr/bin/bindgen
20:35 fdobridge: <g​fxstrand> It's possible bindgen is falling over, something to do with AArch64 ABI
20:35 HdkR: `bindgen 0.59.1`
20:35 fdobridge: <g​fxstrand> Can you `2> err` and pastebin the whole thing?
20:39 HdkR: ...Deleted the build directory and it seems fine now
20:40 DodoGTA: HdkR: I think I encountered that with the Rust compiler merge (after deleting it I had no more issues like that)
20:46 HdkR: built, so yea just a stale build folder causing weirdness
20:48 HdkR: GPU id : 0 (AD104):
20:48 HdkR: GL_RENDERER: NV194
20:48 HdkR: nice
20:50 HdkR: Now I need to build x86 and x86-64 versions
20:54 fdobridge: <m​ohamexiety> HdkR: try wiping and starting from a fresh build directory. I don't know why but meson on first build always does something weird and the rust stuff always fails
21:01 fdobridge: <g​fxstrand> "Hangs pretty hard"... Okay, I'll not try that one on the laptop, then. 😂
21:06 fdobridge: <a​irlied> @zmike was hoping the pipeline cache fix was you discovering it, but not just a regression 🙂
21:07 fdobridge: <a​irlied> I've just walked off a 14hr tin can, so it seems unlikely I'll recover enough this week for much success
21:09 fdobridge: <m​ohamexiety> oof. hope you a good recovery!
21:14 HdkR: gah, of course Ubuntu Jammy didn't build llvmspirvlib for i386 but they fixed it in mantic
21:31 fdobridge: <!​DodoNVK (she) 🇱🇹> What is a tin can?
21:34 fdobridge: <!​DodoNVK (she) 🇱🇹> I recently updated the MR
21:37 fdobridge: <g​fxstrand> I assume an airplane
21:37 fdobridge: <g​fxstrand> I assume an airplane ✈️ (edited)
21:38 fdobridge: <k​arolherbst🐧🦀> @asdqueerfromeu if you want to do some more serious cleanup, there are still a couple of clippy warnings around, which usually lead to better and more readable code once fixed
21:38 fdobridge: <k​arolherbst🐧🦀> but also need to be careful, because some things are violated on purpose
21:46 HdkR: This i386 rust cross-compiling is definitely spicy
21:48 fdobridge: <g​fxstrand> Just wait until someone tries to build it for s390
21:51 fdobridge: <!​DodoNVK (she) 🇱🇹> There are longer flights than that actually
21:52 fdobridge: <!​DodoNVK (she) 🇱🇹> Does that hardware have PCIe support?
21:52 fdobridge: <g​fxstrand> I don't know
21:54 HdkR: @gfxstrand: In your cross file, is cc and c++ clang or gcc?
21:55 fdobridge: <g​fxstrand> gcc
21:56 HdkR: hmm
22:03 HdkR: Looks like I got it, now to make sure my rootfs build script can handle it
22:32 HdkR: oop, looks like I'm missing some nouveau ioctls
22:37 HdkR: What is NR 0x47...?
22:38 HdkR: Oh right, DRM base + 7
22:40 HdkR: Here's hoping NVIF is arch agnostic since the linux header doesn't declare the layout of the operation
22:40 karolherbst: the uapi headers are lacking stuff
22:42 HdkR: Looks like only NVIF and the deprecated commands I don't have described
22:45 HdkR: If it doesn't do a compat_ioctl check or operating mode check then it'll probably be fine
22:46 fdobridge: <g​fxstrand> Okay, this makes no sense whatsoever...
22:46 fdobridge: <g​fxstrand> `dEQP-VK.subgroups.vote.graphics.subgroupallequal_int8_t` passes
22:46 fdobridge: <g​fxstrand> `dEQP-VK.subgroups.vote.graphics.subgroupallequal_int16_t` fails
22:47 fdobridge: <g​fxstrand> The shaders are identical besides a single `shf` in the int16 version and the `prmt` instructions to cast things to/from 8 or 16-bit
22:47 fdobridge: <g​fxstrand> They even use the same register assignments
22:47 fdobridge: <g​fxstrand> How?!?!?!?
23:03 fdobridge: <!​DodoNVK (she) 🇱🇹> Is allocating memory inside the /dev/dri/render* memory space normal?
23:03 fdobridge: <g​fxstrand> What do you mean?
23:05 HdkR: Nice. Looks like vendorID/deviceID needs to be hidden otherwise Proton tries enabling NVAPI
23:06 fdobridge: <!​DodoNVK (she) 🇱🇹> I'm trying to debug the Vita3K segfault again (it's still present with the latest NVK/Vita3K versions)
23:06 fdobridge: <g​fxstrand> 🤡
23:06 fdobridge: <g​fxstrand> Proton should know better...
23:06 fdobridge: <g​fxstrand> We have driverID for a reason, folks.
23:06 fdobridge: <g​fxstrand> And it's been around for a long time
23:06 fdobridge: <S​id> I'll poke some proton guys about that
23:11 Sid127: HdkR: is there any specific game where that's causing issues? for testing purposes, and to tell jens (the dxvk-nvapi guy)
23:12 HdkR: Sid127: GoW 2018
23:12 HdkR: https://cdn.discordapp.com/attachments/765304672579092511/1214712004460290098/Screenshot_2024-03-05_15-11-37.png?ex=65fa1bb6&is=65e7a6b6&hm=f316dcba059755474e1b721509360ced5b19c301bf890bcbcd154ce2cc69dd02&
23:12 HdkR: It works though
23:12 Sid127: hm, what issue does it cause? sadly don't have gow'18
23:12 HdkR: No audio through the displayport cables sadly
23:13 Sid127: am just talking to some proton folks about potentially switching to using driverID for enabling nvapi
23:13 HdkR: Sid127: A bunch of spam about "NvAPI_QueryInterface (0xad298d3f): Unknown function ID" and then a hang
23:14 Sid127: thanks <3
23:14 fdobridge: <g​fxstrand> HdkR: So, I take it NVK works on Arm, then?
23:14 Sid127: that is through steam, right?
23:14 HdkR: Sid127: Yea, this was the Steam release of the game
23:15 HdkR: @gfxstrand: Yep, that is DXVK+NVK
23:15 HdkR: On Orin of course
23:16 HdkR: Do I need a specific kernel option for DP/HDMI audio, or is that known not working atm?
23:18 Sid127: HdkR: by any chance, was the display not plugged in at boot
23:18 HdkR: I switched to a different panel while running if that counts
23:19 Sid127: hm, I know for a fact there's a bug in snd_hda_intel, but that shouldn't break hdmi audio...
23:19 HdkR: It's also DP->HDMI if that matters
23:19 Sid127: also about GoW: do you have DXVK_NVAPI_ALLOW_OTHER_DRIVERS=1 in your env by any chance?
23:20 HdkR: I don't have that environment variable set
23:20 HdkR: I doubt Steam set it
23:20 Sid127: also a PROTON_LOG=1 from GoW would be helpful
23:21 Sid127: sadly I dunno much about dp/hdmi audio, I do know there's a bug in snd_hda_intel that keeps the audio controller on the gpu active if it fails to initialize (no display plugged in at boot) and that prevents suspend/resume from working
23:21 fdobridge: <r​edsheep> HdkR: I know several people are also unable to get DP audio, myself included. I have not been replugging the panel after boot, and it is not being converted to HDMI.
23:22 fdobridge: <r​edsheep> Also I have no intel audio hardware so it isn't caused by that
23:23 Sid127: @redsheep snd_hda_intel is not vendor specific
23:23 HdkR: legacy name
23:23 Sid127: https://www.kernel.org/doc/html/v6.7/sound/hd-audio/notes.html
23:24 fdobridge: <r​edsheep> Oh weird, ok nevermind then.
23:24 HdkR: Since obviously this ARM dev board also doesn't have any Intel bits in it :P
23:24 fdobridge: <r​edsheep> Fair
23:26 Sid127: HdkR: what proton version were you on?
23:26 HdkR: 9.0-201
23:27 Sid127: okie, thanks
23:27 Sid127: if you could send a proton log over that'd be great too :>
23:27 HdkR: Yea, letting it eat through the vulkan shaders so it stops eating my CPU cores
23:28 Sid127: wait, 9.0-201?
23:28 Sid127: is this a custom build?
23:28 HdkR: I assume it is Proton Experimental
23:28 Sid127: could you check please :3
23:28 Sid127: the little info icon on the game page
23:28 Sid127: in your library
23:28 Sid127: between settings and the favorites icon
23:29 HdkR: Yea, it's on experimental
23:29 Sid127: thank
23:31 HdkR: Wait a minute, this time it didn't complain
23:31 HdkR: Unless PROTON_LOG redirects it?
23:31 Sid127: possibly, I wouldn't know..
23:32 HdkR: Oh yea, it redirected to the log in $HOME
23:32 Sid127: still hits the hang?
23:32 HdkR: yea
23:32 HdkR: Although also maybe this hang is a DXVK+NVK problem
23:33 Sid127: possibly
23:33 Sid127: you could try running it with wined3d's vulkan backend
23:33 Sid127: PROTON_USE_WINED3D=1 WINE_D3D_CONFIG="renderer=vulkan"
23:34 HdkR: https://gist.github.com/Sonicadvance1/219eb4a350a8ad63eab969fa5dc45244 There's the GoW proton log
23:34 Sid127: thanks!
23:36 Sid127: but yeah, I'd try with wined3d's vulkan renderer too
23:36 Sid127: it's generally friendlier to a less developed driver
23:38 HdkR: Looks like it still hung. Interesting
23:39 Sid127: does dmesg have anything?
23:39 Sid127: channel killed, perhaps?
23:39 HdkR: nope, nothing new showing up in there
23:39 Sid127: also, you could set PROTON_DISABLE_NVAPI=1 to force disable it
23:39 Sid127: just to see what happens
23:39 HdkR: ah, good idea
23:41 fdobridge: <S​id> @gfxstrand mind if I bring up a weird prime/nvk/zink thing?
23:42 fdobridge: <S​id> right now, setting `DRI_PRIME=pci-0000_01_00_0 NOUVEAU_USE_ZINK=1` on a prime set up does not make nouveau use zink
23:42 fdobridge: <S​id> however `DRI_PRIME=pci-0000_01_00_0 __GLX_VENDOR_LIBRARY_NAME=mesa MESA_LOADER_DRIVER_OVERRIDE=zink GALLIUM_DRIVER=zink` does
23:43 fdobridge: <g​fxstrand> That's one for @airlied, I think.
23:43 fdobridge: <S​id> right, sorry 😅
23:43 fdobridge: <g​fxstrand> No worries.
23:43 fdobridge: <g​fxstrand> Given that he's thoroughly jetlagged, maybe just file a bug and tag him for now.
23:44 fdobridge: <S​id> will do, mesa/mesa, yeah?
23:44 HdkR: Well then, looks like disabling NVAPI doesn't solve the hang
23:44 Sid127: likely driver issue then, if it's happening on damavand too
23:44 Sid127: it's possible we're getting stuck on compiling a shader
23:44 Sid127: I know that's what's happening on elite dangerous
23:45 HdkR: Going to restart the device to see if DP audio is fixed
23:46 HdkR: Without replugging the monitor of course
23:47 fdobridge: <k​arolherbst🐧🦀> is there a nice little tldr on how all the modern `VM_BIND` and `SYNC_OBJ` is supposed to work or do I have to figure that out from reading code? Though I think more pressing is to know what implications it has on the gl driver actually as this all feels more involved than I anticipated
23:49 fdobridge: <g​fxstrand> @marysaka where did you write down all those SPH bits you found?
23:49 HdkR: Pulseaudio seems to think it is sending audio to the correct device but nothing comes out the other end. So that's interesting
23:49 fdobridge: <r​edsheep> Right there's a device for it but just no sound. And since 27993 just merged it might make sense to recompile and retest the crashing game, if it was a shader
23:50 fdobridge: <S​id> hm, should retest elite dangerous myself too...
23:51 fdobridge: <S​id> ugh, grub
23:51 fdobridge: <S​id> why must you be like this
23:51 fdobridge: <m​arysaka> I think I have some md file somewhere, let me see (converted the html doc from NVIDIA and added new stuffs to it directly)
23:52 karolherbst: Lyude: I think I'm kinda in the mood of implementing HDMI 2.1 stuff in nouveau 🙃 I mean.. how hard could it be
23:53 fdobridge: <g​fxstrand> Damn... I was hoping that bit 611 would help but no
23:53 fdobridge: <m​arysaka> oh well...
23:54 Sid127: narrator: little did karolherbst know, it was very hard
23:54 karolherbst: when did that ever stop me
23:54 Sid127: just messing with ya~
23:54 Sid127: has !27927 been merged?
23:55 Sid127: out of range exception thingy