00:00gfxstrand[d]: There are always going to be games that break when they think we're the prop driver. But I agree closing that gap is a good thing when we can.
00:00redsheep[d]: Radv or whater might not always be happy to be fed Nvidia optimized stuff but assuming nvk can make those optimizations still help as they do on prop it's a good thing
00:01gfxstrand[d]: NVK is always going to be a different driver. But we should try to make stuff work as well as we can.
00:01redsheep[d]: gfxstrand[d]: Yeah the downside would be sometimes being expected to share Nvidia prop quirks
00:41esdrastarsis[d]: gfxstrand[d]: "According to frog..." lol
00:46gfxstrand[d]: GitLab names. 🤷🏻♀️
00:53saancreed[d]: redsheep[d]: No, latencyflex doesn't even implement the entire API surface of Reflex. Using the Vulkan extension is probably way to go nowadays, only DXVK is blocked by that.
07:45tiredchiku[d]: an interesting issue was filed on the dxvk tracker
07:45tiredchiku[d]: https://github.com/doitsujin/dxvk/issues/4600
09:48awilfox[d]: I don't know why any of the mappings for libwayland-client.so would be opened writeable, but every other bit of that issue makes me think that somehow the card was led to scribble over host memory. In fairness I have not heard of that in many years, but I do remember back in 2018 having IOMMU checkstops on a Power machine caused by a Nvidia card trying to write to memory it should not have…
11:42tiredchiku[d]: tested, notourbug
11:42tiredchiku[d]: unless memory management on turinv vs ampere is so different that turing can scribble over host mem while ampere can't
12:45dwlsalmeida[d]: avhe[d]: any guess on the AV1 skip length?
12:50avhe[d]: No clue about that sorry, I haven't looked at av1 as it's not supported on Maxwell
12:51avhe[d]: But it's something I'd like to take a look at after I get a jetson nano super
12:52dwlsalmeida[d]: how did you RE the h265 one?
12:53dwlsalmeida[d]: guessing?
13:15avhe[d]: i reversed their parsing library yeah
13:22avhe[d]: But it seems to be working differently for AV1. Here for HEVC you can see the NumBitsToSkip field which ends up in sw_skip_start_length, but there doesn't seem to be an equivalent in the AV1 structure <https://developer.nvidia.com/docs/drive/drive-os/6.0.8/public/drive-os-linux-sdk/api_reference/nvmedia__common__decode_8h_source.html>
13:22avhe[d]: So either it's calculated later (which should make it easier to figure out), or it can be left blank
13:54dwlsalmeida[d]: yeah, the vulkan video av1 api also gives us `FrameHeaderOffset` and `TileOffset`
13:54dwlsalmeida[d]: if it's not 0, then maybe one of these two, lets see
15:36gfxstrand[d]: tiredchiku[d]: That's... Entertaining. I guess it's theoretically possible that nouveau isn't cleaning up old mappings properly somewhere or missing TLB flushes but I doubt it would be that reproducible.
15:37tiredchiku[d]: yeah, it's happening on their system with a 100% hitrate
15:38gfxstrand[d]: That smells like something else is borked and the game is tickling it. Like, I would be checking for SSD hardware futures before assuming nouveau.
15:52tiredchiku[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1327304004404908073/2jSFOEr.png?ex=678293ae&is=6781422e&hm=6c980aa53fce0b89a3b92bbdbe1e175f39b5057739ba57de81771cc581733c62&
15:52tiredchiku[d]: also our current working theory
15:56dwlsalmeida[d]: airlied[d]: just spoke to the AMD people at the vulkan video call, they're parsing the bitstream in the firmware
15:56dwlsalmeida[d]: I assume the same for NVIDIA
15:56dwlsalmeida[d]: apparently that's how they got around the bitstream skip stuff
16:00dwlsalmeida[d]: for the vp9 prob updates, they say they're doing that in fw too
16:59dwlsalmeida[d]: any thoughts on these?
16:59dwlsalmeida[d]: 1 unsigned short superres_upscaled_width; // upscale width, frame_size_with_refs() syntax,restoration will use it
16:59dwlsalmeida[d]: 2 unsigned short superres_luma_step;
16:59dwlsalmeida[d]: 3 unsigned short superres_chroma_step;
16:59dwlsalmeida[d]: 4 unsigned short superres_init_luma_subpel_x;
16:59dwlsalmeida[d]: 5 unsigned short superres_init_chroma_subpel_x;
17:19avhe[d]: https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/master/Docs/Appendix-Super-Resolution.md
17:19avhe[d]: codec feature afaict
18:00dwlsalmeida[d]: yeah, superres for sure,
18:01dwlsalmeida[d]: but none of the parameters I pasted are in the spec
18:01dwlsalmeida[d]: (except for superres_upscaled_width)
18:29dwlsalmeida[d]: Nicolas managed to find this in the v4l2 driver too
18:37avhe[d]: hantro stuff again?
19:17tiredchiku[d]: is it true that apps that are "closed" (have a background process and can be reopened via the systray) do not keep their allocated vidmem buffers on windows?
19:18tiredchiku[d]: or in simpler words
19:18tiredchiku[d]: on windows, does closing an app to the system tray free up the vram it was using?
19:21redsheep[d]: tiredchiku[d]: I'm pretty sure it depends on the application, but generally I would expect less or no vram usage from a normal app in the tray
19:22tiredchiku[d]: hm
19:22tiredchiku[d]: apparently that is not how it works on linux
19:26redsheep[d]: tiredchiku[d]: I'd be surprised if whatever you're seeing isn't just an issue with certain UI frameworks. At least on windows you can have an application with no UI at all request a tray icon, so it's definitely possible to have no vram except maybe the icon itself. Idk how tray icons work on Linux but it would be weird to be different
19:27tiredchiku[d]: no, I'm seeing no difference in vram used by the process whether the app is open or relegated to a tray icon
19:28tiredchiku[d]: tried it with steam, spotify, and discord so far
19:28tiredchiku[d]: cef, cef, electron
19:28tiredchiku[d]: using nvidia-smi to check
19:28redsheep[d]: Right, so that's an application/framework issue
19:29redsheep[d]: And not really an issue if I they don't use much and want to be responsive
19:29tiredchiku[d]: let me try transmission-qt (torrent client)
19:29tiredchiku[d]: redsheep[d]: it does add up
19:30tiredchiku[d]: ~300mb for all three of those is already nearly 1/8th of my total vram
19:31tiredchiku[d]: it's not always that much, but still
19:32redsheep[d]: tiredchiku[d]: Sure. It's just one of those situations where it's not a design flaw with tray icons, just applications being suboptimal and thinking they're the only important thing going on. We sacrificed efficiency for the convenience and ease of development
19:32redsheep[d]: When we decided everything should just be a browser, and that browsers should do everything
19:34tiredchiku[d]: nvm got out of bed to test it
19:34tiredchiku[d]: to see if my memory was being ass
19:34tiredchiku[d]: spotify frees up resources entirely, steam drops half of them
19:35redsheep[d]: That's good
19:38tiredchiku[d]: so my memory was being shit
19:38tiredchiku[d]: ok
19:38tiredchiku[d]: back to bed
19:39redsheep[d]: tiredchiku[d]: Irony
19:39tiredchiku[d]: :vanpalm:
19:41tiredchiku[d]: tiredchiku[d]: bad idea
19:41tiredchiku[d]: it uses 3MB even when focused and full-screen
19:42tiredchiku[d]: and continues to use 3mb when in the tray
19:43HdkR: Lucky it's only 3MB :)
19:45tiredchiku[d]: yeah, but not ideal for me wanting to test 😅
20:01airlied[d]: I think Windows can tell apps the GPU went away to force them to drop contexts and vram
20:02airlied[d]: dwlsalmeida[d]: yeah parsing it in fw would be how to do it properly 🙂 also what Intel do when you have the fw, just not sure where NVIDIA needs it, maybe only for encrypted streams?
22:33gfxstrand[d]: Windows memory management is also generally app visibility-aware. Like minimized apps will get swapped out first; stuff like that. Linux has no way to do that. The compositor isn't given that much power.
22:49redsheep[d]: An os where every part isn't meant to be as interchangeable has its advantages. Not to say that some of that couldn't come to the Linux desktop, but any time lots of different things need to work closely that means getting a lot of people with different goals to agree (as all of you are already well aware)
22:50redsheep[d]: Just saying sometimes it's a good thing for someone to be able to just say "agree on this and move on"