Custom Resolution Utility (CRU)
|
12-05-2022, 10:46 AM
Post: #7090
|
|||
|
|||
RE: Custom Resolution Utility (CRU)
(12-01-2022 07:42 PM)ToastyX Wrote:(12-01-2022 08:15 AM)TnF Wrote: But i know this is BS because there seems to be a limit where if the total pixel clock exceeds a specific value, vram clocks will switch to high because there is no other intermediary powerplay clock state to support that total bandwidth..It's 2022 and multimonitor high resolution/bandwidth users still get f*cked over with this. Nvidia does it too. They will never learn it looks like it.The memory clock issue has nothing to do with bandwidth. Changing the memory clock while the screen is refreshing will corrupt the image while the memory is being retrained, so the memory clock needs to change during the vertical blanking period to avoid this. If the vertical blanking period is not long enough, there won't be enough time to finish retraining the memory before the next refresh starts. That's why the memory clock won't change if the vertical blanking is too low. That's for a single monitor. For memory clock changes to work with multiple monitors, both monitors must be perfectly synchronized so the vertical blanking period happens at the same time, otherwise there's no way to avoid corrupting the image on one of the monitors. You have to make sure that the timing parameters for the detailed resolutions for both monitors match exactly. If they do match and it still won't clock down, then that's a driver bug or hardware-specific limitation. There should be no issues with clocking down with two identical monitors at 2560x1440 @ 144 Hz if the vertical blanking is long enough. What happens if you try 8 bpc color instead of 10 bpc? Thanks a lot for the reply. I actually found the issue. I made this device a year ago to trick the GPU to still output video signal when you turn off the monitor, so it doesn't re-arrange your windows and stuff. You can only do this on Quadro/Radeon Pro cards by doing edid emulation, but it's not available on consumer cards. Some monitor offer this option in their menu but i've only seen it on workplace kind of monitors. There is no such product in the market for DP, there is only for HDMI where the implementation is much easier. So what happens (depending on the monitor) they might follow DP specs on the implementation or do whatever they want. It looks like not even GPU's follow it, or something was changed since i do not have access to the latest standard, only to v1.2. Normally when the monitor turns off (downstream device) it should notify the gpu (upstream device) so it cuts off transmission, and when the monitor it's powered on again it should notify the gpu to re-train the DP link and start transmitting again. The 27GL850's i have of the latest revision follow this spec, but for example the first revision 27GL850 i had didn't (you would power it off and it would still show as powered on to the gpu, and only when you powered it on again it would do retraining..) This is handled on the HPD line, and there is specific range of timing duration for the pulses done to communicate. For example the timing is too short the gpu will not detect that a monitor was powered on and it will not output video signal. In this case here what happens is that it looks like when you already have established a link with the monitor and you change resolution, or wake the monitor from sleep a different kind of quick re-training happens, and if the pulse is too long, the AMD gpu drivers will think that the monitor failed to accept the resolution and it will drop down to lower data rate. And since the 10bit signal didn't fit in HBR2 it drops bitrate to 6 bit (or just goes there straight as "safe mode"; impossible to tell only AMD knows). Anyways by adjusting the pulse duration i was able to find a happy medium that works in all cases..this is a temp solution however as other monitors/gpus might behave differently. So i need to re-write my code to detect this kind of "quick link re-training" and adjust accordingly. For now i tested it the whole weekend and it worked 100% perfectly. I also made a version of this device that should theoretically be able to emulate edid in hardware but i haven't wrote any code to test it. I want to finish other projects first. Regarding the vram clocks: I've checked the vertical blanking and it's more than enough, tried exact values, increased further etc, i only get idle vram clocks when i run: - 1x monitor 1440p@10bit@144hz - 2x monitors 1440p@10bit@60hz Anything more i get full vram clk. |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 54 Guest(s)