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 239555
To view parent comment, click here.
To read all comments associated with this story, please click here.
PlatformAgnostic
Member since:
2006-01-02

What makes you think that OSS people have any idea what to do with a stream processor or how to write a graphics driver? The kinds of people who are really good at this stuff are few and far between. And I'm willing to bet that they want the big bucks.

The high end gaming graphics market that's out there grew up around a highly proprietary synergy between Microsoft and NVidia/ATI. OpenGL was not going anywhere in the 3D gaming market until after DirectX had been established. 3dfx was the exception, and it seems like they did a lot to get OGL working on hardware.

OSS seems to be a means for corporate success only when one is selling hardware. Otherwise, open-sourcing the software is just a tool for companies that are going out of business or simply can't compete to sell their software. The linux kernel is a big exception to this, but I'm not so sure it's doing a great job when it comes to things that require more centralized design and careful planning such as suspend/resume.

Reply Parent Score: 2

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

lemur2 Member since:
2007-02-17

{What makes you think that OSS people have any idea what to do with a stream processor or how to write a graphics driver?}

What makes you think they don't?

{The high end gaming graphics market that's out there grew up around a highly proprietary synergy between Microsoft and NVidia/ATI. OpenGL was not going anywhere in the 3D gaming market until after DirectX had been established. 3dfx was the exception, and it seems like they did a lot to get OGL working on hardware.}

History revisionism. DirectX is strictly second-rate compared with OpenGL, to the extent that Microsoft had to eventually buy some OpenGL patents from the death throes of SGI, and then make OpenGL run on top of DirectX in Vista to kill its performance in order to try to kill OpenGL.

Still OpenGL rules in high-end visual systems.

The high end of graphics in PCs is not PC games, it is more like this sort of gear:
http://www.es.com/

"I'm not so sure it's doing a great job when it comes to things that require more centralized design and careful planning such as suspend/resume."

Suspend resume problems are all due to failures of motherboard & BIOS to stick to the ACPI specification. Even Windows has problems, and most BIOSes are written with Windows in mind.

Suspend/resume works perfectly in Linux (say on Ubuntu Feisty) on any machine with a correct ACPI implementation.

Edited 2007-05-12 07:25

Reply Parent Score: 2