01:25xorg4404[d]: will there be support for vulcan on geforce 460 gtx in nvk?
01:28karolherbst[d]: probably never until a poor soul is found willing to work on it
01:29karolherbst[d]: though it's questionable if it can properly expose vulkan 1.0, because even nvidia decide it's not worth it (they shopped support for it in an early driver but removed it, because it was also kinda broken)
01:30karolherbst[d]: though it could be made good enough to support zink
01:56phomes_[d]: why would a game use range 65536 in VkDescriptorBufferInfo on nvk, but much smaller and varied range on anv? I am debugging a game crash and the range seems wrong on nvk
02:00phomes_[d]: it is using UpdateDescriptorSetWithTemplate and the info struct is written in the data from the game. I put the details in an issue: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12349
02:04gfxstrand[d]: phomes_[d]: Good question. Maybe a limit somewhere is funky?
02:04phomes_[d]: I tried modifying some limits I thought the game might base it on but did not get any difference
02:04gfxstrand[d]: That's 2^16
02:05phomes_[d]: I can try changing a bunch more
02:05gfxstrand[d]: That's also 64K which is our sparse binding limit
02:07gfxstrand[d]: I really wish there were a better way to figure out how limits affect apps
02:08gfxstrand[d]: My gut says some limit somewhere is causing them to way align up the sizes.
02:11phomes_[d]: thank you. I will take a look at where nvk limits differ from anv and test a bunch of them. I should probably get some sleep and do that tomorrow 🙂
02:14gfxstrand[d]: Cool
02:16gfxstrand[d]: Are you looking at a capture?
02:18gfxstrand[d]: Because BDA capture/replay can force high alignments. Those should only matter for buffer bind, though, not descriptor sets.
02:21phomes_[d]: Not a capture. Just launching the game in steam
02:29phomes_[d]: Maybe I should try faking the vendor id. But it seems more likely that they use some limit. I am just a bit confused about why it would be a thing to change. 64k is a lot and some writes have offsets where the distance between them match with the ranges used on anv. On nvk the writes must overlap
02:39gfxstrand[d]: Yeah
02:39gfxstrand[d]: You can also play around with this:
02:39gfxstrand[d]: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/nouveau/vulkan/nvk_buffer.c?ref_type=heads#L15
04:34tiredchiku[d]: gfxstrand[d]: so it's another "wait for nova" thing, okay
04:38tiredchiku[d]: unless I try to implement it in nouveau myself, which
04:38tiredchiku[d]: I'm really not keen on doing
05:00tiredchiku[d]: we're really getting to a point where NVK as a user experience is starting to be held back by the nouveau kmd
07:16asdqueerfromeu[d]: karolherbst[d]: 🔺 seems to like old (ATI) hardware (so they could start learning NVIDIA GPUs with that project)
07:23karolherbst[d]: thing is.. most of the code is already there because fermi is similar to kepler in a lot of ways, unless where it's not and those are the annoying bits to get right
07:23karolherbst[d]: because it also requires kernel changes.. probably, or a lot of reworks
07:28ermine1716[d]: Oh, you still care for those?
07:33karolherbst[d]: well.. atm it's not properly working in nvk
07:34karolherbst[d]: but enough code is there to fix it if one would be willing to do so
07:38ermine1716[d]: Ah. Well, I've just gave away my kepler card
11:31pavlo_kozlenko[d]: karolherbst[d]: Why nvidia remove vulkan support in fermi?
11:31pavlo_kozlenko[d]: > it was also kinda broken
11:31pavlo_kozlenko[d]: How
14:07asdqueerfromeu[d]: Since NVK seems to have atomics mostly working, nouveau ecosystem just needs one more extra atomic thing: modesetting atomics ⚛️ (are there any known issues with that?)
17:50dwlsalmeida[d]: hey is there a spec sheet for NVDEC listing the capabilities for each GPU?
17:54dwlsalmeida[d]: something like this, but up to ada: https://developer.download.nvidia.com/assets/cuda/files/NVIDIA_Video_Decoder.pdf
17:54tiredchiku[d]: dwlsalmeida[d]: https://developer.nvidia.com/video-encode-and-decode-gpu-support-matrix-new
17:56dwlsalmeida[d]: this is great, but I am also looking for max resolution and the supported profile and levels
17:57dwlsalmeida[d]: https://developer.nvidia.com/video-codec-sdk
17:57dwlsalmeida[d]: I think this is it
17:58mohamexiety[d]: yup
17:58mohamexiety[d]: also https://docs.nvidia.com/video-technologies/video-codec-sdk/pdf/NVDEC_Application_Note.pdf
18:00mohamexiety[d]: https://docs.nvidia.com/video-technologies/video-codec-sdk/12.2/nvdec-video-decoder-api-prog-guide/index.html
18:05dwlsalmeida[d]: given `struct nvk_physical_device`, how do I get the actual GPU in use?
18:05dwlsalmeida[d]: I assume somewhere in `nvk_physical_device::info`, but not clear how to go from `device_id` or `chipset` to e.g.: `Maxwell (1st Gen)*` as per that table
18:09tiredchiku[d]: pdev->info->cls_eng3d
18:10dwlsalmeida[d]: thank you sir
18:11dwlsalmeida[d]: dwlsalmeida[d]: also anybody knows anything about this? how long are these valid for?
18:17mhenning[d]: For video it might be more correct to keep track of the video class that's present instead of looking at the 3d class (pdev->info->cls_eng3d) and assuming they line up
18:22tiredchiku[d]: do we have the video class in the headers?
18:23tiredchiku[d]: nope
18:23tiredchiku[d]: struct nv_device_info has
18:23tiredchiku[d]: uint16_t cls_copy;
18:23tiredchiku[d]: uint16_t cls_eng2d;
18:23tiredchiku[d]: uint16_t cls_eng3d;
18:23tiredchiku[d]: uint16_t cls_m2mf;
18:23tiredchiku[d]: uint16_t cls_compute;
18:24tiredchiku[d]: ~~unless m2mf is the video class~~
18:24mhenning[d]: Yeah, it might require some plumbing to make it available
18:27dwlsalmeida[d]: tiredchiku[d]: we do (in my branch)
18:33tiredchiku[d]: oh, you've plumbed the video classes too? that's awesome
18:38avhe[d]: https://github.com/philipl/nv-video-info/tree/master
18:38avhe[d]: there's also this little tool that can query the capabilities from the cuvid library
18:46avhe[d]: mohamexiety[d]: something to note is that this lists maximum resolution constraints, but there is also a minimum
18:46avhe[d]: the tool i linked can be patched to output it
18:47avhe[d]: <https://github.com/averne/FFmpeg/blob/nvtegra/libavcodec/nvtegra_decode.c#L386-L458> i also have some numbers here, for maxwell 2nd gen
18:50dwlsalmeida[d]: This will only output anything for the GPU currently in use, right?
18:52dwlsalmeida[d]: Also, I am a bit confused on how `cls_video` works..`c5b0` is basically video decoding for turing, right?
18:52dwlsalmeida[d]: in which case, how do we support earlier archs?
18:56avhe[d]: dwlsalmeida[d]: yes
18:57gfxstrand[d]: tiredchiku[d]: Yeah, I know. I'm hoping to make some progress on that pre-nova but IDK how much we can effectively fix without major restructuring.
18:58gfxstrand[d]: dwlsalmeida[d]: Valid for the duration of the current command buffer recording session and execution. They go away when the command buffer is either destroyed or reset, neither of which are allowed to happen while it's executing on the GPU.
18:59gfxstrand[d]: mhenning[d]: Yeah, we should add a cls_video. Unfortunately, we might need to allocate a second context to get it, though. 😭
18:59dwlsalmeida[d]: gfxstrand[d]: I am storing a pointer so that we can dump `_nvdec_status_s` on failure if `NVK_DEBUG=push_sync`, so far this seems to work
19:00gfxstrand[d]: Yeah, that works. IDK how I feel about stashing pointers like that but it'll definitely still be alive at that time.
19:01gfxstrand[d]: It's got the same lifetime as the pushbufs themselves.
19:02dwlsalmeida[d]: gfxstrand[d]: I..already have that in my branch,
19:02dwlsalmeida[d]: https://gitlab.freedesktop.org/dwlsalmeida/mesa/-/blob/nvk-vulkan-video/src/nouveau/winsys/nouveau_device.c#L371
19:09dwlsalmeida[d]: dwlsalmeida[d]: avhe[d] would you know anything about this? I see that your tegra patch is also using C5B0?
19:19gfxstrand[d]: Depending on the Tegra, that could still mostly work.
19:21gfxstrand[d]: Nvidia often only adds stuff so 3D code written for Turing generally works on anything Turing+.
19:21dwlsalmeida[d]: ok, but then `cls_video` cannot be used to decide the video capabilities, since we'd have multiple generations being supported by, say, `c5b0`, and as per the nvidia docs, the hardware capabilities are not the same
19:22dwlsalmeida[d]: mhenning[d]: this is what I am referring to, btw
19:22gfxstrand[d]: There was a bit of a shuffle around Volta/Turing where the did delete stuff but that's about it.
19:23gfxstrand[d]: dwlsalmeida[d]: No, Turing will report c5b0, Ampere will report c7b0, etc.
19:23i509vcb[d]: I haven't checked in a while, iirc Ampere Tegra could probably run under Nova (GSPLite)
19:23avhe[d]: dwlsalmeida[d]: i use c5b0 because that was the only header published in the open-gpu-doc repo at the time i started working on the project. the register layout is backwards compatible so it doesn't matter
19:23i509vcb[d]: But it wouldn't be PCIe stuff
19:25dwlsalmeida[d]: gfxstrand[d]: yeah, my point is, what would
19:25dwlsalmeida[d]: Second
19:25dwlsalmeida[d]: generation
19:25dwlsalmeida[d]: Maxwell
19:25dwlsalmeida[d]: (GM20x,
19:25dwlsalmeida[d]: except
19:25dwlsalmeida[d]: GM206)
19:25dwlsalmeida[d]: report?
19:25dwlsalmeida[d]: Because if that's also `c5b0`, then we must find a way to say that HEVC is not supported in this case
19:26gfxstrand[d]: Maxwell B should be b1b0
19:27dwlsalmeida[d]: I dont think there's a `b1b0.h` file?
19:28gfxstrand[d]: Maybe not but that's because Nvidia hasn't published it, not because everything is c5b0
19:28dwlsalmeida[d]: ok, things are starting to make sense for me now
19:29gfxstrand[d]: We should be able to ask. If they're publishing Turing, I don't see why they couldn't publish earlier ones. They probably just haven't.
19:32avhe[d]: you don't really need it, anyway? since everything is (afaik) kept backward compatible, you can just build using c9b0.h or later, and then enable specific features/codepaths depending on `cls_video`
19:33tiredchiku[d]: if these headers are published with openrm, pre-turing haven't been published, because, well, no pre-turing on openrm
19:33gfxstrand[d]: avhe[d]: Yup. It's a bit against the current NVK coding style but it works.
19:34tiredchiku[d]: but yeah, we could ask. I don't think they'll actually publish them (for the same reason pre-turing fw won't happen) but no harm in asking
19:34gfxstrand[d]: tiredchiku[d]: They've published pre-turing for a bunch of other stuff, though. It's worth asking.
19:34tiredchiku[d]: absolutely
19:34avhe[d]: they published the 3d engine class stuff for maxwell etc, i don't see why this couldn't happen
19:35gfxstrand[d]: ahuillet: may be able to grease those wheels.
19:38dwlsalmeida[d]: avhe[d]: hmm, no P010 support for HEVC?
19:38dwlsalmeida[d]: Device 0: NVIDIA GeForce RTX 2060
19:38dwlsalmeida[d]: -----------------------------------------------------------------
19:38dwlsalmeida[d]: Codec | Chroma | Depth | Min Width | Min Height | Max Width | Max Height | Surface Formats
19:38dwlsalmeida[d]: -----------------------------------------------------------------
19:38dwlsalmeida[d]: H264 | 420 | 8 | 48 | 16 | 4096| 4096 | NV12
19:38dwlsalmeida[d]: MJPEG | 400 | 8 | 64 | 64 | 32768| 16384 | NV12
19:38dwlsalmeida[d]: MJPEG | 420 | 8 | 64 | 64 | 32768| 16384 | NV12
19:38dwlsalmeida[d]: MJPEG | 422 | 8 | 64 | 64 | 32768| 16384 | NV12
19:38dwlsalmeida[d]: MJPEG | 444 | 8 | 64 | 64 | 32768| 16384 | NV12
19:38dwlsalmeida[d]: HEVC | 420 | 8 | 144 | 144 | 8192| 8192 | NV12
19:38dwlsalmeida[d]: HEVC | 420 | 10 | 144 | 144 | 8192| 8192 | P016, NV12
19:38dwlsalmeida[d]: HEVC | 420 | 12 | 144 | 144 | 8192| 8192 | P016, NV12
19:38dwlsalmeida[d]: HEVC | 444 | 8 | 144 | 144 | 8192| 8192 | YUV444P
19:38dwlsalmeida[d]: HEVC | 444 | 10 | 144 | 144 | 8192| 8192 | YUV444P16
19:38dwlsalmeida[d]: HEVC | 444 | 12 | 144 | 144 | 8192| 8192 | YUV444P16
19:38dwlsalmeida[d]: VP8 | 420 | 8 | 48 | 16 | 4096| 4096 | NV12
19:38dwlsalmeida[d]: VP9 | 420 | 8 | 128 | 128 | 8192| 8192 | NV12
19:38dwlsalmeida[d]: VP9 | 420 | 10 | 128 | 128 | 8192| 8192 | P016, NV12
19:38dwlsalmeida[d]: VP9 | 420 | 12 | 128 | 128 | 8192| 8192 | P016, NV12
19:38dwlsalmeida[d]: -----------------------------------------------------------------
19:38redsheep[d]: gfxstrand[d]: My thinking on this has continued to head further towards actually supporting openrm being a good idea. If nothing else, it will lead to fewer surprises for users when something points at nvk if it doesn't break because the nvidia blacklists nouveau loading, especially if they end up doing that to nova as well
19:39dwlsalmeida[d]: dwlsalmeida[d]: P016 for 10bit HEVC looks wrong basically
19:40avhe[d]: dwlsalmeida[d]: P016 here means 16-bit for the surface decoded to, not the actual content. so this includes P010 and P012. the code relies on cudaVideoSurfaceFormat:
19:40avhe[d]: <https://www.ffmpeg.org/doxygen/3.4/dynlink__cuviddec_8h.html#aeadfc346b514944acf3ad5fcf8616b58https://www.ffmpeg.org/doxygen/3.4/dynlink__cuviddec_8h.html#aeadfc346b514944acf3ad5fcf8616b58>
19:41tiredchiku[d]: redsheep[d]: fwiw nvidia installer blacklisting nouveau is optional, and distros opt to make that behavior default
19:41avhe[d]: i should have said *can* include P010 and P012
19:42redsheep[d]: tiredchiku[d]: 🤷 Eitehr way it will happen
19:42avhe[d]: not sure if there's a way to query the supported bit depths in cuvid
19:42avhe[d]: for decoding
19:42gfxstrand[d]: redsheep[d]: NVK loading alongside the Nvidia proprietary driver by default is problematic. I don't want the Nvidia reps to suddenly find themselves fielding NVK issues because of weird enumeration order hiccups or anything like that. We'd need to come to some sort of understanding of how it should work.
19:42redsheep[d]: Hmm. Yeah I suppose that could be annoying from their end.
19:43tiredchiku[d]: that's more of an icd management thing though
19:43tiredchiku[d]: amdgpu does it too, I'm pretty sure amdvlk amd radv use the same kernel driver
19:43gfxstrand[d]: We'd need a solution is the point. Right now, you pick which kernel loads and that determines what userspace you get. It's pretty straightforward.
19:43tiredchiku[d]: yeah
19:44gfxstrand[d]: tiredchiku[d]: Yes but no one cares about amdvlk.
19:45gfxstrand[d]: If someone fires up a default distro install, they get NVK. If they're happy with that, great. If they go out of their way to install the proprietary drivers, that's what they should get.
19:45tiredchiku[d]: but yeah, if the wait for nova is going to be long, having openrm as at least a base to test nvk on would be helpful
19:46tiredchiku[d]: for ironing out NVKs kinks, if nothing else
19:46gfxstrand[d]: Point being that, at least as it currently stands, NVK not enumerating when nvidia.ko is loaded is a feature, not a bug.
19:46tiredchiku[d]: if nova's right around the hypothetical corner, maybe less so
19:47gfxstrand[d]: I really hope we eventually get to a future where NVK and the proprietary stuff can happily live side-by-side. But that'll take careful thought and maybe a bit of negotiation with Nvidia's Linux team.
19:49gfxstrand[d]: I think Nova is part of that picture. Once we have full userspace contexts, maybe we can start talking about CUDA on Nova. But that's several years out.
19:49dwlsalmeida[d]: avhe[d]: can somebody else run this on Ampere if you have the time please? 🙂
19:49dwlsalmeida[d]: I only have Turing and Ada
19:49dwlsalmeida[d]: Also please output the minimum values:
19:49dwlsalmeida[d]: diff --git a/nvdecinfo.c b/nvdecinfo.c
19:49dwlsalmeida[d]: index 6e504ed..b64139e 100644
19:49dwlsalmeida[d]: --- a/nvdecinfo.c
19:49dwlsalmeida[d]: +++ b/nvdecinfo.c
19:49dwlsalmeida[d]: @@ -145,8 +145,8 @@ static int get_caps(cudaVideoCodec codec_type,
19:49dwlsalmeida[d]: break;
19:49dwlsalmeida[d]: }
19:49dwlsalmeida[d]: - printf("%5s | %6s | %5d | %9d | %10d | %15s\n",
19:49dwlsalmeida[d]: - codec, format, bit_depth, caps.nMaxWidth, caps.nMaxHeight, surface);
19:49dwlsalmeida[d]: + printf("%5s | %6s | %5d | %9d | %9d | %9d| %10d | %15s\n",
19:49dwlsalmeida[d]: + codec, format, bit_depth, caps.nMinWidth, caps.nMinHeight, caps.nMaxWidth, caps.nMaxHeight, surface);
19:49dwlsalmeida[d]: return 0;
19:49dwlsalmeida[d]: }
19:49dwlsalmeida[d]: @@ -194,7 +194,7 @@ int main(int argc, char *argv[])
19:49dwlsalmeida[d]: printf("-----------------------------------------------------------------\n");
19:49dwlsalmeida[d]: CHECK_CU(cu->cuCtxCreate(&cuda_ctx, CU_CTX_SCHED_BLOCKING_SYNC, dev));
19:49dwlsalmeida[d]: - printf("Codec | Chroma | Depth | Max Width | Max Height | Surface Formats\n");
19:49dwlsalmeida[d]: + printf("Codec | Chroma | Depth | Min Width | Min Height | Max Width | Max Height | Surface Formats\n");
19:49dwlsalmeida[d]: printf("-----------------------------------------------------------------\n");
19:49dwlsalmeida[d]: for (int c = 0; c < cudaVideoCodec_NumCodecs; c++) {
19:49dwlsalmeida[d]: for (int f = 0; f < 4; f++) {
19:51tiredchiku[d]: gfxstrand[d]: one idea would be to have NVK enumerate on nvidia.ko only if an env var is set
19:51tiredchiku[d]: similar to the kepler one
19:52tiredchiku[d]: it'd at least assist w/ the dev/testing process
19:53gfxstrand[d]: tiredchiku[d]: Yeah. I do think nvidia.ko support will happen eventually. It's just enumerating by default that I currently have a problem with.
19:53gfxstrand[d]: And we've got the NVKMD abstraction so if someone wanted to start working on it...
19:53tiredchiku[d]: I was actually toying with the idea ~12h ago
19:54tiredchiku[d]: it might be too ambitious for lil old me, but
19:54gfxstrand[d]: No harm in starting on it.
19:54tiredchiku[d]: yeah
19:54tiredchiku[d]: https://tenor.com/view/jacksparrow-jack_sparrow-captainjacksparrow-captainjack-captain_jack-gif-22081901
19:54gfxstrand[d]: Worst case, you give up and it rots in a branch somewhere.
19:55gfxstrand[d]: Or maybe the worst case is that you end up maintaining it. 🤭
19:55tiredchiku[d]: I'd accept that fate
19:55tiredchiku[d]: something something job security /j
19:57avhe[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1320480272726102017/message.txt?ex=6769c096&is=67686f16&hm=24e7efddb6089c22d074d4aa26d2b91a939c8a2fba22a1a10e48fa262e8ce589&
19:57avhe[d]: dwlsalmeida[d]:
19:58tiredchiku[d]: beat me to it by a minute 😅
19:58tiredchiku[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1320480580806250556/3070nvdecinfo.log?ex=6769c0df&is=67686f5f&hm=c2e24db0fca76ca8bb1dc925d3059271d152d7d9034877b5f1e1017175141b35&
19:58tiredchiku[d]: yeah that's identical
19:58avhe[d]: btw I realize that each supported bit depth is listed in a separate line, so the surface format either means it can output full-depth data (P016), or dithered down to 8-bit (NV12)
19:59avhe[d]: tiredchiku[d]: because i had a build ready from way back when 😏
19:59redsheep[d]: I think the environment variable solution is a good one. Those who want to use nvidia's kmd with mesa can just put that in their /etc/environment and keep things from using nvidia's icd or whatever
19:59gfxstrand[d]: Yup
20:00tiredchiku[d]: I had to get out of bed, boot my pc, log in, clone, apply the patch, grab the ffnvcodec headers, and then run it e-e
20:00gfxstrand[d]: NVK_ENABLE_OGK or something
20:00tiredchiku[d]: I like talking to the little nerds in my phone in real time but it is not good for my sleep schedule
20:00tiredchiku[d]: gfxstrand[d]: NVK_I_WANT_EXPLOSIONS
20:01avhe[d]: tiredchiku[d]: and i had to pause subnautica
20:01tiredchiku[d]: avhe[d]: I yield
20:01gfxstrand[d]: Oh, the trials we endure...
20:01avhe[d]: it's a hard life 😩
20:04redsheep[d]: I definitely like the env variable over it being in some branch that has to get rebased any time I want to use it for testing. Also if it's fairly easy to set up I think there would actually be quite a few people wanting to use that config if it worked well. Nova getting as good as openrm is probably going to take a long time, and until then it would be the best way to get DSC, DP audio, proper
20:04redsheep[d]: bit depth, etc.
20:05tiredchiku[d]: Nova is probably going to take a long time to arrive itself tbf
20:05tiredchiku[d]: or that's what it feels like as an outsider
20:07airlied[d]: dwlsalmeida[d]: I only asked NVIDIA for Turing+ to go with GSP I don't think we should bother with pre gsp video the fw situation is too messy and it will confuse users
20:08airlied[d]: I don't want to spend a lot of time explaining that you need to extract fw from the blob that I don't even think we have the code to load
20:08gfxstrand[d]: redsheep[d]: Yeah, I don't want people to have to rebase indefinitely, either.
20:09tiredchiku[d]: if I understand correctly, I'd have to add in the header from openrm that has the relevant ioctls for it and then wire it up to nvkmd
20:09airlied[d]: If someone solves all the pre gsp video hurdles then we can ask NVIDIA for headers but not before
20:10gfxstrand[d]: airlied[d]: That's totally fair. I keep forgetting about that complication.
20:11airlied[d]: "the header"
20:11gfxstrand[d]: I'm also very okay with making things Turing+ in general. The old hardware is only getting older and Turning is already 6 years old.
20:11tiredchiku[d]: yeah there's five billion of them e-e
20:11airlied[d]: I'd reckon on at least 30 headers to start :-p
20:12gfxstrand[d]: 🤷🏻♀️
20:12tiredchiku[d]: only one way to find out
20:12tiredchiku[d]: add them all, wire them up, then axe headers until something breaks
20:12gfxstrand[d]: Pull in whatever we need and start hacking. We'll figure out how scattered it is pretty quickly.
20:12tiredchiku[d]: yee
20:13tiredchiku[d]: I'll get cracking tomorrow
20:13airlied[d]: I think you would need mostly what nouveau pulls in for ctrl hdrs
20:13airlied[d]: Then the ioctl ones
20:13tiredchiku[d]: I wanted to bisect to find what broke plasma wayland hardware cursors, but that'll have to wait for another day
20:16airlied[d]: We could reuse my struct generator eventually though it doesn't cover ioctl hdrs
20:16redsheep[d]: tiredchiku[d]: Did you open an issue? Might be good to, just so it's not forgotten
20:16tiredchiku[d]: not yet, no
20:17tiredchiku[d]: but also I don't have much helpful info that'd go into an issue apart from "I noticed it broken around mid-november"
20:17redsheep[d]: Ah, yeah fair
20:18tiredchiku[d]: might have a build where it isn't broken somewhere but I'd have to find that and confirm it first
20:18tiredchiku[d]: I'll get to it, eventually..
20:20tiredchiku[d]: anyway, 0150, back to bed for me
20:20tiredchiku[d]: https://tenor.com/view/powerpuff-girls-gif-16492030194795525365
20:21airlied[d]: I think also we can some more API things to nouveau just a matter of how much work vs reward they provide
20:21dwlsalmeida[d]: airlied[d]: so I should just forget about anything below Turing, basically? ack
20:21tiredchiku[d]: airlied[d]: a way to request the kernel for uncached sysmem would be great if possible 🙏
20:22airlied[d]: Yeah I wouldn't get into it until Turing+ is feature complete across decode and encode
20:22tiredchiku[d]: unless I misunderstood what you meant
20:22tiredchiku[d]: in which case, good night
20:23airlied[d]: The question is how much work that is and what the benefit is, if there is an app that can't work without uncached I'd be surprised
20:23airlied[d]: Vs say zcull or compression which also will need api
20:24airlied[d]: But people should still learn how to implement things on nouveau
20:24airlied[d]: The experience will translate to nova not like nova will magically spring up fully featured
20:26redsheep[d]: airlied[d]: Apparently it's good for performance, and stuff like vkd3d-proton doesn't like uncached being missing
20:27tiredchiku[d]: also NVKs the only dGPU driver that doesn't expose that type
20:28tiredchiku[d]: airlied[d]: noted though, maybe I should be a bit more keen on trying to write code for nouveau
20:41dwlsalmeida[d]: This is apparently missing main12?
20:41dwlsalmeida[d]: typedef enum StdVideoH265ProfileIdc {
20:41dwlsalmeida[d]: STD_VIDEO_H265_PROFILE_IDC_MAIN = 1,
20:41dwlsalmeida[d]: STD_VIDEO_H265_PROFILE_IDC_MAIN_10 = 2,
20:41dwlsalmeida[d]: STD_VIDEO_H265_PROFILE_IDC_MAIN_STILL_PICTURE = 3,
20:41dwlsalmeida[d]: STD_VIDEO_H265_PROFILE_IDC_FORMAT_RANGE_EXTENSIONS = 4,
20:41dwlsalmeida[d]: STD_VIDEO_H265_PROFILE_IDC_SCC_EXTENSIONS = 9,
20:41dwlsalmeida[d]: STD_VIDEO_H265_PROFILE_IDC_INVALID = 0x7FFFFFFF,
20:41dwlsalmeida[d]: STD_VIDEO_H265_PROFILE_IDC_MAX_ENUM = 0x7FFFFFFF
20:41dwlsalmeida[d]: } StdVideoH265ProfileIdc;
20:43pavlo_kozlenko[d]: Is hardware encoding now available?
20:43pavlo_kozlenko[d]: rly?
20:43tiredchiku[d]: wip
20:44pavlo_kozlenko[d]: tiredchiku[d]: Oh, I missed a lot
20:45pavlo_kozlenko[d]: When will this page be updated? 😁
20:45pavlo_kozlenko[d]: https://nouveau.freedesktop.org/VideoAcceleration.html
20:46airlied[d]: dwlsalmeida[d]: not sure it was put in standard, or what hw supports it
20:47dwlsalmeida[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1320492943467089930/Screenshot_2024-12-22_at_17.47.19.png?ex=6769cc63&is=67687ae3&hm=bd83f612c05ba7d6b515a7c2e71056fc805897e83a2fa3aabd732e4c5c81cfc0&
20:47dwlsalmeida[d]: airlied[d]:
20:47dwlsalmeida[d]: HEVC is the 4th column
20:48airlied[d]: Surprised the definition was lost then
20:48dwlsalmeida[d]: so apparently yeah main12 is supported by the hw
20:48dwlsalmeida[d]: I guess the nvidia people at the vulkan video tsg would not let this slip by, so this is a bit surprising
20:48dwlsalmeida[d]: I'll ask Tony in the next call
22:38avhe[d]: i think Main 12 would be included in the range extensions https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding?useskin=vector#Version_2_profiles
22:38avhe[d]: along with 4:4:4
22:38dwlsalmeida[d]: has anyone here used prof in NVK?
22:39dwlsalmeida[d]: I really need to figure out why my Rust version takes 10x to execute, debug vs release makes no difference
22:42airlied[d]: should just work, doubt it needs anything special
22:43gfxstrand[d]: It's been a bit but yeah, I've used it.
22:43dwlsalmeida[d]: it apparently needs a `-g` flag when compiling
22:43airlied[d]: debug builds should have that
22:43dwlsalmeida[d]: ah, -g is debug symbols?
22:44dwlsalmeida[d]: I thought it was something perf specific
22:44dwlsalmeida[d]: actually, it seems to be `-pg`
22:46dwlsalmeida[d]: isn't this the same flag that's used by `ftrace`?
22:56gfxstrand[d]: A debug build should have everything you need for perf.
22:57gfxstrand[d]: I've used it many times