zzpulp
User
Fresh Boarder
| Posts: 4 |   |
Karma: 0
|
Delta clock - 2007/08/21 16:01
*Throughout this discussion, I refer to a generic byte of data as a character (char)*
Well I finally got one of those new-fangled 7 series cards and bid farewell to my 6800 go ultra. I know I am a bit late on the scene and I dont want to sound like the guy that just saw Heat for the first time ("So you wanna talk about it?"). Therefore as a prelude, I will mention that I have not done any significant research into this issue online and have seen maybe two posts about it. Hopefully, I am not posting old information. And I am not trying to be overly technical either, just somewhat precise. I have posted a short and to the point conclusion at the end.
Before overclocking, I decided it would be fun to examine this delta clock that I had seen as a new edition to the 7 series. To those unfamiliar with the delta clock, it allows you to set clocks for different domains of the core rather than just the core frequency as a whole. These domains are geometric, shader, and ROP (raster operation). The memory still performs as it used to though.
Anyway, I started out applying positive (or so I thought) deltas via NiBiTor. I disregarded some random advice I got encouraging me not to apply a delta greater than 50. As of NiBiTor 3.4a, the delta is interpreted rather strangely. It seems to be little endian, the same as the core and memory clock and I assume any value that requires more than one character (2 Hex digits) representation. Anyway, the interpretation of the delta is two char little endian meaning the first char is the low char and the second is the high char. So four hex digits represent these two chars and allows 16^4 = 65536 possible values [hex-bitwise format: XXYY] (XX and YY just refer to a two-digit hex number and does not imply both digits have to be the same). I tried to put in a delta of 255 [hex- bitwise: FF00] for the hell of it and used Rivatuner to monitor the changes. The result was the same as stock [hex-bitwise: 0000]. I know that Rivatuner's accuracy is not very high when reading clock speeds. So this result made me think possibly that FF was being interpreted as a negative number, namely -1 by 16's complement. Either that or the drivers didn't like deltas that high. So now I began to think of the "XX" clocks as 16's complement (-128 to 127) rather than magnitude-only (0 to 255). To test this, I tried 127 [7F00] and it was indeed interpreted correctly. Also, -128 [8000] was interpreted correctly as well. If you're like me, then this result makes you wonder what those other two digits are for.
I set the XX hex digits to zero and altered YY. Result was that the YY digits control the shader/ROP delta. Knowing this, you can see that there is no need to apply a negative delta to one domain as you can just apply a positive delta on the other domain. Next I wanted to see if I could mix and match. Unfortunately, the bit logic gets a bit complex when trying two non-zero deltas at once. I noted that two of the three domain clocks were always the same and there may be some logic as to which two domain clocks will be the same. Likely Nvidia doesnt even care about these conditions so there is no point in figuring out the logic but I was just a bit interested. I got tired of flashing however so I dont quite know the logic but I think I'm noticing a pattern. The only reason you would wish to set two deltas is to try to control the shader and ROP independently of one another. Also, say if you use Linux, you could boost frequencies in Windows through only drivers instead of a higher-level software utility while keeping default/normal clocks in Linux.
I used this code to test out the bit logic. This code just generates 255 roms giving all possible char values of one position. There are 65536 possible roms but you can kinda cheat the logic so that you only have to test say 50 or so. This code only requires you pass in a rom with the right checksum and that you know the offset of the delta chars. I have a 7950 go GTX and my delta offset is C71D as you can see from the code. I am not a C guy so dont remark on how I didnt use the file structure to read the file size.
| Code: |
#define OFFSET (1 << 12)*12 + (1 << 8)*7 + (1 << 4)*1 + (1 << 0)*13
//delta = XXYY
//change XX
int main(int c, char *argv[])
{
int i,j,n;
unsigned char *b;
char buff[11];
FILE *fin;
for (i=1; i<c; i++)
{
n = 0;
fin = fopen(argv[i], "r");
if(fin == NULL)
{
printf("Error: could not open file %s\n", argv[i]);
continue;
}
//read file size + 1 null
while(!feof(fin))
{
fscanf(fin, "%c", &buff[0]);
n++;
}
fclose(fin);
//fill array with rom values
fin = fopen(argv[i], "r");
b = (char*)malloc(n);
for(j=0; j<n; j++)fscanf(fin, "%c", &b[j]);
fclose(fin);
//adjust rom values and checksum accordingly
for(j=0; j<256; j++)
{
sprintf(buff, "test%02x.rom", j);
fin = fopen(buff, "w");
for(k=0; k<n-1; k++)fprintf(fin, "%c", b[k]);
fclose(fin);
b[OFFSET]++;
b[n-2]--;
//checksum editing via modular arithmetic
//can also change more than the last char for checksum but it is pointless
}
free(b);
}
return 0;
}
|
Format: ./a.out [roms]
Although I have stated why negative deltas are unneeded for conventional use, I will still post the methodology:
To calculate negative delta's I just applied sixteen's complement to the magnitude of the negative number I wished to use and used NiBiTor's built-in hex editor to put in that value (note you can also convert this number back to decimal and put it in the regular input window).
So to calculate -50, write 50 in hex. Then use 16's complement. To do this, think what digit plus the original will give you 15 aka F. Then just add one.
N + N* = 0
50 (10) = 32 (16)
N = 32
N* = CE (note that C+3 = 15 and D+2=15 and add one to this and you get CE)
You can also convert this number back to decimal so you can just input it in Nibitors standard window rather than using the hex editor.
So CE = 16*12+ 14 = 206
So short answers about this post:
If you regard the delta clock as XXYY:
Both XX and YY use 16's complement and hence have a range of -128 to 127
XX controls the core delta*
YY controls the shader/rop delta*
*This is only if the other delta is zero
If you wish to use two nonzero deltas, the logic gets a bit fuzzy. The only significant reason to try two nonzero deltas is to control the shader and rop independently.
Personally, I think the delta is rather gimmicky right now, but later, if NVIDIA engineers cards that are able to reach significantly higher clocks in one domain, then it will be very nice.
Also note that in my bios I have two more hex digits following this XXYY delta that I am unsure about. I got tired flashing so I didn't get to test them out. I was also too lazy to try this out on multiple drivers but I imagine that as long as you dont use two nonzero deltas, the logic is the same. By the way, the driver I used on my 7950GTX was 94.22. I am determined to mod my xbox now though so no distractions. Once I do that I will return to this experiment.
I cant say I have re-read this but if you find anything hard to understand or awkward then just ask or drop me a PM.
|
NiBiTor v6.03
