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."
Permalink for comment 239574
To read all comments associated with this story, please click here.
butters
Member since:
2005-07-08

What makes you think that people don't take advanced computer graphics courses in school and then decide to do something else with their careers? There are community projects reverse engineering graphics cards and rewriting the drivers from scratch. That's much harder than exploring a fully-functional OSS graphics driver and finding room for improvement.

Some people just don't know how to think like a programmer. But for those who do, picking up new specialties just isn't as difficult as one might think. Programmers with different backgrounds can add a great deal of value to a team. Someone with a background in filesystems might have different insights than someone who has been doing graphics since high school.

One of the challenges facing any software vendor is figuring out what their customers want. Proprietary vendors have various strategies for doing this: Competitive analysis, focus groups, customer interviews, and beta programs. OSS vendors provide SVN repositories, nightly builds, download mirrors, bug trackers, mailing lists, IRC channels, forums, wikis, and blogs. Which method do you think best addresses the challenge of staying in touch with the needs of the userbase?

However, vendors that throw their code over the wall but fail to build a community and engage it in the development process will not realize the potential of the OSS model. Ask the OpenDarwin folks about what happens when OSS goes horribly wrong. Sun has positioned themselves as an OSS powerhouse, but while they have many millions of lines of OSS, their communities still in the incubator phase. They're gunna need a lot more eyes to cover that voluminous software library.

But back to graphics. OpenGL was 3D gaming up until the third or fourth release of DirectX. The first few versions of DirectX were somewhere between a joke and a good try. Most of the functionality to support OpenGL or DirectX is in the driver stack, and this is becoming more true over time. The hardware might be optimized for the kinds of instruction mixes that these programming models tend to produce. But most of the reason why nVidia tends to have an advantage over AMD/ATi in OpenGL is because their drivers do a better job of code generation for OpenGL. As I said before, most of the magic that makes those chips render 3D scenes--as opposed to solving some other kind of vector computation problem--is in the drivers.

The kind of "highly proprietary synergy" you refer to is the reason why we still use these chips predominantly as graphics accelerators as opposed to using them for accelerating any code that can be vectorized. If the hardware wasn't closed, we would have optimizing compilers that generate code for "graphics" chips wherever possible. But instead we rely on the graphics vendors to implement specialized routines in their drivers. nVidia can now offload some video codec operations if you use their driver interface. But if I want to do some slightly different block transform, I'm out of luck, because they didn't account for that.

As for things like suspend/resume, this is part of a class of systems programming problems where the basic approach is to have callback hooks for which various components can supply routines. When the system suspends, it runs through the list of registered callbacks, and the drivers (for example) are responsible for doing whatever magic they need to do in order to support suspend. An analogous process happens when we resume. This takes discipline, and it involves little pieces of code scattered across various parts of the source tree. But I'm not sure this is inherently more challenging for OSS than it is for proprietary vendors. For one thing, third-party proprietary kernel modules mean all bets are off. There's no way to tell if the module will properly suspend and resume, or if it might barf all over other parts of memory if we try.

I wouldn't worry about whether the OSS community has enough skills or the discipline to deliver high-quality software. We've got plenty of talent, probably more than any one of those big proprietary vendors. They've got managers to decide who's to blame when deadlines are missed, requirements are overlooked, or teams aren't on the same page. OSS developers rely on each other, and they pick up the ball if someone else drops it.

Software has more value in how it can be reassembled and extended to solve new problems than it has in and of itself. That's why OSS makes sense.

Edited 2007-05-12 06:01

Reply Parent Score: 5