00:17zmike[d]: feature parity with nvidia at last
01:24gfxstrand[d]: CTS is looking pretty good. I'm going to run Zink tests tomorrow
05:02redsheep[d]: gfxstrand[d]: Did it end up being as hellish as you were expecting?
05:03gfxstrand[d]: No. It's mostly fine, actually. I was pretty worried about buffer views but I came up with a solution that I'm surprisingly happy with. It's still a bit complicated but not nearly as bad as I'd feared.
05:03gfxstrand[d]: The rest of the pain was mostly me struggling to grok the extension for a while. It's not a very obvious extension.
05:04redsheep[d]: gfxstrand[d]: Oh that's great. I assume the zero indirection thing ended up being impossible?
05:04gfxstrand[d]: Oh, I didn't even try for zero indirection
05:05gfxstrand[d]: But, apart from buffer views, what I'm doing for EDB is basically identical to what I'm doing for descriptor sets.
05:05gfxstrand[d]: We'll see what kind of shenanigans I need to pull to optimize descriptors and get better perf but hopefully a lot of it will apply to EDB, too.
05:05gfxstrand[d]: Like my bound UBO optimization already works with EDB.
05:07redsheep[d]: That's awesome. I am hoping that EDB will magically make all the remaining zink issues evaporate
05:07gfxstrand[d]: IDK about that but it'll hopefully at least fix the shader stutters
05:08gfxstrand[d]: Feel free to throw some games at the branch if you feel so inclined. It probably won't affect D3D11 titles but D3D12 stuff will hit it hard.
05:09redsheep[d]: Zink should too, right? Yeah when I get some time I will give it a go
05:10gfxstrand[d]: Yeah, Zink will hit it hard, too
05:13redsheep[d]: If I am reading the dxvk vulkan profile correctly EDB isn't involved at all, so yeah no impact there. DXVK games have already been generally working pretty consistently though.
05:13gfxstrand[d]: Yeah, it's VKD3D-Proton that uses EDB heavily
05:14redsheep[d]: Wasn't it basically made for it?
05:14gfxstrand[d]: Pretty much
05:14gfxstrand[d]: Or at least Proton is why Intel and NVIDIA ever bothered to implement it.
05:17gfxstrand[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1271336569067933770/Z.png?ex=66b6f7f2&is=66b5a672&hm=cb95787f9fa5fc4394c8baa7595269b99a7279e7f0285e2e8d3665a2c554d785&
05:19redsheep[d]: Do you know if there's an easy way to toggle whether EDB gets used by either zink or vkd3d, or would I have to run a local patch to compare?
05:21redsheep[d]: I am not seeing anything like that on the vkd3d-proton side so I would probably just have to shut off it being advertised to A B test
05:22redsheep[d]: Oh I could just have a build without your last commit, easy enough
06:01dadschoorse[d]: `VKD3D_DISABLE_EXTENSIONS=VK_EXT_descriptor_buffer`
06:04redsheep[d]: dadschoorse[d]: Oh nice, that is more convenient, thanks
06:41airlied[d]: next thing you'll be saying shaders can go in objects 😛
11:04asdqueerfromeu[d]: airlied[d]: NVIDIA gives that support for free :nouveau:
11:24redsheep[d]: karolherbst[d]: Got a new monitor with interesting behavior. It is a 4k240 display that relies on DSC to hit full speed, the PG32UCDP. Obviously DSC doesn't work which is an expected mode, except that on windows the way that behaves is 10 bit 422 at 120hz. Nouveau does expose 120hz which is awesome, but picks 444 at 6 bit...
11:25redsheep[d]: So I guess good news is I have an easy display for testing the too-low-bpc failure mode. Also, this has hdmi 2.1 so I can still test FRL if and when the time comes, but I don't need it for full speed since DSC is amazing.
11:32redsheep[d]: This is also one of the wacky dual mode woled displays which can swap the edid and configure the scaler to make 1080p480 possible
11:40redsheep[d]: Hmm on the fast 1080p setting I also get limited to 120hz, but this time 444 10 bit.
14:17asdqueerfromeu[d]: gfxstrand[d]: How many of these issues are already fixed?
15:10gfxstrand[d]: I've got it all sorted, assuming it doesn't blow everything up
15:11asdqueerfromeu[d]: gfxstrand[d]: ~~Maybe vkd3d-proton tests should be a part of Mesa3D's CI?~~
15:41gfxstrand[d]: And I already found a zink bug...
15:41gfxstrand[d]: Apparently, NVK is the final boss. 😛
15:43karolherbst[d]: yeah, that's expected
15:43karolherbst[d]: that's a fermi one
15:44asdqueerfromeu[d]: pavlo_kozlenko[d]: You should use a `for` loop (or actually specify the device number): `for frog in /sys/kernel/debug/dri/*/pstate; do echo "0f" > ${frog}; done`
15:44karolherbst[d]: pavlo_kozlenko[d]: well.. in theory one could implement all those missing bits and pieces, but it's a loooot of work, for old GPUs almost nobody uses anymore
15:45karolherbst[d]: I think Ben had some WIP patches, but it was never production ready afaik
15:46asdqueerfromeu[d]: karolherbst[d]: I wonder if the current priority is nova :ferris:
15:53gfxstrand[d]: Ugh... Zink is taking down my kernel. 😢
15:57asdqueerfromeu[d]: gfxstrand[d]: I guess at this point the KMD might be the worst part of the NVK stack :nouveau:
16:01gfxstrand[d]: Yeah... But I don't want folks to waste too much time monkeypatching it if we're just going to write a new one.
16:06asdqueerfromeu[d]: gfxstrand[d]: Hopefully it will feature all of the important goodies on a proper release (like userptr, queues, fdinfo metrics etc.) otherwise...
16:18gfxstrand[d]: I'll be happy if it's not a feature regression over the current driver and doesn't have the stability problems.
16:20asdqueerfromeu[d]: I kind of believe in "Build Back Better" for the nouveau stack
16:47gfxstrand[d]: Ugh... EDB is undebuggable. 😅
16:47gfxstrand[d]: Fortunately, I can set break points in Zink
16:52gfxstrand[d]: Zink vs. NVK are currently at 1-love
17:53zmike[d]: slander
17:54tiredchiku[d]: slander is spoken, in print it's libel
17:54zmike[d]: that's print as in published works
17:55zmike[d]: looks like everyone in this channel is wrong today
18:25gfxstrand[d]: I need to run piglit without edb to get a baseline. 🤔
18:26gfxstrand[d]: I'm seeing a lot of splats in dmesg that make me nervous but the machine is still alive. <a:bim_shrug2:1102331343695790160>
18:45gfxstrand[d]: As much as I like being able to run one test at a time, one of the things that really sucks about the Vulkan CTS is that it rarely draws, changes a bunch of state, and draws again. It's rubbish at finding dirty tracking bugs.
18:45gfxstrand[d]: piglit+Zink on the other hand, is pretty good at catching them. My Zink bug was the descriptor buffer version of the same bug Zink already caught with push descriptors.
18:58asdqueerfromeu[d]: How easy is it to debug kernel driver faults without disabling GSP (or on Ada)? I think someone has an issue like that in one particular application (but NVIDIA workers mentioned some Protobuf stuff)
19:00gfxstrand[d]: Random faults in an app? Hard.
19:01gfxstrand[d]: Even in a single app it can be a PITA
19:01gfxstrand[d]: But fault addresses also don't always help you because, by their very nature, the fault address is wrong.
19:01gfxstrand[d]: If it were right, it wouldn't have faulted.
19:02gfxstrand[d]: But sometimes it can help to see how it went wrong
19:02asdqueerfromeu[d]: gfxstrand[d]: It's some mmu fault (but GSP of course doesn't give much information)
19:03gfxstrand[d]: zmike[d]: Care to review https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30580/diffs?commit_id=c800f418c440c93697c4e94f969591f466d74907 quick?
19:08asdqueerfromeu[d]: gfxstrand[d]: Hopefully Mike won't respond with a headache emoji though (because that's fairly common) :frog_gears:
19:09gfxstrand[d]: It's a pretty straightforward change. I'm just not sure if I got them all or if that's the best place to put them.
19:11zmike[d]: what is that line wrapping :hypertensionheadache:
19:13zmike[d]: unwrap and you have my 🪓
19:13karolherbst[d]: no line wrapping in zink, everybody knows this 😛
19:14zmike[d]: not no line wrapping
19:14zmike[d]: you gotta feel the line wrap
19:14asdqueerfromeu[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1271547236123152504/nvk-gsp-fault2.txt?ex=66b7bc25&is=66b66aa5&hm=225b7ec6cf6a8a7487e4e92e7ac0635f8d5c3fd7cc8080ca8e06ffa02ba87226&
19:14asdqueerfromeu[d]: asdqueerfromeu[d]: This is a better dmesg from non-GSP (with a 6.9.12-200.fc40.x86_64 kernel and Mesa 24.1.3 from the Flatpak runtime) :triangle_nvk:
19:14zmike[d]: otherwise you end up like the rest of the codebase with
19:14zmike[d]: ```c
19:14zmike[d]: function(
19:14zmike[d]: param, function(
19:14zmike[d]: param),
19:14zmike[d]: param);
19:14zmike[d]: and then literally what are you even doing
19:15karolherbst[d]: uhh.. I think there were people who literally wrote code like text, so they always filled the line and did a new line, like text and no indentation
19:16zmike[d]: yeah well at least there's no question of what params go where if you don't wrap, even if you happen to inconvenience the people still coding on their palm pilots
19:16zmike[d]: it's nowhere near as bad as vvl or cts tho
19:16zmike[d]: that's next level no-wrap
19:16zmike[d]: line length like 6000
19:17karolherbst[d]: ```c
19:17karolherbst[d]: static nir_def * lower_ufind_msb64(nir_builder *b, nir_def *x) { nir_def *x_lo
19:17karolherbst[d]: = nir_unpack_64_2x32_split_x(b, x); nir_def *x_hi = nir_unpack_64_2x32_split_y(
19:17karolherbst[d]: b, x); nir_def *lo_count = nir_ufind_msb(b, x_lo); nir_def *hi_count =
19:17karolherbst[d]: nir_ufind_msb(b, x_hi); return nir_imax(b, lo_count, nir_ior_imm(b, hi_count,
19:17karolherbst[d]: 32));}
19:17karolherbst[d]: like this, but don't ask me where I've seen that stuff
19:17asdqueerfromeu[d]: zmike[d]: gedit won't definitely like that 🍩
19:17zmike[d]: karolherbst[d]: yeah exactly jfc
19:18karolherbst[d]: in rusticl it's whatever `rustfmt` says, then there are no disucssions
19:19zmike[d]: that was tried in other parts of the tree with clang-format
19:19karolherbst[d]: clang-formats mistake was to have more than 1 option
19:19zmike[d]: turns out machines are really bad at understanding line wrapping in general
19:19zmike[d]: that's where my hatred originated, though it was on a different project
19:20karolherbst[d]: yeah fair...
19:20karolherbst[d]: though rustfmt is pretty good tbh
19:20zmike[d]: if you wrap at 80 cols in the current year and it's a hard limit, you're wrong
19:20karolherbst[d]: at least the default config is
19:20gfxstrand[d]: rustfmt is way more sane than clang-format
19:20zmike[d]: my use of rust predated rustfmt, so I don't know it well enough to comment
19:21gfxstrand[d]: zmike[d]: Yes, but let's not have dEQP's minimum of an average of 200 chars/line
19:21zmike[d]: I usually aim for 120
19:21zmike[d]: that's when I have to start looking onto my second monitor
19:21gfxstrand[d]: 120 is a reasonable limit on modern displays
19:21zmike[d]: and it starts getting 🤔
19:21karolherbst[d]: rustfmt uses 100 by default
19:22zmike[d]: but at the same time, if the line would be 121 chars then probably I'm not gonna wrap over 1 extra char
19:22karolherbst[d]: you see, that's why I use rustfmt, I won't have to think about it
19:23zmike[d]: smh this is how the machines win karol
19:23zmike[d]: they take a little bit at a time and soon enough they're lifting weights at the gym for you and your gains are gone
19:23karolherbst[d]: fine by me
19:24zmike[d]: :grimace:
19:25soreau:puts the code formatting script in git commit hook
19:26zmike[d]: don't make me delete it again
19:27gfxstrand[d]: Oh, I'll ack that delete
19:27gfxstrand[d]: I like rustfmt but clang-format can burn
19:28zmike[d]: don't worry, it's still gone
19:28zmike[d]: it can't hurt you
19:28zmike[d]: :feels:
19:28gfxstrand[d]: zmike[d]: I found another issue with alignments. How do you feel about just requiring `db_size[i]` to always be aligned so no one forgets?
19:29zmike[d]: yea that's fine
19:29zmike[d]: none of this code has changed in a long time and I don't expect it to change
19:30airlied[d]: asdqueerfromeu[d]: nova won't have releases, it'll be a kernel driver released as part of the kernel, and it'll be developed upstream in pieces. At some point it'll be recommended to distros to turn it on instead of nouveau for gsp cards
19:30asdqueerfromeu[d]: gfxstrand[d]: I wonder if GCC has its own format tool
19:30zmike[d]: gfxstrand[d]: probably slap a backport tag on it while you're in there
19:32asdqueerfromeu[d]: airlied[d]: But will it have all of those mentioned features by the next Ubuntu LTS for example (or 28.04)? 🐸
19:32airlied[d]: Nobody working on it cares
19:34airlied[d]: I think aligned features with current nouveau for new hw releases is probably the only sorta goal
19:37gfxstrand[d]: zmike[d]: Will do.
19:38gfxstrand[d]: airlied[d]: do we have a UAPI plan? Are we going to try and do something similar or burn and start over?
19:38zmike[d]: gfxstrand[d]: cool, congrats on getting it all working
19:39airlied[d]: Nope no plans
19:39airlied[d]: But burn but try and stay aligned seems likely
19:39airlied[d]: Like no more nvc0 is a call we have to make
19:40gfxstrand[d]: zmike[d]: I love how the commit in the `Fixes:` tag explicitly says in the commit message that it's bug-free. 😅
19:41airlied[d]: Like if there are uapi improvements we can make now in nouveau it might be worth the effort so we can use that knowledge for nova
19:41gfxstrand[d]: Yeah, skeggsb9778[d] and I need to chat about device enumeration. That's still a big one. We should maybe try to have that chat next week.
19:41asdqueerfromeu[d]: gfxstrand[d]: "Zink has no bugs"
19:42gfxstrand[d]: I'm going to call both of the Zink bugs I found one bug since it's basically the same bug twice, I just needed to fix harder. That means that it's still tied 1-1 for this round.
19:42zmike[d]: gfxstrand[d]: tbf it's your fault for adding the bug with your extra driver
19:43asdqueerfromeu[d]: Also I wonder how an updated NVK Zink slide would look like (it definitely needs one change though) :triangle_nvk:
19:44zmike[d]: gfxstrand[d]: but also I wrote now that for you now and backported it to make you laugh
19:44zmike[d]: you're welcome.
19:48gfxstrand[d]: I'm just increasing the bug-freeness
19:48zmike[d]: 🇺🇸
19:51asdqueerfromeu[d]: zmike[d]: Is it as free as 🇳🇴 though?
19:53gfxstrand[d]: airlied[d]: skeggsb9778[d] Do either of you know what this means:
19:53gfxstrand[d]: [ 440.541003] nouveau 0000:17:00.0: fifo:c00000:001b:[gl-2.1-minmax[8774]] ectx 1[gr]: -28
19:53gfxstrand[d]: [ 440.541007] nouveau 0000:17:00.0: fifo:c00000:001b:00d8:[gl-2.1-minmax[8774]] vctx 1[gr]: -28
19:53gfxstrand[d]: [ 440.547673] nouveau 0000:17:00.0: imem: OOM: 000ea000 00010000 -28
19:54gfxstrand[d]: It immediately splats after that
19:54gfxstrand[d]: But also it seems kinda harmless? I've got a pile of them but my kernel is still going. The whole GPU does seem to die after a while, though.
19:54asdqueerfromeu[d]: gfxstrand[d]: Now that's something I've never seen before
19:55gfxstrand[d]: I've not seen it before, either. piglit+NVK+Zink is throwing them like mad, though.
19:55karolherbst[d]: imem is this weird thing....
19:56karolherbst[d]: I wished I'd know more than that
19:57airlied[d]: running out of instance mem, probably due to creating too many contexts
19:57gfxstrand[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1271557917136650281/9k.png?ex=66b7c617&is=66b67497&hm=e751f9b0452f8ffc7d63e3971c4f5d9125330fc8ebfe1705b68b0dc6a4c9df12&
19:57airlied[d]: but it should recover I think
19:57gfxstrand[d]: airlied[d]: Oh, that would make sense.
19:57asdqueerfromeu[d]: gfxstrand[d]: Discord channel #zmikes-meme-factory repost material
19:57gfxstrand[d]: Piglit is trying to run 36 tests at a time on one GPU
19:58zmike[d]: sure would be cool if piglit/cts had zygote modes where they could share the same context across threads/jobs
19:59gfxstrand[d]: I'm gonna drop piglit to -j16
20:00gfxstrand[d]: For the Vulkan CTS, I have a thing in `deqp-runner` that lets me shard across 2 GPUs and that's how I'm able to reliably run with 36 threads.
20:00karolherbst[d]: imagine a world where every single GUI app has its own context and after ~50 nouveau just doesn't work anymore and everybody will hate us
20:00gfxstrand[d]: Otherwise, that's just too many contexts
20:00zmike[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1271558849501073439/8zs8x1.png?ex=66b7c6f6&is=66b67576&hm=2b03cc410c6fc5b0424e50073ecf725707fce5b8e6370fe59939a87ef10951cf&
20:01gfxstrand[d]: lmao
20:01zmike[d]: oh noes you caught me
20:02gfxstrand[d]: Once I figured out buffer views, EDB wasn't that bad. I was worrying too much about it.
20:02gfxstrand[d]: It's still an absolute trainwreck of a feature but I've got it working.
20:02airlied[d]: I thought there was some code to allow instmem evicts, but maybe there isn't, skeggsb9778[d] would know more
20:03asdqueerfromeu[d]: gfxstrand[d]: Will it be faster than proprietary driver implementation though?
20:03gfxstrand[d]: karolherbst[d]: Are you sure we're not already in that world? I can tell you with high certainty that you can blow up nouveau.ko by creating too many contexts too fast.
20:03gfxstrand[d]: asdqueerfromeu[d]: Maybe? <a:shrug_anim:1096500513106841673> IDK how the prop driver implements it.
20:03karolherbst[d]: gfxstrand[d]: I mean.. yes, but gtk4 ain't widely deployed yet enough to matter I think... or maybe not.. dunno, actually, maybe I should check
20:04gfxstrand[d]: I think it's kind of okay having lots of contexts but there are races in context create
20:04karolherbst[d]: though with gl you only get one context per app.. not sure if that changes with vulkan (I hope not)
20:04karolherbst[d]: mhh.. yeah...
20:04karolherbst[d]: nvk creating two on startup also doesn't help
20:04gfxstrand[d]: And throwing 36 threads of dEQP or piglit at it is a good way to stress that
20:05redsheep[d]: does chromium create lots of contexts, like one per tab since they are all separate processes?
20:05karolherbst[d]: maybe you should cache the lookup context for real
20:05karolherbst[d]: redsheep[d]: not really
20:05gfxstrand[d]: Yeah, I need to come up with something better there
20:05gfxstrand[d]: I've got ideas. I just need to hack something together
20:05karolherbst[d]: just store it in the struct an use it if it's not -1 or something 😛
20:06gfxstrand[d]: Yeah, it's not too hard. I just need to type some things out.
20:06redsheep[d]: Hmm now that I think of it I think it creates just one rendering process
20:06gfxstrand[d]: I can atomic swap it out so only the first context is able to steal it
20:10karolherbst[d]: yeah, should be good enough
20:15gfxstrand[d]: heh. nouveau_ws_context_query_classes was right there....
20:15gfxstrand[d]: So I have to allocate a channel but not subchans
20:15gfxstrand[d]: That should help some, maybe?
20:15karolherbst[d]: should be the more expensive part anyway
20:15karolherbst[d]: channel allocation is... expensive
20:16gfxstrand[d]: 😢
20:52gfxstrand[d]: Found this while I was working on descriptor buffer: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30596
20:52gfxstrand[d]: That's probably part of our perf problem.
20:53gfxstrand[d]: I've not CTS'd it yet so there could be dragons hidden in there. In theory, it should be more reliable now than it was but GPUs are hard and I may have screwed something up.
20:53karolherbst[d]: yeah, that might help indeed 😄
20:53gfxstrand[d]: I knew we had to have some glaring problem.
20:53gfxstrand[d]: And that one's a frickin' lighthouse. 😅
20:59redsheep[d]: My spidey sense told me somebody said performance
21:01gfxstrand[d]: Feel free to give it a whirl. As usual, try with and without `NVK_DEBUG=no_cbuf` if you're on a big GPU.
21:01redsheep[d]: 🫡
21:26redsheep[d]: Hmm. That's a bit of a roadblock. Just got some builds going and mesa main doesn't successfully launch the witness for me right now.
21:27redsheep[d]: It doesn't launch talos either... something is off, let me see if I can get logs. Maybe I need to uninstall nvidia drivers again if they are interfering.
21:31redsheep[d]: Uggh, yeah I just uninstalled the nvidia drivers to be sure I wasn't seeing weird stuff creep back in, and yeah I am getting swapchain failure errors with nouveau alone
21:31dadschoorse[d]: gfxstrand[d]: if you don't put the descriptor directly into the descriptor buffer, how do you prevent leaks? do you implement the buffer view offset in software? because otherwise I imagine you have potential massive leaks if applications have usage patterns similar to a ring buffer
21:32gfxstrand[d]: I cover the whole address space in descriptors I allocate at device create time.
21:33redsheep[d]: Maybe a zink session will save me...
21:37redsheep[d]: Yeah... No that's worse. NOUVEAU_USE_ZINK=1 results in everything but the cursor being corrupt, and the loader override one results in the kernel hanging or sddm being black with just a cursor.
21:38dadschoorse[d]: gfxstrand[d]: that sounds disgusting but also clever I guess 🐸
21:42redsheep[d]: I'm not even using Wayland, and my environment and builds are all very default and benign.
21:45redsheep[d]: I decided to just go for it and install the 30596 branch to my system, but that has the same issues
21:46redsheep[d]: This is like the 5th time in two months I have gone to test something and hit a similar issue, so I basically haven't been testing.
21:49gfxstrand[d]: Witness seems to work fine for me on that branch. No improvement, though. 😢
21:49gfxstrand[d]: dadschoorse[d]: It's better than doing format conversion in shaders.
21:50redsheep[d]: Wait... that branch has the same issues with zink sessions, BUT I can do an nvc0 session and have games launch. So something in the commits between the 30596 branch and main broke games launching
21:50redsheep[d]: I can't really do comparative testing, but I would agree this looks like similar perf
21:51dadschoorse[d]: hot take: buffer views shouldn't exist anyway, but I guess we are stuck with them now
21:52gfxstrand[d]: <a:shrug_anim:1096500513106841673>
21:52gfxstrand[d]: They were added for a reason, presumably
21:52gfxstrand[d]: And they're pretty useful if you're pulling vertex data in a ray or mesh shader
21:55redsheep[d]: OK I do actually have comparable numbers for Talos, and yeah... with and without no_cbuf it looks to be in much the same spot that it's been for months
21:56gfxstrand[d]: 😢
21:56dadschoorse[d]: gfxstrand[d]: I guess, although in recent games I've seen more and more custom vertex data format unpacking with alu
21:58gfxstrand[d]: Yeah
21:59gfxstrand[d]: Unpacking with ALU is fine if you know your data formats up-front.
21:59redsheep[d]: Hmm. Didn't no_cbuf cause talos to regress a little, but the witness to jump? Seems like on this branch it makes both faster
21:59gfxstrand[d]: Honestly, the whole "you get floats in the shader" only really makes sense for things where the HW is going to do some sort of interpolation for you.
21:59gfxstrand[d]: redsheep[d]: Interesting! If that's the case then it is reducing serialization
22:00gfxstrand[d]: gfxstrand[d]: Or if you're trying to program in a generic way where you want to be able to swap out formats without changing shader code.
22:00gfxstrand[d]: But neither of those is really the case for a lot of engine code.
22:01gfxstrand[d]: gfxstrand[d]: Okay, one more CTS run and then we're merging this sucker.
22:01dadschoorse[d]: there are d3d games that use R32 texel buffers for almost everything (sometimes including uniform reads)
22:01gfxstrand[d]: (I meant to reply to the original descriptor buffer post but oh well)
22:02gfxstrand[d]: dadschoorse[d]: The Intel drivers use RGBA32UI texel buffers for UBOs. 🤡
22:02gfxstrand[d]: Or did for a long time. On DG2+, the dataport is fast enough it's not a big deal
22:03gfxstrand[d]: SKL era, I think it's dataport for direct loads and texture for indirect. It's been a while, though.
22:04dadschoorse[d]: R32 texel buffers writes in hlsl/d3d are really annoying, because the shader contains no format info, and the writes store x for all components instead of undef for the unused ones
22:10redsheep[d]: With more testing, yeah it looks like that branch has essentially the same performance in talos with and without no_cbuf, so yeah the heuristics around that maybe makes sense to change? If it is a regression it's very small now, not more than 3%
22:11redsheep[d]: gfxstrand[d]: I will do a quick build over there as well to try to get some testing in too
22:14redsheep[d]: Hopefully it is still far enough behind main to not be broken
22:31redsheep[d]: Ok, minecraft, heaven, and supertuxkart work on zink+nvk+edb which is good
22:42redsheep[d]: Horizon zero dawn has the same foliage artifacts, but works. Deep rock galactic works just like before. Tested a number of known fails too, and they're in the same state, so seems like vkd3d-proton is no worse off.
22:46redsheep[d]: As expected the zink session isn't magically fixed
22:47redsheep[d]: gfxstrand[d]: No apparent surprises with EDB. Seems like 30580 is solid ^
22:53gfxstrand[d]: :frog_party:
22:53gfxstrand[d]: My CTS run died (kernel issues) so I'm gonna try one more time before assigning Marge.
22:54gfxstrand[d]: But it's also 6:00 PM here so I'm pretty much done. I may still check it and assign marge but that's it for the week.
22:59redsheep[d]: gfxstrand[d]: Sounds good, enjoy your weekend