NVIDIA Talks Of Optimus Possibilities For Linux

[dfx.]

ignorance vs. wisdom

For whatever reason, the management at Nvidia will not allow this. I'd hope the kernel developers realize that not every company can, or is willing to, release OSS drivers for their product. If the kernel devs are going to object on moral grounds, why not remove support for binary blobs altogether?

again, "moral" bullshit...
there is are "moral grounds". there are good, practical fucking reasons for rules, regulations and licensing in place to ensure that no participant sways the blanket on their side, so to speak, and no user interests are diminished while they're trying to do so.

That last bit of freedom you're asking for can be quite expensive. If we make life easier for binary blobs, the result will be more binary blobs. More binary blobs equals less freedom. So by asking for more you get less.

I sometimes use closed source software as well, but I try very hard not to become dependent on it. Once you're stuck... you're stuck.

words of wisdom, Words of Fucking Wisdom, man!
it's good that there are still people with damn clue.

[Pajser]

i hope they left nvidia in the dark. this anti open-source company should die.

nvidia can survive without Linux users, can users* use Linux without nvidia drivers?

*who own nvidia hw

[popper]

Isn't that mean DMA-BUF may be used in Intel, nouveau and R600g drivers for implementation Optimus and AMD Dual Graphics in FOSS drivers?

It's meant for sharing dma-able memory between drivers. That could be muxless hybrid laptops, zero copy video between v4l and drm, etc.

AMBER GRANER of the

Linaro vendors

did a write-up of why ARM needs it

http://www.linaro.org/linaro-blog/2012/01/12/linaros-emphasis-on-dma_buf-in-the-3-3-linux-kernel/

POSTED ON

JANUARY 12, 2012

BY

AMBER GRANER
Linaro’s Emphasis on dma_buf in the 3.3 Linux Kernel

Jesse Barker, Graphics WG (Working Group) Tech Lead for Linaro shares with readers the importance and challenges in getting dma_buf inclusion for 3.3 Linux Kernel.Back in April, as we—a collective group of hardware vendors, software vendors, kernel developers and maintainers from across many areas of the Linux community—were preparing for the memory management mini-summit at Linaro Connect (still called Linaro Developer Summit at the time), and later during the event itself, identified three main areas within the kernel that would need explicit attention, if our “holy grail” use case of a zero-copy video to graphics to display pipeline were to be realized. There were user-space API considerations as well; however, we needed to focus on the kernel first.

First, we needed to address the requirement of devices that lack ......
...
....
Last, but not least, we needed a way for device drivers within the kernel to “share” buffers, that is to have the same buffer mapped for access by multiple devices. This is the crux of the zero-copy pipeline. The core piece of this mechanism is a kernel data structure called “struct dma_buf” which gives device drivers the interfaces they need to negotiate this sharing. Version 3 of the initial proposal for the basic plumbing (much more functionality is needed to fully support something like a modern GPU driver) was recently integrated into Dave Airlie’s DRM tree and pulled into Linus Torvalds’ kernel tree for 3.3 of the Linux kernel. .....


https://wiki.linaro.org/OfficeofCTO/MemoryManagement
Memory / Buffer Management

Overview

Architecture for hardware accelerators- efficient mechanism for memory sharing and plug-in. Currently, multiple methods used for memory sharing and SoC specific performance optimizations. Consolidation and upstreaming of the merged module is required. A common and efficient mechanism with the capability to use virtual memory for accelerators.

• Share buffers across ARM, video hw and GPU
• Similar to hwmem/UMP API but single widely adopted API across all
• Relying on memory regions and hotplug

Activity in kernel WG + MM experts from landing teams. Visibility into proprietary MM from each Vendor is required
Project tracking for discrete work items can be found here

[enrico.tagliavini]

I really hope a way to do buffer sharing between nvidia blob and intel will be found. It would be even better if it will use DMA-BUF. This without violate Kernel owner's rights indeed. But i do really hope Kernel devs can understand the importance of having fully functional hardware. There must be balance between philosophy and engineering. Too much philosophy (enforcing on user and devs rights and freedom) and you may actually hust the user from a practical point of view, too much engineering and you will end loosing your freedom (as with an ipad, aka the cool jail).

Non working or semi-working hardware due to driver misses is the stopper for linux as a desktop. FOSS drivers are just semiworking (except the intel one, since that's the main driver done by the manufacter). Radeon is not bad, AMD supports it, but with a limited man power, nouveau is a russian roulette.

I don't like having binary drivers. I strongly believe in free software (as in freedom). But i like even less having a non working hardware. You don't have choices in Graphic card world. AMD and NVIDA have binary drivers, and by mean they are superior then the FOSS alternative (with some drawbacks, but still better from a pure practical point of view, ignoring license). Ok there's intel, but here you might have a limit on the power, depending on what you usually do with your pc. If you don't do heavy graphic works then it is just a pleasure to use intel (i have it at work, and i like it very much).

I would never accept, for example, a propertary scheduler for the linux kernel, but i can live with a propertary device driver (if it is done well, and works as expected), it is binded to the hardware, i can change it if i'm not happy, and migrate to a more free software friendly vendor.

Propertary software is not all bad, the world is not black and white. NVIDIA at least do something for free software (eg Xorg patches if i'm right).

So i wish to kernel devs to do the more wise choice, whatever it will be

[patrik]

I really hope a way to do buffer sharing between nvidia blob and intel will be found. It would be even better if it will use DMA-BUF. This without violate Kernel owner's rights indeed. But i do really hope Kernel devs can understand the importance of having fully functional hardware. There must be balance between philosophy and engineering. Too much philosophy (enforcing on user and devs rights and freedom) and you may actually hust the user from a practical point of view, too much engineering and you will end loosing your freedom (as with an ipad, aka the cool jail).

I used to argue the same way you do but after 15 years of Linux on my desktop I've seen the consequences. You would most likely already have Optimus support if the driver had been open. Tossing nvidia a bone here because they are late to the party will not make things any better in the future.

Non working or semi-working hardware due to driver misses is the stopper for linux as a desktop.

Stopped by manufacturers, not by Linux. Only having binary drivers for Linux is also a stopper for Linux on the desktop. Either way you loose.

FOSS drivers are just semiworking (except the intel one, since that's the main driver done by the manufacter). Radeon is not bad, AMD supports it, but with a limited man power, nouveau is a russian roulette.

Your point here is that FOSS drivers backed by manufacturers are good. Drivers with no backing are bad. I totally agree with that.

I don't like having binary drivers. I strongly believe in free software (as in freedom). But i like even less having a non working hardware. You don't have choices in Graphic card world.

The manufacturers aren't giving you a choice. Linux developers around the world are trying to help you with this.

AMD and NVIDA have binary drivers, and by mean they are superior then the FOSS alternative (with some drawbacks, but still better from a pure practical point of view, ignoring license). Ok there's intel, but here you might have a limit on the power, depending on what you usually do with your pc. If you don't do heavy graphic works then it is just a pleasure to use intel (i have it at work, and i like it very much).

This is a good description of the current situation. But it's not a good situation.

I would never accept, for example, a propertary scheduler for the linux kernel, but i can live with a propertary device driver (if it is done well, and works as expected), it is binded to the hardware, i can change it if i'm not happy, and migrate to a more free software friendly vendor.

As you stated above, this is not the case for graphics cards. If you need performance, you must use a binary driver.

Propertary software is not all bad, the world is not black and white. NVIDIA at least do something for free software (eg Xorg patches if i'm right).

Binary drivers are fine as long as they don't have bugs and are updated at the same time the software they interact with change. I don't see any of those drivers around? If you load a binary driver your whole kernel gets tainted, and as a consequence you cannot contribute back to the kernel in form of bug reports. Without bug reports the bugs will not get fixed. If Linux is full of bugs, it will not succeed on the desktop, mobile or server platform. I understand your reasoning but in this case the nvidia way of serving their customers is counter productive for the rest of the Linux community. Use the proprietary nvidia driver if you must, but at least don't tell that to nvidia

So i wish to kernel devs to do the more wise choice, whatever it will be

They have been doing the right thing for years, but from a user perspective it's not always that obvious.

[TheBlackCat]

I used to argue the same way you do but after 15 years of Linux on my desktop I've seen the consequences. You would most likely already have Optimus support if the driver had been open. Tossing nvidia a bone here because they are late to the party will not make things any better in the future.

That argument would be more compelling if NVidia actually cared about desktop and laptop Linux users. They don't, they mostly see Linux as a workstation and high-performance computing operating system (hence their support for cuda, for example). Primarily laptop-oriented technologies like optimus and xrandr are simply not considered important by them, both according to their own statements and their history of (non-) support for such technologies.

So making it harder for them isn't going to convince them to change their ways, it is simply going to make them give up. They simply aren't willing to allocate many resources to getting something like this working, so the harder you make it the less likely they are going to do it at all. As long as releasing binary blobs that share most features between all three operating systems is going to satisfy what they see as their primary audience, why would they change to a much more costly and difficult method of supporting a unique, open-source, linux-only driver?

The only way to convince NVidia that supporting open-source drivers is if there is sufficient market pressure to do so. It would be great if there were enough people using Linux on their laptops that this were the case, but it isn't right now, and it probably never will if people can't use their hardware properly.

[crazycheese]

That argument would be more compelling if NVidia actually cared about desktop and laptop Linux users. They don't, they mostly see Linux as a workstation and high-performance computing operating system (hence their support for cuda, for example). Primarily laptop-oriented technologies like optimus and xrandr are simply not considered important by them, both according to their own statements and their history of (non-) support for such technologies.

While this is true, Id like to remind you that AMD also has vision of fglx being workstation-only driver.
Now draw the comparison lines and you have nvidia driver which is still superb after so many years, on much wider hardware range and base system (kernel,glibc,xorg) versions.

And as of opensource driver, radeon gets too few actual company support and no possiblity for card buyers to support it, except code themself.

[patrik]

That argument would be more compelling if NVidia actually cared about desktop and laptop Linux users. They don't, they mostly see Linux as a workstation and high-performance computing operating system (hence their support for cuda, for example). Primarily laptop-oriented technologies like optimus and xrandr are simply not considered important by them, both according to their own statements and their history of (non-) support for such technologies.

If they don't care about desktop Linux we will not get the support we need for our hardware anyways. Sacrificing bits and pieces of what is good about Linux is not worth it IMO.

So making it harder for them isn't going to convince them to change their ways, it is simply going to make them give up. They simply aren't willing to allocate many resources to getting something like this working, so the harder you make it the less likely they are going to do it at all. As long as releasing binary blobs that share most features between all three operating systems is going to satisfy what they see as their primary audience, why would they change to a much more costly and difficultaus method of supporting a unique, open-source, linux-only driver?

Making it easier will not convince them to change either. By loading their binary modules you effectively give up control of you kernel and many of the advantages you get from it being open. If you don't intend to contribute back to the community this is fine, but the community will not be able to help you. This goes for both you and nvidia.

The only way to convince NVidia that supporting open-source drivers is if there is sufficient market pressure to do so. It would be great if there were enough people using Linux on their laptops that this were the case, but it isn't right now, and it probably never will if people can't use their hardware properly.

You're not telling nvidia that they should go open source by using their closed driver. What you are doing is telling nvidia that you think it is ok to cripple the Linux ecosystem in exchange of making your hardware work for now.

I understand your opinion but I'd like you to look at the bigger picture. I would never trade Linux for better hardware support because only Linux can give us the hardware support we need. Windows is a great example of what you would get if you put too much binary sauce into the mix.

[bridgman]

Id like to remind you that AMD also has vision of fglx being workstation-only driver.

Not true. Workstation is first priority for fglrx but I don't think anyone has ever said workstation-only. If you turned the statement around and said that we see 3D workstation as fglrx-only that's probably more true, but it's a completely different statement.

And as of opensource driver, radeon gets too few actual company support and no possiblity for card buyers to support it, except code themself.

It's open source... there are all kinds of other ways for users to support it without coding themselves. What you asked for before was an amd.com web page that lets card buyers to "support the open source drivers" by magically making more money appear for developers, but I've never been able to understand where you think the money will come from. We can't take it away from fglrx, so how is it supposed to work ?

[bridgman]

What does all that have to do with the question, which was how crazycheese's request for an amd.com web page was supposed to help open source development without taking funds from fglrx or increasing our overall Linux spend ?