Contribute
Register

Enabling 5K display with ATI Radeon RX480/580

Status
Not open for further replies.
Joined
Aug 1, 2012
Messages
692
Motherboard
Asus ProArt Z690 Creator
CPU
i7-13700K
Graphics
RX 6800 XT
Mac
  1. MacBook Pro
Mobile Phone
  1. iOS
Enabling 5K display with ATI Radeon RX480/580


As matter of fact I’ve always been driven by a desire to have a 5K monitor working in a multi display configuration. Since last year I’ve jumped on the red ATI bandwagon and, in doing so, all my efforts have been moved towards ATI GPUs.


My HW test configuration is the following:

• SKU GA Z170-HD3 DDR3
• GPU PowerColor Radeon RX480 8GB Red Devil
• GPU (alternate) PowerColor Radeon RX580 8GB Red Devil Golden Sample (it's coming...)
• CPU Intel Kaby Lake I7-7700K
• HP Z27Q 5K

Following the guides here and here and using tools provided in the 1st posts of each guide I made all my homework and got the complete dump of the necessary infos regarding my RX480:
show_img.png

where from left to right we have:

  1. 01 [DISPLAY_PORT] (top)
  2. 02 [DISPLAY_PORT] (middle)
  3. 03 [DISPLAY_PORT] (bottom)
  4. 04 [HDMI_TYPE_A]
  5. on the second row 05 [DVI_TYPE_D]
connectors configurations are as follow in this spoiler:

01 [DISPLAY_PORT] (top)

redsock_bios_decoder :

enc obj id [0x21] txmit [0x12] duallink [0x2] enc [0x4]

radeon_bios_decode :

Connector at index 0

Type [@offset 40862]: DisplayPort (10)
Encoder [@offset 40866]: INTERNAL_UNIPHY2 (0x21)
i2cid [@offset 40972]: 0x90, OSX senseid: 0x1
HotPlugID: 06

Code Costruction: 12 04 06 01

=========================================================


02 [DISPLAY_PORT] (middle)

redsock_bios_decoder :
encoder obj id [0x21] txmit [0x22] duallink [0x2] enc [0x5]

radeon_bios_decode :
Connector at index 1

Type [@offset 40872]: DisplayPort (10)
Encoder [@offset 40876]: INTERNAL_UNIPHY2 (0x21)
i2cid [@offset 40999]: 0x92, OSX senseid: 0x3
HotPlugID: 04

Code Costruction: 22 05 04 03


=========================================================


03 [DISPLAY_PORT] (bottom)

redsock_bios_decoder :
encoder obj id [0x20] txmit [0x11] duallink [0x1] enc [0x2]

radeon_bios_decode :
Connector at index 2
Type [@offset 40882]: DisplayPort (10)
Encoder [@offset 40886]: INTERNAL_UNIPHY1 (0x20)
i2cid [@offset 41026]: 0x91, OSX senseid: 0x2
HotPlugID: 01

Code Costruction: 11 02 01 02

=========================================================


04 [HDMI_TYPE_A]

redsock_bios_decoder :
encoder obj id [0x20] txmit [0x21] duallink [0x1] enc [0x3]

radeon_bios_decode :
Connector at index 3
Type [@offset 40892]: HDMI-A (11)
Encoder [@offset 40896]: INTERNAL_UNIPHY1 (0x20)
i2cid [@offset 41053]: 0x93, OSX senseid: 0x4
HotPlugID: 05

Code Costruction: 21 03 05 04

===========================================================


05 [DVI_TYPE_D]


redsock_bios_decoder :
encoder obj id [0x1e] txmit [0x10] duallink [0x0] enc [0x0]

radeon_bios_decode :
Connector at index 4
Type [@offset 40902]: DVI-D (3)
Encoder [@offset 40906]: INTERNAL_UNIPHY (0x1e)
i2cid [@offset 41080]: 0x95, OSX senseid: 0x6
HotPlugID: 03

Code Costruction: 10 00 03 06


=========================== END ============================

All the necessary dumps and scripts results are in a zip file where everyone can find the hardware details of my PowerColor. it's called Archive.zip.

The second piece of information needed is the correct FB to choose.

Code:
AMD9500Controller — Acre, Dayman, Guariba, Huallaga
0x67E01002 0x67EF1002 0x67FF1002 0x67C01002 0x67DF1002

AMD9510Controller — Berbice
0x67EF1002

AMD9515Controller — Longavi, Mazaruni
0x67EF1002

AMD9520Controller — Caroni, Elqui, Florin
0x67E01002 0x67EF1002 0x67FF1002 0x67C01002 0x67DF1002

AMDRadeonX4100_AMDBaffinGraphicsAccelerator
0x67E01002 0x67FF1002 0x67EF1002

AMDRadeonX4150_AMDBaffinGraphicsAccelerator
0x67E01002 0x67FF1002 0x67EF1002

AMDRadeonX4200_AMDBaffinGraphicsAccelerator
0x67EF1002 0x67FF1002

AMDRadeonX4200_AMDEllesmereGraphicsAccelerator
0x67DF1002 0x67C01002

As you can see the Device ID of my card 0x67DF1002 is present in more than one kext and there are many FBs available for each Kext. After a long long examination I choose to go with Dayman but I've tried extensively also OPM which leads basically to the same results but needs much more modifications.

So i Put in Clover Dayman, Inject ATI, and videoport=5. As you can see here:

Screenshot 2017-06-20 15.37.08.png
and rebooted. Et voilà: 5K is enabled!

The correct resolution is stated in HP OSD panel. And OSX says the same: 5120*2880 HP Z27Q in About this Mac. But there are some caveats which I was not able to solve completely.

Screen Shot 2017-06-21 at 21.52.56.png


  1. NOT ALL THE DP ports are working at the same time. Only two of them can work simultaneously. I really don't know why and I ask for help to solve this limit. The middle DP (2) seems to be inactive or kind of passive... But more of this later.
  2. It's fundamental that the 1st DP port of the monitor starts as really as first that's to say 1st from an hardware point of view.

Infact HP Z27Q has the following display modes:

Screenshot 2017-06-20 15.58.12.png
And the main is DP is the HP_DP1 as you can see here at the point number 3. in the next figure:

Screenshot 2017-06-20 16.12.48.png
so HP_DP1 must start before(*) HP_DP2 for having the monitor correctly display 5K res. So you can have plenty of configurations here, all working. I.e. :

GPU_DP1 <-> HP_DP1
GPU_DP2 <-> HP_DP2

or i.e.:

GPU_DP1 <-> HP_DP1
GPU_DP3 <-> HP_DP2

all of them are working.
But unfortunately the left GPU DP is not working, no matter if you connect a 1K, or 2K or 4K display. It won't work: black screen and then the monitor will go to sleep and, above all, the monitor is not present in system report. Furthermore HDMI and/or DVI were not tested at that moment.

All this without any modding of the Dayman FB. All Vanilla. SO I tried to work on the FB personality to improve the situation. Let's look at the Dayman a bit closer:

Code:
Dayman (6) @ 0x102370
DP, DP, DP, HDMI, DVI-D, DP
000400000403000000010101000000001204060100000000
000400000403000000010201000000002205040300000000
000400000403000000010301000000001102010200000000
000800000402000000010400000000002103050400000000
040000000402000000010500000000000000030600000000
000400000001000000010601000000002001020500000000

and as you can see, last DP aside, Dayman is exactly the same hw configuration of my GPU. More than that, Dayman has almost the right connectors code in place. Before modding we have:

1a row: 00040000 04030000 00010101 00000000 12 04 06 01 00000000
2a row: 00040000 04030000 00010201 00000000 22 05 04 03 00000000
3a row: 00040000 04030000 00010301 00000000 11 02 01 02 00000000
4a row: 00080000 04020000 00010400 00000000 21 03 05 04 00000000
5a row: 04000000 04020000 00010500 00000000 00 00 03 06 00000000
6a row: 00040000 00010000 00010601 00000000 20 01 02 05 00000000

and I don't consider the 6th row because my GPU has only 5 ports. After modding we have:

1a row: 00040000 04030000 00010101 00000000 12 04 06 01 00000000
2a row: 00040000 04030000 00010201 00000000 22 05 04 03 00000000
3a row: 00040000 04030000 00010301 00000000 11 02 01 02 00000000
4a row: 00080000 04020000 00010400 00000000 21 03 05 04 00000000
5a row: 04000000 04020000 00010500 00000000 10 00 03 06 00000000

the underlined byte is the only one modified. And the explanation is pretty clear as already stated in many FB modding guides: if, for example, we just consider the 1st row, then we'll have:

Code:
00 04 00 00 / Display Port

04 03 00 00 /ATY, ControlFlags

00 01 01 01 / Features

00 00 00 00 /Sierra control code

12             / Trasmitter

04            / Encoder

06            /hotplug ID

01             / Sense ID

00 00 00 00 /Sierra control code

and this matches perfectly what we have got from the hw dump of my GPU. Now I put my attention on the corsive 8 bytes coloured in medium grey. We have:

1a row: 00010101
2a row: 00010201
3a row: 00010301

This is the part that relates to the ATY,Features (hex digits),

Code:
and the first pair of numbers are:

0 × 0002: LVDS * 0x09 = 09
0 × 0004: DVI 0x00 = 00
0 × 0010: VGA 0x00 = 00
0 × 0080: S-Video 0x04 = 04
0 × 0200: DVI 0x00 = 00
0 × 0400: Display Port 0 × 00 = 00
0 × 0800: HDMI 0 × 00 = 00
0 × 1000: DVI 0x00 = 00

The second pair of numbers:
Use Internal * 0 × 01 = 01
Use RGB YUV On 0 × 04 = 04
Use Backlight * 0 × 08 = 08
Backlight Inverted 0 × 10 = 10
Use Clamshell 0 × 20 = 20

A third pair of numbers represents the order of connector activation
01 = first active connector
02 = second active connector
03 = third active connector
etc. ...

I suggest that you mark as first, connector row that your monitor will use it as primary. Anyway in this case we have:


1a row: 00 01 01 01 <=> DP port; Internal Use; 1st active connector; Unknown;

now I modified the 3rd pair of bytes to mirror the Sense ID order of the other octet as follow:

1a row: 00040000 04030000 0001 01 01 00000000 12 04 06 01 00000000

2a row: 00040000 04030000 0001 03 01 00000000 22 05 04 03 00000000
3a row: 00040000 04030000 0001 02 01 00000000 11 02 01 02 00000000

now look at the underlined bytes to see the modification and just notice the relation with OSX SenseID: I have to admit this is a total try... and I have the suspect this modification is more related to Hotplug ID order than Sense ID order. But I'm open to experimenting here! Anyway what I got was:

all the 4 monitor (I consider 5K an MST double monitor as required two DPs) working at the same time! 3 DP ports and 1 HDMI! :)

