03:53almagbegun: I am way too busy to deal with retards, what i remember was those fuckers trying to kill me over ten times in cambodia, but there is a big list of locals needed to be knocked out, chinese will buy the second hotel too and remain in charge to handle trash in that region, we only handle finland and estonia during upcoming conflict. Lot of human trash gets killed off. British scout boys are pretty much fairytale boys , those just run away under
03:53almagbegun: scout boys
03:57fdobridge: <Sid> oh no they're back
08:27fdobridge: <redsheep> Ok helldivers 2 is not actually working, Sid was right, it doesn't load into maps.
08:41fdobridge: <gfxstrand> Do wee need some place to track all this?
08:42fdobridge: <gfxstrand> There's a guy on Mastodon who's been trying out games and posting videos: https://mastodon.social/@nebadon2025
08:43fdobridge: <!DodoNVK (she) 🇱🇹> NVK game compatibility list (real)
08:44fdobridge: <gfxstrand> Is that a thing? If so, where is it?
08:45fdobridge: <gfxstrand> I mean, protondb exists but IDK how to query it for NVK
08:45fdobridge: <!DodoNVK (she) 🇱🇹> Of course not
08:46fdobridge: <gfxstrand> I'd like to start compiling a list of stuff that works with RADV but not NVK along with a categorization of why. Rendering bugs, missing features, etc.
08:46fdobridge: <gfxstrand> Maybe we should just have a shared google doc?
08:47fdobridge: <gfxstrand> We could also track it in an issue
08:47fdobridge: <gfxstrand> It's fun to have a positive list (Yay! Games work!) but the ones that aren't working are obviously more interesting.
08:47fdobridge: <gfxstrand> IDK that I want to have a bug for every single one but we should have something.
08:48fdobridge: <dadschoorse> isn't that's what the mesa issue tracker is for?
08:48fdobridge: <gfxstrand> Sure
08:56fdobridge: <redsheep> Yeah I have tons of test results I could start documenting if we get an issue. I just assumed you probably wouldn't want the noise in mesa
08:57fdobridge: <redsheep> A google doc would avoid emailing a load of people all the time, we could have an issue that links to the doc?
09:05fdobridge: <gfxstrand> https://docs.google.com/spreadsheets/d/1RuHD3Z_nBKCp618HHC5I9hOu0lqCoFYwQ4FM69M-Ajg/edit#gid=0
09:06fdobridge: <gfxstrand> https://gitlab.freedesktop.org/mesa/mesa/-/issues/11066
09:06fdobridge: <gfxstrand> DM me a gmail address and I'll give you edit access
09:09fdobridge: <gfxstrand> (or other Google-enabled e-mail address)
09:10fdobridge: <gfxstrand> @redsheep I'd be happy to let you act as something of an organizer for this if you're up for it.
09:10fdobridge: <gfxstrand> @redsheep I'd be happy to hav you act as something of an organizer for this if you're up for it. (edited)
09:10fdobridge: <gfxstrand> @redsheep I'd be happy for you act as something of an organizer for this if you're up for it. (edited)
09:11fdobridge: <redsheep> Works for me, I will dump some results in soon
09:16fdobridge: <gfxstrand> It's literally an empty sheet right now. Go ahead and add whatever columns you think make sense. I can help you re-organize it later if we end up wanting something different. But I don't have a plan right now so whatever makes sense to you is fine with me.
09:17fdobridge: <gfxstrand> I'm happy to give other folks edit access, too, if they want to help out.
09:18fdobridge: <marysaka> Seems I already have edit access :aki_thonk:
09:19fdobridge: <gfxstrand> I don't know how. That link should be read-only
09:19fdobridge: <ahuillet> if someone had the skills and time for it, a nvk FeatureMatrix + nvkdb might be interesting, but it may well be overkill
09:20fdobridge: <ahuillet> (don't look at me, I track my work in a Google Docs thing, and even that I have trouble keeping up to date)
09:22fdobridge: <gfxstrand> https://vulkan.gpuinfo.org/listreports.php?submitter=Faith%20Ekstrand
09:23fdobridge: <gfxstrand> I'm planning to upload once per Mesa release if I remember to
09:33fdobridge: <redsheep> There's also always https://mesamatrix.net/
09:41fdobridge: <marysaka> nevermind I don't have access yeah
11:25fdobridge: <gfxstrand> Well, you do now. 😝
11:32fdobridge: <redsheep> Let me know if you think this format will work, I haven't had time to get it really sorted out
11:34fdobridge: <redsheep> Trying to figure the best way to have dmesg and proton logs in here as I think those will be really relevant. Proton logs are so huge...
11:53fdobridge: <gfxstrand> I added a 3-option drop-down for an instant-view status of the game.
11:53fdobridge: <gfxstrand> The options are ✅ , ✗, and 🫤
11:54fdobridge: <redsheep> Hmm. My intention was to have the status in the games sheet as a summary. Maybe just have that dropdown in both places?
11:55fdobridge: <gfxstrand> Yeah, or we can just have the one sheet
11:55fdobridge: <gfxstrand> You should be able to filter on the drop-down if you want to see just ✅ games, for instance.
11:59fdobridge: <Joshie with Max-Q Design> I am really starting to wonder if this being linked to irc is worth it at all
12:00fdobridge: <Joshie with Max-Q Design> The number of irc interactions is very low
12:00fdobridge: <redsheep> There are still a good number of useful contributors who are IRC only
12:00fdobridge: <redsheep> Like most of the kernel people
12:01fdobridge: <mohamexiety> yeah. also this person's rantings have been massively massively reduced already. used to post multiple times per week in the past
12:02RSpliet: And me, hello!
12:03karolherbst: I'm planning to set up a bridge which doesn't suck
12:03karolherbst: but yeah...
12:08fdobridge: <redsheep> The idea is that the first tab won't have duplicates, where the second one will to represent different configurations, hardware, and testers, and can't be quite as simple and clean. Maybe there's some good way to make one tab work well for that though, I am finding that sheets is missing quite a bit in terms of excel features I take for granted
12:09fdobridge: <mtijanic> IRC bridge also means all the logs from here are kept and publicly accessible. _And searchable_, which discord fails at massively.
12:10fdobridge: <mtijanic> As a sample size of 1, I've been following along the chatter here via the logs for quite a while before I needed to send someone a direct message and actually joined.
12:10fdobridge: <redsheep> A discord bot scraping the chat to publish logs would accomplish the same thing though, and would do a better job of retaining things like who is replying to who. As it is it's really hard to understand the conversations between discord users here when you are on the IRC side
12:11fdobridge: <redsheep> The context switching gets to be a real mess
12:11fdobridge: <mtijanic> I think logging bots are against discord TOS. Which probably includes the IRC bridge one as well in this way, but dunno how they'd handle it.
12:12fdobridge: <ahuillet> ./build/src/nouveau/headers/nvk_clb197.h <- this is autogenerated from the class headers, correct?
12:12fdobridge: <mohamexiety> iiuc you can log but you can't maintain usernames/IDs though. I don't exactly know much but someone I know was looking into creating a memey AI chatbot and he said that the scraping was fair game but the guidelines explicitly require the data to be anonymous
12:12fdobridge: <mohamexiety> yes
12:12RSpliet: I think I have a more fundamental problem with relying on a proprietary provider for comms. IRC is an RFC-standard, Matrix is (I just learned) an open standard, both would be better to lean on for core comm than something controlled externally
12:12fdobridge: <ahuillet> class_parser.py?
12:12RSpliet: But then again, it's not really my party
12:13karolherbst: yeah....
12:13karolherbst: but like..
12:13karolherbst: moderation on matrix is even worse than on IRC
12:13karolherbst: it's a shame that we don't really have _good_ standards
12:13fdobridge: <marysaka> yes it's generated by class_parser.py
12:13fdobridge: <mtijanic> Maybe the EU DMA will eventually make discord suck less in that regard.
12:14fdobridge: <ahuillet> @marysaka if I update a class header, does it do the right thing automatically or do I need to edit the script?
12:14fdobridge: <ahuillet> I see it explicitly lists some names
12:15fdobridge: <marysaka> so the explicit list is for the "array" around, but if you want to update the class header, I think we are trying to keep in sync with the open-gpu-doc repo
12:16fdobridge: <ahuillet> yeah, don't worry about that for now, I just want to understand the second part of the process
12:16fdobridge: <ahuillet> (assume the repo is updated with the stuff I'm working on publishing)
12:16fdobridge: <marysaka> the MR for rasterization or mesh shader have some patches that add "mixins" to define stuffs outside of the normal headers
12:17fdobridge: <ahuillet> I'm working on re-doing the conservative rasterization MR, without the "mixin" stuff
12:17fdobridge: <ahuillet> so for the time being I edited the class headers to add what I needed, but it doesn't look like class_parser is picking that up right away.
12:18fdobridge: <ahuillet> so anyway my question is -- when the class headers are edited, do I need to do something special for class_parser to pick up the new defines?
12:19fdobridge: <ahuillet> oh, or maybe if I update the correct class file ID I'll get better results :D
12:20fdobridge: <gfxstrand> Ah, that makes sense
12:20ad__: hi gm
12:21ad__: so i got mail feedback the patch https://lists.freedesktop.org/archives/dri-devel/2024-April/451295.html is working
12:22ad__: really would be nice for me if it could be accepted. Lyude : let me know if i need to adjust soemthing
12:26fdobridge: <gfxstrand> That helps. 😂
12:34fdobridge: <ahuillet> within nvk_flush_rs_state, do I have a way to access cls_eng3d?
12:35fdobridge: <ahuillet> maybe there's a global somewhere?
12:35fdobridge: <ahuillet> nvk_cmd_buffer_3d_cls
12:35fdobridge: <ahuillet> I swear every time it's the same thing, you grep for 10 minutes, ask the question, grep more and find the answer right away
12:37fdobridge: <mohamexiety> hahaha
12:37fdobridge: <mohamexiety> or you ask the question and find yourself answering it right away yourself
12:38fdobridge: <redsheep> See if the sheet makes sense now. I've ran out of time to fill it out for now, but I think the bones are there. My interpretation of your 3 statuses so far are works perfectly, has rendering or major performance issues, and crashes. Maybe we want more different emojis for more granularity though, and a legend somewhere
12:40fdobridge: <ahuillet> Unsupported SPIR-V capability: SpvCapabilityFragmentFullyCoveredEXT (5265)
12:43fdobridge: <gfxstrand> Yeah, that makes sense. Thanks!
12:43fdobridge: <gfxstrand> You need to add something to the caps section of `spirv_options` in `nvk_shader.c`
12:49fdobridge: <ahuillet> can we make things depend on the HW generation in there, or does it not matter because gen-invalid SPIRV won't make it there?
12:50fdobridge: <ahuillet> ```thread '<unnamed>' panicked at ../src/nouveau/compiler/nak/from_nir.rs:2955:18:
12:50fdobridge: <ahuillet> Unsupported intrinsic instruction: load_fully_covered
12:50fdobridge: <ahuillet> ```
12:50fdobridge: <ahuillet> or maybe I keep that particular feature for later
12:50fdobridge: <gfxstrand> It doesn't really matter. Alyssa had a thing to try and auto-generate it all based on Vulkan features. We should probably push that forwards.
12:59fdobridge: <zmike.> I'm suddenly getting a bunch of rust errors trying to build nvk
12:59fdobridge: <zmike.> like
12:59fdobridge: <zmike.> ```
12:59fdobridge: <zmike.> error[E0786]: found invalid metadata files for crate `bitview`
12:59fdobridge: <zmike.> --> ../src/nouveau/compiler/nak/ir.rs:4:1
12:59fdobridge: <zmike.> |
12:59fdobridge: <zmike.> 4 | extern crate bitview;
12:59fdobridge: <zmike.> | ^^^^^^^^^^^^^^^^^^^^^
12:59fdobridge: <zmike.> |
12:59fdobridge: <zmike.> = note: invalid metadata version found: /home/zmike/src/mesa/build/src/nouveau/compiler/libbitview.rlib
12:59fdobridge: <zmike.> ```
13:03fdobridge: <zmike.> looks like something broken with meson
13:03fdobridge: <zmike.> have to delete build/src
13:04fdobridge: <mohamexiety> when rustc gets upated, you need to rebuild crates I think, which meson doesn't do by itself
13:10fdobridge: <zmike.> convenient
13:36fdobridge: <zmike.> @gfxstrand I'm looking into optimizing pre-checks for glcts runs which might enable passing ES at some point
13:37fdobridge: <zmike.> it seems incredibly stupid that glcts has to run synchronously across all the configs instead of being able to run N configs across N cores, at the least
14:30fdobridge: <zmike.> hm
14:35fdobridge: <zmike.> `dEQP-EGL.functional.buffer_age.*` fails on my nvk system but passes on every other system
14:35fdobridge: <zmike.> it passes on my intel igpu on the nvk system but fails on nvk
14:35fdobridge: <zmike.> this feels like an nvk problem somehow
14:52fdobridge: <zmike.> @gfxstrand try this script on one of your fast machines and you should get the full results for an entire cts-runner instance in like an hour:
14:52fdobridge: <zmike.> ```sh
14:52fdobridge: <zmike.> #!/bin/zsh
14:52fdobridge: <zmike.>
14:52fdobridge: <zmike.> CTS_DIR=~/src/VK-GL-CTS/egl/external/openglcts/modules
14:52fdobridge: <zmike.> export MESA_LOADER_DRIVER_OVERRIDE=zink
14:52fdobridge: <zmike.> export VK_ICD_FILENAMES=/usr/local/share/vulkan/icd.d/nouveau_icd.x86_64.json
14:52fdobridge: <zmike.> export NIR_DEBUG=novalidate
14:52fdobridge: <zmike.> export DISPLAY=:0
14:52fdobridge: <zmike.>
14:52fdobridge: <zmike.> cur_dir="$PWD"
14:52fdobridge: <zmike.>
14:52fdobridge: <zmike.> cd "$CTS_DIR"
14:52fdobridge: <zmike.> if [ -z "$1" ] ; then
14:52fdobridge: <zmike.> "$CTS_DIR"/cts-runner --help
14:52fdobridge: <zmike.> cd "$cur_dir"
14:52fdobridge: <zmike.> exit 1
14:52fdobridge: <zmike.> fi
14:52fdobridge: <zmike.>
14:52fdobridge: <zmike.> lists=($("$CTS_DIR"/cts-runner --type=$1 --summary|grep Config|tr -d ','|cut -d: -f2|sed 's/ /asdf/g'))
14:52fdobridge: <zmike.> cd "$cur_dir"
14:53fdobridge: <zmike.>
14:53fdobridge: <zmike.> for l in "${lists[@]}" ; do
14:53fdobridge: <zmike.> skip=$(echo -n "$l" | grep -o CTS-Configs)
14:53fdobridge: <zmike.> if [ -n "$skip" ] ; then
14:53fdobridge: <zmike.> continue
14:53fdobridge: <zmike.> fi
14:53fdobridge: <zmike.> cmd="${l//asdf/ }"
14:53fdobridge: <zmike.> logfile=$(echo -n $cmd|sed 's/.*--deqp-log-filename=\([^ ]*\).*/\1/g')
14:53fdobridge: <zmike.> logfile="${logfile//.qpa}"
14:53fdobridge: <zmike.> caselist="$CTS_DIR"/$(echo -n $cmd|sed 's/.*--deqp-caselist-file=\([^ ]*\).*/\1/g')
14:53fdobridge: <zmike.> just change a couple vars near the top along with your baseline/skips/flakes at the bottom and run like `./script.sh es32`
14:54fdobridge: <zmike.> ~15 minutes on a 32core machine here
15:10fdobridge: <gfxstrand> Yes, yes it is
15:10fdobridge: <gfxstrand> Or it's a non-modifiers problem
15:16fdobridge: <zmike.> lavapipe passes on other systems too but not on this one 🤔
15:45fdobridge: <zmike.> takes about an hour on my 8 core machine
15:45fdobridge: <zmike.> not bad
15:54fdobridge: <Sid> hmmm
15:54fdobridge: <Sid> somewhere between 0c0d62b and 588c762, NVK regressed
15:55fdobridge: <Sid> Killer Instinct is taking much longer to load assets
15:57fdobridge: <redsheep> Yeah I am pretty sure that some games are taking much longer than before. Can you bisect?
15:58fdobridge: <Sid> can do in ~2h
15:59fdobridge: <Sid> funny
15:59fdobridge: <Sid> there's not many commits to src/nouveau between those 2 commits
16:00fdobridge: <Sid> there's only
16:00fdobridge: <Sid> 2
16:00fdobridge: <Sid> unless this is a vk common runtime thing
16:07fdobridge: <Sid> oh wait I was wrong
16:07fdobridge: <Sid> there's only 1 commit to src/nouveau between those 2
16:55fdobridge: <zmike.> @gfxstrand alright, with https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28900 https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28903 https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28904 I think es32 should pass
16:56fdobridge: <zmike.> doing another run on a couple systems to confirm, should have results within the hour
16:58fdobridge: <zmike.> passes on radv...
17:51fdobridge: <zmike.> passed.
18:04fdobridge: <Sid> here's a couple d3d12/vkd3d-proton logs
18:04fdobridge: <Sid> https://cdn.discordapp.com/attachments/1034184951790305330/1232754059904290867/helldivers2-vkd3d.log?ex=662a9b2f&is=662949af&hm=878ceb0b046dcbbf730bcb02dcff989af43d3e969d7417bdf5ce827d8e81374d&
18:04fdobridge: <Sid> https://cdn.discordapp.com/attachments/1034184951790305330/1232754060516528259/milesmorales-vkd3d.log?ex=662a9b2f&is=662949af&hm=366207c3353a5b800f98905a57f8010c2f9e59bca84c6b5b93dd4222a08dbbdc&
18:05fdobridge: <Sid> Helldivers 2 DX12 does not launch on my machine, and Miles Morales does not render past the intro videos
18:17fdobridge: <Sid> so I reverted to the build of 0c0d62b I already had
18:17fdobridge: <Sid> and it still loads slow
18:18Lyude: airlied: btw, you wanted me to get you the output of "meta->gspFwWprEnd - meta->gspFwWprStart" on my kernel right?
18:24fdobridge: <Sid> do we currently expose only one queue?
18:26airlied: Lyude: yes
18:48Lyude: airlied: gotcha, will get that for you in just a moment
19:00Lyude: how many traits/types can a rust API have just to expose a drm_plane_state? the answer may surprise you
20:28fdobridge: <gfxstrand> Sweet! I may give it a run tomorrow if I get bored. Otherwise it'll be next week sometime at the earliest.
20:29fdobridge: <gfxstrand> We do. It's easy enough to fix, though. The only real problem is deciding how many to expose. I guess we could just copy Nvidia. 🤷🏻♀️
20:37fdobridge: <marysaka> I think NVIDIA expose another queue for some async compute stuffs like AMD
20:37fdobridge: <Sid> I do think copying the proprietary driver on that would be a good way to go about it
20:38fdobridge: <marysaka> like those weird scheduling thing (SCG was the name I think?)
20:38fdobridge: <gfxstrand> Yeah, probably. We can just look at gpuinfo and see what they do. It's just a couple of lines in nvk_physical_device.c.
20:38fdobridge: <gfxstrand> Someone just needs to do the archeology so we're reasonably sure we're actually doing what they do.
20:39fdobridge: <gfxstrand> We should definitely advertise more than one, though.
20:39fdobridge: <Sid> GTX turing: https://vulkan.gpuinfo.org/displayreport.php?id=30008#queuefamilies
20:40fdobridge: <airlied> Also not 100% sure kernel will dtrt for async compute
20:40fdobridge: <Sid> rtx turing: https://vulkan.gpuinfo.org/displayreport.php?id=29623#queuefamilies
20:41fdobridge: <Sid> sorry, accidentally picked a windows GTX turing
20:44fdobridge: <Sid> ok, so
20:45fdobridge: <Sid> 5 queue families on turing, 6 on ampere and ada
20:45fdobridge: <Sid> all on 550 driver series, linux
20:46fdobridge: <Sid> 1660S: https://vulkan.gpuinfo.org/displayreport.php?id=29785#queuefamilies
20:46fdobridge: <Sid> 2080S: https://vulkan.gpuinfo.org/displayreport.php?id=28447#queuefamilies
20:46fdobridge: <Sid> 3090: https://vulkan.gpuinfo.org/displayreport.php?id=29266#queuefamilies
20:46fdobridge: <Sid> 4090: https://vulkan.gpuinfo.org/displayreport.php?id=29508#queuefamilies
20:46Lyude: airlied: so on my testing desktop (so, normal suspend resume - but I assume that shouldn't make any difference) I get: [ 168.573099] Lyude:r535_gsp_fini:1998: (meta->gspFwWprEnd - meta->gspFwWprStart) == 176029696
20:46fdobridge: <Sid> total of 28 on the turings, 29 on the 3090, and 30 on the 4090
20:47fdobridge: <Sid> queues, that is
21:04fdobridge: <Sid> I wonder if bumping up our queues will net any perf uplift
21:04Lyude: anyway, I am gonna give one more shot at writing up a patch since I think I have a slightly better understanding of what needs to happen here now (and most of the problem seemed to just be from the fact that I couldn't use sgt everywhere)
21:12fdobridge: <georgeouzou> The two dma copy queues would be helpful too
21:24fdobridge: <Sid> is this still a to-do? `// TODO: add mapable VRAM heap if possible`
21:44fdobridge: <Sid> it is
21:52fdobridge: <Sid> maybe? can't tell
22:01fdobridge: <zmike.> Test with the script I pasted first so you don't waste all that time if there's still issues
22:30Lyude: airlied: do you know how to actually properly map stuff with nvkm_sg_table()? I mainly ask because I'm trying to figure out what's going wrong with this much less invasive patch, https://gitlab.freedesktop.org/lyudess/linux/-/commit/46fd67476beb5f819ac4a190518a9a86c91849c9
22:31Lyude: https://paste.centos.org/view/3da3526b is currently what I'm seeing the kernel spit out with CONFIG_SG_DMA. unfortunately none of it looks particularly useful
22:32Lyude: https://paste.centos.org/view/3da3526b is currently what I'm seeing the kernel spit out with CONFIG_SG_DMA. unfortunately none of it looks particularly useful
22:32Lyude: i am very confused on what weechat just did to me there
22:33Lyude: I was going to say *the only useful bits look like the fault errors and the mbox error
22:37skeggsb: Lyude: i'm not 100% sure sg_dma_len() will return the same size that nvkm_gsp_mem.size contains
22:38skeggsb: oh, though it should be, we already round up to PAGE_SIZE (or... GSP_PAGE_SIZE, which matches on x86 anyway)
22:42Lyude: yeah, I'm trying to see if I can hookup the debug_dma_error() function but there's more or less 0 documentation I can see on how to actually do anything useful with that
22:53Lyude: skeggsb: do you have any idea what that mbox error means?
22:53Lyude:not really sure how to debug thi
23:00skeggsb: Lyude: i think the FLCN_ERR_* defs in src/nvidia/arch/nvalloc/common/inc/flcnretval.h are what appear there
23:00skeggsb: heading out for a walk/run with my dog, but might be back a bit later and take a closer look
23:00Lyude: hooray dog :)
23:00Lyude: and gotcha! thanks for the tip
23:03Lyude: It's getting late here so I'm gonna call it a day, will check back tomorrow