00:01 HdkR: Dang, kernel 6.0 also still hasn't solved one of my panel's not getting to 4k 144hz
00:10 HdkR: https://gitlab.freedesktop.org/drm/amd/-/issues/1564#note_1045678 Horrifying when two panels get 144hz and the other is stuck at 120hz
08:26 gekret005: I think I'm discovering some very strange behavior with reprojection in steamvr
08:27 gekret005: Is there a good method to just generate enough load to trigger a 50% reprojection
08:28 gekret005: I want a consistent way to produce it that isn't application specific
08:29 gekret005: what I'm noticing is that if it ever can't afford to drive 150% resolution at 120hz it'll drop to 60 then stay there
08:29 gekret005: the same does not occur at 20%
08:30 gekret005: actually I can just generate some cpu noise I'll test more later
08:31 gekret005: haven't verified if it occurs in windows yet
08:33 gekret005: is there a good way to measure actual framerates in addition to frame timing?
10:57 haagch: you could reduce the power limit to make the gpu throttle
10:58 haagch: with vr, it's generally the vr runtimes that drive the frame rate of applications, if they can't make the native refresh rate of the display, it typically gets throttled to half of that because everything else looks really bad in vr
11:01 haagch: also for rdna and later the default power profile often doesn't behave very well for steamvr https://github.com/ValveSoftware/SteamVR-for-Linux/issues/469
14:36 Venemo: agd5f: are you aware of this issue? https://gitlab.freedesktop.org/mesa/mesa/-/issues/7939#note_1714051
14:38 Venemo: apparently a certain ppfeaturemask solves gpu hangs on RDNA3
14:41 agd5f: Venemo, thanks. I'll take a look
14:42 Venemo: thank you
16:35 Venemo: agd5f: what would be the best way for mesa to query the PCIe link width of a GPU?
17:18 agd5f: Venemo, generic PCI sysfs interface?
17:19 Venemo: isn't there an API?
17:19 Venemo: do you mean to just read the sysfs files?
17:19 agd5f: yeah
17:19 Venemo: how do I find out the path to the sysfs interface of the GPU?
17:22 agd5f: based on the BDF of the device. E.g., /sys/class/pci_bus/<domain:bus:device.func>/
17:22 agd5f: that said, the PMFW changes the link speed and width dynamically at runtime
17:22 Venemo: I'm interested in the max link width
17:23 Venemo: I mean the max that is possible on the current link, not the max the GPU is cabable of
17:24 agd5f: e.g., /sys/bus/pci/devices/0000\:44\:00.0/max_link_speed and /sys/bus/pci/devices/0000\:44\:00.0/max_link_width
17:25 Venemo: does that not change in runtime?
17:25 agd5f: the max possible doesn't change
17:26 Venemo: great thx :)
17:26 agd5f: although you could be limited by something further up the topology
17:27 Venemo: yes, those limits are what I want to find out
17:27 agd5f: e.g., if you are behind a PCIE bridge whose upstream link is only x4 while the downstream link is x16
17:27 Venemo: will max_link_width be x4 in that case?
17:28 agd5f: I think those files are based on the individual device they are querying. I don't think the kernel limits it based on the slowest component in the topology, but I'd need to double check the code
17:29 Venemo: I'd like to find the narrowest component in the topology
17:29 agd5f: you could walk the PCI tree
17:30 agd5f: e.g., lspci -t
17:31 Venemo: isn't there an API for it? I don't think it's a good idea to have radv run lspci
17:32 agd5f: maybe libpci supports something like that