08:41 fdobridge: <t​riang3l> And it runs Red Dead Redemption 2
08:45 magic_rb: Ill test all the games i have to see if they run, though i cant connect to my nas over ethernet, 6.7 broke my ethernet dongle...
16:35 fdobridge: <g​fxstrand> Yay! @marysaka helped me figure out what was going wrong with my OOR addr patch.
16:36 fdobridge: <g​fxstrand> I'm CTSing the updated MR now and will land it later if everything looks good
16:36 fdobridge: <g​fxstrand> There are some other bits we probably want to set as well but I'll leave those for another MR so people can test them independent of the OOR addr bit.
17:06 fdobridge: <J​oshie with Max-Q Design> Nicee
17:06 Sid127: @prop_energy_ball could you resend that dmesg snippet from the other day thank you
17:07 fdobridge: <J​oshie with Max-Q Design> https://cdn.discordapp.com/attachments/1034184951790305330/1215826350913355946/message.txt?ex=65fe2987&is=65ebb487&hm=e6d7384fd59f296310d7c1a60e1e97ed01c077e4f498c61f8feddb1c27eabb33&
17:08 Sid127: thanks
17:09 Sid127: stock arch 6.7.9, right?
17:15 fdobridge: <J​oshie with Max-Q Design> Yea
17:16 Sid127: compiling unstripped arch 6.7.9, should have some info for the source of that issue in ~1h
17:19 fdobridge: <!​DodoNVK (she) 🇱🇹> GTA San Andreas has frametime issues even with the frametime trick 🤔
17:19 fdobridge: <!​DodoNVK (she) 🇱🇹> https://cdn.discordapp.com/attachments/1034184951790305330/1216435174892376185/Screenshot_20240310_190513.png?ex=66006089&is=65edeb89&hm=5671b8e6973901712f5b69699f5e9290a7497a555516660e27896b667312408b&
17:20 Sid127: what's the frametime tick
17:21 Sid127: s/tick/trick
17:22 Sid127: also, am dumb, I could just compile nouveau instead of the whole kernel
17:24 Sid127: let's see...
17:25 DodoGTA: Sid127: `d3d9.maxFrameLatency = 1`
17:41 Sid127: huh
17:57 fdobridge: <g​fxstrand> PSA: The OOR address fix has been merged. That should sort out the Zink bug (I need to go close the issue). I opened a new MR which disables a couple more exceptions: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28096
17:58 fdobridge: <g​fxstrand> This is likely to fix more app bugs. Please test.
17:58 Sid127: I'll test it in a couple days
17:59 Sid127: if that's okay
18:53 fdobridge: <J​oshie with Max-Q Design> Lyuude: How usable is Nova rn? At some point I'd be interested in looking into hooking up HDR stuff for nouveau/nova, and wondering if I should wait for nova or what have you.
18:54 fdobridge: <J​oshie with Max-Q Design> Saw the post about it from a while ago
19:33 fdobridge: <t​om3026> just curious where is the fault in hitting all these exceptions, driver, gpu, games? feels like even if exceptions is turned on it shouldnt trigger why do they have them otherwise
19:33 fdobridge: <g​fxstrand> Probably the game
19:33 fdobridge: <g​fxstrand> The CTS passes with all the exceptions enabled
19:33 fdobridge: <t​om3026> or are they merely driver "behind closed door" CTS testing to see if they are still working, but games are bonanza and breaks all logic
19:34 fdobridge: <t​om3026> yeah okay
19:40 fdobridge: <t​om3026> would it be worth having an env var to turn them back on running the CTS tests when more and more extensions are added?
19:40 fdobridge: <g​fxstrand> I think so
19:41 fdobridge: <g​fxstrand> Yeah, probably.
19:42 fdobridge: <g​fxstrand> I'm not quite sure how I want that to work, though. Maybe an `NVK_DISABLE_SHADER_EXCEPTIONS` that takes a comma separated list?
19:43 fdobridge: <t​om3026> either enable or disable, but seems the current approach is games are broken, disable by default heh
19:45 fdobridge: <t​om3026> and if you ask me most users wouldnt know what the comma seperated list would mean, OOR, OOB stack etc. but perhaps is useful to pin point CTS errors
19:45 fdobridge: <g​fxstrand> Yeah, I think we want a set of defaults.
19:45 fdobridge: <t​om3026> so for bug bisecting comma list, for users? no idea. hide it 😄
19:46 fdobridge: <g​fxstrand> We could also make the list have +foo/-foo to adjust things either direction.
19:46 fdobridge: <t​om3026> oh true
19:46 fdobridge: <t​om3026> like WINEDEBUG pretty much
19:48 fdobridge: <t​om3026> im just throwing out ideas, if they dont make sense just ignore them ❤️
19:54 fdobridge: <g​fxstrand> Nah, it's a good idea. I was thinking about it some too. I was just more focused on fixing that bug than coming up with clever environment variables. 🤷🏻‍♀️
20:21 fdobridge: <a​irlied> @prop_energy_ball nova isn't code yet in any meaningful way
20:21 fdobridge: <J​oshie with Max-Q Design> Gotcha
20:27 fdobridge: <e​sdrastarsis> The driver only has firmware loading support atm iirc
20:33 fdobridge: <a​irlied> Doesn't even do that
20:41 fdobridge: <a​irlied> the initial work has mostly been on how to make rust drm drivers viable
20:52 fdobridge: <S​id> @prop_energy_ball well, I now know your VM issue is caused by some ACPI related jank
20:52 fdobridge: <S​id> https://discord.com/channels/1033216351990456371/1033216738050969670/1216488268682498098
20:52 fdobridge: <S​id> I still don't have full access to my disks, so I'll poke around further later
20:56 fdobridge: <a​irlied> @prop_energy_ball that backtrace should be non-fatal
20:57 fdobridge: <S​id> yeah, it's a warning
20:57 fdobridge: <S​id> but apparently it breaks gfx
20:57 fdobridge: <a​irlied> No something else breaks I'd guess not that
20:58 fdobridge: <S​id> confusing (partly because I'm not well versed with nouveau kmod yet)
20:59 fdobridge: <S​id> man, if I knew about faddr2line before
21:00 fdobridge: <S​id> I wouldn't have had to bisect that issue :frog_gears:
21:06 fdobridge: <S​id> actually, I wonder..
21:08 fdobridge: <S​id> I wonder if it's because 6.7.9 doesn't have all drm/nouveau patches yet
21:10 fdobridge: <a​irlied> Depends on what problem he is seeing. Since the backtraces is not the problem
21:11 fdobridge: <S​id> yeah, we'll have to wait for more info
21:11 fdobridge: <S​id> ideally a full dmesg
21:30 fdobridge: <p​homes_> with main X4 Foundations works (with the driconf to fake vendor ID). With the patches in 28096 BG3 still fails but now with:
21:30 fdobridge: <p​homes_> Xwayland[10631]: nv50cal_space: -16
21:30 fdobridge: <p​homes_> bg3.exe[25036]: job timeout, channel 112 killed!
22:00 fdobridge: <t​riang3l> Level 1 troll from Russia: writes a ~~request~~ shitpost to have a driver compiled for XP 64.
22:00 fdobridge: <t​riang3l> Level desyatichok^-tselkovyi leshiy from the land of Modern Ruses:
22:00 fdobridge: <t​riang3l> https://cdn.discordapp.com/attachments/1034184951790305330/1216506039759798352/20240310_230220.jpg?ex=6600a289&is=65ee2d89&hm=a556098067b202df713cdbff711d7533d3c10b3a351cdd4a98ab2cb77b40f7c3&
22:17 fdobridge: <S​id> i'm confused
22:50 fdobridge: <t​riang3l> Intercepting NtGdiDdDDICreateContext and NtGdiDdDDIRender 👀 (on TeraScale 🫄)
23:04 fdobridge: <J​oshie with Max-Q Design> please do not talk about that here
23:07 fdobridge: <k​arolherbst🐧🦀> @triang3l yeah.. we have a few developers here working on wine/proton/whatever and those projects are _super_ strict about being tainted by any kind of leaked source code or decompiling/disassembling of any win binaries
23:07 fdobridge: <k​arolherbst🐧🦀> so we really can't have any of that here
23:08 fdobridge: <k​arolherbst🐧🦀> black box reverse engineering is fine, right?
23:08 fdobridge: <J​oshie with Max-Q Design> Cleanroom is fine
23:09 fdobridge: <k​arolherbst🐧🦀> ahh right.. cleanroom was the term :ferrisUpsideDown:
23:09 fdobridge: <J​oshie with Max-Q Design> I also don't care what Triangle does for his driver, as long as there is nothing Windows posted here
23:09 fdobridge: <J​oshie with Max-Q Design> The includes reverse engineering MS code or driver code
23:09 fdobridge: <J​oshie with Max-Q Design> The includes disassembling MS code or driver code directly (edited)
23:09 fdobridge: <t​riang3l> Ah, okay, those are user APIs documented on MSDN (as D3DKMT* functions, which are redirected to them), and they're used largely for passing GPU-vendor-specific data
23:10 fdobridge: <k​arolherbst🐧🦀> not sure what the situation is with documents acquired under such circumstances
23:10 fdobridge: <k​arolherbst🐧🦀> but I think people generally are very careful in this regard for obvious reasons
23:10 fdobridge: <t​riang3l> https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/d3dkmthk/nf-d3dkmthk-d3dkmtrender 🙃
23:12 fdobridge: <t​riang3l> But yes, UAPI details aren't something that's openly documented by vendors, so yeah
23:12 fdobridge: <k​arolherbst🐧🦀> yeah.. I think linking/looking at those is fine
23:12 fdobridge: <k​arolherbst🐧🦀> yeah...
23:12 fdobridge: <t​riang3l> But yes, UAPI details like relocation slot IDs and command buffers aren't something that's openly documented by vendors, so yeah (edited)
23:13 fdobridge: <t​riang3l> But yes, UAPI details like relocation slot IDs and command buffers aren't something that's openly documented by vendors, so maybe (edited)
23:13 fdobridge: <b​utterflies> Intel's Windows UAPI is public
23:14 fdobridge: <b​utterflies> to the extent that it's used by `compute-runtime`
23:14 fdobridge: <b​utterflies> (because compute-runtime is officially supported for compilation on Windows and WSL2 environments outside of Intel)
23:15 fdobridge: <b​utterflies> D3DKMT* headers are also available as an OSS licensed variant - see `include/uapi/misc/d3dkmthk.h` in the WSL kernel trees.
23:19 fdobridge: <b​utterflies> also available in the Mesa source tree for the WSL bits, see `include/drm-uapi/d3dkmthk.h`
23:20 fdobridge: <k​arolherbst🐧🦀> windows should just change their license and allow any kind of reverse engineering for running shit on other OS'
23:21 magic_rb: That would make windows completely absolete, which is a good thing i admit
23:22 magic_rb: *obsolete, spelling is hard