AMD/ATI Pixel Clock Patcher

[razner312]

(01-13-2017 01:47 AM)ToastyX Wrote:  

(01-13-2017 01:08 AM)razner312 Wrote:  Hi there, recently upgraded to a 1440p Hannspree monitor (HQ271) and am having some annoying issues with trying to overclock the monitor past 73hz. As the monitor unfortunately doesn't have a display port output, I have it connected with a HDMI 1.4a, connected to my R9 Fury which doesn't support the monitors other output which is is Dual Link DVI. Anyways so far I have tried installing different versions of the AMD Crimson Drivers, patched the drivers using your tool over here, disabled the signing of drivers through windows and finally made different types of custom resolutions using CRU. I honestly don't know whats stopping my PC from recognizing anything more than 73hz, but I do know that HDMI 1.4a has a max pixel clock of 340mhz which does mean that I should be able to overclock the monitor to at least 84hz. Thanks in advance!

AMD cards have a 297 Hz limit with HDMI 1.x, but the patch should get around that. Maybe the patch misses something that affects the Fury, but before going any further, are you sure the monitor can display higher refresh rates without skipping frames? 2560x1440 monitors with multiple inputs usually have scalers that can't handle higher refresh rates correctly. This should be noticeable simply by moving the mouse cursor, or you can use this test with a camera: http://testufo.com/#test=frameskipping

It must be hitting the 297 hz limit then, because 73hz is at a pixel clock of 294mhz and 74hz is 298mhz. I used the frame skipping test already and it went perfectly fine and should do to much higher refresh rates (its a very good panel). So it looks like the patch is missing something, is there anyway manually of doing it then as I am still craving those extra Hz's. On a side note, there was someone on youtube using the same monitor as me and he managed to get his monitor to 100hz so it is reassuring that its capable of that. Thanks again

[mtrai]

Scratch this it is not the Pixel Patch but changes in how windows 10 build 15007 handles displays.

[ToastyX]

(02-17-2017 09:11 AM)ErionHashimoto Wrote:  I'm having problems with Radeon Software 17.2.1. Is there a compatibility issue? If so, is there a fix in the works?

The patch works with 17.2.1. What problems are you having?

If you're using CRU, keep in mind that 17.2.1 has a problem with EDID overrides as noted in the CRU thread:

(02-14-2017 02:15 AM)ToastyX Wrote:  This seems to be a driver bug in 17.2.1. The driver is not loading EDID overrides on startup.

I found one workaround: toggling GPU scaling will load the EDID override, but you'll have to do this every reboot.

Make sure to report this to AMD: http://www.amdsurveys.com/se.ashx?s=5A1E27D23A3DE979

[hannes69]

Regarding this:
1.4.3: Fix HBlank limit for 16.12.1.
1.4.2: Added patch for 56 horizontal blanking (HBlank) limit.

At the moment with current drivers (I think with the last one before the current too) I have a hblankmin of 57 (using TFT monitor on DVI and DLP projector on HDMI). When using values below 57, the according display device simply turns off (monitor goes to energy saving mode, projector doesn´t sync and shows black picture). E.g. the monitor itself shouldn´t be limiting because it accepts values down to 1 for front porch / sync width / back porch when using total blanking values >=57 (e.g. 55 / 1 / 1 is accepted!).
This is true for using EDID override via CRU and when using custom resolutions in CCC.
Using Radeon R7 250, driver 17.2.1, Windows 7 x64.

This behavior is given WITH and WITHOUT the Pixel Clock Patcher!

[ToastyX]

(02-28-2017 09:07 PM)hannes69 Wrote:  At the moment with current drivers (I think with the last one before the current too) I have a hblankmin of 57 (using TFT monitor on DVI and DLP projector on HDMI). When using values below 57, the according display device simply turns off (monitor goes to energy saving mode, projector doesn´t sync and shows black picture). E.g. the monitor itself shouldn´t be limiting because it accepts values down to 1 for front porch / sync width / back porch when using total blanking values >=57 (e.g. 55 / 1 / 1 is accepted!).

Are you sure the monitor can handle lower horizontal blanking values? A monitor can accept lower porch/sync values and still limit the total blanking.

