[MOVED] Hacking NVidia Cards into their Professional Counterparts

[gordan]

I was talking to the raw binary code hex editor view, but you should be able to verify the exact location of the bytes you need to change using nvbios dumps.

Loss of fan control and video outputs is exactly the reason why I suggested modifying into a K5000 rather than K2, since the K5000 is supported for all of the same VGPU functionality as a K2, and as I mentioned before I ran a 4GB GTX680 with a K5000 BIOS on it with no ill effects.

Did you modify the device id hierarchy IDs on the primary K2 BIOS to make it work on a 680? nvflash shouldn't have even allowed you to flash the BIOS onto the card if you hadn't adjusted that.

Did you remember to rebuild the BIOS checksum using KBT after you modified the BIOS? If the checksum is invalid, the card won't work with similar symptoms to what you are describing.

For normal PCI passthrough, all the modified cards I tried work fine - over time I have used 450, 470, 480, 670, 680, 690 and currently 780Ti. If normal PCI passthrough doesn't work, the modified BIOS is broken.

I wouldn't expect the EEPROM to expire in fewer than 1000 writes. I did kill the EEPROM on my sacrificial GTX450 way back when I was still researching what strap bits do, but that involved trying to go through many, many permutations of strap bits in an automated way (nvflash the straps on a 450 running as a secondary card, reboot, capture lspci -vvvv, repeat...) and eventually it gave up.

You might want to investigate further using a cheap GTX470 or GTX480 card. No hardware modification required, it's all controlled by the soft straps. Get a Q5000 or Q6000 BIOS, make sure the device ID strap bits are suitably set for the GeForce card to result in the equivalent Quadro, modify the RAM configuration block to adjust the size from 6GB to 1.5GB (or 5GB to 1.25GB in case of the Q5000), fix the checksum with KBT, flash that on, and see how you get on. The Fermi cards didn't have UEFI headers and crypto signatures, so with a modified BIOS on those you won't be getting thwarted if the newer drivers check the BIOS' crypto signatures. A high end Fermi card is probably a much better candidate for exprimentation with this kind of thing than the Kepler cards. And of course they are much cheaper nowdays, so not as big a loss of you break one. Quadro 5000 and Quadro 6000 are both supported for ESXi VSGA, so in theory the functionality is there. I remember reading about a demo system somebody put together, running 6 gaming seats (Borderlands at 800x600@25fps) on a single Q6000. Obviously you won't get that many with 1/4 of the RAM on a 480, but it should be sufficient for experimental purposes. Whether Xen actually supports the older Fermi cards, I don't know, but ESXi definitely did.

