GeForce 256 DDR for vintage pc

[Jasin Natael]

I have one. It doesn't work, gets super hot super fast. Artifacts and won't run any benchmarks without crashing.

I've kept it around as a curiosity only.

[havli]

I think for NV1x architecture the major bottleneck is the memory bandwidth. Fillrate is not that important. Therefore GF 256 DDR will be always faster than any GF2 MX... even OC models like 200/200 MHz Asus V7100/pro. GF4 MX440 is nice, but only 128-bit models... 64-bit is more or less the same like GF2 MX or GF 256 SDR.

[swaaye]

GF4 also adds dithering to DXT1/S3TC so it's no longer horribly banded as with GF1-3.

[Skanque]

Dell 9830U nVidia 180-P0003-0100-D02 GeForce 256 32MB AGP VGA Video Card RARE

Try this description on eBay, I already have two Geforce 256, so think someone ells will be more happy with it.

[ph4nt0m]

I think for NV1x architecture the major bottleneck is the memory bandwidth. Fillrate is not that important. Therefore GF 256 DDR will be always faster than any GF2 MX... even OC models like 200/200 MHz Asus V7100/pro. GF4 MX440 is nice, but only 128-bit models... 64-bit is more or less the same like GF2 MX or GF 256 SDR.

Not exactly. GF 256 and GF2 didn't have any Z-buffer optimisations unlike GF3 and newer. Most notably hidden surface removal and Z-buffer compression. They wasted a lot memory bandwidth and fill rate on overdraw, i.e. rendering objects hidden behind other objects visible to the viewer. This is the area where early Radeons were so much better. In addition, memory controllers of GF 256 and GF2 weren't multichannel, i.e. one 128-bit vs. four 32-bit channels. It was of a lower importance since they didn't support pixel shaders, but anyway.

[dries_86]

Dell 9830U nVidia 180-P0003-0100-D02 GeForce 256 32MB AGP VGA Video Card RARE

Try this description on eBay, I already have two Geforce 256, so think someone ells will be more happy with it.

Seems to be right, 180-P0003-0100-D02 . Currently at least 2 for sale on ebay in US.

[The Serpent Rider]

GF 256 and GF2 didn't have any Z-buffer optimisations unlike GF3 and newer.

GeForce 256 had some optimisations with the texture filtering though.

[silikone]

I think for NV1x architecture the major bottleneck is the memory bandwidth. Fillrate is not that important. Therefore GF 256 DDR will be always faster than any GF2 MX... even OC models like 200/200 MHz Asus V7100/pro. GF4 MX440 is nice, but only 128-bit models... 64-bit is more or less the same like GF2 MX or GF 256 SDR.

Not exactly. GF 256 and GF2 didn't have any Z-buffer optimisations unlike GF3 and newer. Most notably hidden surface removal and Z-buffer compression. They wasted a lot memory bandwidth and fill rate on overdraw, i.e. rendering objects hidden behind other objects visible to the viewer. This is the area where early Radeons were so much better. In addition, memory controllers of GF 256 and GF2 weren't multichannel, i.e. one 128-bit vs. four 32-bit channels. It was of a lower importance since they didn't support pixel shaders, but anyway.

Doesn't it still save a write operation upon a failed depth test? That should help on SDR where the four pixel pipelines get bottlenecked by the bandwidth, but the DDR has one of the highest bandwidth-to-fillrate ratios of all NVIDIA cards ever released.

[rasz_pl]

I think for NV1x architecture the major bottleneck is the memory bandwidth. Fillrate is not that important. Therefore GF 256 DDR will be always faster than any GF2 MX... even OC models like 200/200 MHz Asus V7100/pro. GF4 MX440 is nice, but only 128-bit models... 64-bit is more or less the same like GF2 MX or GF 256 SDR.

Not exactly. GF 256 and GF2 didn't have any Z-buffer optimisations unlike GF3 and newer. Most notably hidden surface removal and Z-buffer compression. They wasted a lot memory bandwidth and fill rate on overdraw, i.e. rendering objects hidden behind other objects visible to the viewer. This is the area where early Radeons were so much better. In addition, memory controllers of GF 256 and GF2 weren't multichannel, i.e. one 128-bit vs. four 32-bit channels. It was of a lower importance since they didn't support pixel shaders, but anyway.

Doesn't it still save a write operation upon a failed depth test?

Thats how normal Zbuffer works
What advanced Zbuffer optimizations do is:
-save bandwidth reading Z values (compression, simplest is cached tiling with clever min/max/cleared per tile, more advanced adds actual transparent compression per tile)
-skips fragment shader altogether - saves on all the texture lookup/blending (early-z culling)
-terminate whole triangle after single read (hi-z)
Ati HyperZ marketingwank was all 3 of the above combined