nVidia GPU/CPU?

[|JuiceZ|]

Do you guys think nVidia is gearing up to take on the big boys here in the next few yrs? They're always talking about eliminating the cpu...?

I personally just hope they don't bite off more than they can chew...

[SavagePaladin]

It's very possible they could make a processor capable of all tasks, or a setup such, but I can't honestly say I care. It won't be for a while.

[netviper13]

Right now they don't have enough hardware engineers to take on such a task, so if they do go on a hiring spree, I think we can assume what's going to happen, lol.

[Sgt. Slaughter]

nVidia is too friendly with AMD right now. I think they may become AMD's main chipset maker, but not make CPU's.

[Matthyahuw]

I don't think they will make a CPU...at least not in the next 5years

[Uttar]

I doubt they'll EVER make CPUs. Their corporate strategy is *exactly* the opposite. nVidia is a company specialized in special-purpose processors. CPUs are general-purpose processors.

However, i really think that in a few years, they'll do other special-purpose processors ( What about a network processor, able to compress/decompress packets to make internet faster? Sure, right now broadband is sufficent, but a LOT more could be done with 10x the bandwidth )


Uttar

[SavagePaladin]

10x is a hard sell when dealing with lossless...
they already make a MCP and will be sure to evolve on it, but thats asking a bit much

[Uttar]

Originally posted by SavagePaladin
10x is a hard sell when dealing with lossless...
they already make a MCP and will be sure to evolve on it, but thats asking a bit much

Well, i pretty much meant 10x in VERY optimal cases

And that's REALLY possible. Take www.tomshardware.com

I took the main html file ( 55k ) and zipped it ( 11k )

Zipping, if done on a special purpose processor, could take more power, maybe putting that file up to 8k. In even more optimal cases, 10x might be possible.


So, considering we'd have 2 times today bandwidth, we could evantually have about 7-8 times today "effective" bandwidth with that.


Uttar

[SavagePaladin]

It is pretty hard to recompress data with any results in real time

[SurfMonkey]

Packet transmission already utilises compression (headers etc). In a simple message you have a relatively small piece of data and some fat headers that describe it, state where it's going, who it's from and what it's CRC value should be when it arrives at its destination and a few other bits and bobs.

If your computer was constantly having to compress and decompress the many thousands of packets and headers coming in and going out, it probably wouldn't have time to do anything else. It's faster not to compress the headers fully.

Also you have to have a lossless algortithm, like RLE or Huffman Encoding, which is capable for binary and non-binary data and is error restistant. Also if the data being sent was already compressed, a zip file say, then the end result could be a larger data set than you started with.

Besides all the compression would be doing is giving you extra bandwidth and it's easier to increase the bandwidth physically currently.

[Uttar]

Originally posted by SurfMonkey
If your computer was constantly having to compress and decompress the many thousands of packets and headers coming in and going out, it probably wouldn't have time to do anything else. It's faster not to compress the headers fully.

And that's EXACTLY why a special-purpose processor would be helpful.


Uttar

[SurfMonkey]

Well most network cards already do or are capable of some form of header compresssion. Though most ISPs don't seem to use this feature due to the danger of data corruption and also due to the overhead of the compression/decompression. If the work was done by a separate chip on the network card you would still run the danger of having to stall the connection whilst the data was decompressed and checked for errors.

On a busy network that would have the effect of narrowing the bandwidth, especiially if the connection was bad and the data contained alot of errors. You would have to decompress it first before you found out, currently if the MD5 or CRC doesn't compute the packet is instantly discarded and a request for a new packet is sent.

On tight packet intranets, like I use at work, there is a form of compression used which was developed in house and it works very well until you want to use the internet and then you realise just how slow it can be.

The other down side would be the extra cost of having extra harwdare on a card, and the whole uphill battle of developing a standard to use.