On a separate note, if you want VSGA/VGPU type functionality, there are other ways to achieve something equivalent. Run VMware Player 5 (6 has somewhat broken 3D acceleration in my experience), and once you get 3D accelerated VMware drivers installed, also install Kainy. That will do realtime video compression (CPU based, sadly, so you'll need plenty of CPU) and allow you to output it to a Kainy client (which exists for Windows, Linux and Android). It effectively gives you the equivalent capability stack to VSGA/VGPU and Nvidia Shield. And best of all, you don't even have to use an Nvidia card. Not as performant as VSGA/VGPU, but when I tested it as a proof of concept it worked usably well.

[Milardo]

Hi, i couldn't quite find an answer, but is it possible to via software method in windows os, modify the device id of a mobile gpu like the gt650m that has nvidia optimus? So i have a clevo w110er and i want to use gamestream and shadowplay but gt650m isn't supported because it's a gt series card. I want to modify the device id into a gtx660m which is closely related to gt650m so geforce experience will let me use gamestream and shadowplay. Is this possible, please let me know and how to do that, thanks in advance for any good replies.

[high]

Did you modify the device id hierarchy IDs on the primary K2 BIOS to make it work on a 680? nvflash shouldn't have even allowed you to flash the BIOS onto the card if you hadn't adjusted that.

Oops! Need to look into that. But "nvflash -4 -5 -6" happily flashed the card. Of course, I agreed to all the warnings, including selling my soul.

the K5000 is supported for all of the same VGPU functionality as a K2,

Even for the XenServer/Nvidia GPU hypervisor technology? http://www.nvidia.co.uk/object/grid-virtual-gpus-uk.html

Did you remember to rebuild the BIOS checksum using KBT after you modified the BIOS? If the checksum is invalid, the card won't work with similar symptoms to what you are describing.

Yes, I updated the checksum.

You might want to investigate further using a cheap GTX470 or GTX480 card.

I'm considering that for my VM Host build. I was hoping to put together a XenServer (the Citrix distribution) with the GTX680 -> K2 to specifically use the XenServer-Nvidia vGPU/GPU Hypervisor. But if that technology still locked to the "proper" K1/K2 cards, then I will simply have to defer to using multiple cards in full passthrough.
 

On a separate note, if you want VSGA/VGPU type functionality, there are other ways to achieve something equivalent.

Thanks! I'll take a look at your suggestions.

WRT the K5000 mod, I've removed the two resistors on my GTX680 to make a K2. Can I simply flash the K5000 bios (changing the memory from 4GB to 2GB) onto the GTX680? Do the soft-straps in the bios also need to be changed? (please. please. don't tell me I have to solder a 0402 resistor. I can't even see those buggers, let alone solder them!)

Thanks you for all your guidance in getting this working. It's greatly appreciated!

[gordan]

GT650M and GTX660M are based on GK107 which is a Kepler generation chip. You can use the soft-straps in the BIOS to change the device ID, same as on earlier Fermi and Tesla GPUs, but whether the extra features like Gamstream and Shadowplay will become available is questionable. By all means, try it and report back, I don't think anyone has attempted this before.

[gordan]

the K5000 is supported for all of the same VGPU functionality as a K2,

Even for the XenServer/Nvidia GPU hypervisor technology? http://www.nvidia.co.uk/object/grid-virtual-gpus-uk.html

No idea, I never looked into it.

You might want to investigate further using a cheap GTX470 or GTX480 card.

I'm considering that for my VM Host build. I was hoping to put together a XenServer (the Citrix distribution) with the GTX680 -> K2 to specifically use the XenServer-Nvidia vGPU/GPU Hypervisor. But if that technology still locked to the "proper" K1/K2 cards, then I will simply have to defer to using multiple cards in full passthrough.

I am only using straight PCI passthrough. For any sensible degree of performance you will probably need most of a 680's worth of GPU. If you need more density than that, 690s are probably the way to go.

You should also be aware that, as mentioned recently on this thread, most recent QEMU includes patches that neuter the GPU driver's detection of whether it is running in a VM, so there is no longer any need to modify the card. The driver simply won't be able to detect it is running in a VM and will thus agree to initialize the card without any problems. That rather deprecates most of this thread.

On a separate note, if you want VSGA/VGPU type functionality, there are other ways to achieve something equivalent.

Thanks! I'll take a look at your suggestions.

WRT the K5000 mod, I've removed the two resistors on my GTX680 to make a K2. Can I simply flash the K5000 bios (changing the memory from 4GB to 2GB) onto the GTX680? Do the soft-straps in the bios also need to be changed? (please. please. don't tell me I have to solder a 0402 resistor. I can't even see those buggers, let alone solder them!)

To modify to a K5000 you will have to make sure the resistors are in place with appropriate values for a K5000. Soft straps no longer do anything of importance, and the masks should be left blank (OR bits of the device ID should be set to 0 and AND bits of the device ID should be set to 1). Other than that, a K5000 BIOS with the memory initialization change should work fine.

I seem to recall reading somewhere that recent drivers check the crypto signature on the BIOS, which means that any BIOS modification will make the crypto signature check fail, which will make the driver refuse to initialize the card. Even of you manage to defeat other problems, this may well foil your plans, since for the 2GB card you'll have to modify the BIOS payload. On a 4GB card you can get away with simply replacing the resistors to set the hard strap and flashing the K5000 BIOS as is onto the card, which means an unmodified BIOS with all the right signatures.

A number of people have reported that just removing both resistors can cause problems. For some people it works fine (it did for me), for some people it causes problems ranging from driver not initializing the card at all to random stability problems.

This is one of the big advantages of the old GTX480 cards - no soldering required, and no UEFI BIOS signatures.

[high]

I am only using straight PCI passthrough. For any sensible degree of performance you will probably need most of a 680's worth of GPU.

My use case isn't for gaming, rather its for virtualization. And my last stumbling block is getting AVCHD video to play sensibly to a thin client. It seems that Multimedia Passthrough of AVCHD video over remoting protocols is broken with win8. The Mrs. will not be happy with my tinkering if she can't watch videos of the kiddies. And AVCHD decompression without hardware offloading in VMs is inadequate. Funny, the performance issue is only with AVCHD video, not other H264 content. But that's for another thread...

You should also be aware that, as mentioned recently on this thread, most recent QEMU includes patches that neuter the GPU driver's detection of whether it is running in a VM, so there is no longer any need to modify the card.

I'll take a look at that if all else fails. But I have a hacked GTX680, so let's see how far we can push it.

To modify to a K5000 you will have to make sure the resistors are in place with appropriate values for a K5000.

https://www.eevblog.com/forum/chat/hacking-nvidia-cards-into-their-professional-counterparts/msg207550/#msg207550

According to this, I need a 15K value at resistor 2 but will first try without the 40K at resistor 0. Hopefully, the card will be stable. Did you replace both resistors?

Even of you manage to defeat other problems, this may well foil your plans,

It's worth a shot. And would be worth the risk to have something really cool for only £130.

This is one of the big advantages of the old GTX480 cards - no soldering required, and no UEFI BIOS signatures.

Absolutely! Unfortunately, they don't really come cheap on eBay for their age. Maybe I'll get lucky. fingers-crossed.

[gordan]

I am only using straight PCI passthrough. For any sensible degree of performance you will probably need most of a 680's worth of GPU.

My use case isn't for gaming, rather its for virtualization. And my last stumbling block is getting AVCHD video to play sensibly to a thin client. It seems that Multimedia Passthrough of AVCHD video over remoting protocols is broken with win8. The Mrs. will not be happy with my tinkering if she can't watch videos of the kiddies. And AVCHD decompression without hardware offloading in VMs is inadequate. Funny, the performance issue is only with AVCHD video, not other H264 content. But that's for another thread...

I had reasonable results with Kainy with reasonable amounts of CPU available to the VM (I wouldn't want to have fewer than 4 cores per VM for it). You have to be realistic with the kind of resolution you expect on the client, though.

To modify to a K5000 you will have to make sure the resistors are in place with appropriate values for a K5000.

https://www.eevblog.com/forum/chat/hacking-nvidia-cards-into-their-professional-counterparts/msg207550/#msg207550

According to this, I need a 15K value at resistor 2 but will first try without the 40K at resistor 0. Hopefully, the card will be stable. Did you replace both resistors?

Yes, I replaced both nibbles' worth of resistors.

This is one of the big advantages of the old GTX480 cards - no soldering required, and no UEFI BIOS signatures.

Absolutely! Unfortunately, they don't really come cheap on eBay for their age. Maybe I'll get lucky. fingers-crossed.

That's because they are still extremely good at some things. The Kepler architecture was a radical change and although it allowed for many more shaders and higher clock speeds there were other constraints that made implementing efficient solutions to some computational problems difficult, not to mention the cases where on existing cuda code 480 significantly outperformed the 680. Various examples of this still pop up on various GPU computing forums. The Fermi cards were also quite hackable, e.g. by Quadrifying the GTX470 and 480 you get not only virtualization passthrough support, but also the second DMA channel which can make a huge difference for some loads. Hacking the 680 into a K5000 doesn't enable this, even though the real K5000 does supposedly have dual DMA engines.

Also, remember there is a problem with the K2 with things like DL-DVI modes and higher resolutions. Eventually in the interest of easy modification and no worse functionality I settled for using the last of my 680s as a Tesla K10. Teslas get PCI passthrough support, and it only required modifying one nibble of the ID on the 680. But most importantly, unlike with the K2 modification, the high resolution modes worked. This is a documented bug with K2s, and required both a driver update and a firmware update to overcome. I was particularly surprised to find that a 680 modified into a K2 with the stock BIOS suffered from the same problem. It implies that the driver tries to do something odd with the card in terms of output when it detects it as a K2.

Then again, given how intensive the task of rendering 3D + H.264 encoding in realtime is, it wouldn't surprise me if nobody actually expected this to work at more than SL-DVI grade resolutions in a meaningful way anyway. As I mentioned before, the ESXi demo I read about with the Quadro 6000 provided 6 seats at 800x600@25fps. If you add those together, that's a single seat at 1080p@34fps. Assuming a 680/K10/K2 is about twice as fast as a 480 (a generous assumption), that will just about give you 1080p@60fps. If that is the level of performance you require, then you might as well just use direct PCI passthrough.

The whole GPU sharing idea is only really usable for very low resolutions and frame rates.

[feeling]

Hello everyone,

I need your help, I lose myself in the subject.

I would like to mount a VMWare ESXi server and I think using vSphere client.

I would like the customer can enjoy the pc graphics acceleration for games and 3D.

at present, with a budget of $ 650 which graphics card you advise me, and you need it to make changes to the circuit, if so can you give me the reference of a card on which it is running.

Thank you very much in advance.

[gordan]

Quadro 6000

[feeling]

yes if I multiply my budget by 10. lol

[gordan]

The going rate for Quadro 6000 on ebay is under $650.
Note: Quadro 6000 (Fermi), NOT Quadro K6000 (Kepler).

[high]

GTX690 has 3 devices on the same slot, and they have a specific hierarchy. A GTX680 has no hierarchy. Hierarchy is encoded in the BIOS and (thankfully), nvflash refuses to flash a BIOS with incorrect hierarchy ID.

The question is - where is the hierarchy ID encoded in the BIOS? The two vBIOSes on the GTX690 are quite different, so it isn't obvious where one is set for hierarchy ID of switch port 8 and the other to switch port 16.

I don't suppose anyone here knows?

Hi Gordan,

Did you ever figure out where the Hierarchy ID is encoded in the BIOS? nvflash seems to figure out hierarchy id. Comparing the bios from the two GPUs on the GTX690 or the K2 doesn't seem to yield any useful results in the binary diff. Will an nvbios dump show the location of this Hierarchy ID? Also, google doesn't seem to yield much information on "PCI hierarchy id".

I'll still try plugging along until my 15K resistors arrive and I'll also have to give up coffee so I can steady my hands to solder that tiny thing.

As always, advice will be greatly appreciated.

Thank!

[gordan]

I did figure it out some time last year. I thought I posted something about it. Unfortunately, my GTX690 expired shortly after my BIOS hacking on it, so I'm not even sure if I have notes on that part of reverse engineering somewhere.

I did it by comparing the two BIOS-es on the GTX690. They are nearly identical, IIRC the main differences are:
1) Version number (no idea why, but IIRC the versions are slightly different between primary and secondary GPU)
2) Video output initialization (each GPU has access to a subset of the ports on the back of the card, IIRC)
3) Hierarchy ID setting block
4) Checksum at the end of the file

