00:25fdobridge: <karolherbst🐧🦀> remove the `RUN_PASS(2, MemoryOpt, run);` line
00:26fdobridge: <mhenning> ^ in nv50_ir_peephole
00:27fdobridge: <mhenning> (which is a lousy name for that file imo)
00:33fdobridge: <karolherbst🐧🦀> I just hope we can get rid of it soon
00:35fdobridge: <mhenning> get rid of what?
00:36fdobridge: <mhenning> I imagine codegen as a whole will live for a while longer, at least for nv50 if not for other archs
00:39fdobridge: <karolherbst🐧🦀> I'd rather add support for those older archs to NAK than to keep maintaining codegen
00:43fdobridge: <mhenning> really? here I was trying to slowly clean up the worst of codegen because I assumed it would live another decade
00:44fdobridge: <airlied> I think both will be true 🙂
00:44fdobridge: <mhenning> that's also possible 🙂
00:46fdobridge: <karolherbst🐧🦀> uhhh
00:46fdobridge: <karolherbst🐧🦀> wait until somebody adds nv30 support to NAK in like 5 years, because why not
00:48fdobridge: <karolherbst🐧🦀> every time I think about refactoring codegen I'm can't find the spot where to begin, because refactoring one spot just requires to to refactor everything else, because it's all to interdependent
00:51fdobridge: <mhenning> yeah, whenever I try to make a bigger change to codegen it doesn't go well. eg. I tried rewriting the merge/split handling in RA at one point, but I somehow managed to make things worse overall despite the old algorithm being obviously incorrect
00:55fdobridge: <mhenning> or I was pretty excited about https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22118 since it represents a way to rely less on MemoryOpt, but I somehow regressed shaderdb a bunch (maybe due to flimsy heuristics elsewhere)
00:58fdobridge: <karolherbst🐧🦀> I think the only way it can work is if we move most of the normal optimizations into the nir level, make `from_nir` _less_ dumb (as in: don't workaround silly codegen problems) and then things should just fall into place
01:00fdobridge: <karolherbst🐧🦀> the issue what I'm seeing is, that you can't break ubo loads into 32 bit pieces
01:00fdobridge: <karolherbst🐧🦀> we can do 64 bit ubo loads 🙂
01:01fdobridge: <karolherbst🐧🦀> just not with a direct load
01:01fdobridge: <karolherbst🐧🦀> ehh wait.. `LDC` can do 64 bit loads anyway
01:02fdobridge: <karolherbst🐧🦀> commenting on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22118/diffs?commit_id=d2f2ab9ca9f4fb40d0803b84834f36f92d5cd8de
01:03fdobridge: <karolherbst🐧🦀> also kernel input lowering to lower_uniform is wrong in most cases
01:03fdobridge: <karolherbst🐧🦀> otherwise we wouldn't have bothered with adding it
01:03fdobridge: <karolherbst🐧🦀> `kernel_input` is _always_ byte addressing, `load_uniform` is not
01:04fdobridge: <mhenning> well... we used to break all ubo loads into 32-bit pairs, then combine those into instructions where possible and re-merge them into 64-bit at MemoryOpt
01:04fdobridge: <karolherbst🐧🦀> (I also hate `load_uniform` btw, can we kill it?)
01:04fdobridge: <karolherbst🐧🦀> yeah, because codegen is stupid
01:05fdobridge: <karolherbst🐧🦀> but if we want to remove the memoryOpt pass, then we have to make codegen accept those 64 bit ones without breaking
01:06fdobridge: <karolherbst🐧🦀> I'm sure it doesn't break for all things, but...
01:06fdobridge: <karolherbst🐧🦀> I think some 64 bit loads make it through on purpose, can't remember which one tho
01:07fdobridge: <karolherbst🐧🦀> anyway.. it's all funky, and when I wrote the translation code is was close to Christmas and I forgot about most the details anyway 🙃
01:07fdobridge: <mhenning> I'm actually the one who moved us to emitting 64-bit ubo loads directly from nir. I think something is broken in the heuristics for combining the ubo loads into other instructions
01:07fdobridge: <mhenning> which is why that one regresses
01:08fdobridge: <karolherbst🐧🦀> yeah.. potentially
01:08fdobridge: <karolherbst🐧🦀> I could probably tell why it's regressing looking at some examples
01:08fdobridge: <mhenning> also the load_kernel doesn't get lowered to load_uniform, it just uses that bit
01:09fdobridge: <mhenning> yeah, I haven't gotten to that point on that patch set yet
01:09fdobridge: <karolherbst🐧🦀> ohh, right. it's the var type, not the intrinsic
01:10fdobridge: <mhenning> I've been wondering if I should submit https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22118/diffs?commit_id=a06833decef6e05d86531f8e686c99ef55f71cca separately so we can land it earlier
01:11fdobridge: <karolherbst🐧🦀> was thinking the same
01:11fdobridge: <karolherbst🐧🦀> I think I tried it once and it broke for weirdo reasons
01:11fdobridge: <karolherbst🐧🦀> maybe it's fine now
01:12fdobridge: <mhenning> The branch as a whole does not regress cts
01:12fdobridge: <karolherbst🐧🦀> but when I checked it was before that `lower_uniforms_to_ubo` option existed
01:13fdobridge: <karolherbst🐧🦀> what I kinda want to see and what I think would simplify a lot of stuff is to make all memory entirely byte based
01:13fdobridge: <karolherbst🐧🦀> and after that doing all that stuff should get easy
01:15fdobridge: <karolherbst🐧🦀> offset in the ubo should always be in bytes and I suspect it would already simplify a lot of things
01:18fdobridge: <mhenning> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22815
02:57fdobridge: <gfxstrand> Ugh... Talos keeps segfaulting and I don't know why. It appears to be inside the game, though. 😓
03:28fdobridge: <gfxstrand> Found one maxwell bug: https://gitlab.freedesktop.org/nouveau/mesa/-/commit/0b76ea158e8fcc658f1eee9e59ab74f4fd1e559a
03:34Skillingford: Don't let Micky Mouse diddle your little boy! Mickey was busted by Chris Hansen on To Catch a Predator trying to buttscrew a 13 y/o boy in a sting operation! Read all about it here: https://pastebin.com/edvNf8kn Ron Desantis 2024
03:38fdobridge: <gfxstrand> Oops... I may have just reported our IRC bridge to Discord. 😓
03:38fdobridge: <gfxstrand> Saw a spam and missed that it was coming in from IRC.
03:38fdobridge: <gfxstrand> @Mr Fall🐧 ^^
05:51fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> That's interesting
06:25HdkR: Needs to be obliterated from this side yea
09:52avoidr: karolherbst, I just now got another display freeze but with VDPAU compiled out and no firmware. Is there anything I can do about it short of replacing my card?
09:53avoidr: Same as always, on mpv quit, this time no load whatsoever, though.
10:41karolherbst: avoidr: I suspect you are on mesa 22.3 or newer?
10:41karolherbst: but it's odd... so you just use mpv with no acceleration whatsoever and it freezes?
10:42karolherbst: I'll try to look into it this week as I fixed another multithreading fix regression last/this week and might as well fix that mpv stuff
11:03avoidr: media-libs/mesa-22.3.7-r1
11:04avoidr: karolherbst, it's a very rare occurence, it seems random. Maybe high load helps with it, though.
11:04avoidr: Well, not very rare. Happens once a week I guess. Something like that. On normal usage.
11:07avoidr: I don't know if there isn't any acceleration going on whatsoever. But mpv(1) says that --hwdec=no is the default, and I have not set it in any config files myself. mpv still says [gpu], though, not sure what that means.
11:08avoidr: Ok, it says [gpu] even if I set --hwdec=no explicitly.
11:09avoidr: I was thinking maybe fullscreen has something to do with it, too. Since that's when my screen never tears. I know the last two times my screen froze I'm pretty sure they were fullscreened. Don't remember about the first time it happened.
11:10avoidr: Happens on nouveau and modeset DDX drivers all the same.
11:19avoidr: I can try running with --vo=x11 for a while. "Shared memory video output driver without hardware acceleration that works whenever X11 is present."
12:29karolherbst: avoidr: yeah.. an issue which only happens once a week is pure pain to debug.. maybe I find some races or something odd in the code. I think the video acceleration is still a bit broken in regards to threading, but less so than before
12:29karolherbst: I wouldn't be surprised if you'd see less crashes then with mesa 22.2 or older
12:30avoidr: "then", or "than"?
12:30karolherbst: than
12:31avoidr: I also want to say that I was on hiatus from nouveau for the past two years or so. And I never had issues with nouveau and this card before. I used this card for 10 years. But also a lot has changed from the time I switched cards.
12:32karolherbst: mhh yeah.. applications are starting to use more acceleration and stuff. mpv is kinda a weird oddball here
12:33avoidr: Why is mpv an oddball?
12:33karolherbst: in the past nouveau was completely and entirely broken if an application was using two "gallium contexts" which e.g. happens if you mix opengl and vdpau acceleration
12:33karolherbst: as long as you only do vdpau or only GL it's fine
12:34karolherbst: but applications like mpv _might_ use GL for displaying and vdpau for video acceleration
12:34avoidr: Aha.
12:35karolherbst: other applications (mostly electron and cef based ones like slack/vscode/discord) use multiple gl contexts so that was always broken, but fixed in 22.3
12:35karolherbst: but something is funky with mpv and given the project has several forks or something it's always hard to tell what users are using specifically
12:35avoidr: Mhm.
12:36karolherbst: or rather mplayer has multiple forks and mpv just has some.. I dunno, different things going on. So if you'd used mplayer in the past, but now mpv this might actually change things
12:36avoidr: I've used mpv for a while longer now.
12:37karolherbst: anyway.. there might be other issues, but kinda hard to tell.. do you have a second machine? In case it locks up again you should be able to SSH into it and retrieve logs or do a proper shutdown
12:37karolherbst: or at least sync the fs so you can check the logs on next boot
12:39avoidr: I reboot via the magic sysrq key. REISUB.
12:39karolherbst: ahh
12:39karolherbst: so you should have logs?
12:39avoidr: What kind of logs do I need? I honestly would know. Not sure I keep them between boots.
12:40karolherbst: or wait.. is it a force reboot or telling init to reboot?
12:40avoidr: *wouldn't
12:40karolherbst: mhh..
12:40karolherbst: usually just checking `journalctl --boot -1` and checking for kernel and/or userspace errors would do the trick
12:40avoidr: Not sure now. Might be force.
12:40avoidr: If only I had journalctl.
12:41karolherbst: yeah, then I have no idea :) depends highly on your logging daemon and where it stores X session/wayland session/dmesg logs
12:42avoidr: Wait, I seem to have multiple days in /var/log/kern.log
12:44avoidr: May 3 11:46:35 BDZ kernel: nouveau 0000:01:00.0: X[2533]: nv50cal_space: -16
12:44avoidr: May 3 11:46:43 BDZ last message buffered 59 times
12:44avoidr: May 3 11:48:16 BDZ kernel: sysrq: Keyboard mode set to system default
12:44avoidr: This makes sense. After those I get "Linux version" etc from boot.
12:45karolherbst: mhhhh
12:45karolherbst: okay, so this is purely a "running out of VRAM" issue
12:46karolherbst: which we don't handle very well
12:46karolherbst: especially not if it happens within the X server
12:46avoidr: Heh, funny. Is it possible that the VRAM size is detected wrongly or something?
12:46karolherbst: probably not
12:47karolherbst: just userspace requiring more VRAM these days
12:47karolherbst: how much VRAM do you have?
12:47avoidr: GPU package says 512 MB.
12:48avoidr: Yes, dmesg seems to confirm.
12:48karolherbst: tough
12:49avoidr: Is it not much anymore?
12:49karolherbst: could also be some weird race or something
12:49karolherbst: well.. I have a GPU with 48GB VRAM here
12:49avoidr: lol
12:49karolherbst: but most of the new low end ones have like 4GB+
12:49fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> i have 4 GB VRAM
12:50avoidr: I used to have RAM as big as my VRAM now. And that was plenty.
12:50karolherbst: seems like there are some with 2GB around
12:50fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> And I struggle with GSP for some reason (nvidia-open handles that way better)
12:50karolherbst: but yeah.. by today standards 512MB ain't much
12:50karolherbst: GeForce GT 1010 which is like the lowest low end possible is like 2GB
12:51avoidr: But I would vote for a race, since it seemed to want to freeze eagerly the other time when I was updating my system/compiling.
12:51karolherbst: yeah.. it should be handled better
12:51karolherbst: are you using the nouveau DDX?
12:51karolherbst: or modesetting?
12:51avoidr: Now I'm on modesetting.
12:51avoidr: But this has happened on nouveau, too.
12:51avoidr: The first time.
12:51karolherbst: mhh
12:52avoidr: On second time I was already on modesetting. It happened three times in total.
12:52karolherbst: the annoying part is that how the driver is written it's really really hard to solve this
12:52avoidr: That's very sad.
12:52karolherbst: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19543 this MR _might_ help in those cases
12:53karolherbst: as it stops blocking in some cases
12:53karolherbst: kinda planned to finish this up as it should mitigate some of those freezing up issues
12:53avoidr: The annoying part is also that even if I apply this, I can't measure the results beyond feelings right now.
12:53karolherbst: yeah
12:53karolherbst: but might be worth a shot
12:54avoidr: Maybe I'll take some time to try and provoke it aggressively.
12:54karolherbst: if it's about VRAM usage, you might trigger it by doing some WebGL things or something
12:56avoidr: I'll try busying my CPU a lot with something and watching some stuff.
13:01avoidr: Another question: Is it possible, in principle, to implement a "TearFree", like amdgpu has, in the DDX driver? Is this a driver thing, or a GPU thing?
13:03karolherbst: do you see tearing with the modesetting ddx? If yes, enabling DRI 3 on the nouveau one might help
13:04avoidr: I think I tried that already, modesetting and nouveau with DRI2/3. I should try again, if it makes any difference, but so far I don't remember it being perfect on any combination.
13:05avoidr: I only have zero tears on mpv on fullscreen.
13:13karolherbst: don't really see why it should tear with modesetting and dri 3 enabled... though could be that we don't sync something properly up
13:21avoidr: Right, on modesetting, DRI3 is the default.
13:58avoidr: Here are the docs for the magic sysrq: https://www.kernel.org/doc/html/latest/admin-guide/sysrq.html
14:30fdobridge: <DadSchoorse> what subgroup operations does nvidia hw support? only shuffle or also some more specific opcodes?
14:50fdobridge: <karolherbst🐧🦀> also some more specific ones
14:51fdobridge: <karolherbst🐧🦀> we have a swizzle add
14:51fdobridge: <karolherbst🐧🦀> so you can do additions across lanes
14:51fdobridge: <karolherbst🐧🦀> most there to help implementing ddx/ddy and TXD lowering
14:51fdobridge: <karolherbst🐧🦀> *mostly
14:53fdobridge: <karolherbst🐧🦀> and we have a native vote
14:53fdobridge: <karolherbst🐧🦀> and I think that's it?
14:54fdobridge: <karolherbst🐧🦀> @DadSchoorse ^^
15:14fdobridge:<gfxstrand> has no idea why the without_format tests are suddenly running with rebased NVK
15:14fdobridge: <gfxstrand> _has no idea why the `without_format` tests are suddenly running with rebased NVK_ (edited)
15:15fdobridge: <gfxstrand> _has no idea why the_ `without_format` _tests are suddenly running with rebased NVK_ (edited)
15:18fdobridge: <gfxstrand> But only with deqp-runner, of course. 🙄
15:20fdobridge: <DadSchoorse> okay, I was asking because amd has a lot of more optimal instructions if the shuffle is only based on the invocation id
15:21fdobridge: <DadSchoorse> but I'm still unsure if upstreaming <https://gitlab.freedesktop.org/DadSchoorse/mesa/-/commit/901e5233f77de5cbfadb2dcc1eacbddbbc6ee35e> is worth the time
15:27fdobridge: <karolherbst🐧🦀> mhh we do have some weirdo modifiers on shuffle tho
15:27fdobridge: <Mohamexiety> they fail while running them normally with `deqp-vk`?
15:29fdobridge: <karolherbst🐧🦀> but yeah.. not sure if any of them can be used for such optimizations anyway
16:34fdobridge: <gfxstrand> Because I was running my NAK branch, not NVK... *sigh*
16:56fdobridge: <gfxstrand> I probably shouldn't have picked names where one is the other kinda flipped. Not good for my dyslexic brain.
17:02fdobridge: <gfxstrand> PSA: Just pushed a rebase. Picked up a frexp fix from @mhenning and the new device properties framework from Constantine.
17:12fdobridge: <gfxstrand> @Mr Fall🐧 no idea if you like this fix but it shuts up valgrind on some tests: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22834
17:12fdobridge: <gfxstrand> No rush. I'll just carry locally for now.
17:20fdobridge: <gfxstrand> Oh, shit... This kernel doesn't have the helper invocation fix
17:22fdobridge: <gfxstrand> Let's see if I can manage a backport
17:22fdobridge: <gfxstrand> Otherwise, I may need @Mr Fall🐧 to help out
17:24fdobridge: <gfxstrand> Rebase was easy. Let's hope it works. 😅
17:27fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> No patch failures and vkcube still works
17:33fdobridge: <gfxstrand> ```
17:33fdobridge: <gfxstrand> [ 134.717386] asynchronous wait on fence nouveau:Dirt4[3914]:cf9 timed out
17:33fdobridge: <gfxstrand> [ 145.467371] asynchronous wait on fence nouveau:Dirt4[3914]:d04 timed out
17:33fdobridge: <gfxstrand> [ 155.711580] [TTM] Buffer eviction failed
17:33fdobridge: <gfxstrand> ```
17:33fdobridge: <gfxstrand> 😩
17:33fdobridge: <gfxstrand> But it got to the intro video this time
17:38fdobridge: <Mohamexiety> would rebasing on my local branch be involved or is it just one `git rebase` away?
17:39fdobridge: <Mohamexiety> (haven't done this before, sory)
17:39fdobridge: <Mohamexiety> (haven't done this before, sorry) (edited)
17:39fdobridge: <gfxstrand> I'd do `git rebase -i` and make sure it only tries to pick up your patches.
17:39fdobridge: <gfxstrand> Otherwise, should be easy
17:39fdobridge: <Mohamexiety> got it, thanks!
17:47fdobridge: <gfxstrand> Ugh... Everything is running into MAX_BUFFERS
17:50fdobridge: <karolherbst🐧🦀> just do the userspace stuff
17:51fdobridge: <karolherbst🐧🦀> like that PRIV_REG thing I've added, it should work just as well on gm200+
17:52fdobridge: <gfxstrand> I just backported the kernel patch. It was almost clean.
17:52fdobridge: <gfxstrand> Now everything works until it hits the BO limit.
17:55fdobridge: <karolherbst🐧🦀> good to know, I should poke Ben about that patch again I guess
18:04fdobridge: <gfxstrand> which patch?
18:05fdobridge: <gfxstrand> Oh, right, helpers
18:05fdobridge:<gfxstrand> wonders if she can just bump the BO limit...
18:05fdobridge: <karolherbst🐧🦀> probably
18:05fdobridge: <karolherbst🐧🦀> I don't think there is actually a hardware limit
18:06fdobridge: <karolherbst🐧🦀> just I think it's used for stack allocations somewhere?
18:06fdobridge: <gfxstrand> Not even that from a quick grep
18:06fdobridge: <karolherbst🐧🦀> mhhh
18:06fdobridge: <karolherbst🐧🦀> okay then 🙂
18:09fdobridge:<gfxstrand> bumps it to 8192
18:09fdobridge: <gfxstrand> I mean, yeah, there's a stack array in NVK but meh
18:10fdobridge: <gfxstrand> 1024 is nowhere near enough
18:11fdobridge: <karolherbst🐧🦀> for GL it was enough 🙃
18:11fdobridge: <gfxstrand> I'm trying to get a demo to run here. There are no rules. 😁 🔥
18:11fdobridge: <karolherbst🐧🦀> well.. using real ubos might actually help with that 😄
18:11fdobridge: <karolherbst🐧🦀> especially if they are small
18:12fdobridge: <gfxstrand> I mean, for GL, people seem to think that only succeeding RA most of the time is enough. 😛
18:12fdobridge: <karolherbst🐧🦀> I mean.. yeah
18:12fdobridge: <gfxstrand> But, yeah, GL limits are such that 1024 should be plenty
18:12fdobridge: <gfxstrand> Unless you're doing bindless
18:12fdobridge: <karolherbst🐧🦀> nah
18:12fdobridge: <karolherbst🐧🦀> the difference is, we don't chain push buffers
18:13fdobridge: <gfxstrand> Without bindless, the number of bindings is low enough that it'll always fit.
18:13fdobridge: <gfxstrand> You can always split the batch small enough.
18:13fdobridge: <karolherbst🐧🦀> and we do 64k? buffers
18:13fdobridge: <gfxstrand> With bindless or Vulkan you can have 10k UBOs bound at one time.
18:13fdobridge: <gfxstrand> 1024
18:13fdobridge: <karolherbst🐧🦀> so... really hard to run into limits here
18:13fdobridge: <gfxstrand> It's dismal
18:13fdobridge: <karolherbst🐧🦀> uhh
18:13fdobridge: <karolherbst🐧🦀> funky
18:13fdobridge: <karolherbst🐧🦀> I'm still convinced that bindless ubos just work on top of the unused ubo slots
18:13fdobridge: <karolherbst🐧🦀> and are filled round-robin or whatever
18:14fdobridge: <gfxstrand> With bindless GL you can't have 10k UBOs, just 10k images but still
18:14fdobridge: <gfxstrand> With Vulkan you can have nearly infinity of anything
18:14fdobridge: <karolherbst🐧🦀> yeah...
18:14fdobridge: <gfxstrand> Point is, lots more than 1024 BOs
18:14fdobridge: <karolherbst🐧🦀> I wonder if LDG.CONSTANT is that much faster
18:14fdobridge: <gfxstrand> Let's see if talos runs now. 😄
18:16fdobridge: <karolherbst🐧🦀> I was always under the impression that you can fill ubos from within the command buffers, but... mhh maybe it's just something stuck in my brain forever and was forever false
18:28fdobridge: <gfxstrand> There's a thing for that but IDK how it actually works.
18:28fdobridge: <gfxstrand> Like, does the new data end up in the backing buffer? Do you need a backing buffer? Is it all in some magic memory somewhere and setting constant data from a UBO does a copy? IDK
18:29fdobridge: <gfxstrand> It's on my list of things I really need to grok if we're gonna make NVK go brrrr
18:31fdobridge:<gfxstrand> rebuilds in release to make those pesky nv50_ir_from_nir asserts go away 😅
18:32fdobridge: <gfxstrand> _rebuilds in release to make those pesky_ `nv50_ir_from_nir` _asserts go away 😅_ (edited)
18:32fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> The 1 << 11 one is very annoying
18:33fdobridge: <gfxstrand> What's really frustrating is how hard it is to debug anything in proton
18:33fdobridge: <gfxstrand> A debugger would work wonders
18:35fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> Just use gdb 🐸
18:42fdobridge: <gfxstrand> You say that as if getting GDB to connect through wine is easy. Maybe it's easier these days? Been a while, TBH.
18:43fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> Proton has `WINEDEBUG=+gdb` variable for better GDB integration (but you'll still have to do a loop looking for the game process)
18:51fdobridge: <gfxstrand> Skyrim is failing to find an adapter (probably DXVK giving up)
18:55fdobridge: <gfxstrand> Ok, that was because I didn't advertise 1.3
18:55fdobridge: <gfxstrand> (I hacked it down to 1.1 which is aparently too low)
18:56fdobridge: <gfxstrand> Come on... I just want ONE game to work...
19:03fdobridge: <Mohamexiety> portal?
19:04fdobridge: <Mohamexiety> that should be simpler since it's dx9
19:05fdobridge: <Mohamexiety> for native vulkan/no DXVK, I only know of talos sadly 🐸
19:05fdobridge: <gfxstrand> Talos does run
19:05fdobridge: <gfxstrand> So I guess I do have one. 😅
19:19fdobridge: <airlied> Dota2 got to loading screen, but not sure I've seen it run
19:19fdobridge: <phomes> I have played "Serious Sam Fusion 2017 (beta)" on NVK a few times
19:34HdkR: X4: Foundations is a native Linux game with Vulkan
19:34HdkR: Ender Lilies is a native UE4 game with Vulkan
19:35HdkR: Oh, Hollow Knight is Vulkan on Linux
19:36HdkR: Forsaken Remastered and some other Kex Engine games
19:37HdkR: There's a decent number :)
19:37fdobridge: <gfxstrand> Oh, yes, many games exist. But do they run on this crappy maxwell laptop? That's the real question. 😛
19:38HdkR: Hollow Knight for Unity Engine, Ender Lilies for Unreal, X4/Forsaken for custom. Unity and Unreal being the most interesting
19:39fdobridge: <Esdras Tarsis> Hollow Knight works on NVK
19:39HdkR: Nice
19:41HdkR: DXVK is obviously the big one since that would mean like 90% of the Steam store would be the playground
19:42fdobridge:<gfxstrand> buys hollow knight
19:45fdobridge: <Esdras Tarsis> Hollow Knight on NVK (screenshot from January)
19:45fdobridge: <Esdras Tarsis> https://cdn.discordapp.com/attachments/1034184951790305330/1103406965222293555/Screenshot_from_2023-01-06_10-48-08.png
19:46fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> Did it eork after setting Vulkan 1.3?
19:47fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> Did it work after setting Vulkan 1.3? 🐸 (edited)
19:50fdobridge: <airlied> @gfxstrand is the demo of NAK?
20:05fdobridge: <gfxstrand> No, just NVK
20:05fdobridge: <gfxstrand> Skyrim is hanging. Skyrim HD gets to the menu okay and then hangs.
20:05fdobridge: <gfxstrand> Both are faulting, IIRC.
20:06fdobridge: <gfxstrand> And this kernel has basically zero GPU recovery because it's crap.
20:06fdobridge: <gfxstrand> Hollow Knight works great though. 😄
20:09HdkR: \o/
20:09HdkR: Aperture Desk Job is one if you want to try Source2 Vulkan I guess :P
20:10fdobridge: <airlied> I feel I should taunt you to make it a NAK demo 😛
20:10HdkR: Although I guess one of the Dota games also do that
20:12fdobridge: <Mohamexiety> haha, NAK demo would be fun
20:12fdobridge: <Mohamexiety> will the demo be public btw?
20:16fdobridge: <gfxstrand> I'm not going to get more shader stages and a full Maxwell port done in the next 3 days. 😛
20:16fdobridge: <airlied> do you need sleep or something? 🙂
20:16fdobridge: <gfxstrand> No, I'm not streaming it or anything. It's just to show off to folks at Collabora
20:16fdobridge: <gfxstrand> Even without sleep, that's a tall order.
20:17fdobridge: <gfxstrand> Is that the DXVK HUD? It's not working for me for some reason.
20:17fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> How about 3 years?
20:17fdobridge: <Mohamexiety> ah I see. good luck!
20:18fdobridge: <gfxstrand> Oh, given that I've been working on NVK and NAK for about 1 year so far, you can get a lot done in 3 years.
20:18fdobridge: <gfxstrand> 3 days, though, is a bit more limiting. 😛
20:18fdobridge: <gfxstrand> 365x more limiting, in fact.
20:19fdobridge: <Esdras Tarsis> Mangohud
20:19fdobridge: <airlied> I ate a donut a few days ago and I've nearly implemented lavapipe mesh shaders because of it 😛
20:19fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> DXVK HUD should work on NVK (the graph needs some shader magic though)
20:20fdobridge: <Esdras Tarsis> I think it needs vulkan 1.2
20:57fdobridge: <karolherbst🐧🦀> meanwhile I'm almost done with the iris SVM rework...
20:58fdobridge: <airlied> @Mr Fall🐧 you should implement the intel svm replacement
20:58fdobridge: <airlied> as I think that's what their sycl really wants anyways
20:58fdobridge: <karolherbst🐧🦀> probably
20:58fdobridge: <karolherbst🐧🦀> the thing is.. it requires the same changes in the iris driver
20:58fdobridge: <karolherbst🐧🦀> soo...
20:59fdobridge: <karolherbst🐧🦀> but yeah.. I probably will look into that once I get blender to use rusticl 🙃
21:00fdobridge: <karolherbst🐧🦀> what's the main difference between the intel stuff and CL's one? less reqs?
21:02fdobridge: <karolherbst🐧🦀> ahh it's single device based
21:02fdobridge: <karolherbst🐧🦀> and the allocation is more specific
21:02airlied: no cl_mems :)
21:02airlied: https://registry.khronos.org/OpenCL/extensions/intel/cl_intel_unified_shared_memory.html hasa nice list
21:02airlied: because I asked for it
21:03fdobridge: <karolherbst🐧🦀> so what happens if you use that pointer with `USE_HOST_PTR`?
21:03fdobridge: <karolherbst🐧🦀> from a quick look it seems to require way more tracking on the runtime side than the CL stuff
21:04fdobridge: <karolherbst🐧🦀> but at least it's not so dumb and allocates for all devices in a context
21:07fdobridge: <airlied> that's question 20 btw the host ptr one
21:08fdobridge: <karolherbst🐧🦀> `UNRESOLVED` 🥲
21:08fdobridge: <karolherbst🐧🦀> but yeah...
21:08fdobridge: <karolherbst🐧🦀> that you can use it for backing random cl_mem objects is really the annoying
21:11HdkR: Just do the Pascal thing of supporting 49-bit VA, so it can always know which view is device and which is host :P
21:11fdobridge: <karolherbst🐧🦀> anyway, I think my runtime code is already more or less correct, shouldn't be too hard to add the Intel stuff on top
21:18HdkR: Wonder if latest hardware bumped that to 58-bit finally for 57-bit server CPUs
22:38fdobridge: <gfxstrand> Okay, even with heaps fixed, maxwell is still a trash fire. 😭
22:38fdobridge: <gfxstrand> But hey, hollow knight works. I'm gonna take that as a win.
22:42HdkR: "NVK now works on all Unity games that use Vulkan"
22:54fdobridge: <Esdras Tarsis> Now try Streets of Rage 4 and Terraria
22:54fdobridge: <Esdras Tarsis> It should work
23:18fdobridge: <gfxstrand> As much as I hate fixing codegen... https://gitlab.freedesktop.org/nouveau/mesa/-/merge_requests/220
23:18fdobridge: <gfxstrand> @Mr Fall🐧 That one could use real code review by you
23:18fdobridge: <gfxstrand> I'm CTSing it now
23:18fdobridge: <gfxstrand> So far so good, though.
23:30avoidr: Is it possible to query VRAM usage?
23:31avoidr: Something like free(1).
23:45HdkR: nvtop support when? :P
23:49avoidr: Don't laugh, I was told that 512 MB VRAM is not much anymore ._.
23:50HdkR: Nah, I actually want nvtop support everywhere
23:50fdobridge: <karolherbst🐧🦀> yeah.. probably fine
23:51avoidr: karolherbst_, thanks for your assistance today.
23:52HdkR: Sticking the memory usage in drm_info would be a first good step to nvtop support :)
23:53HdkR: er, fdinfo
23:53HdkR: Whatever the kernelspace thing is called I guess
23:54fdobridge: <Mohamexiety> avoidr: we now have 24GB VRAM GPUs on the high end
23:54fdobridge: <karolherbst🐧🦀> I have a 48GB VRAM GPU 😄
23:55karolherbst_: avoidr: yeah.. there should be a way.. GALLIUM_HUD might have a graph for it
23:55karolherbst_: check with GALLIUM_HUD=help
23:55HdkR: NVIDIA's 80GB monster wants a word
23:56fdobridge: <Mohamexiety> you have one of the Ada 6000s? 😮 damn that's really impressive
23:56fdobridge: <karolherbst🐧🦀> RTX a6000 actually
23:57fdobridge: <karolherbst🐧🦀> I think it's broken tho
23:57fdobridge: <Mohamexiety> ah. the older brother I suppose. how is it broken?
23:57fdobridge: <karolherbst🐧🦀> AER errors and GPU randomly crashes
23:57fdobridge: <karolherbst🐧🦀> I also have the RTX 6000, so that's fine 😄
23:58fdobridge: <Mohamexiety> hahahaha
23:58fdobridge: <karolherbst🐧🦀> the 6000 is from nvidia, not sure who gave me/us the a6000
23:58fdobridge: <karolherbst🐧🦀> maybe also nvidia
23:58fdobridge: <Mohamexiety> yeah that's neat
23:58fdobridge: <karolherbst🐧🦀> well.. they said, it's cheaper for them to give us those GPUs than "normal" GPUs
23:59fdobridge: <Mohamexiety> ...huh. that's interesting
23:59fdobridge: <karolherbst🐧🦀> yeah.. the others they'd have to buy first
23:59fdobridge: <karolherbst🐧🦀> so they'd have to sell market prices
23:59fdobridge: <karolherbst🐧🦀> ehh
23:59fdobridge: <karolherbst🐧🦀> pay
23:59fdobridge: <Mohamexiety> ohh right
23:59fdobridge: <Mohamexiety> yeah