00:58dwlsalmeida[d]: I wonder if you guys know where these NVKM_ENGINE_* are defined?
00:58dwlsalmeida[d]: NVKM_LAYOUT_ONCE(NVKM_ENGINE_GR , struct nvkm_gr , gr)
00:58dwlsalmeida[d]: NVKM_LAYOUT_ONCE(NVKM_ENGINE_IFB , struct nvkm_engine , ifb)
00:58dwlsalmeida[d]: NVKM_LAYOUT_ONCE(NVKM_ENGINE_ME , struct nvkm_engine , me)
00:58dwlsalmeida[d]: NVKM_LAYOUT_ONCE(NVKM_ENGINE_MPEG , struct nvkm_engine , mpeg)
00:58dwlsalmeida[d]: NVKM_LAYOUT_ONCE(NVKM_ENGINE_MSENC , struct nvkm_engine , msenc)
00:58dwlsalmeida[d]: NVKM_LAYOUT_ONCE(NVKM_ENGINE_MSPDEC , struct nvkm_engine , mspdec)
00:58dwlsalmeida[d]: NVKM_LAYOUT_ONCE(NVKM_ENGINE_MSPPP , struct nvkm_engine , msppp)
00:58dwlsalmeida[d]: NVKM_LAYOUT_ONCE(NVKM_ENGINE_MSVLD , struct nvkm_engine , msvld)
00:58dwlsalmeida[d]: NVKM_LAYOUT_INST(NVKM_ENGINE_NVDEC , struct nvkm_nvdec , nvdec, 8)
00:58dwlsalmeida[d]: NVKM_LAYOUT_INST(NVKM_ENGINE_NVENC , struct nvkm_nvenc , nvenc, 3)
00:58dwlsalmeida[d]: NVKM_LAYOUT_INST(NVKM_ENGINE_NVJPG , struct nvkm_engine , nvjpg, 8)
00:58airlied[d]: right there
00:59airlied[d]: the layout.h gets included elsewhere
01:00airlied[d]: subdev.h has the enum
01:01dwlsalmeida[d]: this is buried below a couple of layers of macros, I wonder if this is where this 0x300 comes from? i.e. `NVKM_ENGINE_NVDEC==0x300`
01:08airlied[d]: probably where I copied it from, though I don't think it has to correpsond
01:34dwlsalmeida[d]: crap, it seems to be impossible have a single channel that works for both everything else and video
01:34dwlsalmeida[d]: I...really did not want to have two channels because that's not really how the current code works and it seems clunky
01:35dwlsalmeida[d]: sadly it seems to be the only way, IIUC
01:37dwlsalmeida[d]: (gfxstrand[d] FYI)
01:38airlied[d]: yes video has to be a separate channel
01:38airlied[d]: it's why it's a separate queue family
01:40dwlsalmeida[d]: Interesting, video has to be a separate channel, but everything else:
01:40dwlsalmeida[d]: enum nouveau_ws_engines {
01:40dwlsalmeida[d]: NOUVEAU_WS_ENGINE_COPY = (1 << 0),
01:40dwlsalmeida[d]: NOUVEAU_WS_ENGINE_2D = (1 << 1),
01:40dwlsalmeida[d]: NOUVEAU_WS_ENGINE_3D = (1 << 2),
01:40dwlsalmeida[d]: NOUVEAU_WS_ENGINE_M2MF = (1 << 3),
01:40dwlsalmeida[d]: NOUVEAU_WS_ENGINE_COMPUTE = (1 << 4),
01:40dwlsalmeida[d]: Can be backed by a single channel
01:40airlied[d]: we want that for transfer queues etc
01:41airlied[d]: you can't do async compute or async transfer queues without using separate channels
01:42dwlsalmeida[d]: thanks for clarifying Dave
01:42gfxstrand[d]: Yeah, video on its own queue is fine.
01:43gfxstrand[d]: Vulkan requires you to have at least one queue that does 3D, compute, and copy. There's no such requirement about video.
01:43dwlsalmeida[d]: since you're here, what's the difference between M2MF and COPY?
01:43airlied[d]: I think you might be able to expose a VIDEO|TRANSFER on nvidia
01:44gfxstrand[d]: dwlsalmeida[d]: M2MF is the old Fermi thing, I think.
01:44gfxstrand[d]: We don't use it
01:44airlied[d]: but I think we'd want transfer queues first
01:45gfxstrand[d]: We need to sort out topology enumeration and context creation before we can do explicit transfer or compute queues. I was hoping to do that before I took off but then COVID happened and I lost 3 weeks. We'll pick it up next year.
01:46dwlsalmeida[d]: wait, aren't transfer queues a thing already?
01:46dwlsalmeida[d]: I assume that's what COPY is
01:46gfxstrand[d]: Not transfer-only.
01:46dwlsalmeida[d]: ah
01:47gfxstrand[d]: We have that combined 3D+transfer+compute queue and that's it.
01:47dwlsalmeida[d]: Btw, apparently a video queue *must* also support transfer
01:47dwlsalmeida[d]: not sure if I said something trivial, anyways
01:48airlied[d]: I thought we got rid of that
01:48gfxstrand[d]: But with the current API it's tricky to create a compute or transfer-only queue and know that you won't also accidentally pick up 3D and end up conflicting with the 3D queue.
01:49gfxstrand[d]: dwlsalmeida[d]: That might be okay. I suspect the video engines support copy.
01:49airlied[d]: dwlsalmeida[d]: not sure where you read that, I can't see it in the spec
01:50airlied[d]: graphics and compute must implement transfer ops
01:52dwlsalmeida[d]: airlied[d]: https://www.youtube.com/watch?v=R5x6_nBRrv4 13:55
01:52airlied[d]: the spec doesn't say it though
01:52airlied[d]: and I'm pretty sure on non-NVIDIA hw it's not possible
01:53airlied[d]: so I think that info is just out of date
08:43elangelo: ❯ lspci | grep NVIDIA 01:00.0 VGA compatible controller: NVIDIA Corporation Device 28b8 (rev a1) < what kind of hardware is this even? I'm trying to match this with the feature matrix but I really don't understand how to map this
08:45elangelo: sudo dmesg | grep -i chipset this returns nothing as well
08:46tiredchiku[d]: https://www.techpowerup.com/vgabios/265988/265988
08:46tiredchiku[d]: one of them oem workstation GPUs
08:46tiredchiku[d]: for a laptop
08:47elangelo: tiredchiku[d]: should i read that as 'not supported by nouveau' ?
08:47tiredchiku[d]: https://www.techpowerup.com/gpu-specs/rtx-2000-mobile-ada-generation.c4093
08:48tiredchiku[d]: it's based on the ada lovelace architecture, so as long as it has a GSP, it should be supported by nouveau
08:48tiredchiku[d]: tis a laptop Ada Quadro chip
08:49elangelo: cool so I have to look at NV190
08:49elangelo: so it makes sense I guess that my usb-c ports are not working for display.. . if i understd correctly that shoulud be done with the display muxing thing
08:50tiredchiku[d]: NV190GL, technically, but yeah
08:50tiredchiku[d]: elangelo: if the techpowerup page is to be believed, that chip does not support external monitors being connected
08:51tiredchiku[d]: i.e. external displays have to be managed by the iGPU, if one exists
08:51elangelo: allright thank you. much appreciate... gonna just keep on refreshing that page until i can finally drop the binary blob on this machine then
08:51elangelo: ow
08:51elangelo: so only the internal display is done with the nvidia gpu? and the external ones with the intel?
08:52elangelo: i'm very old school... didn't even know that was possible
08:52tiredchiku[d]: you should be able to try nouveau on it already, with an up to date linux-firmware and nouveau.config=NvGspRm=1
08:53elangelo: this is corporate machine so I have to use Ubuntu LTS... not sure if those would work with what you are suggesting
08:53tiredchiku[d]: if I understand it correctly, it just passes its output to the iGPU, and the iGPU is responsible for relaying it to the internal display
08:53tiredchiku[d]: the workstation chips are rare and come on expensive machines, so testing on them is rather sparse 😅
08:54elangelo: yeah not the cheapest machine I agree...
08:54elangelo: anything i can do to improve the testing on this particular hardware?
08:54tiredchiku[d]: if you have a kernel newer than 6.7, you can give nouveau a spin already
08:54karolherbst: elangelo: it kinda depends. There are laptops now which allow switching the GPU driving the internal panel on demand, but sometimes there is a firmware setting to switch the main GPU. Some laptops switch all ports to the nvidia GPU, some don't. Some laptops drive USB-C via the iGPU, but proper connectors (HTMI/DP) via the dGPU. Apparently every
08:54karolherbst: laptop is special here and it always depends on the specific model.
08:55tiredchiku[d]: yeah, what karol said... do note that I'm speaking based only on what the techpowerup page told me for that chip (tho I do understand how a fair few different laptops work)
08:56elangelo: the real shit is that all workstation class laptops these days come with nvidia gpu's
08:57elangelo: though even on amd this might then pose a problem if this is depending on whatever the laptop manufacturor decides
08:57tiredchiku[d]: makes sense to me, CUDA is the biggest player in GPGPU loads
08:57elangelo: feels like ACPI all over again
08:57tiredchiku[d]: yeah, laptop OEMs are... very unful when it comes to this
08:58tiredchiku[d]: unfun*
08:59elangelo: gonna see if i can upgrade to the latests linux-firmware and try passing that bootflag
09:00elangelo: Version: 20240318.git3b128b60-0ubuntu2.4 that sounds old
09:03tiredchiku[d]: might have to uninstall the proper driver too
09:03tiredchiku[d]: proprietary*
09:03tiredchiku[d]: hmm.. I don't remember when the firmware files got added
09:16elangelo: i'm not upgrading this install... will install vanilla without any propieraty stuff and then try on that new install
10:03Pheoxy[AWSTUTC8][m]: been awhile sorry had to do a full reinstall which sapped my enthusiasm for testing NVK, but I
10:04Pheoxy[AWSTUTC8][m]: * but I've noticed I'm barely using any CPU when playing some older games but it's taking ages for shaders to compile resulting in choppy gameplay? Anyway to play with the shader compile settings to speed this up or what may be causing this?
10:05karolherbst: huh.. that sounds like a different problem, like maybe something stalls a lot somewhere
10:11Pheoxy[AWSTUTC8][m]: should I just use NVK_DEBUG=print or is their a easier command or varible?
10:30Pheoxy[AWSTUTC8][m]: Whoops, meant NAK_DEBUG=print,serial
10:37Pheoxy[AWSTUTC8][m]: well that at least seems to be doing a shit ton more compile at least with that
13:05gdaymate: Hi I was just wondering if using nouveau can harm the longevity of a graphics card in any way?
13:16notthatclippy[d]: No, I can't see how it could.
13:26gdaymate: Perhaps incorrect settings for clocks, voltages etc. ?
14:13notthatclippy[d]: Theoretically possible on Kepler but hiiighly unlikely. Certainly same likelihood as with the proprietary drivers.
14:37Pheoxy[AWSTUTC8][m]: is there a way to force the nouveau driver for nvk to stay in performance mode and not powersave the gpu
14:38karolherbst: not at the moment
14:42Pheoxy[AWSTUTC8][m]: bugger, at the moment with NAK_DEBUG=print,serial steam I'm running warframe with the latest git although its always done this it'll be laggy but the shaders seem to be getting forced when I load new areas helping when i run without NAK_DEBUG=print,serial but after a little it sometimes goes into what feels like a powersave mode or something weird and fps completly tanks and shaders take what feels like 10 times longer to
14:42Pheoxy[AWSTUTC8][m]: compile?
14:43Pheoxy[AWSTUTC8][m]: or maybe its done all the smaller ones? don't know whats going on exactly though
14:43Pheoxy[AWSTUTC8][m]: how do I debug this?
14:45karolherbst: could try to make a CPU trace
14:46karolherbst: but
14:46karolherbst: `serial` also hurts performance a lot
14:46karolherbst: and `print` also hurts compile times
14:53Pheoxy[AWSTUTC8][m]: yeah, its become a hole chicken and egg thing for me because unless I can see log output I think it its frozen after a couple of minutes and then its causes freezes and causes restarts sometimes but otherwise some shaders just wont compile for some reason
14:53Pheoxy[AWSTUTC8][m]: usually fire or smoke stuff really hurts performance as well
14:53Pheoxy[AWSTUTC8][m]: although vkd3d stuff hurts the most
14:56karolherbst: I see...
15:01Pheoxy[AWSTUTC8][m]: also have to watch ls -l .cache/mesa.... Is there a better way to do this?
16:38Pheoxy[AWSTUTC8][m]: anybody else testing War Thunder with NVK? Got a weird issue where some hud and minimap elements disappear usually they come back if most shaders are compiled in view I think?
18:33Pheoxy[AWSTUTC8][m]: doesn't happen with gamescope for some reason, using kde plasma 6.2.2
18:34Pheoxy[AWSTUTC8][m]: although gamescope has it's own issues currently