Screen Shot 2017-06-17 at 00.57.33.png

and here there is a video :

but as you can see from the video (sorry it's in my italian! The video was not initially meant for the forum!), the 5K starts in scaled mode and the HP OSD panel states 2560*1440 px while the RetinaDisplayMenu app states correctly 2560*1440px (HiDPI) mode, that means full 5K res. I also tried cmd+alt+3 to make a screen capture and the png is 5120*2880px , so I'm pretty sure that the monitor is working correctly.

Thanks to @Fl0r!an for his guide. Thanks to @LostVector for his tips.
BTW @LostVector , at least for now, I haven't used any modification of the "CFG_USE_AGDC" var neither in AMD*controllers.kext nor in AGDP.kext.

I'm asking for help, suggestions or any ideas to remove that last strange scaled mode in which 5K is presented even if it's working in 5K correctly. I'm really close to have everything working as it has to be.

That's my actual environment:

  • MacOS 10.12.6 Public Beta 3 Beta 5
  • SYsDef 17,1 (but tried also with 18,3 and it's working)
  • CSM disabled in BIOS
  • iGPU (HD630) as helper graphics enabled (and needed!)
  • Clover v. 4091 4097
 

Attachments

  • Screenshot 2017-06-20 15.37.08.png
    Screenshot 2017-06-20 15.37.08.png
    436.7 KB · Views: 1,480
  • Archive.zip
    51.8 KB · Views: 240
Last edited:
DAYMAN MODDING

as we saw in the previous post Dayman FB is the one we want.Now we look deeper into the specific variations of this modding. The unchanged FB is:

Code:
Dayman (6) @ 0x102370
DP, DP, DP, HDMI, DVI-D, DP
000400000403000000010101000000001204060100000000
000400000403000000010201000000002205040300000000
000400000403000000010301000000001102010200000000
000800000402000000010400000000002103050400000000
040000000402000000010500000000000000030600000000
000400000001000000010601000000002001020500000000

that we can rewrite here in the correct form for putting it into Clover ATI Connector Patch:

000400000403000000010101000000001204060100000000000400000403000000010201000000002205040300000000000400000403000000010301000000001102010200000000000800000402000000010400000000002103050400000000040000000402000000010500000000000000030600000000000400000001000000010601000000002001020500000000


and now we have the 1st possibility of modding:

000400000403000000010101000000001204060100000000000400000403000000010201000000002205040300000000000400000403000000010301000000001102010200000000000800000402000000010400000000002103050400000000040000000402000000010500000000001000030600000000000000000000000000000000000000000000000000000000


and this leads to the situation shown here where you have to put attention to displays' connectors:

  1. TOP DP: white connector -> 4K SST Monitor
  2. MIDDLE DP: black connector with label -> secondary port 5K MST Monitor
  3. BOTTOM DP: black connector without label -> primary port 5K MST Monitor
  4. HDMI: black/red connector -> BENQ PV270 2K.
as already stated in post #7 even if the OS declares 2560*1440px it's really working in 2560*1440 Hi-Dpi mode, as you can see here:

Screen Shot 2017-07-06 at 09.41.09.png
and here:

Screen Shot 2017-07-06 at 09.40.46.png

note that if you invert the 5K DPs connectors, it won't start!

Now the 2nd possibility of modding is the following:

000400000403000000010101000000001204060100000000000400000403000000010301000000002205040300000000000400000403000000010201000000001102010200000000000800000402000000010400000000002103050400000000040000000402000000010500000000001000030600000000000000000000000000000000000000000000000000000000

and as you can see now the order of DP ports is changed and this leads to the inversion of 5K DP ports and this leads to the situation in Youtube video linked in post #1 and connectors are as follows:
  1. TOP DP: white connector -> 4K SST Monitor
  2. MIDDLE DP: black connector with label -> primary port 5K MST Monitor
  3. BOTTOM DP: black connector without label -> secondary port 5K MST Monitor
  4. HDMI: black/blue connector -> 1K TV display

so you have all the ports enabled. And this is the exact same configuration proposed in post #1.

As already speculated in post #7 I still believe in Polaris Ellesmere 10/20 not all the 5/6 video ports (as enumerated in FBs) are independent. On the XFX site for example is reported that RX580 cards can support up to 3 monitors simultaneously and if you want more than 3 monitors you need to use an MST hub. So for me RX480/580 cards are really 3(+2) monitors and there is some kind dependencies among the video ports.
In MacOS environment the MST capabilities are governed by var CFG_USE_AGDC . And if i'is set to false, you won't have any MST capabilities. Subsequently var CFG_USE_AGDC is strictly related to the load of AGDP.kext. Now if you look into info.plist of AMD9500Controller.kext - which is the one loaded for Ellesmere cards - you can see:

Code:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>BuildMachineOSBuild</key>
    <string>16G16a</string>
    <key>CFBundleDevelopmentRegion</key>
    <string>English</string>
    <key>CFBundleExecutable</key>
    <string>AMD9500Controller</string>
    <key>CFBundleGetInfoString</key>
    <string>AMD9500Controller 1.51.8 18578</string>
    <key>CFBundleIdentifier</key>
    <string>com.apple.kext.AMD9500Controller</string>
    <key>CFBundleInfoDictionaryVersion</key>
    <string>6.0</string>
    <key>CFBundleName</key>
    <string>Radeon HD 9500 Controller</string>
    <key>CFBundlePackageType</key>
    <string>KEXT</string>
    <key>CFBundleShortVersionString</key>
    <string>1.51.8</string>
    <key>CFBundleSignature</key>
    <string>????</string>
    <key>CFBundleSupportedPlatforms</key>
    <array>
        <string>MacOSX</string>
    </array>
    <key>CFBundleVersion</key>
    <string>1.5.1</string>
    <key>DTCompiler</key>
    <string>com.apple.compilers.llvm.clang.1_0</string>
    <key>DTPlatformBuild</key>
    <string>8V109d</string>
    <key>DTPlatformVersion</key>
    <string>GM</string>
    <key>DTSDKBuild</key>
    <string>16G16a</string>
    <key>DTSDKName</key>
    <string>macosx10.12internal</string>
    <key>DTXcode</key>
    <string>0830</string>
    <key>DTXcodeBuild</key>
    <string>8V109d</string>
    <key>IOKitPersonalities</key>
    <dict>
        <key>Controller</key>
        <dict>
            <key>ATY,Acre</key>
            <dict>
                <key>aty_config</key>
                <dict>
                    <key>CFG_NVV</key>
                    <integer>2</integer>
                    <key>CFG_PTPL2_TBL</key>
                    <data>
                    MgAAABwAAAAaAAAAGQAAABcAAAAVAAAAFAAA
                    ABIAAAARAAAADwAAAA0AAAAMAAAACgAAAAkA
                    AAAHAAAABgAAAA==
                    </data>
                    <key>CFG_USE_AGDC</key>
                    <true/>
                    <key>CFG_USE_CP2</key>
                    <true/>
                </dict>
                <key>aty_properties</key>
                <dict>
                    <key>PP_DisableClockStretcher</key>
                    <integer>1</integer>
                </dict>
            </dict>
            <key>ATY,Dayman</key>
            <dict>
                <key>aty_config</key>
                <dict>
                    <key>CFG_NVV</key>
                    <integer>2</integer>
                    <key>CFG_USE_AGDC</key>
                    <true/>
                    <key>CFG_USE_CP2</key>
                    <false/>
                </dict>
            </dict>
            <key>ATY,Guariba</key>
            <dict>
                <key>aty_config</key>
                <dict>
                    <key>CFG_NVV</key>
                    <integer>2</integer>
                    <key>CFG_USE_AGDC</key>
                    <true/>
                </dict>
            </dict>
            <key>ATY,Huallaga</key>
            <dict>
                <key>aty_config</key>
                <dict>
                    <key>CFG_NVV</key>
                    <integer>2</integer>
                    <key>CFG_USE_AGDC</key>
                    <true/>
                </dict>
            </dict>
            <key>CFBundleIdentifier</key>
            <string>com.apple.kext.AMD9500Controller</string>
            <key>IOClass</key>
            <string>AMD9500Controller</string>
            <key>IOMatchCategory</key>
            <string>IOFramebuffer</string>
            <key>IOName</key>
            <string>AMD9500Controller</string>
            <key>IOPCIMatch</key>
            <string>0x67E01002 0x67EF1002 0x67FF1002 0x67C01002 0x67DF1002</string>
            <key>IOProbeScore</key>
            <integer>65050</integer>
            <key>IOProviderClass</key>
            <string>IOPCIDevice</string>
            <key>aty_config</key>
            <dict>
                <key>CFG_APER_MODE</key>
                <integer>1</integer>
                <key>CFG_CAA</key>
                <integer>0</integer>
                <key>CFG_FB_LIMIT</key>
                <integer>0</integer>
                <key>CFG_FORCEMAXDPM</key>
                <false/>
                <key>CFG_FORCE_MAX_DPS</key>
                <false/>
                <key>CFG_GEN_FLAGS</key>
                <integer>0</integer>
                <key>CFG_INT_SSPC</key>
                <integer>25</integer>
                <key>CFG_NODM</key>
                <true/>
                <key>CFG_NO_HDCP</key>
                <false/>
                <key>CFG_NO_MSI</key>
                <false/>
                <key>CFG_NO_MST</key>
                <false/>
                <key>CFG_NO_PP</key>
                <false/>
                <key>CFG_NO_SLS</key>
                <false/>
                <key>CFG_PAA</key>
                <integer>0</integer>
                <key>CFG_PULSE_INT</key>
                <true/>
                <key>CFG_TRANS_WSRV</key>
                <true/>
                <key>CFG_USE_AGDC</key>
                <false/>
                <key>CFG_USE_CP2</key>
                <false/>
                <key>CFG_USE_DPT</key>
                <false/>
                <key>CFG_USE_FBC</key>
                <false/>
                <key>CFG_USE_FEDS</key>
                <true/>
                <key>CFG_USE_LPT</key>
                <false/>
                <key>CFG_USE_REGAMMA</key>
                <true/>
                <key>CFG_USE_SRRB</key>
                <false/>
                <key>CFG_USE_STUTTER</key>
                <true/>
                <key>DALReadDelayStutterOff</key>
                <integer>4</integer>
                <key>DALUseUrgencyWaterMarkOffset</key>
                <integer>0</integer>
            </dict>
            <key>aty_properties</key>
            <dict>
                <key>PP_DisableCAC</key>
                <integer>0</integer>
                <key>PP_DisableDIDT</key>
                <integer>0</integer>
                <key>PP_DisableFFC</key>
                <integer>1</integer>
                <key>PP_DisablePowerContainment</key>
                <integer>0</integer>
                <key>PP_DisableULV</key>
                <integer>0</integer>
                <key>PP_DisableVoltageIsland</key>
                <integer>1</integer>
                <key>PP_EnableBAPM</key>
                <integer>0</integer>
                <key>PP_EnableLoadFalconSmcFirmware</key>
                <integer>1</integer>
                <key>PP_EnablePerDPM</key>
                <integer>1</integer>
                <key>PP_Falcon_QuickTransition_Enable</key>
                <integer>1</integer>
                <key>PP_MclkActivityTarget</key>
                <integer>5</integer>
                <key>PP_MclkDpmDisabled</key>
                <integer>0</integer>
                <key>PP_MclkDpmTuning0</key>
                <integer>2057216</integer>
                <key>PP_MclkDpmTuning1</key>
                <integer>2057216</integer>
                <key>PP_PhmUseDummyBackEnd</key>
                <integer>0</integer>
                <key>PP_SclkDpmTuning0</key>
                <integer>1991680</integer>
                <key>PP_SclkDpmTuning1</key>
                <integer>1991680</integer>
                <key>PP_SclkDpmTuning2</key>
                <integer>1991680</integer>
                <key>PP_SclkDpmTuning3</key>
                <integer>1991680</integer>
                <key>PP_SclkDpmTuning4</key>
                <integer>1991680</integer>
                <key>PP_SclkDpmTuning5</key>
                <integer>1991680</integer>
                <key>PP_SclkDpmTuning6</key>
                <integer>1991680</integer>
                <key>PP_SclkDpmTuning7</key>
                <integer>1991680</integer>
            </dict>
        </dict>
    </dict>
    <key>OSBundleLibraries</key>
    <dict>
        <key>com.apple.iokit.IOACPIFamily</key>
        <string>1.2</string>
        <key>com.apple.iokit.IOGraphicsFamily</key>
        <string>1.3</string>
        <key>com.apple.iokit.IOPCIFamily</key>
        <string>1.2</string>
        <key>com.apple.kext.AMDSupport</key>
        <string>1.5.1</string>
        <key>com.apple.kpi.bsd</key>
        <string>8.0.0</string>
        <key>com.apple.kpi.iokit</key>
        <string>8.0.0</string>
        <key>com.apple.kpi.libkern</key>
        <string>8.0.0</string>
        <key>com.apple.kpi.mach</key>
        <string>8.0.0</string>
    </dict>
    <key>OSBundleRequired</key>
    <string>Safe Boot</string>
</dict>
</plist>

and if you look for Dayman we have:

<key>ATY,Dayman</key>
<dict>
<key>aty_config</key>
<dict>
<key>CFG_NVV</key>
<integer>2</integer>
<key>CFG_USE_AGDC</key>
<true/>
<key>CFG_USE_CP2</key>
<false/>
</dict>
</dict>



so that var calling the AGDC.kext is already set to true by default. And that's why things are working between Dayman and 5K monitors. The default RadeonFramebuffer doesn't have it set to True by default and so you should edit it if you want to use that FB instead of Dayman. And this is true for all the other FBs which doesn't have the var explicitly set to true.

@Mork_vom_Ork Configurations where there is no MST hub or display could not work with all the 3 DP ports active but, most likely, you will have 2 DP ports and 1 HDMI active and no more.
 
Last edited:
I mean, it seems as if your HP is simply not working in 5K, which is why it's showing in scaled mode. Support can be glitchy, sometimes powering everything down and back up can help get things in sync. I have found that displayport cables are insanely finicky as well ... if you have shorter 6 ft cables, test with those first.

CFG_USE_AGDC edits are only necessary if your card does not have it enabled by default. You've probably locked in on a particular framebuffer that has it enabled already. I use the default RadeonFramebuffer with AMD7000Controller and thus have to make the edit.
 
I mean, it seems as if your HP is simply not working in 5K, which is why it's showing in scaled mode. Support can be glitchy, sometimes powering everything down and back up can help get things in sync. I have found that displayport cables are insanely finicky as well ... if you have shorter 6 ft cables, test with those first.

CFG_USE_AGDC edits are only necessary if your card does not have it enabled by default. You've probably locked in on a particular framebuffer that has it enabled already. I use the default RadeonFramebuffer with AMD7000Controller and thus have to make the edit.

Uhm...no, I don't think so. As you can read in the initial part of my post , my HP starts in 5K native mode without any FB edits when it's alone, but the other 3rd DP port is disabled. So cables and ports cannot be the culprit here. Same ports and same cables.
After Dayman's modding all the other monitors, my BenQ 2K (DP), and my Sony TV 1K (HDMI) work all together with my HP, which is still working 5K - because 2560*1440px HiDPI is 5K res - but its recognised by MacOS as scaled.

Late today or tomorrow I will post all the detailed results of Dayman edits, but my speculation here is that there is some sort of dependencies among all the ports DPs & HDMIs . These dependencies rule one DP port out when all the other two are working. Modding the FB addresses this specific limit and all the ports come to life again but with that caveat: the HP is working 5K but it considered as scaled by OSX.

Of course it doesn't happen under Windows because I've been testing Windows too and that points out it's MacOS related and not HW related. What intrigues me very much is the chance that deeper edits of Dayman FB might lead to being able to remove any limitation ... or not!

PS: CFG_USE_AGDC edit's technique doesn't work in this case because the AGPD.kext has inside of it the same limitation: only two ports, even if they can work in MST mode.
 
Uhm...no, I don't think so. As you can read in the initial part of my post , my HP starts in 5K native mode without any FB edits when it's alone, but the other 3rd DP port is disabled. So cables and ports cannot be the culprit here. Same ports and same cables.
After Dayman's modding all the other monitors, my BenQ 2K (DP), and my Sony TV 1K (HDMI) work all together with my HP, which is still working 5K - because 2560*1440px HiDPI is 5K res - but its recognised by MacOS as scaled.

Late today or tomorrow I will post all the detailed results of Dayman edits, but my speculation here is that there is some sort of dependencies among all the ports DPs & HDMIs . These dependencies rule one DP port out when all the other two are working. Modding the FB addresses this specific limit and all the ports come to life again but with that caveat: the HP is working 5K but it considered as scaled by OSX.

Of course it doesn't happen under Windows because I've been testing Windows too and that points out it's MacOS related and not HW related. What intrigues me very much is the chance that deeper edits of Dayman FB might lead to being able to remove any limitation ... or not!

PS: CFG_USE_AGDC edit's technique doesn't work in this case because the AGPD.kext has inside of it the same limitation: only two ports, even if they can work in MST mode.
I don't see how your HP could possibly be in 5K mode if the display OSD itself says 2560x1440. The scaling itself happens in software but the resolution to the monitor should be 5120x2880. Also, you have the "About this Mac/Displays" section open and that says 2560x1440 as well. The monitor will say "5120 x 2880" there if it's running at full res ... it does this correctly on all my computers.

I suppose there could be some sort of other glitch going on. But objectively speaking it would be VERY difficult for the HP monitor itself to be confused about what resolution it is receiving.

If ports are misbehaving that definitely points to a framebuffer issue. I get the impression that some of the controller kext's target specific framebuffers by default instead of using the auto-detecting RadeonFramebuffer, which will cause all kinds of problems if you don't have a matching card or haven't gotten the framebuffer patching exactly right via clover. I've tried to stay away from the framebuffer edits as I've had some really strange stuff happen, especially with multiple video cards.

BTW when MST support flips out due to bad cables, framebuffers, plugging and unplugging, etc ... it can often manifest itself in weirdness. This often bit me during testing. The most stable MST solution is still to boot cold and not unplug anything.

Not sure what you are referring to regarding AGDP limitations of two ports?
 
I don't see how your HP could possibly be in 5K mode if the display OSD itself says 2560x1440. The scaling itself happens in software but the resolution to the monitor should be 5120x2880. Also, you have the "About this Mac/Displays" section open and that says 2560x1440 as well. The monitor will say "5120 x 2880" there if it's running at full res ... it does this correctly on all my computers.

I know it's pretty difficult to explain, but facts are there and we have to accept them. Better: we have to find a possible explanation for this.

Screen Shot 2017-06-22 at 22.34.50 (2).png

it's definitely 5K even if the OS states differently.
I can also put the monitor to 5K without Hi-DPI and it will work perfectly, as you can see:

Screen Shot 2017-06-22 at 22.36.11 (2).png

so nobody can say it's not 5K res. It is!

And all the displays are working together:

Screen Shot 2017-06-22 at 22.31.43.png
MacOS still states 2560*1440px but it's evidently a mistake, the resolution is not read properly. Why? I don't really know. But I have some speculations.

The best one is that when the var CFG_USE_AGDC is set to true - and in Dayman FB is true by default (10.12.6 beta) - there is some sort of limitations in the numbers of DP/HDMI ports that can work simultaneously together. My technique to resort the priority of DP ports modding the FB kind of force them to work and so ports that would have been disabled by the policy (AGDP.kext) are still working but in a kind of passive mode: they send signals but they are not recognised by the OS.

But I also humbly ask for help because I still don't full understand this behaviour.

Still, If you use a FB which has the var CFG_USE_AGDC is set to false, you won't have MST. Unluckily MST is strictly related - in a manner I don't fully understand - to the call of AGDP.kext.

BTW your technique to modify the pointer of your Mac board-ID in AGDP.kext making it point to a Custom empty profile might lead to occasional freezes and instability when you change monitors plugs, ports, or resolutions. That's why you somehow experienced occasional weirdness.
With my modding you can hot-plug whatever monitor you want or change its resolutions and nothing bad will happen, because there is still a "Config" var to point at, that defines how the system has to behave.
 
I know it's pretty difficult to explain, but facts are there and we have to accept them. Better: we have to find a possible explanation for this.

View attachment 262643

it's definitely 5K even if the OS states differently.
I can also put the monitor to 5K without Hi-DPI and it will work perfectly, as you can see:

View attachment 262644

so nobody can say it's not 5K res. It is!
I'll have to take your word for it. It's very odd.


And all the displays are working together:

View attachment 262646
MacOS still states 2560*1440px but it's evidently a mistake, the resolution is not read properly. Why? I don't really know. But I have some speculations.

The best one is that when the var CFG_USE_AGDC is set to true - and in Dayman FB is true by default (10.12.6 beta) - there is some sort of limitations in the numbers of DP/HDMI ports that can work simultaneously together. My technique to resort the priority of DP ports modding the FB kind of force them to work and so ports that would have been disabled by the policy (AGDP.kext) are still working but in a kind of passive mode: they send signals but they are not recognised by the OS.

But I also humbly ask for help because I still don't full understand this behaviour.
It isn't clear to me that AGDP actually disables individual ports on the monitor, but your framebuffer edits are very interesting and seem to be accomplishing something good. That's good progress!

Still, If you use a FB which has the var CFG_USE_AGDC is set to false, you won't have MST. Unluckily MST is strictly related - in a manner I don't fully understand - to the call of AGDP.kext.
AGDC is required for MST to work. If you examine the displaypolicyd binary, which seems to control MST support, there are many references to AGDC inside. There are actually many interesting potential switches to start displaypolicyd with, but I haven't figured out how to activate them in any useful manner.

BTW your technique to modify the pointer of your Mac board-ID in AGDP.kext making it point to a Custom empty profile might lead to occasional freezes and instability when you change monitors plugs, ports, or resolutions. That's why you somehow experienced occasional weirdness.
With my modding you can hot-plug whatever monitor you want or change its resolutions and nothing bad will happen, because there is still a "Config" var to point at, that defines how the system has to behave.
That's interesting ... I had not considered the edits I made to AGDP might affect that. Although I'm not sure how to work around it.

Of course I have a slightly different configuration from yours at the end of the day ... I have been running some combination of ATI Radeon HD 7970, FirePro W7000 in the past. And now a single FirePro W9000 with triple Dell UP2715K's! I've been using these particular GPU's, even though they are older, instead of the RX480 and 580 specifically to avoid as many compatibility problems as possible. The monitor itself, as we know, also appears to matter ... the Dell is what appears to have the most hands on support from Apple at the moment. I would not rule out some specific quirks with the Z27q.
 
Of course I have a slightly different configuration from yours at the end of the day ... I have been running some combination of ATI Radeon HD 7970, FirePro W7000 in the past. And now a single FirePro W9000 with triple Dell UP2715K's! I've been using these particular GPU's, even though they are older, instead of the RX480 and 580 specifically to avoid as many compatibility problems as possible. The monitor itself, as we know, also appears to matter ... the Dell is what appears to have the most hands on support from Apple at the moment. I would not rule out some specific quirks with the Z27q.

Yes, you're right in this. HP Z27Q has less support than DELL 5K under MacOS ... but I was unable to find the UP2715K in my country... it's not in stock anymore.

But your choice in GPU made me think and so I've ordered and will give a try to an AMD RX7100 which is the PRO card closer to the RX480/580 as they all have an Ellesmere Polaris 10 chip. It has 4 DP ports and no other port type.

I'm very curious about its VBIOS dump and I'll report about it as soon as I get it. But then choosing the right FB will be crucial...
 
Yes, you're right in this. HP Z27Q has less support than DELL 5K under MacOS ... but I was unable to find the UP2715K in my country... it's not in stock anymore.

But your choice in GPU made me think and so I've ordered and will give a try to an AMD RX7100 which is the PRO card closer to the RX480/580 as they all have an Ellesmere Polaris 10 chip. It has 4 DP ports and no other port type.

I'm very curious about its VBIOS dump and I'll report about it as soon as I get it. But then choosing the right FB will be crucial...
I've been quite curious about how well the WX series cards will work so I'm looking forward to your experience! It's essentially an up to date version of the FirePro 7000 and only the pro cards like the Radeon Pro series really bump up the number of displayports enough.
 
Status
Not open for further replies.
Back
Top