Interesting Info from COO of ATI

The DAC, does that use the same pipelines as the 3d does for its color? If it does, the only way ATi could achieve a 10-bit DAC is by using its FP pipeline since I think the R300's integer calculations are still 8 8 8 8. Maybe ATi hasn't implemented a 10-bit DAC because of this? I am just guessing here.
 
LittlePenny said:
The DAC, does that use the same pipelines as the 3d does for its color? If it does, the only way ATi could achieve a 10-bit DAC is by using its FP pipeline since I think the R300's integer calculations are still 8 8 8 8. Maybe ATi hasn't implemented a 10-bit DAC because of this? I am just guessing here.

DACs don't do calculations. They are Digital to Analog convertors. You give it a digital value (with a range of perhaps 8 or 10 bits), and it produces an analog level as a result. Let's say you're trying to generate a color signal that has a range from 0 V to 3.3 V. With an 8 bit DAC, an input of 0x00 would give you 0 V, and an input of 0xFF would give you 3.3 V. You'd then have 254 possible values in the middle to step from 0V to 3.3V. If you have a 10 bit DAC, 0x000 would give you 0V, 0x3FF would give you 3.3V, and you have 1022 intermediate steps. So you get a lot finer control, because your step size is smaller.
 
Btw, I just checked, and the 9700 Pro specs do indeed mention a 10-bit 400MHz DAC. The 9500 almost certainly also includes one. All that's needed to make use of it is to have a front buffer with at least 10 bits of integer precision (64-bit FP color, 64-bit int color, or 32-bit 10-10-10-2 color).
 
Chalnoth said:
A 10-bit DAC shouldn't be the result of any driver-level feature, or anything on the programming side. All that would be necessary is a front-buffer that has at least 10 bits per channel color (which would likely require at least a 64-bit back buffer).

Actually a 10-bit DAC can have a small advantage with a 8-bit framebuffer too when gamma correction is used. It allows the gamma lookup table to contain 10-bit values, and result in more precise output.
 
Interesting, thanks for the corrections. So the R300 uses its FP unit for integer based calculations too? Guess I am no psychic, I always would have thought the NV30 would be the one to not have any integers seeing how they designed Cg.

So not to prod or anything, but how(mathwise) does the R300 do array indexing? I know how to access memory in MIPS assemble, but that uses ints, wouldn't precision errors be a problem with floating point mem access?
 
To think that floats always can get rounding errors is a good but pessimistic base assumption. The truth is that when you only use them for ints (and just doing+ - * ), then you won't get any rounding errors as long as the int fits into the mantissa. R300 can fit a 16bit int in the mantissa. And it can actually store any 17bit int correctly.
 
LittlePenny, That is correct. The ATI-9700 always performs all operations using their high precision format [96bit floating point]. The only difference is when writing to the frame-buffer. At that time, it will vary depending on the mode used (written as 32/64/128 bits). This was talked about here: http://www.beyond3d.com/forum/viewtopic.php?p=43299
 
Basic said:
To think that floats always can get rounding errors is a good but pessimistic base assumption. The truth is that when you only use them for ints (and just doing+ - * ), then you won't get any rounding errors as long as the int fits into the mantissa. R300 can fit a 16bit int in the mantissa. And it can actually store any 17bit int correctly.

This is likely why nv30 offers 12bit ints - those can be fit in FP16.

(FP16 is 1 bit sign + 5 bits exponent + 10 bits mantissa, the FX12 is sliced as 1 bit sign, 11 bit value which can be stored exactly. The highest non-zero bit's position is stored in the exponent so it doesn't need to be stored in the mantissa.)
 
LittlePenny said:
So not to prod or anything, but how(mathwise) does the R300 do array indexing?
Array indexing? You mean for indexed triangle lists/strips/etc.? Obviously, integers are used for memory accesses. However, I wouldn't call how the memory is accessed part of the pipeline...
 
I suspect that LittlePenny referred to array indexing from within vertex/pixel shader programs. Under vertex shaders, the only array that can be indexed is a bank of constant-registers (96 in VS1.0, 256 in VS2.0) - this array contains only 4-element vectors, and indexing is done by putting an FP number into a dedicated address register, rounding it down to nearest integer in the process. Under pixel shaders, the closest thing you can get to an indexed array lookup is a texture map lookup - to simulate lookups into an 1D array, define a 1D texture, set filtering method to point-sampling and divide the array index by the texture size just prior to lookup. For 2D and 3D array lookups, extend this method to 2D and 3D textures as needed. Neither vertex nor pixel shaders allow you to write to any indexable arrays.
 
Back
Top