If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

NVIDIA Talks Of Optimus Possibilities For Linux

01-25-2012, 11:10 AM

Phoronix: NVIDIA Talks Of Optimus Possibilities For Linux

A NVIDIA Linux engineer is trying to work on code that could lead to official Optimus support under Linux, but there's a catch... And it falls outside of NVIDIA Corp as the fate of this multi-GPU notebook feature could now fall with the Linux kernel developers...

Comment

"but we for better or worse can't share much infrastructure like DRI."

I don't understand why they can't do that ?
They can't share the user space OpenGL driver, I can understand, but why the DRI ?
The DRI part could be split from the user space OGL driver and could live in the kernel space, I believe that a number of SoC vendors already behave like this.

Comment

"but we for better or worse can't share much infrastructure like DRI."

I don't understand why they can't do that ?
They can't share the user space OpenGL driver, I can understand, but why the DRI ?
The DRI part could be split from the user space OGL driver and could live in the kernel space, I believe that a number of SoC vendors already behave like this.

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?

Comment

"but we for better or worse can't share much infrastructure like DRI."

I don't understand why they can't do that ?
They can't share the user space OpenGL driver, I can understand, but why the DRI ?
The DRI part could be split from the user space OGL driver and could live in the kernel space, I believe that a number of SoC vendors already behave like this.

Their driver stack is different. They could either rewrite it to use the DRI, or continue to use the mechanism that they presumably share with their windows driver. Rewriting is more work for dubious benefit, so...