NVIDIA Developer Talks Openly About Linux Support

[TeoLinuX]

--every single word--

mega-quote!!!!!

[next9]

painful graphics segment

It is strange situation in Linux graphics. I can't imagine any other segment of HW, that was so perseveringly sabotaged by HW vendors. Nowhere else is so much hogwash about IP. In every other segment, there is at least one major vendor who supports Opensource way.

I appreciate nVidia efforts to provide binary driver in those dark times, but this solution is not sustainable for a long time. OSS driver is nescessary and former Linux-ignorant ATI under the direction of AMD showed, that it could be done.

What else?

1) ATI strongly attacks nVidia at Windows/DirectX segment.

2) It is obvious fact, that nVidia does not have x86 license, so production of own independed CPU+GPU solution for Windows is imposibble. With binary software, they can hardly go non-Windows (Linux) way with another CPU architecture.

3) With ATI and nVidia binary drivers become close, ATI would have real advantage of additional OSS driver.


Summary: It is time to test actual ATI drivers with some HD4000/5000 card, and I will see....

[Ant P.]

I can't imagine any other segment of HW, that was so perseveringly sabotaged by HW vendors.

How about motherboard and chipset stuff? To date none of the big BIOS makers have contributed anything (but they're all too happy to sell Splashtop back to you on a preinstalled-Windows hard disk), and hardware RAID is notoriously proprietary.

[droidhacker]

Despite statements to the contrary, this IS typical marketing BS. Not to mention the fact that the questions asked were *SEVERELY* sensored from those listed in the original thread. Yes, some of the questions were rude, but facing rude questions is the price you pay for writing a binary blob driver for Linux.

They have basically come out and stated in no uncertain terms, that they are sitting on their a$$es.

How exactly does the code being shared between microshaft and *nix relate to supporting open source? We don't want your crap code. We want *specifications*.

IP from specifications? You know perfectly well that everything in your chips has been reverse engineered and documented by AMD, Intel, and everyone else with deep pockets using electron microscopes (since that is what you yourself do...), so the only groups who could benefit (in the sense that they would compete with you) from the IP giveaway (i.e. those who are in the GPU business) that the specifications might lead to *ALREADY HAVE IT*.

Good news is that the AMD OSS drivers are in a great state. I think I'll drop the $25 and pick up a nice new AMD card -- light all my nvidia's (2) on FIRE.

[droidhacker]

How about motherboard and chipset stuff?

What... you mean this: http://www.phoronix.com/scan.php?pag...item&px=NzQzOQ ?

To date none of the big BIOS makers have contributed anything

Nice thing about bios is that the magical info needed is what I showed you just up above... and it leads to stuff like this: http://www.coreboot.org/Welcome_to_coreboot

and hardware RAID is notoriously proprietary.

Really? We're talking REAL HARDWARE RAID, or that fakeraid nonsense? Because last I checked, most of the *REAL* hardware raid manufacturers (adapted, 3ware, etc.) were very friendly to open source...

[mtippett]

The main comments below are asking what is the usage of the tech, not what is the tech itself.

Nothing new:
- NO KMS

KMS is an interesting one, where do you get value from this? There are a couple of areas that it might add vale.

o BSOD equivalence - get the log messages on the screen with an oops. The joke of the Windows world applied to Linux. I would expect it'll feel just like the old Sun Workstations from 20 years ago.
o "Flicker free" boot. Well, I don't really see too many problems with this. Sure Apple has it - but that is a closed system, top to bottom. But what value does it *really* provide?

- NO Gallium3D
- NO EXA

These are implementation details. Let me translate

o Gallium3D (or DRI2) - Full support for composited environments, OpenGL, OpenCL, xV client support. You already get that without it on NV and ATI drivers. Just a different model. Gallium3D is a refactoring of the architecture to easily support more clients without needing lots more developers.
o EXA - increased 2D performance (and RENDER and dynamic framebuffer realocation). Again, EXA isn't needed. dynamic framebuffer reallocation doesn't need EXA, but it does need RANDR1.2+ to be useful).

Start with the user or application facing features that you want and dive down from there. What are the features your *really* want.

The assumption that a single implementation is the *only* path to achieving a user visible feature usually ends up with comprimise. The composited desktop has many paths right now. XGL was an interesting idea, but ultimately went away. Same for EXA for intel (UXA).

Regards,

Matthew

[mtippett]

I think that such a high % of code sharing between windows and Unix drivers will prevent nVidia from implementing many new trendy and innovative features that are peculiar to Linux. And it'll prevent them from releasing any tech docs too.

Most of the code sharing would be abstracting the hardware itself. Most of the trendy or innovative features are in the Unix specific code anyway. Ironically, it is the code sharing that allows some trendy things to be done with minimal effort.

Having a confirmation that drivers are developed mainly on the needs of OEM and professional workstation users make me sad, because that sounds like they'll put general desktop users on a low consideration. Let alone gamers

Follow the money.

Semiconductor companies mostly sell chips. The OEMs, ODMs, AIBs and so on make the products that you buy. It's only when handing over a cheque that you can also add a "and add this feature".

If there is money in the linux desktop, then there will be a money trail there too. In the PC market, it is the OEMs who buy the OS for the system they sell. Or the SIs that get involved in large deployments.

If you don't have a money trail, you don't get the corporate investment. Great things can happen without corporate investment, but it's rare (don't use Linux - Linus is a strong leader, and the corp investement in Linux has *always* been huge, it's just that there isn't corp leadership).

Regards,

Matthew

[Ant P.]

What... you mean this: http://www.phoronix.com/scan.php?pag...item&px=NzQzOQ ?


Nice thing about bios is that the magical info needed is what I showed you just up above... and it leads to stuff like this: http://www.coreboot.org/Welcome_to_coreboot


Really? We're talking REAL HARDWARE RAID, or that fakeraid nonsense? Because last I checked, most of the *REAL* hardware raid manufacturers (adapted, 3ware, etc.) were very friendly to open source...

Last time I checked, Adaptec support got kicked out of OpenBSD for the exact opposite.

[mtippett]

It is strange situation in Linux graphics. I can't imagine any other segment of HW, that was so perseveringly sabotaged by HW vendors. Nowhere else is so much hogwash about IP. In every other segment, there is at least one major vendor who supports Opensource way.

Find another HW segment that replaces a good portion of their flagship product on a 12 monthly cycle.

If you have been following bridgman's comments on ATI's threads, each product family has at least one part that is a major diversion from the previous generation. That's where the first part of the issues come in. Each new product family costs 10's to 100's of effort-years of development. You can argue that OSS if fast and nimble, but that is still an incredible challenge.

Gallium3D goes a long way to simplifing and abstracting the HW out of the drivers, and is a boon for OSS driver development.

[next9]

How about motherboard and chipset stuff? To date none of the big BIOS makers have contributed anything (but they're all too happy to sell Splashtop back to you on a preinstalled-Windows hard disk), and hardware RAID is notoriously proprietary.

AFAIK chipset are well supported by kernel thus their drivers are opensource. I don't know the situation precisely, but at least AMD release documentation.

So called HW raid integrated on motherboards IS NOT HW raid. it is traditional software raid, modified to motherboard BIOS (now called firmware RAID), because the great Redmond OS is unable to boot from traditional SW RAID. It is bullshit to use this crap in Linus instead of SW RAID.