I don't have the time to waste on benchmarking anything not related to code I implement and some of the things I have stated are obvious.
If you don't believe performance is affected by injection of a virtual bios insert 2 different cards alter and inject a virtual bios for each card and then create (valid) NVMT data for each card and inject it and tell me it isn't more responsive.
Bloating the device-properties with 64k of rom for each video card doesn't make a lot of sense when this can be reduce to less than 128 bytes per card by producing NVMT data and yes, processing large device-properties data takes time and the time is noticeable, especially when it contains three 64k rom blobs.
The DCB does not need to be altered, you do it because you do not encode/inject NVMT, this of course requires injection of the altered virtual bios to keep your intended configuration which bloats the device-properties and thus takes more time to process and you think this doesn't have any negative impact on performance or functionality?
Here is something factual again, not all cards work with/from a virtual bios and some cards will not work with other cards when a virtual bios is introduced and bofors can confirm this, we spent three days working this conflict before figuring out what the problem was.
The apple EFI generated and injected NVMT data provides information to decode the DCB and PCT, is significantly smaller in size and takes less time to generate than extracting a rom image, patching the DCB and injecting the (patched/altered) rom and then processing it, why do you think apple does it the NVMT way?
The information contained in the NVCAP can affect a cards performance as well as providing quick access to port assignments for drivers, I have found 5 different versions of apple NVCAP data based on the a cards chipset (I don't have every apple nVidia card so there could be more), 3 are pretty much the minimum I would suggest be implemented, a simple switch/case can provide the correct version of the NVCAP data for alteration.
The other issue with the current trend of NVCAP data/injection is that it is not understood, the first byte actually tells the driver something, the 0x07 near the end people assume is a static value with no bit assuagement is also an incorrect assumption along with all of the 0x00 values in between, think of the NVCAP as a set of consecutive 8bit and 16bit registers, some registers are reserved and should remain 0x00 while others can be altered to change behavior.
Since the goal is to obtain the greatest compatibility amongst non-native cards a little tradeoff is expected and you should be able to get away with 3 different versions of NVCAP data without seriously sacrificing performance.
Tell me that the following two NVCAP's create the same performance in the test card:
/* test card - BFG GT120 512mb */
#define OLD_NVCAP 0
#if OLD_NVCAP == 0
uint8_t NVCAP[] =
{
0x04, 0x00, 0x00, 0x00,
0x00, 0x00, 0x03, 0x00,
0x1c, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x07,
0x00, 0x00, 0x00, 0x00
};
#else
uint8_t NVCAP[] =
{
0x05, 0x01, 0x00, 0x00,
0x00, 0x00, 0x03, 0x00,
0x1c, 0x00, 0x00, 0x00,
0x00, 0x00, 0x0a, 0x0b,
0x00, 0x00, 0x00, 0x00
};
#endif
If you think they do then you need to test this cause I see 1 byte that puts the card in a faster clock rate and that means faster GPU processing.
As I said, I have time to help someone with the code but I don't have time to do it myself, if you wish to take advantage of my assistance great, if not that's OK too, I just don't have the time to work on a project I don't use and have no way of testing so assign it to someone and have them see me if you want my assistance.