Popular Post Mieze Posted October 16, 2017 Popular Post Share Posted October 16, 2017 (edited) Introduction With Whatevergreen.kext we already have a workaround for the AMD GPU wakeup issue which first arose with the release of El Capitan, but as a workaround is just a second class solution for a problem I decided to trace back the reason for the issue to it's origin and this post is the result of my research. As I used a R9 270X to do my research, which is the only AMD GPU I have, my patch has only been verified to work properly with this chip but according to the information sources I used, I have no reason to believe it won't work on other AMD GPU's too. In case there is still some uncertainty left in a particular point, I will mention this explicitly. Materials Used The Linux kernel sources of the Radeon driver in order to get a better understanding of the GPU's internals: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/radeon?h=next-20171013 A copy of the ACPI 6.0 specs in order to find out how to dump the chip's control register space. A disassembler, e.g. objdump in Terminal or the trial version of Hopper Disassembler. What I Did As it's been a well known fact that wakeup with AMD GPUs still works with El Capitan and Sierra provided you select the IGPU as primary GPU enabled CSM and use Legacy VBIOS of the AMD GPU in BIOS setup. I was wondering what is different with UEFI VBIOS and decided to I create dumps of the GPU's control register space while using Legacy VBIOS with CSM enabled and while using UEFI VBIOS with CSM disabled in order to find out. Comparing the register space contents it became obvious where the root of the problem lies and how it can be fixed with a DSDT patch. Technical Background Using Legacy VBIOS only the primary GPU is initialized by the VBIOS, i.e. only the IGPU is initialized while the AMD GPU is left untouched. When OS X boots up the framebuffer controller kext will find the AMD GPU in vanilla state, initialize it properly and wakeup will work as expected. That's also the reason why you have to blind boot in this configuration. Using UEFI VBIOS the AMD GPU will be initialized too, provided it has a display connected to one of it's ports. You'll see the BIOS splash screen and will be able to access the BIOS settings but unfortunately macOS's framebuffer controller kext will notice that the GPU has already been initialized and skips the basic setup so that the configuration made by the VBIOS will be used and this is the point where things start to go wrong because this configuration seems to be broken causing wakeup to fail. First of all you have to locate the AMD GPU in your DSDT. In my case it can be found at _SB.PCI0.PEG0.PEGP but it needs to be renamed to GFX0 for AppleGraphicsDevicePolicy.kext (AGDP) to work properly. This can be done manually or using a Clover patch (this is what I did) and I assume that this problem has been already solved before. The reason why I mention it explicitly here, is that you should be aware of it and don't get confused when your AMD GPU has a different name in the DSDT than in IORegistry. Second, we need to get access to the GPU's control register space. According to the Linux sources, PCI Base Address Register 2 (BAR2) is used to address the control register space on Radeon HD5000, HD6000 and HD7000 GPUs. It's a 64bit base address register but newer GPUs (BONAIRE and above, i.e. Radeon HD8000 and HD9xxx) are different as the use BAR5 instead of BAR2. Unlike BAR2, BAR5 is a 32bit base address register. On my R9 270X (PITCAIRN) BAR5 is zero so that I decided to use this as an indication to use BAR2 but I must confess that I haven't checked if it works for all supported GPUs too. In case my patch doesn't work for you, be aware that this might be a pitfall! The Radeon driver's source code tells us that the first display controller engine's registers can be found starting at offset 0x6800. It also tells us a lot about the meaning of the register contents. Using Legacy VBIOS my R9 270X's display controller engine's registers are still at their default values when macOS boots: 00006800 01 00 00 00 08 80 00 0a 00 00 00 00 00 00 00 00 |................| 00006810 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00006820 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00006830 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00006840 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00006850 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00006860 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00006870 00 00 00 00 08 80 00 14 00 00 00 00 00 00 00 00 |................| 00006880 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00006890 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000068a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000068b0 00 00 00 00 10 00 00 00 00 00 00 20 00 00 00 20 |........... ... | 000068c0 00 00 00 20 10 00 00 00 00 00 00 20 00 00 00 20 |... ....... ... | 000068d0 00 00 00 20 00 00 00 00 00 20 00 00 00 00 00 00 |... ..... ......| 000068e0 00 00 00 20 00 00 00 00 00 00 00 00 00 20 00 00 |... ......... ..| 000068f0 00 00 00 00 00 20 00 00 00 00 00 00 00 00 00 20 |..... ......... | With UEFI VBIOS the display controller engine's registers look quite different. Using the Linux driver sources you can easily make sense out of these values and will discover that I've got a 4K display connected to my R9 270X which is configured to it's native resolution using 32 bits per pixel. 00006800 01 00 00 00 0a 80 00 0a 00 00 00 00 00 00 00 00 |................| 00006810 00 00 00 00 00 00 00 00 00 0f 00 00 f4 00 00 00 |................| 00006820 f4 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00006830 00 00 00 00 00 0f 00 00 70 08 00 00 00 00 00 00 |........p.......| 00006840 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00006850 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 |................| 00006860 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00006870 00 00 00 00 08 80 00 14 00 00 00 00 00 00 00 00 |................| 00006880 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00006890 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000068a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000068b0 00 00 00 00 10 00 00 00 00 00 00 20 00 00 00 20 |........... ... | 000068c0 00 00 00 20 10 00 00 00 00 00 00 20 00 00 00 20 |... ....... ... | 000068d0 00 00 00 20 00 00 00 00 00 20 00 00 00 00 00 00 |... ..... ......| 000068e0 00 00 00 20 00 00 00 00 00 00 00 00 00 20 00 00 |... ......... ..| 000068f0 00 00 00 00 00 20 00 00 00 00 00 00 00 00 00 20 |..... ......... | The rest was just a little bit of laborious work and trial and error, comparing register contents, understanding their meanings and see what happens when you reset these registers to their default values. If you try to play around with your GPU's control registers a little bit more, be prepared to get a garbled screen for a few seconds. After all I've managed to create a DSDT patch which fixes the wrong registers while preserving screen output during boot and, most important, solves the wakeup issue. The Patch Putting things together I created a DSDT patch to fix the incorrectly initialized registers. With this patch applied, I now have working wakeup with my R9 270X under Sierra (10.12.6) using UEFI VBIOS with CSM disabled in UEFI setup. No kext patches or additional kexts are needed anymore for sleep/wake to work properly with my R9 270X anymore. I can see the BIOS splash screen on my display and can access UEFI setup but the best of all is that there hasn't been a single wakeup issue since I applied this patch. Device (PEGP) { Name (_ADR, Zero) // _ADR: Address OperationRegion (PCIB, PCI_Config, Zero, 0x0100) Field (PCIB, AnyAcc, NoLock, Preserve) { Offset (0x10), BAR0, 32, BAR1, 32, BAR2, 64, BAR4, 32, BAR5, 32 } Method (_INI, 0, NotSerialized) // _INI: Initialize { If (LEqual (BAR5, Zero)) { Store (BAR2, Local0) } Else { Store (BAR5, Local0) } OperationRegion (GREG, SystemMemory, And (Local0, 0xFFFFFFFFFFFFFFF0), 0x8000) Field (GREG, AnyAcc, NoLock, Preserve) { Offset (0x6800), GENA, 32, GCTL, 32, LTBC, 32, Offset (0x6810), PSBL, 32, SSBL, 32, PTCH, 32, PSBH, 32, SSBH, 32, Offset (0x6848), FCTL, 32, Offset (0x6EF8), MUMD, 32 } Store (Zero, FCTL) Store (Zero, PSBH) Store (Zero, SSBH) Store (Zero, LTBC) Store (One, GENA) Store (Zero, MUMD) } } In case you have in-detail questions or need AML code for debugging (code to dump BARs or to dump the GPUs control register space) please let me know. I'm willing to share all my information in order support further research. Below you can find the register dumps I created attached to this post. FAQ Do I still have to select the IGPU as the primary display? No. Although I haven't tried this on my own, user chh1 confirmed that this is no longer required when using the patch (please see http://www.insanelymac.com/forum/topic/328549-tracing-back-the-amd-gpu-wakeup-issue-to-its-origin/?do=findComment&comment=2519884). Nevertheless I still recommend to select the IGPU as primary as there is absolutely no reason not to do so, in particular as the IGPU will be unusable for multimedia acceleration on Haswell based systems when it's not the primary one (IGPU's dev id is different when it's not the primary one). When I boot into macOS I always end up with a black screen. Does your patch solve this problem too? No, it doesn't. This patch solves the wakeup issue, nothin more and nothing less. The black screen after boot is either the result of a connector problem (please create a connector patch for your graphics card using the well-known methods) or the result of a problem with AGPM as certain system definitions (in particular recent iMacs) select special configurations for graphics power management. In order to achieve proper operation of AGPM it is crucial that your GPUs have correct names in the DSDT matching those listed in the AGPM configuration for the system definition (IGPU for the Intel GPU and GFX0 for the AMD GPU on iMac15,1, iMac17,1 and iMac18,x). You may patch your DSDT manually or use a Clover DSDT-patch to fix the device names. Credits vit9696 for developing Whatevergreen.kext and pointing me to the right direction. RehabMan for developing ACPIDebug.kext The Linux Radeon driver kernel developers for providing me with the background information I needed. Legacy.bin.zip UEFI.bin.zip Edited November 27, 2017 by Mieze 44 Link to comment Share on other sites More sharing options...
MattsCreative Posted October 17, 2017 Share Posted October 17, 2017 Now all we need is a multi monitor fix for more then 2 monitors Link to comment Share on other sites More sharing options...
kitmac Posted October 17, 2017 Share Posted October 17, 2017 awesome work. Would this work for an RX 580 in an Egpu? Link to comment Share on other sites More sharing options...
Mieze Posted October 17, 2017 Author Share Posted October 17, 2017 awesome work. Would this work for an RX 580 in an Egpu? Yes, it should work with the Polaris GPUs too. PS: It would be helpful if someone with a Polaris GPU could send me a dump of the GPU's PCI config space created with lspci (or RW-everything under Windows, etc.) so that I can verify the Base Address Register layout. Mieze 1 Link to comment Share on other sites More sharing options...
Slice Posted October 17, 2017 Share Posted October 17, 2017 Yes, it should work with the Polaris GPUs too. PS: It would be helpful if someone with a Polaris GPU could send me a dump of the GPU's PCI config space created with lspci (or RW-everything under Windows, etc.) so that I can verify the Base Address Register layout. Mieze Hello Mieze! Good work you began! This dump contains lspci dump and more for Polaris GPU #35 We have three issues with Radeon drivers in HackOS 1. Bad GPU registers initialisation. Hope you resolved this. 2. Bad connectors in PC Videocard compared to Apple's framebuffer. If we set Inject=NO then Apple's driver calculates connectors by itself. But not enough for multimonitors. 3. Bad AMDRadeonX4000GLDriver.bundle (not for Hack). It can't be patched by Clover because it is loaded from user space. I may propose to create better bundle with name like AMDRadeonX4001GLDriver.bundle and patch the name somewhere it used. 5 Link to comment Share on other sites More sharing options...
Mieze Posted October 17, 2017 Author Share Posted October 17, 2017 This dump contains lspci dump and more for Polaris GPU #35 Thank you very much for the link! Mieze Link to comment Share on other sites More sharing options...
chh1 Posted October 21, 2017 Share Posted October 21, 2017 Thank you very much. Disable IGPU,My RX580 works very well without whatevergreen. 1 Link to comment Share on other sites More sharing options...
p569 Posted October 21, 2017 Share Posted October 21, 2017 Great work, Mieze Thank you for sharing your findings The patch works perfectly on Sapphire Radeon RX580 Nitro+!! I don't even need to disable IGPU in BIOS, disabling CSM and setting the IGPU as a primary display is enough The 4K screen is connected to the Radeon card and I can boot with all debug messages shown on the screen+ Apple Logo I can go to sleep - and wake up. 2 Link to comment Share on other sites More sharing options...
Pavo Posted October 22, 2017 Share Posted October 22, 2017 Yes, it should work with the Polaris GPUs too. PS: It would be helpful if someone with a Polaris GPU could send me a dump of the GPU's PCI config space created with lspci (or RW-everything under Windows, etc.) so that I can verify the Base Address Register layout. Mieze Tell me how you do it and I can dump it for you on my MP5,1 with RX 480 Hope this helps DarwinDumper_3.0.3_21.10_21.46.29_MacPro5,1_Apple_X64_Unknown_17A405_henrybrock.zip 1 Link to comment Share on other sites More sharing options...
Mieze Posted October 22, 2017 Author Share Posted October 22, 2017 Tell me how you do it and I can dump it for you on my MP5,1 with RX 480 Hope this helps Hello Pavo, thank you for your friendly offer and the link but Slice already posted a link to this dump a few days ago. Mieze Link to comment Share on other sites More sharing options...
MattsCreative Posted October 22, 2017 Share Posted October 22, 2017 https://drive.google.com/drive/folders/0B3y5hldpEFDYNGJiWTdtUDNlY28?usp=sharinglets hope one of these is what you need Link to comment Share on other sites More sharing options...
Matthew82 Posted October 22, 2017 Share Posted October 22, 2017 I make little and cosmetic modification of your patch to add correct name, apply correct framebuffer and load custom rom. For rx 580 Device (GFX1) { Name (_ADR, Zero) // _ADR: Address OperationRegion (PCIB, PCI_Config, Zero, 0x0100) Field (PCIB, AnyAcc, NoLock, Preserve) { Offset (0x10), BAR0, 32, BAR1, 32, BAR2, 64, BAR4, 32, BAR5, 32 } Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method { Store (Package (0x1C) { "AAPL,slot-name", Buffer (0x07) { "Slot-4" }, "@0,name", Buffer (0x0C) { "ATY,Orinoco" }, "@1,name", Buffer (0x0C) { "ATY,Orinoco" }, "@2,name", Buffer (0x0C) { "ATY,Orinoco" }, "@3,name", Buffer (0x0C) { "ATY,Orinoco" }, "@4,name", Buffer (0x0C) { "ATY,Orinoco" }, "ATY,Card#", Buffer (0x0C) { "113-4E3531U" }, "ATY,Copyright", Buffer (0x33) { "(C) 1988-2017, AMD Technologies Inc." }, "ATY,Rom#", Buffer (0x1D) { "GV-RX580GAMING-8GD/F10/058AE" }, "ATY,VendorID", Buffer (0x02) { 0x02, 0x10 }, "ATY,DeviceID", Buffer (0x02) { 0xDF, 0x67 }, "device_type", Buffer (0x12) { "ATY,OrinocoParent" }, "model", Buffer (0x13) { "RX 580 G1 GIGABYTE" }, "hda-gfx", Buffer (0x0A) { "onboard-1" } }, Local0) DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0)) Return (Local0) } Method (_INI, 0, NotSerialized) // _INI: Initialize { If (LEqual (BAR5, Zero)) { Store (BAR2, Local0) } Else { Store (BAR5, Local0) } OperationRegion (GREG, SystemMemory, And (Local0, 0xFFFFFFFFFFFFFFF0), 0x8000) Field (GREG, AnyAcc, NoLock, Preserve) { Offset (0x6800), GENA, 32, GCTL, 32, LTBC, 32, Offset (0x6810), PSBL, 32, SSBL, 32, PTCH, 32, PSBH, 32, SSBH, 32, Offset (0x6848), FCTL, 32, Offset (0x6EF8), MUMD, 32 } Store (Zero, FCTL) Store (Zero, PSBH) Store (Zero, SSBH) Store (Zero, LTBC) Store (One, GENA) Store (Zero, MUMD) } } Device (HDAU) { Name (_ADR, One) // _ADR: Address Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method { Store (Package (0x02) { "hda-gfx", Buffer (0x0A) { "onboard-1" } }, Local0) DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0)) Return (Local0) } } for r9 290x Device (GFX2) { Name (_ADR, Zero) // _ADR: Address OperationRegion (PCIB, PCI_Config, Zero, 0x0100) Field (PCIB, AnyAcc, NoLock, Preserve) { Offset (0x10), BAR0, 32, BAR1, 32, BAR2, 64, BAR4, 32, BAR5, 32 } Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method { Store (Package (0x1A) { "AAPL,slot-name", Buffer (0x07) { "Slot-1" }, "@0,name", Buffer (0x0B) { "ATY,Baladi" }, "@1,name", Buffer (0x0B) { "ATY,Baladi" }, "@2,name", Buffer (0x0B) { "ATY,Baladi" }, "@3,name", Buffer (0x0B) { "ATY,Baladi" }, "ATY,Card#", Buffer (0x11) { "113-C6710101-100" }, "ATY,Copyright", Buffer (0x25) { "(C) 1988-2017, AMD Technologies Inc." }, "ATY,Rom#", Buffer (0x36) { "C67101 HAWAII XT A0 GDDR5 4GB 64MX32 STILT MLU +37.5M" }, "ATY,VendorID", Buffer (0x02) { 0x02, 0x10 }, "ATY,DeviceID", Buffer (0x02) { 0xB0, 0x67 }, "device_type", Buffer (0x11) { "ATY,BaladiParent" }, "model", Buffer (0x14) { "R9 290X Asus MATRIX" }, "hda-gfx", Buffer (0x0A) { "onboard-1" } }, Local0) DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0)) Return (Local0) } Method (_INI, 0, NotSerialized) // _INI: Initialize { If (LEqual (BAR5, Zero)) { Store (BAR2, Local0) } Else { Store (BAR5, Local0) } OperationRegion (GREG, SystemMemory, And (Local0, 0xFFFFFFFFFFFFFFF0), 0x8000) Field (GREG, AnyAcc, NoLock, Preserve) { Offset (0x6800), GENA, 32, GCTL, 32, LTBC, 32, Offset (0x6810), PSBL, 32, SSBL, 32, PTCH, 32, PSBH, 32, SSBH, 32, Offset (0x6848), FCTL, 32, Offset (0x6EF8), MUMD, 32 } Store (Zero, FCTL) Store (Zero, PSBH) Store (Zero, SSBH) Store (Zero, LTBC) Store (One, GENA) Store (Zero, MUMD) } } Device (HDAU) { Name (_ADR, One) // _ADR: Address Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method { Store (Package (0x02) { "hda-gfx", Buffer (0x0A) { "onboard-1" } }, Local0) DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0)) Return (Local0) } } 5 Link to comment Share on other sites More sharing options...
Mieze Posted October 22, 2017 Author Share Posted October 22, 2017 I make little and cosmetic modification of your patch to add correct name, apply correct framebuffer and load custom rom. Yes, iIt can be done this way but it's also possible to let Clover inject these properties. In the end, both methods lead to the same result. Nevertheless, thank you! Mieze Link to comment Share on other sites More sharing options...
Matthew82 Posted October 22, 2017 Share Posted October 22, 2017 Yes, iIt can be done this way but it's also possible to let Clover inject these properties. In the end, both methods lead to the same result. Nevertheless, thank you! Mieze True, but clover can not load two defriend framebuffer selected by me. Link to comment Share on other sites More sharing options...
Gen4ig Posted October 23, 2017 Share Posted October 23, 2017 Thank you Mieze My RX 580 work fine CSM disable, RX 580 Primary Only one more thinks - add HDAU in DSDT for HDMI Audio All great work! Link to comment Share on other sites More sharing options...
Mork vom Ork Posted October 23, 2017 Share Posted October 23, 2017 Just want to confirm, that Miezes patch from first post is working on my config as well. IGPU and CSM completely disabled in BIOS. just have to make some "preperations" to make a tripple-monitor-setup working and some cosmetic changes as well, as already Matthew82 has documented. So now, i no longer nee LILU and WhatEverGreen kexts. Thanx for another incredible work. Love it. Makes my Hackintosh so much easier. 2 Link to comment Share on other sites More sharing options...
carlo_67 Posted October 23, 2017 Share Posted October 23, 2017 Really great, I'm working with two GPU r9 270x and r9 270, on an AMD fx platform, with InjectAti and Framebuffer Futomaki in Clover, and with LILU and WhatEverGreen in kexts 10.12/10.13 I do not have a selection for IGPU, but only enable CSM and legacy Vbios,\and inserted inject Ati and Fbuffer into Clover Mac Pro di carlo.zip Link to comment Share on other sites More sharing options...
Cyberdevs Posted October 23, 2017 Share Posted October 23, 2017 @Mieze Thanks a lot for this great solution. Does this method work on Legacy BIOS as well or it only applies to UEFI? I have an old GA-EP45-DS3R and a Sapphire 7790 GPU which was working with WheteverGreen and Lilu, but ever since macOS High Sierra it's not working anymore. I get the black screen. Thanks again Link to comment Share on other sites More sharing options...
pico joe Posted October 23, 2017 Share Posted October 23, 2017 for HD 7790 with High Sierra i can confirm is black screen too, but normal in 10.13.1 beta 3 btw Thanks for the tips @Mieze 1 Link to comment Share on other sites More sharing options...
carlo_67 Posted October 23, 2017 Share Posted October 23, 2017 @pico joe end @cyberdevs insert the FBuffer in Clover and limit the doors to 2, work in Hsierra 2 Link to comment Share on other sites More sharing options...
Slice Posted October 24, 2017 Share Posted October 24, 2017 @Mieze It's fantastic work! Confirm working with my Radeon 6450 in Sierra. I just made this patch as SSDT SSDT-AMD.aml.zip 16 Link to comment Share on other sites More sharing options...
Slice Posted October 24, 2017 Share Posted October 24, 2017 One more confirmation full uefi | csm-disabled, Gigabyte Radeon HD 7870 (GV-R787OC-2GD) (1002:6818) 5 Link to comment Share on other sites More sharing options...
Mainul Posted October 24, 2017 Share Posted October 24, 2017 Confirmed working without Whatevergreen.kext on Sapphire Nitro+ RX 580 4GB, High Sierra (10.13). Used SSDT aml provided by slice in clover patched folder. With clover injection System information looks better (shows as RX 480). Without clover injection still works and shows as AMD R9 XXX. Might need some cosmetic DSDT patch to show correct information. Sleep works. I have: 1. CSM Disabled 2. IGPU enabled 3. Primary Display PEG 4. ig-platform-id for HD 630 as 0x59120003 for quicksync 5. Lilu.kext and IntelGraphicsFixup.kext for quicksync Everything works fine including hardware decoding by HD 630. SMBIOS used iMac18,3 1 Link to comment Share on other sites More sharing options...
pico joe Posted October 25, 2017 Share Posted October 25, 2017 I can confirm too its work without Whatevergreen.kext in HD 7790 via DSDT @HackPro 6.1 2 Link to comment Share on other sites More sharing options...
Mainul Posted October 25, 2017 Share Posted October 25, 2017 with the patch, on Sapphire nitro+ RX 580 I can get the machine to work on single monitor, however, dual monitor is still not working. dual monitor didn't work with whatevergreen.kext too. Dual monitor works on 10.12.6 but second monitor fails to get signal in 10.13. (both monitor connected to DP ports, where ports are DP,DP,HDMI,HDMI, DDVI, both monitor are 4k monitor). I know some of us have same or similar card and working dual monitor setup. It would be of great help if anyone can give me directions to get my setup working. Thanks. Link to comment Share on other sites More sharing options...
Recommended Posts