Linked by Thom Holwerda on Fri 11th May 2007 18:17 UTC, submitted by diegocg
Intel "The Intel 965GM Express Chipset represents the first mobile product that implements fourth generation Intel graphics architecture. Designed to support advanced rendering features in modern graphics APIs, this chipset includes support for programmable vertex, geometry, and fragment shaders. Extending Intel's commitment to work with the X.org and Mesa communities to continuously improve and enhance the drivers, support for this new chipset is provided through the X.org 2.0 Intel driver and the Mesa 6.5.3 releases. These drivers represent significant work by both Intel and the broader open source community."
Thread beginning with comment 239504
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: OpenGL support
by stephanem on Fri 11th May 2007 21:18 UTC in reply to "RE: OpenGL support"
stephanem
Member since:
2006-01-11

Are you jocking? Installing Nvidia propietary drivers is a pain in the ass. Nothing comes close to open source Intel drivers that get compiled and included along the rest of opensource drivers.


Sure they are a pain in the ass on Linux - but for that you need to blame Linus for his infinite wisdom about no stable kernel APIs.

FreeBSD and Solaris do not suffer from any such problems.

Reply Parent Score: 4

RE[3]: OpenGL support
by butters on Fri 11th May 2007 22:07 in reply to "RE[2]: OpenGL support"
butters Member since:
2005-07-08

On all of these *nix systems, the majority of the driver support lives in userspace and interacts with the driver interface in the X server, which is under a non-copyleft, non-share-alike license. The part that involves the kernel is the direct rendering code, which interacts with the DRI framework. To get around the linking problem with the Linux kernel, this part of the nVidia driver lives in userspace and talks to a GPL shim layer that they load into the kernel. If the DRI changes, they only need to update their shim.

FreeBSD and Solaris face challenges because Linux DRI is advancing beyond their capabilities, mainly due to contributions from Intel. FreeBSD and especially Solaris are mostly locked into the frameworks they have. This is the double-edged sword of stable interfaces. As nVidia works to keep their shim in sync with Linux DRI, it becomes a hassle to continue to support these other kernels.

In his "infinite wisdom," Linus decided that eventually people's patience with--and trust in--proprietary drivers will run out, making stable in-kernel interfaces a non-issue. The Linux kernel development model works great for OSS drivers, and most hardware will eventually be supported by OSS drivers. Our suffering is temporary and for a good reason.

Reply Parent Score: 5

RE[4]: OpenGL support
by kaiwai on Fri 11th May 2007 23:10 in reply to "RE[3]: OpenGL support"
kaiwai Member since:
2005-07-06

FreeBSD and Solaris face challenges because Linux DRI is advancing beyond their capabilities, mainly due to contributions from Intel. FreeBSD and especially Solaris are mostly locked into the frameworks they have. This is the double-edged sword of stable interfaces. As nVidia works to keep their shim in sync with Linux DRI, it becomes a hassle to continue to support these other kernels.


Pardon - you do realise that DRI exists in both Solaris and FreeBSD; Solaris has the Intel driver merged, the DRI merged and Mesa is included with Solaris as well.

There is no double edge to a stable interface - what it does mean is this; when you design an interface, it'll take longer - rather than throwing ideas at a wall and see what sticks, it'll require going away, designing, arguing, debating, analysing then implementing - sure, it'll take longer, but what it means is that the API has been properly thought out before being merged - and better still modular enough so that new features can be added without breaking compatibility.

A prime example of this would be Solaris's new network driver API which covers all the facits of networking, and when features are added, such as WPA support, all wireless drivers support it by virtue of it being in the actual driver API rather than it being an after thought.

I don't want to bash Linux, but to me, it always seems that people just keep throwing ideas and see what sticks rather than sitting down and logically thinking out what the requirements of the API are and all the various issues that surround it.

Reply Parent Score: 5

RE[3]: OpenGL support
by codergeek42 on Fri 11th May 2007 22:13 in reply to "RE[2]: OpenGL support"
codergeek42 Member since:
2006-01-07

"Sure they are a pain in the ass on Linux - but for that you need to blame Linus for his infinite wisdom about no stable kernel APIs."

A stable in-kernel API does nothing but hinder further development in terms of new features and bugfixes. Please read Grek KH's response on this for more info, called "stable_kernel_nonsense.txt" in the kernel source's Documentation directory. (It's also available online at his site: http://www.kroah.com/log/linux/stable_api_nonsense.html )

(Sorry, I meant to vote you down but clicked the wrong button. Would someone do so for me please? ;) )

Reply Parent Score: 5

RE[4]: OpenGL support
by ormandj on Sat 12th May 2007 00:32 in reply to "RE[3]: OpenGL support"
ormandj Member since:
2005-10-09

(Sorry, I meant to vote you down but clicked the wrong button. Would someone do so for me please? ;) )


Last time I checked, you weren't supposed to mod people down just because you disagree with them. You'd be -5 if that were the case. No wonder so many posts get modded negatively even though they are not breaking the rules (off topic/personal insults.) Learn to moderate...

That said, a stable kernel API doesn't hinder development. Just because one person, obviously biased, says so - doesn't make it true. I'd say dtrace was light years ahead of anything linux has to offer. Same with ZFS. Same with zones. The list goes on.

A stable API just means the development model is different. More time planning, less time hacking together code that semi-works. There's a reason why drivers in linux tend to be flaky, especially ones that are newly introduced. Personally, I'll stick with stability. You can have all the bleeding edge functionality that doesn't/barely/halfway works, I'll happily wait for a stable solution that always/fully works instead.

Different models, different methods, both eventually get to the same point. One is a little more rapid at the expense of a lot of stability, one is a lot more stable at the expense of a little bit of rapidity.

Reply Parent Score: 4