Fermi
Andy "Krazy" Glew
Among other things, I observe that Fermi is dual issue. Warps from two
different threads can be dispatched in the same SM every cycle.
More precisely "warps, consisting of several lane threads, from two
different non-lane threads, can be dispatched in the same SM every cycle."
Because I usually draw the warps going horizontal, with threads queues
going vertical: "warps, consisting of several horizontal lane threads,
from two different verical non-lane threads, can be dispatched in the
same SM every cycle." But I have learned never to use horizontal and
vertical in terminology.
Sounds like the DIMT I was talking about earlier this year. Dual
Instruction Multiple Threads (as opposed to SIMT, Single Instruction
Multiple Threads).
Brett Davis
Fermi may never make it to real production. Debugged cut down versions
will take a year, and then only if it makes economic sense. Which with
ATI crushing NVidia on die size and performance, may mean never.
Graphics move onto the CPU die starting next year, leaving NVidia
without a market.
Fermi is basically just the previous NVidia chip with twice the
pipelines and some improvements, like adding support for float doubles.
So you have 480 pipes on a huge die with 2% yield. These are big beefy
cores with all the bells and whistles.
ATI's new chip is also twice the old one with some nice improvements,
1600 simple pipes on a die size half of Fermi's. Slightly less
performance out of the ATI chip, but you can have two of them on a board
for less than what Fermi costs and crush Fermi on all the benchmarks.
I would have made the same mistake as NVidea, figuring core count would
run out of steam and go for big fat bells and whistles cores instead.
There is a comp.arch lesson in this failure.
AMD's Radeon HD 5870: Bringing About the Next Generation Of GPUs
http://www.anandtech.com/video/showdoc.aspx?i=3643
Nvidia kills GTX285, GTX275, GTX260, abandons the mid and high end market
http://www.semiaccurate.com/2009/10/06/nvidia-kills-gtx285-gtx275-gtx260-
abandons-mid-and-high-end-market/
Nvidia halts future Intel chipset development
http://www.reghardware.co.uk/2009/10/09/nvidia_vs_intel/
Miracles happen, GT300 tapes out!
http://www.semiaccurate.com/2009/07/29/miracles-happen-gt300-tapes-out/
http://www.semiaccurate.com/2009/09/15/nvidia-gt300-yeilds-under-2/
Nvidia roadmaps turn up: Ugly and devoid of hope
http://www.semiaccurate.com/2009/09/01/nvidia-roadmaps-turn/
ATI Radeon HD5870
http://www.theinquirer.net/inquirer/review/1556348/ati-radeon-hd5870
The whole list of ATI Radeon HD 5870 reviews
http://www.theinquirer.net/inquirer/news/1556110/the-list-ati-radeon-hd-5
870-reviews
Brett
Robert Myers
> In article <H6mdnbrGv4ONDVjXnZ2dnUVZ_vedn...@giganews.com>,
>
> Nvidia kills GTX285, GTX275, GTX260, abandons the mid and high end markethttp://www.semiaccurate.com/2009/10/06/nvidia-kills-gtx285-gtx275-gtx...
> abandons-mid-and-high-end-market/
>
> Nvidia halts future Intel chipset developmenthttp://www.reghardware.co.uk/2009/10/09/nvidia_vs_intel/
>
> Miracles happen, GT300 tapes out!http://www.semiaccurate.com/2009/07/29/miracles-happen-gt300-tapes-out/http://www.semiaccurate.com/2009/09/15/nvidia-gt300-yeilds-under-2/
>
> Nvidia roadmaps turn up: Ugly and devoid of hopehttp://www.semiaccurate.com/2009/09/01/nvidia-roadmaps-turn/
>
>
> The whole list of ATI Radeon HD 5870 reviewshttp://www.theinquirer.net/inquirer/news/1556110/the-list-ati-radeon-...
> 870-reviews
>
The hot rumor, of course, is that Fermi chip yield is unacceptable.
If you're outside the business, and don't care about the balls being
carted about in wheel-barrows, a failure for Fermi would be an unhappy
event.
Robert.
Bernd Paysan
> I would have made the same mistake as NVidea, figuring core count
> would run out of steam and go for big fat bells and whistles cores
> instead. There is a comp.arch lesson in this failure.
Of course, there is - keep it stupid simple! I remember that for the
previous generation (R600), ATI/AMD put in quite some effort to make the
cores simpler, smaller, and less power-hungry. This seems to be a huge
success. NVidia didn't went to "big fat" cores, they just didn't go to
lighter cores. The company which wants to make GPUs with big fat cores
is called Intel - their Larrabee effort seems to be pretty desperate.
Putting many Pentium cores on a die is still way too complex.
The most interesting part here is that architecture starts to matter
again - during the time of the P6 platform (which basically still
continues), architecture disappeared, and only microarchitecture was
what matters - no matter how dreadful your ISA is, if you threw in
enough resources, your code ran fast; and even if your ISA is good, the
advantage was small.
Now, on GPUs, the many cores again need to be small and simple, so you
can't put just any ISA on it and make it fast. At least not x86.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
Andy "Krazy" Glew
Interestingly, so far as I can tell from what is publicly available,
Nvidia choose to go for more cores, but simpler, essentially scalar,
cores, whereas ATI went for fewer cores that are VLIW. In the earliest
generation. Where "cores" means "vector lanes", in the terminology that
I am more familiar with. Now, VLIW works to some extent, so ATI won with
fewer but fatter VLIW cores. However, at the moment it appears that ATI
can provide more VLIW lane cores than Nvidia can scalar lane cores. I
would like to understand why this is so - why ATI apparently has the
better density. Nvidia's emphasis on DP with Fermi is probably part of
it - DP mul-adds naturally want to be 4x more expensive than SP (okay,
maybe 3x, but not 2x), so making them 2X implies additional overhead.
Nvidia's emphasis on the cache & coherency is probably also costing
them. As is Nvidia's attempt to break out of the GPU market. But I
suspect there is some element of plain old hard work.
Brett Davis
"Andy \"Krazy\" Glew" <ag-...@patten-glew.net> wrote:
> Bernd Paysan wrote:
> > Brett Davis wrote:
> >> I would have made the same mistake as NVidea, figuring core count
> >> would run out of steam and go for big fat bells and whistles cores
> >> instead. There is a comp.arch lesson in this failure.
> >
> > Of course, there is - keep it stupid simple! I remember that for the
> > previous generation (R600), ATI/AMD put in quite some effort to make the
> > cores simpler, smaller, and less power-hungry. This seems to be a huge
> > success. NVidia didn't went to "big fat" cores, they just didn't go to
> > lighter cores. The company which wants to make GPUs with big fat cores
> > is called Intel - their Larrabee effort seems to be pretty desperate.
> > Putting many Pentium cores on a die is still way too complex.
>
>
> Interestingly, so far as I can tell from what is publicly available,
> Nvidia choose to go for more cores, but simpler, essentially scalar,
> cores, whereas ATI went for fewer cores that are VLIW. In the earliest
> generation. Where "cores" means "vector lanes", in the terminology that
> I am more familiar with. Now, VLIW works to some extent, so ATI won with
> fewer but fatter VLIW cores. However, at the moment it appears that ATI
> can provide more VLIW lane cores than Nvidia can scalar lane cores. I
> would like to understand why this is so - why ATI apparently has the
> better density. Nvidia's emphasis on DP with Fermi is probably part of
> it - DP mul-adds naturally want to be 4x more expensive than SP (okay,
> maybe 3x, but not 2x), so making them 2X implies additional overhead.
> Nvidia's emphasis on the cache & coherency is probably also costing
> them. As is Nvidia's attempt to break out of the GPU market. But I
> suspect there is some element of plain old hard work.
Double precision math is almost free if you reuse the pair of single
precision units that are already there. IBM has been doing this with the
PowerPC chips for the past decade. Doubles take four cycles through the
shared unit instead of three for singles, and you get a small pipeline
bubble when switching. Its a large engineering and validation task, but
the die savings pay for it.
The new NVidia uber chip with twice the pipes on 40nm is the same size
as the previous chip on 60nm.
ATI runs the same code on groups of ten VLIW pipes that are five singles
wide each. (Four + one, you can ignore the extra one, its a helper unit
to make code simpler and faster.) Most of the pipes will be stalled
waiting for data, so only a few of the ten will be running at any one
time? No early data prediction and fetching? Stone cold stupid simple?
Verses NVidia which has a huge LONG complex single pipes (but grouped)
and fetches data early to keep the (far fewer) units busy?
This is what NVidias budget line looks like compared to ATI, a bad joke:
Galaxy GeForce 210 and GT 220 Review - NVIDIA 40nm GPUs hit consumers
http://www.pcper.com/article.php?aid=794&type=expert&pid=1
NVidia will have low single digit market share this time next year.
Would short the stock, but someone stupid might buy them. More profit
being long AMD anyway. Bought a bunch at the crazy $2 price, will sell
at the equally crazy ~$35 that AMD will hit for the third time, the wall
street roller coaster is quite simply crazy.
Brett
Andy "Krazy" Glew
> Double precision math is almost free if you reuse the pair of single
> precision units that are already there. IBM has been doing this with the
> PowerPC chips for the past decade. Doubles take four cycles through the
> shared unit instead of three for singles, and you get a small pipeline
> bubble when switching. Its a large engineering and validation task, but
> the die savings pay for it.
At the risk of embarassing myself with a newbie error:
Consider a single precision multiplier that calculates A * B = AB.
Now consider a double precision multiplication of twice the width,
(A1,A2) * (B1,B2).
This involves calculating A1*B1, A1*B2, A2*B1, A2*B2.
Now, if you are just doing the multiplication, you do not need to
instantiate all of the low order bits (for floating point or fractional
fixed point) or the high order bits (for integer).
(There's a paper by, I believe, somebody at Berkeley, Patterson's RISC
group perhaps, on this.)
But if you are doing it as part of a fma with extended precision, I
*think* that you need to instantiate all of the bits, at least in some
circumstances.
If done in a fully pipelined manner, it is natural for this to take an
extra cycle of latency - you are adding up more bits. But you are
taking up quite a lot of hardware.
If done in a non-pipelined manner, using a SP multiplier array, it
should take longer.
I am familiar with one system where DP fma took only 2 passes through
the SP multiplier array - because the SP system had a primitive that
calculated A*X + B*Y.
But IIRC it takes quite a bit more hardware - roughly 4X in the
multiplier array, 2X in the adder - to do DP at the same throughput as SP.
Let's see if I have forgotten anything basic.
Terje Mathisen
> Brett Davis wrote:
>> Double precision math is almost free if you reuse the pair of single
>> precision units that are already there. IBM has been doing this with
>> the PowerPC chips for the past decade. Doubles take four cycles
>> through the shared unit instead of three for singles, and you get a
>> small pipeline bubble when switching. Its a large engineering and
>> validation task, but the die savings pay for it.
>
> At the risk of embarassing myself with a newbie error:
>
> Consider a single precision multiplier that calculates A * B = AB.
>
> Now consider a double precision multiplication of twice the width,
> (A1,A2) * (B1,B2).
>
> This involves calculating A1*B1, A1*B2, A2*B1, A2*B2.
>
> If done in a fully pipelined manner, it is natural for this to take an
> extra cycle of latency - you are adding up more bits. But you are taking
> up quite a lot of hardware.
On key point:
There's only room for half as many DP values in the same vector
register, so you already have a pair of SP multipliers available for
each DP result.
>
> If done in a non-pipelined manner, using a SP multiplier array, it
> should take longer.
>
> I am familiar with one system where DP fma took only 2 passes through
> the SP multiplier array - because the SP system had a primitive that
> calculated A*X + B*Y.
SSE/Altivec or LRB will all have the same dual resources available when
working with half as many DP values.
>
> But IIRC it takes quite a bit more hardware - roughly 4X in the
> multiplier array, 2X in the adder - to do DP at the same throughput as SP.
Right, so most of the vector units will only do half (or a little less)
the throughput for DP values. OTOH, the throughput measured in result
bytes/cycle is nearly the same.
It was you who taught me that for a first approximation, only the amount
of data to load and store matters, the actual computation is nearly
free. In the DP case we get half the number of results but the same
amount of data. :-)
Terje
>
> Let's see if I have forgotten anything basic.
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
nm...@cam.ac.uk
Terje Mathisen <Terje.M...@tmsw.no> wrote:
>Andy "Krazy" Glew wrote:
>>
>> But IIRC it takes quite a bit more hardware - roughly 4X in the
>> multiplier array, 2X in the adder - to do DP at the same throughput as SP.
>
>Right, so most of the vector units will only do half (or a little less)
>the throughput for DP values. OTOH, the throughput measured in result
>bytes/cycle is nearly the same.
>
>It was you who taught me that for a first approximation, only the amount
>of data to load and store matters, the actual computation is nearly
>free. In the DP case we get half the number of results but the same
>amount of data. :-)
Yes and no. There is a problem with chalk and cheese. In the case
of early computers, and some (most?) current GPUs and DSPs, the
multiplication logic takes a significant proportion of the space
and power. For those, double precision is a problem. In the case
of 'general purpose' chips, it's lost in the noise.
[ That isn't to inform you, Terje, as I know you know it, but to
try to clarify this thread. ]
However, if people still understood numerics, they would realise
that 'last bit' accuracy for all operands is very, very rarely
needed or even useful. And what is really needed can be provided
for much less logic than the full double precision multiply. It's
also more vectorisable.
Regards,
Nick Maclaren.
Bernd Paysan
> On key point:
>
> There's only room for half as many DP values in the same vector
> register, so you already have a pair of SP multipliers available for
> each DP result.
It's still that NVidia claims that it can do half the DP operations as SP
operations in the same time. If they said "we can do half the DP operations
as SP operations per unit, and it takes twice the time", I would agree -
like Andy explains, having a primitive in the form of AX+BY is useful to
have in a GPU, and then you can really use the two such units to perform one
DP multiplication - but you also can use them to perform four SP
multiplications.
There's a trick to reduce the number of multiplications to three, but it
costs you adder resources and latency. You can also drop the A2*B2 partial
result if you aren't interested in the last few bits, and if your multiplier
array is made of components for smaller parts (e.g. if the building block is
an 8 by 8 multiplier, and you have 9 of those), you can distribute the more
interesting portions of the A1*B2+A2*B1 into a single SP multiplier and just
lose a few more bits. Note that two SP units give you only a 48 bit result,
while for exact DP you really need 53 bits.
I can imagine that such a structure for the multiplier cells is useful for a
GPU, where you can use the 8x8 multiplier components also for alpha
blending. Maybe there are enough resources of that kind to perform a
sufficiently accurate DP multiplication with just two SP multiplier cells.
But note that probably the SP multipliers already use this performance
trick, so when they do (A1,A2,A3)*(B1,B2,B3), they already drop at least
three results, and just use the 6 8x8 blocks that are necessary for alpha
blending. This won't be enough for DP.
Brett Davis
Bernd Paysan <bernd....@gmx.de> wrote:
> Terje Mathisen wrote:
> > On key point:
> >
> > There's only room for half as many DP values in the same vector
> > register, so you already have a pair of SP multipliers available for
> > each DP result.
>
> It's still that NVidia claims that it can do half the DP operations as SP
> operations in the same time. If they said "we can do half the DP operations
> as SP operations per unit, and it takes twice the time", I would agree -
> like Andy explains, having a primitive in the form of AX+BY is useful to
> have in a GPU, and then you can really use the two such units to perform one
> DP multiplication - but you also can use them to perform four SP
> multiplications.
NVidia did not mention latency, you can issue either every cycle, but
the SP results may only take 3 cycles to come out and the doubles 4 or 5.
(This does imply that there is some extra hardware, for the extra
stage(s), but significantly less than twice the hardware.)
> There's a trick to reduce the number of multiplications to three, but it
> costs you adder resources and latency. You can also drop the A2*B2 partial
> result if you aren't interested in the last few bits, and if your multiplier
> array is made of components for smaller parts (e.g. if the building block is
> an 8 by 8 multiplier, and you have 9 of those), you can distribute the more
> interesting portions of the A1*B2+A2*B1 into a single SP multiplier and just
> lose a few more bits. Note that two SP units give you only a 48 bit result,
> while for exact DP you really need 53 bits.
I was aware that one is short a few bits, tacking those on is pretty
much a rounding error in your transistor count.
> I can imagine that such a structure for the multiplier cells is useful for a
> GPU, where you can use the 8x8 multiplier components also for alpha
> blending. Maybe there are enough resources of that kind to perform a
> sufficiently accurate DP multiplication with just two SP multiplier cells.
> But note that probably the SP multipliers already use this performance
> trick, so when they do (A1,A2,A3)*(B1,B2,B3), they already drop at least
> three results, and just use the 6 8x8 blocks that are necessary for alpha
> blending. This won't be enough for DP.
Yes my major concern is that I got the quote backwards, so that with
doubles, doing singles is free. But that would not have been as
interesting as a mental exercise.
So the end result is you end up with a tree of smaller multipliers and
adders spread across the stages of execution. (For pipelining.)
For the 8x8 multiply (or add) you assume half a cycle, or a third a
cycle, and just plop them down in the order needed to get a SP result,
then clone it, and then compare to the similar order needed for DP. You
could pick a 12x12 base unit instead, etc.
Using 12x12 for simplicity my crude scribbles have me needing twice the
multipliers for DP than two SP, 8 units verses 16 for a full multiply,
if you drop the low bits its 6 verses 10. Just under twice.
Its looking like I got the quote backwards.
Brett
Brett Davis
"Andy \"Krazy\" Glew" <ag-...@patten-glew.net> wrote:
> Brett Davis wrote:
> > Double precision math is almost free if you reuse the pair of single
> > precision units that are already there. IBM has been doing this with the
> > PowerPC chips for the past decade. Doubles take four cycles through the
> > shared unit instead of three for singles, and you get a small pipeline
> > bubble when switching. Its a large engineering and validation task, but
> > the die savings pay for it.
>
> At the risk of embarassing myself with a newbie error:
I am well aware that you are a real hardware guy, and I am the newbie. ;)
> Consider a single precision multiplier that calculates A * B = AB.
>
> Now consider a double precision multiplication of twice the width,
> (A1,A2) * (B1,B2).
>
> This involves calculating A1*B1, A1*B2, A2*B1, A2*B2.
I got the quote backwards, so with doubles doing singles is free.
But this brings up another question, in a old die layout of the Athlon
chip they showed separate blocks for the SP multiplier and DP
multiplier. Is this still common? Or am I just wrong again. ;)
Andy "Krazy" Glew
> In article <4AD54E5E...@patten-glew.net>,
> "Andy \"Krazy\" Glew" <ag-...@patten-glew.net> wrote:
>
>> Brett Davis wrote:
>>> Double precision math is almost free
>>
>
> I am well aware that you are a real hardware guy, and I am the newbie. ;)
Hey, Brett, I did not mean to be arch or condescending. For all I know
you may have just designed an SP/DP FMA unit as part of your MS thesis,
and may know something I don't.
I don't really know if I'm a real hardware guy or not. I think many
people might say not. To software people I'm a hardware guy, to
hardware people I'm a software guy. But, I'm seldom shy to ask
questions if something doesn't make sense.
> But this brings up another question, in a old die layout of the Athlon
> chip they showed separate blocks for the SP multiplier and DP
> multiplier. Is this still common? Or am I just wrong again. ;)
I don't remember that Athlon chip plot.
However, many x86 systems have separate x87 (32b SP, 64b DP, and 80-bit
EP) and SSE (2,4,... x 32b) datapaths. Perhaps that is what you saw?
Brett Davis
Bernd Paysan <bernd....@gmx.de> wrote:
> Brett Davis wrote:
> > I would have made the same mistake as NVidea, figuring core count
> > would run out of steam and go for big fat bells and whistles cores
> > instead. There is a comp.arch lesson in this failure.
>
> Of course, there is - keep it stupid simple! I remember that for the
> previous generation (R600), ATI/AMD put in quite some effort to make the
> cores simpler, smaller, and less power-hungry. This seems to be a huge
> success. NVidia didn't went to "big fat" cores, they just didn't go to
> lighter cores. The company which wants to make GPUs with big fat cores
> is called Intel - their Larrabee effort seems to be pretty desperate.
> Putting many Pentium cores on a die is still way too complex.
Lets take the other side of the coin, Fermi is almost good enough to run
a real OS on.
Do you need a main CPU if your GPU has 400 processors?
The answer for Windows and Unix is yes you need a CPU, but for OS/X I am
not so sure. For the next generation of game consoles if you could throw
out the CPU you could cut your costs in almost half, with no loss in
performance if done correctly...
Apple could pull this off, (iConsole?) Sony might try and fail, anyone
else would get laughed at, its to hard.
FYI: Apple has its own CPU design team, does not need NVidia.
You would still have two types of processors, GPU work needs extra units
that a real CPU does not need. So you could end up with CPUs smaller
than on ATIs 1600 vector pipe chip. Lots smaller if you dont bother with
adding vector units to the CPUs. Scratch that, the real CPUs would not
be clustered as ten pipes running the same code. That change alone would
make the CPU units ~4 times bigger than the ATI units.
I kinda like this idea, would be interesting to program for.
Brett
Morten Reistad
Brett Davis <gg...@yahoo.com> wrote:
>In article <06o9q6-...@vimes.paysan.nom>,
> Bernd Paysan <bernd....@gmx.de> wrote:
>Do you need a main CPU if your GPU has 400 processors?
>
>The answer for Windows and Unix is yes you need a CPU, but for OS/X I am
>not so sure. For the next generation of game consoles if you could throw
>out the CPU you could cut your costs in almost half, with no loss in
>performance if done correctly...
How big and how capable is that CPU/GPU you have 400 compies of?
QNX runs pretty well on a 286, and can run on a few tens of slow
processors pretty well. How much memory, what kind of mmu, how
are common buses interfaced, and how you do interrupts?
>Apple could pull this off, (iConsole?) Sony might try and fail, anyone
>else would get laughed at, its to hard.
>
>FYI: Apple has its own CPU design team, does not need NVidia.
I don't think cpu design is the issue here. The issues are
systems design and os design.
>You would still have two types of processors, GPU work needs extra units
>that a real CPU does not need. So you could end up with CPUs smaller
>than on ATIs 1600 vector pipe chip. Lots smaller if you dont bother with
>adding vector units to the CPUs. Scratch that, the real CPUs would not
>be clustered as ten pipes running the same code. That change alone would
>make the CPU units ~4 times bigger than the ATI units.
>
>I kinda like this idea, would be interesting to program for.
Why would you bother having different cpus if 95% of the load
is graphics work anyway?
- mrr
Brett Davis
This was the NVidia Fermi thread, subject changed.
> >Do you need a main CPU if your GPU has 400 processors?
> >
> >The answer for Windows and Unix is yes you need a CPU, but for OS/X I am
> >not so sure. For the next generation of game consoles if you could throw
> >out the CPU you could cut your costs in almost half, with no loss in
> >performance if done correctly...
>
> How big and how capable is that CPU/GPU you have 400 compies of?
Wimpy, only one quarter the speed of a "real" CPU at the same clock, or
less, way less. The tradeoff is you get ~25 times as many CPUs per die
area.
> QNX runs pretty well on a 286, and can run on a few tens of slow
> processors pretty well. How much memory, what kind of mmu, how
> are common buses interfaced, and how you do interrupts?
Your MMU design, or ways to not use your MMU are critical.
Also related is your L1 and L2 connectivity to your CPUs.
Ideally you want a code thread to say it wants a cluster of 16 cpus with
shared MMU/L1/L2, and then let that thread spawn 100 sub-threads in that
shared memory space of 16 CPUs.
Otherwise you have 100 threads/CPUs fighting over MMU pages, and none of
those CPUs making any significant progress.
So you design your hardware around 16 CPU clusters, and your OS, and
your apps around the same paradigm. If you do it right, over time if the
sweet spot moves to 8 CPUs or 32 CPUs, the same code will still run. You
gave the primary process a cluster, it does not need to know how many
CPUs, or how much cache, or what the clock speed was.
This is the future of CPU based computing, mini clusters.
The huge benefit is that you only need one MMU/L1/L2 per cluster. The
MMU is a huge piece of die real estate, (and heat) as is the L1 and L2.
As for any idea of using no MMU and a completely shared memory space
like a graphics chip. That is insane. Having a thousand other processes
running broken code and scribbling all over my data and code, leads to a
design that will never work in the real world. Its a house of cards, in
a room full of angry two year olds.
> >Apple could pull this off, (iConsole?) Sony might try and fail, anyone
> >else would get laughed at, its to hard.
> >
> >FYI: Apple has its own CPU design team, does not need NVidia.
>
> I don't think cpu design is the issue here. The issues are
> systems design and os design.
Bingo, hardware companies do not understand system design or OS design.
Apple as a software company that designs hardware to sell, does.
Few software or hardware companies can force their customer base and
developer base onto a new paradigm, one that is a difficult and costly
transition. Even if that change has huge benefits. Apple can, maybe Sony.
Apple is heavily promoting Grand Central Dispatch, which has 90% of what
you need to run on these shared memory clusters I just described.
http://developer.apple.com/mac/articles/cocoa/introblocksgcd.html
Sony is betting on Larrabee, which may end up with a similar cluster
organization. MMU looks like it would be part of the ring controller
that controls memory access off the cluster. L2 is global.
My first pass design is ATI like, with shared L1, not sure you can share
a L1 16 ways... But with separate L1s you get a hideous number of MMU
checks you have to deal with between the L1 and L2. Being a software guy
this tradeoff is outside of my knowledge base.
> >You would still have two types of processors, GPU work needs extra units
> >that a real CPU does not need. So you could end up with CPUs smaller
> >than on ATIs 1600 vector pipe chip. Lots smaller if you dont bother with
> >adding vector units to the CPUs. Scratch that, the real CPUs would not
> >be clustered as ten pipes running the same code. That change alone would
> >make the CPU units ~4 times bigger than the ATI units.
> >
> >I kinda like this idea, would be interesting to program for.
>
> Why would you bother having different cpus if 95% of the load
> is graphics work anyway?
For most games less than 20% of the CPU is doing anything directly
related to graphics. And most of that 20% would be character skinning,
which is moving onto the GPU.
The landscape is chopped into pre-compiled blocks that are handed off to
the graphics chip. You spend maybe 3% on bounding box checks for those
blocks, and these checks also will move largely into the GPU over time.
Another 20% is spent on character bone animation and character physics,
this is also moving onto the GPU, or a CPU cluster...
10% on other physics and collisions, which is trying and failing to move
onto the GPU. These problems are actually too hard for GPUs today, but
its perfect for a CPU cluster.
10% on particles, this is moving onto the GPU.
5% in AI, this stays on the CPU.
And a big list of other things that will stay on the CPU.
In answer to your question, a typical PC sold today has 2 CPUs and 400
GPU pipes, so yes 95% of the computation is actually on the GPU. But
without that CPU doing all the hard work, that GPU will sit idle.
In the game industry we are running out of things we can hand off to the
GPU, even if that GPU is relatively bright.
Brett
Del Cecchi
"Brett Davis" <gg...@yahoo.com> wrote in message
news:ggtgp-5E63F4....@netnews.asp.att.net...
You might note that Sony has in the past utilized quite competent cpu
and core and chip designers. I would guess they are still around.
del
Mayan Moudgill
> As for any idea of using no MMU and a completely shared memory space
> like a graphics chip. That is insane. Having a thousand other processes
> running broken code and scribbling all over my data and code, leads to a
> design that will never work in the real world. Its a house of cards, in
> a room full of angry two year olds.
>
Umm... MMU != memory protection. Various forms of base+bound protection
could be implemented that would give you protection without needing an MMU.
Joe Pfeiffer
This depends critically on your definition of MMU. I'd regard
base+bound as a really primitive MMU; you seem to require something
stronger in order to count as an MMU.
--
As we enjoy great advantages from the inventions of others, we should
be glad of an opportunity to serve others by any invention of ours;
and this we should do freely and generously. (Benjamin Franklin)
Brett Davis
Mayan Moudgill <ma...@bestweb.net> wrote:
x86 started with base+bounds, even giving a plentiful set of offset
registers. Almost no one used it, and those registers were recycled for
other uses.
RAM is so plentiful now that if you went with fine grain memory
protection, you would just round up allocations and give out full pages.
Makes paging out to disk easy, which is needed when the user closes the
lid on his laptop, and everything is saved.
Does anyone use base+bounds in any market?
Brett
ArarghMai...@not.at.arargh.com
<snip>
>
>x86 started with base+bounds, even giving a plentiful set of offset
>registers. Almost no one used it, and those registers were recycled for
>other uses.
It did? x86? When? Where? Any Docs?
<snip>
--
ArarghMail910 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html
To reply by email, remove the extra stuff from the reply address.
Andrew Reilly
> On Mon, 26 Oct 2009 04:43:21 GMT, Brett Davis <gg...@yahoo.com> wrote:
>
> <snip>
>>
>>x86 started with base+bounds, even giving a plentiful set of offset
>>registers. Almost no one used it, and those registers were recycled for
>>other uses.
> It did? x86? When? Where? Any Docs? <snip>
That's more or less how the 286 MMU worked, and (I think) versions of QNX
and Minix and perhaps Xenix have worked with that model, too.
Probably helps that there were vaguely similar base+bound MMUs around for
Z8000 and PDP-11 variants, both of which had something-like-unix that
used them. (Not sure about the 68000 MMU capabilities: maybe they went
straight to paging, following the lead of VAX?)
The early ARM systems had a funky memory protection-but-no-mapping system
with very large granularity for mapping (32k), which made BSD Unix hard,
but worked OK for their own OS (which was a unified address space thing.)
Cheers,
--
Andrew
ArarghMai...@not.at.arargh.com
<andrew-...@areilly.bpc-users.org> wrote:
>On Mon, 26 Oct 2009 01:29:17 -0500, ArarghMail910NOSPAM wrote:
>
>> On Mon, 26 Oct 2009 04:43:21 GMT, Brett Davis <gg...@yahoo.com> wrote:
>>
>> <snip>
>>>
>>>x86 started with base+bounds, even giving a plentiful set of offset
>>>registers. Almost no one used it, and those registers were recycled for
>>>other uses.
>> It did? x86? When? Where? Any Docs? <snip>
>
>That's more or less how the 286 MMU worked, and (I think) versions of QNX
That's not how I remember it, but I will dig out the manual and see.
>and Minix and perhaps Xenix have worked with that model, too.
I know that there was a 286 Xenix because I have a copy. I bought the
wrong version, and couldn't return it. Still have it.
386 version, also. If I could find a copy of TCP/IP for the 386
Xenix, I might actually use it for something. But SCO dropped support
for it YEARs ago. :-)
Mayan Moudgill
> Mayan Moudgill <ma...@bestweb.net> writes:
>
>
>>Brett Davis wrote:
>>
>>
>>>As for any idea of using no MMU and a completely shared memory space
>>>like a graphics chip. That is insane. Having a thousand other
>>>processes running broken code and scribbling all over my data and
>>>code, leads to a design that will never work in the real world. Its
>>>a house of cards, in a room full of angry two year olds.
>>>
>>
>>Umm... MMU != memory protection. Various forms of base+bound
>>protection could be implemented that would give you protection without
>>needing an MMU.
>
>
> This depends critically on your definition of MMU. I'd regard
> base+bound as a really primitive MMU; you seem to require something
> stronger in order to count as an MMU.
Generally, MMU => virtual memory
And that is *probably* how the original poster thought of it too: he states:
Mayan Moudgill
> In article <_-OdnSjff4QDa3nXn...@bestweb.net>,
> Mayan Moudgill <ma...@bestweb.net> wrote:
>
>
>>Brett Davis wrote:
>>
>>
>>>As for any idea of using no MMU and a completely shared memory space
>>>like a graphics chip. That is insane. Having a thousand other processes
>>>running broken code and scribbling all over my data and code, leads to a
>>>design that will never work in the real world. Its a house of cards, in
>>>a room full of angry two year olds.
>>>
>>
>>Umm... MMU != memory protection. Various forms of base+bound protection
>>could be implemented that would give you protection without needing an MMU.
>
>
> x86 started with base+bounds, even giving a plentiful set of offset
> registers. Almost no one used it, and those registers were recycled for
> other uses.
No, it didn't; it started of with (a variant of) segments, which are
completely different than base+bound.
> RAM is so plentiful now that if you went with fine grain memory
> protection, you would just round up allocations and give out full pages.
> Makes paging out to disk easy, which is needed when the user closes the
> lid on his laptop, and everything is saved.
>
You wanted protection, not translation or paging support. If real memory
= address space, when do you page? BTW: preserving the memory image does
not require paging.
Joe Pfeiffer
> In article <_-OdnSjff4QDa3nXn...@bestweb.net>,
> Mayan Moudgill <ma...@bestweb.net> wrote:
>
>> Brett Davis wrote:
>>
>> > As for any idea of using no MMU and a completely shared memory space
>> > like a graphics chip. That is insane. Having a thousand other processes
>> > running broken code and scribbling all over my data and code, leads to a
>> > design that will never work in the real world. Its a house of cards, in
>> > a room full of angry two year olds.
>> >
>>
>> Umm... MMU != memory protection. Various forms of base+bound protection
>> could be implemented that would give you protection without needing an MMU.
>
> x86 started with base+bounds, even giving a plentiful set of offset
> registers. Almost no one used it, and those registers were recycled for
> other uses.
8086 had base but no bound, and the base could be modified by a user
program (in fairness, it didn't have user/system modes).
286's segmented memory was much, much more complex than branch+bound.
> RAM is so plentiful now that if you went with fine grain memory
> protection, you would just round up allocations and give out full pages.
> Makes paging out to disk easy, which is needed when the user closes the
> lid on his laptop, and everything is saved.
>
> Does anyone use base+bounds in any market?
>
> Brett
--
Morten Reistad
Brett Davis <gg...@yahoo.com> wrote:
>The future of CPU based computing, mini clusters.
>
>This was the NVidia Fermi thread, subject changed.
>
>> >Do you need a main CPU if your GPU has 400 processors?
>> >
>> >The answer for Windows and Unix is yes you need a CPU, but for OS/X I am
>> >not so sure. For the next generation of game consoles if you could throw
>> >out the CPU you could cut your costs in almost half, with no loss in
>> >performance if done correctly...
>>
>> How big and how capable is that CPU/GPU you have 400 compies of?
>
>Wimpy, only one quarter the speed of a "real" CPU at the same clock, or
>less, way less. The tradeoff is you get ~25 times as many CPUs per die
>area.
That would be on the order of a Via C3 or somesuch, 600-800 Mhz,
still usably fast for code that farms well out into threads.
>> QNX runs pretty well on a 286, and can run on a few tens of slow
>> processors pretty well. How much memory, what kind of mmu, how
>> are common buses interfaced, and how you do interrupts?
>
>Your MMU design, or ways to not use your MMU are critical.
>Also related is your L1 and L2 connectivity to your CPUs.
>
>Ideally you want a code thread to say it wants a cluster of 16 cpus with
>shared MMU/L1/L2, and then let that thread spawn 100 sub-threads in that
>shared memory space of 16 CPUs.
Both basic unix design and e.g. qnx can live with segment descriptors as
the mmu objects. The demand paging stuff is extra, so the
mmu can be a pretty simple one. The 286 model works pretty well,
actually.
>Otherwise you have 100 threads/CPUs fighting over MMU pages, and none of
>those CPUs making any significant progress.
>
>So you design your hardware around 16 CPU clusters, and your OS, and
>your apps around the same paradigm. If you do it right, over time if the
>sweet spot moves to 8 CPUs or 32 CPUs, the same code will still run. You
>gave the primary process a cluster, it does not need to know how many
>CPUs, or how much cache, or what the clock speed was.
>
>This is the future of CPU based computing, mini clusters.
>
>The huge benefit is that you only need one MMU/L1/L2 per cluster. The
>MMU is a huge piece of die real estate, (and heat) as is the L1 and L2.
But you still get process isolation, right?
>As for any idea of using no MMU and a completely shared memory space
>like a graphics chip. That is insane. Having a thousand other processes
>running broken code and scribbling all over my data and code, leads to a
>design that will never work in the real world. Its a house of cards, in
>a room full of angry two year olds.
yep. You need basic process isolation, but the paging stuff is a
historic legacy now.
>> >Apple could pull this off, (iConsole?) Sony might try and fail, anyone
>> >else would get laughed at, its to hard.
>> >
>> >FYI: Apple has its own CPU design team, does not need NVidia.
>>
>> I don't think cpu design is the issue here. The issues are
>> systems design and os design.
>
>Bingo, hardware companies do not understand system design or OS design.
>Apple as a software company that designs hardware to sell, does.
>
>Few software or hardware companies can force their customer base and
>developer base onto a new paradigm, one that is a difficult and costly
>transition. Even if that change has huge benefits. Apple can, maybe Sony.
Why not take an OS that runs _only_ in the gpu clusters, and
let whatever stuff is sold with the machine handle the "main" cpu?
This is a stellar chance to migrate "below the radar".
>Apple is heavily promoting Grand Central Dispatch, which has 90% of what
>you need to run on these shared memory clusters I just described.
>
>http://developer.apple.com/mac/articles/cocoa/introblocksgcd.html
>
>Sony is betting on Larrabee, which may end up with a similar cluster
>organization. MMU looks like it would be part of the ring controller
>that controls memory access off the cluster. L2 is global.
>
>My first pass design is ATI like, with shared L1, not sure you can share
>a L1 16 ways... But with separate L1s you get a hideous number of MMU
>checks you have to deal with between the L1 and L2. Being a software guy
>this tradeoff is outside of my knowledge base.
The "big" cpu's behave terribly here. They are somewhat saved by
hypertransport, which is just a pipe with raw speed to peek in other caches.
A "logarithmical" layout, 16 cpus, 4 L1, 1 L2 may be a way to
go.
Is this because of need for serial speed ("big" cpus), memory footprint,
or organisational issues where you simply do not have an os and scheduler
for running the gpu units as if they were a large set of normal cpus?
-- mrr
ArarghMai...@not.at.arargh.com
ArarghMai...@NOT.AT.Arargh.com wrote:
>On 26 Oct 2009 08:30:25 GMT, Andrew Reilly
><andrew-...@areilly.bpc-users.org> wrote:
>
>>On Mon, 26 Oct 2009 01:29:17 -0500, ArarghMail910NOSPAM wrote:
>>
>>> On Mon, 26 Oct 2009 04:43:21 GMT, Brett Davis <gg...@yahoo.com> wrote:
>>>
>>> <snip>
>>>>
>>>>x86 started with base+bounds, even giving a plentiful set of offset
>>>>registers. Almost no one used it, and those registers were recycled for
>>>>other uses.
>>> It did? x86? When? Where? Any Docs? <snip>
>>
>>That's more or less how the 286 MMU worked, and (I think) versions of QNX
>That's not how I remember it, but I will dig out the manual and see.
Drat. Can't find the 286 manual.
Jeremy Linton
> On Mon, 26 Oct 2009 05:09:02 -0500,
> ArarghMai...@NOT.AT.Arargh.com wrote:
>
>> On 26 Oct 2009 08:30:25 GMT, Andrew Reilly
>> <andrew-...@areilly.bpc-users.org> wrote:
>>
>>> On Mon, 26 Oct 2009 01:29:17 -0500, ArarghMail910NOSPAM wrote:
>>>
>>>> On Mon, 26 Oct 2009 04:43:21 GMT, Brett Davis <gg...@yahoo.com> wrote:
>>>>
>>>> <snip>
>>>>> x86 started with base+bounds, even giving a plentiful set of offset
>>>>> registers. Almost no one used it, and those registers were recycled for
>>>>> other uses.
>>>> It did? x86? When? Where? Any Docs? <snip>
>>> That's more or less how the 286 MMU worked, and (I think) versions of QNX
>> That's not how I remember it, but I will dig out the manual and see.
> Drat. Can't find the 286 manual.
There are 286 manuals here:
http://www.ragestorm.net/downloads/286intel.txt
http://datasheets.chipdb.org/Intel/x86/286/datashts/intel_M80C286.pdf
(page 12 has the descriptor formats)
From the manual section 6.4:
"Finally, the segment descriptor contains the physical base address of
the target segment, as well as size (limit) and access information. The
processor sums the 24-bit segment base and the specified 16-bit offset
to generate the resulting 24-bit physical address."
One could argue, that the 286 was the first x86 with an MMU, and
therefor the statement the x86 started with base+bounds would be correct.
I have found memories of my 286 and its protected mode. I remember it
worked pretty well in windows 3.0 (286 protected mode got removed
shortly after with the only choice being real or 386 protected) and I
was unhappy when they removed it, as the only other choice was 386
protected mode which ran significantly slower on my machine.
Brett Davis
Morten Reistad <fi...@last.name> wrote:
> In article <ggtgp-4FCC6C....@netnews.asp.att.net>,
> Brett Davis <gg...@yahoo.com> wrote:
> >The future of CPU based computing, mini clusters.
> >> >Do you need a main CPU if your GPU has 400 processors?
> >
> >So you design your hardware around 16 CPU clusters, and your OS, and
> >your apps around the same paradigm. If you do it right, over time if the
> >sweet spot moves to 8 CPUs or 32 CPUs, the same code will still run. You
> >gave the primary process a cluster, it does not need to know how many
> >CPUs, or how much cache, or what the clock speed was.
> >
> >The huge benefit is that you only need one MMU/L1/L2 per cluster. The
> >MMU is a huge piece of die real estate, (and heat) as is the L1 and L2.
>
> But you still get process isolation, right?
I am fairly indifferent about process isolation inside a cluster.
I figure that generally you are running the same code on 1000 items.
So a programmer gets a cluster sand box that is all his property.
The OS would wait for all threads to finish before reseting the sandbox
and giving the cluster to another process group.
One could argue that this wastes CPUs, but thats antiquated thinking,
you have THOUSANDS of these wimpy CPUs, in HUNDREDS of clusters, the
last thing you want is some irresponsible memory thrashing process
trying to "share" your CPU cluster with you. That would FAIL.
To pull this off you need KISS at all levels, the OS would not care
about individual CPUs, the OS only cares about clusters, and with
hundreds of clusters it has its hands full as it is.
> Why not take an OS that runs _only_ in the gpu clusters, and
> let whatever stuff is sold with the machine handle the "main" cpu?
> This is a stellar chance to migrate "below the radar".
GPUs do not run real code, they run code fragments on pixels/data.
Your CPU runs the ATI OS code to manage the ATI GPU.
> A "logarithmical" layout, 16 cpus, 4 L1, 1 L2 may be a way to
> go.
I like this.
> >In the game industry we are running out of things we can hand off to the
> >GPU, even if that GPU is relatively bright.
>
> Is this because of need for serial speed ("big" cpus), memory footprint,
> or organisational issues where you simply do not have an os and scheduler
> for running the gpu units as if they were a large set of normal cpus?
Legacy issues of old spaghetti code designed a decade ago, and grown
into a modern Godzilla nightmare. And I have it easy compared to the
poor losers at EA who are using code two decades old, that was never
actually "designed" to begin with...
ArarghMai...@not.at.arargh.com
<reply-...@nospam.org> wrote:
>ArarghMai...@NOT.AT.Arargh.com wrote:
>> On Mon, 26 Oct 2009 05:09:02 -0500,
>> ArarghMai...@NOT.AT.Arargh.com wrote:
>>
>>> On 26 Oct 2009 08:30:25 GMT, Andrew Reilly
>>> <andrew-...@areilly.bpc-users.org> wrote:
>>>
>>>> On Mon, 26 Oct 2009 01:29:17 -0500, ArarghMail910NOSPAM wrote:
>>>>
>>>>> On Mon, 26 Oct 2009 04:43:21 GMT, Brett Davis <gg...@yahoo.com> wrote:
>>>>>
>>>>> <snip>
>>>>>> x86 started with base+bounds, even giving a plentiful set of offset
>>>>>> registers. Almost no one used it, and those registers were recycled for
>>>>>> other uses.
>>>>> It did? x86? When? Where? Any Docs? <snip>
>>>> That's more or less how the 286 MMU worked, and (I think) versions of QNX
>>> That's not how I remember it, but I will dig out the manual and see.
>> Drat. Can't find the 286 manual.
I thought I had one. I found the 386 manual, and the 86/88/186/188
manual.
>
>There are 286 manuals here:
>http://www.ragestorm.net/downloads/286intel.txt
>http://datasheets.chipdb.org/Intel/x86/286/datashts/intel_M80C286.pdf
>(page 12 has the descriptor formats)
Thanks. I spent some time looking for these with no luck.
> From the manual section 6.4:
>"Finally, the segment descriptor contains the physical base address of
>the target segment, as well as size (limit) and access information. The
>processor sums the 24-bit segment base and the specified 16-bit offset
>to generate the resulting 24-bit physical address."
>
>One could argue, that the 286 was the first x86 with an MMU, and
>therefor the statement the x86 started with base+bounds would be correct.
Yes, I guess so.
What confused me was:
"even giving a plentiful set of offset registers. Almost no one used
it, and those registers were recycled for other uses."
I don't remember "plentiful set of offset registers" or "any registers
being recycled".
> I have found memories of my 286 and its protected mode. I remember it
>worked pretty well in windows 3.0 (286 protected mode got removed
>shortly after with the only choice being real or 386 protected) and I
>was unhappy when they removed it, as the only other choice was 386
>protected mode which ran significantly slower on my machine.
A 386SX-16 perhaps? :-)
I still have some 286 systems -- I wonder if any still work?
Brett Davis
"Del Cecchi" <delcecchi...@gmail.com> wrote:
> "Brett Davis" <gg...@yahoo.com> wrote in message
> > Do you need a main CPU if your GPU has 400 processors?
> >
> > The answer for Windows and Unix is yes you need a CPU, but for OS/X
> > I am
> > not so sure. For the next generation of game consoles if you could
> > throw
> > out the CPU you could cut your costs in almost half, with no loss in
> > performance if done correctly...
> >
> > Apple could pull this off, (iConsole?) Sony might try and fail,
> > anyone else would get laughed at, its to hard.
>
> You might note that Sony has in the past utilized quite competent cpu
> and core and chip designers. I would guess they are still around.
>
> del
Sony is a good company to work for with a high clue quotient.
Sonys problem is that they want to crush the competition with superior
technology, at high costs, and then wait for the tech curve to push
those costs down and finish off the competitors.
Worked great for PS1 and PS2, which faced the typical idiots for
competitors. Did not work so well with the PS3, which faced some clued
up competitors.
Using the PS2 as a template I predicted almost exactly what the PS3
would look like years before it came out. I had done the same for the
PS4 and as a result have discounted them as a force in the future... ;)
That prediction for the PS4 was made 3 years ago, times change, the ship
date for the PS4 has slipped a few years, and Sony has joined the
Larrabee camp.
You made me throw out the CPUs in my old PS4 prediction. Sony is now
clearly in the cluster camp, using Larrabee and NVidia, no real CPU.
So instead of triple high cost parts, its double, going up against
Apples cheap-o home grown CPU clusters, and cheap-o embedded or ATI GPUs.
Microsoft of course buys IBMs mini cluster CPUs and ATI GPUs.
(cheap-cheap)
Then there is Nintendo who will ship something that looks like a copy of
the previous generation of consoles, again.
This is a rerun of the third generation console war, except with four
players. This is not happy time as far as EA and Activision share
holders are concerned. They want some winners, or at least some losers
to whittle down the field to reduce costs and increase profits.
Brett
Andy "Krazy" Glew
Years ago, I overheard one of the CUDA architects say "Nvidia will never
have virtual memory".
For some time, I took that to mean that Nvidia did not do page based
address translation.
Eventually I learned that Nvidia does do page based address translation.
Classic TLBs. However, no page faults.
While I agree that page faults to disk may not need to be supported, I
suspect that page fault tricks like COW (Copy On Write) are so
ubiquitous that they must be supported to have a reasonable chance of
running modern software well.
Mayan Moudgill
> While I agree that page faults to disk may not need to be supported, I
> suspect that page fault tricks like COW (Copy On Write) are so
> ubiquitous that they must be supported to have a reasonable chance of
> running modern software well.
There are several OSes (including, IIRC, HP-UX) which do not permit
multiple virtual addresses to point to the same real address. I'm
guessing that they've managed to work around the CoW trick somehow.
ChrisQ
> In article <il1hr6-...@laptop.reistad.name>,
> Morten Reistad <fi...@last.name> wrote:
>
>> In article <ggtgp-4FCC6C....@netnews.asp.att.net>,
>> Brett Davis <gg...@yahoo.com> wrote:
>>> The future of CPU based computing, mini clusters.
>
>>>>> Do you need a main CPU if your GPU has 400 processors?
>>> So you design your hardware around 16 CPU clusters, and your OS, and
>>> your apps around the same paradigm. If you do it right, over time if the
>>> sweet spot moves to 8 CPUs or 32 CPUs, the same code will still run. You
>>> gave the primary process a cluster, it does not need to know how many
>>> CPUs, or how much cache, or what the clock speed was.
>>>
>>> The huge benefit is that you only need one MMU/L1/L2 per cluster. The
>>> MMU is a huge piece of die real estate, (and heat) as is the L1 and L2.
>> But you still get process isolation, right?
>
> I am fairly indifferent about process isolation inside a cluster.
> I figure that generally you are running the same code on 1000 items.
> So a programmer gets a cluster sand box that is all his property.
> The OS would wait for all threads to finish before reseting the sandbox
> and giving the cluster to another process group.
This was done in the 70's. Motorola built a cmos 1 bit microprocessor in
a 16 pin dip package for embedded industrial control work. A friend at
ibm told me that someone had built a computer using 1000 of these
devices, but no other details. Part no was MC 14500 and still have the
manual somewhere.
Maybe it's all been done before in hardware terms, but the software
issues still remain to be addressed and are the main stumbling block to
progress...
Regards,
Chris
Chris Gray
> There are several OSes (including, IIRC, HP-UX) which do not permit
> multiple virtual addresses to point to the same real address. I'm
> guessing that they've managed to work around the CoW trick somehow.
The restriction may be in the MMU. My memories of this are pretty vague,
but wasn't it (and the one in Power?) a "reverse lookup", which actually
mapped physical pages to virtual pages, instead of the other way around?
There could be only one such entry for a physical page. So, as Mayan
carefully says, you can't have multiple virtual addresses associated
with one physical address. However, that doesn't stop multiple address
spaces from having that physical page in them - it just must be at the
same virtual address in all of them (and perhaps the same modes).
It too long since I worked on the Myrias PAMS stuff, but I think there
was something extra that we had to do under HP-UX that we didn't have
to do under AIX. It may have related to the ability to nuke entire
virtual segments under AIX, however.
--
Experience should guide us, not rule us.
Chris Gray c...@GraySage.COM
http://www.Nalug.ORG/ (Lego)
http://www.GraySage.COM/cg/ (Other)
Anne & Lynn Wheeler
Mayan Moudgill <ma...@bestweb.net> writes:
> There are several OSes (including, IIRC, HP-UX) which do not permit
> multiple virtual addresses to point to the same real address. I'm
> guessing that they've managed to work around the CoW trick somehow.
the problem can be when there is some sort of virtual cache (i.e. cache
lines are virtual address associative) ... here is old email describing
the "logical directory" (mixture of virtual and real addresses) for 3090
cache:
http://www.garlic.com/~lynn/2003j.html#email831118
in this old post
http://www.garlic.com/~lynn/2003j.html#42
where the virutal addresses are "STO" associative ... effectively address
space identifier. there was work in original 370 architecture allowing
for "PTO" associative i.e. STO (segment table origin) points to a unique
"Segment table" for each address space; the segment table contains
segment table entries which are PTOs (page table origin) pointing to
page table for each segment. If different virtual address spaces did
sharing by pointing to the same segment (i.e. pagetable) and if the
cache was PTO associative ... then there wouldn't be a problem ... even
if the same shared segment appeared at different virtual addresses in
different virtual address spaces.
I had done a lot of stuff originally on cp67 for page mapped filesystem
and virtual sharing ... even sharing the same thing at different virtual
addresses (or even having the same thing appearing multiple times in the
same virtual address space at different virtual addresses). old email
discussing migrating the changes from cp67 to vm370:
http://www.garlic.com/~lynn/2006v.html#email731212
http://www.garlic.com/~lynn/2006w.html#email750102
http://www.garlic.com/~lynn/2006w.html#email750430
--
40+yrs virtualization experience (since Jan68), online at home since Mar1970
Morten Reistad
Brett Davis <gg...@yahoo.com> wrote:
>In article <il1hr6-...@laptop.reistad.name>,
> Morten Reistad <fi...@last.name> wrote:
>> >The huge benefit is that you only need one MMU/L1/L2 per cluster. The
>> >MMU is a huge piece of die real estate, (and heat) as is the L1 and L2.
>>
>> But you still get process isolation, right?
>
>I am fairly indifferent about process isolation inside a cluster.
>I figure that generally you are running the same code on 1000 items.
>So a programmer gets a cluster sand box that is all his property.
>The OS would wait for all threads to finish before reseting the sandbox
>and giving the cluster to another process group.
I am thinking about the possibility to take this one step further;
and look into if it is possible to run _all_ of the system inside
the GPU. If each cluster is on the order of a Via C3 in processing
power this should be perfectly feasible.
Using a few handfuls of clusters as the "main cpu". To have any
hope of running "modern" code like, say QNX, or Version 7 unix,
we need a minimal MMU. Not fancy demand paging; simple process
isolation with base+offset registers does nicely; the 80286 ran
both of these well.
So, basic process isolation 286-style is a basic requirement.
>One could argue that this wastes CPUs, but thats antiquated thinking,
>you have THOUSANDS of these wimpy CPUs, in HUNDREDS of clusters, the
>last thing you want is some irresponsible memory thrashing process
>trying to "share" your CPU cluster with you. That would FAIL.
>
>To pull this off you need KISS at all levels, the OS would not care
>about individual CPUs, the OS only cares about clusters, and with
>hundreds of clusters it has its hands full as it is.
In my world, this OS would be a hypervisor for something resembling
netbsd, where the BSD sees a few scores of processors.
>> Why not take an OS that runs _only_ in the gpu clusters, and
>> let whatever stuff is sold with the machine handle the "main" cpu?
>> This is a stellar chance to migrate "below the radar".
>
>GPUs do not run real code, they run code fragments on pixels/data.
>Your CPU runs the ATI OS code to manage the ATI GPU.
Seems memory is an issue.
Exactly how tight is memory in the GPU?
>
>> A "logarithmical" layout, 16 cpus, 4 L1, 1 L2 may be a way to
>> go.
>
>I like this.
>
>> >In the game industry we are running out of things we can hand off to the
>> >GPU, even if that GPU is relatively bright.
>>
>> Is this because of need for serial speed ("big" cpus), memory footprint,
>> or organisational issues where you simply do not have an os and scheduler
>> for running the gpu units as if they were a large set of normal cpus?
>
>Legacy issues of old spaghetti code designed a decade ago, and grown
>into a modern Godzilla nightmare. And I have it easy compared to the
>poor losers at EA who are using code two decades old, that was never
>actually "designed" to begin with...
Well, perhaps we can get KLH up and running.
-- mrr
Morten Reistad
I ran QNX on the 286'es, and got very good results too. One BBS
even ran 30+ logged in users on a noname china-clone in late 1986,
with lots of resources left except for memory. 1.5 megabyte was
a little tight for 30 users, even then.
The process size has 64k limits on I,D,stack and mapped data,
but the message passing made it possible to make servers to handle
common tasks.
It has a stellar scaling performance. So, this is where I
would start to look if we are to press farms of GPUs into service
as general purpose computers.
-- mrr
Del Cecchi
You might note that IBM did all three console chips for the third
generation. Sony is using Larrabee and NVidia for fourth generation?
Where did you hear that?
Del Cecchi
> Mayan Moudgill <ma...@bestweb.net> writes:
>
>> There are several OSes (including, IIRC, HP-UX) which do not permit
>> multiple virtual addresses to point to the same real address. I'm
>> guessing that they've managed to work around the CoW trick somehow.
>
> The restriction may be in the MMU. My memories of this are pretty vague,
> but wasn't it (and the one in Power?) a "reverse lookup", which actually
> mapped physical pages to virtual pages, instead of the other way around?
> There could be only one such entry for a physical page. So, as Mayan
> carefully says, you can't have multiple virtual addresses associated
> with one physical address. However, that doesn't stop multiple address
> spaces from having that physical page in them - it just must be at the
> same virtual address in all of them (and perhaps the same modes).
>
> It too long since I worked on the Myrias PAMS stuff, but I think there
> was something extra that we had to do under HP-UX that we didn't have
> to do under AIX. It may have related to the ability to nuke entire
> virtual segments under AIX, however.
>
EricP
> Mayan Moudgill <ma...@bestweb.net> writes:
>
>> There are several OSes (including, IIRC, HP-UX) which do not permit
>> multiple virtual addresses to point to the same real address. I'm
>> guessing that they've managed to work around the CoW trick somehow.
>
> The restriction may be in the MMU. My memories of this are pretty vague,
> but wasn't it (and the one in Power?) a "reverse lookup", which actually
> mapped physical pages to virtual pages, instead of the other way around?
> There could be only one such entry for a physical page. So, as Mayan
> carefully says, you can't have multiple virtual addresses associated
> with one physical address. However, that doesn't stop multiple address
> spaces from having that physical page in them - it just must be at the
> same virtual address in all of them (and perhaps the same modes).
>
> It too long since I worked on the Myrias PAMS stuff, but I think there
> was something extra that we had to do under HP-UX that we didn't have
> to do under AIX. It may have related to the ability to nuke entire
> virtual segments under AIX, however.
>
The IBM PPC 603 and 604 used inverted (hashed) paged tables,
however Linux expects to be able to have shared virtual sections.
Linux expects its page tables to be a 3 level tree a-la x86 style.
The linux port (below) treats the hash table like a second level TLB,
and retains the x86 page tables as the "official" look up.
A hardware TLB miss loads from the hash table.
A hash table miss triggers a page fault, which looks in
the x86 page tables, loads the hash table and restarts.
On process switch the hash table is cleared, just like a TLB.
However rather than scanning the hash table to clear out
old entries, the 603/604 supported Address Space IDs on PTE's
so they just use a counter as the ASID each time they switch
and the old entries won't match.
(Alternately, has there not been ASIDs, they could use a small
circular FIFO list to track the valid entries in the hash table).
see
Optimizing the Idle Task and Other MMU Tricks
http://www.usenix.org/events/osdi99/full_papers/dougan/dougan.pdf
Eric
Anne & Lynn Wheeler
re:
http://www.garlic.com/~lynn/2009p.html#19 The future of CPU based computing, mini clusters.
I've periodically claimed that John's 801/risc in the mid to late 70s
some past posts
http://www.garlic.com/~lynn/subtopic.html#801
was to to to the opposite hardware extreme from the (failed/canceled)
future system effort ... some past posts
http://www.garlic.com/~lynn/submain.html#futuresys
801/iliad/romp/rios started out 32bit virtual addresses ... with 16
segment registers (top four bits of virtual address would access one of
16 segment registers). The segment register would contain a "segment id"
(12bits in romp, 24bits in rios) ... which would be used to provide
"associativity" (TLB).
in 370, TLB (and potentially virtual cache) would be "STO" associative
... basically the real address of the start of the address space
"segment table". 370 hardware could implement a "STO stack" ... say
seven entries saving the most recently used STOs. TLB (STO-associative)
entries would have 3-bit tag ... indicating invalid entry ... or
association with one of the seven entries from the STO stack.
801 with inverted tables ... didn't have a corresponding hardware tables
for uniquely identifying virtual address space ... so explicitly defined
an virtual address spaced identifier ... or actually a virtual address
space segment identifier (a combination of 16 values used to create a
virtual address space definition). The ROMP 12-bit "identifier" roughtly
corresponded to the 3bit STO-stack identifier in (some) 370 hardware
implementations. However, being a segment identifier ... it corresponds
closer to the "PTO" identifier mentioned in the previous post (allowed
for in the original 370 architecture definition ... but I don't believe
there was actually any such 370 implementation).
There were some issues with only 16 segment registers ... that it
limited number of concurrent different shared objects for sharing. In
original 801, there was no protection domain ... and the claim was that
inline code could as easily change the value in one of the virtual
segment registers ... as address pointers in general registers could be
changed. This ran into little more difficulty in the transition
to using 801 for unix ... and requirement to implement hardware
protection domain.
Mayan Moudgill
> The future of CPU based computing, mini clusters.
I've been figuring out how to answer this, given that a real answer
would require a lot of background, and would have to be heavily
qualified. So, some things I say may not seem well justified, or
soundcategorical where it should be conditional. And of course,
everything is approximate.
The problem that (IMO) they are trying to tackle is the diconnect
between compute capacity on one hand and memory bandwidth and latency on
the other.
To put things in perspective, lets see what it would take to keep the
floating point pipelines fully occupied. Assume a 2GHz clock.
* A floating point pipeline can sustain ~2Gops/cycle. Assuming 1
output/2 inputs per cycle and dual precision operations, it needs 48
GB/sec.
* A floating point pipeline has a depth of ~5-8 cycles. This means that
there must be 5-8 independent floating point operations available for
full utilization.
* (External, DRAM) Memory is about ~200 cycles for the initial access,
plus some delta for subsequent accesses (I know I'm being optimistic).
To cover this latency fully, we need 200 independent FP ops.
* Assuming Qimonda's GDDR5 part, each chip can supply 4GB/s with a chip
of size 64MB and ~60 pins. So, to get 48GB/sec, assuming 50% efficiency
(I'm being generous) one needs a minimum configuration of 1.5GB and 1440
pins.
These are all for *1* FP pipe. For 32 pipes, the bandwidth and the
resources required go up by 32.
One can use on-chip caches to work around some of the contraints. At
>1MB/1mm^2 (for 1T-SRAM/eDRAM), you can budget about 64MB on-chip. To
keep off-chip accesses reasonable, with 32 pipes, we probably want a
miss rate of less than 2%.
Now, the miss rate is application dependent, of course. But it is
imperative that whatever app you run on this processor fit be tailored
to have a resident set size of less than 64MB.
Lets assume that we can fit it so that we expect a miss rate of 1%. That
means that ~1 out of 30 ops will take (at least) 200 cycles to complete
[remember each FP op has 3 accesses in it]. Adding this to the length of
the FP pipe, and delay to access the various levels of the caches, and
we end up with an average latency of about 20 cycles per op. This means
that for one pipe, we probably need 20+ threads, and for 32 fp pipes we
need 640+ threads!
Each of those threads will need:
- registers (or some equivalent to hold state)
- I$ (not directly, but additional threads => more PCs => pressure on
the I$)
- higher level D$ (assumes that there is more than 1 level of D$;
assuming that we can meet the bandwidth using the 64MB D$, it is
arguable that we should not have any other D$. Among other things,
coherence is trivial).
>>How big and how capable is that CPU/GPU you have 400 compies of?
>
>
> Wimpy, only one quarter the speed of a "real" CPU at the same clock, or
> less, way less.
After balancing out these concerns, you are probably going to be left
with a processor that, for single threaded applications, should be
viewed as being closer to 100-250MHz.
> The tradeoff is you get ~25 times as many CPUs per die
> area.
The problem with these comparisons is that, for massively parallel
execution to work, you must still control the off-chip miss rate. After
that, multi-threading can kick in and hide memory hiearchy and pipeline
latencies.
However, if you can control the miss-rates, an alternative design such
as 4 convential cores augmented ny 8-way SIMD might be within 2x of the
performance of the multi-threaded structure, but have single core
performance with 2x of the best single core designs.
Brett Davis
Mayan Moudgill <ma...@bestweb.net> wrote:
> Brett Davis wrote:
> > The future of CPU based computing, mini clusters.
>
> I've been figuring out how to answer this, given that a real answer
> would require a lot of background, and would have to be heavily
> qualified. So, some things I say may not seem well justified, or
> soundcategorical where it should be conditional. And of course,
> everything is approximate.
>
> * Assuming Qimonda's GDDR5 part, each chip can supply 4GB/s with a chip
> of size 64MB and ~60 pins. So, to get 48GB/sec, assuming 50% efficiency
> (I'm being generous) one needs a minimum configuration of 1.5GB and 1440
> pins.
GDDR5, how quaint. ;)
I am assuming that in two to four years we start switching to embedded
RRAM. 8 gigs on die with multiple 1024 bit busses, etc.
> These are all for *1* FP pipe. For 32 pipes, the bandwidth and the
> resources required go up by 32.
We already have 1600 vector pipes on ATI chips, 400 CPUs is quite a bit
less potential flops.
Game software expands to use up all resources: RAM, flops, bandwidth.
Rendering is going to change from polys to raytracing or more likely
Reyes. (Sub-pixel sampling.) Reyes is cache friendly, it just needs an
order of magnitude more flops than today, to move from Pixar movies to
realtime on your PC.
Brett
Mayan Moudgill
> In article <4AE982F3...@bestweb.net>,
> Mayan Moudgill <ma...@bestweb.net> wrote:
>
>
>>Brett Davis wrote:
>>
>>>The future of CPU based computing, mini clusters.
>>
>>I've been figuring out how to answer this, given that a real answer
>>would require a lot of background, and would have to be heavily
>>qualified. So, some things I say may not seem well justified, or
>>soundcategorical where it should be conditional. And of course,
>>everything is approximate.
>>
>>* Assuming Qimonda's GDDR5 part, each chip can supply 4GB/s with a chip
>>of size 64MB and ~60 pins. So, to get 48GB/sec, assuming 50% efficiency
>>(I'm being generous) one needs a minimum configuration of 1.5GB and 1440
>>pins.
>
>
> GDDR5, how quaint. ;)
> I am assuming that in two to four years we start switching to embedded
> RRAM. 8 gigs on die with multiple 1024 bit busses, etc.
>
Embedded in 2 to 4 years *may* allow you to get to 128MB (256MB, *maybe*
on a really huge chip). On chip-only not happenning.
However, I am sure that in 2-4 years we will see increases in
bandwidth/pin and data/chip.
>>These are all for *1* FP pipe. For 32 pipes, the bandwidth and the
>>resources required go up by 32.
>
>
> We already have 1600 vector pipes on ATI chips, 400 CPUs is quite a bit
> less potential flops.
Agreed, with the caveat that they appeart to be SP pipes, not DP (its
320 DP pipes). And the clocking is less than 1GHz.
Redoing the memory demand for SP, we come up with ~1.5 TB/s to keep the
vector pipes filled, while the *peak* off-chip bandwidth is 1/10th that.
So, extracting performance is going to be a function of locality and
hit-rates.
> Game software expands to use up all resources: RAM, flops, bandwidth.
>
> Rendering is going to change from polys to raytracing or more likely
> Reyes. (Sub-pixel sampling.) Reyes is cache friendly, it just needs an
> order of magnitude more flops than today, to move from Pixar movies to
> realtime on your PC.
Raytracing, I understand. I'm not sure it's cache friendly, but at least
I know the basic algorithm. About Reyes, I'm woefully ignorant. I'll
have to do some reading before I can even ask some dumb questions.
nm...@cam.ac.uk
Mayan Moudgill <ma...@bestweb.net> wrote:
>Brett Davis wrote:
>
>> I am assuming that in two to four years we start switching to embedded
>> RRAM. 8 gigs on die with multiple 1024 bit busses, etc.
>
>Embedded in 2 to 4 years *may* allow you to get to 128MB (256MB, *maybe*
>on a really huge chip). On chip-only not happenning.
It depends slightly on what you mean by "embedded". Some people
classify the CPUs that go in printers and control aircraft as that.
Technically, I can't see a problem with 8 GB/package in 2-4 years,
if any suitable company wanted to make them, and whether a package
includes only one chip or several is a purely manufacturing detail.
But it WOULD mean facing up to some unpalatable decisions. It isn't
likely, but it's possible.
Regards,
Nick Maclaren.
Mayan Moudgill
> In article <4AEABE6C...@bestweb.net>,
> Mayan Moudgill <ma...@bestweb.net> wrote:
>
>>Brett Davis wrote:
>>
>>
>>>I am assuming that in two to four years we start switching to embedded
>>>RRAM. 8 gigs on die with multiple 1024 bit busses, etc.
>>
>>Embedded in 2 to 4 years *may* allow you to get to 128MB (256MB, *maybe*
>>on a really huge chip). On chip-only not happenning.
>
>
> It depends slightly on what you mean by "embedded". Some people
> classify the CPUs that go in printers and control aircraft as that.
To clarify, in this context, embedded = eDRAM/1TSRAM (embedded memory)
ChrisQ
>
> It depends slightly on what you mean by "embedded". Some people
> classify the CPUs that go in printers and control aircraft as that.
That's correct and embedded devices are already far more powerfull than
486 class x86 in terms of throughput. They have on chip ram, flash and
moderately high speed comms as well as other peripherals.
Assume an array of such devices, assigned a single thread each, there
would be no need for cache and interrupt requirements would be minimal.
How usefull would this be, assuming future developments could put enough
code space on chip and the comms problem between an allocation cpu and
the array could be solved ?...
Regards,
Chris
nm...@cam.ac.uk
Very, for suitable applications. But most existing ones would need
redesigning :-(
Regards,
Nick Maclaren.
Mayan Moudgill
Think transputer (on a chip, of course)
Andy "Krazy" Glew
The way to get enough code space for meaningful programs is... to have
an I$. Nick will probably say otherwise, from his massive experience,
but guys at the world's largest supercomputer customers contain this for me.
It's easier to deal with limited dates many than it is with codesize
lustrations and overlays, where line change can blow you out.
Although... I'm not so sure that data cache may not be worthwhile.
Perhaps not coherent caches; perhaps not strong memory ordering.
Andy "Krazy" Glew
And since programmer productivity is more after the battered, how likely
is this to happen?
Perhaps it will hopper as programmer pay falls , because of
globalization and the recession.
Brett Davis
> >>
> >>>The future of CPU based computing, mini clusters.
> >>
> > I am assuming that in two to four years we start switching to embedded
> > RRAM. 8 gigs on die with multiple 1024 bit busses, etc.
> >
>
> Embedded in 2 to 4 years *may* allow you to get to 128MB (256MB, *maybe*
> on a really huge chip). On chip-only not happenning.
I have made plentiful posts on RRAM/Memristor, here are the Wiki pages.
http://en.wikipedia.org/wiki/RRAM
http://en.wikipedia.org/wiki/Memristor
Look at that die picture, I am not talking 6 transistor SRAM, this has
no transistors. Makes a 6 transistor SRAM look like a vacuum tube, at
~25 times smaller. All the transistors are in the bottom layer, this can
be put on any layer. Quoted 100 gigabits per chip, I am assuming 1
square centimeter, and assuming 22nm, and then rounded down to get 8
gigaBYTES.
http://library.thinkquest.org/3308/transistor.jpg
http://1.bp.blogspot.com/_WibILqsOlLg/SqJSDM3P2KI/AAAAAAAAAZ0/bfkTBehOHek
/s320/sram.png
http://www.hardwarezone.com/img/data/articles/2004/982/transistor-6t_cell
.jpg
http://design.osu.edu/carlson/history/images/tubeandtransistor.jpg
> > We already have 1600 vector pipes on ATI chips, 400 CPUs is quite a bit
> > less potential flops.
>
> Agreed, with the caveat that they appeart to be SP pipes, not DP (its
> 320 DP pipes). And the clocking is less than 1GHz.
640 DP pipes in the 1600 SP ATI chip. (Not 800, every fifth pipe is
special.) And top bin 975 MHz parts are not much less than 1GHz. ;)
http://www.anandtech.com/video/showdoc.aspx?i=3643&p=5
You can do pairs of DP muls or adds per cycle, but only one DP MADD.
So the DP throughput is about a third of the SP.
> > Rendering is going to change from polys to raytracing or more likely
> > Reyes. (Sub-pixel sampling.) Reyes is cache friendly, it just needs an
> > order of magnitude more flops than today, to move from Pixar movies to
> > realtime on your PC.
>
> Raytracing, I understand. I'm not sure it's cache friendly, but at least
> I know the basic algorithm. About Reyes, I'm woefully ignorant. I'll
> have to do some reading before I can even ask some dumb questions.
http://en.wikipedia.org/wiki/Reyes_rendering
http://www.steckles.com/reyes1.html
http://www.kunzhou.net/2009/renderants-tr.pdf
As for ray tracing with about 8 copies of 8 sony Cell vector processors
expanded out to 16 SP wide, you could think about it. (Or Larrabee) That
gives you 64 wide vector processors, with I assume a quarter+ meg of RAM
each. Chop your scene up and farm out the geometry to that RAM, batch up
your ray trace vector bounces that bounce out, and feed the bounce
batches to the vector units that have the geo.
http://en.wikipedia.org/wiki/Cell_(microprocessor)
Assuming quad wide Element Interconnect Bus, (EIB) you get 100 GB/s per
Cell of bandwidth, times 64.
End result, you never touch main RAM, all computation is on chip.
Which is good because you only have ~25 GB/s to RAM.
Again, even without RRAM, your concerns about main RAM bandwidth are
quaint. ;)
If you do things right you only touch each page used of RAM once per
frame, for geometry loads and texture loads, and code loads. All the
writes go to the video card, and you run at 60+ fps.
Today of course that is not true, cache sizes and local RAM sizes are
too small, so you hit each used RAM page multiple times, and write a
fair bit out to RAM as well.
It could be argued that future CPUs need LESS bandwidth to RAM than
today!
Brett
Mayan Moudgill
> Mayan Moudgill <ma...@bestweb.net> wrote:
>
>>Brett Davis wrote:
>>
>>> Mayan Moudgill <ma...@bestweb.net> wrote:
>>>
>>>>>The future of CPU based computing, mini clusters.
>>>>
>>>GDDR5, how quaint. ;)
>>>I am assuming that in two to four years we start switching to embedded
>>>RRAM. 8 gigs on die with multiple 1024 bit busses, etc.
>>>
>>
>>Embedded in 2 to 4 years *may* allow you to get to 128MB (256MB, *maybe*
>>on a really huge chip). On chip-only not happenning.
>
>
> I have made plentiful posts on RRAM/Memristor, here are the Wiki pages.
>
> http://en.wikipedia.org/wiki/RRAM
> http://en.wikipedia.org/wiki/Memristor
>
> Look at that die picture, I am not talking 6 transistor SRAM, this has
> no transistors. Makes a 6 transistor SRAM look like a vacuum tube, at
> ~25 times smaller. All the transistors are in the bottom layer, this can
> be put on any layer. Quoted 100 gigabits per chip, I am assuming 1
> square centimeter, and assuming 22nm, and then rounded down to get 8
> gigaBYTES.
If it was 2-4 years away from deployment, someone would be talking about
trial runs etc. Could be, but my bet is at least decade - and that's if
it turns out to be viable. Anyone seen widespread MRAM deployment yet?
Also, the density figures are a little implausible. They have to be
assuming every cell is a minimum dimension. [Lets work the nummbers:
assuming a 2 lambda x 2 lambda cell in 22nm - 400Mb/mm^2, 16x16 chip -
yeah, about 100Gb].
Now for a sanity check: DRAM which can be made, IIRC, with a 6 or 8
lambda^2 cell. Question - why is no one talking about 50Gb DRAM chips in
22nm?
Oh and one more thing - don't expect your favorite competitor to silicon
to necessarily scale as well as silicon. Even when it theoretically
should, it'll need a lot of engineering, which it isn't necessarily
going to get.
>>>We already have 1600 vector pipes on ATI chips, 400 CPUs is quite a bit
>>>less potential flops.
>>
>>Agreed, with the caveat that they appeart to be SP pipes, not DP (its
>>320 DP pipes). And the clocking is less than 1GHz.
>
>
> 640 DP pipes in the 1600 SP ATI chip. (Not 800, every fifth pipe is
> special.) And top bin 975 MHz parts are not much less than 1GHz. ;)
>
> http://www.anandtech.com/video/showdoc.aspx?i=3643&p=5
>
> You can do pairs of DP muls or adds per cycle, but only one DP MADD.
> So the DP throughput is about a third of the SP.
BTW: I goofed here. I said 1.5 TB/s, its actually 15TB/s of arguments +
results for the 2 input/1 output SP ops (20TB/s if you're using MADD).
So the peak-bandwidth is 1/100th of the required data-rate. Your cache
hit rates had better be *REAL* good.
>
>>>Rendering is going to change from polys to raytracing or more likely
>>>Reyes. (Sub-pixel sampling.) Reyes is cache friendly, it just needs an
>>>order of magnitude more flops than today, to move from Pixar movies to
>>>realtime on your PC.
>>
>>Raytracing, I understand. I'm not sure it's cache friendly, but at least
>> I know the basic algorithm. About Reyes, I'm woefully ignorant. I'll
>>have to do some reading before I can even ask some dumb questions.
>
>
> http://en.wikipedia.org/wiki/Reyes_rendering
> http://www.steckles.com/reyes1.html
> http://www.kunzhou.net/2009/renderants-tr.pdf
>
> As for ray tracing with about 8 copies of 8 sony Cell vector processors
> expanded out to 16 SP wide, you could think about it. (Or Larrabee) That
> gives you 64 wide vector processors, with I assume a quarter+ meg of RAM
> each.
Assuming you are correct, you are talking about 8 copies x 8 processors
x 16-wide x 3.2GHz = 3.2 Tops. You're assuming that you have about 16MB
on chip.
> Chop your scene up and farm out the geometry to that RAM, batch up
> your ray trace vector bounces that bounce out, and feed the bounce
> batches to the vector units that have the geo.
How many shapes? polygons? triangles? points? can be stored in 256KB?
Will you need to convert shapes down to sub-pixel sized polygons, and
store some associated surface properties (color,etc.)? If so, what's a
typical metric (such as so many bytes per object) used?
Let me take a stab at it: a point probably has at least 10 values that I
can think of (coordiantes, normal,color), and probably a few more that I
am ignorant of. Assume its about 16 values, so 64B per point. That
means we can store a maximum of 4K points in 256KB, and a maximum of
256K points across the entire chip.
I'm assuming that one recursively splits the volume using something like
an oct-tree till you end up with a box containing a small enough number
of objects to fit in cache. Given a box and a set of rays entering the
box, you bounce the rays around the objects in the box, compute the set
of rays leaving the box, then pass that information to the adjacent boxes.
Hmmm....I wonder how many boxes we'll need. I have no clue here, so lets
start with a real WAG. You probably want to represent any object using a
sub-pixel mesh - lets say 4 points per pixel. Assume that the set of
objects fits 1/2 the screen. Lets say that we want to represent both
sides (otherwise, what's the point of ray tracing). Lets assume a
1920x1280 screen. So, thats about 10M points (is that high or low?). If
so, you end up with a few thousand boxes.
[BTW: how much memory does a ray require? I'm guessing its also at least
10 elements of information, and maybe more]
> http://en.wikipedia.org/wiki/Cell_(microprocessor)
>
> Assuming quad wide Element Interconnect Bus, (EIB) you get 100 GB/s per
> Cell of bandwidth, times 64.
>
> End result, you never touch main RAM, all computation is on chip.
> Which is good because you only have ~25 GB/s to RAM.
>
> Again, even without RRAM, your concerns about main RAM bandwidth are
> quaint. ;)
>
> If you do things right you only touch each page used of RAM once per
> frame, for geometry loads and texture loads, and code loads. All the
> writes go to the video card, and you run at 60+ fps.
>
Hmmm...clearly I don't understand how. The way I had visualized it, I
would end up processing a box multiple times - I would have rays leaving
a box, bouncing off an object in another box and re-entering the box.
Also, given bi-directional ray tracing, the light source(s) would
introduce rays that would go in the opposite direction than the
eye-based rays, and so would cause boxes to be evaluated differently
(and therefore more than once). With a few thousand boxes, under my
assumptions, one would end up swapping boxes in and out of the chip
repeatedly.
What am I missing?
nm...@cam.ac.uk
Andy \"Krazy\" Glew <ag-...@patten-glew.net> wrote:
>ChrisQ wrote:
>>
>> That's correct and embedded devices are already far more powerfull than
>> 486 class x86 in terms of throughput. They have on chip ram, flash and
>> moderately high speed comms as well as other peripherals.
>>
>> Assume an array of such devices, assigned a single thread each, there
>> would be no need for cache and interrupt requirements would be minimal.
>> How usefull would this be, assuming future developments could put enough
>> code space on chip and the comms problem between an allocation cpu and
>> the array could be solved ?...
>
>The way to get enough code space for meaningful programs is... to have
>an I$. Nick will probably say otherwise, from his massive experience,
>but guys at the world's largest supercomputer customers contain this for me.
You are getting increasingly ridiculous. That is completely irrelevant
to the point ChrisQ was making.
Regards,
Nick Maclaren.
nm...@cam.ac.uk
Brett Davis <gg...@yahoo.com> wrote:
>
>As for ray tracing with about 8 copies of 8 sony Cell vector processors
>expanded out to 16 SP wide, you could think about it. (Or Larrabee) That
>gives you 64 wide vector processors, with I assume a quarter+ meg of RAM
>each. Chop your scene up and farm out the geometry to that RAM, batch up
>your ray trace vector bounces that bounce out, and feed the bounce
>batches to the vector units that have the geo.
>
>http://en.wikipedia.org/wiki/Cell_(microprocessor)
>
>Assuming quad wide Element Interconnect Bus, (EIB) you get 100 GB/s per
>Cell of bandwidth, times 64.
>
>End result, you never touch main RAM, all computation is on chip.
>Which is good because you only have ~25 GB/s to RAM.
>
>Again, even without RRAM, your concerns about main RAM bandwidth are
>quaint. ;)
>
>If you do things right you only touch each page used of RAM once per
>frame, for geometry loads and texture loads, and code loads. All the
>writes go to the video card, and you run at 60+ fps.
>
>Today of course that is not true, cache sizes and local RAM sizes are
>too small, so you hit each used RAM page multiple times, and write a
>fair bit out to RAM as well.
>
>It could be argued that future CPUs need LESS bandwidth to RAM than
>today!
Er, games are not the ONLY important application! I frequently see
people where their primary limit is memory size, but where their code
still takes super-linear CPU time in the amount of memory.
There always have been applications that need a limited working
set. I once wrote a serious application that ran almost entirely
in a CPU's registers - all right, that was a Ferranti Atlas/Titan :-)
Regards,
Nick Maclaren.
ChrisQ
>
> There always have been applications that need a limited working
> set. I once wrote a serious application that ran almost entirely
> in a CPU's registers - all right, that was a Ferranti Atlas/Titan :-)
>
You could do that on some of the early pdp11's, which had all the
registers mapped into address space. The example I remember was a
simple core memory test program and may have been in one of the 11/05
manuals.
Back on topic, it just seems to me that the ever increasing complexity,
single core, is getting nowhere and a return to much simpler
architectures may be be a way forward. Embedded devices may not be
ideal, but might be a very low cost way to do some serious research on
parallel methods, which could be scaled up as the technology advances.
Some of the 50 mip devices cost a couple of ukp each or less in quantity
and they need almost no external hardware to function. Compared to
current desktop hardware, they are low power, simple devices. Code
normally executes from on chip pre programmed flash, sometimes with a
wait state or 2, but can also run from on chip ram, where there are
often no wait states required. Putting numbers into this, flash mem
sizes range up to a megabyte or so, with ram sizes up to 512 K bytes.
However, many have reasonably large (Gbyte) address spaces and have
external bus capability to allow more memory or peripherals to be connected.
The elephant in the room is of course the fundamental gulf between
present software methodology at the programmer interface (basically
serial) and parallel archhitectures of any kind. i don't think that
there will be much progress until that is bridged. The problem is one of
software and initially at least, there may need to be an abstraction
layer between the machine and programmer so that current code can
continue to work, while new methods are developed to take advantage of
the underlying parallel architecture...
Regards,
Chris
nm...@cam.ac.uk
ChrisQ <me...@devnull.com> wrote:
>
>> There always have been applications that need a limited working
>> set. I once wrote a serious application that ran almost entirely
>> in a CPU's registers - all right, that was a Ferranti Atlas/Titan :-)
>
>You could do that on some of the early pdp11's, which had all the
>registers mapped into address space. The example I remember was a
>simple core memory test program and may have been in one of the 11/05
>manuals.
Yes, but I wasn't cheating in that way - the machine I used did NOT
memory map registers - it had 128 registers, and used a special
register to allow register indexing.
Regards,
Nick Maclaren.
ChrisQ
> Yes, but I wasn't cheating in that way - the machine I used did NOT
> memory map registers - it had 128 registers, and used a special
> register to allow register indexing.
>
128 registers provides a bit more space then the pdp11's 8, but how did
your code work ?. The registers must have been sequential in some
accessable address space for the program counter to access them, or you
were doing something really clever like indirect execution through the
index ?. Not familiar with that architecture makes it more difficult guess.
Just how did it work ? :-)...
Regards,
Chris
Terje Mathisen
> http://en.wikipedia.org/wiki/RRAMhttp://en.wikipedia.org/wiki/Memristor
>
> Look at that die picture, I am not talking 6 transistor SRAM, this has
> no transistors. Makes a 6 transistor SRAM look like a vacuum tube, at
> ~25 times smaller. All the transistors are in the bottom layer, this can
> be put on any layer. Quoted 100 gigabits per chip, I am assuming 1
> square centimeter, and assuming 22nm, and then rounded down to get 8
> gigaBYTES.
That's bogus.
According to the same wiki link, there's no way to switch state
quickly for that memristor, due to very low mobility.
The testing described was at ~1Hz, which is a few orders of magnitude
below what you need for useful performance.
I.e. this might well work at some point in time, but not in "2-4
years", more like 10-20.
:-(
Terje
(who'd love to have a GB or so of embedded RAM/core. :-)
ChrisQ
Looks like it's already been done. Have you seen this ?..
http://www.tilera.com/products/TILE-Gx.php
A load of supporting software and development hardware platforms as well...
Regards,
Chris
Brett Davis
> >>>I am assuming that in two to four years we start switching to embedded
> >>>RRAM. 8 gigs on die with multiple 1024 bit busses, etc.
> >>
> > http://en.wikipedia.org/wiki/RRAM
> > http://en.wikipedia.org/wiki/Memristor
> >
> assuming every cell is a minimum dimension. [Lets work the nummbers:
> assuming a 2 lambda x 2 lambda cell in 22nm - 400Mb/mm^2, 16x16 chip -
> yeah, about 100Gb].
I wont complain if I only get 4gigs instead of 8. ;)
The big problem with bringing DRAM on chip is you end up with this 5
layer DRAM abutting your CPU chip with its 11 layers that use a
different process. Bottom layer is transistors, all the other layers are
wiring.
RRAM will use a small number of transistors (for sense/drive) with the
actual RAM added as more layers to an existing design. So you can
re-plot out your chip to give room for the few RRAM transistors. Unlike
all other RAM processes that use every bit of the transistor space.
A RRAM only chip would actually have 4 or so layers of RRAM to make
better use of the transistor layer. So the actual density could be
several times better than the 100Gb quote.
> > As for ray tracing with about 8 copies of 8 sony Cell vector processors
> > expanded out to 16 SP wide, you could think about it. (Or Larrabee) That
> > gives you 64 wide vector processors, with I assume a quarter+ meg of RAM
> > each.
>
> Assuming you are correct, you are talking about 8 copies x 8 processors
> x 16-wide x 3.2GHz = 3.2 Tops. You're assuming that you have about 16MB
> on chip.
I did not mean to imply that Sony would not increase the the 256k per
processor, Sony will add whatever is needed to make this a good platform.
> > Chop your scene up and farm out the geometry to that RAM, batch up
> > your ray trace vector bounces that bounce out, and feed the bounce
> > batches to the vector units that have the geo.
>
> How many shapes? polygons? triangles? points? can be stored in 256KB?
> Will you need to convert shapes down to sub-pixel sized polygons, and
> store some associated surface properties (color,etc.)? If so, what's a
> typical metric (such as so many bytes per object) used?
>
> Let me take a stab at it: a point probably has at least 10 values that I
> can think of (coordiantes, normal,color), and probably a few more that I
> am ignorant of. Assume its about 16 values, so 64B per point. That
> means we can store a maximum of 4K points in 256KB, and a maximum of
> 256K points across the entire chip.
The points are generated on the fly from the light sources, you only
need space for buffers of points streaming in and streaming out. 4k is
probably plenty, of course you also need RAM for geo and textures, etc.
> I'm assuming that one recursively splits the volume using something like
> an oct-tree till you end up with a box containing a small enough number
> of objects to fit in cache. Given a box and a set of rays entering the
> box, you bounce the rays around the objects in the box, compute the set
> of rays leaving the box, then pass that information to the adjacent boxes.
>
> Hmmm....I wonder how many boxes we'll need. I have no clue here, so lets
> start with a real WAG. You probably want to represent any object using a
> sub-pixel mesh - lets say 4 points per pixel. Assume that the set of
> objects fits 1/2 the screen. Lets say that we want to represent both
> sides (otherwise, what's the point of ray tracing). Lets assume a
> 1920x1280 screen. So, thats about 10M points (is that high or low?). If
> so, you end up with a few thousand boxes.
>
> What am I missing?
With that approach you just explained why "real" ray tracing in real
time is impossible for next gen, but I do games, and we cut corners
everywhere to do what others think is impossible. My assumptions are
different.
I am assuming current gen poly and texture budgets, if you hope to make
Ray Tracing viable. 10k poly characters with 1k square texture and 1k
square bump map, plus one more, and then of course the 1k square
accumulation buffer for the ray trace result. (Texture mapped on the
character.)
You have four of these characters on screen and thats half your poly and
texture budget, the visible landscape using all the rest.
"Real" ray tracing does things a little differently, and real time use
has some quality and drop out issues that are not acceptable to users.
With texture mapped ray results you can clean up the accumulation
textures before sending the results to a traditional rendering pipeline
to finish up. This is all a SWAG.
The real goal here is to get real soft shadowing that work right,
something that Reyes and others will not give you.
This looks really hard to chop up in a sensible manner to fit in Cell
RAM, might be why Sony switched to Larrabee, let the MMU handle the
block overlaps? Would that explain the large L2 cache on larabee, to
hold all that data?
> [BTW: how much memory does a ray require? I'm guessing its also at least
> 10 elements of information, and maybe more]
Not a fan of Ray Tracing, Reyes is better for the next gen, so I have
not run the numbers. Ray Tracing is next next gen, or next next next
gen, if ever. I did mention that Sony likes to intro new tech before its
ready, to crush the competition. (Bad idea, Microsoft is not scared,
Nintendo does not care, and Apple is used to selling slower hardware
with better marketing.)
Even on a PS4 with ray tracing I expect only 6 or so games on the
bleeding edge to use limited ray tracing, a quarter will use Reyes, and
the rest will be ports that use traditional rendering. SWAG.
Watch this demo of what a modern tessellation engine (ATI + DirectX 11)
can do. Does anyone need ray tracing or Reyes with this level of quality
being "free"?
http://pchardwareblips.dailyradar.com/video/hardware-tessellation-with-di
rectx-11-unigine-heaven/
Quality wise it will beat the crap out of low poly ray traced results.
Of course Sony could release something that makes my comments look like
an idiot babbling.
The best of both worlds is to use the ray trace accumulation buffers as
lighting/shadowing maps on tessellated geo. BINGO.
Brett
FYI: No one at my site is working with next gen hardware, or has any
info. I do not expect my site to ever work on next gen while it is
secret. (Everyone wants to work on platform launch titles, but those
titles always lose money, my bosses prefer to make money.) If I did I
would not be making these posts, too many paranoid suits around that
would veto my working on the platforms due to fears I would babble. Or
worse yet expose that the emperor has no clothes, that would interfere
with the marketing message...
FYI2: You will note I do not comment on current gen hardware, its all
wonderful, and I love all of them. Any hardware quotes are from
Wikipedia, if its not there, then I will not mention it. Once the PS4 is
real hardware and ships I will tell you its all happy wonderful
hardware, as I might want to work on it... ;)
Losers whine about hardware not being perfect, I make old hardware sing
tunes no one else thought they could. Embrace the hardwares point of
view, and you can modify old software to fit, making the impossible,
possible.
My opinion does not jive with others anyway, I do most of my work on the
PS2. A platform I love, due to its eccentricities, and which most
programmers despise, for the same reasons. ;)
Brett
nm...@cam.ac.uk
After 40+ years, I should have to check up on which algorithm it was
and reinvent the method. Basically, it was something that needed
a lot of combinatoric calculations on a small number of counts.
And, yes, you could index through the registers. The loading and
unloading was manual, of course.
Regards,
Nick Maclaren.
Bernd Paysan
> That's bogus.
>
> According to the same wiki link, there's no way to switch state
> quickly for that memristor, due to very low mobility.
>
> The testing described was at ~1Hz, which is a few orders of magnitude
> below what you need for useful performance.
If I recall correctly, the CNT with embedded iron shuttles is "good
enough" if you want hard-disk-like writes, but probably "orders of
magnitude too low" if you want DRAM-like writes (although the write
speed scales exponentially with voltage, so probably you just have to go
high enough with the write voltage). I would expect that memristors
will first be used as flash-like memories (essentially hard-disks),
until we find memristors fast enough to be used as main memory.
Hm, digging out the publication leads me here:
http://www.physics.berkeley.edu/research/zettl/pdf/361.NanoLet.9-
Begtrup.pdf
> I.e. this might well work at some point in time, but not in "2-4
> years", more like 10-20.
I don't think one can plan the availability of unobtanium. The current
state of research is to find a material that is suitable as memristor.
You can find one tomorrow, or not in 1000 years. Zettl's nanotubes with
embedded iron shuttles look much better than HPs titanium dioxide
memristors. They are also probably a lot harder to make ;-).
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
Terje Mathisen
> Terje Mathisen wrote:
> Hm, digging out the publication leads me here:
>
> http://www.physics.berkeley.edu/research/zettl/pdf/361.NanoLet.9-
> Begtrup.pdf
>
>> I.e. this might well work at some point in time, but not in "2-4
>> years", more like 10-20.
>
> I don't think one can plan the availability of unobtanium. The current
> state of research is to find a material that is suitable as memristor.
> You can find one tomorrow, or not in 1000 years. Zettl's nanotubes with
> embedded iron shuttles look much better than HPs titanium dioxide
> memristors. They are also probably a lot harder to make ;-).
The key point is that even if they do find the proper (easy to
manufacture, stable, cheap etc) material today, it will still take a lot
more than "2-4 years" to make it commonly available in the form of
embedded memory.
Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
Brett Davis
Del Cecchi <delcecchinos...@gmail.com> wrote:
> >> "Brett Davis" <gg...@yahoo.com> wrote in message
> >>> Do you need a main CPU if your GPU has 400 processors?
> >
> > Sony is a good company to work for with a high clue quotient.
> >
> > You made me throw out the CPUs in my old PS4 prediction. Sony is now
> > clearly in the cluster camp, using Larrabee and NVidia, no real CPU.
> >
> > So instead of triple high cost parts, its double, going up against
> > Apples cheap-o home grown CPU clusters, and cheap-o embedded or ATI GPUs.
> >
> You might note that IBM did all three console chips for the third
> generation. Sony is using Larrabee and NVidia for fourth generation?
> Where did you hear that?
I forgot Larrabee has texture units, so NVidia is out. I never
understood the NVidia pick in the PS3, not cost effective against ATI.
Heard that the original GPU was just more Cell units, do not know if it
even had any texturing units. Real software was written for it, but it
failed hard.
NVidia was picked weeks before the final Dev Tools were shipped, mere
months before hardware shipped for sale. Availability of millions of
large chips on short notice may be a factor. ATIs fab partner may have
been booked solid, (big XBox360 and Wii wins) and could not deliver.
So maybe the PS4 keeps PowerPC and the Cell units. Sony will not make a
choice for another year or so, so basically anything could happen.
I heard that for the PS2 Sony funded two different graphic designs, the
group that lost had no idea there was a 2nd design team. Likely IBM
offered a CPU design to get the PS2 business, which they finally won
with the PS3.
If you want a 3GHz processor, you have one choice, IBM, and IBM offers
good terms. 2nd best are ARM and MIPS at 1GHz and pretty pathetic
designs in comparison. My old PS4 prediction was 8 PowerPCs 4 way
threaded, with 4 to 8 rings of 8 Cells. (64 vector processors.) With
billion plus dollar design costs already paid for its hard for Sony to
walk away from this. (Whatever that design really is...) Or even fund
more than a skeleton rival team with a paper design. Then Intel shows up
and offers the Larrabee design for free?
I am aware that Sony and IBM have a joint design team, a large expensive
one that is ongoing. Many hundreds of millions a year spent jointly.
My own guess is that Larrabee became Sonys backup graphic team, and that
economic and performance comparisons against ATI will fail. Unless
Larrabee can do all three tasks; CPUs, Vectors, and GPU, with good
price/performance. (Bad news for your old co-workers.)
Then there is NVidia which will go bankrupt in the next year or so, Sony
may buy the remains... Might be something there that could ship in time
for PS4 graphics...
Do not trust insiders, when I was at Sony I was told that the PSP was
going to use PS1 hardware. I laughed at my boss, and told him he was
lied to. Anyone with a clue about hardware and Sony would have agreed
with me that the PSP would be a down clocked PS2, which is what shipped.
Sony wanted to keep this a secret, which is why the disinformation
campaign against Sonys own workers was instituted. From Sonys point of
view this bought them another 6 months before Nintendo could copy them,
so it would take a whole year before Nintendos version came out. Three
years later Nintendo still has not copied the PSP, and never will. The
inferior Nintendo hardware has been crushing the PSP in sales. Nintendo
knows its market better than Sony, $300 with $30 games is outside what
that market is willing to pay. Nintendo keeps making incremental
upgrades to keep the same price point at top, and down costing the old
hardware, to drive sales on the low end.
The PS3 failed on cost, due to NVidia, and Blue Ray and adding a Hard
Drive. Sony had no choice on NVidia, and Sony Pictures needs Blue Ray to
drive a movie replacement cycle. (Billion in movie sales to be made...)
That leaves the hard drive, Sony had plans for that as well, but it was
a bridge and cost too far.
Now that the PS3 is cheaper, it may take back 2nd place from XBox360.
With the sudden collapse of Wii sales I might say Sony has a shot at
first, but the Wii HD will likely revive the Wii enough to keep the
console #1 title. Nintendo had it waiting in the wings for just that
reason. Same strategy Nintendo uses in the handheld market, always have
an incremental upgrade ready. (Go to http://www.joystiq.com/ for the Wii
HD rumor, its hot off the press, and surprised me. I expected this to
ship in two years, when Sony and the others ship next gen...)
Nintendo seems to understand Sonys market better than Sony does...
The Rumor that started it all:
http://www.theinquirer.net/inquirer/news/1050851/intel-design-playstation
-gpu
http://news.softpedia.com/news/Intel-039-s-Larrabee-in-Sony-039-s-PS4-Bes
t-Fiction-Since-LOTR-104047.shtml
Larrabee links:
http://download.intel.com/technology/architecture-silicon/Siggraph_Larrab
ee_paper.pdf
http://www.bit-tech.net/news/hardware/2009/04/13/larrabee-die-size-is-mas
sive/1
http://www.geek.com/articles/games/intel-shows-first-fuzzy-die-pic-of-lar
rabee-intels-new-cpu-gpu-20090518/
Bernd Paysan
> The key point is that even if they do find the proper (easy to
> manufacture, stable, cheap etc) material today, it will still take a lot
> more than "2-4 years" to make it commonly available in the form of
> embedded memory.
Well, I'm a bit more optimistic about that. "Easy to manufacture" means
"fits into the current process flow", so it's essentially just another
process step - memristor inserted into a via - in a standard process. If
you ask the process guys "please grow multi-walled carbon nanotubes of 200nm
length with embedded iron shuttles in every via hole", then you'll get your
multi-year estimate with no guarantee to success, but if it's really just
something you can create with a standard CVD process step (like the titanium
oxide HP wants to use), it's not rocket science, and can be ported to other
fabs as well.
ChrisQ
Right, i've forgotten half the stuff I ever knew about the pdp11 and vax
and that's only 20 years ago.
Still, there does seem to be *real* progress in computer architecture,
despite the retentiveness of the major players. It seems that Tilera
processors will be on server motherboards within a year. A 100 cpu
'computing surface', if you like. No fpu, but i'm sure ways will be
found to utilise them for hpc none the less. Link is at:
http://www.theregister.co.uk/2009/11/02/tilera_quanta_servers/
How could you use that ?. It will be commodity prices as well...
Regards,
Chris
nm...@cam.ac.uk
Bernd Paysan <bernd....@gmx.de> wrote:
>Terje Mathisen wrote:
>> The key point is that even if they do find the proper (easy to
>> manufacture, stable, cheap etc) material today, it will still take a lot
>> more than "2-4 years" to make it commonly available in the form of
>> embedded memory.
>
>Well, I'm a bit more optimistic about that. "Easy to manufacture" means
>"fits into the current process flow", so it's essentially just another
>process step - memristor inserted into a via - in a standard process.
Well, yes, if you don't mind it not working or fouling up everything
else. There's more to engineering than just getting parts to fit
together.
>If
>you ask the process guys "please grow multi-walled carbon nanotubes of 200nm
>length with embedded iron shuttles in every via hole", then you'll get your
>multi-year estimate with no guarantee to success, but if it's really just
>something you can create with a standard CVD process step (like the titanium
>oxide HP wants to use), it's not rocket science, and can be ported to other
>fabs as well.
Rocket science is almost trivial; rocket engineering is hard. Quite
a lot of things are like that.
Regards,
Nick Maclaren.
Robert Myers
> Rocket science is almost trivial; rocket engineering is hard. Quite
> a lot of things are like that.
If X engineering is hard, it's almost because X science is missing or
incomplete.
That is, in my not so humble opinion, particularly true of rocket
science, which is anything but trivial.
Robert.
Del Cecchi
Sort of a strange article in Inquirer. Thanks for the pointers.
Del Cecchi
"Bernd Paysan" <bernd....@gmx.de> wrote in message
news:1588054.E...@elfi.zetex.de...
I think the point is that the material hasn't been defined yet and
until at least one suitable material has been identified the whole
idea is somewhat of a fantasy.
Remember Ovonics? Before solar cells they were going to make all
sorts of miraculous circuitry. Don't see much of it around.
del
Del Cecchi
ChrisQ
> On Nov 2, 7:48 am, n...@cam.ac.uk wrote:
>
>> Rocket science is almost trivial; rocket engineering is hard. Quite
>> a lot of things are like that.
>
> If X engineering is hard, it's almost because X science is missing or
> incomplete.
>
Sorry, no. While science can show that some physical process is possible
in theory, the engineering technology is not always there to build it,
since the engineering usually depends on a lot of other unrelated
technologies...
Regards,
Chris
dj3v...@csclub.uwaterloo.ca.invalid
Throw stuff in one direction, you move in the other direction.
That's rocket science. The rest is engineering.
There's a nontrivial amount of other types of science behind that
engineering, but 'tain't rocket science.
dave
--
Dave Vandervies dj3vande at eskimo dot com
I wouldn't pay anyone who used realloc like THAT, except perhaps to
clean the toilets.
--infobahn in comp.lang.c
Robert Myers
Most engineering that goes wrong is because most things are under-
engineered: the design was supported by inadequate analysis.
Sometimes the analytical capability doesn't exist (the science isn't
there) and sometimes people are just unwilling to spend the money.
I'm not now nor have I ever been a solid state physicist, but the
black art of device engineering seems to result from a lack of
adequate science, so that much of it is inspired guesswork and cut and
try. As far as I know, computational and theoretical device physics
aren't in very good shape, which makes the progress that does take
place even more amazing.
Rocket engineering is also a lot of inspired guesswork and cut and
try, sometimes with unwitting test pilots aboard the under-engineered
vehicle. Rocket science could be in much better shape, but no one
wants to spend the money.
Robert.
Robert Myers
> In article <d82693a7-864a-4fec-a676-5a94bf453...@j24g2000yqa.googlegroups.com>,
> Robert Myers <rbmyers...@gmail.com> wrote:
>
> >On Nov 2, 7:48 am, n...@cam.ac.uk wrote:
>
> >> Rocket science is almost trivial; rocket engineering is hard. Quite
> >> a lot of things are like that.
>
> >If X engineering is hard, it's almost because X science is missing or
> >incomplete.
>
> >That is, in my not so humble opinion, particularly true of rocket
> >science, which is anything but trivial.
>
> Throw stuff in one direction, you move in the other direction.
> That's rocket science. The rest is engineering.
> There's a nontrivial amount of other types of science behind that
> engineering, but 'tain't rocket science.
>
experience is in fluid mechanics, I must disagree. Getting a rocket
to lift off the pad without shaking everything to pieces is still a
hard problem. Returning things to earth from orbit is similarly a
hard problem. Cut and try is very expensive and sometimes fatal. The
science, such as it is, is far from being in hand, and, if there is
such a thing as rocket science, trying to understand what happens with
all the various fluids at launch and reentry would have to qualify.
Robert.
Brett Davis
Brett Davis <gg...@yahoo.com> wrote:
> > >>> Do you need a main CPU if your GPU has 400 processors?
> > >
> > > going up against
> > > Apples cheap-o home grown CPU clusters, and cheap-o embedded or ATI GPUs.
Apple has forecast a 70 percent increase in capital expenditures
http://www.appleinsider.com/articles/09/11/02/apples_2010_capital_expendi
tures_could_signal_major_investments.html
"This year's 10K added wording for purchases of 'product tooling and
manufacturing process equipment"
"A major $1.9 billion in capital expenditures during the 2010 fiscal
year. That's well up from the $1.1 billion the company spent in 2009."
These are the sorts of numbers and phrases that Sony posts for console
startup costs...
Brett
Del Cecchi
<dj3v...@csclub.uwaterloo.ca.invalid> wrote in message
news:hcn6u8$ert$1...@rumours.uwaterloo.ca...
I always wondered what "rocket science" was. F=MA? or turbulent flow
in hypersonic regime. Some things are scientifically easy but hard in
practice. All you have to do is deposit a 100 nm film uniformly over
the surface of that 300 mm wafer. All you have to do is make the bat
intersect the ball as it crosses the plate.
A lot of semiconductor stuff is in that category. You can do the
experiments to figure it out but that is essentially the engineering.
del
Del Cecchi
"Robert Myers" <rbmye...@gmail.com> wrote in message
news:94433a1b-fdc8-4739...@k19g2000yqc.googlegroups.com...
Robert.
---------------------------
How are you posting? It is very strange that your posts are the only
ones that outlook express doesn't properly put the marks on when I
reply. So I fire up thunderbird but that is a little annoying to have
to do that for a reply.
Any ideas as to what might be going on? Could it be google groups?
Robert Myers
wrote:
> <dj3va...@csclub.uwaterloo.ca.invalid> wrote in message
>
> news:hcn6u8$ert$1...@rumours.uwaterloo.ca...
>
>
>
>
>
> > In article
> > <d82693a7-864a-4fec-a676-5a94bf453...@j24g2000yqa.googlegroups.com>,
properties of solutions to the Navier-Stokes equations. Practical
consequences of understanding those equations include launch shake,
foam shedding, and the hazards of reentry. Computers play a big role,
which is why lots of fluid mechanicists are so involved with
computers. F=ma (or it's continuum mechanics equivalent, the Reynolds
transport theorem applied to mass, momentum, and energy) will take you
a long way, but the math is still hard. When you do turbulence, a lot
of stuff starts to look like quantum field theory, which is one reason
I am extremely skeptical of quantum voodoo.
I'm not a laboratory scientist. That was settled early on. I
calculate stuff, sometimes analyze data, and often do stuff that could
be regarded as either science or engineering. Nick works at the
University of Cambridge, where the University Press publishes the
Journal of Fluid Mechanics and there is a long and impressive history
of non-trivial contributions to the field. He really should have
known better.
Robert.
Robert Myers
wrote:
>
> How are you posting? It is very strange that your posts are the only
> ones that outlook express doesn't properly put the marks on when I
> reply. So I fire up thunderbird but that is a little annoying to have
> to do that for a reply.
>
> Any ideas as to what might be going on? Could it be google groups?
It's probably google groups, which doesn't seem to get high marks from
anyone. Honestly, Del, I spend so much of my time tending to computer
stuff and trying to remember passwords that it just isn't worth it to
me to have one more thing (a usenet account and yet another
application) to worry about.
On the other hand, why are you using outlook express? ;-)
Robert.
Niels Jørgen Kruse
That is rather weak evidence for a console launch. Where can Apple add
value to a console?
--
Mvh./Regards, Niels J�rgen Kruse, Vanl�se, Denmark
Del Cecchi
Robert.
Because it has a menu item for "block sender" while thunderbird is
more cumbersome.
It is just strange about the quoting. I just noticed that it was just
your posts that didn't get quoted correctly and wondered if you were
using something exotic.
del
nm...@cam.ac.uk
Robert Myers <rbmye...@gmail.com> wrote:
>
>Nick works at the
>University of Cambridge, where the University Press publishes the
>Journal of Fluid Mechanics and there is a long and impressive history
>of non-trivial contributions to the field. He really should have
>known better.
Oh, yes, I know that - our Engineering department is very highly
regarded for its work in that area. Now, what is it that I should
have known better? :-)
Yes, I know that DAMTP and Physics also work in such areas, but I
stand by my point, and I think that others agree with me.
Regards,
Nick Maclaren.
ChrisQ
>>
> Are you now, or have you ever been, a rocket scientist?
>
> Most engineering that goes wrong is because most things are under-
> engineered: the design was supported by inadequate analysis.
> Sometimes the analytical capability doesn't exist (the science isn't
> there) and sometimes people are just unwilling to spend the money.
>
> I'm not now nor have I ever been a solid state physicist, but the
> black art of device engineering seems to result from a lack of
> adequate science, so that much of it is inspired guesswork and cut and
> try. As far as I know, computational and theoretical device physics
> aren't in very good shape, which makes the progress that does take
> place even more amazing.
>
> Rocket engineering is also a lot of inspired guesswork and cut and
> try, sometimes with unwitting test pilots aboard the under-engineered
> vehicle. Rocket science could be in much better shape, but no one
> wants to spend the money.
>
> Robert.
Real world engineering is always a devils compromise between cost,
timescales, performance and available technology, while science builds
the theory that says something is possible.
Engineering is the process of translating abstract concepts into
physical reality. The science is only the starting point on the way to
building things that work. If you have ever done any discreet component
analog rf circuit design, for example, you would find that all the math
in the world won't describe a physical layout and circuit values that
are optimal. You use the science to model and calculate approximate
circuit values. add in previous experience and some assumptions, build
it, then fine tune layout and values to optimise the performance. There
are just too many variables to describe some things in any reasonable
mathematical way. Seems to me that a lot of engineering is like that.
I guess the philosophical point is that while engineering is constrained
by scientific limits, the creative part is what reconciles those limits
with the original vision of a working solution. The vision comes from
where ?. One could argue that that's part of the science as well, though
it can be more intuitive than analytical :-)...
Regards,
Chris
Robert Myers
> Real world engineering is always a devils compromise between cost,
> timescales, performance and available technology, while science builds
> the theory that says something is possible.
>
> Engineering is the process of translating abstract concepts into
> physical reality. The science is only the starting point on the way to
> building things that work. If you have ever done any discreet component
> analog rf circuit design, for example, you would find that all the math
> in the world won't describe a physical layout and circuit values that
> are optimal. You use the science to model and calculate approximate
> circuit values. add in previous experience and some assumptions, build
> it, then fine tune layout and values to optimise the performance. There
> are just too many variables to describe some things in any reasonable
> mathematical way. Seems to me that a lot of engineering is like that.
>
> I guess the philosophical point is that while engineering is constrained
> by scientific limits, the creative part is what reconciles those limits
> with the original vision of a working solution. The vision comes from
> where ?. One could argue that that's part of the science as well, though
> it can be more intuitive than analytical :-)...
I don't know how I got into this. If I see smoke rising from an
argument over definitions, I usually turn the car around and drive the
other way. ;-)
There are some important issues, although, in the end, arbitrary
labels are arbitrary labels.
Just as there are many different kinds of people, there are different
kinds of scientists and engineers with all kinds of different ways of
pursuing their vocations.
The characterizations of "rocket science" that got me into this are so
naive and wrong-headed that I just couldn't not say anything. Whether
you want to call it rocket science or rocket engineering, believe me,
it is not easy, as the US quickly learned as it tried to hurl into
space satellites that the Russians sneered at as "grapefruit." In the
process, US rocket scientists (actually, the German rocket scientists
we had captured) learned the hard way just how difficult it is to put
something even into into sub-orbital flight that might span
continents, never mind actually to put something into orbit around the
earth, and there were many spectacular failures to drive the point
home. Whether the US succeeded or failed was a very big deal, and the
stakes were much higher than most at the time appreciated. If anyone
had snotty thoughts or attitudes about "rocket science," they would
have kept them to themselves. That was the error of "duck and cover"
drills in grade school.
In such a context, all philosophical and dictionary considerations
seem silly. Whatever talent was available was put to work, and there
was a serious shortage of talent that was up to the task. Now, of
course, you could just shop it all out to India, but this is a
different world, because everyone else internalized the lesson that
the United States learned while the United States is now in the
process of aggressively forgetting so that the smartest people can use
their talents stealing from everyone else.
In *that* context, is there anyone here who deserves to be sneered
at? The departmental labels don't matter.
Both science and engineering should and do concern themselves with
identifying and asking questions worth exploring. That's a hugely
important skill and one that can't really be taught. Whether it's
science of engineering, someone in Cal-Trans has been making too many
assumptions and asking too few questions unrelated to money or
votes.
If you persist in trying to make class distinctions among people with
technical skills, you simply increase the likelihood that some hack
will be able to make mistakes without adult supervision. The nation
cares more about Michelle Obama's wardrobe than it does about the
competence of the technical people who supposedly take care of the
nation's infrastructure. There's not much glamor in fatigue or
fracture, but, believe me, it's *hard*. There is science,
engineering, mathematics, intuition, and just plain dumb luck (or the
lack of it, as in the San Francisco-Oakland Bay Bridge incident).
There is also theory and experiment, under whatever category you put
them.
Both science and engineering are constrained. You can make design
choices in science just as you can in engineering. That is
particularly true if you are a modeler. Neither scientist nor
engineer works with a free hand, and just exactly what the constraints
are varies wildly. Both scientist and engineers vary wildly as to how
they think, whether abstractly or in very concrete terms. Even those
who think concretely (and they can be found in both science and
engineering) have huge variations in what they think of as concrete.
Among those who think abstractly, examples of which can be found in
both science and engineering, also bring wildly differing cognitive
tools to whatever they do.
When you try to insist on distinctions, that potential benefit (many
different eyes and minds) becomes a huge liability. If everyone
thinks pretty much the same way, it might make for a more peaceful
workplace, but it very likely does not result in better science or
engineering, and you can't tell how someone thinks by looking at a
C.V. (degrees and job experience).
I remember Stephen Weinberg stopping himself in the middle of a
lecture hall peroration to comment, as if to no one, that he was
pontificating. He was, and I didn't understand a word of it. I'll
stop.
Robert.
Robert Myers
> In article <30b13890-50c6-4b47-8ed4-99769f847...@o10g2000yqa.googlegroups.com>,
> Robert Myers <rbmyers...@gmail.com> wrote:
>
>
>
> >Nick works at the
> >University of Cambridge, where the University Press publishes the
> >Journal of Fluid Mechanics and there is a long and impressive history
> >of non-trivial contributions to the field. He really should have
> >known better.
>
> Oh, yes, I know that - our Engineering department is very highly
> regarded for its work in that area. Now, what is it that I should
> have known better? :-)
Fluid mechanics, in whatever department it is taught, is a scientific
discipline. I believe that Harvard teaches it in the "Engineering
Science" department.
Robert.
Terje Mathisen
> Fluid mechanics, in whatever department it is taught, is a scientific
> discipline. I believe that Harvard teaches it in the "Engineering
> Science" department.
Robert, isn't the interesting/relevant part of Fluid Mechanics the fact
that almost all interesting flow regimes are impossible to solve
exactly, so even the science part of it becomes a set of simplified
equations for various hopefully interesting subsets?
If so, then even those calling it science are doing engineering imho, in
the form of finding mathematical simplifications that give useful results?
I guess I'm saying that the boundary between science and engineering is
rather fluid.
no one
nos...@ab-katrinedal.dk (Niels J�rgen Kruse) wrote:
> > Apple has forecast a 70 percent increase in capital expenditures
> > http://www.appleinsider.com/articles/09/11/02/apples_2010_capital_expendi
> > tures_could_signal_major_investments.html
> >
> > "This year's 10K added wording for purchases of 'product tooling and
> > manufacturing process equipment"
> >
> > "A major $1.9 billion in capital expenditures during the 2010 fiscal
> > year. That's well up from the $1.1 billion the company spent in 2009."
> >
> > These are the sorts of numbers and phrases that Sony posts for console
> > startup costs...
>
> That is rather weak evidence for a console launch. Where can Apple add
> value to a console?
Two words: App Store.
Apple has a near monopoly on download music sales, which in a few short
years may be the only way people buy music.
Apple wants to expend this franchise to movie downloads, but has ZERO
presence in the living room of your home. Sony used the PS2 to help push
DVD sales, and is now using the PS3 to push BlueRay.
The iConsole is a Trojan horse to sell you movies, and while its there
in your living room it can serve as a hub for your iPod and iPhone and
iTouch as well as your iGames and iMovies, while you watch your iTVShows.
The iTV (Tivo/DVR clone) Apple sells was the prelude, a testbed for the
technology. To get movie downloads tested, build out the hardware and
software and licensing issues.
Apple has been planning this for years. Two years ago Apple bought
PA-semi which was selling a low power 8 core PowerPC chip that it
designed to military customers. Apple co-owns the PowerPC design, so
there are no licensing costs, which everyone else pays. A few months ago
Apple signed a unlimited license to GPU cores from firm with a low power
Tile engine renderer. (Same chip used in the iPhone/iTouch.) Easy enough
to plop 16 of these tiny tile engines on a chip to drive a high res
display. Apple wrote a physics engine for this graphics chip, overkill
for iPhone, but needed for any console. All the pieces are coming
together.
Apple HATES rumors like this, I just got added to the top of their shit
list.
Robert Myers
> Robert Myers wrote:
> > Fluid mechanics, in whatever department it is taught, is a scientific
> > discipline. I believe that Harvard teaches it in the "Engineering
> > Science" department.
>
> Robert, isn't the interesting/relevant part of Fluid Mechanics the fact
> that almost all interesting flow regimes are impossible to solve
> exactly, so even the science part of it becomes a set of simplified
> equations for various hopefully interesting subsets?
>
> If so, then even those calling it science are doing engineering imho, in
> the form of finding mathematical simplifications that give useful results?
>
> I guess I'm saying that the boundary between science and engineering is
> rather fluid.
>
I was trying to make that argument among others in my longer post.
Every branch of science has pure and applied incarnations.
Engineering is the odd beast because it invents rather than studies,
but every branch of applied science finds its way into some kind of
engineering. A natural scientist does not have the luxury of
designing the object of his interest: the natural world is a given.
When a scientist invents a new abstraction, though, he's doing
something very much akin to what an engineer does: he designs
something that is more or less useful for an intended purpose, and
more or less ex nihilo, even if while standing on the shoulders of
giants.
Science v. engineering isn't all that helpful a distinction for those
of us who live in the world of applications, but there are
incarnations of fluid mechanics that are most definitely pure science--
certainly if you allow mathematics to be a science. If it's not a
science because mathematics isn't a science, then it's a branch of
mathematics. It has nothing whatever to do with the mechanical
engineering, aero engineering, or chemical engineering departments
when you are doing, say, astrophysical fluid dynamics and the
equations are still the same, maybe only with more phases and/or the
MHD approximation. Engineers and scientists both wrestle with
radiative transfer.
Judicious approximation and idealization are practically hallmarks of
good science. No planet orbits the sun in an ellipse, but it's a
helpful idealization. For back of the envelope estimates, both
scientists and engineers will be happy to ignore the eccentricity of
the orbit entirely and put the sun or the earth at the center of a
circle and even to ignore the fact that neither the earth nor the sun
is an inertial frame, even though almost no geophysical fluid
mechanics can ignore the rotation of the earth.
The equations of fluid mechanics are the first three moments of the
Boltzmann equation. The infinite hierachy is closed at the first
moment for incompressible flow by adding viscosity, which is a form
of what field theorists call renormalization. If you do turbulence
theory, you get a similar hierarchy with more elaborate methods of
attempting to renormalize, none of which seem as natural or to work as
well as viscosity (but no one knows why the low order closure of the
Navier Stokes equations seems to work so well). To me, all these
equations look so much alike that the distinctions people make seem
artificial. You can attempt Feynman diagram methods for turbulent
flow, but they turn out to be just a low Reynolds number expansion.
If I learn a trick in one field, why shouldn't I get mileage out of it
wherever a similar circumstance occurs?
The idea that it's all so hard that you might as well just throw it
onto the computer and stop losing sleep may well have seized the
imagination of managers who don't like uncertainty, but the most
popular codes make some really crude approximations that couldn't be
fixed even if anyone really knew how to do satisfactory turbulence
modeling, and someone whose insight goes deeper than the input
necessary to run a code is necessary to see when those problems are
leading to unrealistic results. Is that science or engineering? I
think it's science. The design decisions you make based on the
predictions and whatever uncertainty is inherent in them is
engineering. I've done both. Am I a scientist or an engineer?
Yes, computer architecture is hard, and there is the inevitable
tension between those who idealize and those who have to make it
work. Fluid mechanics is a teensy branch of nineteenth century
physics, but, at that, the field could never be mastered in its
entirety by anyone I've ever known. And it's just one piece of
"rocket science."
Robert.
Niels Jørgen Kruse
> In article <1j8lqqu.1yn99k5ia0k5bN%nos...@ab-katrinedal.dk>,
> nos...@ab-katrinedal.dk (Niels J�rgen Kruse) wrote:
>
> > > Apple has forecast a 70 percent increase in capital expenditures
> > > http://www.appleinsider.com/articles/09/11/02/apples_2010_capital_expendi
> > > tures_could_signal_major_investments.html
> > >
> > > "This year's 10K added wording for purchases of 'product tooling and
> > > manufacturing process equipment"
> > >
> > > "A major $1.9 billion in capital expenditures during the 2010 fiscal
> > > year. That's well up from the $1.1 billion the company spent in 2009."
> > >
> > > These are the sorts of numbers and phrases that Sony posts for console
> > > startup costs...
> >
> > That is rather weak evidence for a console launch. Where can Apple add
> > value to a console?
>
> Two words: App Store.
Download is an established distribution model for game consoles and
Wintel games too. This is not new.
> Apple has a near monopoly on download music sales, which in a few short
> years may be the only way people buy music.
>
> Apple wants to expend this franchise to movie downloads, but has ZERO
> presence in the living room of your home. Sony used the PS2 to help push
> DVD sales, and is now using the PS3 to push BlueRay.
>
> The iConsole is a Trojan horse to sell you movies, and while its there
> in your living room it can serve as a hub for your iPod and iPhone and
> iTouch as well as your iGames and iMovies, while you watch your iTVShows.
iPhone games are hardly suitable for running on a console. The interface
is too different.
It is true that Apple wants to get into video distribution and that
Apple TV is the preferred vehicle for getting it to your TV.
Video playback however, is well suited for special purpose hardware and
there is no need for anything special in the CPU.
> Apple has been planning this for years. (...) All the pieces are coming
> together.
This is what they all say when going off the deep end. Cringely is one
of the most prolific in cranking out this kind of speculation. Read it
for entertainment.
Bernd Paysan
> Robert, isn't the interesting/relevant part of Fluid Mechanics the fact
> that almost all interesting flow regimes are impossible to solve
> exactly, so even the science part of it becomes a set of simplified
> equations for various hopefully interesting subsets?
Hm, the only science I know where you can solve some interesting problems
exactly is math. Fluid Mechanics is a many-particle problem, and of course
it requires approximations of all sorts. Even the basic idea that particles
stay as they are is not true inside the rocket engine: There e.g. 2*H₂+1*O₂
gives 2*H₂O, i.e. only two thirds of the molecules entering the engine leave
it on the other side.
Brett Davis
Apple touts Itunes TV to broadcasters
http://www.theinquirer.net/inquirer/news/1561300/apple-touts-itunes-tv-br
oadcasters
$3.6 billion a year, most of it profit, a chance at far more.
Brett Davis
"Del Cecchi" <delcecchi...@gmail.com> wrote:
> >> Where did you hear that?
> >
> > The Rumor that started it all:
> > http://www.theinquirer.net/inquirer/news/1050851/intel-design-playstation-gpu
> >
> > http://news.softpedia.com/news/Intel-039-s-Larrabee-in-Sony-039-s-PS4-Best-Fiction-Since-LOTR-104047.shtml
> >
> > Larrabee links:
> >
> > http://download.intel.com/technology/architecture-silicon/Siggraph_Larrabee_paper.pdf
> >
> > http://www.bit-tech.net/news/hardware/2009/04/13/larrabee-die-size-is-massive/1
> >
> > http://www.geek.com/articles/games/intel-shows-first-fuzzy-die-pic-of-larrabee-intels-new-cpu-gpu-20090518/
> >
> > http://forum.beyond3d.com/showthread.php?t=54144
>
> Sort of a strange article in Inquirer. Thanks for the pointers.
IBM kills off Cell processor development
http://www.fudzilla.com/content/view/16530/1
That looks like confirmation that Sony has signed the
contract for Larrabee.
Sorry about your friends at IBM.
Now we get to speculate on if some "real" CPUs are included.
I say absolutely no.
And on if a "real" graphics chip is included. I say yes.
The yes side says the Larrabee rendering engine is just
for ray trace shadow maps, still need a display engine.
On a cost/performance basis ATI offers a deal that cannot be beat.
The no side says Sony is willing to have the slowest graphics
for next gen. Yeh, right. NOT.
Next gen consoles ship about ~2 years from today.
Brett
Terje Mathisen
> IBM kills off Cell processor development
> http://www.fudzilla.com/content/view/16530/1
>
> That looks like confirmation that Sony has signed the
> contract for Larrabee.
> Sorry about your friends at IBM.
>
> Now we get to speculate on if some "real" CPUs are included.
> I say absolutely no.
> And on if a "real" graphics chip is included. I say yes.
I think you're wrong.
> The yes side says the Larrabee rendering engine is just
> for ray trace shadow maps, still need a display engine.
> On a cost/performance basis ATI offers a deal that cannot be beat.
Obviously untrue, otherwise we'd be reading about how that Sony console
would use AMD/ATI instead of Sony. It is of course possible that Intel's
total manufacturing cost is higher than AMDs, but Intel has the
financial strength to offer Sony a 'deal they couldn't refuse'.
> The no side says Sony is willing to have the slowest graphics
> for next gen. Yeh, right. NOT.
Brett, I know absolutely nothing about any Sony/LRB deals, but the only
way I can see that making any sense at all is if Intel supplies a single
multicore chip that handles both OS and graphics.
For general computing I'd probably prefer that to be a hybrid (say 2 x
Core i7 + 32 x LRB), but I really cannot see any reason why a game
console would need any fast (& powerhungry) cores at all.
Sony lost (from all the accounts I've read) several G$ on PS3 because it
was too expensive to manufacture, and the cost didn't ramp down quickly
enough. Getting rid of one of the two large chips makes a lot of sense
to me.
Noob
> IBM kills off Cell processor development
> http://www.fudzilla.com/content/view/16530/1
cf. also
http://arstechnica.com/hardware/news/2009/11/end-of-the-line-for-ibms-cell.ars
Brett Davis
Terje Mathisen <Terje.M...@tmsw.no> wrote:
> Brett Davis wrote:
> > IBM kills off Cell processor development
> > http://www.fudzilla.com/content/view/16530/1
> >
> > That looks like confirmation that Sony has signed the
> > contract for Larrabee.
> > Sorry about your friends at IBM.
> >
> > Now we get to speculate on if some "real" CPUs are included.
> > I say absolutely no.
> > And on if a "real" graphics chip is included. I say yes.
>
> I think you're wrong.
>
> > The yes side says the Larrabee rendering engine is just
> > for ray trace shadow maps, still need a display engine.
> > On a cost/performance basis ATI offers a deal that cannot be beat.
>
> Obviously untrue, otherwise we'd be reading about how that Sony console
> would use AMD/ATI instead of Sony. It is of course possible that Intel's
> total manufacturing cost is higher than AMDs, but Intel has the
> financial strength to offer Sony a 'deal they couldn't refuse'.
A monopoly is in business to make money, Intel is only willing to
write off design costs, on expectations of future profits.
Chips cost real money, and are not subsidized. Intels manufacturing
costs are little different than anyone else using the same fab
tools.
> > The no side says Sony is willing to have the slowest graphics
> > for next gen. Yeh, right. NOT.
>
> Brett, I know absolutely nothing about any Sony/LRB deals, but the only
> way I can see that making any sense at all is if Intel supplies a single
> multicore chip that handles both OS and graphics.
I never said that there would be more than one chip. It is likely as
the economics of two smaller chips is better for the first few spins.
(The next PS3 model will have 1 chip, same as PS2 which also started
as two chips and has been one for years now.)
> For general computing I'd probably prefer that to be a hybrid (say 2 x
> Core i7 + 32 x LRB), but I really cannot see any reason why a game
> console would need any fast (& powerhungry) cores at all.
The name of the game is computation per square mm of chip. A Core i7
is at best four times faster than a Larrabee core at simple math,
while using 16+ times the mm. Not going to happen.
ATI has twice the computation per mm as NVidia, as for Intel graphics
my knowledge in that area is as weak as typical Intel graphics. ;)
Intel seems to think their graphics is good, maybe it is.
I base my SWAG on the current Larrabee die photo which had pretty
small amounts of mm devoted to pixels. But my knowledge is limited,
and that may not be the final design.
> Sony lost (from all the accounts I've read) several G$ on PS3 because it
> was too expensive to manufacture, and the cost didn't ramp down quickly
> enough. Getting rid of one of the two large chips makes a lot of sense
> to me.
The PS3 was too expensive because of Blue Ray and the hard drive,
neither of which went down in cost as expected. Burdens XBox360 and Wii
do not have. They hoped PS2 style volumes would make back the costs.
The two big chips cost no more than the two big chips in the first PS2,
and are going down in cost as expected. XBox360 also has two big chips,
that cost much the same as Sonys. The coming Wii_HD will be about the
same, two now medium sized chips.
May as well compare Ford, GM and Honda, and argue over Cubic inches
and fit and finish. Little in the way of rocket science here.
Any company with 10 billion in the bank and a few hundred software
engineers and can jump in this market, if they so desire.
> Terje
Brett