00:07dwlsalmeida[d]: What is this NVIF business?
00:08dwlsalmeida[d]: (also this ABI16 thing, which seems to be a special case of something)
00:08airlied[d]: it's the interface between the nouveau driver front and backend
00:09airlied[d]: abi16 is the userspace ABI that was going to be replaced, but I think ended up not being, so is the userspace ABI
01:06asdqueerfromeu[d]: airlied[d]: Just like GTT I guess?
01:10tiredchiku[d]: airlied[d]: fun (?) fact: the proprietary driver does note have any of that :D
01:16airlied[d]: they do they just don't call it
01:19tiredchiku[d]: :Thonk:
01:20tiredchiku[d]: Memory info (GL_NVX_gpu_memory_info):
01:20tiredchiku[d]: Dedicated video memory: 6144 MB
01:20tiredchiku[d]: Total available memory: 6144 MB
01:20tiredchiku[d]: Currently available dedicated video memory: 5921 MB
01:20tiredchiku[d]: OpenGL vendor string: NVIDIA Corporation
01:20tiredchiku[d]: OpenGL renderer string: NVIDIA GeForce GTX 1660 Ti/PCIe/SSE2
01:20tiredchiku[d]: the output for this is different on NVK, as well as AMD
01:21tiredchiku[d]: as in, the Total Available Memory value is different
01:23tiredchiku[d]: even vulkaninfo has the differences, the memory heaps
01:25airlied[d]: yeah GART and GTT are the same thing
01:26tiredchiku[d]: likely a driver bug, but yeah, nvidia doesn't _seem_ to show the shared memory, if i even uses it
01:33airlied[d]: I think we also could not expose as much as we do with modern hw, but NVIDIA drivers don't engage with overcommitting physical memory so have different limitations
01:36dwlsalmeida[d]: OK, my google-fu and git-fu failed me here, what is this:
01:36dwlsalmeida[d]: struct drm_nouveau_channel_alloc req = { .fb_ctxdma_handle = ~0, .tt_ctxdma_handle = 0x300 };
01:36dwlsalmeida[d]: envytools apparently has nothing explaining that
01:37dwlsalmeida[d]: most importantly, if you do `struct drm_nouveau_channel_alloc req = {}`, you don't get XXb0, which is the video object class
01:45airlied[d]: that is an api hack
01:45airlied[d]: if you pass in ~0 for the fb ctxdma handle, the tt ctxdma handle is used to represent an engine
01:49airlied[d]: it uses the NOUVEAU_FIFO_ENGINE* defines in the uapi
01:51dwlsalmeida[d]: #define NOUVEAU_FIFO_ENGINE_GR 0x01
01:51dwlsalmeida[d]: #define NOUVEAU_FIFO_ENGINE_VP 0x02
01:51dwlsalmeida[d]: #define NOUVEAU_FIFO_ENGINE_PPP 0x04
01:51dwlsalmeida[d]: #define NOUVEAU_FIFO_ENGINE_BSP 0x08
01:51dwlsalmeida[d]: #define NOUVEAU_FIFO_ENGINE_CE 0x30
01:51dwlsalmeida[d]: ```
01:51dwlsalmeida[d]: The OR of everything above is not 0x300 though
01:53dwlsalmeida[d]: is 0x300 some special value meaning `all engines`?
02:38airlied[d]: no 0x300 is just what I added in my patch
02:38airlied[d]: no idea why I picked that value
02:39airlied[d]: I've also no idea why CE is 0x30 though
02:39airlied[d]: since I don't see the code ever uses them as a mask
02:39airlied[d]: skeggsb9778[d]: do those values have meaning? ^^
02:46skeggsb9778[d]: iirc it was once a mask (to say "either ce0 or ce1")
02:51skeggsb9778[d]: really probably need a better uapi that knows about runlist topology etc
02:52skeggsb9778[d]: what's there was hacked in when kepler appeared and introduced multiple runlists, and didn't see much attention since
02:53dwlsalmeida[d]: Wow, thanks, that’s extremely helpful !
02:58airlied[d]: so at a guess my patch series should not use 0x300 🙂
03:46skeggsb9778[d]: the uapi is horrific anyway, it hardly matters 😛
03:46skeggsb9778[d]: but yeah, a single bit per "engine type" is probably fine for now
03:48skeggsb9778[d]: ie. these days for "ce" the drm driver will pick the first runlist which has a solo ce (ie. not the one on the gr/compute runlist), if it exists, and fall back to the ce on the same runlist as gr
03:48Spawns: hello. i read that nouveau now supports automatically reclocking turing GPUs, with something called GSP firmware. how do i actually use this?
04:04airlied[d]: probably just use a modern distro
04:06Spawns: im on gentoo and using 6.8 something kernel
04:06Spawns: im pretty sure the GPU is stuck in low power mode though
04:08airlied: Spawns: maybe try boot with nouveau.config=NvGspRm=1
04:09Spawns: where do i put that? in the kcmdline?
04:12airlied: you also need to make sure you have latest linux-firmware installed
04:13Spawns: okay ill try this, thank you
04:13Spawns: its very possible my linux firmware is out of date
06:39tiredchiku[d]: unlikely, unless you haven't updated linux-firnware in over a year
07:16Spawns_Carpeting: Is this the official nouveau chat? Am I on oftc or is my client broken
07:17tiredchiku[d]: yes, this is the official channel on OFTC
07:19Spawns_Carpeting: Thanks my client must be bugging out or something. I asked a question on accident in the libera version of this channel I think. My question was about a ray tracer that uses shaders to do computations, but when it takes too long the driver seems to kill my process
07:19Spawns_Carpeting: Here's the system log output https://bpa.st/WTN2A
07:20Spawns_Carpeting: I think this is in part related to my GPU not entering high power mode, it being stuck in low power mode means it gets bogged down a lot easier I assume, but I was wondering if there is a way to prevent this
07:21Spawns_Carpeting: I was also wondering why the whole system hangs when the ray tracer is doing work, if this is a nouveau limitation or whether its just how it is in general
07:22tiredchiku[d]: nvk does not support the ray tracing extensions yet
07:22Spawns_Carpeting: I'm doing ray tracing manually in a shader
07:22tiredchiku[d]: as for the GPU 's power mode, what GPU is it?
07:22Spawns_Carpeting: Its an rtx 2060
07:23tiredchiku[d]: you might need to boot with nouveau.config=NvGspRm=1 to enable the GSP, which handles power management among other things
07:23Spawns_Carpeting: I didn't get a chance to try that yet, I'm compiling the new kernel and stuff and will try tomorrow
07:27Spawns_Carpeting: Is there something I can set to tell the driver to not timeout the GPU even if its stuck doing something for a little while
07:27Spawns_Carpeting: Im pretty sure there is some sort of watchdog that kills my process
08:38tiredchiku[d]: not really, the issue looks more like the GSP is snagging on something and crashing
08:38tiredchiku[d]: to my untrained eye, at least
09:30divya: Hello! I'm considering to buy a GPU at last. But I wanted to buy only those that have good/complete free software compatibility. Is it still true that only GTX 780ti supports this?
09:32karolherbst: In theory yes, but there can always be random bugs. Also Vulkan support on that one isn't really there yet, so there is that drawback unless somebody finds enough time to complete the vulkan support there
09:34phasta: tbh I would just buy an AMD card at this point ^^'
09:38divya: Are AMD cards supported by nouveau/libre drivers?
09:47phasta: AMD is supported by the amdgpu driver which is inline and open source
12:47tiredchiku[d]: this was helpful
12:47tiredchiku[d]: https://www.youtube.com/watch?v=h9Z4oGN89MU
13:12notthatclippy[d]: tiredchiku[d]: Haven't watched it but it made the rounds at NV and people say it's great and they learned a lot.
14:03mohamexiety[d]: yeah that channel is a hidden gem
14:04mohamexiety[d]: they're _really_ high quality and also well researched. their videos are accurate and insightful