search

Bumblebee-Project / Bumblebee-old

nVidia Optimus support for GNU/Linux aimed at stability. Rewritten and improved fork
https://launchpad.net/~bumblebee
117 stars 5 forks source link

Nouveau support #18

Closed Samsagax closed 12 years ago

Samsagax commented 13 years ago

As some might notice, our current Bumblebee implementation isn't completely free as we depend on the proprietary binaries from nVidia.

To develop a complete free solution we are in need to support Bumblebee under nouveau drivers and their Gallium3D features. This, of course, will have the limitation of such features and support from nouveau in each particular card.

Advantages of supporting nouveau:

This feature will be implemented in the branch "common-nouveau"

Ximi1970 commented 13 years ago

It is a shame that you removed the nouveau support from the openSuSE version... Luckely it is still available at my git tree (or MrMEEE) or in the openSuSE repositories.

Lekensteyn commented 13 years ago

@Ximi1970 it's available in the history of git. We're just trying to get an unified Bumblebee to give everyone the same experience of using it.

ArchangeGabriel commented 13 years ago

It is even available in the to_clean branch, which purpose is to save all the old work.

I've only removed it to have the same basis for every distro. nouveau could be available as soon as you would have updated the install script for openSuSE.

Samsagax commented 13 years ago

Well after some research I found that nouveau support will be easy to implement but difficult to maintain with the actual installer.

First, how it works:

a simple configuration file xorg.conf.nouveau will do for the X server:

Section "ServerLayout"
    Identifier     "Layout0"
    Option         "AutoAddDevices" "false"
EndSection

Section "Device"
    Identifier     "Device1"
    Driver         "nouveau"
EndSection

This file will work with 3d enabled provided the following conditions are met:

Things that are not needed by nouveau but nvidia need them (so here is the problem on how we split them):

I've tested that myself and worked fine with some advantages (application compatibility, non broken libgl, proper 32/64 bit selection, it's free) and disadvantages (performance, some cards are not supported).

There are changes to be made in both the installer and daemon. They are not hard to make in the daemon as is a matter of variable setting; but the main concern is the installer.

Lekensteyn commented 13 years ago

The installer needs another stage for the driver. The next stages are currently involved:

Looks like there must be a stage between welcome and checkdependencies. Proposal:

Now, to be flexible in packaging, we should probably package like this:

Samsagax commented 13 years ago

Ok. I'm again on the run for this one: Current installer is used adding the separate options according to DRIVER. The whole idea is to keep the present installer usable for both drivers.

setvars: defines which driver should be used (possibly by using --driver=DRIVER)

Added the two options for AVAILABLE_DRIVERS array. The only thing to discuss is which would be the default one.

distro/setvars: XORG_MODULEPATH, which is driver-dep checkdependencies: the driver needs to be installed. Should we create a new stage for each driver or include it in the installer?

Solved by adding a 'case' statement (if no driver set will fail). NVIDIA_LIB{32,64}DIR are not used anymore (at least in Ubuntu/Arch). For the dependencies i was trying to integrate the checkdependencies to the distro-independent installer by setting variables in the DISTRO/setvars stage. As for balcklisting nouveau: most packages do taht automatically (in Ubuntu is done by installing the nvidia-current package) so this might be left to that packages instead of doing it myself

Regarding packaging, it would be great to use a "core" for driver-independent installer and separate packages for each one. The installer should be then laid out in that way.

Lekensteyn commented 13 years ago

About blacklisting, good point, Ubuntu indeed blacklists nouveau when installing nvidia-current so it should be removed in a future version. I guess that no cleanup action is required for nouveau-blacklist.conf since that file will only be created if nouveau hasn't blacklisted yet.

I like the package idea of separating the core from driver-deps.

As for the default driver, what about using nvidia-current as default since it gives better performance over the nouveau one? We should probably avoid detecting an available one (nvidia vs nouveau) as it makes the installers behavior not consequent.

ArchangeGabriel commented 13 years ago

I didn't have had the time to read this thread, but I would just add something important for me : it would be really nice to be able to use both. For example, running optirun uses the default setting, and you can run optirun --driver (driver being replaced by driver name) to use bumblebee with this driver.

Samsagax commented 13 years ago