You should be able to identify 3) by elimination and a bit of trial and error reasonably quickly. It is the same approach I used to identified the part of the BIOS code that sets up the RAM options.

If you get anywhere with a modified K2 BIOS you'll need to get the fan working (you WILL cook your card without it very, very quickly!). I'm not sure where the fan control piece of code is, unfortunately, but if you look on OCN at some of the 780Ti/Titan OC-ing thread, there's a user OccamRazor that might know more about the fan control in the Kepler BIOS-es.

[high]

Awesome! Will give that a whirl.

Got it, so the hierarchy is an entire block rather than a simple flag. Will check it out.

WRT the fan, the "real" K2 doesn't have any fans and is passively cooled. So perhaps the GK104 could run passively cooled.

Besides, when I flashed the K2 bios to my 680, the fan defaulted to full-speed; so not too worred about cooking eggs on the heatsink right now. :-P
 
The next thing I will probably have to wrry about is that the K2 has an I2C controller exported to PCI but the GTX680 doesn't. I wonder if anything besides sensors are expeciting to see that device?

[gordan]

WRT "block", I mean in the sense of a diff of xxd hex dumps. It could be just one line of difference, but a line could only be differing in a single byte, and it'd still come up as a while line in the diff.

K2 can run passively cooled ONLY in a server that has tornado grade fans pushing the air from the front of the server to the back of the server, as is typical on rack mounted servers. The heatsink and casing design on the K2 is such that the front and back of the HSF package is open, to allow air blown by the case fans to easily pass through the GPU heatsink. You cannot do that with a 680.

