02:38 cheako: pressure-vessel-wrap[560604]: W: "opt/amdgpu/share/libdrm" is unlikely to appear in "/run/host"
02:38 cheako: I've been having this problem running amd-pro drivers with steam games.
17:30 cheako: Venemo: It may never be possible for me to learn how to tell something to anyone else. I wonder if the issue tracker would work better if questions were asked here and I updated my comments until they are understandable, it may be tough on someone to read through our question/answer sections.
19:27 cheako: I've tried to explain this as part of https://gitlab.freedesktop.org/mesa/mesa/-/issues/6012 If I do just reloading I can restart NMS 50 times and get the same FPS, but issuing a suboptimal or performing in-game tasks almost always rolls a new FPS. However from one week to the next the number I get when starting NMS can change and I get number similar to the numbers I get from the other methods.
19:29 cheako: So I know if someone tried they'd see the same FPS, but that's like counting 10 black crows and then claiming all crows are black... I'm saying I've seen white crows, I get the same FPS numbers as in the video.
19:30 cheako: From month-to month. So often when starting NMS I'll get 7 FPS, but other weeks it'll be 60 or 30.
19:32 cheako: It does seem to always be `1/2^x`, multiples of a half? Though that could be explained by observation bias.
19:33 cheako: The layer I wrote was awesome! I'd start NMS and get 7FPS, but then it'd send a suboptimal and it's like I restarted, but it didn't take 5min.
19:34 cheako: Though with the latest patch suboptimal seems to brick NMS, could be some rust interaction.
21:11 Venemo: cheako: you can just answer yes or no on the gitlab issue
21:16 cheako: It depends on how you define "experienced the same problem" and quickly gets into philosophy, so answering just no is to be opaque to the extreme.
21:26 cheako: I'll be away till tomorrow, CST.
22:58 Venemo: cheako: so if you didn't experience the same problem on AMDVLK, then it looks like AMDVLK works nicely for you. then I recommend to just enjoy using AMDVLK then
22:59 Venemo: can we close the issue?
22:59 cheako: 777Both drivers have problems with consistently providing the same FPS, it just takes weeks of testing to find that out.
23:00 cheako: Also amdvlk has other problems, crashes and artifacts that the radv driver doesn't.
23:02 cheako: That's why I'm not saying keep testing to see if you can get the same random FPS as I do... because if you did that you'd be unable to move forward until you could repeat it in another week.
23:02 cheako: I keep asking what you would test for that second week?
23:03 Venemo: you just said the opposite
23:03 Venemo: sorry cheako but now it really feels to me like you are intentionally trolling me
23:06 Venemo: so, do you experience this problem on AMDVLK or not?
23:06 Venemo: if not, then please enjoy using AMDVLK
23:06 Venemo: if yes, that means both drivers have the same problem on your computer
23:14 cheako: yes
23:18 Venemo: okay, this would hint that either both drivers have the same bug or it's not a driver related issue
23:23 cheako: Either way, there is still some data that could be collected that would help... I don't think it's worthwhile to narrow down where fingers should be pointed, it seems wasteful when we could just solve for the cause and then point fingers.
23:23 Venemo: great
23:24 Venemo: if you have any suggestions, I'm listening
23:26 cheako: We need someone who knows these systems well enough to generate a list of systems that could cause this effect, then I could write code to watch those systems closely. Memory types was a good guess, but I think I ruled that out. I've narrowed it down to a handful of vulkan calls, specifically the create grfx pipeline and create swapchain/descendants.
23:29 Venemo: the pipeline does not change when you hit alt tab or the windows key on your keyboard
23:30 Venemo: the swap chain could indicate problems elsewhere, eg. window system integration or the compositor or who knows where
23:30 cheako: *IT DOES*, my logs clearly show the pipelines being destroyed and recreated. and obviously when the application is restarted it needs new pipelines.
23:31 Venemo: given the same input, the driver will compile the same pipeline for you
23:32 Venemo: if the pipeline was already compiled before, then it is loaded from a cache
23:32 cheako: I don't know what to say, the video clearly shows otherwise.
23:32 Venemo: assuming that the same pipeline is being recreated, it is going to be a cache hit
23:33 Venemo: the thing on your video could be caused by literally anything
23:34 cheako: Let's start with a list of anything then.
23:34 Venemo: okay
23:34 Venemo: I'm listening
23:35 cheako: We need someone who knows these systems well enough to generate a list of anything, now.
23:36 Venemo: okay, let me know when you find someone
23:39 cheako: Where should I look for someone like that, are there any names of ppl I might bribe?
23:41 cheako: I gtg, If someone was trying to reproduce this but wouldn't know what to do next... what was the point of having them reproduce it, is it that easy to think I would fake a video?
23:42 Venemo: I think I already explained that to you in the gitlab, but I'll repeat in case you didn't see it
23:43 Venemo: reproducing an issue is not about somebody faking a video. reproducing an issue is important because if I can't reproduce it locally then I can't examine what is happening exactly
23:44 Venemo: nobody is accusing you of faking the video, we are just trying to help you here
23:50 iive: are there tools like apitrace for vulkan that can record the drawing commands?
23:50 Venemo: yes, gfxreconstruct for example
23:54 iive: what's the exact problem cheako has? visual glitch? low fps? frame jumps/jitter?
23:57 Venemo: you can find the details here: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6012
23:58 iive: thanks
23:59 Venemo: any suggestion is welcome
23:59 Venemo: it may be indeed worth to take a gfxreconstruct trace and see if that reproduces the problem, so that's a good one