Bickering Continues About NVIDIA Using DMA-BUF

[elanthis]

isnt optimus just a crappy solution to the performance hit caused by compositing ?

Not even remotely.

Optimus allows a computer to use both the integrated GPU and a discrete GPU in an efficient manner. This is most important for laptops, where you want the discrete GPU sometimes for the speed, features, and power, but you want the integrated GPU when you're just dicking around on the Web or using office apps to conserve on power and prolong battery life.

The Optimus approach in Windows is a giant hack, yes. Optimus on Windows makes use of a registry of applications to determine at the driver level whether the app should be directed to the discrete GPU or not, which is a pain since you need to keep an app database up to date and have to manually override add entries to the DB (which is a few clicks in a context menu to do, but still) for any apps you build yourself. This is necessary right now because the current Direct3D API (as well as the current OpenGL API, of course) lacks a smart way to select an "appropriate" device. You can ask for a default device for a display, or you can ask for a specific device out of the list of all available devices, but there's no way currently to say "hey OS, I'm a high-performance app, give me whichever device is fastest" or to say "hey OS, I'm only making light use of the GPU, give me the low-power device." There's also an issue where a lot of apps don't support having the GPU swapped out from under them, even though the Direct3D API actually makes supporting that about as easy as could be expected (compared to OpenGL, which completely lacks any direct means of supporting it, since the OpenGL API assumes that your configured context will never ever be destroyed or invalidated unless the app explicitly requests it), so the driver can't dynamically switch to the high-end GPU after an app is started (e.g., by using heuristics to determine the app is a game or content tool that is better off on the discrete GPU).

OS X's implementation does things equally bad, where the decision on which GPU to use is tied which API is used to do rendering. As soon as you use OpenGL directly (or one of the higher-level GL wrappers) OS X assumes the app needs high-speed graphics and switches to the discrete GPU. You're forced to the use the proprietary rendering kits Apple provides to get good-looking high-speed graphics that stick to the low-power GPU.

Linux has an opportunity here to beat the other OSes to the punch and deliver on an actually sane API (as an EGL extension or a custom API in Wayland/GLX) that allows apps to indicate whether they'd prefer high-performance or low-power. Hell, it might even go so far as to add some OpenGL extensions to make having the context invalidated for a forced graphics switch to actually work. Which is better anyway for things like hibernate; much better to just wipe the context away and expect the app to reinitialize it after wakeup, especially for a game with potentially 1+GB of textures and buffers and whatnot for modern graphics/hardware.

