11:59 karolherbst[d]: seems like Nvidia plans to move Maxwell, Pascal and Volta to a legacy driver branch
12:00 karolherbst[d]: a bit surprising they also cut out Volta, but the runtime code is different enough in a few places so it probably makes a lot of sense (and who cares about volta anywaay)
12:02 tiredchiku[d]: yeah
12:02 tiredchiku[d]: 570 driver """""leaked""""" too
12:03 tiredchiku[d]: https://developer.download.nvidia.com/compute/cuda/redist/nvidia_driver/linux-x86_64/
12:49 ermine1716[d]: Oh, I thought Maxwell was EOL'd already?
13:03 tiredchiku[d]: nope
13:09 notthatclippy[d]: GM10X is EOL as far as I know. GM20X is not.
13:10 notthatclippy[d]: I don't think GM10X was ever productized for desktop, it's mostly laptop stuff. i.e. the gtx 800 series that is MIA on desktop.
13:12 notthatclippy[d]: karolherbst[d]: This applies only to CUDA currently, in the sense that new CUDA features won't be working on those. The overall driver stack still supports them.
13:31 mohamexiety[d]: notthatclippy[d]: it was for one product; GTX 750 and GTX 750Ti
13:31 mohamexiety[d]: but that's as far as it went on desktop
13:34 notthatclippy[d]: Thanks! Somehow I totally missed that one.
13:42 avhe[d]: dwlsalmeida[d]: do you know if we have a comprehensive table of gpu models/chips and associated nvdec revisions?
13:42 avhe[d]: The matrix provided by nvidia only lists codec support which doesn't tell us whether some extensions (eg. hevc range extensions) are supported <https://developer.nvidia.com/video-encode-and-decode-gpu-support-matrix-new>
13:42 avhe[d]: I believe nvidia uses a versioning system for the engine rev (see <https://github.com/NVIDIA/open-gpu-doc/blob/master/classes/video/nvdec_drv.h#L323-L325>), but I'm unable to find info for desktop cards, only for tegras (eg. <https://github.com/alliedvision/linux_nvidia_jetson/blob/master/kernel/nvidia/drivers/video/tegra/host/t23x/t23x.c#L271>)
13:43 avhe[d]: and even then, some info is missing (for instance, when was the vp9 bit depth stuff introduced)
13:45 dwlsalmeida[d]: I can ask Tony..but they’re usually behind a red tape somehow
13:45 dwlsalmeida[d]: Gotta ask their managers, legal, the works
13:46 avhe[d]: Yeah, I imagine... In any case this is something you will also need for your vulkan-video work, eventually
13:46 dwlsalmeida[d]: I mean, we’re fighting an uphill battle here right, we might as well try, and if the firmware rejects it, then sorry
13:47 dwlsalmeida[d]: We did the best we could with the little that was put out there by the vendor
13:47 avhe[d]: I guess we can kind of piece together something from looking at info from the tegra side, and testing with the cuvid test app on various cards <https://github.com/philipl/nv-video-info>
13:49 dwlsalmeida[d]: But that doesn’t say what you’re after right, it won’t say anything about extensions
13:50 avhe[d]: It should be enough to figure out range extensions for hevc and vp9, which is the most important part
13:50 avhe[d]: The other two hevc extensions are slice-level decoding and multi-viewpoint I believe
13:55 dwlsalmeida[d]: Wait how will nv-video-info help here?
13:55 notthatclippy[d]: I think you can figure it out from openrm and the class descriptor lists.
13:57 notthatclippy[d]: Here you will find a pairing between the HAL function and the nvdec class (search for `_VIDEO_DECODER`): <https://github.com/NVIDIA/open-gpu-kernel-modules/blob/main/src/nvidia/generated/g_gpu_class_list.c>
13:57 notthatclippy[d]: And then here you'll find the pairing between the HAL function and which chips it applies to: <https://github.com/NVIDIA/open-gpu-kernel-modules/blob/main/src/nvidia/generated/g_gpu_nvoc.c#L990-L1030>
13:58 notthatclippy[d]: The actual IP version number I don't know if it's logged anywhere, but the support matrix will tell you the major version, and then just increment the minor version as you go along I guess.
13:58 avhe[d]: dwlsalmeida[d]: It gives a list of supported bit depths and subsampling schemes for each codec, see eg. here https://discord.com/channels/1033216351990456371/1034184951790305330/1320475457849917510
13:58 avhe[d]: In that message we can see that both hevc and vp9 high bit depths (ie.the hevc "v1" and vp9 "v1" substructures in the codec setup) are supported on the 2060
14:01 avhe[d]: notthatclippy[d]: I'll take a look, this is promising already. Then I guess we would need a map from nvdec class to nvdec revision, and finally from nvdec revision to supported extensions
14:01 avhe[d]: Or just nvdec class to supported extensions would be sufficient I imagine
14:03 notthatclippy[d]: Shouldn't those be listed in the appropriate class's headers in <https://github.com/NVIDIA/open-gpu-doc/tree/master/classes/video> ?
14:04 notthatclippy[d]: How would you otherwise use the extensions anyway?
14:07 avhe[d]: I don't think the class definitions gives us info on which extensions are supported. Extensions are just additions at the end of the main codec setup structure (<https://github.com/NVIDIA/open-gpu-doc/blob/master/classes/video/nvdec_drv.h#L482-L484>), and the challenge is to know whether or not you can use it
14:09 notthatclippy[d]: ACK. Sorry, I wouldn't know then, this is a direct usermode->nvdec thing and neither the kernel nor GSP have this info as far as I know. Best ask someone from the NV video group.
14:11 notthatclippy[d]: The red tape for a quick question should be minimal. It mostly goes full corporate once we need to actually write working code and license it.
14:11 avhe[d]: One thing I came across is this bit in openrm <https://github.com/NVIDIA/open-gpu-kernel-modules/blob/master/src/common/sdk/nvidia/inc/ctrl/ctrl0080/ctrl0080bsp.h#L107>, that the cuvid library calls during init. Would you know if this is related?
14:13 notthatclippy[d]: That's a lot higher level than what you need. Stuff like "does it support vp9/hevc/etc at all"
14:14 avhe[d]: Got it, thanks for checking
14:25 dwlsalmeida[d]: dwlsalmeida[d]: notthatclippy[d] I wonder if you feel like helping out with this?
14:25 dwlsalmeida[d]: It'd be great if we got this to work on ffmpeg too, but without any tips on what is crashing the fw, it's impossible to fix
14:26 dwlsalmeida[d]: the same exact code is working fine with gstreamer
14:30 notthatclippy[d]: Let's give skeggsb9778[d] a few more days? :)
14:30 notthatclippy[d]: I'm not actually set up to decode these logs from nouveau and it would take a few hours just to get to that point. So if Ben has the 15 minutes to do it anytime soon, it'd be great. [Ben: I can help look at the logs after they're decoded if it's not obvious]
14:30 dwlsalmeida[d]: yeah sure, I ask that knowing full well that you guys have full-time jobs with other priorities
14:30 dwlsalmeida[d]: no worries
14:31 dwlsalmeida[d]: last time we figured out it was a WFI command that was not supported on the video queue, I wonder what it's going to be this time
14:31 notthatclippy[d]: I'll gladly take a bit of time to help unblock you guys in general, but if it ends up being half a day's of work then it needs weighing against all the other stuff - and there's a lot of other stuff :)
14:32 dwlsalmeida[d]: do you know what the bits are for error_code == 11 ?
14:32 dwlsalmeida[d]: in nvdec_status_s
14:32 dwlsalmeida[d]: also error_code == 3
14:33 dwlsalmeida[d]: last time you said this was a bitfield with some not-exactly-helpful bit names
14:34 dwlsalmeida[d]: dwlsalmeida[d]: also do you know which of these buffers must contain data fed by the driver?
14:35 dwlsalmeida[d]: for now I assume `NVC7B0_SET_TILE_SIZE_BUF_OFFSET`, `NVC7B0_AV1_SET_GLOBAL_MODEL_BUF_OFFSET`, `NVC7B0_AV1_SET_FILM_GRAIN_BUF_OFFSET` and `NVC7B0_AV1_SET_PROB_TAB_READ_BUF_OFFSET`
14:37 notthatclippy[d]: bit 0 is a useless "error occurred" thing, I imagine it'll always be set. Bit 1 suggests a timeout. Bit 3 I'm not sure about
14:38 notthatclippy[d]: And I don't know the video class enough to answer this stuff, sorry. I'm a kernel/GSP guy.
14:39 avhe[d]: dwlsalmeida[d]: One thing I did figure out about these is that in the tegra library, they group bits together when checking for errors (0x12/0b1101 and 0x12/0b10010)
14:39 avhe[d]: So this might suggest there are two classes of errors
14:40 avhe[d]: 0xd/0b1101*
14:41 dwlsalmeida[d]: @averne still doesn't say anything about the number 11, or the number 3 in particular, right
14:41 dwlsalmeida[d]: notthatclippy[d]: a timeout, that's..actually helpful
14:42 dwlsalmeida[d]: maybe it just means it hanged..
14:42 avhe[d]: Nope, no logs unfortunately. I grepped for the names of the bits that were dropped last time and no hits either
16:21 orowith2os[d]: airlied[d]: how's https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29232 feeling?
16:21 orowith2os[d]: decided to sift through some older mesa PRs
17:43 redsheep[d]: orowith2os[d]: I finally got set back up to test again with some major help from tiredchiku[d]
17:43 redsheep[d]: I tried to run a full nvk+zink session last night and ended up on a black screen with a cursor on sddm, so before even logging in. I'm going to try Wayland sddm tomorrow but either way there still seem to be some snags, at least on my machine
17:44 redsheep[d]: Hoping to figure it out a little better so I can open and update issues for zmike's rodeo
17:50 orowith2os[d]: Yeah, I have some stuff he might like to rip apart if he enjoys running out to Firefox :p
17:55 mhenning[d]: redsheep[d]: Might want to test on top of https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33204 (which is currently in the process of landing)
17:57 redsheep[d]: mhenning[d]: Will do, thanks
19:16 gfxstrand[d]: Someone should implement pipeline binaries on NVK.
19:16 gfxstrand[d]: IDK if we have an issue for that or not
19:21 gfxstrand[d]: I think Alyssa has a branch somewhere.
19:24 mohamexiety[d]: pipeline binaries?
19:25 mohamexiety[d]: oh found it
19:30 gfxstrand[d]: It's kind of a terrible extension. ESO is way better.
19:34 dj-death: is it? ;)
19:34 karolherbst[d]: ESO is best
19:34 ermine1716[d]: ESO?
19:34 karolherbst[d]: though might be biased, because it's almost no work on nvidia 😄
19:35 karolherbst[d]: nvidia hw supports all the stages 1:1 in hardware and linking is done outside the shader binary
19:36 tiredchiku[d]: ermine1716[d]: elder scrolls online :ha:
19:37 dj-death: should have been named VK_NVIDIA_shader_object
19:38 karolherbst[d]: it's kinda weird why all the other vendors looked at the APIs and decided: yep, we just do it the painful way
19:39 gfxstrand[d]: dj-death: Arguably, yes, they should have just called it that and released it.
19:39 gfxstrand[d]: But I am a big fan of the extension and some (not all!) of the design principals around it.
19:40 karolherbst[d]: I wonder what are the main reason why the other vendors have their own custom stages, though I guess it's easier to implement in hardware and might be more performant?
19:40 mohamexiety[d]: ermine1716[d]: https://registry.khronos.org/vulkan/specs/latest/man/html/VK_EXT_shader_object.html
19:41 dj-death: gfxstrand[d]: I very much dislike it's in vulkan and contradicting a bunch of default principles
19:41 dj-death: especially as EXT
19:43 gfxstrand[d]: Yeah, the combination with EDS3 and dynamic state is all kinds of broken.
19:44 dj-death: enable all the features by default is also non sense
19:46 gfxstrand[d]: Like, if you forget about pipelines and assume all the state is dynamic, it mostly makes logical sense. But I seriously hope no apps are mixing and matching on a single command buffer. I doubt that reliably works on any implementation.
19:46 ermine1716[d]: mohamexiety[d]: _looks at contributor list and sees familiar names_
19:47 gfxstrand[d]: IDK how I feel about feature enables. I think robustness was definitely an oversight. I don't know how protected works so I'm less clear on that one.
19:47 gfxstrand[d]: I need to finish my robustness extension.
19:48 dj-death: lol protected
19:57 tiredchiku[d]: finally found a game where we're beating prop driver
19:57 tiredchiku[d]: rage 2
19:58 tiredchiku[d]: ~1000 fps vs ~1600 fps (on the main menu :lul:
19:58 tiredchiku[d]: unfortunately
19:59 tiredchiku[d]: the game crashes when loading into it
19:59 tiredchiku[d]: native vulkan renderer
20:31 redsheep[d]: Time to declare nvk superiority, the main menu is the place to be
20:33 mhenning[d]: tiredchiku[d]: want to file a bug report for the crash?
20:33 redsheep[d]: In all seriousness though yeah there have been a couple cases that are probably CPU bound where nvk has looked very good. I'm optimistic for what that can mean in the future
20:33 tiredchiku[d]: I do, but after gathering more info :)
21:13 esdrastarsis[d]: tiredchiku[d]: this game had issues with nv prop years ago, did they fix it?
21:14 tiredchiku[d]: the egs copy? no
21:14 tiredchiku[d]: that's why I installed it
21:14 tiredchiku[d]: steam copy is apparently fine
21:14 tiredchiku[d]: did poke arthur with the bug id though
21:14 tiredchiku[d]: let's see
23:35 skeggsb9778[d]: OftenTimeConsuming: you're calling mthd 0x288 somewhere
23:36 skeggsb9778[d]: dwlsalmeida[d]: you're calling mthd 0x288 somewhere
23:37 skeggsb9778[d]: unless a mthd is named NVxxB0_, or NVxx6F_ - you can't call it on an nvdec channel
23:38 dwlsalmeida[d]: Thank you, that’s extremely helpful