- Joined
- Dec 8, 2018
- Messages
- 59 (0.03/day)
Processor | 2x Intel Xeon E5-2680 v2 |
---|---|
Motherboard | ASUSTeK COMPUTER INC. Z9PE-D8 WS |
Memory | SAMSUNG DDR3-1600MHz ECC 128GB |
Video Card(s) | 2x ASUS GEFORCE® GTX 1080 TI 11GB TURBO |
Display(s) | SAMSUNG 32" UJ590 UHD 4k QLED |
Case | Carbide Series™ Air 540 High Airflow ATX Cube Case |
Power Supply | EVGA 1000 GQ, 80+ GOLD 1000W, Semi Modular |
Mouse | MX MASTER 2S |
Keyboard | Azio Mk Mac Wired USB Backlit Mechanical Keyboard |
Software | Ubuntu 18.04 / [KVM - Windows 10 1809 / OSX 10.14] |
Got it. I just don't believe that NV team each time redesigns totally that part(s) of driver which calls for motherboard version.
From the other hand, I thought about permanent fix for good and all future versions and OS's from the side of MoBo and to mod the BIOS to show right version that NV driver will accept as SLI ready.
Just name/version and nothing more.
For instance, I have ASUS P8Z77 V-LX, and if I'll change it to ASUS P8Z77 V-LK , that stupid check will be fooled.
And of course, I don't mean it's easy and can be recommended to the wide audience.
Personally I did not put much effort into understanding how they are validating SLI support (I am pretty sure it's not as simple as checking the ACPI DSDT SLI entry but I could be wrong). However, I can confirm that simply changing the Mobo model will not do the trick. If you want to play around with that idea I would encourage you to set up a VM with GPU passthrough so that you can easily modify the BIOS args that are provided to the OS.
My intuition tells me (or at least this is how I would do it if I were in their shoes) that they might do some hashing with the (MOBO model + some UUID that is agreed upon between NVIDIA and the MOBO vendor) which gets validated at runtime when the driver is initialized.
Overall, my approach was to follow the path of least resistance. Moreover, people can patch the driver themselves and know that their system was not compromised, wherehas if they are running an executable to modify their driver they have no idea what is happening in the background. I know some users would prefer to have it done the easy way but I am a big advocate for transparency. To digress a bit, there's hundreds of thousands of people running torrent based windows pirated version with rootkits and yet they are completely oblivious to it.
As for how it is done. The first time I did indeed trace the functions as @P!nkpanther suggested. After a couple of versions it became easier to find the functions without tracing anything since the byte code does not change by much ; running heuristics it takes 2 minutes to find the location of the target function between two dll's. The original Different-Auto-SLI was done by searching for bitmasks patterns in the .dll; while this works in the short term it fails miserably whenever a new version is released where new bytecode has a slight different structure or different registers are used to perform the OPs (using a relaxed bitmask means that you'll get more than one possible candidate function, making it too strict means it will most likely fail to find the function in the next version release). This is why Different-Auto-SLI had to be manually updated every of couple of driver releases.
If you ask me what would be the way to go in terms of making it future proof for any OS version and easier for everyone to use I would say it's rather trivial. I would host a website on IPFS (InterPlanetary File System) with a javascript app that allows you to upload the DLL, read the version from the header, and then run call graph heuristics to find the byte code to patch. I do not have the time nor interest to work on such project but I would more than happy to contribute in terms of feedback and ideas on how to tackle such task.
P.S: For those of you who keep PM'ing me, do not waste your time - If you have anything to say or ask do it inside this thread otherwise you're not going to get a reply from me.
Last edited: