Disclaimer: I am working on asynchronous hardware for 3D graphics, towards my PhD at Adelaide University, Australia.
Only some families of asynchronous hardware suffer from the problems of slow feedback. Typical bundled-data handshaking, as described above, generally does suffer from these problems; however, an approach developed at Adelaide University and known as FeFA manages to remove the bulk of the feedback. It is more similar to synchronous logic than most asynchronous styles, but the performance is generally slightly better (due to lower latency) and the noise and power consumption are both a lot lower.
[For the uninitiated: noise emissions are bad in synchronous circuits due to the switching of the clock - everything happens at once, so you get noise at the clock frequency and its harmonics]
In addition, speed-insensitive designs - for which software synthesis tools, notably the open-source petrify, now exist - do not have typical feedback paths, but each logic block provides its own indications of completion by a different data encoding. This offers the benefits of *no* timing constraints whatsoever, resulting in (theoretically) much easier design processes and a significantly higher level of tolerance to fabrication errors.
As a hardware designer, I'm very pleasantly surprised by the functionality and likely performance of the new chip. The new memory controller architecture and usage optimisations are particularly impressive; the array of new functionality is mind-blowing. However, they still seem to be missing some basic things. The 2D quality is only going to be "the same as GeForce2" - i.e. well below ATI and especially Matrox at high resolutions. There is no multi-monitor support. All the anti-aliasing modes use uniform sampling (which is very bad). The filtering used in anti-aliasing and mipmap generation seems to be plain averaging (i.e. a hideously ugly box filter) - when very little extra effort would permit gaussian or even programmable filters, providing much better image quality. The video features don't stack up to those of ATI's Radeon.
As truly stunning as I find the 3D and memory architecture of the card, it's really going to be difficult to justify buying one unless the machine is used exclusively for games. For anyone with a monitor bigger than 17" it really won't cut the mustard for anything else - same as GeForce and GeForce2. I hope they hurry up with the GeForce3 MX and pray that it's not too badly crippled - no-one seems to want to make a card that's suitable for work _and_ high-end 3D gaming, since Matrox released the G400 back in 1999. Sigh.
This seems to just be limited to ATI... I own a G400 MAX and just yesterday discovered brand-new drivers from Matrox, including three new modes of dual-headed operation (sadly only implemented in 'doze for now, but linux will no doubt follow). This is despite the fact that the card was released over 18 months ago (light-years in graphics terms) and is now obsolete.
ATI's drivers are, in my view, their biggest downside though - NVidia and Matrox both seem to do a far better job, although the former have been criticised for their sluggishness with 2D features (witness TwinView on the GeForce2 MX, which only got fully functional drivers for _any_ OS 6 months after release) and the latter for dodgy OpenGL support, they do seem to have a better focus on the software side of things than ATI. Which is a shame, because until today the Radeon looked to be (hardware-wise) the best thing on the market...
There's really only one chipset worth having at the moment and that's the VIA KT133. Although the performance isn't fantastic, it's better than any of the alternatives until we start seeing DDR mobos hit the shelves (any time now, hopefully). The standard 2.2 series kernels are quite happy with them, and applying the IDE patches to the kernel will give you reasonable performance. The 2.4-test series have this built in.
Of course, if you want 3D to work, that's a whole different kettle of fish:) .
"Well, it's a Matrox card"?? Never mind the fact that the G400 MAX, at time of release, was the fastest 32-bit gaming solution. It wasn't until 6 months later, with the release of the GeForce, that something faster came along.
This card definitely isn't intended for gaming (although it won't totally suck - you can still buy a voodoo3 for instance), but the upcoming G800 - if the information that MURC and others have come up with is correct - looks like it will be a very sweet card for gaming. Also, the Matrox 3D support under linux is still as good or better than any of the others - frame rates aren't as high as GF, but the drivers are open-source, the specs are open, and the stability is far superior. Also, DualHead is supported under linux; NV's TwinView is conspicuous by its absence, and is even missing some features in windoze. And then there's the issue of 3D image quality...
SRAM also requires around six times the chip area of DRAM, so you get only one sixth of the storage per chip. The common SRAM cell uses six transistors to store a single bit; DRAM can do it with one transistor and some carefully grown capacitance.
First up, it's DDR-SDRAM... DDR is just a modified version of current SDRAM design practices in that the clock rate is half the data rate, rather than the full rate. Since the pads (to connect DRAM chips to the circuit board) only support lower bandwidths than inside the chip, if we halve the clock rate it transitions at the same rate as the data. This means that, if the clock goes at the maximum speed supported by the pads, we get data going twice as fast - hence, double data rate. There is no such thing as "DDRAM"...
RDRAM has some very nice design ideas behind it; I think it is good technology and may have a future one day. However, for a number of reasons, its time is not going to be now:
- Because of the fact that the controller design is totally different to what they're used to, Intel have not lived up to their usual performance in the i820 & i840 chipsets. It's not just latency that's holding RDRAM back in the benchmarks. I would expect DDR designs, because of the evolutionary nature, to hit full performance right away.
- Cost is currently way too high given the performance: at double the price of PC133 (because of lower demand, yields, royalties and various issues) it's simply not good value at the moment
- Rambus has managed to alienate just about every other company in the industry through bad PR, and don't get me started on the appropriation of JEDEC standards as their own patented technology...
I think, had things gone differently, it could have a future - there _are_ some good points to the technology, such as lower pin count - but I can't see it becoming widely adopted outside of consoles & embedded systems (where it is best suited) for the foreseeable future.
Slashdot Mirror
Nah, it's not my page - it is a guy that I know from Adelaide Uni though and I let him know in advance that he was in for a /.ing :)
Only some families of asynchronous hardware suffer from the problems of slow feedback. Typical bundled-data handshaking, as described above, generally does suffer from these problems; however, an approach developed at Adelaide University and known as FeFA manages to remove the bulk of the feedback. It is more similar to synchronous logic than most asynchronous styles, but the performance is generally slightly better (due to lower latency) and the noise and power consumption are both a lot lower.
[For the uninitiated: noise emissions are bad in synchronous circuits due to the switching of the clock - everything happens at once, so you get noise at the clock frequency and its harmonics]
In addition, speed-insensitive designs - for which software synthesis tools, notably the open-source petrify, now exist - do not have typical feedback paths, but each logic block provides its own indications of completion by a different data encoding. This offers the benefits of *no* timing constraints whatsoever, resulting in (theoretically) much easier design processes and a significantly higher level of tolerance to fabrication errors.
Linux has support for bad RAM modules, and has for a while. See this HOWTO for how to do it. Windows has no such support.
As a hardware designer, I'm very pleasantly surprised by the functionality and likely performance of the new chip. The new memory controller architecture and usage optimisations are particularly impressive; the array of new functionality is mind-blowing. However, they still seem to be missing some basic things. The 2D quality is only going to be "the same as GeForce2" - i.e. well below ATI and especially Matrox at high resolutions. There is no multi-monitor support. All the anti-aliasing modes use uniform sampling (which is very bad). The filtering used in anti-aliasing and mipmap generation seems to be plain averaging (i.e. a hideously ugly box filter) - when very little extra effort would permit gaussian or even programmable filters, providing much better image quality. The video features don't stack up to those of ATI's Radeon. As truly stunning as I find the 3D and memory architecture of the card, it's really going to be difficult to justify buying one unless the machine is used exclusively for games. For anyone with a monitor bigger than 17" it really won't cut the mustard for anything else - same as GeForce and GeForce2. I hope they hurry up with the GeForce3 MX and pray that it's not too badly crippled - no-one seems to want to make a card that's suitable for work _and_ high-end 3D gaming, since Matrox released the G400 back in 1999. Sigh.
This seems to just be limited to ATI... I own a G400 MAX and just yesterday discovered brand-new drivers from Matrox, including three new modes of dual-headed operation (sadly only implemented in 'doze for now, but linux will no doubt follow). This is despite the fact that the card was released over 18 months ago (light-years in graphics terms) and is now obsolete.
ATI's drivers are, in my view, their biggest downside though - NVidia and Matrox both seem to do a far better job, although the former have been criticised for their sluggishness with 2D features (witness TwinView on the GeForce2 MX, which only got fully functional drivers for _any_ OS 6 months after release) and the latter for dodgy OpenGL support, they do seem to have a better focus on the software side of things than ATI. Which is a shame, because until today the Radeon looked to be (hardware-wise) the best thing on the market...
There's really only one chipset worth having at the moment and that's the VIA KT133. Although the performance isn't fantastic, it's better than any of the alternatives until we start seeing DDR mobos hit the shelves (any time now, hopefully). The standard 2.2 series kernels are quite happy with them, and applying the IDE patches to the kernel will give you reasonable performance. The 2.4-test series have this built in. Of course, if you want 3D to work, that's a whole different kettle of fish :) .
This card definitely isn't intended for gaming (although it won't totally suck - you can still buy a voodoo3 for instance), but the upcoming G800 - if the information that MURC and others have come up with is correct - looks like it will be a very sweet card for gaming. Also, the Matrox 3D support under linux is still as good or better than any of the others - frame rates aren't as high as GF, but the drivers are open-source, the specs are open, and the stability is far superior. Also, DualHead is supported under linux; NV's TwinView is conspicuous by its absence, and is even missing some features in windoze. And then there's the issue of 3D image quality...
http://www.anandtech.com/showdoc.html?i=1311
SRAM also requires around six times the chip area of DRAM, so you get only one sixth of the storage per chip. The common SRAM cell uses six transistors to store a single bit; DRAM can do it with one transistor and some carefully grown capacitance.
First up, it's DDR-SDRAM... DDR is just a modified version of current SDRAM design practices in that the clock rate is half the data rate, rather than the full rate. Since the pads (to connect DRAM chips to the circuit board) only support lower bandwidths than inside the chip, if we halve the clock rate it transitions at the same rate as the data. This means that, if the clock goes at the maximum speed supported by the pads, we get data going twice as fast - hence, double data rate. There is no such thing as "DDRAM"...
RDRAM has some very nice design ideas behind it; I think it is good technology and may have a future one day. However, for a number of reasons, its time is not going to be now:
- Because of the fact that the controller design is totally different to what they're used to, Intel have not lived up to their usual performance in the i820 & i840 chipsets. It's not just latency that's holding RDRAM back in the benchmarks. I would expect DDR designs, because of the evolutionary nature, to hit full performance right away.
- Cost is currently way too high given the performance: at double the price of PC133 (because of lower demand, yields, royalties and various issues) it's simply not good value at the moment
- Rambus has managed to alienate just about every other company in the industry through bad PR, and don't get me started on the appropriation of JEDEC standards as their own patented technology...
I think, had things gone differently, it could have a future - there _are_ some good points to the technology, such as lower pin count - but I can't see it becoming widely adopted outside of consoles & embedded systems (where it is best suited) for the foreseeable future.