The Dell XPS L401x L501x L701x series is a refresh of the XPS line and comes with an Nvidia Optimus configuration.
A DSDT.dsl table from a Dell XPS L501x model was submitted here:
http://bugs.launchpad.net/bugs/312756
See the link below for a review:
Support for NVIDIA Optimus models in Linux is still far from perfect, although more and more laptop models come with this configuration.
There are now more than 300 Linux users who joined the hybrid-graphics-linux Launchpad Team, and new developments are being incorporated
to the mainline Linux kernel to improve support of this graphics configurations.
Here are two new models that have been recently announced:
Equipped with a 2.4GHz Core i5-520M, 4GB of DDR3 RAM, a 320GB HDD and NVIDIA's GT 425M (1GB).
Acer Aspire 5742G with NVIDIA GeForce GT 540M
[Phoronix] Intel, NVIDIA Hybrid GPU Switching On Linux Nears
A month after making some small progress towards "hybrid graphics switching" on Linux to allow notebooks with dual GPUs (usually a low-power integrated graphics processor and a performance-oriented but high-powered discrete GPU), Red Hat's David Airlie is beginning to get things working for Intel and NVIDIA GPU combos on notebooks such as the Lenovo ThinkPad T410. Hybrid graphics on Linux still sucks, but at least it's getting better.
In a branch dubbed "drm-nvidia-switch" of David Airlie's Linux kernel DRM testing tree he has the kernel portion working for switching between the Intel IGP and the NVIDIA GPU with the open-source i915 and Nouveau DRM/KMS drivers, respectively. However, some bits are still missing and this will not work in all notebooks, but testing is just being done on the ThinkPad.
More details on this Linux GPU switching achievement can be found on David Airlie's blog.
Asus U31 13.3-inch ultrathin comes soon
The Asus U31 features some quite impressive specs for an ultrathin and we are looking at a 13.3-inch 1366x768 LED backlit screen, Intel's Core i3-370M/380M or Core i5-460M CPU, up to 4GB of DDR3 memory, up to 500GB of HDD space, 802.11bgn WiFi, and a 6-cell battery,
The Asus U31 will be available in two versions, the U31F and U31JG. The difference is the graphics card as the U31F features Intel's GMA 4500M while the U31JG will come with Nvidia's DirectX 11 ready, Geforce GT 415M with 1GB of memory. The U31JG will of course feautre Nvidia's Optimus technology for automatic GPU switching, something that we talked about for a couple of times.
As noted, the new U31 should appear in Europe by the end of December with a retail/e-tail price starting at €799.
You can find more here.
One of the ASUS U/UL series Linux users has found a way to enable the nvidia drivers by blacklisting the intel chip:
[ubuntu] ASUS N61Jv / N71Jv / N82Jv / UL50Vf anyone? - Page 3 - Ubuntu Forums
Reposting a report by peberlein in the launchpad hybrid-graphics-linux mailing list about the Asus EEEPC 1215N hybrid graphics. Instructions:
git clone http://github.com/peberlein/acpi_call.git
cd acpi_call
make
sudo insmod acpi_call.ko
./asus1215n.sh
[Hybrid-graphics-linux] Asus 1215N success
I successfully powered down the Nvidia device in my Asus 1215N. I modified the apci_call module and created a script to power it off and on. Here is the github fork:
http://github.com/peberlein/acpi_call
I owe a huge thanks to Mkottman for acpi_call and George Shearer for m11xr2hack. Those sources were excellent for learning about acpi and buffers.
I modified the acpi_call module to allow byte buffers to be passed as parameters, and also to return the acpi_object result in /proc/acpi/call. Being able to see the result helped me figure out some of the state in the acpi methods.
The 1215N is similar to the m11x r2 in that it requires a special method (_DSM) being called with buffer arguments before the _PS3 method will turn the power off. I also found that the _PS0 method turns the power back on. After turning off the power, the power state appears to be set in the _PSC object: 0x0 when on, and 0x3 when off. Except this isn't accurate after the system has been put in standby - the power is on (according to the battery rate) but the_PSC is still 0x3. I have to use the script to turn the power off again after coming out of standby.
One of the sony-vaio-z-series launchpad team members has reported the way to successfully switch on/off the nvidia card in VPCZ13 models:
Re: [Sony-vaio-z-series] Ubuntu on VPCZ13*
One of the hybrid-graphics-linux team member has posted an email to the mailing list with details about the Asus EEPC 1015PN laptop in Linux:
[Hybrid-graphics-linux] EEEPC 1015PN Optimus with ION
The modified acpi_call method for the Asus EEEPC 1215PN, doesn't work on this model to switch off the nvidia ION card.
Some months ago, David Airlie wrote VGA switcheroo as a system to enable hybrid graphics hot switching via logout/login from a X session.
David initially implemented this on an ATI hybrid laptop, but immediately after the first implementation, with Matthew Garrett's help, he also committed some code to enable it on nvidia hybrid configurations. This wasn't thoroughly tested at the time due to the lack of hardware, but different users in the hybrid-graphics-linux launchpad team have reported their success stories with VGA switcheroo.
Compared to VGA switcheroo, acpi_call is a module to test what ACPI method is available to switch on/off the discrete graphics card. Many nvidia laptop configurations have different ACPI methods, so in order to switch on/off the nvidia card, one needs to call the right method for the laptop.
It is in theory possible to put together the work done on acpi_call and VGA switcheroo, so that most of the laptop configurations would have the hot switching feature via logout/login in Linux. There is a bit of work to be done in code integration, hopefully someone will pick this up and work on it, since there are now more than 200 users who would benefit from it.
For more information:
http://asusm51ta-with-linux.blogspot.com/
http://airlied.livejournal.com/71434.html
[Phoronix] Nouveau Needs Help With Timing Management
For those owners of NVIDIA graphics hardware that are already using -- or interested in using -- the open-source Nouveau driver that is developed by the community as an alternative to NVIDIA's proprietary driver, the developers could use some help. Martin Peres has issued a testing request for people to try out new code for the Nouveau driver that deals with memory timing management.
Martin and two other developers have been working on adding memory timings support to Nouveau so that they can be tightened and loosened accordingly when manipulating the memory clock. It was just recently that the Nouveau driver began to reach a state of having working power management. The Nouveau developers have written up some code, but the video BIOS table that stores these vRAM timings contains a lot of "magic" (or still some uncertainty from their clean-room reverse-engineering), so they would like some help in the form of BIOS and register dumps across more NVIDIA GPUs.
For those interested in helping out this open-source project working towards a fully open-source NVIDIA 2D/3D driver, see this mailing list message and there is a GitHub Wiki page. An NV40 class GPU or newer is needed and the Wiki page covers how to produce a NVIDIA BIOS dump and peeking the graphics card's strap and selected timings.
One of the hybrid-graphics Launchpad team members has reported about the use of a modified version of acpi_call to swich on/off the nvidia optimus card on the Asus Eee 1215N models:
[Hybrid-graphics-linux] Asus 1215N success
I successfully powered down the Nvidia device in my Asus 1215N. I modified the apci_call module and created a script to power it off and on. Here is the github fork:
http://github.com/peberlein/acpi_call
I owe a huge thanks to Mkottman for acpi_call and George Shearer for m11xr2hack. Those sources were excellent for learning about acpi and buffers.
I modified the acpi_call module to allow byte buffers to be passed as parameters, and also to return the acpi_object result in /proc/acpi/call. Being able to see the result helped me figure out some of the state in the acpi methods.
The 1215N is similar to the m11x r2 in that it requires a special method (_DSM) being called with buffer arguments before the _PS3 method will turn the power off. I also found that the _PS0 method turns the power back on. After turning off the power, the power state appears to be set in the _PSC object: 0x0 when on, and 0x3 when off. Except this isn't accurate after the system has been put in standby - the power is on (according to the battery rate) but the_PSC is still 0x3. I have to use the script to turn the power off again after coming out of standby.
CUDA and OpenCL offer two different interfaces for programming GPUs. OpenCL is an open standard that can be used to program CPUs, GPUs, and other devices from different vendors, while CUDA is specific to NVIDIA GPUs. Although OpenCL promises a portable language for GPU programming, its generality may entail a performance penalty. In this paper, we compare the performance of CUDA and OpenCL using complex, near-identical kernels. We show that when using NVIDIA compiler tools, converting a CUDA kernel to an OpenCL kernel involves minimal modifications. Making such a kernel compile with ATI's build tools involves more modifications. Our performance tests measure and compare data transfer times to and from the GPU, kernel execution times, and end-to-end application execution times for both CUDA and OpenCL.
At the GPU Technology Conference in San Jose, NVIDIA announced that the Open Source Computer Vision
(OpenCV) library, which includes image processing algorithms, will,
from the start of next year, be able to utilise the computing power of
NVIDIA GPUs by making use of CUDA GPU acceleration.The OpenCV source code repository already contains some initial GPGPU
functionality, but a full initial release of the CUDA support is
scheduled to arrive in Spring 2011. According to Gary Bradski, senior
researcher at Willow Garage, which is involved in maintaining the
library, many OpenCV algorithms run five to ten times faster with GPU
assistance. OpenCV contains more than 500 algorithms for functions such
as image processing, face and body recognition and real time recording
and is available, free-of-charge, under the BSD licence.
If (LEqual (P3MO, 0x01)) {
}
After removing the lines, ran
echo '\_SB.PCI0.RP00.VGA._PS3' > /proc/acpi/call
and miraculously power consumption went down from 20W to 12W.
Up to eight hours of battery life.
Questions for anyone with even a remote knowledge of ACPI.
First of all, assumed that LEqual stands for "Less than or equal to". Under this assumption, how P3MO would ever be greater than 0x01 because it isn't changed to anything but zero or one?
This is every line I found P3MO on...
14781: Name (P3MO, 0x00)
14885: Store (One, \_SB.PCI0.RP00.VGA.P3MO)
14889: Store (Zero, \_SB.PCI0.RP00.VGA.P3MO)
15157: Store (0x00, P3MO)
Intel Core i3/5 platforms with integrated graphics support both CPU and
GPU turbo mode. CPU turbo mode is opportunistic: the CPU will use any
available power to increase core frequencies if thermal headroom is
available. The GPU side is more manual however; the graphics driver
must monitor GPU power and temperature and coordinate with a core
thermal driver to take advantage of available thermal and power headroom
in the package.
The intelligent power sharing (IPS) driver is intended to coordinate
this activity by monitoring MCP (multi-chip package) temperature and
power, allowing the CPU and/or GPU to increase their power consumption,
and thus performance, when possible. The goal is to maximize
performance within a given platform's TDP (thermal design point).
Asus N71JV - TY079V
./test_off.shTrying \_SB.PCI0.P0P1.VGA._OFF: failedAsus N71Jv 1.0
Trying \_SB_.PCI0.OVGA.ATPX: failed
Trying \_SB_.PCI0.OVGA.XTPX: failed
Trying \_SB.PCI0.P0P2.PEGP._OFF: failed
Trying \_SB.PCI0.MXR0.MXM0._OFF: failed
Trying \_SB.PCI0.PEG1.GFX0._OFF: works!01:00.0 VGA compatible controller [0300]: nVidia Corporation Device [10de:0a35] (rev a2)
00:02.0 VGA compatible controller [0300]: Intel Corporation Core Processor Integrated Graphics Controller [8086:0046] (rev 12)
HP Pavilion dm4-1063cl
with Intel (integrated) and ATI (Discrete)
Compiling acpi_call and here's the result:
Trying \_SB.PCI0.P0P1.VGA._OFF: failed
Trying \_SB_.PCI0.OVGA.ATPX: failed
Trying \_SB_.PCI0.OVGA.XTPX: failed
Trying \_SB.PCI0.P0P2.PEGP._OFF: works!
Here is an init script with this to disable the discrete card for now, because the battery drains quicly with the two cards on.
#!/bin/bash
insmod /home/mansor/acpi_call/acpi_call.ko
echo '\_SB.PCI0.P0P2.PEGP._OFF' > /proc/acpi/call
This is a patch to apply on top of current Linux tree, with a dmesg from a pre-optimus nvidia hybrid machine should bring up some info on the current state of the switchable toggle.
Testers welcomed, please report back at mailing list https://launchpad.net/~hybrid-graphics-linux, this email is repeated there:
http://people.freedesktop.org/~airlied/scratch/0001-nouveau- mux-switching-test-patch-1. patch
Also, if you have time to package the patched kernel for your favourite distro, please post it somewhere so that other people can install it and try it.From d2049202567dcb83ef9b8bbf34a3bccc10d90477 Mon Sep 17 00:00:00 2001
From: Dave Airlie <airlied@redhat.com>
Date: Tue, 20 Jul 2010 09:06:09 +1000
Subject: [PATCH] nouveau: mux-switching test patch 1
---
drivers/gpu/drm/nouveau/nouveau_acpi.c | 20 +++++++++++++++++++-
1 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c b/drivers/gpu/drm/nouveau/nouveau_acpi.c
index d4bcca8..dfb3b5b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_acpi.c
+++ b/drivers/gpu/drm/nouveau/nouveau_acpi.c
@@ -31,6 +31,8 @@
#define NOUVEAU_DSM_POWER_SPEED 0x01
#define NOUVEAU_DSM_POWER_STAMINA 0x02
+#define NOUVEAU_DSM_TOGGLE 0x05
+
static struct nouveau_dsm_priv {
bool dsm_detected;
acpi_handle dhandle;
@@ -90,7 +92,12 @@ static int nouveau_dsm(acpi_handle handle, int func, int arg, int *result)
static int nouveau_dsm_switch_mux(acpi_handle handle, int mux_id)
{
- return nouveau_dsm(handle, NOUVEAU_DSM_LED, mux_id, NULL);
+ int result, ret;
+ ret = nouveau_dsm(handle, NOUVEAU_DSM_LED, mux_id, NULL);
+
+ ret = nouveau_dsm(handle, NOUVEAU_DSM_TOGGLE, (mux_id | (1<<31)), &result);
+ printk("mux switch toggle returned %d\n", result);
+ return ret;
}
static int nouveau_dsm_set_discrete_state(acpi_handle handle, enum vga_switcheroo_state state)
@@ -181,10 +188,21 @@ static bool nouveau_dsm_detect(void)
}
if (vga_count == 2 && has_dsm) {
+ u32 result;
+ int ret;
acpi_get_name(nouveau_dsm_priv.dhandle, ACPI_FULL_PATHNAME, &buffer);
printk(KERN_INFO "VGA switcheroo: detected DSM switching method %s handle\n",
acpi_method_name);
nouveau_dsm_priv.dsm_detected = true;
+ /* get current power state */
+ ret = nouveau_dsm(nouveau_dsm_priv.dhandle, NOUVEAU_DSM_POWER, NOUVEAU_DSM_POWER_STATE, &result);
+ if (ret == 0) {
+ printk("VGA switchreoo: current power state is %d\n", result);
+ }
+ ret = nouveau_dsm(nouveau_dsm_priv.dhandle, NOUVEAU_DSM_TOGGLE, 0, &result);
+ if (ret == 0) {
+ printk("VGA switchreoo: current toggle state is %d\n", result);
+ }
return true;
}
return false;
--
1.7.1
a) figure out what values to pass the DSM method to trigger the MUX,
It looks like method 0x5 is the one to trigger the mux switch but I've
no idea yet what values to pass it to trigger the mux switch.
b) figure out how to get the LVDS DDC lines and make nouveau find the
panel, at the moment it fails to find the panel when booted and intel
is in control.
looking at (a) I expect we could pass a bunch of values to the ACPI
method possibly using acpi_call to switch the mux and switch it back,
It looks like passing 0 will return the current toggle status, then
its a matter of working out which of the top bits are doing what,
>From reading one DSDT I can see,
if bit 31 set, then bit 30 is some sort of notify, then bits 25,26,27
are used to work out some values stored in a TOGF
otherwise bit 24 is used for something, then bits 12,13,14, and 3,2,1,
and it stores some values for CRT/LCD/TVout, which may again be
toggles.
If someone with the hardware and can use acpi_call it would be nice to
try and map out some of these things, at least initially a value that
will turn the Intel LCD off and back on.
The DSDT I'm using at the moment is attached to bug 16403.
sudo apt-get install git
# type password
git clone http://github.com/mkottman/acpi_call.git
cd acpi_call
make
sudo insmod acpi_call.ko
# To check that the status of your VGA devices, run this command:
lspci -vnnn | grep VGA
# Unplug laptop, click on the battery indicator and take note of
# estimated remaining time.
# Now run this script:
./test_off.sh
# If you see a "works!" message, it's found a method.
To check that the status of your VGA devices has changed,
run this command again and check for the differences:
lspci -vnnn | grep VGA
Click on the battery indicator after running the test.sh script,
it should show a difference of about an extra 1-3 hours battery life.
Please join the hybrid graphics team if you are new by clicking on the
"Join Team" link at the right in this URL:
If you have any comments/questions, the best way to get an answer is to
subscribe to the mailing list at the bottom of that page and send an email there.
One of the hybrid-graphics-linux Launchpad team members has created a Linux kernel module to call ACPI methods through /proc/acpi/call. The code is here:
http://github.com/mkottman/acpi_call
You can try it by installing the module and then calling it like this:
sudo insmod acpi_call.ko
echo '\_SB.PCI0.PEG1.GFX0.DOFF' > /proc/acpi/call
Using the open source NVIDIA graphics driver -- Nouveau,
which is included in the Linux kernel -- PathScale created a fork off the
source code with high performance computing in mind. PathScale also
managed to recruit most of the talent from the driver project. PathScale's CTO, Bergström,
says the team was able to reverse engineer the NVIDIA ISA, register
details, and device exception handling. With that knowledge, they set
out to rewrite the code generator (compiler back-end), driver, and
runtime, focusing on improved memory management, error handling,
security and HPC-specific features, and performance.
Posting the link for a very interesting article about CUDA for Intel's Open-Source Drivers at phoronix.
Kernel Mode-Setting enabled some of the interesting graphics drivers features that we are enjoying in the Linux community nowadays. Find in the link a talk about KMS.
I recently obtained an account on our GPU cluster,
so I thought I should get my head around some of the technology that
drives GPU computing.
Put simply, GPUs can be used to perform calculations and since there are
many processors on a GPU, this can lead to quite substantial speed
increases as compared with CPUs. NVIDIA are
leading the way and they provide libraries and
software tools for people interested in this field.
Development is typically performed using C, C++ or Fortran. I’m not a
compiled languages guy – I could just about manage a hello world
in C – so I’m relying on tools built by other people, such as R
gputools.
Step 1 is to download and install the required libraries, toolkit and
possibly, drivers. I ran into a couple of minor problems on my machine,
so I thought I’d document them here.
Specifications
I run Ubuntu 10.04 on a 64-bit machine with a quad-core AMD Phenom II X4
955 Processor and a GeForce 9600 GT nVidia 512 MB card. The issues
documented here relate largely to Ubuntu 10.04.Install the CUDA toolkit
This is reasonably straightforward. Note that the latest version of the
toolkit is for Ubuntu 9.04.
2chmod+x cudatoolkit_3.0_linux_64_ubuntu9.04.run
3sudo./cudatoolkit_3.0_linux_64_ubuntu9.04.runThe installer asks where you would like to install the toolkit. I
chose /opt/cuda, over the default /usr/local/cuda. You then add
/opt/cuda/bin to your PATH and /opt/cuda/lib64 to LD_LIBRARY_PATH.
There are several ways to achieve this; I like to edit ~/.profile:
1# CUDA
2if[ -d"/opt/cuda/bin"] ;then
3PATH="/opt/cuda/bin:$PATH"
4LD_LIBRARY_PATH="/opt/cuda/lib64:$LD_LIBRARY_PATH"
5fiDownload and unpack the SDK
This is also quite easy.
2chmod+x gpucomputingsdk_3.0_linux.run
3./gpucomputingsdk_3.0_linux.runThis simply unpacks the SDK to the default destination of
~/NVIDIA_GPU_Computing_SDK.Fix up issues with compilation
In theory, the next step is to cd to
~/NVIDIA_GPU_Computing_SDK/C, type “make” and watch the sample
applications compile. There are a couple of problems with Ubuntu 10.04.
First, the version of GCC in the distribution is 4.4.3, whereas the SDK
requires, at most, 4.3.x. We need to install gcc-4.3:
1sudoapt-getinstallgcc-4.3Next, we have to tell the SDK which GCC to use. Open up
~/NVIDIA_GPU_Computing_SDK/C/common/common.mk in a text editor and:
1# look for this line
2# NVCCFLAGS :=
3# and change it to this
4NVCCFLAGS :=
--compiler-bindir=/usr/bin/gcc-4.3At this point, make still failed with errors related to
libraries. Ubuntu 10.04 has an up-to-date version of the NVIDIA video
driver, so there should be no need to update it. However, check whether
your system has libxi-dev, libxmu-dev and libglut3-dev
and install them if required.
My final make error was “unable to find -lcuda”. On my system,
it lives in /usr/lib/nvidia-current/libcuda.so. A temporary symbolic
link to /usr/lib did the trick:
1sudoln-sf /usr/lib/nvidia-current/libcuda.so /usr/lib/Finally, make works and creates 68 executables in the
directory ~/NVIDIA_GPU_Computing_SDK/C/bin/linux/release. If everything
went well, you can now enjoy a fast rendering of a smoke cloud, like
the one in the video at the top of this post, by running smokeParticles.Next step – figuring out how to do something useful and
bioinformatics-related with this new toy.I used several very helpful blog posts by other people to
troubleshoot these issues. Unfortunately, I don’t have the links with
me right now, so I’ll update this post later in the day.
The testing userbase for the PRIME mylti-gpu Linux support keeps growing, and now we have 2 different Linux users with Asus N82Jv laptops registered to the https://launchpad.net/~hybrid-graphics-linux team. The Asus N82Jv laptop comes with a Geforce GT 335M nvidia card that can be automatically brought to use with NVIDIA Optimus, and hopefully soon with the open-source PRIME multi-gpu offloading implementation of the same kind.
If you're looking for notebook power on the cheap and you're not too keen on either using Intel's integrated graphics or paying for a higher-performing, NVIDIA-made workaround (i.e., Optimus), then there's an obvious alternative mobile platform for you: AMD/ATI. AMD is gaining steam in the mobile space due to a combination of low cost and its ATI Radeon graphics solution, with Reuters reporting that the company will better than double the number of design wins this back-to-school season compared to a year ago.
HP, for instance, announced a huge revamp of its mobile lineup on Friday, and AMD was in the bulk of the new models on both the consumer and business side. In fact, many of the new notebooks are available only with AMD—Intel inside is not an option. This is a huge victory for AMD, one that looks to be part of an ongoing winning streak.
Jon Peddie Research's most recent report on the graphics space for the first quarter of 2010 shows AMD taking about six percent of the total graphics market share from Intel, with NVIDIA staying about flat at 31.5 percent. Intel dropped from 49.7 percent market share in the first quarter of 2009 to 43.5, and AMD jumped from 17.1 percent to 24.0 percent in that same period. These numbers are for total graphics market share, which includes both integrated graphics processors (IGP) and the newly launched integrated processor graphics (IPG). Part of Intel's market share loss is no doubt due to the shortage of Arrandale processors. AMD saw its biggest boost in mobile graphics, according to JPR, which suggests that the scarcity of Intel's mobile CPU/IPG combo may have taken a toll.
AMD seems to have some momentum on its side, and it's worth pausing for a moment to think about the chipmaker's advantage here.
IGP vs. IPG
The first quarter of 2010 saw the dawn of a new acronym and the start of a major shift in the PC hardware market—the move from integrated graphics processors to integrated processor graphics. In the former, the GPU is integrated into the chipset's northbridge, while in the latter, the CPU is in the same package or on the same die as the processor (e.g., Intel's Clarksdale and Arrandale 32nm parts, with in-package GPUs).
AMD doesn't have an IPG offering yet, but it doesn't yet need one. The thing that's making AMD attractive, apart from price (and price is a major factor), is that Intel's IPG just isn't that great. It's a lot better than it once was, but it's still no match for IGPs from NVIDIA or AMD.
The problem with having a not-so-great GPU in the same package as the processor die is that if you want to buy Intel's latest and greatest mobile CPU, you have to buy its GPU along with it. So you have to pay for this GPU that isn't very good and that you may not want, and then if you want real graphics performance you have to then go out and pay for an NVIDIA GPU to go with it (via Optimus or Apple's proprietary solution).
NVIDIA's Optimus is definitely a win-win for Intel, NVIDIA, and Intel users, because it gives Intel's customers the option of a better GPU that and a platform that can dynamically optimize its graphics performance to fit the running workload. But if you stack it up against a traditional CPU + IGP combination, like that which AMD offers, it's hard to imagine that all that all the shuffling graphics data back and forth between the GPU's private pool of DDR3 and the framebuffer that sits in system memory doesn't burn extra power.
In other words, from an engineering perspective, it would be better to have a more efficient IGP, where you do all your dynamic power optimization by turning on and off parts of the IGP, than it is to have two IGPs—a weak one and a strong one—and switch back and forth between those two depending on workload. Intel users are sort of stuck with the latter, more coarse-grained, system-level form of power optimization, while AMD can do the former by just focusing on making its single IGP very efficient across a range of performance points.
Ultimately, Arrandale's CPU is just plain better (it's a whole process node ahead, which is key for mobile, and the Nehalem microarchitecture is superior), but Intel has hung a dud of a GPU around its neck and has forced users who want better performance to resort to exotic system-level solutions like Optimus. This misstep has left a door open for AMD to walk right through with a saner and more conventional solution. And because AMD not only offers better graphics performance but is cheaper to boot, notebook makers (and probably users) are increasingly going to opt for the AMD mobile platform.
An Nvidia spokesperson confirmed to AppleInsider Tuesday that Apple's new high-end MacBook Pros include an automatic graphics switching solution that is the Mac maker's own creation. Nvidia had no input on Apple's solution and would not comment on the utilized technology.
Earlier this year, Nvidia introduced a new technology called Optimus, which is designed two work alongside Nehalem notebook designs -- like the Core i5 and Core i7 -- that include Intel's integrated graphics processor, as well as a discrete Nvidia graphics chip. The feature chooses the best of the two processors for running a given application. While the end result is similar, Apple's automatic graphics switching solution is not Optimus, Nvidia said.
This switching is accomplished on-the-fly with no input from users. Apple also offers users the option to switch solely to discrete graphics and turn off the automatic switching.
The top-tier MacBook Pros include the Nvidia GeForce 330M graphics processor, which is more than twice as fast as the low-end 320M found exclusively in the new 13-inch model. The 330M, however, is not an exclusive GPU, as it has been found in competing PCs that have already come to market.
Apple on Tuesday introduced its new line of MacBook Pros, with the 15- and 17-inch models sporting the proprietary graphics switching capabilities. The feature dynamically switches between the 330M for peak performance, and the integrated Intel HD Graphics for more energy efficient operation. Apple said the tightly integrated software and hardware solution allows battery life of 8 to 9 hours on the new MacBook Pros.
But it gets worse. Viewing QuickTime movie trailers on Apple's site in Chrome (a buggy experience, by the way) bumps you up to discrete, but doesn't bump you back down after you're done -- only closing the browser and opening it up again seems to reset it. Firefox and Safari keep you on integrated graphics the whole time -- as does downloading 480p or 720p content to your local QuickTime player -- but pulling up 1080p video locally kicks you into high gear (this sounds closer to the correct behavior, at least).
The most egregious thing we've seen, though, has to be Tweetie. Yes, little ol' Tweetie, that innocuous applet that stays out of your hair and shoots you a Growl notification every once in a while: as long as it's open, it's going to be rockin' the discrete graphics. The bottom line is that this is a great opportunity to underscore something we've said before, which is that Apple needs to bring back an ironclad disable option for the discrete graphics like it does with the older unibody models -- especially when battery life is supposedly Cupertino's single biggest push with these things. Of course, failing that, we've got to hope that some third-party dev out there has the wit, courage, and spitfire to craft a simple toggle utility.
Apple's approach in the new 15" and 17" MacBook Pros differs from Optimus in two key ways. The first is that the switching is all handled automatically by Mac OS X without any user intervention (though there is actually a System Preference to deactivate it, if you choose). Apps that use advanced graphics frameworks such as OpenGL, Core Graphics, Quartz Composer or others will cause the OS to trigger the discrete GPU. So, when you are reading or writing Mail, or editing an Excel spreadsheet, Mac OS X will simply use the integrated Intel HD graphics. If you fire up Aperture or Photoshop, Mac OS X kicks on the NVIDIA GeForce GT 330M.
The second way that it differs from Optimus is that the integrated graphics are powered down when the discrete GPU is active. This saves even more power than Optimus does, leading to a stated battery life as long as nine hours.
Apple credits its solution to the company's attention to detail when it comes to user interaction (though its original solution with its login/logout missed this mark), and because Apple is unique among PC vendors in that it controls both the hardware and software. That level of integration is much more difficult when multiple vendors control different parts of the system.
The 2.4 GHz, 13-inch MacBook Pro, for a suggested retail price of $1,199 (US), includes:
* 13.3-inch widescreen LED-backlit 1280 x 800 glossy display;
* 2.4 GHz Intel Core 2 Duo with 3MB shared L2 cache;
* 1066 MHz front-side bus;
* 4GB 1066 MHz DDR3 SDRAM, expandable to 8GB;
* NVIDIA GeForce 320M integrated graphics;
* 250GB serial ATA hard drive running at 5400 rpm, with Sudden Motion Sensor;
* a slot-load 8X SuperDrive® with double-layer support (DVD±R DL/DVD±RW/CD-RW) optical drive;
* Mini DisplayPort (VGA, DVI and HDMI adapters sold separately);
* AirPort Extreme® 802.11n wireless networking and Bluetooth 2.1+EDR;
* Gigabit Ethernet port;
* iSight® video camera;
* two USB 2.0 ports;
* one FireWire® 800 port (FireWire 400 compatible);
* SD card slot;
* combined headphone/line in (analog/digital);
* glass Multi-Touch trackpad and illuminated keyboard;
* built-in, 63.5WHr lithium polymer battery; and
* 60 Watt MagSafe® Power Adapter.
The 2.66 GHz, 13-inch MacBook Pro, for a suggested retail price of $1,499 (US), includes:
* 13.3-inch widescreen LED-backlit 1280 x 800 glossy display;
* 2.66 GHz Intel Core 2 Duo with 3MB shared L2 cache;
* 1066 MHz front-side bus;
* 4GB 1066 MHz DDR3 SDRAM, expandable to 8GB;
* NVIDIA GeForce 320M integrated graphics;
* 320GB serial ATA hard drive running at 5400 rpm, with Sudden Motion Sensor;
* a slot-load 8X SuperDrive with double-layer support (DVD±R DL/DVD±RW/CD-RW) optical drive;
* Mini DisplayPort (VGA, DVI and HDMI adapters sold separately);
* AirPort Extreme 802.11n wireless networking and Bluetooth 2.1+EDR;
* Gigabit Ethernet port;
* iSight video camera;
* two USB 2.0 ports;
* one FireWire 800 port (FireWire 400 compatible);
* SD card slot;
* combined headphone/line in (analog/digital);
* glass Multi-Touch trackpad and illuminated keyboard;
* built-in, 63.5WHr lithium polymer battery; and
* 60 Watt MagSafe Power Adapter.
Open Source PRIME multi-gpu supportX.Org Wiki - SummerOfCodeIdeas
This SoC project involves taking the nvidia optimus technology and implementing the same technology in open source driver stack. Some work has already been done to flesh this out in http://airlied.livejournal.com/71734.html there needs to be more work done in integrating it into the kernel and X.org stacks along with some client side method of picking which apps should be started where. Also the possibility of rendering 2D apps could be investigated.
Possible mentor: DavidAirlie
Gallium H.264 decoding
Write a VDPAU state tracker for Gallium. In Gallium, state trackers implement APIs, and generate card-independent shaders. This allows supporting multiple cards with a single piece of code. As part of Summerof Code 2008, a student successfully implemented g3dvl, a video layer for decoding XvMC on top of Gallium. This project separated the video decoding code into two parts: a common vl part, and an XvMC frontend. The result allowed hardware accelerated MPEG2 playback on all Gallium-supported hardware. The purpose of this project is to build upon this code and add H.264 and VDPAU support. This requires improving the vl code for features that differ between H.262 and H.264, and adding a new VDPAU frontend. Furthermore, not all H.264 features can be implemented using shaders (like for example CABAC), so integrating CPU-based and GPU-based acceleration stages together will be another challenge. Ultimately, the purpose of this project is the production of a fully open source chain for hardware video decoding on any Gallium-supported GPU.
Possible mentor: StephaneMarchesin
This
SoC project involves taking the nvidia optimus technology and
implementing the same technology in open source driver stack. Some work
has already been done to flesh this out in http://airlied.livejournal.com/71734.html there needs to be more work done in integrating it into the kernel and
X.org stacks along with some client side method of picking which apps
should be started where. Also the possibility of rendering 2D apps could be investigated.
Mentor: DavidAirlie
As it's stated in the description, David Airlie has already done a bit of work in this area, so it's now ripe time for an enthusiastic student to apply for the project and spend time experimenting with Linux/Xorg code to implement cool new Linux features for the newest line of GPU hardware on the market. All this while earning good money from Google! Who said open-source software doesn't pay???!?!We are looking for Linux users with Nvidia Optimus-enabled laptops
willing to provide debugging information for Open Source PRIME
multi-gpu support features being worked on. Please join the team and
send an email to the mailing list specifying your laptop model.
You can check the model, version and graphic card details of you laptop with this command:
sudo dmidecode -s system-product-name
sudo dmidecode -s system-version
lspci -vnnn | perl -lne 'print if /^\d+\:
Now that David Airlie's vga_switcheroo has went upstream in the Linux 2.6.34 kernel that provides hybrid graphics support and delayed GPU switching, David went on to look for something new to work on in his downtime when not busy with tasks at Red Hat. This new work is on GPU offloading / multi-GPU rendering.airlied: GPU offloading - PRIME - proof of concept
Last month NVIDIA introduced Optimus as a way for dual-GPU notebooks to seamlessly switch between the two GPUs but also to offload the rendering workload to the other graphics processor. This is somewhat similar to NVIDIA's SLI and ATI/AMD's CrossFire for splitting the rendering workload across multiple GPUs, but it has its differences. David ended up developing a proof-of-concept similar to NVIDIA's Optimus that he is calling "Prime" and it works with Intel and ATI GPUs.
David's goals with Prime are to allow a second GPU to render 3D applications onto the screen of the first GPU, with it being configurable by the client, and just to handle the rendering side. This work isn't as simple as his vga_switcheroo implementation, but it required changes to the Linux kernel and the Graphics Execution Manager (GEM), the DRI2 protocol, the X Server and DRI2 modules, and then the actual Linux hardware drivers.
All of this code has already been published as a proof-of-concept, but David shares on his blog that he's unlikely to personally take this work further by upstreaming the code. He has been successful though in using this code to offload the rendering work from an Intel IGP that's driving a display to a discrete ATI graphics processor.
Right now Intel and ATI hardware is supported, but NVIDIA GPUs could be supported too. This work depends upon a system using DRI2 (albeit with these out-of-tree patches) and a compositing manager must be running. David also shares, "To make this as good as Windows we need to seriously re-architect the X server + drivers. At the moment you can't load an X driver without having a screen to attach it to, I don't really want a screen for the slave driver, however I still have to have one all setup and doing nothing and hopefully not getting in the way. We'd need to separate screen + drivers a lot better. Having some sort of dynamic screens would probably fall out of this work if someone decides to actually do it."
It would be wonderful if this work on Prime could be continued and it works its way upstream or that someone takes the reigns from David to continue on with this GPU offloading work for open-source drivers. First though it may make more sense to focus on getting decent performance out of a single GPU before dealing with multi-GPU excitement.
THIS IS A PROOF OF CONCEPT - its not
going to be upstream unless someone else dedicates their life to it,
(btw anyone know anyone in ASUS?)
So NVIDIA unveiled their
optimus GPU selection solution for Windows 7, so I decided to see what
it would take to implement something similar under DRI. I've named it
PRIME for obvious reasons.
Goals:
1. Allow a second GPU to render 3D apps onto the screen of the first, pickable from the client side.
2.
Just target the rendering side, I'm assuming the GPU power up/down is
similiar to what was done for the older switching method.
Restrictions + limitations:
1. Must have compositing manager running
2. Must have second screen configured for slave card (doesn't need to be used)
Test system:
Intel 945 IGP + radeon r200 PCI card - yes this won't be a speed demon.
Terms:
Master: the IGP displaying the output - intel
Slave: the GPU rendering the app - radeon r200 in this case.
Step 1: kernel support
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-testing.git;a=shortlog;h=r efs/heads/drm-prime-test
http://cgit.freedesktop.org/~airlied/drm/log/?h=prime-test
The kernel requirements were simple, we needed a way to share a memory managed object between two kernel device drivers.
The
kernel has a GEM namespace per device, however this isn't good enough
to share with other devices, so I introduced a new PRIME namespace with
two ioctls. One ioctl allows the master device to associate a device
buffer handle with a name in the prime namespace, and the other allows
the slave device to associate a prime namespace handle with a buffer.
When the master creates a prime buffer the kernel associates the list
of pages with the handle, and when the slave looks up the same handle
it retrieves the list of pages and fakes up a TTM buffer populated with
those pages as backing store. I've added the concept of slave object to
TTM to allow for this.
The drm repo contains the API wrappers + intel + radeon pieces to call the association functions for buffer objects.
Step two: DRI2 Protocol
http://people.freedesktop.org/~airlied/prime/0001-dri2proto-add-prime-token.p atch
http://people.freedesktop.org/~airlied/prime/0001-prime-support-for-mesa.pa tch
From
the X server point of view a recent change to the DRI2 layer allowed
for multiple device driver names to be associated with a DRI2 end
point. The client can request either a DRI or VDPAU device name
currently. I firstly extended the DRI2 protocol, to add a new buffer
type, called PRIME, and added a hack to mesa's glx loader to request
the prime driver if an environment variable was specified.
Step 3: X server DRI2 module + drivers
http://people.freedesktop.org/~airlied/prime/0001-intel-add-prime-master-su pport.patch
http://cgit.freedesktop.org/~airlied/xf86-video-ati/log/?h=prime-test
http://people.freedesktop.org/~airlied/prime/0001-dri2-prime-hackfest.patch
This
was the messiest bit and still requires a lot of change. First up I
added an interface for the drivers to register as PRIME master and
slaves. Intel driver registers as master, radeon as slave for my demo.
We store these in an array. When a client connects and requests prime
driver, we mark the drawable and redirect the dri2 buffer creation
requests to the slave screen driver. Also the drm authentication is
sent to both kernel drms. It then hooks the swapbuffers command where
it does a region copy, and redirects this to the slave driver, and
damages the pixmap in the master driver. Now the "interesting" part, my
original implementation simply grabbed the window pixmap at the dri2
create buffers time, however there is an ordering issue with
compositing, this pixmap is pre-composite redirection so isn't actually
the pixmap you want to tell the kernel to bind to both gpus. This
turned out to function badly, I could see gears all stretched over the
front buffer.
So a quick coke + chocolate break later, I had
enough sugar to bash out the hack that now exists. DRI2 calls the slave
driver copy region callback, which checks if the drawable pixmap is on
the same screen, if its not, it checks if we've marked the pixmap as a
prime pixmap (i.e. one that belongs to the master). It is, it swaps in
the slaves copy, otherwise it callsback into DRI2. This callback calls
the Intel driver to make the buffer object backing the pixmap,
shareable, and returns the handle,then calls into radeon with the
handle to create a new pixmap pointing at the shared buffer object.
Once all that is done, radeon copies the back buffer to the shared
front pixmap, we return and damage is posted and the compositor grabs
the window pixmap and displays it.
So does it work?
On my
blistering fast test system with X + xcompmgr running glxgears was
going at 150fps from the r200 PCI card. Hopefully I can get some time
on a faster system or one of the dual laptops.
Caveats:
- When a window manager is running the gears get all corrupted, this looks like the clipping and/or stride matching between
the
drivers isn't correct. I suspect something with reparenting and
decorations, I'm not enough of an X guru to understand this yet,
hopefully one of the other hackers can fill me in. Also before it gets
reparented and redirected a frame can land on the real front buffer,
again clipping should take care of this, but isn't working yet. I need
to workout how clipping and that stuff works in X/DRI2. - talk to ppl
about clipping then JDI.
- Once a client has connected as a prime,
we don't tear it down properly, so later clients can end marked as
prime. - work out some sort of resources to turn stuff off
-
Reference counting on the pages in the kernel is iffy, currently i915
ups the page list refcount but never drops it. solution JDI
- hardcoded /dev/dri paths in dri2 for slave device - solution JDI
- radeon driver could in theory be a prime master - solution JDI
- nouveau could support prime master/slave also. - solution nouveau guys JDI
-
requires an ugly second screen in xorg.conf to load the slave driver.
Can we have a 0 sized screen or maybe a rootless second screen. -
solution : rearchitect X server to allow drivers without screens
(6m-1yr work)
- pageflipping needs to be hacked off in intel driver. - work out and then JDI
Where is the video?
Once I get it working with a window manager on a useful machine I might do a video of two gears going.
Where now?
Well
this is a purely academic exercise so far, after a week of kernel
fighting I decided to do something new and cool. To make this as good
as Windows we need to seriously re-architect the X server + drivers. At
the moment you can't load an X driver without having a screen to attach
it to, I don't really want a screen for the slave driver, however I
still have to have one all setup and doing nothing and hopefully not
getting in the way. We'd need to separate screen + drivers a lot
better. Having some sort of dynamic screens would probably fall out of
this work if someone decides to actually do it.
The kernel bits
aren't as ugly as I thought but I'm not sure if upstreaming them is a
good idea without the others bits. The refcounting definitely needs
work also the cleanup when clients exit.
DRI2 needs some more changes, I might try and flesh it out a bit more and then talk to krh about a sane interface.
I'm
probably going to get forced task switch quite soon, so I might just
get to having this running on a W500 or T500, before dropping it for 6
months, so if anyone wants a neat project to play with and has the hw
feel free to try and take this on.
ASUS
feel free to send me one of the real optimus laptops and I'll get
nouveau guys hooked up and try and RE the nvidia DMA engine.