Try it with 16.11.5: http://support.amd.com/en-us/download/de...ev=16.11.5

The ReLive drivers might have an issue that prevents lower horizontal blanking values from working correctly even with the limit removed. I'm seeing an issue with RX 480 cards that causes the screen to turn to colored snow with lower horizontal blanking values, but that's unrelated to the 56 limit.

[hannes69]

Quote:Are you sure the monitor can handle lower horizontal blanking values? A monitor can accept lower porch/sync values and still limit the total blanking.

Try it with 16.11.5: http://support.amd.com/en-us/download/de...ev=16.11.5

The ReLive drivers might have an issue that prevents lower horizontal blanking values from working correctly even with the limit removed. I'm seeing an issue with RX 480 cards that causes the screen to turn to colored snow with lower horizontal blanking values, but that's unrelated to the 56 limit.

I tried driver 16.11.5 and tried patched and not patched. The behaviour is the same like described above. What can we conclude from that?
Is it really coincidence that both of my devices (TFT monitor and DLP projector) can exactly go down to hblankmin 57 and not any further? If so, then AMD seems to have made a useful restriction, if normal devices (I consider I have "normal" devices) can´t go below 57 hblank.
I myself can´t test if it is the driver or the device, because how will I know that the resolution is "fired" through the DVI/HDMI port (so no restriction of the driver) or not?
There is a small hint from my monitor (at least for me) that it is possibly not a violation of the monitor accepted range: My monitor gives an OSD feedback about range violations, it does so for
- horizontal frequency too high (all above 84kHz)
- vertical frequency too low (all below 48 Hz)
- vertical frequency too high (all above 76 Hz)
- vertical blanking too high (all above 65)

Especially giving an error message for too high vertical blanking leads to assuming that the monitor should give a feedback about too low horizontal blanking as well I think. Instead it simply goes to standby.
I´m really not sure about that.
What would be a method to be sure that a resolution is really "fired"? I have a multimeter (but not an oscilloscope at home) for measurements. When e.g. a cable is not connected to the DVI port (so it is not terminated) are the signals still lying on the pins?

[ToastyX]

(03-05-2017 07:49 PM)hannes69 Wrote:  I tried driver 16.11.5 and tried patched and not patched. The behaviour is the same like described above. What can we conclude from that?
Is it really coincidence that both of my devices (TFT monitor and DLP projector) can exactly go down to hblankmin 57 and not any further? If so, then AMD seems to have made a useful restriction, if normal devices (I consider I have "normal" devices) can´t go below 57 hblank.

The driver limit is 56, not 57, so you're running into a different limitation. It could be a coincidence, or maybe your video card can't go below 57 for some reason. I have no trouble going under 56 with 16.11.5. For 56, try something like 16/24/16 instead of 1/1/54.

(03-05-2017 07:49 PM)hannes69 Wrote:  I myself can´t test if it is the driver or the device, because how will I know that the resolution is "fired" through the DVI/HDMI port (so no restriction of the driver) or not?

The only way I know for sure is to use a monitor that I know can handle lower values. The driver won't send a signal if it doesn't detect a monitor.

[hannes69]

Quote:The driver limit is 56, not 57, so you're running into a different limitation. It could be a coincidence, or maybe your video card can't go below 57 for some reason. I have no trouble going under 56 with 16.11.5. For 56, try something like 16/24/16 instead of 1/1/54.

I tried values like 16/24/16, nothing below 57 is working.
Because both of my devices are affected and because my monitor doesn´t show an OSD message, I believe it is some kind of limitation of my GPU, but of course I have no evidence for that, only suspect it.

Quote:The only way I know for sure is to use a monitor that I know can handle lower values. The driver won't send a signal if it doesn't detect a monitor.

Yeah, but I have no other devices left in my storage hehe... And it is too much effort too build a breakout DVI cable to find out about the signals

[edstewbob]

I just installed 17.3.1. Should I be able to run this and disable the BIOS signature checking for this release?

[ToastyX]

(03-15-2017 07:02 PM)edstewbob Wrote:  I just installed 17.3.1. Should I be able to run this and disable the BIOS signature checking for this release?

Yes.