There is still a little catch: My test-runs on the daemon result in fullscreen corruption and no manner to retrieve usefull debug data. But if I start the X server at minimum required and vglrun at minimum it starts with no problems. Maybe the problem is in the client side (optirun) but can't know for sure.

I'll add an option to the daemon to start the X on-demand so we can test this. The installer is almost ready to deploy either driver right now and is a good step to eliminate the need for a distro-check in checkdependencies.

Samsagax commented 13 years ago

News: The model works on nouveau (YAY!). Still the blacklisting is a problem to be solved and the load/unload of the appropriate graphics card should be done based on the DRIVER configuration in /etc/bumblebee/bumblebee.conf file.

Need some discussion on how to integrate this to the current nvidia-only model and be able to switch between them.

For packaging: the only substantial difference/problem I see in packaging is the dependencies for each driver are totally different. The 'core' package can be the actual one but configuration and dependencies can be managed by this two metapackages 'bb-nouveau' and 'bb-nvidia'.

I'll try to integrate both in a way that the daemon can switch between them provided the good dependencies are met.

ArchangeGabriel commented 13 years ago

nouveau and nvidia are only conflicting if we try to run them at the same time, right ?

Then what I propose is to install both, set one as default (and give the user the ability to choose which one is default), and give the ability ro run the other via optirun --nouveau or optirun --nvidia (or even optirun --driver nouveau, optirun --driver=nouveau, optirun --driver nvidia, optirun --driver=nvidia).

In order to do that, before modprobing one, we should verify if the other one is running, and in that case mordpobe -r it (only if there are no X server running with it, else, tell the user that there is an app running with the other driver).

Samsagax commented 13 years ago

The branch 'common-nouveau' is merged into develop. Now comes the testing part and bugfixing the installer mostly

ArchangeGabriel commented 13 years ago

In my opinion, it shouldn't have been merged so fast, because the installer still lacks support, and we didn't make testing yet. develop isn't here for such testing but in order to merge function back when there are READY.

Imagine that nouveau support can't be ready for sunday, then releasing ACPI will be blocked because nouveau has been merged into develop. I've particularly insisted on that point.

By the way, we discussed about packaging, and here is what went out: -bumblebee will be packaged by default with nouveau support as default -bumblebee-nvidia will provide nvidia support for Bumblebee (this package depends on nvidia one) and make nvidia the default

Lekensteyn commented 13 years ago

Todo: allow the installer to install multiple drivers, I'll do that.

ArchangeGabriel commented 13 years ago

I will unmerge nouveau in order to make a dev snapshot of acpi-framework for our dev PPA.

Should I merge it again after or do we decide to finish work to support both drivers before ?

ArchangeGabriel commented 13 years ago

Discussed in IRC. I will not unmerge anything as changes in the installer doesn't impact our building scripts.

About installer, here is my opinion on what we should do. The global behavior is to install nouveau anyway and to install nvidia in addition if the user want it. Why that ? Because I think that someone that want to get ride of nouveau is someone that should be able to modify bumblebee to suit his need, first because removing things like nouveau need a good knowledge of what you're doing, then because that's probably someone that want a really minimalist system, and that should then use a custom recompiled kernel, so use a custom bumblebee is not a great obstacle...

So, for git installer, the idea is the following:

For packages, this is translated like that:

