AMD Launches Radeon E6760: The Next Embedded Radeonby Ryan Smith on May 2, 2011 12:01 AM EST
Lately we’ve been working on expanding our GPU coverage to include more GPUs that are only sold as part of a package. Up until now we’ve mostly focused on 4 classes of GPUs: Desktop, Mobile/IGP, High Performance Computing (HPC), and we’ve spent some time dabbling with System on a Chip (SoC) GPUs for smartphones/tablets/netbooks. This range of products mostly covers the different GPUs seen in consumer products and in commercial supercomputing, but there is still a large gap in there for non-consumer business uses. This is the embedded market, and today we’re expanding our GPU coverage to include those GPUs.
Kicking off our coverage of embedded GPUs is AMD’s Radeon E6760, which is launching today. The E6760 is the latest and greatest AMD embedded video card, utilizing the Turks GPU (6600/6700M) from AMD’s value lineup. The E6760 isn’t a product most of us will be buying directly, but if AMD has it their way it’s a product a lot of us will be seeing in action in the years to come in embedded devices.
|AMD Radeon E6760||AMD Radeon E4690||AMD Radeon E2400|
|Memory Clock||800MHz (3.2GHz data rate) GDDR5||700MHz (1.4GHz data rate) GDDR3||700MHz (1.4GHz data rate) GDDR3|
|Memory Bus Width||128-bit||128-bit||64-bit|
|Manufacturing Process||TSMC 40nm||TSMC 55nm||TSMC 65nm|
|MCM Package Size||37.5mm x 37.5mm||35mm x 35mm||31mm x 31mm|
As we mentioned previously, the E6760 is based on the Turks GPU. Specifically, AMD’s embedded video cards are based on their mobile products, so the E6760 is derived from the 6700M series both in performance and naming. For the sake of consistency we’re going to be referring to the E6760 as a video card – AMD refers to it as a GPU, but this confuses the product (processor + RAM on a MCM package) with the fact that normally just the graphics processor is referred to as the GPU.
The E6760 replaces the RV730 based E4690 (4600/4600M) as AMD’s top of the line embedded video card, which at a couple of generations old makes the E6760 a bigger step up than we normally see in the desktop/mobile space; on top of 50% more SPs, it has all of the architectural enhancements from the Radeon 5000 and 6000 series. Utilizing a fully enabled Turks GPU with a core clock of 600MHz and a memory clock of 800MHz (3.2GHz data rate), in terms of performance the E6760 is effectively a 6750M suitable for soldering directly onto a motherboard, or in comparison to desktop parts it performs closely to a 6750 with significantly lower power consumption. The TDP of the card is 35W, owing to its mobile heritage. This includes the 1GB of GDDR5 on the MCM package.
If you’re wondering why AMD is only now replacing the E4690, this is due to the nature of the embedded market. As products utilizing embedded devices are normally manufactured for years, there’s little need to be consistently upgrading the GPU used and as such AMD has only been releasing 1 embedded GPU per every other product cycle. Devices that require different GPUs are normally so small a fairly large embedded GPU doesn’t make sense, or so large that utilizing higher performing laptop/desktop parts makes more sense. Thus embedded GPUs fill the niche for products that need value-desktop like performance with a GPU soldered right on to the rest of the motherboard. Consequently, because AMD releases an embedded GPU roughly once every year and a half, each release is a significant upgrade from the previous embedded GPU.
AMD (and ATI before it) have sold GPUs for embedded purposes for over 10 years, but until 2008 they largely sold the individual GPUs for integration directly onto a product, and completed cards (PCIe, MXM, etc) for larger devices. 2008 changed that with the introduction of the Radeon E2400, a multi-chip-module (MCM) suitable for integration that contained the GPU and VRAM (but no VRMs) on a single ball grid array (BGA) package.
Top: E4690 MCM. Bottom: E4690 MXM
The significance of this is that a MCM is much easier for device makers to integrate into a product – they need only worry about the MCM package (and supplying power to it) as opposed to integrating a GPU and VRAM separately. In fact it’s the VRAM that makes the MCM package so significant for buyers, as they don’t need to track down approved GDDR memory years later; AMD sells the entire package directly through their distributors. 1st party sales also directly impacts product availability, as AMD’s embedded video cards are normally available for 5 years due to the long lifecycle of the products they’re used in. So the E2400, a relatively ancient product by modern standards will be available until 2013, while today’s E6760 would be available until 2016, making a self-contained MCM package all the more important.
So what are embedded video cards used in? As we noted before they’re not normally used in consumer devices (which have much shorter product cycles), rather they’re used in business environments where there’s a slow turnover in technology. This isn’t to say that they’re used for boring things however – in fact one of the most popular uses is still gaming. And by gaming, we mean gambling.
One of AMD’s principle markets for their embedded video cards are video gambling machines for casinos. It turns out that many of the same things that gamers find attractive are also attractive to gamblers: specifically complex and flashy graphics. Selling the casinos on this concept opened up a large market for higher end GPUs for AMD, as previously casinos would use low-end SoC-class hardware almost exclusively. This is also one of markets that makes the 5 year availability window so important for AMD, as gambling machines have strict regulatory requirement, and so device makers need to be able to acquire parts for a number of years as regularly approval for new parts is expensive and time consuming.
The other significant uses for AMD’s embedded video cards tend to not be as flashy, although still GPU-intensive. Image processing is a big market here, as advanced medical equipment (e.g. Ultrasound) and some air traffic control systems utilize these higher power GPUs. For AMD the fact that the E6760 is the first embedded video card to support DirectCompute/OpenCL is a particularly big deal for these markets – as we’ve already seen on the gaming side of things, some image processing algorithms are better executed on the compute side than the graphics side, so on top of the hardware improvements the E6760 brings, it potentially offers a major speedup in specific image processing scenarios.
The final significant market for AMD’s embedded video cards is digital signage, interestingly enough. Here we’d be talking about things like as flight information screens and the ubiquitous (and annoying) digital advertising billboard. This has never struck us as a GPU intensive activity, but apparently in some cases it is. But for the E6760 though AMD has a more focused entry into the marketplace through Eyefinity. All 6 of Turks’ display controllers are enabled on the E6760, so it can be used to drive all of the Eyefinity configurations we’re accustomed to seeing with high-end GPUs, or alternatively driving 6 independent displays off of a single GPU versus 2 on the E4690. The E6760 still has the usual display interface limitations of AMD’s GPUs however, so those 6 display controllers are divided among 4 controllers for DisplayPort, and 2 controllers for DVI/HDMI/VGA/LVDS.
Finally, for those of you curious what other components embedded video cards are normally paired with, AMD opened up to us some on that. Given that the primary market for Turks is desktop/mobile x86 use, it should be no surprise that embedded video cards like the E6760 are mostly paired with x86 devices – AMD of course would love to sell you some of those too. However it can be paired with other architectures when buyers/3rd parties are willing to put in some work on writing their own drivers. The military often pairs their equipment with PowerPC, and with AMD’s open source Linux drivers it’s technically possible to pair it with a number of different architectures under specific circumstances once those drivers catch up with the hardware.
Post Your CommentPlease log in or sign up to comment.
View All Comments
Guspaz - Monday, May 2, 2011 - linkA bunch of laptops used MXM, but it was used to let notebook vendors offer different configurations, not for users to upgrade GPUs.
My Inspiron 9400 (E1705 in the US) used MXM for the GPU. It was theoretically possible for the user to swap the GPU, but in practice this was extremely expensive (even today the crappy five year old GPUs for the thing cost like $600) and difficult, so only the most advanced users ever even tried. Really, it was just a way for Dell to make a single notebook that had, if memory serves, three or four different GPU options.
Gauner - Monday, May 2, 2011 - linkSo, let me see if I got this right:
With one of these I could, in theory, hook it up to my beagleboard or any other low power board AND use it(with the linux drivers and after patching the kernel) to run 3D intensive applications or things like realtime h.264 1080p processing+transcode(supported in some way by every AMD and nVidia GPU) and streaming on a system that would consume 40w at peak?
Where can I find more information about this? do they even sell those things to end users?
Ryan Smith - Monday, May 2, 2011 - linkYou'd have to go through AMD's distributors. Hooking it up might be difficult however, as it doesn't have any voltage regulation gear, and I'd imagine the BGA pinout is quite specific. A MXM module (which has VRMs and a standard interface) may be easier.
ncalipari - Monday, May 2, 2011 - linkIt's not that easy:
- ATI fails to provide drivers for linux other than x86, so either you should use user contributed drivers or you give up using it on
- The power might be there.... but you need the bus. And a fast enough bus is very pricey.
- These components are not easily available in small quantities...
Penti - Monday, May 2, 2011 - linkHum, you can already do all that with ARM and MIPS SoCs with their built in video encoders and decoders so what is the point? With the Beagleboard too already. Just use the GPU or DSP, and the video hardware acceleration. Besides you got Quick Sync in Intel's embedded/mobile Sandy Bridge chips. Maybe 35W TDP isn't enough? Fusion APU/Ontario/Zacate also does encoding with gpu-acceleration.
Gauner - Monday, May 2, 2011 - linkThe GPU/DSP encoders for arm are really bad, at least last time I tried.
Also I was talking in a general sense, I've been working in some applications that need a loot of GPU power for graphics and video, but not a lot of CPU power, that's why I thought of an ARM+ embedded AMD combo, and why sandy bridge is not really suited for my needs(dunno about Fusion).
After reading the responses I think It would be too much trouble to be worth it, but still it's a pity, if the price was right this could help a lot in the small market of really intensive GPU computing with no need for CPU other than basic OS management stuff.
Penti - Tuesday, May 3, 2011 - linkI get why this would be interesting, but I too have a hard time to see that it is worth the trouble. AMD even exited the mobile gpu-market for that matter. So getting a platform like that (from a vendor) with a working SDK would be hard work. AMD won't supply it. I guess you could get a Sandy Bridge platform like something based on Celeron B810 to use very little power though. It would only cost pennies too pretty much. Much faster then AMD GPUs doing transcoding too. AMD GPUs aren't that magical when handling encoding.
And I guess most CE stuff does fine with the different vendors encoders and encoders built into the on die GPUs/DSPs for that matter. It's certianly enough for BD-players and STB'es any way. I guess some solution (on ARM/MIPS) should be able to handle above realtime high-bitrate H.264 encoding with the right software/drivers and conditions. Dunno if IVA2.2 from TI like the beagleboard uses would be fast enough for 1080p transcodes though. But software for that doesn't even come with the beagleboard any way so. And I guess the free codecs from TI is limited to 480p. Leveraging the DSP of course isn't the easiest. It's only intended to do up to 720p encodes any way. But there is newer gen chips around now. Maybe you could try a OMAP4 development board if you like to explore that. It's still a safer bet then to try turning an AMD GPU into doing that under GNU/Linux. Which would basically entail building a AMD Stream App which does the encodes and / or porting AMD's library for that. (Which I think they call AVT now). Also requiring the proprietary AMD drivers. Certainly wouldn't be impossible, but nothing you could do with open drivers any day. I however I think saw some work on doing Quick Sync transcodes in Linux. You at least got the decodes there. An AMD solution would entail proprietary drivers and X86 as of now to get running I think.
Penti - Monday, May 2, 2011 - linkI have been waiting for this, on package RAM that is. So we can get away with bulky external chips or flawed memory shared systems. This looks like a decent solution with a decent amount of memory. Maybe not the fastest but definitely more useful then the E2400.
floobit - Monday, May 2, 2011 - linkThe data rate shown on the first page is inconsistent. In the table, it is listed as 800 Mhz, and in the paragraph below, it is listed as 900.
ahmedz_1991 - Monday, May 2, 2011 - linkwow, that's a great news. embedded systems are the easy way to develop any thing anywhere.
in fact, here in Egypt, we have the subsidiary of Intel, SysDSoft, the LTE monster living it up only with simple embedded systems