AMD's first 'Fusion' processor isn't due until mid-2009, but specs are leaking out. Given how AMD has touted its 'native' multi-core designs, AMD's next-gen part isn't as integrated as you'd expect The chip, codenamed 'Swift', brings together CPU and GPU. However, according to Taiwanese mobo-maker moles, cited by Chinese- …
"the boot is now firmly on the other foot"
Do Intel have a CPU+GPU on a single slab of silicon?
"acronym is APU - Accelerated Processing Unit."
Isn't it also the acronym for Armoured Personnel Unit, as per the Matrix trilogy?
But where are the main stream 64 bit apps? That's been how many years of 64bit computing potential and we are still stuck in a rut with main stream 32bit OS and apps.
multicore 64bit CPUs and now soon APUs totally crippled on a 32 bit OS running 32 bits apps, is it just me or can anyone else see how pathetic this is?
Some lazy sods somewhere needs to get their fingers out and get this sorted.
AMD's I have a Dream moment, whets the Appetite with APUType Processor ....? :-)
"What should we read into that, we wonder? " ....:-) The Head Cases have Virtually taken over the Asylum would be one Prime Valid Reading, which would Really also need ACcompanying Drivers for Embedded and Embedding Consolidation ....... thus Assuring Market Lead which then Delivers Naturally Increased Market Share and PreDominant and Pre-Eminent Position.
Could we add a further graphics card to boost performance? Or woudl that slow things down or be entirely unsupported?
So, it will have a separate bus for graphics memory, and then separate DIMM slots required on the mobo for graphics memory? As well as the slots and bus(ses?) for ordinary CPU memory? If it's going to be shared memory like a lot of current integrated graphics it will stink and sink unless it is just aimed at the budget market. Sounds like fun making that faster than a graphics card with its own local memory, but I suppose they could still pull it off. And hopefully the mobos to go with it will have room to spare for all the extra DIMM slots for a non-shared memory solution.
But I do like the idea of having the two separate dies in one ceramic as it will make it a lot easier to evolve the designs in parallel, which means an upgrade to the graphics chip can be made without affecting the CPU core and vcie versa, the change is simply made at the ceramic packaging point. Of course, making a Crossfire version just means putting another GPU core in the same ceramic package..... Hey, how about a dual-core and two GPU cores in one package..... or a quad and four.... Oh, now I like it!
Surely its Kang...
Aimed at latpots, betnooks, etc
Targeted at laptops and the like, this could be a killer. It will save the OEMS a lot of cash and should be quite power efficent too. I can imagine the GPU core using system memory, but sat next to the CPU there shouldnt be too much latency involved.
This certainly wont make any headway with the enthusiast crowd tho, who love their add-in graphics too much ;)
Griffin Mobile Processors, Apu graphics chips
Anyone else think AMD have been watching too many cartoons?!
AMD- Our new chips are Kwik-er than the oppositions'!
AMD- Griffin isn't as s-Lois as our competitors for getting to market.
Undoubtedly there are more puns to come
nerdism: Taking A=1,B=2,C=3......G=7, then C+G=10 (which is J).
Therefore JPU, or Joint Processing Unit.
Surely that would be the best possible name. Not only satisfying our requirements around calling something what it is, but also making some spuriously slightly logical sense.
I'll get my coat
Re: Memory Bus(es)
AMDI MVNGwy from shared memory for graphics. The current 780G and 780M chipsets have dedicated VRAM onboard. There will be no "slots" for the VRAM, it will be attached directly to the PCB just like with Sideport VRAM with the 780G/780M MBs now.
This setup alos allows for better cooling since most of the heat is being generated in one area and thus be vented out more efficiently. Current laptop desings rely one elaborate heatpipe designs to get the heat out. Imagine if you had just a single simple fan and heatsink ported out the back? Makes for FAR MORE efficient cooling.
Wrt 64 bit apps... 64 bit XP, 2003 and I think Vista all exist. Linux was 64 bit from almost the moment the Opteron was released. 64 bit UNIXes have been around for at least 20 years (OSF/1). IBM DB2 and Oracle are 64 bit for many years. It's not a short list.
Of course 32 bit XP still dominates on the desktop but that's probably got more to do with that it's so hard to find a copy of 64 bit XP to pirate ;-)
food, dont you just love it
"a new bus codenamed 'Onion'. The GPU's link to the on-board memory controller is called 'Garlic', apparently."
hmm would you want to take a byte of that, perhaps you might consider a nibble, but perhaps you can only manage a bit.
that 128 bus doesnt sound to good for the long term or even the short does it!
I don't know what you have been smoking.... but, Joint Processing Unit, I don't think it will fly ;-)
What about a quad core CPU + 4 GPU cores and AMD's HPC GPU API stack? Some serious computational power!
Intel Beat Up AMD with Poor Engineering - AMD's Turn
"Swift's 'Kong' graphics core is separate die built into the CPU package."
"Does this matter? From a technology standpoint, not much, and from a business perspective it's a smart move."
People did not care that some generations of Intel multi-cores were multiple pieces of silicon glued together into the same carrier... AMD took a beating over trying to architect it right!
Well, it appears AMD has taken a play from Intel's playbook - design unique junk and it will be bought because it is cheaper.
It is too bad that people care more about cost than rewarding good engineering - but that is the world we live in.
Perhaps the next generation will be a real system on one chip.
I thought APU was the Audio Processing Unit. You know, those OPL and EMU chips used in soundcards to offset CPU MIDI/Audio processing...
to Anonymous Coward - no 64 bit apps or 64 bit OS? Get a Real OS
An Anonymous Coward said:
"But where are the main stream 64 bit apps? That's been how many years of 64bit computing potential and we are still stuck in a rut with main stream 32bit OS and apps."
"multicore 64bit CPUs and now soon APUs totally crippled on a 32 bit OS running 32 bits apps, is it just me or can anyone else see how pathetic this is?"
Hope you didn't missed the boat - 32 bit users have been transitioning to 64 bit in the Open arena ( http://www.sparc.com/ ) for almost 20 years now. 64 bit users have been in 8 core open source CPU's ( http://www.opensparc.net/ ) for years now. People have used 32 bit and 64 bit applications on a 64 bit OS ( http://www.solaris.com/ ) for 10 years now.
When you run a 64 bit operating system like Solaris (for commercial support), or OpenSolaris (to compile and tweek the source code yourself) - it will run all of your old 32 bit code (transparently) and give you the option of running 64 bit code (when you run into a jam!)
Heck, you can even run various OS's in virtualized containers ( http://opensolaris.org/os/community/brandz/ ) with virtually no overhead and no licensing costs of virtual machines.
Yes, Solaris and OpenSolaris will run on your AMD x64 or Intel x64 platforms - and even on your 32 bit proprietary platforms.
While the rest of the market is struggling to get a foothold in the 64 bit world, the Open System market is moving to 256 bit capability ( http://opensolaris.org/os/community/zfs/ ) with ZFS.
It has been time to move on from old 32 but technology for a decade, it is now time to move up to 64 bit & 256 bit computing capabilities on over a dozen cores ( http://www.itjungle.com/tug/tug041708-story01.html ) with many dozens of threads.
RE: David Halko
No, what matters to business (and probably to most home users) is that the job gets done at the lowest cost, with the least hassle. How it is engineered is irrellevant, as long as it does the job. This is how x86 stole into the server market in the first place, by doing a reasonable job a lot cheaper than proprietary UNIX offerings such as Solaris on SPARC. Over-engineering for the sake of cleverness rarley pays off, unless it gives you a market advantage. In this case, comparing Intel and AMD's approach, it looks like the smarter engineering decision to do the two-in-one rather than both-as-one option, as it will probably get AMD's solution to market first with a clear advantage. Introducing Solaris and SPARC into the conversation is just whimsical - since when has anyone shown any interest in a Niagara-based or SPARC-based laptop? And as for Sun's graphical ability, that was surpassed by the average Xeon workstation years ago.
And as to your waffle about Slowaris and "real operating systems", the challenge there would be to find anything that runs on any version of Solaris that doesn't run better, faster and cheaper on Linux, let alone Windows, and probably the Linux version will have been around a lot longer, have a far superior community support, and viable commercial support options too if you so wish. And as for desktop apps for Slowaris x86? Please, don't make me laugh!
Let's be real here and recognise that Windows vastly dominates the desktop, so let's push the Penguin into the water for a start (yes, yes, it's wonderful, better than Windows, OS X, and whatnot)...
The main issue with 64bit Windows is the lack of support by software and more importantly hardware manufacturers. Drivers really are the big problem.
Another important point is that 64bit doesn't automatically mean faster & better. It's just a wider address and register space. For computational purposes, 32bits is just fine for most things the majority do with a PC. In terms of memory, few need more than a couple of gig at present anyway (and remembering most software is bloatware consuming far more than required). In graphics it's another matter but then we have GPUs with more "bits" than CPUs anyway for this.
Just simply compiling your favourite app in 64 bits and running it on a 64 bit processor isn't going to make it any better or faster though generally. Not to mention that many of the current 64 bit processors are optimised for 32 bit performance.
Should also be noted that it took the DOS/Windows world quite a long time to move up to 32bit. Whilst NT was the first of Microsoft's 32bit line, the majority sat on DOS and Win 3.1 for years (with some hybrid 32bit layering available later on), before finally the masses adopted 32bit Windows 95 (and even then it was still essentially a hybrid 16/32 OS). True 32bit from the core adoption by the masses in Windows didn't happen until XP!
to Matt Bryant - SUN Sells Linux and Solaris; Solaris 10 is not slow
Matt Bryant asks, "since when has anyone shown any interest in a Niagara-based or SPARC-based laptop?"
Since the release of the first 64 bit 8 core CPU from SUN, back in 2006. Many would love to see a T1 or T2 based laptop, it would be another "first" for the computer industry (i.e. the first 8 core laptop.) The following page illustrates why:
SUN has been about stateless Thin Clients for almost a decade. In a similar fashion, SUN was about disk-less workstations in their first decade.
WiFi Ultra-Thin Client laptops on the market from various partners which work with SUN systems based upon proprietary AMD & Intel or various Open Source SPARC systems.
All those 32 bit and 64 bit software applications that people wanted to run were possible through this architecture... and that was the target of my original comment. SUN has been where people wanted to be for 64 bit applications on 64 bit operating systems on 64 bit architecture.
Matt Bryant asks, "And as for Sun's graphical ability, that was surpassed by the average Xeon workstation years ago."
I am not sure what your point is, since SUN sells high-performing proprietary AMD and proprietary Intel workstations with Linux, Solaris, and Windows support.
SUN seems to have a pretty robust line of graphic cards for quite some time, as well.
I guess Matt is trying to say that SUN has passed SUN eons ago.
Matt says, "as to your waffle about Slowaris and 'real operating systems', the challenge there would be to find anything that runs on any version of Solaris that doesn't run better, faster and cheaper on Linux"
This has not been the case since January 2005.
Solaris is free, linux is free, so Linux being cheaper (in price) is incorrect. Solaris support seems to be less expensive than various Linux support vendors, however.
As far as "better": if you are looking for visibility into running processes, Solaris 10 has DTrace, which is superior to Linux; if you are looking for large filesystems, ZFS under Solaris 10 is far superior to file systems offered under Linux (unless you like to sit around for days, waiting to make use of a 48 terabyte file system under Linux instead of minutes under Solaris... but that might qualify as faster & better.)
It seems Solaris is just as fast as Linux, in regular benchmarking, done by trade journals.
"Solaris 10 is as fast as its Linux competition... The numbers posted by Solaris 10 and RedHat Enterprise Linux AS 4.0 in our series of Web transactional tests, in which both were running Apache 2.0.3 on the same Polywell 64-bit server,were very close across the board. We did find that Solaris had a small performance advantage when tested on Sun's own V20z box."
The performance benefits since Solaris 10 have found their way into legacy SPARC platforms, as well.
"Many of the major features built into Solaris 10... Key improvements include faster networking technology that Sun has built into the TCP/IP stack. Fike said the networking enhancements have "dramatically improved" the performance of network-intensive applications that run on Solaris-based systems at FedEx."
Seems for other real world applications, Solaris is superior.
VoIP - http://www.thrallingpenguin.com/articles/asterisk-solaris.htm
"By employing your converged voice/data on the Solaris 10 operating system, you are able to increase the number of concurrent calls on equivalent hardware."
Linux shops have been enjoying the performance enhancements of Solaris, as well.
"The Real Time Matrix Corp. faced something of a dilemma. As a small company with 15 employees and contractors, Real Time Matrix was a die-hard Linux shop. But the company's computing processing needs quickly surpassed its size."
"On a 64-bit AMD processor and Fedora, we could process approximately 200 matches per second of RSS," Whitehead said. "With Solaris 10 on the T1000, this match rate jumped to 10,000 per second."
If it is a small single core embedded system, Linux may outperform Solaris, but Solaris on the same modern day hardware will usually be faster than Linux. The throughput performance gap widens in favor of Solaris significantly when multi-core CPU's are benchmarked.
This comparison, is silly, however, since SUN is a Solaris and Linux vendor.
Matt suggests, "and probably the Linux version will have been around a lot longer, have a far superior community support, and viable commercial support options too if you so wish. And as for desktop apps for Slowaris x86?"
SUN has been selling Solaris based systems for 20 years, Linux applications did not really exist back then, so longer seems to be a silly comparison.
I guess Linux users really have GNOME, which is shipped on Solaris desktops as well as Linux desktops.
Are you suggesting that SUN's OpenOffice desktop application Solaris is not as good as Linux? (That would be rather silly!)
Is the community support for SUN's MySQL is superior under Linux because MySQL is different under Linux than Solaris?
(Commercial vendor support from SUN is offered to both Solaris & Linux communities, by the way.)
Perhaps, if you could discuss what is slower under Solaris than Linux, that would be a good starting point. I could not find any meaningful benchmarks to support your assertion.
The reality of the situation is... SUN sells Linux as well as Solaris on the desktop, so suggesting that one of SUN's desktops is better than another of SUN's desktops is not very significant.
to TimM - Windows does not dominate 64 bit
TimM says, "Let's be real here and recognise that Windows vastly dominates the desktop... The main issue with 64bit Windows is the lack of support by software and more importantly hardware manufacturers. Drivers really are the big problem."
Let's be real here and recognize that Windows does not dominate the 64 bit market.
You want 64 bit applications on a 64 bit operating system with 64 bit driver support.
Pick the operating system and platform to support your application requirement.
If your application does not support a real operating system, you picked the wrong application.
I have been using 64 bit operating systems for years and using 64 bit applications when we hit 32 bit memory boundaries (3.75 Gig under Solaris, 2 Gig under other operating systems.)
It is all about architecture.