The concern with this plan is: is nouveau everywhere in the linux world (or at least the part that may use bumblebee, won't check that support for Hannah Montanah Linux or Baby Linux ...)

Fedora: OK, default since Fedora 11 Ubuntu: OK, default since 10.04, lowest version we support Mandriva: OK since somewhere in 2009 (don't know if it is the default now, they are potentially still using nv) openSUSE: OK (didn't look since when) Debian: OK since Squeeze Gentoo: Did not find the information in less than one minute, abandonned research RHEL: OK, default since at least RHEL 6.0

Globally, nouveau is present everywhere there is at least a 2.6.34 kernel, which we could hope when we're talking about Optimus technology... Do you want me to do more research on other distros (Slackware, ...) ?

About both driver support, there is one concern for me, about how we will handle that in the backend part.

For what I see now, we need to restart the daemon in order to switch driver. That is better to be sure that no X server is running on the other driver and for some other things, but there is one problem with that.

Could we add something like an argument to start the daemon on a given driver ? Actually, it will start using the driver defined in the conf file. So if you want to restart it for an other driver, you need to stop it, change the conf file, start it again (or edit the file and restart). Can't there be an easier way todo that ?

Also take a loot at #77.

Having all this ready for 02/09 is at risk, so here is what we should do:

Samsagax commented 13 years ago

won't check that support for Hannah Montanah Linux or Baby Linux ...

You won't check for Justin Beiber distro either? :'( < BIG FAT LOL!

Lekensteyn commented 13 years ago

No need for a command line option (at least not to the initscript!). If you need to change the driver quickly, use sed like this:

sudo /etc/init.d/bumblebee stop
sudo sed 's,^DRIVER=.*,DRIVER=nouveau,' -i /etc/bumblebee/bumblebee.conf
sudo /etc/init.d/bumblebee start

So, we'll use nouveau by default (for now) and provide nvidia in an additional package. Still, we haven't made a decision on the driver choice during installation yet. Should we default to nouveau, and let the user change the conffile? Not really userfriendly imo, and I'd like to use alternative links for that. An alternative solution (given that we've just two drivers for now) would be making a post{inst,rm} script that sets the driver to nvidia or reverts it back to nouveau on removal of bumblebee-nvidia. What do you think of that?

ArchangeGabriel commented 13 years ago

In fact we've already made this choice. We would ever have just two drivers, this has been discussed a lot.

So what we decided about that is:

About you code block just before, I will make from that a function. Will see how.

Lekensteyn commented 13 years ago

I missed a trailing comma in the code which I've now edited in.

For the installer, I've decided to extend --driver with --driver=driverA,driverB,driverC(default) (--driver=nvidia,nouveau)

Please join #bumblebee-dev for a faster discussion

Lekensteyn commented 13 years ago

@ArchangeGabriel: should we really make nouveau the default driver for Ubuntu? There does not seem to be official nouveau releases since the code is always in development and not finished yet. The PPA https://launchpad.net/~oibaf/+archive/graphics-drivers/+packages broke desktop effects on my intel display, so I didn't bother trying nouveau from it either. (the updated mesa package was causing issues with errors like "Mesa warning: failed to remap index [number]" in /var/log/kdm.log).

Samsagax commented 13 years ago

Are really Canonical that narrow?

+1 on banning Ubuntu from existence :P.

You just don't need any packages from ppa. With the mesa + libgl + nouveau-dri should do the trick.

ArchangeGabriel commented 13 years ago

@Lekensteyn: For this release, I'm packaging it only for nvidia. Will see later for nouveau.

Lekensteyn commented 13 years ago

@ArchangeGabriel: that's fine, I'll include the updated bugreport tool too and update the ppa files to use nvidia.

starks commented 13 years ago

On the Ubuntu side of things, shouldn't libgl1-mesa-dri-experimental be a dependency?

Lekensteyn commented 13 years ago

From it's package description:

This package does not include the OpenGL library itself, only the DRI modules for accelerating direct and indirect rendering. The drivers in this package may provide more features than the drivers in the libgl1-mesa-dri at the cost of less stability.

I'm really sure about the differences, but as the nouveau driver provided with Ubuntu are quite old. Natty does not support NVC0, not sure about the level of support in Oneiric. For that reason, default use of nouveau has been postponed. Back to your question, I don't know the implications of the -experimental dependency, it should be up to the user to install it (perhaps a Suggests or Recommends for the package). Currently, virtualgl depends on libgl1-mesa-glx | libgl1 which makes it even more confusing. If we're going to split the package into bumblebee-nouveau and bumblebee-nvidia it may be easier to set such dependencies.

starks commented 13 years ago

As I understand it, -experimental provides Nouveau 3D and that Nouveaubee needs it.

It may such that a person may want to optirun an app in 2D only, but I don't think that should be the default behavior.

Lekensteyn commented 13 years ago

Whenever I've time to get a nouveau setup working, I'll certainly test it. Do you have other recommendations for 3D applications to be used for testing?

Also, according to http://nouveau.freedesktop.org/wiki/MesaDrivers, kernel 2.6.38 is required for (the recommended) Gallium 3D to work which is provided with Natty and later (Maverick is shipped with 2.6.35, Lucid with 2.6.32, see http://packages.ubuntu.com/linux-image-generic).

Perhaps we should release a bumblebee with a nouveau default on oneiric and later, not Natty (unless we find a stable PPA, oibaf/graphics-drivers did not work for me).

starks commented 13 years ago

Oneiric will not be very Nouveau-friendly to the mobile Fermi chips (400M/500M) since it won't release with kernel 3.1.

320M and older should be fine.

Lekensteyn commented 13 years ago

I'm running GT425M, and 5xx is also very common now.

"It is recommended to use the Linux 3.1 kernel or newer (or a backported driver from this kernel)" (from http://nouveau.freedesktop.org/wiki/CodeNames#NVC0) Not sure if that also means that the driver may work for 3.0.

starks commented 13 years ago

On 09/07/2011 01:35 PM, Peter wrote:

I'm running GT425M, and 5xx is also very common now.

"It is recommended to use the Linux 3.1 kernel or newer (or a backported driver from this kernel)" (from http://nouveau.freedesktop.org/wiki/CodeNames#NVC0) Not sure if that also means that the driver may work for 3.0.

I haven't been able to use nouveau even with edgers and the 3.1 dailies.

Samsagax commented 13 years ago

The problem is that even xorg-edgers in Ubuntu is using an outdated version. Nouveau developers suggest and even encourage to use git code for newer cards (git as today) and report back into the irc channel to help developing.

I can talk from my distro only and my hardware: I have a 310M and is fully supported under nouveau (except a little annoyance with a i2w error) and works great on Gallium. Arch releases a new package every month of xorg-nouveau driver git. So I can test it myself: All NV50 or less is well supported under nouveau. The NVC0 is a steady WIP

See http://nouveau.freedesktop.org/wiki/FeatureMatrix for more info.

starks commented 13 years ago

NV50 Optimus and NVC0 Optimus are separate case because the former more often than the latter will have non-offloading options available such as vga/asus/byo-switcheroo due to the presence of a mux. As such, I think NVC0 should be the primary target of Bumblebee since it will be increasingly the only choice for NVC0 laptops.

At the same time, I also think it's a bit premature to promote a free/libre default or alternative to the nvidia blob for bumblebee when there are still huge problems with nouveau support for NVC0. The most profound of these problems is that you either need to extract the firmware manually using the nvidia blob or use git trees (nouveau and maybe a kernel roll for better drm) to generate the firmware. Even if Nouveau loads, other support may be lacking.

This is a fundamental problem that we need to upfront with our users should we go ahead with favoring nouveau or packaging it separately.

ArchangeGabriel commented 13 years ago

Effectively, for now, we should let nvidia as default, and just tell users that nouveau backend is ready.

starks commented 13 years ago

If you guys want comparative, real-world benchmark testing of backends, I'd recommend OpenArena or the upcoming OilRush demo.

I'd even go so far to recommend usage of the Phoronix Test Suite to organize and coordinate further benchmarking. It could shed light on where the Nouveau drivers are lacking and provide much needed data for the devs that have otherwise been unable to use Nouveau on muxless laptops.

raveit65 commented 13 years ago

Pls, let the nvidia driver as the default driver for bumblebee, because

a user opinion

Samsagax commented 13 years ago

We can discuss this as much as you want @NiceandGently. But we are trying to push as much as we can to make nouveau the default whenever possible because:

Another user opinion ;)

Lekensteyn commented 13 years ago

For now, we keep nvidia as default, but may consider using nouveau by default providing the replacement does not cause incompatibilities.

I guess we're going to release bumblebee-nouveau and bumblebee-nvidia packages in addition to the bumblebee package which would contain the static / shared stuff.

ArchangeGabriel commented 13 years ago

For your information, I've figured out that nouveau needs the PCI Bus ID of the nvidia card in its xorg.conf, else it doesn't detect it.

ArchangeGabriel commented 13 years ago

I'm unable to use nouveau, it results in : Polygons in scene: 62464 /usr/bin/optirun: line 239: 3646 Segmentation fault vglrun -c "$VGL_COMPRESS" -d "$VGL_DISPLAY" -ld "$VGL_DRIVER" -- "$@"

Lekensteyn commented 13 years ago

Try running it with gdb and get a backtrace:

optirun gdb glxgears
> run
[error here]
> bt
[backtrace here]

Also, I'm in #bumblebee-dev

ArchangeGabriel commented 13 years ago

`#0 0x00000000 in ?? ()

1 0xb7fd06d0 in ?? () from /usr/lib/i386-linux-gnu/dri/swrast_dri.so

2 0xb7ebd9de in ?? () from /usr/lib/i386-linux-gnu/mesa/libGL.so.1

3 0xb7e9b6b8 in ?? () from /usr/lib/i386-linux-gnu/mesa/libGL.so.1

4 0xb7e98193 in ?? () from /usr/lib/i386-linux-gnu/mesa/libGL.so.1

5 0xb7e982c5 in glXGetConfig () from /usr/lib/i386-linux-gnu/mesa/libGL.so.1

6 0xb7f17d16 in ?? () from /usr/lib/i386-linux-gnu/librrfaker.so

7 0xb7f1939b in ?? () from /usr/lib/i386-linux-gnu/librrfaker.so

8 0xb7efa347 in glXChooseVisual () from /usr/lib/i386-linux-gnu/librrfaker.so

9 0x0804a351 in ?? ()

10 0xb7bc2113 in __libc_start_main () from /lib/i386-linux-gnu/libc.so.6

11 0x08049101 in ?? ()

Backtrace stopped: Not enough registers or memory available to unwind further`

ArchangeGabriel commented 13 years ago

And for glxspheres : `#0 0x00000000 in ?? ()

1 0xb7fd06d0 in ?? () from /usr/lib/i386-linux-gnu/dri/swrast_dri.so

2 0xb7ebd9de in ?? () from /usr/lib/i386-linux-gnu/mesa/libGL.so.1

3 0xb7e9b6b8 in ?? () from /usr/lib/i386-linux-gnu/mesa/libGL.so.1

4 0xb7e98193 in ?? () from /usr/lib/i386-linux-gnu/mesa/libGL.so.1

5 0xb7e982c5 in glXGetConfig () from /usr/lib/i386-linux-gnu/mesa/libGL.so.1

6 0xb7f17d16 in ?? () from /usr/lib/i386-linux-gnu/librrfaker.so

7 0xb7f1939b in ?? () from /usr/lib/i386-linux-gnu/librrfaker.so

8 0xb7efa347 in glXChooseVisual () from /usr/lib/i386-linux-gnu/librrfaker.so

9 0x0804a475 in main ()`

ArchangeGabriel commented 13 years ago

Also, some users are facing issues since we don't blacklist nouveau anymore that are solved by blacklisting nouveau again. I will try to find their messages and post them here.

ArchangeGabriel commented 13 years ago

After installing debug symbols :

glxgears `#0 0x00000000 in ?? ()

1 0xb7fd06d0 in driCreateNewScreen (scrn=0, extensions=0xb7ed52bc, driver_configs=0xbfffed2c, data=0x807e2a0) at ../common/drisw_util.c:69

2 0xb7ebd9de in driswCreateScreen (screen=0, priv=0x80ad370) at drisw_glx.c:560

3 0xb7e9b6b8 in AllocAndFetchScreenConfigs (priv=0x80ad370, dpy=0x805d5d0) at glxext.c:784

4 __glXInitialize (dpy=0x805d5d0) at glxext.c:882

5 __glXInitialize (dpy=0x805d5d0) at glxext.c:803

6 0xb7e98193 in GetGLXPrivScreenConfig (dpy=0x805d5d0, scrn=0, ppriv=0xbfffedf8, ppsc=0xbfffedfc) at glxcmds.c:176

7 0xb7e982c5 in glXGetConfig (dpy=0x805d5d0, vis=0x8077da8, attribute=5, value_return=0x807840c) at glxcmds.c:862

8 0xb7f17d16 in ?? () from /usr/lib/i386-linux-gnu/librrfaker.so

9 0xb7f1939b in ?? () from /usr/lib/i386-linux-gnu/librrfaker.so

10 0xb7efa347 in glXChooseVisual () from /usr/lib/i386-linux-gnu/librrfaker.so

11 0x0804a351 in ?? ()

12 0xb7bc2113 in __libc_start_main () from /lib/i386-linux-gnu/libc.so.6

13 0x08049101 in ?? ()

Backtrace stopped: Not enough registers or memory available to unwind further`

glxspheres: `#0 0x00000000 in ?? ()

1 0xb7fd06d0 in driCreateNewScreen (scrn=0, extensions=0xb7ed52bc, driver_configs=0xbfffedcc, data=0x80ca520) at ../common/drisw_util.c:69

2 0xb7ebd9de in driswCreateScreen (screen=0, priv=0x807ac80) at drisw_glx.c:560

3 0xb7e9b6b8 in AllocAndFetchScreenConfigs (priv=0x807ac80, dpy=0x805f5d0) at glxext.c:784

4 __glXInitialize (dpy=0x805f5d0) at glxext.c:882

5 __glXInitialize (dpy=0x805f5d0) at glxext.c:803

6 0xb7e98193 in GetGLXPrivScreenConfig (dpy=0x805f5d0, scrn=0, ppriv=0xbfffee98, ppsc=0xbfffee9c) at glxcmds.c:176

7 0xb7e982c5 in glXGetConfig (dpy=0x805f5d0, vis=0x8079da8, attribute=5, value_return=0x807a40c) at glxcmds.c:862

8 0xb7f17d16 in ?? () from /usr/lib/i386-linux-gnu/librrfaker.so

9 0xb7f1939b in ?? () from /usr/lib/i386-linux-gnu/librrfaker.so

10 0xb7efa347 in glXChooseVisual () from /usr/lib/i386-linux-gnu/librrfaker.so

11 0x0804a475 in main ()`

Samsagax commented 13 years ago

Xorg server nouveau driver testcase.

I'm following the standar Arch convention on commands, when the prompt is marked as # means the command should be issues as root (via su, sudo or logged in as root user). When the promp is marked with $ then the command is issued as a regular user.

First check that Bumblebee is completely stopped and you ahve the right packages. Under ArchLinux these are the names of the needed packages to have full 3D acceleration through Gallium3D:

You can look at the contents of each package here: http://www.archlinux.org/packages/

Start the X server with nouveau

Check nouveau is loaded and it recognizes your card by checking dmesg. Otherwhise load it:

# modprobe -v nouveau
insmod /lib/modules/3.0-ice/kernel/drivers/platform/x86/mxm-wmi.ko.gz 
insmod /lib/modules/3.0-ice/kernel/drivers/gpu/drm/ttm/ttm.ko.gz 
insmod /lib/modules/3.0-ice/kernel/drivers/gpu/drm/nouveau/nouveau.ko.gz

Start X with a simple configuration file using nouveau. I'm using the stock xorg.conf.nouveau shipped with Bumblebee.

# /usr/bin/X :8 -config /etc/bumblebee/xorg.conf.nouveau -sharevts -nolisten tcp -noreset

Check for it to start successfully.

Start a OpenGL 3D application

Now make sure you ahve VirtualGL isntalled and then try to run glxgears

$ vglrun -d :8 glxgears
1791 frames in 5.0 seconds = 358.181 FPS

That will tell you that this works.

You may try another options.

Measuring performance (some unintended but nice findings)

I found that some ways to start the VGL client adds some performance that is comparable to that from xpra (at least is better than the current Bumblebee performance).

Try running glxspheres to benchmark the card performance under vglrun:

$ vglrun -d :8 glxspheres
Polygons in scene: 62464
Visual ID of window: 0x21
Context is Direct
OpenGL Renderer: Gallium 0.4 on NVA8
44.592809 frames/sec - 39.535985 Mpixels/sec

Very crappy huh? Well, now start vglclient and try using an uncompressed transport method:

$ vglclient &
$ vglrun -d :8 -c rgb glxspheres
Polygons in scene: 62464
Visual ID of window: 0x21
Context is Direct
OpenGL Renderer: Gallium 0.4 on NVA8
101.045917 frames/sec - 89.587310 Mpixels/sec

More than 2X performance. This will improve some things If we add this to the mainline

Lekensteyn commented 13 years ago

Isn't the first proxy (which we currently use)? The second can be set in bumblebee.conf using VGL_COMPRESS=rgb. It can have some graphical differences though.

Samsagax commented 13 years ago

@Lekensteyn: indeed it is, but proxy is an uncompressed method too, funny thing is that vglconnect affects performance.

Lekensteyn commented 13 years ago

Isn't that called "VGL transport", and required for rgb (and jpeg iirc)

Samsagax commented 13 years ago

Can we close this issue and remove the common-nouveau branch? This is done now and merged completely into master/develop since release 2.4. And in fact the only problem we find with this is the actual Nouveau support on some cards. On cards fully supported by Nouveau, this step is trivial. The only thing we can discuss is how to distribute differentiated packages for nvidia and nouveau.