But if it defaults to full speed, no need to worry about meltdown.

[pasha4ur]

Hello, people!

I need your help. I want to convert MSI GTX 460 v2 Hawk into Quadro 4000m



my BIOS http://pasha4ur.org.ua/GF104.rom

Please, help me with commands for flashing. I broke my head while read about bytes here
http://www.altechnative.net/2013/11/25/virtualized-gaming-nvidia-cards-part-3-how-to-modify-a-fermi-based-geforce-into-a-quadro-geforce-gts450gtx470gtx480-to-quadro-200050006000/

And I found

Hi hishamkali,

you made a mistake…
you use the string from gtx480…
this work for me on a GTX460 (0E22)
nvflash –index=X –straps 0x7FFC3FC3 0x10006428 0x7FF1FFFF 0x00020000

bye

Will it work better in Adobe Apps? Will I can adjust clocks and fans? Games will work too?

Thx for help

Help, please   

[high]

Well, I'm a bit stumped on the hierarchy ID. The output from "nvflash" for the K2 Bios stated "Normal Board":


NVIDIA Firmware Update Utility (Version 5.136)

IFR Data Size         : 1112 bytes
IFR CRC32             : 75F43D9C
IFR Image Size        : 1536 bytes
IFR Image CRC32       : 7A38D37E
IFR Subsystem ID      : 10DE-100D
Image Size            : 195072 bytes
Version               : 80.04.D4.00.07
~CRC32                : 5FD73C74
OEM String            : NVIDIA
Vendor Name           : NVIDIA Corporation
Product Name          : GK104 Board - 20550550_g1
Product Revision      : Chip Rev   
Device Name(s)        : GRID K2
Board ID              : E122
PCI ID                : 10DE-11BF
Subsystem ID          : 10DE-100D
Hierarchy ID          : Normal Board
Chip SKU              : 895-0
Project               : 2055-0550
CDP                   : N/A
Build Date            : 08/13/13
Modification Date     : 08/19/13
UEFI Support          : Yes
UEFI Version          : 0x10023 (Jul 30 2013 @ 16558196)
UEFI Signer(s)        : Microsoft Corporation UEFI CA 2011
Sign-On Message       : GK104 P2055 SKU 0550 (GPU1) VGA BIOS (HWDIAG)