The next version of DirectX (unfortunately not the version in Win8, which is primarily targeted at tablets that don't have switchable graphics) will include some updates to DXGI to make OS-native switchable graphics more natural, and remove the reliance on hacks like Optimus (or worse, the physical switches that you still find on some AMD-based notebooks). Given Khronos' track record with doing anything correctly or in a timely manner, hell if anyone knows when OpenGL+EGL will gain a good native solution.

[elanthis]

And these markets are getting even more important for discrete GPU vendors like NVidia as the end user desktop is moving away from discrete GPU's to GPGPU solutions. Also since NVidia can't get a licence to produce their own GPGPU solutions on the x86 architecture the x86-based user desktop is becoming a dead market for them as their days there are numbered.

GPGPU doesn't mean what you think it means.

Any somewhat recent discrete NVIDIA GPU _is_ a GPGPU solution. All "GPGPU" means is "general purpose GPU." In other words, using a GPU for non-graphics tasks, by supporting CUDA, DirectCompute, OpenCL, or OpenGL 4.3 Compute Shaders (or even using normal graphics pipeline shaders for non-graphics work, which of course has been done quite a bit and is what inspired the creation of the GPGPU-oriented APIs).

There are some theoretical advantages to having the GPU integrated with the CPU (or more accurately, the memory bus that is these days integrated in the CPU) since it can make it faster to transfer data to/from the GPU, but those advantages are minor compared to the massive speed improvements the GPU gets by having a dedicated high-speed GDDR memory controller, and those advantages also are diminished when you take into account that newer NVIDIA (and soon AMD, I'd suspect) GPUs can directly interface with the PCI-E bus and system memory controller.

[elanthis]

Hmm, speaking of licensing, I wonder... Would it theoretically be possible to have a "half-closed" driver? Say, open-source bits that are yours, and leave a part of the code that isn't yours as closed-source.

Sure, but only so long as the closed part is entirely in userspace (if you want to keep the GPL defenders on lkml happy).

Also, you seemed to imply that it was Windows' fault that parts of the proprietary drivers are proprietary. That is not so. You are fully allowed to publish Free drivers for Windows, GPL'd even (keeping in mind that the GPL allows you to use non-Free APIs that are part of the core OS the GPL code is running on). More than one such driver exists, although they're very rare to see (and are rarely hardware drivers).

Almost any third-party code in their drivers is something voluntarily licensed, excepting maybe the support code for the following point.

The BIG item for the video drivers is the movie decode and DRM stuff that they must support in order to sell products to most consumers. If they accidentally open up those interfaces in the wrong way (.e.g, a way that allows the DRM to be bypassed) then they are going to get hosed from the folks they licensed the patents from and promised they'd keep the DRM lock tight. Since their hardware must support these DRM mechanics in order to be marketable to the larger consumer GPU market, and since those interfaces are apparently still partially protected by driver black magic and an assumption that nobody will figure out the hardware interface to the video decoder units, they are somewhat forced to avoid documenting said interfaces or publishing open code for them.

It may just be beneficial for someone to reverse engineer those and (re)illustrate the folly of security through obscurity, and either force the hardware vendors to move all the DRM protection entirely into the hardware, or (by some miracle) finally get everyone to give up on DRM altogether (good freaking luck).

[Ex-Cyber]

It may just be beneficial for someone to reverse engineer those and (re)illustrate the folly of security through obscurity, and either force the hardware vendors to move all the DRM protection entirely into the hardware, or (by some miracle) finally get everyone to give up on DRM altogether (good freaking luck).

Heck, even if they had put it entirely in hardware in the first place, HDCP itself is completely cracked now (and IIRC even before that some keys had leaked to manufacturers of HDCP-stripping devices), which means that the media companies have to get everyone to upgrade their TVs again if they want another shot at it. I'm guessing that won't happen until about 2020.

[vertexSymphony]

isnt optimus just a crappy solution to the performance hit caused by compositing ?

Actually it's a crappy solution for the "energy consumption" + "compute power and features" relationship of today's GPUs ...

Linux has an opportunity here to beat the other OSes to the punch and deliver on an actually sane API (as an EGL extension or a custom API in Wayland/GLX) that allows apps to indicate whether they'd prefer high-performance or low-power. Hell, it might even go so far as to add some OpenGL extensions to make having the context invalidated for a forced graphics switch to actually work. Which is better anyway for things like hibernate; much better to just wipe the context away and expect the app to reinitialize it after wakeup, especially for a game with potentially 1+GB of textures and buffers and whatnot for modern graphics/hardware.

+1

We could even have profiles like cpufreq ... performance (discrete)/powersave(integrated)/ondemand(workload based? some cards have performance counters? dunno how reliable is that, but should be easy to pick one counter of any kind - temp included? - and customize ranges to switch profiles )

That would be SO AWESOME.

Regards.

[Pallidus]

they aren't going to allow nvidia to do this so discussion is over.



and if the impossible happens and they do, I will remove all traces of linux from every machine I own and I will spit everytime I see the name linux mentioned.

[Sonadow]

-SNIP-

EDIT: never mind, I take that back. I'm quite tired of going along with the arguement.

[vertexSymphony]

-SNIP-

EDIT: never mind, I take that back. I'm quite tired of going along with the arguement.

I don't want this to get lost ... this says a lot about the kind of people that argues "fuck freedom, we want optimus", I'll leave it for educational purposes



Nothing new under the sun ...

[asdx]

they aren't going to allow nvidia to do this so discussion is over.



and if the impossible happens and they do, I will remove all traces of linux from every machine I own and I will spit everytime I see the name linux mentioned.

Same here.

[gamerk2]

Steam is closed source software.
The NVIDIA binary driver is closed source software.

Steam has some notorious security holes (http://www.tomshardware.com/news/Ste...ort,18498.html)
The NVIDIA driver *may* have some security holes.

Steam is treated as the savior to gaming on Linux.
NVIDIA is treaded as the devil to Linux.

......

Anyone else see the blatant hypocracy here? Why are so many going after the best driver on the entire OS, then proclaiming how great it is to finally get Steam?