PDA

View Full Version : whats next, 128bit?


Pages : 1 [2]

SavagePaladin
01-11-04, 09:12 PM
You guys know Suns working on computers that can calculate fractions or something?

That'd be good if we could get rid of floating point inaccuracy widdit

sytaylor
01-12-04, 02:31 AM
Originally posted by Rob_0126
hehe, so true. :D

Well, the 32 bit processor has had quite a long stretch. Maybe it's time for the 64 bit boys to step up. Then 20 years later, 128 bit'ers :p


See, this is where i kinda disagree, I think the 32bit processors were the first to benefit from a proper stretch. Lets not forget how long a 32bit number is, added to the fact that the way many CPU architectures work (with registers and the MIPS (millions of intructions per second) they can perform), it becomes a lot less difficult to process these large numbers even on a 32bit architecture.

The true advantage is when working with yet larger numbers, such as those demanded by intensive research applications currentley run on massive server farms. This kind of power is now almost required at the home level, but mainly the move to 64bit allows the use of greater amounts of ram.

We have been spoiled by acheivements in the hardware industry as software developers, and as such i feel software has a much greater role to play in current pc performance. However, this is an addtitude that will take time to change with the current consumer demand for hardware.

my £0.02

-=DVS=-
01-12-04, 03:14 AM
Originally posted by SnakeEyes
I have to correct myself. The 512 references the true memory transfer capability. Parhelia is a 512 bit chip, using 256bit DDR (2x256bit transfers per clock). The GeForce cards from the GeForce2 on, as well as the ATI cards starting with the original Radeon, all have 256bit memory buses, using 128bit DDR memory. Some cards released by these companies since then have been "value" oriented, and so have skimped on lesser memory (128bit SDR, effectively 128bit memory buses, even a couple 64bit SDR / DDR based cards).

I stand by the crossbar-type memory controllers of later GPUs though- these actually subdivide the GPUs memory controller to allow access to smaller chunks of data as needed, while still using the larger overall bus size.

All other things being equal, the larger bus size (128, 256, 512), the higher the theoretical memory bandwidth available. Faster memory clocks combined with higher bus widths equals greater data transfer capability. The only problem with this is that it also equals much greater costs, to the point of diminishing returns. That's also why both nvidia and ATI have gone to such lengths to implement the bandwidth saving tech into their GPUs- making more effective use of available bandwidth can provide much of the same benefit as providing the next level of bandwidth. Despite theoretically having 2x the bandwidth available, Parhelia is very inefficient about using it. So everything from GF4 on from nvidia and ATI pretty much trounces the Parhelia in overall performance.

Yes Parhelia is first 512 bit chip but that means nothing if it have no bandwidth saveing techniques no compression :o if it had atleast what GF3 had it would be more powerfull chip.

SH0DAN
01-12-04, 06:58 AM
the "256" in Geforce256 was in reference to the 256 bit 2D engine.

nutball
01-12-04, 10:05 AM
Originally posted by SavagePaladin
You guys know Suns working on computers that can calculate fractions or something?

That'd be good if we could get rid of floating point inaccuracy widdit

Interval arithmetic you mean? As I understand it interval arithmetic doesn't eliminate floating-point inaccuracies, it merely tells you what they are.

IIRC for each operation you might take the result and round it up, and also round it down, and remember both values. This gives you an interval in which your "correct" answer lies. You then propagate these bounds through all future operations, doing the same thing each time. By the time you've finished you can say "I don't know precisely what my answer is, but I know for sure it lies between the following two values".

If you want infinitely precise arithmetic in the general case, you surely need to have an infinite number of bits (digits) to represent your numbers. Anything else just doesn't make sense.

SavagePaladin
01-12-04, 01:21 PM
I meant fractions....I'm trying to find what I read, I be lookin.

SavagePaladin
01-12-04, 02:30 PM
Heh, I can't even find it. Nevermind then :p I thought I could find everything.

Uttar
01-12-04, 02:32 PM
Originally posted by SH0DAN
the "256" in Geforce256 was in reference to the 256 bit 2D engine.

Not exactly.
X = pipelines * (max color depth + max Z/Stencil depth)
X = 4 * (32+32)
X = 4 * 64
X = 256

Just marketing though :)


Uttar

bsdgeek
01-12-04, 03:44 PM
I thought Parhelia's bitness came from 4x 128bit vertex shaders.

Rob_0126
01-12-04, 04:14 PM
Originally posted by nutball

.....If you want infinitely precise arithmetic in the general case, you surely need to have an infinite number of bits (digits) to represent your numbers. Anything else just doesn't make sense.

How many decimal places do you really need to calculate an accurate model?

I think 3.14159 is good enough :p

Robert

SH0DAN
01-12-04, 04:46 PM
[i]
Just marketing though :)


Uttar [/B]


Isnt it all :p

SavagePaladin
01-12-04, 05:56 PM
Originally posted by Rob_0126
How many decimal places do you really need to calculate an accurate model?

I think 3.14159 is good enough :p

Robert
I assume you were trying to be funny, because if you multiply an inaccurate number with an inaccurate number, you have a more inaccurate number. So when dealing with something rounded, like a repeating or just really freakin long decimal, your inaccuracies are going to get much bigger, especially given that more than one operation will be performed on that number.

Rob_0126
01-12-04, 07:03 PM
Originally posted by SavagePaladin
I assume you were trying to be funny, because if you multiply an inaccurate number with an inaccurate number, you have a more inaccurate number. So when dealing with something rounded, like a repeating or just really freakin long decimal, your inaccuracies are going to get much bigger, especially given that more than one operation will be performed on that number.

Well, sure you would want a very accurate number, but at what point do you stop, and consider what you have, to be it?

Take pie for instance, it's endless, where do you stop? :)

Robert

sytaylor
01-13-04, 02:19 AM
Originally posted by Rob_0126

Take pie for instance, it's endless, where do you stop? :)

Hate to cop out but, it depends. What are you modelling, what are you using it for.. etc.

If modelling massive outdoor envrionments full of curved polygons, or spheres within spheres, pi had better be pretty accurate. If you were designing something that you were then going to make out of cardboard then as you say 3.14159 would be adequate.

SavagePaladin
01-13-04, 02:52 AM
You'd just think that 1/27867 could be represented as I just typed it instead of a huge decimal.

nutball
01-13-04, 06:19 AM
Originally posted by SavagePaladin
You'd just think that 1/27867 could be represented as I just typed it instead of a huge decimal.

Even if you manipulate fractions, you still don't get infinite precision. You've got one integer divided by another integer, but you still end up requiring integers of infinite length if you want infinite precision in the general case.

After all floating-point numbers as represented by computers are simply two integers flying in close formation.

Rob_0126
01-13-04, 07:48 AM
Too bad computers cant do division like we do. (writing it out )

Robert

SavagePaladin
01-13-04, 09:01 AM
Originally posted by nutball
Even if you manipulate fractions, you still don't get infinite precision. You've got one integer divided by another integer, but you still end up requiring integers of infinite length if you want infinite precision in the general case.

After all floating-point numbers as represented by computers are simply two integers flying in close formation.
I noticed this already, as I'm not stupid, but in such an example as I showed you, the fraction could store as a much smaller number than the decimal, and performing operations on it would result in...another small fraction.

It's just interestin