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 239574
To view parent comment, click here.
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

PlatformAgnostic Member since:
2006-01-02

I'm sorry, I think I was a excessively hateful toward OSS people with my last post. I had just come off a really annoying argument with a zealot which I just should have avoided after the first post.

The reason that I think an open NVidia or ATI graphics driver will be hard is because the interface between one of the fast chips and the software that runs them appears to be complicated, non-obvious, and messy. And this level of graphics hardware design does not seem to be something one learns in school. It's easy to imagine a large OSS developer community building up around a kernel, or a database, or a compiler, because these are all topics that every CS student learns and for which there are a lot of educational materials.

I've never done any 3D graphics myself, so perhaps this knowledge of how the chips work is out there and learnable too.

Reply Parent Score: 2

adamk Member since:
2005-07-08

The reason that I think an open NVidia or ATI graphics driver will be hard is because the interface between one of the fast chips and the software that runs them appears to be complicated, non-obvious, and messy.

And it's something that a number of OSS developers have been able to figure out for the r300/r400 ATI cards simply through reverse engineering (and that others are working on for nvidia cards through reverse engineering). Imagine how much more they'd be able to accomplish with specs or source code to already fully functional drivers.

Reply Parent Score: 3

sbergman27 Member since:
2005-07-24

"""
I'm sorry, I think I was a excessively hateful toward OSS people with my last post. I had just come off a really annoying argument with a zealot which I just should have avoided after the first post.
"""

I'm not aware of that exchange. But it sounds like a perfect example of how well meaning, but overenthusiastic people employing bad advocacy can do far more harm to their cause than good.

Try to remember that *most* of us try to respect others' points of view, exercise a reasonable amount of courtesy, and don't go out of our way to offend.

I'd rather agree to disagree than make an active enemy.

Edited 2007-05-12 20:48

Reply Parent Score: 2