the FSB will be locked on 2:1, but AFAIK isn't the northbridge->memory-bus locked, so Apple can use whatever they want there... please correct me if this is wrong, but this is at least how it's done on P4 motherboards with DDR RAM.</strong><hr></blockquote>
Apple is already using the fastest standard DDR SDRAM - 333MHz effective - in its towers, and they currently have more bandwidth out of the memory controller than the frontside bus can handle!
The architecture will have to change pretty radically to take advantage of the 970, but it seems that Apple has had a lot of time to work on it. If they preannounce the towers at MWSF, or release them a little while after MWSF, they should be able to adopt second-generation DDR SDRAM, at effective bus speeds of 400MHz and 533MHz.
But it's the northbridge<->FSB that gets the most radical change. The northbridge as it is now handles the 333MHz RAM at full speed, but doesn't even have the option of spending all it's power on the processor FSB.
bwah, no point of continuing the talk for me, I do agree fully with Amorph anyways
This thread looks to have fractured into 3 sub-threads.
1) Colour representation will probably never exceed 128-bits, and it will get there because it is just very convenient computationally to have a 32-bit float per channel. There will be a 16-bit integer and a 16-bit float per channel representation as well (i.e. "64-bit colour"). Any of these forms, however, are well beyond the ability of DACs to represent or the human eye to discern -- they exist primarily so that lots of image manipulation doesn't result in noticable round-off errors (which cause visible noise or banding in the image).
2) Apple really doesn't have a historical pattern of "messing things up". Yes they fall behind, yes they sometimes do goofy things, but that's not a reason to assume that they won't come out with a damn good machine. They've done that before too.
3) One factor that is often overlooked in examining the limitations of a virtual memory subsystem is the size of the page tables which are used to keep track of which application has what pages. There is a data structure in the address space of the kernel which tells the operating system where each memory page (4K on OS X currently) is -- i.e. in RAM, on disk, whether it has changed or been initialized, etc. The format of this structure is largely determined by hardware these days. Most of the time this structure must stay in RAM so that the processor can always get to it immediately. It would suck if the information you needed to get in order to find a page of memory was out on disk and you had to go get it... especially if the information you needed in order to find that piece of information was also out on disk. As a result there is a big data structure that has to always stay in memory, and the more memory you have (RAM or virtual) in all processes, the bigger this thing gets. Some VM systems can page parts of this out -- I don't know what OS X & PowerPC can do in detail. Ever wonder why OS X's memory consumption goes up dramatically as you add more RAM? This is why... it is basically the bookkeeping required to keep track of where this memory is. It can easily become the limiting factor in systems which are using very large amounts of virtual memory compared to the amount of physical memory that they have installed.
3) One factor that is often overlooked in examining the limitations of a virtual memory subsystem is the size of the page tables which are used to keep track of which application has what pages. There is a data structure in the address space of the kernel which tells the operating system where each memory page (4K on OS X currently) is -- i.e. in RAM, on disk, whether it has changed or been initialized, etc. The format of this structure is largely determined by hardware these days.</strong><hr></blockquote>
This reminds me of when my place of work agreed to run a hydraulics simulation on our new Alpha (to help pay for it ). We weren't getting terribly good performance running the sim and the Oracle database and SAS and whatever else, so we took the machine down, adjusted the hardware virtual memory page size, and fired it back up. The performance was much improved with a larger page size.
<strong>This reminds me of when my place of work agreed to run a hydraulics simulation on our new Alpha (to help pay for it ). We weren't getting terribly good performance running the sim and the Oracle database and SAS and whatever else, so we took the machine down, adjusted the hardware virtual memory page size, and fired it back up. The performance was much improved with a larger page size.
I love real hardware. Too bad it costs so much.</strong><hr></blockquote>
Most processors support several page sizes, or at least they used to. Nowadays most designs seem to have converged on one or two sizes that turn out to be the most effective. 4K and/or 8K usually.
Most processors support several page sizes, or at least they used to. Nowadays most designs seem to have converged on one or two sizes that turn out to be the most effective. 4K and/or 8K usually.</strong><hr></blockquote>
Well, for what it's worth, the Pentium and its successors support 4kB and 4MB page sizes.
We will likely see a new designation for the pixel attributes, no longer limiting the description to color space bitness itself. Specs and cards are preparing for 256-bit pixel/vertex descriptions of which only 64 bits represent the color space (CS here doesn't include the alpha). All the other bits handle the fallout from vertex calculations and get pared out late in the pipeline as all the rendering finally generates a color/opacity for a pixel just before the frame buffer. Currently all this extra info is handled in a much less efficient manner and quite a bit of it hasn't really been used much below the extreme cutting edge of image generation. With most of this being taken care of on the GFX card at reasonable speeds in the future though, it will filter down to the mainstream.
The long pole in that tent then becomes bus throughput rather than raw CPU speed as high-end models and textures become huge compared to today and are primarily crunched on the GFX card rather than the CPU.
</strong><hr></blockquote>
An interesting feature of ATI's latest GPU (the 9700 family) is that it can have 4 simultaneous output buffers for whatever the shaders want to output. This is a huge step toward powerful multipass algorithms since large amounts of intermediate state can be written out to more than just the 4 traditional channels. Each successive generation of GPU at this point is going to have broader and broader applications in computation.
<strong>Well, what I want to know is how far away are we from Ati/Nvidia helping me with my Lightwave 'real time' renders, huh?
Surely with the Geforce FX/Ati 9700 we are heading into co-processor rendering territory?
Lemon Bon Bon </strong><hr></blockquote>
And how come the Nvidia Geforce Ti and Ati 9000 are trumpeted by apple but we can't have a Quadro or FireGL or Wildcat?
apple always manage to half a*se it up somehow. they'll develop a killer graphics technology then saddle the machines with a middle of the road ati or nvidia card. they'll somehow make sure that we get DDR when the MOBo might be perfectly capable of DDR2. they'll stick with Firewire when they coul have added Firewire 2. They'll do something really strange like ADC. There is always some way in which they manage to snatch defeat from the jaws of victory.
Comments
<strong>
the FSB will be locked on 2:1, but AFAIK isn't the northbridge->memory-bus locked, so Apple can use whatever they want there... please correct me if this is wrong, but this is at least how it's done on P4 motherboards with DDR RAM.</strong><hr></blockquote>
Apple is already using the fastest standard DDR SDRAM - 333MHz effective - in its towers, and they currently have more bandwidth out of the memory controller than the frontside bus can handle!
The architecture will have to change pretty radically to take advantage of the 970, but it seems that Apple has had a lot of time to work on it. If they preannounce the towers at MWSF, or release them a little while after MWSF, they should be able to adopt second-generation DDR SDRAM, at effective bus speeds of 400MHz and 533MHz.
But it's the northbridge<->FSB that gets the most radical change. The northbridge as it is now handles the 333MHz RAM at full speed, but doesn't even have the option of spending all it's power on the processor FSB.
bwah, no point of continuing the talk for me, I do agree fully with Amorph anyways
1) Colour representation will probably never exceed 128-bits, and it will get there because it is just very convenient computationally to have a 32-bit float per channel. There will be a 16-bit integer and a 16-bit float per channel representation as well (i.e. "64-bit colour"). Any of these forms, however, are well beyond the ability of DACs to represent or the human eye to discern -- they exist primarily so that lots of image manipulation doesn't result in noticable round-off errors (which cause visible noise or banding in the image).
2) Apple really doesn't have a historical pattern of "messing things up". Yes they fall behind, yes they sometimes do goofy things, but that's not a reason to assume that they won't come out with a damn good machine. They've done that before too.
3) One factor that is often overlooked in examining the limitations of a virtual memory subsystem is the size of the page tables which are used to keep track of which application has what pages. There is a data structure in the address space of the kernel which tells the operating system where each memory page (4K on OS X currently) is -- i.e. in RAM, on disk, whether it has changed or been initialized, etc. The format of this structure is largely determined by hardware these days. Most of the time this structure must stay in RAM so that the processor can always get to it immediately. It would suck if the information you needed to get in order to find a page of memory was out on disk and you had to go get it... especially if the information you needed in order to find that piece of information was also out on disk. As a result there is a big data structure that has to always stay in memory, and the more memory you have (RAM or virtual) in all processes, the bigger this thing gets. Some VM systems can page parts of this out -- I don't know what OS X & PowerPC can do in detail. Ever wonder why OS X's memory consumption goes up dramatically as you add more RAM? This is why... it is basically the bookkeeping required to keep track of where this memory is. It can easily become the limiting factor in systems which are using very large amounts of virtual memory compared to the amount of physical memory that they have installed.
<strong>
3) One factor that is often overlooked in examining the limitations of a virtual memory subsystem is the size of the page tables which are used to keep track of which application has what pages. There is a data structure in the address space of the kernel which tells the operating system where each memory page (4K on OS X currently) is -- i.e. in RAM, on disk, whether it has changed or been initialized, etc. The format of this structure is largely determined by hardware these days.</strong><hr></blockquote>
This reminds me of when my place of work agreed to run a hydraulics simulation on our new Alpha (to help pay for it
I love real hardware. Too bad it costs so much.
<strong>This reminds me of when my place of work agreed to run a hydraulics simulation on our new Alpha (to help pay for it
I love real hardware. Too bad it costs so much.</strong><hr></blockquote>
Most processors support several page sizes, or at least they used to. Nowadays most designs seem to have converged on one or two sizes that turn out to be the most effective. 4K and/or 8K usually.
<strong>
Most processors support several page sizes, or at least they used to. Nowadays most designs seem to have converged on one or two sizes that turn out to be the most effective. 4K and/or 8K usually.</strong><hr></blockquote>
Well, for what it's worth, the Pentium and its successors support 4kB and 4MB page sizes.
Bye,
RazzFazz
<strong>
We will likely see a new designation for the pixel attributes, no longer limiting the description to color space bitness itself. Specs and cards are preparing for 256-bit pixel/vertex descriptions of which only 64 bits represent the color space (CS here doesn't include the alpha). All the other bits handle the fallout from vertex calculations and get pared out late in the pipeline as all the rendering finally generates a color/opacity for a pixel just before the frame buffer. Currently all this extra info is handled in a much less efficient manner and quite a bit of it hasn't really been used much below the extreme cutting edge of image generation. With most of this being taken care of on the GFX card at reasonable speeds in the future though, it will filter down to the mainstream.
The long pole in that tent then becomes bus throughput rather than raw CPU speed as high-end models and textures become huge compared to today and are primarily crunched on the GFX card rather than the CPU.
</strong><hr></blockquote>
An interesting feature of ATI's latest GPU (the 9700 family) is that it can have 4 simultaneous output buffers for whatever the shaders want to output. This is a huge step toward powerful multipass algorithms since large amounts of intermediate state can be written out to more than just the 4 traditional channels. Each successive generation of GPU at this point is going to have broader and broader applications in computation.
Surely with the Geforce FX/Ati 9700 we are heading into co-processor rendering territory?
Lemon Bon Bon
<strong>Well, what I want to know is how far away are we from Ati/Nvidia helping me with my Lightwave 'real time' renders, huh?
Surely with the Geforce FX/Ati 9700 we are heading into co-processor rendering territory?
Lemon Bon Bon
And how come the Nvidia Geforce Ti and Ati 9000 are trumpeted by apple but we can't have a Quadro or FireGL or Wildcat?
apple always manage to half a*se it up somehow. they'll develop a killer graphics technology then saddle the machines with a middle of the road ati or nvidia card. they'll somehow make sure that we get DDR when the MOBo might be perfectly capable of DDR2. they'll stick with Firewire when they coul have added Firewire 2. They'll do something really strange like ADC. There is always some way in which they manage to snatch defeat from the jaws of victory.