Nouveau support #18
Comments
|
It is a shame that you removed the nouveau support from the openSuSE version... |
|
@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. |
|
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. |
|
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 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. |
|
The installer needs another stage for the driver.
Looks like there must be a stage between welcome and checkdependencies. Proposal:
Now, to be flexible in packaging, we should probably package like this:
|
ghost
assigned
|
Ok. I'm again on the run for this one:
Added the two options for AVAILABLE_DRIVERS array. The only thing to discuss is which would be the default one.
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. |
|
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. |
|
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. |
|
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. |
|
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 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. |
|
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). |
|
The branch 'common-nouveau' is merged into develop. Now comes the testing part and bugfixing the installer mostly |
|
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: |
|
Todo: allow the installer to install multiple drivers, I'll do that. |
|
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 ? |
|
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 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:
|
You won't check for Justin Beiber distro either? :'( < BIG FAT LOL! |
|
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: 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? |
|
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. |
|
I missed a trailing comma in the code which I've now edited in. For the installer, I've decided to extend Please join #bumblebee-dev for a faster discussion |
|
@ArchangeGabriel: should we really make nouveau the default driver for Ubuntu? |
|
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. |
|
@Lekensteyn: For this release, I'm packaging it only for nvidia. Will see later for nouveau. |
|
@ArchangeGabriel: that's fine, I'll include the updated bugreport tool too and update the ppa files to use nvidia. |
|
On the Ubuntu side of things, shouldn't libgl1-mesa-dri-experimental be a dependency? |
|
From it's package description: 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. |
|
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. |
|
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) |
|
On 09/07/2011 01:35 PM, Peter wrote:
|
|
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. |
|
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. |
|
Effectively, for now, we should let nvidia as default, and just tell users that nouveau backend is ready. |
|
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. |
|
Pls, let the nvidia driver as the default driver for bumblebee, because
a user opinion |
|
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 ;) |
|
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. |
|
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. |
|
I'm unable to use nouveau, it results in : |
|
Try running it with Also, I'm in #bumblebee-dev |
|
|
|
And for glxspheres : |
|
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. |
|
After installing debug symbols : glxgears glxspheres: |
Xorg server nouveau driver testcase.I'm following the standar Arch convention on commands, when the prompt is marked as 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 nouveauCheck nouveau is loaded and it recognizes your card by checking # 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.gzStart X with a simple configuration file using nouveau. I'm using the stock # /usr/bin/X :8 -config /etc/bumblebee/xorg.conf.nouveau -sharevts -nolisten tcp -noresetCheck for it to start successfully. Start a OpenGL 3D applicationNow make sure you ahve VirtualGL isntalled and then try to run $ vglrun -d :8 glxgears
1791 frames in 5.0 seconds = 358.181 FPSThat 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 $ 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/secVery crappy huh? Well, now start $ 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/secMore than 2X performance. This will improve some things If we add this to the mainline |
|
Isn't the first proxy (which we currently use)? The second can be set in bumblebee.conf using |
|
@Lekensteyn: indeed it is, but proxy is an uncompressed method too, funny thing is that vglconnect affects performance. |
|
Isn't that called "VGL transport", and required for rgb (and jpeg iirc) |
|
Can we close this issue and remove the |
|
No, in fact there are some problems with nouveau others than lack of support for some hardware. First, since we're not blackilisting nouveau anymore, some users can't use nvidia. So we need to work a little more on this. Next, we still didn't decided as you said how to package different drivers. Finally, there is still some things to enhance in my opinion about the driver management in the daemon. |
|
About the blacklisting thing, isn't that resolved now we unload the loaded driver (often nouveau)? bumblebee, depends on bumblebee-driver Perhaps it does not have to depend on bumblebee-driver at all since some users only need the power saving. @ArchangeGabriel have a look at the WIP bbswitch at https://github.com/Lekensteyn/acpi-stuff/tree/master/bbswitch for power saving. |
Well that's not true, I have nouveau inserted at bootup and if I switch the configuration to use Nvidia then the daemon unloads nouveau and loads nvidia (I don't like that, but in fact it does), as @Lekensteyn stated. And that can be solved by the bumblebee-driver packaging solution (When bumblebee-nvidia package is installed it can "eventually" balcklist nouveau). Still is a matter of system/user/machine CONFIGURATION. That's a thing that should be left to distribution packagers. All post installation steps needed are in fact left to packagers. But maybe I'm being too user-centric about this. I meant no offenses but we should try to put some more credit on users (you'll be surprised) on managing their systems. And probably improve the documentation. The new installation method is purely intended for distribution packagers and somewhat "advanced" users (those who can actually open a terminal and run Btw: @Lekensteyn, great work on the bbswitch, I know is utterly green right now, but it still doesn't break anything :P. I couldn't make it work. Because the calls are hardcoded and I need my own |
|
Will look at it next WE Lekensteyn, doesn't have the time right now. About blacklisting, some people can't load nvidia even with our method (unload nouvea -> load nvidia), loading nvidia fails with such error messages : P.S.: Some others users are having different problems that are also solved by blacklisting nouveau. That's currently one of the first thing I try when facing a unknown problem. And here vmalloc just does nothing, but blacklisting nouveau solves the problem. So, that's truly a problem. |
|
A post-installation step regarding this issue would do the trick then. Still I wouldn't blacklist nouveau unless the user will use nvidia-only configuration. That indeed would be solved by packaging. And still I see this as a non-supported issue by nouveau card issue because is nouveau driver when inserted that messes up with the memory of the card, by blacklisting it you don't insert nouveau in the first place, then the memory is not touched. Regarding this last statement, could you follow this testcase and report back?
the part I'm interested is in the |
|
Will try all this as soon as possible, hope today or tomorrow/sunday. |
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"
The text was updated successfully, but these errors were encountered: