00:02fdobridge_: <airlied> it appears I should have a 2070, will go look
00:07fdobridge_: <airlied> okay seems to happen here, guess that sorts out today's plan 😛
00:08fdobridge_: <prop_energy_ball> 🙏
01:00fdobridge_: <airlied> seems there are some nvdec engines with no nonstall irqs
01:21fdobridge_: <airlied> okay tu106 patch on the list and attached to the issue
01:21fdobridge_: <airlied> appreciate testing
01:26sneil: I'm the person who filed #283, I'll try to build a 6.7 final with the patch tonight
02:42fdobridge_: <prop_energy_ball> Yoooooooooooooooooo
02:43fdobridge_: <prop_energy_ball> I'll test that
03:38sneil: Looks like the patch works for me and one other person
03:38sneil: Thanks!
03:39airlied: yay win, welcome to gsp land :-P
04:42fdobridge_: <Sid> I too have a RIP on module load apparently
04:42fdobridge_: <Sid> am I one of the cool kids now :D
04:42fdobridge_: <Sid> https://paste.sidonthe.net/raw/snail-horse-rabbit
04:42fdobridge_: <airlied> nope not the same one
04:44fdobridge_: <Sid> also I've got a trace that runs successfully on proprietary driver and non-gsp but leads to job timeouts on gsp
04:44fdobridge_: <Sid> https://drive.google.com/file/d/1b4QMaQo2nAXIfPcZur98NfuRndlS_zt5/view
04:45fdobridge_: <airlied> that backtrace suggests running out of ram maybe\
04:45fdobridge_: <Sid> I've got 24 gigs of ram and 6 gigs vram though
04:51fdobridge_: <airlied> what is mm/page_alloc.c:2898 in your source?
04:52fdobridge_: <airlied> might also be bcachefs related
04:52fdobridge_: <airlied> actually seems pretty likely to be bcachefs bug
04:54fdobridge_: <Sid> `WARN_ON_ONCE((gfp_flags & __GFP_NOFAIL) && (order > 1));`
04:54fdobridge_: <Sid> ```
04:54fdobridge_: <Sid> /*
04:54fdobridge_: <Sid> * Do not instrument rmqueue() with KMSAN. This function may call
04:54fdobridge_: <Sid> * __msan_poison_alloca() through a call to set_pfnblock_flags_mask().
04:54fdobridge_: <Sid> * If __msan_poison_alloca() attempts to allocate pages for the stack depot, it
04:54fdobridge_: <Sid> * may call rmqueue() again, which will result in a deadlock.
04:54fdobridge_: <Sid> */
04:54fdobridge_: <Sid> __no_sanitize_memory
04:54fdobridge_: <Sid> static inline
04:54fdobridge_: <Sid> struct page *rmqueue(struct zone *preferred_zone,
04:54fdobridge_: <Sid> struct zone *zone, unsigned int order,
04:54fdobridge_: <Sid> gfp_t gfp_flags, unsigned int alloc_flags,
04:54fdobridge_: <Sid> int migratetype)
04:55fdobridge_: <Sid> {
04:55fdobridge_: <Sid> struct page *page;
04:55fdobridge_: <Sid>
04:55fdobridge_: <Sid> /*
04:55fdobridge_: <Sid> * We most definitely don't want callers attempting to
04:55fdobridge_: <Sid> * allocate greater than order-1 page units with __GFP_NOFAIL.
04:55fdobridge_: <Sid> */
04:55fdobridge_: <Sid> WARN_ON_ONCE((gfp_flags & __GFP_NOFAIL) && (order > 1));
04:55fdobridge_: <Sid>
04:55fdobridge_: <Sid> if (likely(pcp_allowed_order(order))) {
04:55fdobridge_: <Sid> page = rmqueue_pcplist(preferred_zone, zone, order,
04:55fdobridge_: <Sid> migratetype, alloc_flags);
04:55fdobridge_: <Sid> if (likely(page))
04:55fdobridge_: <Sid> goto out;
04:55fdobridge_: <Sid> }
04:55fdobridge_: <Sid>
04:55fdobridge_: <Sid> page = rmqueue_buddy(preferred_zone, zone, order, alloc_flags,
04:55fdobridge_: <Sid> migratetype);
04:55fdobridge_: <airlied> yeah likely bcachefs not nouveau
04:55fdobridge_: <Sid> alrighty, I'll go report it there then, sorry!
04:59fdobridge_: <Sid> rebuilding nvk before I grab logs from there
04:59fdobridge_: <Sid> i.e. job timeout stuff
05:07fdobridge_: <Sid> is there a way to increase the verbosity of the nouveau kernel module?
05:10fdobridge_: <Sid> because right now all it's putting out is
05:10fdobridge_: <Sid> `[Wed Jan 10 10:39:45 2024] nouveau 0000:01:00.0: Metal.exe[44014]: job timeout, channel 16 killed!`
05:11fdobridge_: <Sid> however now only render fails, the app doesn't freeze entirely
05:12fdobridge_: <airlied> that is all the info the driver has I think
05:12Sid127: I'm also able to navigate the menus, get in game, and actually play it (based on audio output)
05:12Sid127: however, all that's rendered is a black screen ^^'
05:14Sid127: I'll test out more things and see if I get any application freezes with relevant kernel logs
05:15Sid127: if not it's likely a userspace issue
05:40Sid127: ok yeah it's partly userspace, those job timeouts I'm having seem to arise from how NVK interacts with DXVK 2.3, because I just tried DXVK 1.10.3 and it does fix some issues
05:41Sid127: however I also have something interesting now
05:41Sid127: https://paste.sidonthe.net/raw/fish-sloth-monkey
05:42Sid127: I think faith had a similar thing when running CTS a couple days ago
05:59fdobridge_: <prop_energy_ball> @airlied Unfortunately still does not work for me
06:00fdobridge_: <prop_energy_ball> `[ 2.990827] WARNING: CPU: 27 PID: 580 at drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c:1156 r535_gsp_oneinit+0x123c/0x1260 [nouveau]`
06:01fdobridge_: <prop_energy_ball> Full patch here https://gitlab.freedesktop.org/drm/nouveau/-/issues/283#note_2232668
06:04fdobridge_: <prop_energy_ball> Looks like I am hitting this:
06:04fdobridge_: <prop_energy_ball> ```
06:04fdobridge_: <prop_energy_ball> if (WARN_ON(obj->type != ACPI_TYPE_BUFFER) ||
06:04fdobridge_: <prop_energy_ball> WARN_ON(obj->buffer.length != 4))
06:04fdobridge_: <prop_energy_ball> return;
06:04fdobridge_: <prop_energy_ball>
06:04fdobridge_: <prop_energy_ball> ```
06:05fdobridge_: <prop_energy_ball> I am guessing my problem is likely getting further, but something is weird about me
06:05fdobridge_: <prop_energy_ball> I am guessing I am getting further but hitting another issue (edited)
06:09fdobridge_: <prop_energy_ball> Lemme make sure my stuff actually applied
06:10fdobridge_: <prop_energy_ball> yeah kernel has the patch
06:12fdobridge_: <prop_energy_ball> Full BUG here https://gitlab.freedesktop.org/drm/nouveau/-/issues/283#note_2232668 (edited)
06:15ilgaz: People: I may have found the strangest freedesktop driver issue ever. I am actually pretty tired of my distro and its maintainers. If I install Fedora current stable and manage to reproduce the same thing (not security related) should I report it to Fedora first or directly to freedesktop gitlab?
07:33fdobridge_: <prop_energy_ball> Ok, got it working, turns out it was unrelated to that WARN
08:02fdobridge_: <tom3026> @asdqueerfromeu pipeline shader cache has been merged the aur pkgbuilds needs a update :p
08:03fdobridge_: <!DodoNVK (she) 🇱🇹> I just updated them
08:03fdobridge_: <tom3026> heh i must have been minutes after then, updated them manually
09:14EisNerd: hu patch? gsp? Any chance to get sth improved with a NVE6?
10:18fdobridge_: <Sid> gsp related patch, yes
15:22fdobridge_: <tom3026> hm no idea how uh reliable vkmark is for benchmarking but nouveau is beating the blob
15:24fdobridge_: <karolherbst🐧🦀> some benchmarks are more CPU/WSI heavy
15:24fdobridge_: <karolherbst🐧🦀> especially in the high fps area
15:26fdobridge_: <!DodoNVK (she) 🇱🇹> Which Plagman managed to create with one game :triangle_nvk:
15:26fdobridge_: <karolherbst🐧🦀> yeah...
15:26fdobridge_: <tom3026> yeah i get the feeling its some kind of cpu overhead since the igpu beats both nvidia and nouveau
15:26fdobridge_: <karolherbst🐧🦀> benchmarking is hard (tm)
15:26fdobridge_: <karolherbst🐧🦀> well.. not having to copy over the pcie bus gives you an advantage 😄
15:26fdobridge_: <tom3026> and a prime setup where the black magics of rendering and syncing and drawing in combination of even more magics
15:27fdobridge_: <tom3026> cpu goes BRRRR pretty much
15:27fdobridge_: <karolherbst🐧🦀> yeah
15:27fdobridge_: <tom3026> but means whatever overhead its lower on nouveau 😛
15:29fdobridge_: <karolherbst🐧🦀> 😄
15:29fdobridge_: <karolherbst🐧🦀> prolly WSI
15:33fdobridge_: <makinbacon21> so question, i was in the irc a while ago asking about ga10b/orin (tegra stuff), but i kinda shelved it hoping the newer jetson linux release would provide better fw. it did not. so back to where i was
15:33fdobridge_: <makinbacon21> we have gsp got ga10b, but it's split and encrypted
15:34fdobridge_: <makinbacon21> not sure if that s smth anyone here has seen before or would know how to deal with
15:34fdobridge_: <makinbacon21> fw we have is uploaded at https://gitlab.incom.co/CM-Shield/proprietary_vendor_nvidia/-/tree/lineage-21/t234/r36/firmware/ga10b?ref_type=heads
15:34fdobridge_: <makinbacon21> not sure why they felt the need to do it this way but whatever thanks nvidia
15:34fdobridge_: <karolherbst🐧🦀> I think the main question is how compatible is it with the stuff we get and with the release branches of the blob driver
15:35fdobridge_: <makinbacon21> this fw works with a shallow fork of the r535 driver
15:35fdobridge_: <makinbacon21> this fw works with a shallow fork of the r535 proprietary driver (edited)
15:35fdobridge_: <makinbacon21> so probably not too bad
15:35fdobridge_: <karolherbst🐧🦀> I see...
15:35fdobridge_: <makinbacon21> this fw works with a shallow fork of the r535 proprietary driver as opposed to prior releases and stuff like t194 which had way more special sauce (edited)
15:35Sid127: at the risk of being cheeky, makinbacon21, you're technically still on IRC :D
15:36fdobridge_: <makinbacon21> yea haha but via the discord
15:36fdobridge_: <makinbacon21> which i prefer :))
15:36fdobridge_: <Sid> yup, yup, just messing with ya
15:36fdobridge_: <makinbacon21> on here for other projects anyway
15:36fdobridge_: <karolherbst🐧🦀> lol
15:36fdobridge_: <marysaka> so are L4T shipping with encrypted firmware blobs?
15:36fdobridge_: <karolherbst🐧🦀> maybe in 5 years we can ditch ITC
15:36fdobridge_: <karolherbst🐧🦀> maybe in 5 years we can ditch IRC (edited)
15:36fdobridge_: <makinbacon21> yes
15:37fdobridge_: <makinbacon21> gsp for example
15:37fdobridge_: <makinbacon21> https://cdn.discordapp.com/attachments/1034184951790305330/1194666233514184797/image.png?ex=65b12ea1&is=659eb9a1&hm=2dc244d9e352fa28d00b65dd714a1e4d32e9f5c014ee53c0d78f10c50d824112&
15:37fdobridge_: <marysaka> I'm pretty sure that there is a variant of openrm for Orin
15:37fdobridge_: <makinbacon21> if there is youd have to show me
15:37fdobridge_: <marysaka> That's android tho?
15:37fdobridge_: <makinbacon21> no
15:37fdobridge_: <makinbacon21> there is no android specific stuff for orin
15:37fdobridge_: <marysaka> I mean literally the L4T driver package on NVIDIA Jeson website
15:37fdobridge_: <makinbacon21> yes
15:37fdobridge_: <makinbacon21> where u think this came from
15:38fdobridge_: <makinbacon21> this is the work of a friend of mine, we've gotten android booting on orin via l4t kernel + fw
15:38fdobridge_: <makinbacon21> this is the work of a friend of mine, we've gotten android booting on orin via l4t kernel + fw (but ofc only sw render cuz 0 userspace) (edited)
15:38fdobridge_: <marysaka> so then how does it works? it surely need to decrypt those at some point :aki_thonk:
15:38fdobridge_: <karolherbst🐧🦀> I wonder how much custom kernel code orin still needs...
15:38fdobridge_: <marysaka> and I'm pretty sure Falcon on GSP support botting already encrypted blobs
15:38fdobridge_: <makinbacon21> if that is the case then i guess im in luck
15:38fdobridge_: <makinbacon21> not much
15:39fdobridge_: <makinbacon21> the diff from desktop driver is pretty small now
15:39fdobridge_: <karolherbst🐧🦀> but yeah... if you get it to work on nouveau you can always send patches or something 😄
15:39fdobridge_: <makinbacon21> the diff from desktop driver is pretty small now, the display stuff might be an issue but theyve pushed more stuff for that (edited)
15:39fdobridge_: <karolherbst🐧🦀> mhhhh
15:39fdobridge_: <karolherbst🐧🦀> well.. that's mostly handled in the gsp firmware anyway
15:39fdobridge_: <makinbacon21> ill take a look, i just wanted to know like how id go about loading the fw for that
15:40fdobridge_: <makinbacon21> i appreciate the support
15:41fdobridge_: <makinbacon21> also props for updating the website to be not crap!!! looks super nice
15:41fdobridge_: <karolherbst🐧🦀> kinda need to add a new chipset entry for it inside `nvkm/engine/device/base.c` and I think the gsp stuff needs to be a bit custom to pick up the other firmware?
15:41fdobridge_: <karolherbst🐧🦀> thank @theevilskeleton for that :3
15:41fdobridge_: <makinbacon21> some links are broken
15:41fdobridge_: <karolherbst🐧🦀> ~~now I wished the content wouldn't still be crap~~
15:41fdobridge_: <makinbacon21> lol
15:42fdobridge_: <makinbacon21> someone should shove in some jekyll and do some writeups haha
15:42fdobridge_: <karolherbst🐧🦀> yeah... prolly just want to remove them, you can always file bugs or something
15:42fdobridge_: <makinbacon21> yea ill do that at some pt
15:43fdobridge_: <karolherbst🐧🦀> (me every day thinking about the wiki)
15:43fdobridge_: <makinbacon21> what we did for the switchroot project is just say f it and switch to gitbook
15:44fdobridge_: <makinbacon21> our wiki is nice
15:44fdobridge_: <makinbacon21> https://wiki.switchroot.org/wiki/
15:44fdobridge_: <makinbacon21> used wikijs for a while but it's garbage now lol
15:45fdobridge_: <karolherbst🐧🦀> yeah....
15:45fdobridge_: <karolherbst🐧🦀> I think it wouldn't be a mistake to switch to other software, but the intention with the new design was so that other wikis could also migrate to it, as most of the fdo wikis are still on ikiwiki 😄
15:46fdobridge_: <makinbacon21> lol
15:46fdobridge_: <makinbacon21> we were using mediawiki in the computer club at my school, a guy from before my time migrated it to md files with the intention of writing the greatest wiki ever
15:46fdobridge_: <makinbacon21> spoiler: was never completed
15:47fdobridge_: <karolherbst🐧🦀> 😄
15:47fdobridge_: <karolherbst🐧🦀> well
15:47fdobridge_: <karolherbst🐧🦀> at least most the ikiwiki stuff is just md files
15:47fdobridge_: <makinbacon21> i had to convince him my freshman year to let us throw up a gitbook instance "for the interim" so we had smth that was not github with raw frontmatter to find docs in
15:47fdobridge_: <makinbacon21> hehehehehe yea easier to convert
15:48fdobridge_: <karolherbst🐧🦀> ikiwiki has special tags and all that stuff, but yeah
16:38fdobridge_: <zmike.> `GL_RENDERER = zink Vulkan 1.1(TU106 (MESA_NVK))`
17:03fdobridge_: <zmike.> CTS is running.
17:03fdobridge_: <zmike.> apparently latest deqp-runner is broken for GL?
17:03fdobridge_: <zmike.> :migraine:
17:04fdobridge_: <zmike.> also my attempt at using rawhide's 6.8 kernel snapshot got nothing but hangs, so I don't recommend that
17:13fdobridge_: <rhed0x> i joined the club
17:13fdobridge_: <rhed0x> https://cdn.discordapp.com/attachments/1034184951790305330/1194690587077660692/image.png?ex=65b14550&is=659ed050&hm=c8da7546f0ab3a9667345405ca70a7fcf666eef5000bf39ac1bad32fd93c3ffe&
17:14fdobridge_: <mohamexiety> moar nvk, nice!
17:14fdobridge_: <rhed0x> bit annoying that 144hz doesnt work on my primary monitor with nouveau
17:14fdobridge_: <rhed0x> the proprietary driver and Windows can both do 144hz just fine and the screen itself supports it
17:15fdobridge_: <rhed0x> maybe DSC related, idk if DSC is necessary for 4k 144hz
17:22fdobridge_: <samantas5855> gsp should support dsc
17:22fdobridge_: <samantas5855> but yes Im pretty sure you need dsc for 4k 144
17:23fdobridge_: <rhed0x> im on ampere, havent set up the kernel parameter yet
17:23fdobridge_: <rhed0x> i did install 6.7 though
17:23fdobridge_: <samantas5855> I mean at least the open gpu kernel modules do since recently
17:25fdobridge_: <rhed0x> nice to run Wayland without XWayland sync problems :happy_gears:
17:33fdobridge_: <redsheep> Are we talking HDMI or DP here? If DP then yes that's DSC for sure, If that's HDMI then it's probably needing FRL
17:33fdobridge_: <rhed0x> DÜ
17:33fdobridge_: <rhed0x> DP (edited)
17:33fdobridge_: <rhed0x> after rebooting with GSP enabled, 144hz isnt even in the list anymore
17:33fdobridge_: <redsheep> Ah I don't have a DSC display just yet so I haven't had the chance to hack around with that
17:38fdobridge_: <esdrastarsis> pls fix Team Fortress 2 and Super Tux Kart on Zink 🙏
17:41fdobridge_: <redsheep> You can probably make a custom 120hz mode work if your only other option is 60, but so far I've only been using X and it sounds like you're on Wayland.
17:42fdobridge_: <zmike.> I must finish this cts run before I can possibly attempt anything else
17:42fdobridge_: <zmike.> nvk currently poised to take the 👑 for lowest zink failure rate on first run for any driver
17:43fdobridge_: <redsheep> Zink on NVK has been working well for me, so I'm not surprised
17:44fdobridge_: <!DodoNVK (she) 🇱🇹> I wonder how close it will get to your meme results :Xorg:
18:06fdobridge_: <airlied> Well I did do gl cts runs pre holidays and fixed the easy ones 🙂
18:12fdobridge_: <zmike.> So far it's actually fixing zink bugs the longer it runs
18:12fdobridge_: <zmike.> Really stellar work all around
18:13fdobridge_: <rhed0x> 120hz 4k works fine
18:13fdobridge_: <rhed0x> just 144hz doesnt work
18:13fdobridge_: <rhed0x> oh and the 120hz 4k mode has insane color banding
18:22fdobridge_: <redsheep> I wonder if it dropped to 6 bit for some reason, or if your display hates that mode
18:23fdobridge_: <redsheep> I haven't seen extra banding with my 4k120
18:25fdobridge_: <rhed0x> https://cdn.discordapp.com/attachments/1034184951790305330/1194708595485442208/PXL_20240110_181005196.MP.jpg?ex=65b15615&is=659ee115&hm=83b3819b7f08d7086e431e3be872c48dd97de263d0c0c123621085e0530d3bd3&
18:25fdobridge_: <rhed0x> that's not just the camera, if actually looks like that
18:26fdobridge_: <rhed0x> until I move it to my second screen (1440p 165hz), it's perfectly fine on that one
18:27fdobridge_: <rhed0x> NVK works great with the stuff I've thrown at it so far though :)
18:28fdobridge_: <redsheep> Can you paste the actual modeline it's using?
18:29fdobridge_: <rhed0x> where do i find that?
18:31fdobridge_: <redsheep> I was using xrandr but on Wayland a quick Google search indicates you can read it from /sys/class/drm
18:36fdobridge_: <rhed0x> i cant find anything on the bit depth though
18:38fdobridge_: <rhed0x> > /sys/class/drm/card0-DP-2/modes
18:38fdobridge_: <rhed0x> just lists resolutions
18:39fdobridge_: <rhed0x> gnome-randr just lists resolution + scale factors
18:46fdobridge_: <redsheep> Does either one list the timings?
18:48fdobridge_: <rhed0x> it listed refresh rates
18:48fdobridge_: <rhed0x> but that's it
18:48fdobridge_: <redsheep> Lame
18:51fdobridge_: <redsheep> Well if the mode exceeds the bandwidth limitations then it's not surprising it used 6 bpc, better that than failing to set the mode.
19:03fdobridge_: <airlied> @makinbacon21 I don't think orin does GSP like discrete GSP,
19:04fdobridge_: <airlied> pretty sure they if there is a gsp engine, they aren't loading the same gsp fw as they do on discrete
19:04fdobridge_: <airlied> for adding support to nouveau I think it would be a lot more like previous jetson stuff
19:13fdobridge_: <makinbacon21> would it? It appears to use the same GSP loading stack in the Nvidia kernel driver
19:13fdobridge_: <makinbacon21> tho I guess that's just for display and they also have the nvgpu stuff
19:13fdobridge_: <makinbacon21> what all would be needed for that
19:17fdobridge_: <redsheep> If you're willing to test using an X session to try to fix it there's a good chance you can set the same modeline that does 4k120 8bpc for me on dp hbr3 without dsc
19:18fdobridge_: <redsheep> Enter an X session and run
19:18fdobridge_: <redsheep> ```xrandr --newmode "3840x2160_120" 1067.5735 3840 3888 3922 4002 2160 2164 2170 2223 +HSync -VSync
19:18fdobridge_: <redsheep> xrandr --addmode DP-3 "3840x2160_120"```
19:18fdobridge_: <rhed0x> nah I rebooted to Windows to play CS 🙃
19:18fdobridge_: <redsheep> If that works then you can add a custom EDID to use it with wayland
19:18fdobridge_: <airlied> @makinbacon21 got a pointer to the gsp loading stack that uses those firmware files?
19:18fdobridge_: <redsheep> Oh also make sure to match to your actual output label
19:19fdobridge_: <makinbacon21> lemme look I just got home, was p sure i saw it in my grep thru nvidia display...1s...
19:22fdobridge_: <zmike.> that does appear to be a depth/clipping issue in stk
19:23fdobridge_: <makinbacon21> welp must have lost my mind
19:24fdobridge_: <makinbacon21> it gets loaded in nvgpu not nvidia
19:24fdobridge_: <makinbacon21> heres part of it
19:24fdobridge_: <makinbacon21> https://gitlab.incom.co/CM-Shield/android_kernel_nvidia_nvgpu/-/blob/lineage-21/drivers/gpu/nvgpu/common/acr/acr_sw_ga10b.c
19:25fdobridge_: <makinbacon21> so yea ur prolly right, since it's just using the desktop esque stuff for disp and not for actual rendering, would need smth similar to other tegra
19:25fdobridge_: <makinbacon21> fun
19:45fdobridge_: <zmike.> hm I forgot to add a skip for that one test that takes 30 minutes on a performant piece of hardware
19:45fdobridge_: <zmike.> this cts run could take a few days
19:46fdobridge_: <airlied> the texture_swizzle one?
19:47fdobridge_: <zmike.> GTF-GL46.gtf32.GL3Tests.packed_pixels.packed_pixels_pixelstore
19:47Lyude: karolherbst: btw - how did you say you got rust-analyzer setup with the linux kernel again?
19:50airlied: the rust docs in the kernel have info
19:50airlied: Documentation/rust/
19:50Lyude: cool cool
19:59fdobridge_: <zmike.> hmm yeah I got another trace here with similar clipping issues
20:02fdobridge_: <zmike.> uhhhhhh lmao okay maybe a bioshock infinite trace was too ambitious
20:03fdobridge_: <!DodoNVK (she) 🇱🇹> Does Doom use more advanced graphics features?
20:11fdobridge_: <zmike.> I don't recall
20:12fdobridge_: <zmike.> I also can't find my good doom trace though
20:23fdobridge_: <airlied> that implies the existance of a bad doom trace
20:33fdobridge_: <zmike.> I have a bad doom trace
20:33fdobridge_: <zmike.> it isn't long enough to get in game
20:35fdobridge_: <Sid> I can generate a trace if you want me to I have the game installed
20:35fdobridge_: <Sid> and am on proprietary driver atm
20:36fdobridge_: <!DodoNVK (she) 🇱🇹> So I can't see the part where that dragon gets hit and "Lockdown in effect" gets said? 🐸
20:37fdobridge_: <Sid> having played every doom game multiple times
20:37fdobridge_: <Sid> what dragon
20:37fdobridge_: <zmike.> I'll get to it at some point maybe
20:38fdobridge_: <!DodoNVK (she) 🇱🇹> I think I meant demon
20:38fdobridge_: <Sid> ah
20:38fdobridge_: <zmike.> I'm confused where my good traces went though
20:51fdobridge_: <zmike.> oh it turned out I was just playing them wrong
20:55fdobridge_: <zmike.> :sensiblechuckle:
20:55fdobridge_: <zmike.> wolfenstein also not quite ready
20:57fdobridge_: <zmike.> cts done, and these are some good results.
21:01fdobridge_: <zmike.> for anyone interested:
21:01fdobridge_: <zmike.> doom - https://mega.nz/file/EREy3JBT#BQG-kSWck7iD12Egz9EJro8fqyAb4C0tbdYVFlS235E
21:01fdobridge_: <zmike.> bioshock - https://mega.nz/file/YVtFTCYT#uzvyIIXFlGJaiH_dABka5FVJeyNrcvmsQFUTU4y_54A
21:01fdobridge_: <zmike.> wolfenstein - https://mega.nz/file/sV92jYLD#A01nljFNeXDLNaq2bRxRM7Qr4MlrhECUhjua7-wSAf8
21:01fdobridge_: <zmike.> all with various misrenders
21:02fdobridge_: <zmike.> and wolfenstein yields a bonus hang on exit
21:09fdobridge_: <samantas5855> hi mike
22:04fdobridge_: <airlied> @zmike. got the cts results?
22:05fdobridge_: <zmike.> https://gitlab.freedesktop.org/mesa/mesa/-/issues/10417
22:13fdobridge_: <airlied> https://paste.centos.org/view/d158b367 fixes some of them
22:14fdobridge_: <airlied> https://paste.centos.org/view/986011d0 fixes another one, but is wrong, since we don't expose that functionality, so it seems like a bug in either GL spirv or zink to hit that path
22:14fdobridge_: <esdrastarsis> Oh, this is the same patch I made to fix Deep Rock Galactic and Resident Evil 2 Remake on DXVK
22:15fdobridge_: <airlied> https://paste.centos.org/view/8b3f4c6e also fixes one
22:15fdobridge_: <airlied> but again not sure if it's right
22:15fdobridge_: <airlied> and all the map buffer ones are due to the PIPE_CAP_MIN_MAP_BUFFER_ALIGNMENT
22:15fdobridge_: <airlied> setting to 64 makes a bunch of those happy
22:16fdobridge_: <airlied> I'll MR the first one then
22:18fdobridge_: <airlied> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26990
22:19Plagman: fwiw my datapoint was prime for nouveau but not for the blob - blob was presenting directly in a passthrough vm
23:24fdobridge_: <gfxstrand> I'm CTSing this now
23:25fdobridge_: <gfxstrand> Here's a fail for you: dEQP-VK.image.texel_view_compatible.compute.extended.3d_image.image_load.bc4_snorm_block.r32g32_sint