02:38cheako: pressure-vessel-wrap[560604]: W: "opt/amdgpu/share/libdrm" is unlikely to appear in "/run/host"
02:38cheako: I've been having this problem running amd-pro drivers with steam games.
17:30cheako: 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:27cheako: 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:29cheako: 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:30cheako: From month-to month. So often when starting NMS I'll get 7 FPS, but other weeks it'll be 60 or 30.
19:32cheako: It does seem to always be `1/2^x`, multiples of a half? Though that could be explained by observation bias.
19:33cheako: 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:34cheako: Though with the latest patch suboptimal seems to brick NMS, could be some rust interaction.
21:11Venemo: cheako: you can just answer yes or no on the gitlab issue
21:16cheako: 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:26cheako: I'll be away till tomorrow, CST.
22:58Venemo: 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:59Venemo: can we close the issue?
22:59cheako: 777Both drivers have problems with consistently providing the same FPS, it just takes weeks of testing to find that out.
23:00cheako: Also amdvlk has other problems, crashes and artifacts that the radv driver doesn't.
23:02cheako: 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:02cheako: I keep asking what you would test for that second week?
23:03Venemo: you just said the opposite
23:03Venemo: sorry cheako but now it really feels to me like you are intentionally trolling me
23:06Venemo: so, do you experience this problem on AMDVLK or not?
23:06Venemo: if not, then please enjoy using AMDVLK
23:06Venemo: if yes, that means both drivers have the same problem on your computer
23:14cheako: yes
23:18Venemo: okay, this would hint that either both drivers have the same bug or it's not a driver related issue
23:23cheako: 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:23Venemo: great
23:24Venemo: if you have any suggestions, I'm listening
23:26cheako: 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:29Venemo: the pipeline does not change when you hit alt tab or the windows key on your keyboard
23:30Venemo: the swap chain could indicate problems elsewhere, eg. window system integration or the compositor or who knows where
23:30cheako: *IT DOES*, my logs clearly show the pipelines being destroyed and recreated. and obviously when the application is restarted it needs new pipelines.
23:31Venemo: given the same input, the driver will compile the same pipeline for you
23:32Venemo: if the pipeline was already compiled before, then it is loaded from a cache
23:32cheako: I don't know what to say, the video clearly shows otherwise.
23:32Venemo: assuming that the same pipeline is being recreated, it is going to be a cache hit
23:33Venemo: the thing on your video could be caused by literally anything
23:34cheako: Let's start with a list of anything then.
23:34Venemo: okay
23:34Venemo: I'm listening
23:35cheako: We need someone who knows these systems well enough to generate a list of anything, now.
23:36Venemo: okay, let me know when you find someone
23:39cheako: Where should I look for someone like that, are there any names of ppl I might bribe?
23:41cheako: 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:42Venemo: I think I already explained that to you in the gitlab, but I'll repeat in case you didn't see it
23:43Venemo: 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:44Venemo: nobody is accusing you of faking the video, we are just trying to help you here
23:50iive: are there tools like apitrace for vulkan that can record the drawing commands?
23:50Venemo: yes, gfxreconstruct for example
23:54iive: what's the exact problem cheako has? visual glitch? low fps? frame jumps/jitter?
23:57Venemo: you can find the details here: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6012
23:58iive: thanks
23:59Venemo: any suggestion is welcome
23:59Venemo: it may be indeed worth to take a gfxreconstruct trace and see if that reproduces the problem, so that's a good one