Cloud computing offers many challenges including the division of graphic-processing IP and rendering tasks between the mobile device and cloud-based servers.
Cloud computing has created new challenges for system designers in terms of the division of functionality between the mobile device and the cloud. This division will directly affect the design of system-on-a-chip (SoC) processors and graphic processing units (GPUs). Autodesk Media & Entertainment Tech Innovators asked the experts at Imagination Technologies and AMD to address the question of graphic processing and rendering partitioned between mobile devices and cloud-based servers. Here’s a portion of their responses. – JB
The answer, as is so often the case, depends on the use.
By and large, we think that the cost, silicon area, and power budget of our GPUs makes them efficient enough to be in the device rather than the cloud. This is especially true of the mobile space and most consumer devices.
But of course, there are often exceptions. Most creative professionals are, in our experience, running fairly slow and demanding apps anyway. They are very intolerant of any additional lag or performance hit. But there can be cases where – say, for a final render of a static image – they may be more willing to send it to the cloud.
In the more mainstream arena, the applications are less demanding. But still, gamers tend to be intolerant of lag too – especially when playing against each other online.
For applications for office, presentation, etc., there may well be a case for dumb terminals with rendering (and everything else) in the cloud. However, the cost needs to be notably lower than conventional devices, which I’m not sure has so far proven to be the case.
Because our technologies are designed for mobile applications first and foremost, they are very efficient and low power, making them very suitable for render cloud applications. When you take enough of them together, there is little in the GPU or GPU-compute space that they cannot achieve. And application programming interfaces (APIs) like OpenCL are making the interface between app and cloud relatively simple to program for.
Rendering in the cloud is, of course, not just rendering. One also requires technologies to control the elements of the system and divide work, etc. Really, it is a CPU/GPU combination for which we have very suitable technologies with our Meta CPU, PowerVR GPU, and RTU technologies.
For those willing to move ray tracing to the cloud, the power to access it is now available from an iPad. In the secretive world of high-stakes film and game production, though, many users aren’t ready or willing to send projects to the cloud. For these users, the challenge remains scaling down high-end ray-tracing technology to the laptop. This is a work in progress, but something we can enable with our ray-tracing-unit (RTU) technology.
It may well be that in the future, the ideal solution will be a combination: local rendering at your main workplace (or gaming space), where performance matters – but with documents stored in the cloud. A cloud-rendering solution will be available as a backup for when you’re in meetings or on the road.
We believe cloud-based services (including remote rendering) will begin to grow exponentially as technology and pricing/licensing models continue to be refined. There seem to be several approaches being developed – including approaches for both interactive design-review and final rendering.
The first method, which is expected to be used mostly for design-review purposes, is server-side rendering in conjunction with client-side user interaction and input on PC/mobile devices. In this scenario, a rendered image is generated in the “cloud,” compressed, and then sent over the network (or the Internet) to a mobile or other device, such as a PC. This scenario is similar to video streaming, except the user is able to interactively control camera and object parameters.
A second cloud-enabled method for design-review visualization, which is being developed by several companies, will make use of hybrid server/client rendering. This user experience is similar to the previous method. However, in this scenario, the cloud server does the heavy lifting – handling the harder lighting and procedural calculations. The “solved” scene is then converted into lightweight data, which can be transmitted instantly to a PC or handheld device, where the image is quickly rendered in 3D. Powerful, low-power, and low-cost technology (such as AMD APUs) will almost certainly accelerate 3D rendering capabilities of mobile devices in this scenario.
For final high-quality, “cinematic” rendering of HD-level stills and animations, cloud-based render farms have been around for a good many years. We see this type of service continuing to be relevant – and even expanding to include near-instantaneous (or at least very fast) GPU-based rendering of high resolution for a range of purposes.
In all of these scenarios (and any that we missed here), there are likely some limiting factors, such as network bandwidth, which will continue to be problematic. Images cannot be processed/rendered until all of the raw content is uploaded to the cloud server. In many cases, there will likely be a considerable delay as large datasets and high-resolution raw assets are transmitted to the “cloud” before any rendering can commence.
Examples include large texture and image maps, video content, and other “big” files that are sometimes required for “cinematic”-style rendering.
Vast amounts of machine-to-machine and human data promise plenty of work for information analysis and semiconductor IP designers.
Machine data will form a big part of the emerging Product-in-Life intelligence metrics, according to Laura Wilber, Solution Analyst, Exalead at Dassault Systemes. Her prediction is supported by a recent Analysis Mason Limited study, which found that machine-to-machine (M2M) device connections will grow to 2.1 billion by 2021. That’s up from an estimated 100.4 million device connections in 2011.
Product-in-Life intelligence refers to the gathering of machine and human data about a product once it’s in the market. Machine-to-machine data can come from anywhere – inside factories (e.g., sorters in postal services), inside automobiles, traffic-light cameras, power-company smart meters, mobile devices, and more.
Human data comes from social media, emails, online product reviews, etc. This type of data does require natural language processing to filter out meaningful information.
During her presentation at Dassault Systemes’s 3DExperience conference, Wilber talked about the challenges that big data places on traditional data-analysis tools and techniques. “The data generated by today’s systems are not suited for transaction-based relational databases,” she explained. “Such traditional systems cannot handle the volume, variety, and velocity of the (M2M and human) data.”
These challenges will also present employment opportunities for information engineers and semiconductor IP designers.
Why should IP designers care about this flood of M2M and human data? Doesn’t this flood lie in the realm of big data analysis? All of that is true, but the growth of M2M and even human data (especially in mobile devices) translates directly into the growth of sensors, microelectromechanical systems (MEMS), and analog technologies. Additionally, M2M data often relies on low-power wireless systems (see figure) and even energy harvesters – all of which require semiconductor IP designs, tools, and integration.
IP giant Imagination is acquiring MIPS while Dassault Systemes eyes semiconductors. At the TSMC OIP, Sean and I drop in on Imaginations, True Circuits, and ARM.
Here are a few highlights from a very busy couple of weeks:
> Imagination To Acquire MIPS – Purchase price for Imagination is $60 million; Portfolio of patents to be sold separately to Bridge Crossing for $350 million.
> Systems Simulation Moves from Goods and Services to Experiences - This is the first of two stories about Dassault Systemes’s move into the experience-based economy and the world of semiconductor development.
> TSMC OIP 2012 Walkabout Videos with Sean O’Kane:
Interview with David Harold from Imagination Technologies
Interview with Stephen Maneatis from True Circuits
Interview with John Heinlein from ARM
How will stacked die affect the IP supply chain? FinFet transistor structures will require new Spice models. But what else?
Today is a mix of medias – all dealing with the coming die and chip 3D challenges:
1. My colleague and editor-in-chief of the Low-Power High-Performance portal – Ed Sperling – has written a three-part IP-supply-chain series based upon interviews with the following: Jim Hogan, an independent VC; Jack Brown, senior vice president at Sonics; Mike Gianfagna, vice president of marketing at Atrenta; Paul Hollingworth, vice president of strategic accounts at eSilicon, and Warren Savage, CEO of IPextreme. Here’s the last of that series: Experts At The Table: The Business Of IP
- Notable quote from Warren Savage, CEO of IPextreme, responding to a question about the future of IP on stacked die:
2. In this short video, Sean O’Kane from Chipestimate.TV and I talk with ARM’s John Heinlein about the coming challenges faced by IP designers using FinFet transistor structures.
- TSMC OIP 2012 – John Heinlein interview
In this October issue of “Industry Trends,” John Blyler and Sean O’Kane ponder the possibilities of inner space and thin air (think Dassault Systemes and Imec).
Remember the ’60s Disneyland Tomorrowland ride called the “Adventure through Inner Space?” In this ride, you were shrunk to the size of an atom. Such an experience is now possible with Dassault Systemes’s 3DVIA virtual-reality development system. Wouldn’t this experience prove to be a useful design tool for chip designers and nanotechnology educators?
What if you could pull energy out of thin air? That’s what the folks at Imec have done with their prototype RF energy-harvesting system. This platform is different from today’s electromagnet rechargers (e.g., for toothbrushes) in that it can pull energy from the RF spectrum at significant distances away from the source.
Staying on the theme of ultra-low power, Imec recently demonstrated a lemon-powered CPU. Similar to Intel’s solar/potato-powered processor covered at the Hot Chips show, both CPUs are designed for near-threshold-voltage (NTV) technology. Such NTV designs will be needed to power the multitude of sensors emerging in our ever-connected world.
A recent system-level power-modeling discussion at an Ansys-Apache-Qualcomm event contained a few surprises for IP designers.
Last week, Qualcomm presented a keynote at Ansys-Apache’s “Dimensions of Electronic Design” seminar. I’ve already written about the system-level power-modeling aspects of that presentation elsewhere (“Power Trumps Performance In Mobile Design”). Now, I’ll cover “the rest of the story” as it applies more specifically to semiconductor intellectual property (IP).
Foundry IP consists of hard cores (or macros) that cannot be modified by the chip designers. The transistor layouts that make up this type of IP must adhere to the target foundry’s process design rules. That is why foundry IP for one fab cannot be easily ported to a different process node or another foundry. Hard-macro IP functions are offered by the major IDMs (such as IBM, Fujitsu, Samsung, TI, etc.), which tend to lock customers into specific processes.
“You must make sure that your IP is not only driven by process technology, but also by your product requirement,” suggested Charles Matar, VP of engineering at Qualcomm, during his keynote address. “I’ve talked about things like power models, collapsing power (leakage management), and different modes of power states that we (as SoC designers) need to support. All of this is driven by the architecture – especially the power architecture – of the SoC.”
Power architectures in mobile design are tightly governed by user operating scenarios, which translate into specific chip voltage, current, and power states. Mata stressed the ongoing challenge of designing for such corners and margins. “A lot of times, we will overdesign our SoCs for 3 Sigma corners or to make sure we have a very robust design, very high yields,” he said. The danger in overdesigning the power bands is the resulting increase in power. In part to address this issue, EDA companies like Cadence have promoted the use of silicon-aware design (i.e., designing with less margin using adaptive techniques).
At a higher level, generous design margins are often the result of engineers working in silos. “As design teams are spread across companies and continents, designers may not be able to share the same information,” explained Aveek Sarkar, VP of product engineering and customer support at Apache Design. “If you are designing the IP, you may not be aware how the IP is being used at the full chip level. So you tend to over-compensate and over-design to protect yourself for the entire system. That leads to increased cost and power usage.”
Returning to design margins and yield, Matar emphasized the importance of working closely with the foundries to ensure that designs were optimized for the chosen process technology. He said that the challenge moving forward is to design for multiple process technologies, depending upon which power, performance, and cost constraints are best suited for a particular product. The days of designing for one process node are gone. Today requires SoC designs that are friendly to different process technologies, Mata concluded.
Does this sentiment support the move toward 3D designs like stacked dies? If so, how would that impact IP designers? I’ll leave that question for another day.
The white-washing of cloud computing remind us of the evolution of decades-old rightsizing and client-server technologies.
Did you see the Dilbert cartoon in this weekend’s paper? In the strip, Dilbert’s pointy-haired boss tells his engineer employee to move some of the company’s function to the Internet, but call the Internet the “cloud.” When asked why, the boss simply notes that no one “will take us seriously unless we’re doing something on the cloud.”
Apparently, cloudwashing is nothing new. Last year, Apririo – a cloud IT services company – toasted the winners of “The Washies.” This is a “tongue-in-cheek award given to the worst cloudwashing offenders.” Past winners have included Oracle, Salesforce.com, and Microsoft.
But let’s take the observation of Dilbert’s boss one step further. To do this, we must step back in time to the last millennium, roughly around the mid-1990s. Back then, the big network buzzword was “rightsizing” – a term used to describe the balancing of functionality between the client (PC) and server systems connected via the Internet. Sound familiar?
At best, cloud computing is the next generation of client-server technology. At worst, it’s cloudwashing. For an interesting comparison of the two, check out this discussion thread on Stackoverflow: “Cloud computing over Client-server: differences, cons and pros?” I’ve mentioned the Stackoverflow site in an earlier blog.
Here, the story gets personal. Back in the 1990s – together with my friend and colleague, Dr. Gary Ray – I co-authored a book called, “What’s Size Got to Do with It?” (Can you recall what Tina Turner song was popular at that time?)
Our book explained the systems engineering of client-server systems, both hardware and software. Please don’t rush out to buy it, as the book is hopelessly outdated with references and case studies based upon now-antiquated operating systems and network implementations. But the systems-engineering approach remains valid.
My point is that from an architectural standpoint, very little has changed in the last 20 years. It’s certainly true that processors and throughput have gotten faster, thanks largely to the relentless push of Moore’s Law. Software development has also improved to make better use of client-server environments. And new applications (applets) have emerged by the thousands. But little has changed in the actual workings of what we now call “the cloud.” Instead, the old client-server model has simply become more personalized and accessible to the average person. This is the general trend of everything on the Internet.
For those of you with copious amounts of free time, I’ve included a link - What’s Size-Ch.01 - to the original galley proofs of the first chapter of our “rightsizing” book. In this introductory chapter, you’ll notice that we used the technology of the day (20 years ago) to basically describe what is happening in today’s cloud environments.
It truly seems like the more things change, the more they stay the same.
A new level of hardware and software IP integration is needed for true power optimization.
Both Intel and Microsoft took the stage at the recent Intel Developer Forum in San Francisco, CA. Their goal was to highlight a new level of hardware and software integration, which aims to optimize energy usage.
This presentation covered the Windows 8 power-management enhancements targeting software developers, including new ultra-low-power states for mobile devices. Barnes Cooper, Senior PE at Intel, and Stephen Berard, Senior PM at Microsoft, gave the presentation, “Optimizing Battery Life on Intel Architecture Based PCs with Windows 8.”
Not surprisingly, battery life in today’s CPU-based systems is dependent upon both hardware and software factors. Hardware usage determines the extent of power consumption. Software dictates when the hardware is active and idle, which in turn decides when and for how long the system can make use of low-power states.
The speakers talked about CPU-related “hygiene improvements” in Windows 8 that will improve system-level power management. The hygiene-related checklist included:
Similar hygienic OS changes have been introduced in the network, storage, and input/output hardware subsystems.
Software – in all of its myriad forms – is now one of the chief causes of increased power consumption. Paying attention to “hygiene” is but one small way to reduce this consumption. Still, every bit helps.
Unlike today’s inductive charging systems, radio-frequency energy harvesters provide ultra-low power over greater distances. And new feedback techniques promise greater energy efficiencies.
Imagine pulling energy out of thin air and from significant distances from the source. This is one of the energy-harvesting technologies that is being studied by Imec.
Radio-frequency (RF) energy harvesters are different from typical induction charging systems, such as the popular “power mats” and electric toothbrushes that require a nearby power source. There, the close proximity of the power sources is needed to ensure an efficient transfer of power—usually within millimeters.
In contrast, RF energy harvesters work over a much larger distance—from about 10 to 15 meters—and at much higher frequencies. (Typically, they are in the GSM mobile-radio band.) The key to successful RF power transfer lies in the design of the antenna system, according to Jan Van der Kam, program director for the Sensors and Energy Harvester Group at Imec.
“We are looking at antennas that direct the RF energy much more efficiently instead of spreading it in all directions,” Kam said at the recent Imec Technology Forum (ITR) held in Leuven, Belgium. Imec is working on designing more efficient antennas, but also developing the feedback mechanism for the energy receptors. This feedback approach will help to increase the efficiency of the energy transfer to even greater distances.
Application areas for this technology would include everything from smart buildings (where the energy could be generated locally and transferred without wires) to recharging a hearing-aid battery. As a proof of concept, Imec acquired a small weather station that was successfully powered at a distance using RF energy harvesters.
Energy harvesting, or scavenging, has become a lucrative topic of late and a source of new intellectual-property (IP) patents. When combined with the added functionality and performance requirements of today’s mobile devices, the slow improvement in battery technology (estimated at about 3% to 5% per year) has created needs for the following: architectural changes to improve system-on-a-chip (SoC) efficiency and new ways to generate energy. The architectural changes can be difficult and expensive to implement. While voltage islands and dark silicon are well discussed, companies are just beginning to work with more exotic approaches like near-threshold computing. Being able to generate energy could postpone the need to move to those techniques while saving costs.
Most approaches focus on movement or light to generate that energy. But pulling energy out of thin air isn’t a new concept. At the turn of the 20th century, Nikola Tesla proposed using wireless power and even set up a laboratory in Wardenclyffe, N.Y., to turn that idea into reality. More than a century later, his idea appears to have some merit.