In my opinion, 2x64 is a lot more than 0x64. </strong><hr></blockquote>
Well, to be fair, this should read "1x64" rather than "0x64" (the G4 does have a DP FPU).
[quote]<strong>
Vectorization is not a big issue, because scientific calculations already are vectororized for either supercomputers, clusters or P4s (where everything dp is done in SIMD).</strong><hr></blockquote>
Well, supercomputers probably have much longer vectors in the first place, so you'd have to rewrite again for AltiVec, and a program designed for a cluster won't help much for an on-chip SIMD unit either.
Since SSE2 uses the same vector types (assuming 4x32FP SIMD), it should be possible to at least partially reuse code for it.
[quote]<strong>
A halfword has to be aligned (RazzFazz) to 16 bits and a byte to 8 bits. So you can still have your 32 bytes in one 256 bit cache block. This has absolutely nothing to do with register size.
</strong><hr></blockquote>
Hm, not sure, but I thought I remembered that, at least for some architectures, reading byte-aligned values on a 32bit machine takes longer than reading ones aligned to the "native" size.
Also, couldn't early Alphas not read individual bytes from memory at all (i.e. you had to read a quadword and mask out the byte you were interested in)? Damn, definitely need to beef up my long-term memory
[quote]<strong>He was talking about function calls, and so was I (true, context switches are expensive, but I wasn't addressing them).</strong><hr></blockquote>
Oops, sorry, must have mixed up some quotes in that case.
[quote]<strong>I still don't think it accounts for "a few percent on most benchmarks", I'd say a fraction of one.
</strong><hr></blockquote>
As stated above, I had the quoted Darwin-Developerment-posting in mind.
Well, I was under the impression that the VRSAVE register was added exactly because the guys at Motorola thought that having to save / restore the whole vector register file on each context switch was too much.
Also, that was pretty much what Godfrey van der Linden (Apple employee) said on the Darwin Development List on, uh, wait, March 12th:
"In fact the kernel has made it difficult to get access to floating
point and altivec mostly for efficiency reasons.
I the kernel used these engines we would need to dump the entire
altivec and floating point register sets every time we took a kernel
transition from user land. As these register files are quite large
this is a big performance hit."</strong><hr></blockquote>
Yes, this is a bit of a fuzzy case -- these transitions into the kernel are really function calls to the operating system, but they use a "software interrupt" mechanism which requires a context switch of sorts. These calls can be very frequent and, as you quoted, the repeated cost of saving the complete context would be brutal. VRSAVE ensures that only the registers you are using get saved, but it is up to the OS to enforce that and if you are using any of those registers they still need to be saved. One upside is that vector code doesn't usually make too many operating system calls.
Anyhow, I forgot to explicitly mention this case so thanks for pointing it out.
One added bonus for this kind of a setup might be finally getting rid of the GPU-specific memory, which has reached epic proportions (128 MBytes of RAM just for the graphics engine!!). This would make the graphics memory available to the main system when not needed by the graphics, and system memory available to the graphics when needed. Much more flexible.
</strong><hr></blockquote>
Much more flexible indeed, but also a hell of a lot more expensive than current designs (those 128 MB VRAM you mentioned are considrably faster than standard RAM, and consequently are also much much more expensive).
Also, this might kill expandability. There are reasons why current graphic cards don't feature upgradeable VRAM any more. Beyond a certain speed, you can't stick that memory on an exchangeable module any more, but rather have to solder it onto the board directly (at least with current tech). Given that RAM is probably the most efficient and frequent upgrade to computers, I don't think this would be a good way to go.
<strong>Much more flexible indeed, but also a hell of a lot more expensive than current designs (those 128 MB VRAM you mentioned are considrably faster than standard RAM, and consequently are also much much more expensive).
Also, this might kill expandability. There are reasons why current graphic cards don't feature upgradeable VRAM any more. Beyond a certain speed, you can't stick that memory on an exchangeable module any more, but rather have to solder it onto the board directly (at least with current tech). Given that RAM is probably the most efficient and frequent upgrade to computers, I don't think this would be a good way to go.
</strong><hr></blockquote>
True, but the RAM on graphics boards isn't really much faster than the RAM on the motherboard (i.e. its DDR266 or DDR333). The difference is in the organization... I wrote something on that earlier, was it this thread?
True, but the RAM on graphics boards isn't really much faster than the RAM on the motherboard (i.e. its DDR266 or DDR333). The difference is in the organization...</strong><hr></blockquote>
Are you sure? On first glance, most publications claim "650MHz memory clock" for the new GF4 Ti4600 boards, with between 2 and 3 ns access time. Even if these are in fact only DDRed 325MHz, that would still be almost twice as fast as DDR333.
[quote]<strong>I wrote something on that earlier, was it this thread?
Are you sure? On first glance, most publications claim "650MHz memory clock" for the new GF4 Ti4600 boards, with between 2 and 3 ns access time. Even if these are in fact only DDRed 325MHz, that would still be almost twice as fast as DDR333.</strong><hr></blockquote>
Yeah, you're right about that -- their latest boards do claim a 650 MHz memory clock (I had only seen their geForce4 architecture stuff, not the actual clock specs). Wow, I knew their memory architecture had improved but I didn't realize by how much. Unless they are doing some weird arithmetic, that is (wouldn't be the first time). But saying 650 MHz memory clock is pretty clear.
I'm rather curious about this memory, actually... if it is actually clocked that fast then it may be plausible for Apple to start using it in the rumoured G5 machines since they will be tightly coupled to their memory just like the GPUs are. nVidia is shipping 128MBytes of this stuff on their $500 cards so price-wise it might not be out of reach for Apple's top machines. All sorts of memory expansion issues, of course.
They've also got this fancy cross-bar memory controller which would need to be replicated in the CPU's memory controller before a true unified memory model could happen. Who knows, maybe the future processors will use the GPU's memory controller and talk to it via HyperTransport.
I just want to say, that I don't understand why you post just to have the last word, even if it's totally off topic. Do you need to increase your post count? Congrats, I lose big time.
programmer:
me: Correct, if you use larger types. However, I was talking about...
you: Well, if nothing else, you don't have a choice about the size of your pointers -- they will be twice as big. This includes the vtable..
Do you really think I don't realize that a 64 bit architecture actually means 64 bit pointers? I was not talking (do you read the things you quote?) about biger types (which are either used because you have to(pointers), because you're lazy or because the compiler choses to use them (int = 64bit) and indeed do use more bandwith). My post was about reading characters from memory, addressing Amorph's earlier post. It's a pleasure to quote it a third time:
"it can slow things down, because the minimum size of the data a 64 bit processor reads is 64 bits, and if you're reading in 8 bit ASCII characters then you're pulling 8 times the bandwidth the data actually requires across the bus,..."
and here we go again, maybe this time...:
"it can slow things down, because the minimum size of the data a 64 bit processor reads is 64 bits, and if you're reading in 8 bit ASCII characters then you're pulling 8 times the bandwidth the data actually requires across the bus,..."
And as before, my point is that this is not a difference between 32 and 64 bit processors. Because you would just not (ASCII, not pointers )PULL MORE DATA ACROSS THE BUS than you do now (even if it was slower from L1 cache to the register (RazzFazz), which it isn't!!!, this would still not be the issue here (BUS!)).
RazzFazz:
When we are discussing whether to implement 64bit fp altivec!! support, why do you write:
"Well, to be fair, this should read "1x64" rather than "0x64" (the G4 does have a DP FPU)."
??? We both know, that the G4 does not have any dp fp support in altivec. If I was talking about the whole processor, I would have written 3x64 > 1x64, isnt' that obvious?
you:
Adding 2x64 DP SIMD capabilities to AltiVec is pretty useless...
me:
2x64 is a lot more than 0x64
It was of course all SIMD related! Now, we don't have to agree on everything, but please read the posts and their context a bit closer before posting. Thank you very much.
BTW: "(assuming 4x32FP SIMD)" : I was of course talking about 2x64 SIMD, not 4x32 which is already implemented.
I know this is off subject somewhat but I'd like to know if the G5 is a multicore chip and if it is, how many cores are used in it.
I've been looking at the transistor counts on the G4, G4e, and G5 and if the G5 is made from G4 cores, it looks like it could have up to 4 G4 cores on it based on the transistor count.
I used the G5 transistor count posted on geek.com so I hope their numbers are fairly accurate.
<strong>123, I think you need to re-read before you try to pummel some intelligent posts. Me thinks you just like to selectively chip away in frustration even when the posts were correct. It's beginning to look like a trend... <img src="graemlins/oyvey.gif" border="0" alt="[No]" /> </strong><hr></blockquote>
I don't know, seems like 123 is correect in that people didn't read his post before answering.
For example:
and here we go again, maybe this time...:
"it can slow things down, because the minimum size of the data a 64 bit processor reads is 64 bits, and if you're reading in 8 bit ASCII characters then you're pulling 8 times the bandwidth the data actually requires across the bus,..."
And as before, my point is that this is not a difference between 32 and 64 bit processors. Because you would just not (ASCII, not pointers )PULL MORE DATA ACROSS THE BUS than you do now (even if it was slower from L1 cache to the register (RazzFazz), which it isn't!!!, this would still not be the issue here (BUS!)).
which essentially says your reading 64-bits of the bus everytime anyway (even on a 32-bit processor with a 64-bit bus)
You your self mentioned servers, and the words Unix, and Server go togeter like peanut butter, and jelly. Ruuun Foorrest!!! So 64bit seems like natural step towards a brighter future if you ask me.</strong><hr></blockquote>
quite possibly the hardest thing I've had to read since madtool and da truth train....maybe I need to get to bed though? I've been tired all day....too many damn commas ...and I use to many "..." I used to use too many commas though.
Hi. I noticed that all you people seem to think 64-bit addressing is good for is more RAM. it's not.
Probably the most important upgrade made feasible by a 64-bit computer is 64-bit A/V. remember how incredibly cool it was. and how much nicer it looked when you installed the Radius card in your Mac II. and got 24-bit video? remember how the 660AV and 840AV. due to their 16-bit audio synthesizer/digitizer. sounded so much better?
If any of you have ever used(I have ) a high-end(The ones equipped with 48-bit A/V I/O) SGI machine. and switched between the 48-bit and 24-bit A/V modes. you'll notice a dramatic difference. and the multimedia/graphics professionals that are Apple's bread and butter will DEFINITELY notice.
The key here is not so much the G5(It's pretty much already here) or a 64-bit version of Mac OS X(basically inevitable). the key are those lazy audio/video hardware makers. and what Apple chooses to put on their motherboards. remember how long it was before Apple started shipping machines with 24-bit graphics hardware? notice how Macs STILL don't use 24-bit audio hardware? if Apple is dumb enough to ship G5 machines with 64-bit Mac OS X. and no 48-64-bit A/V I/O. we're doomed. this will be the big stumbling block for 64-bit Macs.
As for compatability. much like every other RISC architecture's bit depth transition(MIPS, POWER, Alpha, SHx, ARM etc?) the G5 will run both 64-bit and totally unmodified 32-bit code concurrently and without any speed penalty whatsoever.
And as for a definition of "x-bit". my definition is that when all parts of a CPU operate at and/or above a certain bit depth. the CPU as a whole can be considered as operating at that bit depth.
For example. while the external bus of the G4 runs at 64-bit, the VPU runs at 128-bit and the FPU also runs at 64-bit. the IPU only operates at 32-bit. the G4 is thusly a 32-bit CPU.
I just want to say, that I don't understand why you post just to have the last word, even if it's totally off topic. Do you need to increase your post count? Congrats, I lose big time.
</strong><hr></blockquote>
Chill, dude.
Why so aggessive?
[quote]<strong>
RazzFazz:
When we are discussing whether to implement 64bit fp altivec!! support, why do you write:
"Well, to be fair, this should read "1x64" rather than "0x64" (the G4 does have a DP FPU)."
??? We both know, that the G4 does not have any dp fp support in altivec. If I was talking about the whole processor, I would have written 3x64 > 1x64, isnt' that obvious?
</strong><hr></blockquote>
I thought we were talking about how to catch up in DP FP power, SIMD or not (see my and programmer's above posts regarding "rather 2xscalar DP than Altivec DP"). In fact, you said yourself that "You could add some additional FPUs or whatever, I don't really care."
[quote]<strong>
you:
Adding 2x64 DP SIMD capabilities to AltiVec is pretty useless...
me:
2x64 is a lot more than 0x64
It was of course all SIMD related! Now, we don't have to agree on everything, but please read the posts and their context a bit closer before posting. Thank you very much.
</strong><hr></blockquote>
Well, again, you said "You could add some additional FPUs or whatever, I don't really care.", and that doesn't sound like "we're exclusively talking SIMD here" to me very much.
[quote]<strong>BTW: "(assuming 4x32FP SIMD)" : I was of course talking about 2x64 SIMD, not 4x32 which is already implemented.</strong><hr></blockquote>
and that doesn't sound like "we're exclusively talking SIMD here" to me very much.
<hr></blockquote>
Ok, I see your point. Yes, I said, that I don't really care, but you said, that SIMD was not an option, so I was defending the SIMD idea, because we already agreed on additional FPUs. I was actually quoting your 2x64 (you were talking exclusively about SIMD in that sentence), but I agree that you could read that either way, misunderstanding on both sides, my apologies.
Why so aggessive?
Because I really was/am frustrated. By now, I wanted to post only a few(3-4) times. But because nobody seems to be able to leave something just there, even if it is undisputable (I think ;-), I had to quote the same things (64 bit bus, funnel theory(other thread)) several times again and again... Then, you tell me Programmer wasn't talking about functions, even though I've even quoted the sentence, then he writes about bigger types, although that has nothing to do with what I was saying and he even repeats that point. After that, you come up with 1x64, although I wasn't talking abot the fpu (from my point of view)... I felt I had to ask people to read closer before posting a response, but I agree that it sounded too aggressive.
AirSluf:
[quote]
Razz and Programmer both gave pretty good explanations in their original posts and they have a long standing track record of low bull-shit high content posting. Someone else has a 2 thread record of low-fact high-warble responses. Which makes more sense to you? <hr></blockquote>
I agree on their track record, but I also think people should read first what other people have written and think about it before posting answers, no matter their name/knowledge/track record/reputation.
(Sorry everyone, this is from another thread, not even hardware related)
Same to you actually, how could you tell me that I was basically saying funnels are completely "un-needed"? If you had read my posts on that subject, you would have noticed that I was never talking about funnels in general, just that they're not reponsible for the big finder problems on SP machines. And about that "low-fact" responses: At least my facts are related to the topic and I'm not talking about jacobians. I also don't just come up with some stuff I've read in a paper or book even if it's irrelevant (as you do), just to show off my tremendous knowledge. (BTW: it would have been pretty easy to dismiss Whyatt's main argument, if you understood funnels, but I think you don't).
<strong>Probably the most important upgrade made feasible by a 64-bit computer is 64-bit A/V. remember how incredibly cool it was. and how much nicer it looked when you installed the Radius card in your Mac II. and got 24-bit video? remember how the 660AV and 840AV. due to their 16-bit audio synthesizer/digitizer. sounded so much better?</strong><hr></blockquote>
Well, this is pretty much similar to the memory size argument: Most people are well capable of seeing a difference between a real life picture or sound and its 8bit digitized equivalent. The same is not true anymore if you go to 24bit or 16bit/44kHz resolutions, respectively (and even less so for 24/96 audio). Unless our eyes and ears suddenly go through an evolutionary quantum leap, there's no point in having resolutions that are way beyond what our sensory organs can discern.
Also, there's little point in having huge internal resolutions, when the interfaces are the quality bottleneck. Most audio DACs and ADCs on the market today, while technically featuring 24bit/96kHz, are far from even coming close to the theoretical SNR allowed by that. Similarly, current LCDs are limited to 24 bit colors at most, and even if this was just a limitation of the interface circuits inside the screen (as opposed to the panel itself), it still couldn't make use of higher bit depths.
[quote]<strong>If any of you have ever used(I have ) a high-end(The ones equipped with 48-bit A/V I/O) SGI machine. and switched between the 48-bit and 24-bit A/V modes. you'll notice a dramatic difference. and the multimedia/graphics professionals that are Apple's bread and butter will DEFINITELY notice.
</strong><hr></blockquote>
Well, since I haven't actually used any of those, I'll have to believe you on this matter.
One plausible explanation I could think of is that 24 bits per pixel, while featuring >16mio colors (more than you could put onto a single screen at once), only allow for 256 shades of every color component (red, green, blue) and consequently only 256 gray scales too. So in case you have a mainly monochromatic image (like a gray scale one), that limit would probably become apparent, whereas 16 bits per color component (i.e. 48bpp) would allow for a much more realistic representation.
On a side note, using AltiVec, the G4 could do 64bpp gfx already today (in fact, it could handle two such pixels per instruction), or even 128bpp (32 bit int or FP per color component).
Concerning audio, though, I'm pretty sure that a 32bit FP representation as used in OS X should be enough.
<strong>Well, this is pretty much similar to the memory size argument: Most people are well capable of seeing a difference between a real life picture or sound and its 8bit digitized equivalent. The same is not true anymore if you go to 24bit or 16bit/44kHz resolutions, respectively (and even less so for 24/96 audio). Unless our eyes and ears suddenly go through an evolutionary quantum leap, there's no point in having resolutions that are way beyond what our sensory organs can discern.</strong><hr></blockquote>
I doubt that. try(If you have a large monitor set at a high resolution) popping open Photoshop and do a large, simple gradient. notice the slight striation and dithering? now try this: get a photograph. and start doing a bunch of brightness/contrast/hue/saturation-type adjustments. notice the loss of detail and posterization effect? these sorts of things matter big time to media professionals. and as for the debate over higher bit depth audio. go to a DVD-Audio or Super Audio-CD site. you'll get an earfull(Heh heh?).
[quote]Originally posted by RazzFazz:
<strong>Also, there's little point in having huge internal resolutions, when the interfaces are the quality bottleneck. Most audio DACs and ADCs on the market today, while technically featuring 24bit/96kHz, are far from even coming close to the theoretical SNR allowed by that.</strong><hr></blockquote>
Really? have you checked out your PowerMac? how about your DVD player? looked into your DV camcorder? I'd be willing to bet that the formermost has a 16-bit audio I/O set-up. while the latter two both bear mere 10-bit audio hardware.
[quote]Originally posted by RazzFazz:
<strong>Similarly, current LCDs are limited to 24 bit colors at most, and even if this was just a limitation of the interface circuits inside the screen (as opposed to the panel itself), it still couldn't make use of higher bit depths.</strong><hr></blockquote>
Emphasis on the "Current". try hooking an older analog LCD to a good SGI/HP/Compaq/IBM etc. machine. this is why I think digital I/O components(Read: those stupid USB speakers and ADC monitors Apple makes) are a bad idea.
[quote]Originally posted by RazzFazz:
<strong>Well, since I haven't actually used any of those, I'll have to believe you on this matter.
One plausible explanation I could think of is that 24 bits per pixel, while featuring >16mio colors (more than you could put onto a single screen at once), only allow for 256 shades of every color component (red, green, blue) and consequently only 256 gray scales too. So in case you have a mainly monochromatic image (like a gray scale one), that limit would probably become apparent, whereas 16 bits per color component (i.e. 48bpp) would allow for a much more realistic representation.</strong><hr></blockquote>
Yup. whereas 24-bit only has around sixteen million(16,777,216) colors, 32-bit can theoretically do four billion(4,294,967,296). 48-bit can do up to two hundred and eighty one trillion(281,474,976,710,656). and full 64-bit can do over a whopping three hundred and forty duodecillion(340,282,366,920,938,463,463,374,607,431,768,211,0 00)! the capability to easily fumble around with such immense numbers would bring the I/O quality up so high as to please even the most particular user. and the power of high bit depth AD/DA circuitry could be tapped in a less CPU taxing fashion with palettes(Remember how a lot of games could get WAY more than 256 colors on early Macs? they did this by selecting 256 individual colors out of a static 16M color palette).
[quote]Originally posted by RazzFazz:
<strong>On a side note, using AltiVec, the G4 could do 64bpp gfx already today (in fact, it could handle two such pixels per instruction), or even 128bpp (32 bit int or FP per color component).</strong><hr></blockquote>
Using AltiVec that is. can you say "2x integer speed penalty"? like I said before. you need AT LEAST 64 bits throughout ALL of the CPU for maximum speed.
[quote]Originally posted by RazzFazz:
<strong>Concerning audio, though, I'm pretty sure that a 32bit FP representation as used in OS X should be enough.</strong><hr></blockquote>
That's what they said about 16-bit CDs. compare a 32-bit signal to an analog(A good one) signal on an oscilloscope. you'll notice tiny plateau-like steps in the digital signal. 32-bit is good. but 48-bit. or better yet. 64-bit audio is quite a bit better.
That's what they said about 16-bit CDs. compare a 32-bit signal to an analog(A good one) signal on an oscilloscope. you'll notice tiny plateau-like steps in the digital signal. 32-bit is good. but 48-bit. or better yet. 64-bit audio is quite a bit better.
What you say is true in the absolute, but there is no need of a 24 bit audio if the analogic conversion , amplification , and the HP are lame.
I doubt that we can see a difference when we ear a 16 bit audio signal compared to even a 64 bit signal on a basic HP (like the lame built-in HP of the tower). The problem is not coming from an huge prize difference between a 24 bits audio chipset and a 16 bit one, but from the huge difference of prize, between a standart qualities of amplifications and HP, and a very good one.
This is the mean reason why in the domain of HI-FI there is so huge difference of prizes. If you don't believe me just go in an auditorium and just try some different stuffs (if you are an audio pro, i don't need to convice you on that particular subject)
Comments
<strong>
In my opinion, 2x64 is a lot more than 0x64. </strong><hr></blockquote>
Well, to be fair, this should read "1x64" rather than "0x64" (the G4 does have a DP FPU).
[quote]<strong>
Vectorization is not a big issue, because scientific calculations already are vectororized for either supercomputers, clusters or P4s (where everything dp is done in SIMD).</strong><hr></blockquote>
Well, supercomputers probably have much longer vectors in the first place, so you'd have to rewrite again for AltiVec, and a program designed for a cluster won't help much for an on-chip SIMD unit either.
Since SSE2 uses the same vector types (assuming 4x32FP SIMD), it should be possible to at least partially reuse code for it.
[quote]<strong>
A halfword has to be aligned (RazzFazz) to 16 bits and a byte to 8 bits. So you can still have your 32 bytes in one 256 bit cache block. This has absolutely nothing to do with register size.
</strong><hr></blockquote>
Hm, not sure, but I thought I remembered that, at least for some architectures, reading byte-aligned values on a 32bit machine takes longer than reading ones aligned to the "native" size.
Also, couldn't early Alphas not read individual bytes from memory at all (i.e. you had to read a quadword and mask out the byte you were interested in)? Damn, definitely need to beef up my long-term memory
[quote]<strong>He was talking about function calls, and so was I (true, context switches are expensive, but I wasn't addressing them).</strong><hr></blockquote>
Oops, sorry, must have mixed up some quotes in that case.
[quote]<strong>I still don't think it accounts for "a few percent on most benchmarks", I'd say a fraction of one.
</strong><hr></blockquote>
As stated above, I had the quoted Darwin-Developerment-posting in mind.
Bye,
RazzFazz
[ 04-07-2002: Message edited by: RazzFazz ]</p>
<strong>
Well, I was under the impression that the VRSAVE register was added exactly because the guys at Motorola thought that having to save / restore the whole vector register file on each context switch was too much.
Also, that was pretty much what Godfrey van der Linden (Apple employee) said on the Darwin Development List on, uh, wait, March 12th:
"In fact the kernel has made it difficult to get access to floating
point and altivec mostly for efficiency reasons.
I the kernel used these engines we would need to dump the entire
altivec and floating point register sets every time we took a kernel
transition from user land. As these register files are quite large
this is a big performance hit."</strong><hr></blockquote>
Yes, this is a bit of a fuzzy case -- these transitions into the kernel are really function calls to the operating system, but they use a "software interrupt" mechanism which requires a context switch of sorts. These calls can be very frequent and, as you quoted, the repeated cost of saving the complete context would be brutal. VRSAVE ensures that only the registers you are using get saved, but it is up to the OS to enforce that and if you are using any of those registers they still need to be saved. One upside is that vector code doesn't usually make too many operating system calls.
Anyhow, I forgot to explicitly mention this case so thanks for pointing it out.
<strong>
One added bonus for this kind of a setup might be finally getting rid of the GPU-specific memory, which has reached epic proportions (128 MBytes of RAM just for the graphics engine!!). This would make the graphics memory available to the main system when not needed by the graphics, and system memory available to the graphics when needed. Much more flexible.
</strong><hr></blockquote>
Much more flexible indeed, but also a hell of a lot more expensive than current designs (those 128 MB VRAM you mentioned are considrably faster than standard RAM, and consequently are also much much more expensive).
Also, this might kill expandability. There are reasons why current graphic cards don't feature upgradeable VRAM any more. Beyond a certain speed, you can't stick that memory on an exchangeable module any more, but rather have to solder it onto the board directly (at least with current tech). Given that RAM is probably the most efficient and frequent upgrade to computers, I don't think this would be a good way to go.
Bye,
RazzFazz
<strong>Much more flexible indeed, but also a hell of a lot more expensive than current designs (those 128 MB VRAM you mentioned are considrably faster than standard RAM, and consequently are also much much more expensive).
Also, this might kill expandability. There are reasons why current graphic cards don't feature upgradeable VRAM any more. Beyond a certain speed, you can't stick that memory on an exchangeable module any more, but rather have to solder it onto the board directly (at least with current tech). Given that RAM is probably the most efficient and frequent upgrade to computers, I don't think this would be a good way to go.
</strong><hr></blockquote>
True, but the RAM on graphics boards isn't really much faster than the RAM on the motherboard (i.e. its DDR266 or DDR333). The difference is in the organization... I wrote something on that earlier, was it this thread?
<strong>
True, but the RAM on graphics boards isn't really much faster than the RAM on the motherboard (i.e. its DDR266 or DDR333). The difference is in the organization...</strong><hr></blockquote>
Are you sure? On first glance, most publications claim "650MHz memory clock" for the new GF4 Ti4600 boards, with between 2 and 3 ns access time. Even if these are in fact only DDRed 325MHz, that would still be almost twice as fast as DDR333.
[quote]<strong>I wrote something on that earlier, was it this thread?
</strong><hr></blockquote>
Nope, not in here...
Bye,
RazzFazz
[ 04-07-2002: Message edited by: RazzFazz ]</p>
<strong>
Are you sure? On first glance, most publications claim "650MHz memory clock" for the new GF4 Ti4600 boards, with between 2 and 3 ns access time. Even if these are in fact only DDRed 325MHz, that would still be almost twice as fast as DDR333.</strong><hr></blockquote>
Yeah, you're right about that -- their latest boards do claim a 650 MHz memory clock (I had only seen their geForce4 architecture stuff, not the actual clock specs). Wow, I knew their memory architecture had improved but I didn't realize by how much. Unless they are doing some weird arithmetic, that is (wouldn't be the first time). But saying 650 MHz memory clock is pretty clear.
I'm rather curious about this memory, actually... if it is actually clocked that fast then it may be plausible for Apple to start using it in the rumoured G5 machines since they will be tightly coupled to their memory just like the GPUs are. nVidia is shipping 128MBytes of this stuff on their $500 cards so price-wise it might not be out of reach for Apple's top machines. All sorts of memory expansion issues, of course.
They've also got this fancy cross-bar memory controller which would need to be replicated in the CPU's memory controller before a true unified memory model could happen. Who knows, maybe the future processors will use the GPU's memory controller and talk to it via HyperTransport.
Thanks.
I just want to say, that I don't understand why you post just to have the last word, even if it's totally off topic. Do you need to increase your post count? Congrats, I lose big time.
programmer:
me: Correct, if you use larger types. However, I was talking about...
you: Well, if nothing else, you don't have a choice about the size of your pointers -- they will be twice as big. This includes the vtable..
Do you really think I don't realize that a 64 bit architecture actually means 64 bit pointers? I was not talking (do you read the things you quote?) about biger types (which are either used because you have to(pointers), because you're lazy or because the compiler choses to use them (int = 64bit) and indeed do use more bandwith). My post was about reading characters from memory, addressing Amorph's earlier post. It's a pleasure to quote it a third time:
"it can slow things down, because the minimum size of the data a 64 bit processor reads is 64 bits, and if you're reading in 8 bit ASCII characters then you're pulling 8 times the bandwidth the data actually requires across the bus,..."
and here we go again, maybe this time...:
"it can slow things down, because the minimum size of the data a 64 bit processor reads is 64 bits, and if you're reading in 8 bit ASCII characters then you're pulling 8 times the bandwidth the data actually requires across the bus,..."
And as before, my point is that this is not a difference between 32 and 64 bit processors. Because you would just not (ASCII, not pointers )PULL MORE DATA ACROSS THE BUS than you do now (even if it was slower from L1 cache to the register (RazzFazz), which it isn't!!!, this would still not be the issue here (BUS!)).
RazzFazz:
When we are discussing whether to implement 64bit fp altivec!! support, why do you write:
"Well, to be fair, this should read "1x64" rather than "0x64" (the G4 does have a DP FPU)."
??? We both know, that the G4 does not have any dp fp support in altivec. If I was talking about the whole processor, I would have written 3x64 > 1x64, isnt' that obvious?
you:
Adding 2x64 DP SIMD capabilities to AltiVec is pretty useless...
me:
2x64 is a lot more than 0x64
It was of course all SIMD related! Now, we don't have to agree on everything, but please read the posts and their context a bit closer before posting. Thank you very much.
BTW: "(assuming 4x32FP SIMD)" : I was of course talking about 2x64 SIMD, not 4x32 which is already implemented.
I've been looking at the transistor counts on the G4, G4e, and G5 and if the G5 is made from G4 cores, it looks like it could have up to 4 G4 cores on it based on the transistor count.
I used the G5 transistor count posted on geek.com so I hope their numbers are fairly accurate.
<strong>123, I think you need to re-read before you try to pummel some intelligent posts. Me thinks you just like to selectively chip away in frustration even when the posts were correct. It's beginning to look like a trend... <img src="graemlins/oyvey.gif" border="0" alt="[No]" /> </strong><hr></blockquote>
I don't know, seems like 123 is correect in that people didn't read his post before answering.
For example:
and here we go again, maybe this time...:
"it can slow things down, because the minimum size of the data a 64 bit processor reads is 64 bits, and if you're reading in 8 bit ASCII characters then you're pulling 8 times the bandwidth the data actually requires across the bus,..."
And as before, my point is that this is not a difference between 32 and 64 bit processors. Because you would just not (ASCII, not pointers )PULL MORE DATA ACROSS THE BUS than you do now (even if it was slower from L1 cache to the register (RazzFazz), which it isn't!!!, this would still not be the issue here (BUS!)).
which essentially says your reading 64-bits of the bus everytime anyway (even on a 32-bit processor with a 64-bit bus)
<strong>
You your self mentioned servers, and the words Unix, and Server go togeter like peanut butter, and jelly. Ruuun Foorrest!!! So 64bit seems like natural step towards a brighter future if you ask me.</strong><hr></blockquote>
quite possibly the hardest thing I've had to read since madtool and da truth train....maybe I need to get to bed though? I've been tired all day....too many damn commas ...and I use to many "..." I used to use too many commas though.
Probably the most important upgrade made feasible by a 64-bit computer is 64-bit A/V. remember how incredibly cool it was. and how much nicer it looked when you installed the Radius card in your Mac II. and got 24-bit video? remember how the 660AV and 840AV. due to their 16-bit audio synthesizer/digitizer. sounded so much better?
If any of you have ever used(I have
The key here is not so much the G5(It's pretty much already here) or a 64-bit version of Mac OS X(basically inevitable). the key are those lazy audio/video hardware makers. and what Apple chooses to put on their motherboards. remember how long it was before Apple started shipping machines with 24-bit graphics hardware? notice how Macs STILL don't use 24-bit audio hardware? if Apple is dumb enough to ship G5 machines with 64-bit Mac OS X. and no 48-64-bit A/V I/O. we're doomed. this will be the big stumbling block for 64-bit Macs.
As for compatability. much like every other RISC architecture's bit depth transition(MIPS, POWER, Alpha, SHx, ARM etc?) the G5 will run both 64-bit and totally unmodified 32-bit code concurrently and without any speed penalty whatsoever.
And as for a definition of "x-bit". my definition is that when all parts of a CPU operate at and/or above a certain bit depth. the CPU as a whole can be considered as operating at that bit depth.
For example. while the external bus of the G4 runs at 64-bit, the VPU runs at 128-bit and the FPU also runs at 64-bit. the IPU only operates at 32-bit. the G4 is thusly a 32-bit CPU.
\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t Eric,
<strong>Programmer, RazzFazz
I just want to say, that I don't understand why you post just to have the last word, even if it's totally off topic. Do you need to increase your post count? Congrats, I lose big time.
</strong><hr></blockquote>
Chill, dude.
Why so aggessive?
[quote]<strong>
RazzFazz:
When we are discussing whether to implement 64bit fp altivec!! support, why do you write:
"Well, to be fair, this should read "1x64" rather than "0x64" (the G4 does have a DP FPU)."
??? We both know, that the G4 does not have any dp fp support in altivec. If I was talking about the whole processor, I would have written 3x64 > 1x64, isnt' that obvious?
</strong><hr></blockquote>
I thought we were talking about how to catch up in DP FP power, SIMD or not (see my and programmer's above posts regarding "rather 2xscalar DP than Altivec DP"). In fact, you said yourself that "You could add some additional FPUs or whatever, I don't really care."
[quote]<strong>
you:
Adding 2x64 DP SIMD capabilities to AltiVec is pretty useless...
me:
2x64 is a lot more than 0x64
It was of course all SIMD related! Now, we don't have to agree on everything, but please read the posts and their context a bit closer before posting. Thank you very much.
</strong><hr></blockquote>
Well, again, you said "You could add some additional FPUs or whatever, I don't really care.", and that doesn't sound like "we're exclusively talking SIMD here" to me very much.
[quote]<strong>BTW: "(assuming 4x32FP SIMD)" : I was of course talking about 2x64 SIMD, not 4x32 which is already implemented.</strong><hr></blockquote>
My bad, sorry.
Bye,
RazzFazz
[quote]
and that doesn't sound like "we're exclusively talking SIMD here" to me very much.
<hr></blockquote>
Ok, I see your point. Yes, I said, that I don't really care, but you said, that SIMD was not an option, so I was defending the SIMD idea, because we already agreed on additional FPUs. I was actually quoting your 2x64 (you were talking exclusively about SIMD in that sentence), but I agree that you could read that either way, misunderstanding on both sides, my apologies.
Why so aggessive?
Because I really was/am frustrated. By now, I wanted to post only a few(3-4) times. But because nobody seems to be able to leave something just there, even if it is undisputable (I think ;-), I had to quote the same things (64 bit bus, funnel theory(other thread)) several times again and again... Then, you tell me Programmer wasn't talking about functions, even though I've even quoted the sentence, then he writes about bigger types, although that has nothing to do with what I was saying and he even repeats that point. After that, you come up with 1x64, although I wasn't talking abot the fpu (from my point of view)... I felt I had to ask people to read closer before posting a response, but I agree that it sounded too aggressive.
AirSluf:
[quote]
Razz and Programmer both gave pretty good explanations in their original posts and they have a long standing track record of low bull-shit high content posting. Someone else has a 2 thread record of low-fact high-warble responses. Which makes more sense to you? <hr></blockquote>
I agree on their track record, but I also think people should read first what other people have written and think about it before posting answers, no matter their name/knowledge/track record/reputation.
(Sorry everyone, this is from another thread, not even hardware related)
Same to you actually, how could you tell me that I was basically saying funnels are completely "un-needed"? If you had read my posts on that subject, you would have noticed that I was never talking about funnels in general, just that they're not reponsible for the big finder problems on SP machines. And about that "low-fact" responses: At least my facts are related to the topic and I'm not talking about jacobians. I also don't just come up with some stuff I've read in a paper or book even if it's irrelevant (as you do), just to show off my tremendous knowledge. (BTW: it would have been pretty easy to dismiss Whyatt's main argument, if you understood funnels, but I think you don't).
[ 04-09-2002: Message edited by: 123 ]</p>
<strong>Probably the most important upgrade made feasible by a 64-bit computer is 64-bit A/V. remember how incredibly cool it was. and how much nicer it looked when you installed the Radius card in your Mac II. and got 24-bit video? remember how the 660AV and 840AV. due to their 16-bit audio synthesizer/digitizer. sounded so much better?</strong><hr></blockquote>
Well, this is pretty much similar to the memory size argument: Most people are well capable of seeing a difference between a real life picture or sound and its 8bit digitized equivalent. The same is not true anymore if you go to 24bit or 16bit/44kHz resolutions, respectively (and even less so for 24/96 audio). Unless our eyes and ears suddenly go through an evolutionary quantum leap, there's no point in having resolutions that are way beyond what our sensory organs can discern.
Also, there's little point in having huge internal resolutions, when the interfaces are the quality bottleneck. Most audio DACs and ADCs on the market today, while technically featuring 24bit/96kHz, are far from even coming close to the theoretical SNR allowed by that. Similarly, current LCDs are limited to 24 bit colors at most, and even if this was just a limitation of the interface circuits inside the screen (as opposed to the panel itself), it still couldn't make use of higher bit depths.
[quote]<strong>If any of you have ever used(I have
</strong><hr></blockquote>
Well, since I haven't actually used any of those, I'll have to believe you on this matter.
One plausible explanation I could think of is that 24 bits per pixel, while featuring >16mio colors (more than you could put onto a single screen at once), only allow for 256 shades of every color component (red, green, blue) and consequently only 256 gray scales too. So in case you have a mainly monochromatic image (like a gray scale one), that limit would probably become apparent, whereas 16 bits per color component (i.e. 48bpp) would allow for a much more realistic representation.
On a side note, using AltiVec, the G4 could do 64bpp gfx already today (in fact, it could handle two such pixels per instruction), or even 128bpp (32 bit int or FP per color component).
Concerning audio, though, I'm pretty sure that a 32bit FP representation as used in OS X should be enough.
Bye,
RazzFazz
<strong>Well, this is pretty much similar to the memory size argument: Most people are well capable of seeing a difference between a real life picture or sound and its 8bit digitized equivalent. The same is not true anymore if you go to 24bit or 16bit/44kHz resolutions, respectively (and even less so for 24/96 audio). Unless our eyes and ears suddenly go through an evolutionary quantum leap, there's no point in having resolutions that are way beyond what our sensory organs can discern.</strong><hr></blockquote>
I doubt that. try(If you have a large monitor set at a high resolution) popping open Photoshop and do a large, simple gradient. notice the slight striation and dithering? now try this: get a photograph. and start doing a bunch of brightness/contrast/hue/saturation-type adjustments. notice the loss of detail and posterization effect? these sorts of things matter big time to media professionals. and as for the debate over higher bit depth audio. go to a DVD-Audio or Super Audio-CD site. you'll get an earfull(Heh heh?).
[quote]Originally posted by RazzFazz:
<strong>Also, there's little point in having huge internal resolutions, when the interfaces are the quality bottleneck. Most audio DACs and ADCs on the market today, while technically featuring 24bit/96kHz, are far from even coming close to the theoretical SNR allowed by that.</strong><hr></blockquote>
Really? have you checked out your PowerMac? how about your DVD player? looked into your DV camcorder? I'd be willing to bet that the formermost has a 16-bit audio I/O set-up. while the latter two both bear mere 10-bit audio hardware.
[quote]Originally posted by RazzFazz:
<strong>Similarly, current LCDs are limited to 24 bit colors at most, and even if this was just a limitation of the interface circuits inside the screen (as opposed to the panel itself), it still couldn't make use of higher bit depths.</strong><hr></blockquote>
Emphasis on the "Current". try hooking an older analog LCD to a good SGI/HP/Compaq/IBM etc. machine. this is why I think digital I/O components(Read: those stupid USB speakers and ADC monitors Apple makes) are a bad idea.
[quote]Originally posted by RazzFazz:
<strong>Well, since I haven't actually used any of those, I'll have to believe you on this matter.
One plausible explanation I could think of is that 24 bits per pixel, while featuring >16mio colors (more than you could put onto a single screen at once), only allow for 256 shades of every color component (red, green, blue) and consequently only 256 gray scales too. So in case you have a mainly monochromatic image (like a gray scale one), that limit would probably become apparent, whereas 16 bits per color component (i.e. 48bpp) would allow for a much more realistic representation.</strong><hr></blockquote>
Yup. whereas 24-bit only has around sixteen million(16,777,216) colors, 32-bit can theoretically do four billion(4,294,967,296). 48-bit can do up to two hundred and eighty one trillion(281,474,976,710,656). and full 64-bit can do over a whopping three hundred and forty duodecillion(340,282,366,920,938,463,463,374,607,431,768,211,0 00)! the capability to easily fumble around with such immense numbers would bring the I/O quality up so high as to please even the most particular user. and the power of high bit depth AD/DA circuitry could be tapped in a less CPU taxing fashion with palettes(Remember how a lot of games could get WAY more than 256 colors on early Macs? they did this by selecting 256 individual colors out of a static 16M color palette).
[quote]Originally posted by RazzFazz:
<strong>On a side note, using AltiVec, the G4 could do 64bpp gfx already today (in fact, it could handle two such pixels per instruction), or even 128bpp (32 bit int or FP per color component).</strong><hr></blockquote>
Using AltiVec that is. can you say "2x integer speed penalty"? like I said before. you need AT LEAST 64 bits throughout ALL of the CPU for maximum speed.
[quote]Originally posted by RazzFazz:
<strong>Concerning audio, though, I'm pretty sure that a 32bit FP representation as used in OS X should be enough.</strong><hr></blockquote>
That's what they said about 16-bit CDs. compare a 32-bit signal to an analog(A good one) signal on an oscilloscope. you'll notice tiny plateau-like steps in the digital signal. 32-bit is good. but 48-bit. or better yet. 64-bit audio is quite a bit better.
\t\t\t\t\t\t\t\t\t\t\t Eric,
<strong>
That's what they said about 16-bit CDs. compare a 32-bit signal to an analog(A good one) signal on an oscilloscope. you'll notice tiny plateau-like steps in the digital signal. 32-bit is good. but 48-bit. or better yet. 64-bit audio is quite a bit better.
\t\t\t\t\t\t\t\t\t\t\t Eric,</strong><hr></blockquote>
What you say is true in the absolute, but there is no need of a 24 bit audio if the analogic conversion , amplification , and the HP are lame.
I doubt that we can see a difference when we ear a 16 bit audio signal compared to even a 64 bit signal on a basic HP (like the lame built-in HP of the tower). The problem is not coming from an huge prize difference between a 24 bits audio chipset and a 16 bit one, but from the huge difference of prize, between a standart qualities of amplifications and HP, and a very good one.
This is the mean reason why in the domain of HI-FI there is so huge difference of prizes. If you don't believe me just go in an auditorium and just try some different stuffs (if you are an audio pro, i don't need to convice you on that particular subject)
[ 04-09-2002: Message edited by: powerdoc ]</p>