Tuesday, June 14, 2011

Saving Power with GPGPU and AMD Fusion

I'm currently pondering the benefits of GPGPU on AMD's Fusion processors from a performance and power consumption perspective. To scratch this itch, I have starting to look into how well the OpenCL applications in the Phoronix Benchmark Suite run on my AMD E-350 netbook. I'm looking at the performance from both a throughput as well as from a power consumption perspective.

So far from a few quick tests, the performance looks like about 60%-100% better on the integrated GPU core than running the applications on the CPUs. Power-wise, the system's power consumption (as measured by the battery drain through ACPI) seems to be about 2 watts better when running on the GPU versus the CPU (overall system power ranges from ~12w-19w.

I decided to start looking into this for several reasons:

1. AMD's Fusion products have relatively better GPUs than they do CPUs. As a result, GPGPU could potentially have a large benefit on Fusion systems.
2. The mobile Fusion GPUs are designed for relatively low-power systems; as a result, the GPU's power consumption should be relatively modest as compared to a lot of discrete GPU applications. The low power of the GPU opens up the potential to utilize GPGPU to save power.
3. GPGPU performance is frequently heavily limited by memory bandwidth; as a result, it would be interesting to see if a GPGPU application has an advantage over a CPU-based application when they have access to exactly the same memory.

Before I spend too much time studying this question on my netbook, I'm wondering what other people think.

There, I Fixed It

It looks like I might be the first person to get Bluetooth working on the HP dm1z netbook/ultraportable:

Tuesday, February 1, 2011

OCCAM for OpenCL

I'm thinking about, if I continue this work beyond my Ph.D. work, to develop a version of OCCAM that uses OpenCL. Here are some potential benefits that may result from using OCCAM with OpenCL:
  1. OpenCL is a stream-like language, similar to the programming model that OCCAM already targets. As a result, an OpenCL version of OCCAM would be relatively straightforward to do.
  2. OpenCL is/is becoming a widespread system for running parallel code on multicore as well as other platforms like GPGPU and CELL. As a result, moving to this platform would greatly improve the applicability of OCCAM.
  3. OpenCL is somewhat opaque in how it works under the hood, due to vendors' various proprietary implementations of it for their GPUs, etc. As a result, trying to ensure portable real-time performance on a variety of OpenCL platforms will be likely highly challenging.
  4. OCCAM's modeling of the application and computer system's behavior as a stochastic system can allow the application designer to work around this issue by adapting the application as needed. Providing such functionality may not require the full, multiple degrees of freedom implementation that OCCAM currently provides. Instead, it may only be necessary to provide a stripped-down version that just adapts the application to meet its timing deadline.