That's why nvflash let me flash the GTX680; it doesn't think that anything is wrong. I'll still try to find the different block and compare with the GTX BIOS to see if a swap will do anything.

I looked at an nvbios dump between the two K2 BIOS and see that the only difference, except for BIOS version numbers is in one of the power profiles:

GPU1:
  2: min = 30000 mW, avg = 66000 mW, peak = 75000 mW (unkn12 = 0)
0x7ee0: 04 00 30 75 00 00 d0 01 01 00 f8 24 01 00 01 01
0x7ef0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x7f00: 00 00 00

GPU2:
  2: min = 30000 mW, avg = 72500 mW, peak = 87000 mW (unkn12 = 0)
0x7ee0: 04 00 30 75 00 00 34 1b 01 00 d8 53 01 00 01 01
0x7ef0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x7f00: 00 00 00

And there is a one byte difference in some UNK3C table:
GPU1: 0x7dc7: 01 ff 00 1b b7 00 00 10 00 00 00 00 00 00 00 00
GPU2: 0x7dc7: 01 fd 00 1b b7 00 00 10 00 00 00 00 00 00 00 00

Even though there is a PLX bridge on the K2 board, the board is presented as two discrete and independent GPUs rather than a single logical board like the GTX690 must be?

With the original GTX680 ROM flashed on the board, I tried the VGX drivers in XenServer again and noticed a line in the logs, in which the driver stated:

vGPU is supported only on VGX capable boards

The driver knows that the VGX extensions are not available. I'm guessing that the GTX BIOS doesn't map any of the Kepler visualization instructions into memory....but the K2 bios does....but I can't get the K2 bios to work on the GTX680...

So, I will resign my build to adding multiple GPUs and directly passing them back to the VMs instead of trying this fancy GPU virtualization stuff - it's clear that it's only reserved for the super-high end and even then, it is still in its infancy. I'm also waiting for some 15K resistors and I'll convert this card to K5000 and see how I get along.

