13:35haasn: How long until GPUs gain instructions to compute PQ EOTF / OETF
14:03HdkR: How weird to think they ever will :P
16:54cheako: Venemo: That worked, I got 55,14 and 1. I'll upload my data to the issue.
17:36cheako: pixelcluster: I ran that tests because I knew it would eventually fail, but because I knew the result it was seemingly a waste of resources for me. I don't know why I can't be given a list of everything so that I can collect data on each of everything and make progress on identifying the cause of this.
17:37pixelcluster: cheako: that list exists, it's you can view it by executing apt list --installed
17:37pixelcluster: as a more serious answer, I don't know what in theory can affect it
17:39cheako: ....you know I can make a book usb stick that contains the bare minimum libraries, write that script as a rust application that runs as init and get the same results.
17:40cheako: It would be a waste of my time to do so, but if the assumption is some apt package is the cause I can remove that possibility.
17:42pixelcluster: no I wasn't serious
17:43cheako: :)
17:46pixelcluster: what I wanted to point out is that I can't just give you a list of things to try out or something like that
17:47cheako: Regardless, I'm willing to try everything. Did I even remove memory types with my previous experiment where I traced the kernel's bo_move or whatever?
17:49cheako: Basically playing games isn't any fun because of this and I'm considering getting an intel card.
17:50pixelcluster: that is nice but the problem is that it wouldn't really work to do "remote debugging" like that, if I were debugging locally I would try something, but I don't know how I would break my debugging strategy down in a way that I could talk about it in a chat and somebody else understands
17:50pixelcluster: also, didn't you say it's barely even reproducible and could take weeks or months to show up?
17:51cheako: Yes, week/months of 7FPS... not a playable experience.
17:52pixelcluster: so as soon as it happens once, it stays at the unplayable framerates forever? even after a reboot?
17:52cheako: Even with these tests I got ~50FPS, but should that not have been 160FPS if not for this bug?
17:53cheako: In the tests it did 1FPS for, if I'm not mistaken, a few dozen times.
17:53cheako: I'm not sure if rebooting has any effect, just restarting the application is what I've been doing.
17:54cheako: I've tried rebooting and it seems to do nothing.
17:55cheako: My experience is I get 7FPS, then my code injects a suboptimal and I get 18FPS and another suboptimal and sometimes I get something above 20FPS... then I play for a half hour until I get another random FPS.
17:57cheako: All the time I should be getting 60 or 90FPS, not sure because I can't reliably get FPS numbers.
18:05cheako: pixelcluster: I'm happy to read source and devise my own debugging strategies. I had planned to take a list of everything and focus on something like the first 3.
18:06pixelcluster: I guess the first thing to rule out would be anything presentation-related
18:07pixelcluster: actually why not make a vulkan app that does the following on repeat: write timestamp -> submit compute work -> write timestamp, so you can use (second timestamp - first timestamp) to see how long that compute work took
18:07pixelcluster: what compute work this is doesn't really matter
18:08pixelcluster: also while testing that app you should maybe force clocks to a stable rate, so that different clocks don't influence your performance stats
18:28cheako: That's a good idea, I can look into aspects of image_view objects as just what I saw first. I'm looking for `radv_image_view_to_handle` and suspect it's a macro?
19:12cheako: Venemo: Do ppl really need to waste bandwidth on that, you know what I did was write a script and let it run for more than a day... that's the part I think you are missing, there is nothing special about these captures.