... will I loose PhysX support or anything similar by reporting this cards to the computer as a higher model?
May be I am missing something?
When modding to the Quadro on my card, it had different results when using the Geforce vs Quadro drivers.
I have a Quadro 4000 and a Tesla C2075 if either of those would help in this or anything in the future.
so question is will a 39KOhms or a 46KOhms one work?
The dom0 will be used by another person for work with the iGPU. Is this possible?
The dom0 will be used by another person for work with the iGPU. Is this possible?
Possible, yes. The i915 (Intel HD4000) will only work if you are using it for a text only console. X has artifacting with the Xen kernel and intel driver when using the iGPU on dom0 (presumed Xen is at fault here, no solution in the works afaik).
I wouldn't recommend using dom0 as a workstation anyway. I passed the iGPU through to an hvm and used it that way. More secure, bit harder to manage dom0 when it is headless, though.
As for the resistors and such, I suggest reading the thread before attempting anything like this. The questions you posed are all answered.
I think I might be getting somewhere with this.
Attached is the glxinfo output from a genuine Q2000 and a GTS450 modified to Q2000.
They are quite substantially different.
I wonder what differences lurk in the BAR0 registers and if they might be changeable...
I'm not sure what version of NVidia drivers you are using, but as a hint try something older, perhaps from the 270.XX line.
With the original softmods back when, I believe that NVidia had caught up with that and disabled advanced features (ie. Quadro) in drivers.
Still trying to determine when it occurred, which requires testing many old versions of drivers.
What would that prove?
How do you figure that? How does the driver know it's not a real Quadro? I'm using the latest, 319.23 on Linux. There are no separate Quadro and GeForce drivers on Linux, it's the same driver for both.
I suspect the functionality is laser cut out.
Then again, it could be there is extra strapping on the PCB (e.g. a cap across chip pins) that disables certain functionality, but this is hard to eyeball. All 3 GTS450 cards hav emarkedly different cap arrangements under the GPU, which is different again from the real Q2000.
I am somewhat positive that crippling occurs on the software side
What would that prove?It would prove that things have changed in the mean time.
People have soft-modded their GTX cards to Quadros in the past, remember RivaTuner? It had a soft-strap editor that would change PCI Id to match whatever other card.
Also, remember that fellow who posted on NVidia CUDA forums about modding vbios soft-straps on his GTX 480 to a Tesla.
How do you figure that? How does the driver know it's not a real Quadro? I'm using the latest, 319.23 on Linux. There are no separate Quadro and GeForce drivers on Linux, it's the same driver for both.I might as well say the same thing back at you: How do *you* figure that?? Obviously you have not done anything past installing the latest drivers and drawing a conclusion based on a quick look at it.
I suspect the functionality is laser cut out.
Then again, it could be there is extra strapping on the PCB (e.g. a cap across chip pins) that disables certain functionality, but this is hard to eyeball. All 3 GTS450 cards hav emarkedly different cap arrangements under the GPU, which is different again from the real Q2000.Prove it.
Everyone assumes some kind of manufacturing process or what not involved to cripple GPUs. I suppose because this is an electronics forum that's inherent, but if you have not looked into other aspects, I would not draw conclusions so fast.
Actually I am somewhat positive that crippling occurs on the software side because, unlike you, I tried an older driver giving me different result than the new one, AND I took a peek under the hood (inside the driver).
Soft-modding still works to a large extent. The only limitation is the strap bits that are exposed in software.
In the past three weeks I have soft-modded:
GTS450->Q2000
GTX470->Q5000
GTX480->Q6000
GTX580->Q7000
GTX680->Tesla K10
Q7000 and Tesla K10 aren't "MultiOS" capable, so the driver doesn't make them work with VGA passthrough, which makes the mod of limited usefulness, over and above enabling TCC feature in Windows.
Everything required to do this is pretty well documented by the nuoveau project. There are also other things that are useful (and easy) to mod, for example BAR1 size to be >= the size of the RAM on the card. This lets you take, say, a 4GB card and when you're not gaming, you can map it as a really fast block device for some fast swap or whatever you might need.
Kepler BIOSes are quite different, but having spent an hour looking at the dump out of my GTX680, I've worked out most of the bits relevant to this thread. The strapping on them is... odd. It's done in two places, but what is odd is that it is done the same way in two places.
The other odd thing is that the PCI device ID is set in two places, but it has a profound effect on the way the card is handled. For example, just changing the the strapping for the device ID from GTX680 -> Tesla K10 works fine. But if you also chance the PCI ID, at least in the primary location, the card no longer works properly - it gets detected as a standard unaccelerated VGA adapter, even though the Quadro driver is still running it, and the RAM on it shows up as 2990MB instead of 4096MB. Put the device IDs back to GTX680 (but keep the K10 strapping), and it works fine. I'm guessing there may be a checksum on the blocks containing the PCI IDs, but I didn't have a genuine Tesla K10 BIOS handy to cross-check against it last night.
It seems to me you mistakenly compare ability to be detected as something else (spoofing) with real conversion of one to another. Perhaps in your application of this modification (Xen in Linux) it is sufficient to just spoof the wanted card but what I'm looking for is actually getting the Quadro performance instead.
I'd like to know how did you mod the GTX 580 to Q7000 with soft straps and have it work?
Because, I've spent some time on a similar project using a GTX 570 and the only real way to do this was through changing hard straps (driver ignores vbios soft-straps and the system will not boot, will boot with a black screen or not initialize the GUI). Some, if not all, Quadro vbioses actually check if the ROM and board PCI ID match and also lock out.
I am able to get a Q7000, C2075 through hard straps and the system actually boots and initializes. Then I am able to install the latest Quadro/Tesla driver, alas the performance is not there due to whatever limitations imposed (I'd say software).
Why don't you share that information here, as it is not documented anywhere it will help everyone else?
You might be finding the PCI ID from the VBIOS and the EFI sections, that's why there are two matches.
On newer Windows systems and Macs, EFI is used to init/boot the card and so the PCI ID in that section also has to be changed - needs to match hard straps. EFI code itself also checks for the Vendor ID, PCI ID and Board ID, so that has to be changed accordingly.
As far as I know the checksums exist for the entire ROM and for the HWINFO section (soft-straps), although it is true that the GK ROM format has changed and they've introduced wrappers for the old VBIOS. Obviously one needs to make sure the HWINFO checksum is correct and then adjust the entire ROM checksum.
You've also probably noticed a cryptographic signature at the end of the ROM which UEFI/Winblows uses to verify authenticity of hardware. In Linux that is irrelevant but thanks to M$, they've managed to create a deadlock and control all OEMs who produce motherboards with this whole signature issue (remember Linux booting problems until the whole UEFI issue was figured out).
The usual way. Change the PCI ID, re-calc the checksum, flash the card, change the straps, in that order. It "just works". Doesn't really gain you much, though. Mosaic app might work, but since Q7000 isn't MultiOS, it won't run in VGA passthrough mode.
I got to that point without heating up my soldering iron.
Hmm... I wonder if this could be stripped out to reduce the BIOS to the old, EFI-less state that is more open to modifying. It'd also make it a lot more similar to the previous BIOSes in terms of understanding what the various bits do.
I don't own any EFI motherboards, but I would have thought the whole EFI wrapping should be strippable out from the VBIOS. Once you skip past the 0x400 bytes of header, the rest of the BIOS is similar in terms of offsets of known areas to the Fermi BIOSes.