00:02 iive: yes, it would be good idea to see if replaying the exact same commands would give different fps during different runs.
00:05 iive: separately, I would suggest trying to turn off vertical sync (vsync/vblank) in the game.
00:12 iive: Looking at the video... when in window mode the fps is always low. going fullscreen sometimes fixes it, sometimes doesn't.
00:13 iive: mesa3d had some detailed graphs for opengl/d3d9, are such things available for radv ?
00:18 Venemo: depends on what you are looking for, but mangohud is pretty good
00:19 iive: thanks :)
00:21 iive: the bug thread looks quite long.
01:02 _ds_: Hmm. That bug report reminds me about identifying which Polaris GPU (given PCI ID 1002:67DF) – the revision no. matters. I recall these: 0xDF (RX 470), 0xD7 (RX 480), 0xEF (RX 570), 0xE7 (RX 580)…
01:03 _ds_: (lshw gives that in the “version:” line, lspci gives it as “(rev NN)”)
17:28 cheako: Venemo: Can you at least hint as to what you'd examine? You may not be able to examine this on your computer, but I have several computers that can do it.
17:34 Venemo: I don't have too much experience with this type of problem, so I don't have a straight answer
17:35 Venemo: maybe you could consider trying the things the other people suggested
18:02 Venemo: What I would look at are things like CPU and GPU utilization when the slowdown happens. Possibly I'd try to take a gpuvis capture and see what is happening during the slowdown. It would definitely be also interesting to see if the issue reproduces on a gfxreconstruct trace or only with the game itself.
18:04 Venemo: I would also look at the GPU clocks.
18:04 cheako: We've looked at gpuvis captures, I just heard about gfxreconstruct and it looks interesting but I don't see how it's better than using my layer combined with games.
18:06 Venemo: I don't remember seeing a gpuvis capture, sorry. What did you see on it?
18:06 cheako: Basically the steam web browser was the most taxing process and the advice was to disable HW drawing in the settings... changed nothing.
18:07 Venemo: Things like apitrace and gfxreconstruct are good because they decouple troubleshooting potential driver issues from the game
18:08 cheako: That makes sence, I've been looking into setting up gfxrc... I couldn't find instructions on setting up the layer.
18:09 Venemo: I'm not sure though whether gfxreconstruct is set up to handle this type of problem or not, but it's worth a try to see what happens
18:10 Venemo: Also cheako have you ruled out power management issues?
18:12 cheako: I did do some testing with different PM profiles, but now I'm just using gamemode and hope that it configures the card appropriately.
18:42 cheako: Is *that* supposed to be less than 1fps?
18:42 cheako: I'm on my phone
18:43 cheako: Seems like 1/5fps
18:53 Venemo: I never used gamemode so I'm not familiar with that
18:53 Venemo: if you already ruled out power management issues that's good
18:53 Venemo: usually what I recommend for that is to either use one of the profiling modes of the GPU or set a manual clock
18:58 cheako: I gave up(on gfxreconstruct) after 30min, when I realized I'd never be able to click on anything.
18:59 Venemo: gfxreconstruct just replays what the game did when you captured it
19:00 Venemo: so it rules out any randomness due to user input or anything that the game may do
19:22 cheako: I found the one file and had my layer read it, I get a constant "7: 1244Mhz *" even when FPS changes.
19:23 cheako: I did get 60FPS for a good while, so when I normally get 30FPS... that's not max speed.
19:24 cheako: When I run with gfxreconstruct's layer I get one frame every 5 seconds... what am I doing wrong?
20:26 Venemo: dunno
20:43 cheako: I can't give up, back to reloading until it works.
20:45 Venemo: it is possible gfrecon can't handle this game yet
20:46 KitsuWhooa: You're probably not doing anything wrong. It has to capture and write every command to disk, so it slows down a lot
20:46 KitsuWhooa: That's been my experience with apitrace, so I assume this is similar
20:47 Venemo: probably not helpful in diagnosing this issue though
20:47 KitsuWhooa: Maybe with enough patience one can see if a capture every time it's ran results in different performance
20:47 KitsuWhooa: s/ran/played back/
20:50 Venemo: well
20:50 Venemo: maybe?
21:30 cheako: https://paste.debian.net/1272244/
21:31 cheako: the trace is 1GB
21:33 cheako: Does mesa-vulkan-drivers from debian offer debug symbls?
22:05 pixelcluster: does that trace have the issue?
22:05 pixelcluster: (the issue = the thing you wrote the bug report for)
22:08 cheako: I define "the thing I wrote the bug for" as every system with every application for everyone all the time.
22:09 cheako: but yes, I did run a know effected application and made a trace.
22:09 cheako: I used Patron and it ran slow, but not unusable slow like NMS.
22:10 cheako: When I made the trace I was getting 30FPS, but I bet without this issue I'd do more than 60.
22:40 _ds_: cheako: affected, not effected
22:57 cheako: Thanks to Timur, today I lessened the possibility gpu clocks are the problem. That rules out power management also, right?
23:08 cheako: I forgot about API dump.
23:10 cheako: Is there a way to get APIdump to print the params first, so I don't get `vkWaitForFences(device, fenceCount, pFences, waitAll, timeout) returns VkResultSegmentation fault`?
23:13 cheako: seems like all the formats do something like that.
23:22 Venemo: cheako: "every system with every application for everyone all the time" -> literally nobody else experienced this problem but yourself
23:22 cheako: How do you know that?
23:23 Venemo: it's difficult to take you seriously if you make claims like that
23:24 Venemo: are you telling us that you own every system and you tested every application?
23:29 cheako: I'm saying all my data shows someone could run with this issue for years and not notice.
23:29 cheako: You have tested and not notice, correct?
23:31 cheako: Is it not more absurd to think somehow code runs differently for this one person?
23:39 cheako: I'd ask in a C++ chan, but then I'd have to explain what I'm doing. How would I print this array and is this how it's done? `std::cerr << "VkWaitForFences(" << device << "," << fenceCount << "," << ")" << std::endl;`
23:49 pixelcluster: cheako: I assume you want to print each fence passed to the function, you'll just have to print each one in a loop
23:49 pixelcluster: I doubt printing them will help with finding out more about the issue though
23:49 cheako: The driver segfaults... I think printing the args it's passed is the next step.
23:50 cheako: It's C++ and I've never written a loop in C++ b4.
23:54 cheako: I look at this blob and I think... there is no way C++ers would write it like that, OMG I'm so glad I never learned to do this. https://www.irccloud.com/pastebin/zKafjJTz/