00:12 mhenning[d]: karolherbst[d]: is the end_group referring to invalidating reuse flags?
00:13 karolherbst[d]: No idea tbh. Would have to check, but not sure I could share that info anyway, would have to do some digging first
00:13 mhenning[d]: fair enough
01:06 x512[m]: How heavy is NVK device? It it fine to create 10000 of them (for many small independent clients)?
01:09 mhenning[d]: I don't think making 10,000 of them is a typical usecase
01:10 orowith2os[d]: 10k, I'd expect the computer to burn up and crash
01:10 orowith2os[d]: Does radv even let you do that...
01:12 x512[m]: Many windows (some of them may be even not visible) etc.
01:12 orowith2os[d]: 10k though?
01:14 mhenning[d]: yeah I can't say making 10,000 windows sounds like a typical usecase either
01:15 orowith2os[d]: Either way. Uh. You should be fine? If you hit limitations, file a bug?
01:16 orowith2os[d]: You'll get a response of "what the fuck are you doing", "how are we even supposed to deal with that", or "L Bozo"
01:16 x512[m]: This with higher resolution :) https://www.youtube.com/watch?v=eFSVK3B7yTs
01:17 x512[m]: I am analyzing resistance of GUI system to high load after introducing GPU rendering.
01:18 orowith2os[d]: So this is why they want absolute window positioning in Wayland...
01:18 x512[m]: It looks like GUI system will become much less resistant.
01:18 orowith2os[d]: /j
01:18 x512[m]: You can do this on Haiku.
01:19 orowith2os[d]: You'd probably hit limitations in the compositor first
01:19 orowith2os[d]: Having to constantly create and destroy and resize windows like that
01:19 x512[m]: So it is good benchmark.
01:20 orowith2os[d]: An unrealistic benchmark, imo, but sure, I guess
01:20 orowith2os[d]: Oh my God, I swapped from yt to discord and it's playing in the background. Why did I have to pay for yt premium.
01:21 x512[m]: At least GUI system must not crash or cause existing clients to fail.
01:22 orowith2os[d]: If you're designing with the assumption that something like this could happen, it makes sense?
01:23 orowith2os[d]: It's easier to deal with if apps are isolated. If something is doing something obviously malicious (or buggy) like creating hundreds of thousands of window system requests when it shouldn't be, it could get throttled or killed
01:23 orowith2os[d]: Just have to know what the stopping point is
01:24 x512[m]: I expect that right behavior is window creation command should fail, but client should continue operation in case of out of resources.
01:25 redsheep[d]: I don't see that recreating this should even require destroying the window if you're allowed to hide them or make them 1x1 and stacked in a corner
01:26 redsheep[d]: Even if you wanted to do the thing where some cover more area, just resize a constant number
01:27 HdkR: Doesn't the old x11perf application have a benchmark for how quickly children window can be smashes out? Sounds similar but for wayland :P
01:48 ermine1716[d]: running test suites with piglit causes many windows to be created
02:17 gfxstrand[d]: ermine1716[d]: Running piglit with X11... Those were the bad old days...
02:18 gfxstrand[d]: x512[m]: An NVK device isn't probably ridiculously heavy, maybe a megabyte or so? But there's likely a limit in the GSP for how many contexts can exist.
02:19 orowith2os[d]: You should find out :akipeek:
02:19 ermine1716[d]: gfxstrand[d]: it creates X11 windows even under wayland
02:20 gfxstrand[d]: Yeah, there's a reason piglit has a GBM backend.
02:21 gfxstrand[d]: The reality bad old days are if you run it without a compositor. Then you have to run one test at a time or else two windows might end up on top of each other and the tests might interfere.
02:21 gfxstrand[d]: :frog_clown:
02:21 orowith2os[d]: We love X11
02:22 gfxstrand[d]: At one point, I think I was starting to nested Weston just to contain piglit.
02:22 gfxstrand[d]: The old school OpenGL and OpenGL ES test suites used to have that problem as well.
02:23 orowith2os[d]: Wouldn't it be cool if piglit had a custom made wl compositor that laid them all out on screen :monad:
02:23 orowith2os[d]: Like back in the days of split screen games. Except more. And for piglit tests
02:23 gfxstrand[d]: 😂
02:24 gfxstrand[d]: Maybe. If you really want to see them all. Or you can just use the GBM backend and no windows ever get created.
02:25 orowith2os[d]: It's probably not too much work. Would be easier if piglit supported native Wayland, which I'm not sure if it does (from context, probably not?)
02:39 leftmostcat[d]: gfxstrand[d]: My last job had me working on a sizable desktop application where, if you blurred focus on the main window during testing, tests would fail. There was a headless mode, but a bunch of tests straight didn't work under it.
03:31 gfxstrand[d]: orowith2os[d]: Not really. There's not much difference between native Wayland and XWayland as far as most piglit tests are concerned.
03:32 orowith2os[d]: I'm bringing it up, because it would be easier to work with if I didn't have to have an xwm for the piglit compositor
03:32 orowith2os[d]: I can add it to my never ending list of things to do, I guess...
03:32 x512[m]: How X11 GPU rendered windows works without compositor?
03:34 orowith2os[d]: It'll put the pixels straight to the buffer, I believe
03:35 orowith2os[d]: So transparency or layered windows doesn't work
03:41 orowith2os[d]: Actually, you can do that with Wayland too. The compositor doesn't have to do any actual compositing. It's just normal for it to
03:44 x512[m]: One of Wayland compositor without compositing is Haiku Wayland compatibility layer: https://github.com/X547/wayland-server. It currently doesn't support semitransparent window parts because Haiku GUI server do not support that.
03:45 x512[m]: Rendering straight to framebuffer will not work I suppose because of synchronization problems.
03:53 orowith2os[d]: That's less a Wayland compositor and more a Wayland *server*, like my rxwl attempt
03:53 orowith2os[d]: Good example though.
03:54 orowith2os[d]: Haiku seems to do interesting things, I should get into some of the dev channels.
04:29 gfxstrand[d]: orowith2os[d]: No need. Everyone just runs piglit with GBM.
04:29 orowith2os[d]: But unnecessary work :hammy:
04:38 nastyworml: So I did the transition value logic for packed computation upfront. 348+328+80+144+144−1024=20 and 348+328+144+144−1024=-60 so if we merge those terms and conditionalize we get -40 or 40. So the the dep incoming operand is 72 and transition value is to 20, and we really want twice of that. I did also test for transition value 16 alike and 80 is 256-144=112 256-112-112=32 112-32=80, so as
04:38 nastyworml: told for to transitioning to 16 it still holds similarly here: 344+328+80+144+144−1024=16 ning 344+328+144+144−1024=-64 once again if we merge those and conditionalize we get -32 or 32 twice the value. That is utter relief btw. since transition value logic is the most complex logic for executing packed hashes. I gonna get the things done, but those are final comments and remarks before i
04:38 nastyworml: start to work on stack, i looked at wasmati codeblocks and things seem very very good.
04:39 nastyworml: At some point things started to flow for me, i started to get data to be accessed, and got the most complex part done for arbitrary answer set selections and transitioning etc.
10:23 x512[m]:uploaded an image: (2427KiB) < https://matrix.org/oftc/media/v1/media/download/Adl1NVqAbQY0iPe_kX3SXGRsHqgX8_iTsK-hg90-FbAltcs-iSV-02cPVy6QDx4yc4XVgpevxkkmYC5oBTUGqJBCeWTZNMiwAG1hdHJpeC5vcmcvV2RwT3RvVkVjd0hpZmtOWnpPdE9xSHlK >
10:24 x512[m]: Ampere also working on Haiku NVRM NVK.
10:26 magic_rb[d]: Nvrm is the kernel side?
10:27 x512[m]: Yes. But in earlier experiments I managed to run NVRM in userland enough to complete GPU initialization.
10:29 x512[m]: It should be possible to run NVRM in userland, but currently various APIs are missing in Haiku for that (setting memory caching, forwarding interrupts to userland, managing devfs in userland).
10:30 magic_rb[d]: Nvrm is the linux one or the nvidia open one?
10:31 x512[m]: This one: github.com/NVIDIA/open-gpu-kernel-modules/
10:32 magic_rb[d]: Ah yeah the nvidia one
10:34 x512[m]: And my NVK branch that integrates NVK with NVRM instead of Nouveau KMD: https://github.com/X547/mesa/tree/mesa-nvk
10:36 magic_rb[d]: Any plans to merge that? Would be sick to have the option of picking nouveau kmd, nvrm or nova eventually
10:37 x512[m]: Still WIP and not ready for merge request. Several months will be needed.
10:38 x512[m]: For example it currently do not implement fences/semaphores at all and do CPU blocked submission.
10:40 magic_rb[d]: No rush, i was more wondering if this is a "lets see if i can do" or "lets do it and eventually finish it"
10:40 orowith2os[d]: magic_rb[d]: Sid was working on it
10:41 orowith2os[d]: It'll be disabled by default, since nvrm has an unstable uapi
10:41 orowith2os[d]: (if you're shipping all the GPU drivers on the system yourself, you'll be okay)
10:41 magic_rb[d]: (Nixos so yes i am :P)
10:41 x512[m]: First published for me, then Sid adapted code to run on Linux.
10:42 orowith2os[d]: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34260
10:43 orowith2os[d]: magic_rb[d]: Including Flatpak and docker containers?
10:43 magic_rb[d]: I dont use flatpak at all and yes
10:43 magic_rb[d]: 98% of my container images are made by me
10:43 magic_rb[d]: I have a custom nixos like distro for it even
10:44 magic_rb[d]: https://github.com/nix-community/NixNG
10:44 orowith2os[d]: Kk
10:44 orowith2os[d]: Ugh, I need to get host driver stuff working at some point.
10:44 orowith2os[d]: So much stuff to do.
12:55 redsheep[d]: orowith2os[d]: Disabling by default isn't due to the unstable uapi, though that is an issue, it's to maintain the 1:1 mapping between the kernel driver you load and the userland driver you get
12:56 orowith2os[d]: I would assume the 1:1 mapping is less of an issue than the uapi
12:56 redsheep[d]: I think you could probably make it only load nvk on openrm by default with a matching version but then we risk stepping on Nvidia's toes
12:57 redsheep[d]: Because having mesa installed at the same time as Nvidia prop is very common and if your mesa happens to build nvk...
12:57 redsheep[d]: Then you might accidentally have applications end up randomly on either one
12:58 orowith2os[d]: you can't set priorities to prefer one or the other?
12:58 orowith2os[d]: that would solve it pretty quick.
12:59 redsheep[d]: The loader does grab them in a deterministic order, and I think nvk ends up first right now if nvk enumerates at all
12:59 redsheep[d]: Either way relying on loader behavior isn't great
13:00 redsheep[d]: Even if there were a currently consistent way to try to be second
13:04 x512[m]: redsheep[d]: Mapping is not issue if specify exact version in package dependencies and check NVRM version on NVK load.
13:06 redsheep[d]: That's great for nvk packages intentionally doing nvk on nvrm, the point faith was making when she said it will never be default, and what I'm calling the mapping issue, is when the user is unaware and isn't intending to have anything other than Nvidia's own code active
13:07 redsheep[d]: Someone happens to have a matching version of nvk and nvrm, doesn't even know what nvk is, and suddenly DLSS doesn't work and their games are slower
13:10 orowith2os[d]: I wonder how amdvlk and amdgpu-pro deal with it?
13:10 orowith2os[d]: I think they just... don't?
13:16 x512[m]: redsheep[d]: I expect that NVK with NVRM should be built separately and not installed by default. Used KMD type is specified in Meson configure options.
13:17 redsheep[d]: orowith2os[d]: Hmm. Yeah I'm not sure, and I don't have an AMD gpu right now to test. I think it's a bit of a different situation though where radv and amdvlk both use the same kmd and have a stable uapi, and aren't as likely to have breakage by loading the wrong vulkan driver
13:17 x512[m]: So if user want to install NVK for NVRM, separate package is needed to be installed that set exact NVRM version in dependencies.
13:18 redsheep[d]: x512[m]: That's a good idea, I was thinking there should be a way to say you want it at build time and that sounds like a good approach. It should still respond correctly to a 0 on the environment variable to force it back off but that sounds reasonable otherwise
13:18 x512[m]: It will not conflict with Nouveau NVK or official Nvidia proprietary Vulkan drivers.
13:19 x512[m]: Also separate Vulkan ICD so file name.
13:20 redsheep[d]: Right, so long as the user has gone out of their way to install a non-default package and that package is handling the versions correctly I would agree that it's fine
13:23 orowith2os[d]: redsheep[d]: if you build it separately, wouldn't you risk symbol conflicts?
13:23 orowith2os[d]: unless you split the mesa package up
13:24 orowith2os[d]: (or have two mesa packages, one with nvk and one with nvk-on-openrm, that are built the same other than the openrm changes)
13:25 x512[m]: Yes, 2 packages. mesa-nvk-nvrm is separate package.
13:26 redsheep[d]: Yeah there's a couple different ways I can see you could solve that. It already works, like with dodo's nvk package, to have nvk separate. Not sure what that does if you already have nvk in your mesa build but afaik everything still just works
13:27 redsheep[d]: Especially if they were even two different ICDs and two different .so files then the main nvk one could maintain never loading on openrm at all
13:27 orowith2os[d]: ngl, I guess it's correct to say you can't load two different vulkan drivers at once?
13:27 orowith2os[d]: so an nvk-on-nouveau and nvk-on-openrm dupe couldn't conflict
13:27 tiredchiku[d]: orowith2os[d]: no
13:28 redsheep[d]: Any one application can't load both at once
13:28 tiredchiku[d]: if you vulkaninfo with amdvlk and radv installed, both will be enumerated
13:28 tiredchiku[d]: redsheep[d]: correct
13:28 orowith2os[d]: mkay, that works out fine then
13:28 redsheep[d]: But yeah you can have two at the same time and point at the different ICDs
13:28 orowith2os[d]: I'd be worried with two separate libgalliums, etc
13:28 orowith2os[d]: (in case nvk-on-openrm has patched zink or something)
13:28 x512[m]: NVK do not use libgallium.
13:29 x512[m]: Zink should just work, even on proprietary Nvidia Vulkan Driver.
13:30 orowith2os[d]: I have a weird mental map going right now, it makes sense over here (for me)
13:30 orowith2os[d]: too much time spent with `dl(m)open()` shenanigans
13:32 redsheep[d]: I have had zink issues before caused by not realizing my nvk was split and having wildly different versions of zink and nvk, but that was a very unusual case. Users using packages for this shouldn't see that, their main mesa package and the nvk-nvrm package should both be keeping mesa up to date and at least close to the same version
13:34 tiredchiku[d]: I still don't understand the appeal behind putting nvk-on-nvrm in a separate package when env vars will suffice
13:35 redsheep[d]: That works fine for us, but I don't see that working for users
13:35 orowith2os[d]: two separate NVK builds, one tied to the nvidia kernel driver package version
13:35 redsheep[d]: Keeping their versions in sync isn't something they should have to do
13:35 orowith2os[d]: one to nouveau
13:35 tiredchiku[d]: redsheep[d]: why not?
13:35 redsheep[d]: tiredchiku[d]: https://discord.com/channels/1033216351990456371/1034184951790305330/1358072508481536080
13:36 tiredchiku[d]: redsheep[d]: assuming a user keeps their packages up to date, that is the responsibility of the devs and the packagers
13:36 tiredchiku[d]: never the user
13:36 redsheep[d]: And if packaged IIUC you could keep all the rest of nvidia's other userspace while deleting their vulkan driver
13:37 tiredchiku[d]: it's only a problem if your user is pinning a package to a specific version
13:37 tiredchiku[d]: redsheep[d]: again, why
13:37 tiredchiku[d]: what good does that achieve
13:38 orowith2os[d]: distros would have to constantly patch and rebuild the main mesa nvk (on nouveau) for the nvk-on-openrm stuff if the nvidia kernel driver changes, versus building it separately and being able to patch and build *only* nvk (and maybe zink) for that package
13:38 orowith2os[d]: (and probably have it conflict with main mesa nvk)
13:38 tiredchiku[d]: btw, nvprop license says:
13:38 tiredchiku[d]: 2.3 You may not modify or create derivative works of the SOFTWARE provided in binary form.
13:38 orowith2os[d]: does package splitting count?
13:39 redsheep[d]: tiredchiku[d]: Ah, okay
13:40 redsheep[d]: I wonder if it would be a derivative work to just install their entire package and block their ICD, so making no actual modification, but maybe that is pushing too close to the line
13:40 tiredchiku[d]: orowith2os[d]: the only difference is having the nvkmd layer being built for nouveau or not
13:41 tiredchiku[d]: alsoz the nvkmd abstraction layer exists for that reason
13:41 tiredchiku[d]: for not needing to patch the userspace part for kernel changes
13:42 redsheep[d]: You're saying you want to make all of this the packagers and distros problem but I don't want them to have to even begin to be aware that keeping mesa and nvidia's drivers version locked to each other is a thing to consider. Those two things should continue to be entirely separate
13:42 tiredchiku[d]: i.e. even if nvrm uapi changes, nvk itself won't need patching, the nvkmd layer would, just like it would for nouveau
13:43 orowith2os[d]: I see
13:43 tiredchiku[d]: redsheep[d]: it *is* the maintainer's headache to keep things working across drivers anyway
13:44 tiredchiku[d]: and you can always do conditionals to make it work across drivers, like the vaapi driver does
13:44 tiredchiku[d]: let me find that code, wait
13:45 tiredchiku[d]: https://github.com/elFarto/nvidia-vaapi-driver/blob/c519e97ef7af581c109f49b6973269fb16d1bc54/src/direct/nv-driver.c#L242
13:45 tiredchiku[d]: having a separate package doesn't make sense to me considering NVK's code proper does not depend on the kernel driver directly
13:46 tiredchiku[d]: just like the nouveau backend
13:46 redsheep[d]: IIRC faith was averse to version conditionals, and I agree. Better to just have the package have the right kernel install to match the version of nvk
13:46 gfxstrand[d]: redsheep[d]: <a:shrug_anim:1096500513106841673> It's kinda both.
13:46 orowith2os[d]: I didn't realize that the nvkmd layer was a thing, that makes it a lot less weird :monadicCat:
13:46 tiredchiku[d]: redsheep[d]: that's difficult to do considering different distros are on different versions
13:46 orowith2os[d]: orowith2os[d]: I won't continue on with that in mind
13:47 tiredchiku[d]: you can't avoid version conditionals if you want to run across distros
13:47 gfxstrand[d]: But we can figure out those details later. Write code first. Figure out packaging/distribution later.
13:47 tiredchiku[d]: debian stable will always be behind arch and you can't change that
13:47 redsheep[d]: tiredchiku[d]: You can if you just only ever have the correct openrm version per nvk version. If nvk is old the openrm is old and vice versa
13:48 tiredchiku[d]: that works if mesa releases coincide with nvidia releases
13:48 tiredchiku[d]: which, they do not
13:48 orowith2os[d]: old debian can ship recent nvidia
13:48 orowith2os[d]: and it can also ship old mesa
13:49 redsheep[d]: tiredchiku[d]: Why does that matter? The package is what would ship the openrm version it needs
13:49 orowith2os[d]: (not even can. Does.)
13:49 tiredchiku[d]: also switching kernel driver versions is a part of testing the userspace driver
13:49 redsheep[d]: Whatever happens to be the nvk code that ships for that release is what it installs
13:49 tiredchiku[d]: artificially locking nvkmd/nvrm to a single driver version just doesn't appeal to me, from a compatibility pov
13:50 tiredchiku[d]: even from an ease-of-use pov for the users brave enough to use a non-default setup
13:50 tiredchiku[d]: like, imagine you downgrade your nvrm module to test a GSP issue, and suddenly you also have to downgrade NVK
13:52 redsheep[d]: I mean at an absolute minimum even if you want all of that headache of supporting every openrm version at once mesa will still need to refuse to enumerate with any openrm version too new for you to know for sure it works
13:52 tiredchiku[d]: meaning you can't test the same driver across kernel versions
13:52 redsheep[d]: tiredchiku[d]: This is a concern for devs only, at which point do all of this yourself and don't use the package
13:52 redsheep[d]: The package is solely intended to make it simple for people who don't mess with it
13:52 tiredchiku[d]: redsheep[d]: yeah, and I'm saying setups are so dynamic across distros for various reasons that locking doesn't make sense
13:52 redsheep[d]: And if you need to do that rebuilding nvkmd is fine
13:53 tiredchiku[d]: I know someone who's pinned their nv driver to 535 because they "don't feel the need to update"
13:53 tiredchiku[d]: redsheep[d]: yeah, but nvkmd isn't a separate build option, it's part of the nvk build files :p
13:54 redsheep[d]: That's probably not a person that makes sense to try to support, but whichver, if you want all of the extra work of supporting all of the uapi changes at the same time in the same build I won't be the person to say no
13:55 redsheep[d]: tiredchiku[d]: Right, it is now. But if I understand correctly what x512 was suggesting it could become separate so you specify just what version of nvidia kernel you want to rebuild nvkmd against
13:55 redsheep[d]: So that you can both specify defaulting and what to default attached to at build time
13:55 tiredchiku[d]: doesn't that imply different code paths for different driver versions?
13:56 tiredchiku[d]: which can just be done with version conditionals?
13:56 tiredchiku[d]: :3
13:56 redsheep[d]: Surely they would work quite differently but yes I suppose so
13:57 tiredchiku[d]: if you're gonna need different code for different versions anyway, why not "add support" to the existing driver instead of "updating the supported kernel module version"
13:57 tiredchiku[d]: it's the same amount of development effort
13:57 tiredchiku[d]: but easier on packagers and users
13:58 tiredchiku[d]: nvrm uapi doesn't change on the same major version, only across major versions when it does
13:58 redsheep[d]: Whichever. I still think a package for users to never get too new of openrm and not needing an env variable makes sense
13:58 redsheep[d]: Even if nvkmd supports it all
13:59 tiredchiku[d]: so if I support an LTS release once, it will remain supported regardless of how many minor revisions it gets
13:59 tiredchiku[d]: redsheep[d]: that can just be a check in the nvkmd enumeration code. if nv driver greater than such version, warn "here thar be dragons"
13:59 tiredchiku[d]: or refuse to enumerate
13:59 tiredchiku[d]: whatever
14:04 tiredchiku[d]: additional packges could be a source for confusion. "I have nvk installed but it won't work"
14:04 tiredchiku[d]: >user has nvk-on-nvrm installed and is running the nouveau kernel module
14:05 tiredchiku[d]: roll it into one build and that's not gonna be an issue
14:06 tiredchiku[d]: redsheep[d]: her package was following arch's packaging style for vulkan drivers, not all distros follow that either
14:09 redsheep[d]: tiredchiku[d]: People don't read these warnings. If openrm is too new it should fail to enumerate if you haven't used the env variable to force it.
14:09 tiredchiku[d]: tiredchiku[d]: mhm
14:10 redsheep[d]: tiredchiku[d]: That package would either just be for version locking a build of nvk that does either, or adding a separate nvk. Their main mesa build should still include nvk
14:10 tiredchiku[d]: that will conflict
14:10 redsheep[d]: I guess a distro not including nvk could be an issue but I think they pretty much all are
14:11 tiredchiku[d]: there can only be one libnouveau_vulkan.so
14:11 tiredchiku[d]: and changing how mesa *builds* nvk is.. a big ask
14:13 redsheep[d]: You can't have the mesa build include nvk and then go to install an nvk only build right now? Surely that is a solvable problem, you could just put it somewhere else and/or rename it and have a separate ICD
14:13 tiredchiku[d]: unnecessary complication .-.
14:14 redsheep[d]: Not if a user has started relying on this being how their drivers work and then they do updates, get too new openrm, and suddenly it doesn't enumerate anymore or blows up
14:14 tiredchiku[d]: why not just have one libnouveau_vulkan that works on both kernel modules
14:15 redsheep[d]: I'm going to get off the merry-go-round now
14:16 tiredchiku[d]: ..ah, this whole argument has been assuming nvrm is enabled by default as a supported kernel backend
14:16 tiredchiku[d]: :derproo:
14:16 tiredchiku[d]: yeah I am against doing that 😅
14:16 tiredchiku[d]: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34260/diffs?file=3a170d3a0145fb5a538f5d2fa59fd5e819a10512#3a170d3a0145fb5a538f5d2fa59fd5e819a10512_69_72
14:17 tiredchiku[d]: at least as of now
14:18 tiredchiku[d]: tiredchiku[d]: subject to change depending on how things play out w/ nova
14:18 tiredchiku[d]: and nouveau itself
14:20 rinlovesyou[d]: using the nvidia kernel module to me sounds like a nice thing for the devs of nvk/nouveau/nova for debugging purposes but i don't see a reason this would ever become the default for users unless there's some magical performance uplift for the time being, which i doubt
14:22 x512[m]: tiredchiku[d]: NVK NVRM should be not enabled by default at least to not harm Nvidia business and to not interfere with Nvidia official proprietary Vulkan drivers.
14:22 rinlovesyou[d]: from this discussion alone it sounds like a packaging nightmare
14:23 tiredchiku[d]: x512[m]: yeah, I agree, but I see redsheep mentioning not needing an env var for nvk-nvrm
14:23 x512[m]: 2 separate NVK builds and 2 separate packages for NVRM and Nouveau KMDs is easy and robust solution.
14:24 tiredchiku[d]: that I disagree with
14:24 x512[m]: Yes, no env variable is needed, it will be meson setup .. -Dnvk-kmd=nvrm.
14:24 tiredchiku[d]: env var to enable nvk-on-nvrm is simpler
14:24 tiredchiku[d]: easier for building and packaging too
14:25 tiredchiku[d]: the nvkmd layer is an abstraction for that reason
14:25 x512[m]: You can't enforce NVRM version without separate NVK ICD package.
14:25 tiredchiku[d]: I disagree with that too
14:25 tiredchiku[d]: you can enforce it in nvkmd
14:32 gfxstrand[d]: The NVRM backend in NVKMD should just not enumerate if there's a major version mismatch. I'm not sure about minor versions. Maybe we can have a NVK_TRY_NVRM_ANYWAY environment variable if we want to overload that. But in the case where we have nouveau.ko, the NVRM stuff won't enumerate no matter how much you ask and if you have NVRM, the Nouveau stuff won't enumerate. There's no reason we can't
14:32 gfxstrand[d]: have both built at the same time.
14:33 gfxstrand[d]: Of course, for Haiku, you'll want to not build the nouveau.ko stuff because you don't want libdrm but that's a separate concern.
14:35 x512[m]: Haiku kernel modules have no .ko suffix :) It have no extension at all. And NVRM KMD is currently called nvidia_gsp (nvidia is already used for old BeOS Nvidia driver).
14:36 x512[m]: And Haiku kernel modules are technically ELF shared libraries (DYN).
15:01 jimmyteldrone: tiredchiku[d]: nutbolt you are a banner hero here? Let me make it clear banass, you are a zoopark inmate soon as much as dave airlie and other dogs are. Fecalists do not even try talk to me ok?
15:04 jimmyteldrone: You get placed into zoopark wards soon enough, or be catrated or vaccinated into a vegetable.
15:04 jimmyteldrone: castrated
15:05 jimmyteldrone: I have seen such mindill evil people before with the same destiny all over again and again
15:13 x512[m]: What is the speech above? It looks insulting.
15:14 jimmyteldrone: You made a mess of tourism with your criminals you locked me into a jail and all who did it got vaccinated with graphene inside as penalty , and you start doing the same stuff again and you get eliminated into zoopark, now that monster lady did not pay ones bills, did extort us with their gang members and kicked me out from my own hotel which dad invested into, are you that nuts like this
15:14 jimmyteldrone: borderline maniac?
15:14 redsheep[d]: Just the typical vile spam, stick around nouveau long enough and it's inevitable to see it
15:16 jimmyteldrone: My dad is a hero in life, you want to say things about him, you talk to your own hand instead, you are mickeys compared to him.
15:20 jimmyteldrone: They have continued with abuse , yeah i see, unsatisfied by their own lawless settlements and pentaly received, which is where the sanctions go only deeper and deeper, gets military involved etc.
15:21 jimmyteldrone: there are too much of petitions and unsatisfied comments about those "legal doctors" who tried to kill me, and goodness wins their time is done soon.
15:26 jimmyteldrone: I did not press any formal charges against those people, cause the amount of corruption was above my health and tension that i could tolerate, and i still do not even plan to do that, because i benefited from those settlements, but only because i am that strong person to have been surviving under those conditions.
15:27 jimmyteldrone: my allies retaliated to those people, cause the former ones are not ok in many ways and pushed too deep.
15:29 snowycoder[d]: Bots on IRC?
15:31 jimmyteldrone: that none bothers me to take on forced trips again, is the result of people who believe in me standing up for me together, that i am worth of no abuse alike, honestly, so they forced the path that i get bit less abuse on streets.
15:32 jimmyteldrone: and yes i am worth that effort imo, cause i did not start that conflict anyhow, i did not place myself into closed doors.
15:33 redsheep[d]: snowycoder[d]: Yeah unfortunately defending against this in IRC isn't super easy without keeping out people who should be there
15:34 jimmyteldrone: behind closed doors perhaps, anyhow any scam does reach to it's legal ending, and that has happened around me already.
15:34 x512[m]: No moderators on IRC or Matrix bridge side?
15:35 redsheep[d]: I forget who needs to get pinged for the irc side. They keep coming back as a new user though so that doesn't last
15:35 jimmyteldrone: and i managed to back up my activities to get along with life also
15:35 tiredchiku[d]: dwfreed ^
15:36 jimmyteldrone: cause the time they wanted to finish me i survived well cause i am strong, and backed up my activities and widened my stuff
15:36 jimmyteldrone: i am injured and i had to change my plans drastically, unfortunate to you i deal with systems these days, cause not everything i can do anymore
15:37 jimmyteldrone: so i got very experienced and mature, cause 10years i lived in numbers all days, i prepared to do big things in tech.
15:39 jimmyteldrone: i am still the strongest lifter among even younger people, but my knee nor hand can function well anymore
15:40 jimmyteldrone: so top level sports obviously i can not put up with by far
15:40 jimmyteldrone: like whatever i translate those evil events into something good, even though i know people did that deliberately due to envy to me
15:41 jimmyteldrone: there is still handful of things i can still manage to be doing
15:41 jimmyteldrone: and imo my numbers turned out very promising
15:42 jimmyteldrone: i am already sure i succeed in the job
15:51 jimmyteldrone: i am little bit known for this i take on big tasks , sometimes too big in effect but situation demands for this atm. europes partners are putting a lot of money into defence aid systems and i need to perform also my own work which i studied for years.
15:53 jimmyteldrone: I still love ancient europe and todays one shifting ideas finally too.
15:55 jimmyteldrone: defense systems or so called secure or assault systems are much easier to build than public operating systems in my opinion, and i apply something there to be cooperating with.
15:56 jimmyteldrone: public os systems are meant for so called systems that are meant to have surveillance on board to get tapped into problem areas , they design vulnerabilities for a reason.
16:01 jimmyteldrone: I can not go on with such life, that some tiredchiku or your nutbolt friends harass or stalk me for years and so be it, i need a better alignment with my work.
16:03 jimmyteldrone: you sabotage put everything out of resonance and expect that i am tahnkful for this terror or what?
16:03 jimmyteldrone: are you broken from the head or what?
16:07 jimmyteldrone: who are you to tell me, how i rest or what i do at my own territory at home, show me your biggest results to even qualify to talk to me, what reputation this Laura idiotic tornado was talking about, why does this bitch scam me out of my own hotel?
16:07 jimmyteldrone: this is an absolute absurd
16:08 redsheep[d]: karolherbst[d]: Maybe you can do something about the spam?
16:10 jimmyteldrone: i am not part of the criminal world, yes gloria and laura are, I am not afraid of those criminals either, it's just i never was active in this world or inside criminal businesses.
16:11 jimmyteldrone: i do not dream of such movements either until there is enough that authorities can do, and world is large we can find issues we can deal with
16:11 x512[m]: I get this when running NVK with Zink: ../src/nouveau/vulkan/nvk_cmd_draw.c:3392:nvk_cmd_flush_gfx_cbufs: ba.base_addr % min_cbuf_alignment == 0
16:13 x512[m]: But Zink version is old (~2 years). Can it be Zink problem?
16:13 redsheep[d]: Not sure personally but I build zink with nvk to avoid the possibility, it has been broken for them to be different before
16:25 jimmyteldrone: I am honestly doing very great! I studied for this too, but those million line codebases are over my head, also i say i am ok to get into split ways but please do not stalk to humiliate me, the mission i learned for should be possible, the execution was always possible if you figured out the transitioning logic, it's mathematical description is also pretty simple, as i showed, data access
16:25 jimmyteldrone: does so many steps, i split from your code a bit, but it's nothing criminal.
16:25 jimmyteldrone: i chose wasmati and will stick to it, webassemly based IR.
16:26 jimmyteldrone: and i do not complain wgpu or wasm and both are totally sane along with metadata code blocks.
16:29 jimmyteldrone: my code is so versatile already even though in lot smaller footprint, it keeps me occupied a lot , millions of details still literally.
16:33 jimmyteldrone: my idea is to work close on compiler which itself could consume and process the code and dump the outputs, that i fail to process my own due to their size and what not more like complexity of C++ at times etc. LLVM also did not want me, and overall i have accepted that they do not.
16:35 jimmyteldrone: My skills are not as big that i could process on old hardware millions of lines of code my own, no one wants me either to collab on key projects. But things go weird if you place me behind closed doors, even though we never knew each other, like why do you care about this? Even weirder when you stalk to ban me from my own house or something where i never bothered anyone either etc.
16:37 jimmyteldrone: data access i finally figured out, but it's for me the project of my life , cause it is merely on limits testing my grand total potential, it has so many modules.
16:38 jimmyteldrone: but such filesystems are so complex that every day perhaps weed junkie is not suitable for such complexities.
16:41 jimmyteldrone: i am pretty sure i figured out the enourmous compression ratio , but there is a lot of work ahead to get it done, i freed all my time to do it, and technically i also do not care what you do either, i am not punishing you
16:41 jimmyteldrone: even though it is very hard to understand what is going on where you want to be so evil and how come and why?
16:46 HdkR: 🎉
17:12 gfxstrand[d]: x512[m]: Possibly? I would start by updating Zink. 2 years is pretty old.
17:40 calico: Trying Nouveau. Having a GTX 1650. No reclocking. Steam games runs slow. Having a GTX 760. No Vulkan. Steam games aren't working.
17:52 redsheep[d]: 700 series vulkan will be a thing before too long but it's not done
17:53 redsheep[d]: As for the 1600 that should work, though if you are seeing it running that slow you probably need to enable the gsp firmware
17:53 redsheep[d]: nouveau.config=NvGspRm=1
17:54 redsheep[d]: It might also just be slow. That's not a terribly fast card and nvk isn't fast at everything yet
17:56 calico: k, I'll try nouveau.config=NvGspRm=1
17:56 calico: "you are seeing it running that slow" --> very laggy games, like less than 5 fps
17:57 redsheep[d]: Hmm. If it's still *that* slow after enabling gsp there's probably something wrong and it's software rendering
17:58 calico: well there's two gpu on that laptop ... an integrated Radeon and the nvidia GPU
17:58 redsheep[d]: It could be falling back to integrated as well then, yeah
17:58 calico: but I don't know how to force the nvidia GPU with nouveau
17:59 calico: what does nouveau.config=NvGspRm=1 do?
17:59 redsheep[d]: It tells the kernel to use the newer firmware that can reclock
17:59 redsheep[d]: And just generally works much better
18:00 calico: good
18:00 calico: that reclocking isn't automatic right?
18:00 redsheep[d]: It is automatic
18:00 calico: k
18:01 calico: and uuh will it work with my GTX 760 too or is it just for newer GPUs?
18:01 redsheep[d]: Only newer gpus. In fact that's the earliest generation that can use it
18:01 redsheep[d]: The 1650, that is
18:02 calico: so with my other laptop that has a 1050, the reclocking would work?
18:02 calico: without that newer firmware?
18:02 redsheep[d]: No that card has no new firmware and no reclocking, automatic or manual
18:03 redsheep[d]: And sadly probably never will
18:03 calico: k
18:03 calico: I see
18:04 calico: (put a sad cat meme here)
18:32 snowycoder[d]: About kepler, does anyone know how `TEXDEPBAR` works?
18:32 snowycoder[d]: It seems to have an immediate to specify, somehow, which texture to wait, but indirect textures instrs are fixed at class `0x0`, direct textures have the class as an immadiate, and old codegen treats texbar immediates as "levels", without much description
18:34 mangodev[d]: redsheep[d]: isn't GSP a hardware component as well?
18:35 tiredchiku[d]: yes
18:36 mangodev[d]: i'd love to see the day someone runs doom on the gsp
18:37 mangodev[d]: would be the next evolution of "running doom on your gpu"
18:46 karolherbst[d]: snowycoder[d]: I think it can also take a register, no?
18:46 karolherbst[d]: or uhm....
18:46 karolherbst[d]: maybe it was a mask?
18:46 karolherbst[d]: so you'd wait on all?
18:46 karolherbst[d]: check codegen 😄
19:00 mhenning[d]: snowycoder[d]: I looked at this a bit, and I think the immediate means something like "how many results are allowed to be waiting in the queue?"
19:02 mhenning[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1358154900181221406/https3A2F2Fsubstack-post-media.png?ex=67f2cfd1&is=67f17e51&hm=c355141eb547a6262a70e6adb75b66892553fbad9da3d3d950761f718d7f5f3c&
19:02 mhenning[d]: Take a look at this example from chips and cheese. After the first 4 texture instructions, there will be 4 outstanding reads in the queue. The first TEXDEPBAR waits on 0x3 to mean that there can be at most 3 left in the queue, which means the first will be complete
19:03 mhenning[d]: If you want to be conservative, you can TEXDEPBAR 0x0 and that will wait for all outstanding reads to complete, which might make sense to do during bringup
19:05 snowycoder[d]: That makes a lot of sense, thanks!
19:05 snowycoder[d]: Yep I'll put it at 0 for now, although a pass to set it shouldn't be that hard
19:07 mhenning[d]: Well, a pass like that can get more complicated if you want to deal with control flow
19:07 snowycoder[d]: Yes, I've seen the old pass in codegen
19:08 mhenning[d]: but yeah, I'd suggest you do the easy thing for now and then once cts is passing you can work on making it less naive
19:09 snowycoder[d]: Yep, I'm still missing something else in textures, it only returns 0
19:09 snowycoder[d]: I'm slowly getting closer
20:17 karolherbst[d]: ohhhh right...
20:18 karolherbst[d]: it was a counter
20:30 pavlo_kozlenko[d]: What parameter in Grub should I specify to set the 0F profile for Kepler?
20:39 gfxstrand[d]: snowycoder[d]: and make sure can_eliminate() returns false for texdepbar and that we treat it as a barrier when scheduling.
20:40 gfxstrand[d]: Otherwise the compiler might do funny things.
20:40 gfxstrand[d]: Really, it should probably be inserted by `calc_instr_deps()`
21:02 snowycoder[d]: For now I'm just hacking it together to see what's broken.
21:02 snowycoder[d]: Also, how can I dump nvidia's TICs?
21:02 snowycoder[d]: (what does TIC stand for? Texture something Commands?)
21:23 calico: still getting very low fps, and it also seems like the iGPU is slowering the CPU ... how can I force the usage of the nvidia gpu?
21:24 calico: there's optimus / prime for nouveau?
21:27 orowith2os[d]: calico: DRI_PRIME=pci-id
21:29 calico: all those refs to the transformers are driving me crazy
21:33 calico: orowith2os: just tried it with glxgears and it didn't work?
21:33 calico: DRI_PRIME=01:00.0 glxgears -info
21:35 orowith2os[d]: Uhhhhhh
21:35 calico: k "DRI_PRIME=01 glxgears -info" works
21:35 orowith2os[d]: Yeah, I think the PCI ID you put in there was wrong
21:35 orowith2os[d]: try the different options you see in lspci -nnv
21:35 orowith2os[d]: But just 1 or 0 should do it
21:39 calico: doesn't seems to work in steam
21:39 orowith2os[d]: Should work fine for the games
21:40 orowith2os[d]: I think most steam installs include a desktop file that sets the GPU
21:40 orowith2os[d]: If you're setting it via terminal, I'm not sure
21:43 calico: I'm setting it from the game settings