Back to the drawing board...

UPDATE: Pulled the trigger for a GTX 470 from the bay. Will mod that to Quadro 5000. My VM host will then have un-gimped GTX470 -> Quadro 5000 and Frankenstein GTX680 -> K5000/K2...and an Intel HD 4000 IGP as an appendix....does anyone run XBMC on a Dom0?

This is the output from XenServer with my modified GTX680 -> K2 card.

Nov 30 20:38:59 xen-01 vgpu-1[5777]: demu_initialize: PLUGIN CONFIG: /usr/share/nvidia/vgx/grid_k220q.conf,gpu-pci-id=0000:02:00.0
Nov 30 20:38:59 xen-01 vgpu-1[5777]: notice: pluginconfig: /usr/share/nvidia/vgx/grid_k220q.conf,gpu-pci-id=0000:02:00.0
Nov 30 20:38:59 xen-01 vgpu-1[5777]: notice: Loading Plugin0: libnvidia-vgx
Nov 30 20:38:59 xen-01 vgpu-1[5777]: notice: gpu-pci-id : 0000:02:00.0
Nov 30 20:38:59 xen-01 vgpu-1[5777]: notice: vgpu_type : quadro
Nov 30 20:38:59 xen-01 vgpu-1[5777]: notice: Framebuffer: 0x1A000000
Nov 30 20:38:59 xen-01 vgpu-1[5777]: notice: Virtual Device Id: 0x11B0:0x109D
Nov 30 20:38:59 xen-01 vgpu-1[5777]: notice: ######## vGPU Manager Information: ########
Nov 30 20:38:59 xen-01 vgpu-1[5777]: notice: Driver Version: 340.34
Nov 30 20:38:59 xen-01 vgpu-1[5777]: notice: VGX Version: 1.2
Nov 30 20:38:59 xen-01 vgpu-1[5777]: error: vGPU is supported only on VGX capable boards
Nov 30 20:38:59 xen-01 vgpu-1[5777]: error: Initialization: unknown error 1
Nov 30 20:38:59 xen-01 vgpu-1[5777]: error: vmiope_process_configuration: plugin registration error
Nov 30 20:38:59 xen-01 vgpu-1[5777]: demu_initialize: fail18
Nov 30 20:38:59 xen-01 vgpu-1[5777]: demu_initialize: fail17
Nov 30 20:38:59 xen-01 vgpu-1[5777]: demu_initialize: fail16
Nov 30 20:38:59 xen-01 vgpu-1[5777]: demu_initialize: fail15
Nov 30 20:38:59 xen-01 vgpu-1[5777]: demu_initialize: fail14
Nov 30 20:38:59 xen-01 vgpu-1[5777]: demu_initialize: fail13
Nov 30 20:38:59 xen-01 vgpu-1[5777]: demu_initialize: fail12
Nov 30 20:38:59 xen-01 vgpu-1[5777]: demu_initialize: fail11
Nov 30 20:38:59 xen-01 vgpu-1[5777]: demu_initialize: fail10
Nov 30 20:38:59 xen-01 vgpu-1[5777]: demu_initialize: fail9
Nov 30 20:38:59 xen-01 vgpu-1[5777]: demu_initialize: fail8
Nov 30 20:38:59 xen-01 vgpu-1[5777]: demu_initialize: fail7
Nov 30 20:38:59 xen-01 vgpu-1[5777]: demu_initialize: fail6
Nov 30 20:38:59 xen-01 vgpu-1[5777]: demu_initialize: fail5
Nov 30 20:38:59 xen-01 vgpu-1[5777]: demu_initialize: fail4
Nov 30 20:38:59 xen-01 vgpu-1[5777]: demu_initialize: fail3
Nov 30 20:38:59 xen-01 vgpu-1[5777]: demu_initialize: fail2
Nov 30 20:38:59 xen-01 vgpu-1[5777]: demu_initialize: fail1: Inappropriate ioctl for device
Nov 30 20:38:59 xen-01 fe: 5777 (/usr/lib64/xen/bin/vgpu --domain=1 --vcpus=4 --gpu=0000:02:00.0 --config=/usr...) exited with code 1

[Milardo]

GT650M and GTX660M are based on GK107 which is a Kepler generation chip. You can use the soft-straps in the BIOS to change the device ID, same as on earlier Fermi and Tesla GPUs, but whether the extra features like Gamstream and Shadowplay will become available is questionable. By all means, try it and report back, I don't think anyone has attempted this before.

Hi and thanks for your reply. Could you please post a guide or link that shows how to modify the soft straps in the BIOS to change the device ID, and which programs to use for  that? I'd very much appreciate that, and I'll report back with results of course. Thanks in advance.

[gordan]

UPDATE: Pulled the trigger for a GTX 470 from the bay. Will mod that to Quadro 5000. My VM host will then have un-gimped GTX470 -> Quadro 5000 and Frankenstein GTX680 -> K5000/K2...and an Intel HD 4000 IGP as an appendix....does anyone run XBMC on a Dom0?

I do (well, Plex Home Theater, but that is just XBMC + Plex plugin + Plex skin), but I use an ATI card for dom0 with the radeon driver. Nvidia have openly said they don't care about supporting dom0 with their binary driver, they know very well it's been broken on newer cards for a long time. My 8800GT works fine with the binary driver, but more recent cards, e.g. GT630 which I wanted to use just crashes the machine when Xorg tries to load in dom0.

[gordan]

GT650M and GTX660M are based on GK107 which is a Kepler generation chip. You can use the soft-straps in the BIOS to change the device ID, same as on earlier Fermi and Tesla GPUs, but whether the extra features like Gamstream and Shadowplay will become available is questionable. By all means, try it and report back, I don't think anyone has attempted this before.

Hi and thanks for your reply. Could you please post a guide or link that shows how to modify the soft straps in the BIOS to change the device ID, and which programs to use for  that? I'd very much appreciate that, and I'll report back with results of course. Thanks in advance.

The info is on the gpumod wiki on wikia.

[Milardo]

Is this it, does it work with kepler gpu, does it matter on an optimus gpu situation?

http://gpumod.wikia.com/wiki/Modifying_2xx_%E2%80%93_4xx_series_GeForce_into_a_Quadro

Can I do this on windows 8.1 x64 in the os and do is it just that i am modifying the bios and not flash a new one?

[gordan]

It won't work on a Kepler, you have to do soldering to modify a Kepler card.
Optimus setup does not work with the Nvidia binary driver, so I'm not sure what you are envisaging achieving.
The OS doesn't matter. You don't need to re-flash the whole BIOS, only modify the straps using nvflash.

[Milardo]

Sorry i dont understand, can i use nvflash to modify the straps, which will change the device id? Since this a mobile gpu, can it be done without a hardware modifying, soldering, etc.? Im using windows 8.1 x64 and i always download the latest nvidia driver which is 344.75 for notebooks. Basically i want to change my device id of gt650m so it gets read by geforce experience, as a gtx660m which is closely related, so i can have gamestream and shadowplay official support, which as of now, i can't use, gamestreaming that is unless i can get geforce experience to let me. Will that webpage tutorial, is it how to modify the straps with nvflash?

[gordan]

It cannot be modified without soldering.

[imanz]

Anyone that had worked on the 680 let me know if you can help. I am working on the gigabyte 680 -  gv-n680OC-2GD but am having some strange problems...

I have been following the example posted here:
https://www.eevblog.com/forum/chat/hacking-nvidia-cards-into-their-professional-counterparts/?action=dlattach;attach=43392;image which I believe is also on page 6 of this post

Before starting it seems my original values were slightly different than what I expected:
R0: none
R1: 12.5k~15k
R2: 25k
R3: 5k

So I followed the example and tried the following arrangement:
R0:40k
R1:none
R2:40k
R3:none

When trying to boot I get no video on both the card and onboard video card. I hear the first post beep and about 15 seconds later get one long beep and 5/6 short beeps (asus motherboard). I removed the card and checked all the resistors/connections and noticed that R2 is reading the correct 40k as expected but I am getting 18.5k resistance on the R0 connection. I removed the resistor and replaced it with another one (same 0402 40K SMD resistor) and the value is still around 18k with same issue at boot.

Does anyone have any ideas?