[Nix-dev] Experiences with Nvidia Optimus?

Mathijs Kwik mathijs at bluescreen303.nl
Fri Jan 20 15:35:40 CET 2012


Hi Arie,

(Peter is cc'ed as he is maintainer for mesa)

I fixed the issue.

In a recent mesa upgrade, someone enabled the experimental gallium3d
driver for our i965-based cards.
Gallium drivers are experimental and work-in-progress for most cards,
but needed if you want to use the open-source ati (r300/r600) or
nvidia (nouveau) drivers with 3d accelleration.
For intel however, the story is different. Intel's open-source driver
has full support for 3d already, and intel stated they are not
interrested in maintaining a second implementation.
I don't know about i915, but i965's gallium driver rotted to the state
that it was thrown out of mesa trunk in november 2011 [1]. Taking i965
out fixed my issues, and all is well again, with acceleration and 3d.

I attached a patch (2 commits), the first commit upgrades dri2proto so
the intel 2_17_0 driver (which is already in nix) compiles.
The second commit removed i965 gallium from mesa. I cannot speak for
i915, but I think it would be best to make it optional (off by
default), as the non-gallium driver is stable and good enough for most
users.

Can any of you commit my patch?

Thanks,
Mathijs

[1] http://en.wikipedia.org/wiki/Gallium3D



On Fri, Jan 20, 2012 at 12:39 AM, Arie Middelkoop <amiddelk at gmail.com> wrote:
> On 19-01-12 22:57, Mathijs Kwik wrote:
>>
>> On Thu, Jan 19, 2012 at 9:52 PM, Arie Middelkoop<amiddelk at gmail.com>
>>  wrote:
>>>
>>> Hi Mathijs,
>>>
>>> Thanks for your reply. It resolved my confusion somewhat :)
>>>
>>>
>>>>> Although it is likely a separate issue, when using the intel driver,
>>>>> all
>>>>> KDE
>>>>> popdown menus have a graphical corruption (e.g. fully black), whereas
>>>>> e.g.
>>>>> popup menus in Chrome do not have any corruption. But this is an
>>>>> incentive
>>>>> to me to put in some effort to get it up and running properly :)
>>>>
>>>>
>>>>
>>>> Yes, that issue is fixed in intel 2.15, patch here
>>>>
>>>>
>>>> https://github.com/bluescreen303/nixpkgs/commit/a0f72db5786f9272735c5a797c4a1fb878de2587
>>>> I know 2.17 is available in nix repo, but it didn't compile (missing
>>>> deps). Officially 2.15+ should need newer xorg-server/mesa libs, but I
>>>> don't have issues.
>>>
>>>
>>>
>>> Version 2.15 is now apparently committed in nixpkgs. It solves the
>>> graphical
>>> corruptions indeed, although hardware acceleration even with only the
>>> intel
>>> driver does not seem to work yet ("aiglx error: calling driver entry
>>> point
>>> failed"). In fact, once in a while it does not notice that it fails and
>>> locks up the X server.
>>
>>
>> I submitted 2.15, but since today I'm having accelleration issues as
>> well. It has been running smoothly for over a month before.
>> I suspect the recent mesa&  libdrm upgrades to interfere. I will try
>>
>> to narrow it down this weekend.
>
>
> Thanks!
> Out of experience, I can tell you that in order for 2.17 to compile, you
> only need a more recent version of dri2proto. However, that does not solve
> the acceleration problem either, so I guess (as you mentioned) that more
> packages have to be changed to get a consistent set for the intel driver.
>
>
>> So your claim about new hardware isn't totally true. I think intel
>> does a nice job here and it's nixos who's lagging behind (that's not a
>> complaint though).
>
>
> Sure. My claim about new hardware was only half serious, in the sense that
> it helps when it works even when you're not running the "bleeding edge" of
> everything ;)
>
>
>> Ubuntu and Arch do stay up to date and bump on all these small
>> inter-module issues and find out the best dependencies. But they have
>> a far larger developer-base and userbase to report and test issues.
>> So for nix - as long as no-one has issues - it's easiest/safest to
>> stick to the "monolithic" xorg releases.
>
>
> I thought of two simple strategies that I simply wanted to try:
>
> a) try the latest version of all the X11 packages. I wrote a simple shell
> script that would crawl the xorg mirror and update the .list files. With
> those I could at least rebuild xserver etc, but I wasn't patient enough to
> really test it out (it started building thunderbird and the gimp so it got
> at least very far in the process)
>
> b) try the versions of the packages that are ~amd64 in the gentoo ebuilds. I
> have at least one system running those, so I know that these should "work"
> together. Also, these are likely close to (a).
>
> These strategies are fairly automatic, which would be nessesairy for me
> because I lack the knowledge and time to find out what the smallest change
> would be...
>
> but if you would be able to find a less rigorous solution, then I'd be very
> happy :)
>
>
>> Just out of interest (since you have a recent laptop as well): Does
>> the suspend functionality work when you close the lid? Mine doesn't by
>> default because of the USB3 driver, but I found a workaround which I
>> can submit to nixos if others need it.
>
>
> I have no problem with the machine entering a suspended state. Hower, I did
> notice that it doesn't always come out of the suspend. I guess that this is
> again related to the videocard issue.
>
> Perhaps it's relevant to mention that I have some TAxas Instruments device
> as USB3 controller, which may be different from yours:
>
> USB Controller: Intel Corporation Cougar Point USB Enhanced Host Controller
> #2 (rev 05)
> USB Controller: Texas Instruments Device 8241 (rev 02)
>
> Let me know if I can help you somehow.
>
> Cheers,
> Arie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xorg-intel-fix.patch
Type: text/x-patch
Size: 2693 bytes
Desc: not available
Url : http://lists.science.uu.nl/pipermail/nix-dev/attachments/20120120/7d31ef3f/attachment.bin 


More information about the nix-dev mailing list