Going with WMA is a risky move at the moment, given that Microsoft is being sued for infringement of DRM patents.
A press release discussing most recent additions to the suit can be found here. (This is an extension of a previous suit which covers Windows Media, Microsoft Reader, and many other MS products, which are mentioned in the last paragraph of the press release. Unfortunately, I can't find a description of the original suit at the moment.)
Think about some of the changes going on in the industry right now:
New PC standards are for systems that are much less open than we've enjoyed in the past. Partly this is due to increasing demands for content protection. Partly this is due to a desire to reduce support costs. There are other reasons as well, but the bottom line is that the open-architecture PC as we knew it may be going out of style.
The high-volume platforms for 3D these days are proprietary entertainment systems (games consoles, perhaps eventually set-tops, and their descendants with better integrated A/V functionality). At this stage in the development of the market, vendors have tremendous incentives to protect their intellectual property and try to lock-in as many customers as possible.
Hardware vendors are collapsing. Microsoft's business model, in which they control the functionality that vendors can provide, reduces the opportunity to differentiate products and drives hardware profit margin down. As a result, a few mistakes are enough to take a vendor out of the game. There's less risk-taking by the vendors who don't enjoy comfortable leads in the market, and much less incentive for a vendor to do anything that would put its relationship with Microsoft at risk.
Conglomerates are acquiring control over the entire entertainment development and delivery process. Companies like Sony and AOL/TW intend to own characters, plots, production houses, news/information organizations, delivery channels, and platforms. (Microsoft has already taken the first steps toward doing the same.)
One of the implications is that our old way of thinking about how graphics is delivered, supported, and used is becoming irrelevant (or at least relevant only to the smaller submarkets like engineering and sci vis). Is 3D graphics support for free systems meaningful when the market offers only proprietary systems?
Just a larger context in which to think about the subject...
As far as I know, none of us who were working on open-source 3D graphics at VA are still with the company. There was a trickle of departures (Jens Owen, Frank LaMonica, Gareth Hughes, et al.) over the past six months. The rest of us were laid off along with the Professional Services group of which we were a part.
There are a few projects underway, but at present no one knows whether those will be handled by contracts with individuals or whether some portion of the group will be hired by another company.
Rather than ask "what's happening with OpenGL," I'd ask "what's happening with the business of 3D graphics platforms?"
The big open question at the moment seems to be whether the general-purpose PC is dead as a gaming platform. The royalty-based revenue stream from consoles is more attractive to platform developers, the configuration consistency of consoles is more attractive to software developers and support organizations and publishers, the hardware and software support for intellectual property protection is better on consoles, and the higher volume of game sales on consoles is more attractive to nearly everyone in the supply chain. Then there are the "we want to own everything from the character concepts to the titles to the delivery platform" business strategies from folks like Sony.
It's possible that the PC will remain a delivery platform for traditional scientific/technical/business applications, but not for entertainment applications. In that case OpenGL would continue to play a role for the "professional" apps even though it might not play a role for the "consumer" apps (except possibly on MacOS X and Linux).
I'm also curious to see how D3D evolves if XBox succeeds. Does the PC become the leading-edge development platform, with console designs occasionally spinning off from the current 3D environment on the PC? Or does D3D on the PC stabilize, getting major revisions only when new console hardware justifies a fresh release?
There are many other things to consider. The next couple of years should be interesting.
You need someone better-informed than I am to confirm this, but in the 70s I was told that the character name "Bat Guano" in Dr. Strangelove refers to an urban legend of the 60s. The UL was that the caffeine added to Coca Cola was derived from bat guano. This is part of the humor behind the character's interaction with the Coke machine -- the line "If you're lying, you'll have to answer to the Coca Cola company" and the Coke machine spraying him after he shoots it.
So to my limited understanding, the name "Bat Guano" is not exactly a pun (as Wheat states); it's a pop-culture reference.
The ARB is an industry-based standards body, much like those that set standards for video equipment, mechanical engineering, chemical engineering, etc. The fact that the ARB isn't a government organization has nothing (as far as I can tell) to do with the observation that MS has a poor record for supporting open-standard APIs.
I note that none of the examples you mention involve APIs. Microsoft has a long history of ignoring, marginalizing, or using its monopoly to sabotage open standards for such things.
They have plans, among other things, to have banner ads when you press the pause button.
Interesting how things change. One of the primary reasons I bought Replay rather than TiVo over a year ago was that TiVo had announced that it would be using banner ads, while Replay had announced that it wouldn't.
The lesson I draw from this is that both companies have changed strategies in the past and are likely to change them again.
FWIW, I find that TiVo users who haven't tried the Skip button on Replay might not realize just how valuable it is.
I don't know the details of the participation agreement in the Rambus case. For example, it's possible that the original patentable designs and the infringing designs were created before Rambus joined the JEDEC working group, and the participation agreement didn't require Rambus to reveal its proprietary interest in that case.
But I agree with you, it's all pretty scary. That's why the participation agreements exist.
One, the vendors are doing a good job of putting the common functionality into multivendor extensions, so if you want to stick with just the universally-available features, then you don't need to use the vendor-specific extensions. On the other hand, if you want to use the latest hot-shot vendor-specific stuff, OpenGL extensions let you do that but D3D doesn't. This is going to get interesting in the near future, as the next-generation products from several vendors go head-to-head. (As Chris Hecker says: There are no more SGI machines to copy, so no one knows the right thing to do anymore.)
Two, with respect to register combiners, the NVIDIA representative to the ARB stated that the current way of doing this is dead-end technology and there will be new extensions proposed for handling pixel shading. D3D "standardized" too early and will have to throw out the previous-generation way of doing things. This is exactly the situation vendor-specific OpenGL extensions are intended to handle; making functionality available without misleading people as to the possibility that it will survive in the long term.
Life is complicated in the graphics business. As long as hardware keeps changing, there are going to be tradeoffs between availability and stability. Sometimes D3D is going to get lucky, and sometimes OpenGL is going to get lucky, but everyone needs to understand the situation more thoroughly than they do now.
I find your definition of "open" to be somewhat confused. The specs for OpenGL, including the extensions, are available to anyone; there's an open process for changing the standardized portions of them; anyone can extend the API without permission of a central authority; open-source implementations are available and anyone can distribute them on any OS. That's much more than "open in name only" and contrasts quite significantly with D3D (for example).
The September OpenGL Architecture Review Board (ARB) meeting was held on Tuesday and Wednesday, so I'll pass along a few observations.
Running an open standard in these days of hyperactive lawyers is a pain. One concern is that people adding new functionality to OpenGL (or even reviewing specifications for it) might sneak in some proprietary intellectual property. If this made it into the standard unchallenged, the owner could then reap a substantial windfall by suing anyone unlucky enough to implement it.
The way this problem is solved is to require anyone active in the ARB to sign an agreement stating that they'll simply disclose any proprietary interest they might have in features that are being considered for use in the API.
This is a good deal, in my opinion; you don't actually have to give up your rights to any intellectual property you might own, and you gain insurance that no one else will "submarine" a patented technology into the API. I encourage anyone who's interested in participating in the development of OpenGL to sign
the agreement. See the
ARB FAQ link on this subject for more information.
The flip-side is that if you haven't signed the agreement, you can't be included in the discussions, so there's no easy way to know what's actually going on. For example, you couldn't know much about the new features going into the API.:-)
As far as features go, everyone should understand that what really counts is what's supported by the hardware. OpenGL and D3D actually have similar ways of exposing these features. Microsoft puts things into the D3D API whether or not the hardware vendors can actually support them, and then adds capability bits and pipeline validation queries so that applications can determine at runtime whether the features will work. The ARB and individual vendors put extensions into OpenGL, and then add the names of the extensions to the extensions string so that applications can determine at runtime whether the features will work.
You get the idea -- the bottom line is really pretty similar for the two APIs. Just because a feature is "in" D3D doesn't mean it actually works; just like in OpenGL, you need to test to see what works and be prepared to adapt your code to run on a particular chip or card.
This isn't a bad thing, in my opinion. As long as the hardware vendors are developing new features, there'll be differences between them that app developers have to live with. But the competition exposes new ideas and the market will eventually encourage the ones that are useful.
Just for the record, things discussed at this ARB meeting included programmable vertex processing, rendering to textures, encapsulating vertex data in objects that can be processed faster by T&L hardware, advanced pixel processing, and new memory management schemes for textures and other objects. You'll probably see this stuff being usable in OpenGL about the time hardware actually supports it, just like D3D.
Oh, yeah, Fahrenheit. Long story there. Bottom line as I understand it: As far as Microsoft is concerned, D3D8 or 9 essentially is the Fahrenheit Low-Level API. SGI isn't participating in that effort any longer. The Fahrenheit Scene-Graph API exists, and you can actually buy it from Microsoft, but there's no support for it, so its future is uncertain.
Allen
Re:We Have X Because Sun Wanted to Keep Da Goodies
on
X Windows Must Die!
·
· Score: 3
While some of the political issues you mentioned were factors in the community's decision to go with X, there were technical issues as well. It's been so long that I don't remember all of them, but some that come to mind are
NeWS didn't support pseudocolor, which was important to some of the key applications of the time.
NeWS used a non-preemptive threading model; it was trivial for rogue code or buggy code to lock the server.
Debugging PostScript code running in the server was horrendously difficult.
The PostScript language interpreted by the NeWS server differed from Adobe's PostScript, which not only caused portability problems, it pissed off Adobe. The Display PostScript extension for X was created as a result.
There were plenty of great features in NeWS, and some of them are enjoying a comeback today. But it's worth remembering that NeWS wasn't a clear-cut technical win. X carried the day for a variety of reasons.
Uh, OpenGL has supported hardware T&L since 1992. You'd have to check with Intense3D to be sure, but I believe Intergraph was shipping hardware T&L OpenGL systems running Windows NT by 1994. D3D is years behind on this one.
One of the reasons it's taken so long to get hardware T&L in the consumer market is that D3D didn't support it until very recently, and Microsoft shut off OpenGL support in the Win9X line as quickly and completely as it could afford. You can say similar things about stencilling, full-scene antialiasing, curve/surface support, and probably a dozen other cases in which it's taken a while for D3D to catch up to OpenGL. Even multitexturing shipped as an OpenGL extension (from 3Dfx) before it shipped in D3D.
Keep an eye on the hardware for the next year or so; I think you'll be surprised at how many of the new DX8 features aren't supported at all, or aren't supported in a consistent way across vendors.
With respect to texture management, there's always been a great deal of misunderstanding about the differences between OpenGL's memory usage and D3D's. The fundamental problem is that kernels in the Win9X line can destroy the contents of texture memory without warning the driver first, so there's no way for the driver to save the textures to main memory. D3D deals with this by simply notifying applications that the data has been lost; OpenGL drivers on Windows deal with it by keeping a main-memory copy so that the data can be reloaded transparently. (Note that this is a characteristic of the OS, though, not the APIs; OpenGL on Linux doesn't have to keep a separate copy of textures, because the kernel doesn't misbehave.)
The problem with the D3D approach is that the app doesn't necessarily have a copy of the texture to reload, particularly if the texture was created dynamically (like a Perlin noise texture or an environment map created by rendering in the framebuffer). So it's a burden for the app developer to deal with the situation.
Obviously the best solution is to fix the bogus behavior in Windows, but Microsoft has no interest in doing that. The fallback is probably to add a Windows-specific extension to OpenGL to allow textures to evaporate when necessary. Tim suggested this at one time, but as far as I know never managed to convince any IHV to support it. It would be interesting to know why.
In the meantime, we can at least be amused that Microsoft now supports OpenGL-style driver-managed textures in D3D, and recommends that people use them. Like so many other features in D3D that started out different from OpenGL, and then eventually were changed to be like OpenGL. (Anyone noticed that DX8 vertex shaders require a vertex data representation that looks like OpenGL vertex arrays rather than the vertex structures in DX7?):-)
You have valid concerns, and I don't want make light of all of them. But I did want to inject a dose of realism about a few things:
D3D is far from consistent. Different implementations have different capabilities, and that definitely includes the new vertex and pixel shader stuff in DX8. Developers will have the same trouble getting those new features to work in D3D that they'll have dealing with OpenGL extensions, if not more.
There are a lot of people working to keep OpenGL competitive. For example, a VP at NVIDIA recently told me "Every hardware feature will be exposed in OpenGL extensions." The first step is always to expose new functionality in extensions; it gets incorporated in the core standard only after it's shown to be useful and generally practical to implement. (This is unlike D3D, where Microsoft decides which vendors to favor and shafts others by adding D3D features that they won't necessarily be able to support.)
Always view new stuff in D3D with a healthy dose of skepticism. Microsoft has had to reverse its design decisions in D3D many times in the past, and now that they can no longer copy features wholesale from OpenGL, they're even less likely to get things right than before. There are highly knowledgable people in the games industry who have major doubts about the new features in DX8.
Bottom line, I think you're correct that more needs to be done to support graphics and games in the open-source world. But I also believe that the game is far from over.
I've had my Replay box for four months. I find it somewhat easier to control (more predictable recording and storage-management behavior) than a friend's TiVo.
Initially I chose Replay because TiVo had plans to use advertising to subsidize schedule subscriptions, and Replay didn't. However, from what I can see, both companies are still fine-tuning their strategies.
I've had one problem, which turned out to be at Replay's end -- there was a period of a few days when my Replay couldn't make the phone connection to download the schedule information. During that time Replay's Customer Service was extremely helpful, even giving me the maintenance codes to look at diagnostic output from Linux.
WRT recording problems, the only glitch I'm dealing with at the moment is that Replay allows a little slop in program start/end times, so that it catches shows that slip due to scheduling problems (like sports events). However, this means that you can catch two episodes of a show if they run at back-to-back times -- for example, in my area, new episodes of Voyager run at 21:00, but my Replay box will also catch the rerun that starts at 22:00.
All in all, I'm happier with my Replay than my friend is with his TiVo.
There are significant gains to be had from runtime code generation. In my opinion, one of the best papers ever written on this subject is Henry Massalin's dissertation on his "Synthesis" OS.
Synthesis takes performance to a level that's impossible to match with code written statically, by using things like address information that's known only at execution time, as well as knowledge of how multiple reusable components are dynamically connected.
I also recommend Christensen's book; Linux has many of the characteristics of the disruptive technologies he discusses, and his insights certainly have prompted me to look at the industry in a new light. However, I don't believe the Innovator's Dilemma was the primary problem that led to SGI's failure. Christensen does a good job of characterizing the ``flight upmarket'' that established firms do in the face of disruptive innovations. Although SGI maintained a strong presence in the high end (the high-end graphics group was still showing significant profit, last I heard), for years it was pushing actively downmarket into the ``disruptive'' areas -- with NT-based systems, and more importantly, with projects like Nintendo 64. I suspect the fundamental problem with SGI was not that it failed to handle disruptive innovation, but that it failed to remain competitive within its core markets. Sun, in particular, avoided this problem. Arguably so did HP. But SGI was late with new machines in its traditional strongholds of CAD and content-creation, and when the new machines shipped they were underwhelming in terms of price or price/performance. Like most SGI veterans, I have opinions as to why this happened despite the fact that everyone from senior management to the lab technicians saw the market shifts occurring. But I'll skip that for the moment. The Innovator's Dilemma is an excellent work, and well worth reading, especially in the context of Linux. But be careful when applying it to any particular corporate failure; it's not the only reason technology companies stumble! Allen
From a philosophical standpoint, I think graphics acceleration should be handled with an abstraction layer / API that sits right on top the hardware and then the windowing system sits on top of that.
Just a general note about something that's not well-understood outside the OpenGL community: OpenGL is a hardware abstraction API that's designed to be the lowest-level interface to graphics hardware. It might seem large compared to common 2D APIs, but in fact it barely covers the hardware functionality available on PC graphics cards that will be shipping by the end of this year. (In fact, in a number of cases it has already been necessary to extend the API to cover special features in existing hardware.)
The DRI is intended to give OpenGL direct access to hardware that also supports X, without the overhead of another driver interface layer. If one were to attempt to create such a layer, it would necessarily be about as large and complex as OpenGL, and that's not a win with respect to software development effort or performance.
Of course it is possible to use OpenGL without X. In such a case you might not need a DRI, because OpenGL might be the native graphics interface. That's beyond the scope of current projects, but might be quite reasonable for a future project (putting Linux and OpenGL onto a console-class machine, for example).
In the meantime, Precision Insight's DRI is intended to solve the specific problem of providing high-performance OpenGL without compromising compatibility with X. The end result should be excellent -- not only will it be possible to play OpenGL-based games like Q3A, but it will be practical to use OpenGL to accelerate graphics operations that have no support in X today. (Consider using OpenGL hardware-accelerated alpha blending, stencilling, and texturing in Enlightenment.)
Allen (Former OpenGL guy at SGI, now project advisor at Precision Insight)
Analog magazine had an article a few months ago describing how to duplicate Farnsworth's fusion system with roughly high-school level physics lab equipment. Recommended. Wear your lead BVDs.
Slashdot Mirror
A press release discussing most recent additions to the suit can be found here. (This is an extension of a previous suit which covers Windows Media, Microsoft Reader, and many other MS products, which are mentioned in the last paragraph of the press release. Unfortunately, I can't find a description of the original suit at the moment.)
One of the implications is that our old way of thinking about how graphics is delivered, supported, and used is becoming irrelevant (or at least relevant only to the smaller submarkets like engineering and sci vis). Is 3D graphics support for free systems meaningful when the market offers only proprietary systems?
Just a larger context in which to think about the subject...
There are a few projects underway, but at present no one knows whether those will be handled by contracts with individuals or whether some portion of the group will be hired by another company.
The big open question at the moment seems to be whether the general-purpose PC is dead as a gaming platform. The royalty-based revenue stream from consoles is more attractive to platform developers, the configuration consistency of consoles is more attractive to software developers and support organizations and publishers, the hardware and software support for intellectual property protection is better on consoles, and the higher volume of game sales on consoles is more attractive to nearly everyone in the supply chain. Then there are the "we want to own everything from the character concepts to the titles to the delivery platform" business strategies from folks like Sony.
It's possible that the PC will remain a delivery platform for traditional scientific/technical/business applications, but not for entertainment applications. In that case OpenGL would continue to play a role for the "professional" apps even though it might not play a role for the "consumer" apps (except possibly on MacOS X and Linux).
I'm also curious to see how D3D evolves if XBox succeeds. Does the PC become the leading-edge development platform, with console designs occasionally spinning off from the current 3D environment on the PC? Or does D3D on the PC stabilize, getting major revisions only when new console hardware justifies a fresh release?
There are many other things to consider. The next couple of years should be interesting.
How long has it been since you've seen "Harold and Maude?" Check out the scene in which Harold is given advice by the family clergyman...
You need someone better-informed than I am to confirm this, but in the 70s I was told that the character name "Bat Guano" in Dr. Strangelove refers to an urban legend of the 60s. The UL was that the caffeine added to Coca Cola was derived from bat guano. This is part of the humor behind the character's interaction with the Coke machine -- the line "If you're lying, you'll have to answer to the Coca Cola company" and the Coke machine spraying him after he shoots it.
So to my limited understanding, the name "Bat Guano" is not exactly a pun (as Wheat states); it's a pop-culture reference.
I wonder how many of Microsoft's current and potential DRM partners are aware this is underway?
The ARB is an industry-based standards body, much like those that set standards for video equipment, mechanical engineering, chemical engineering, etc. The fact that the ARB isn't a government organization has nothing (as far as I can tell) to do with the observation that MS has a poor record for supporting open-standard APIs.
For an example, you can review the OpenGL vs. Direct3D history.
Interesting how things change. One of the primary reasons I bought Replay rather than TiVo over a year ago was that TiVo had announced that it would be using banner ads, while Replay had announced that it wouldn't.
The lesson I draw from this is that both companies have changed strategies in the past and are likely to change them again.
FWIW, I find that TiVo users who haven't tried the Skip button on Replay might not realize just how valuable it is.
Allen
I don't know the details of the participation agreement in the Rambus case. For example, it's possible that the original patentable designs and the infringing designs were created before Rambus joined the JEDEC working group, and the participation agreement didn't require Rambus to reveal its proprietary interest in that case.
But I agree with you, it's all pretty scary. That's why the participation agreements exist.
One, the vendors are doing a good job of putting the common functionality into multivendor extensions, so if you want to stick with just the universally-available features, then you don't need to use the vendor-specific extensions. On the other hand, if you want to use the latest hot-shot vendor-specific stuff, OpenGL extensions let you do that but D3D doesn't. This is going to get interesting in the near future, as the next-generation products from several vendors go head-to-head. (As Chris Hecker says: There are no more SGI machines to copy, so no one knows the right thing to do anymore.)
Two, with respect to register combiners, the NVIDIA representative to the ARB stated that the current way of doing this is dead-end technology and there will be new extensions proposed for handling pixel shading. D3D "standardized" too early and will have to throw out the previous-generation way of doing things. This is exactly the situation vendor-specific OpenGL extensions are intended to handle; making functionality available without misleading people as to the possibility that it will survive in the long term.
Life is complicated in the graphics business. As long as hardware keeps changing, there are going to be tradeoffs between availability and stability. Sometimes D3D is going to get lucky, and sometimes OpenGL is going to get lucky, but everyone needs to understand the situation more thoroughly than they do now.
I find your definition of "open" to be somewhat confused. The specs for OpenGL, including the extensions, are available to anyone; there's an open process for changing the standardized portions of them; anyone can extend the API without permission of a central authority; open-source implementations are available and anyone can distribute them on any OS. That's much more than "open in name only" and contrasts quite significantly with D3D (for example).
Allen
The September OpenGL Architecture Review Board (ARB) meeting was held on Tuesday and Wednesday, so I'll pass along a few observations.
The way this problem is solved is to require anyone active in the ARB to sign an agreement stating that they'll simply disclose any proprietary interest they might have in features that are being considered for use in the API.
This is a good deal, in my opinion; you don't actually have to give up your rights to any intellectual property you might own, and you gain insurance that no one else will "submarine" a patented technology into the API. I encourage anyone who's interested in participating in the development of OpenGL to sign the agreement. See the ARB FAQ link on this subject for more information.
The flip-side is that if you haven't signed the agreement, you can't be included in the discussions, so there's no easy way to know what's actually going on. For example, you couldn't know much about the new features going into the API. :-)
You get the idea -- the bottom line is really pretty similar for the two APIs. Just because a feature is "in" D3D doesn't mean it actually works; just like in OpenGL, you need to test to see what works and be prepared to adapt your code to run on a particular chip or card.
This isn't a bad thing, in my opinion. As long as the hardware vendors are developing new features, there'll be differences between them that app developers have to live with. But the competition exposes new ideas and the market will eventually encourage the ones that are useful.
Oh, yeah, Fahrenheit. Long story there. Bottom line as I understand it: As far as Microsoft is concerned, D3D8 or 9 essentially is the Fahrenheit Low-Level API. SGI isn't participating in that effort any longer. The Fahrenheit Scene-Graph API exists, and you can actually buy it from Microsoft, but there's no support for it, so its future is uncertain.
Allen
While some of the political issues you mentioned were factors in the community's decision to go with X, there were technical issues as well. It's been so long that I don't remember all of them, but some that come to mind are
There were plenty of great features in NeWS, and some of them are enjoying a comeback today. But it's worth remembering that NeWS wasn't a clear-cut technical win. X carried the day for a variety of reasons.
Uh, OpenGL has supported hardware T&L since 1992. You'd have to check with Intense3D to be sure, but I believe Intergraph was shipping hardware T&L OpenGL systems running Windows NT by 1994. D3D is years behind on this one.
One of the reasons it's taken so long to get hardware T&L in the consumer market is that D3D didn't support it until very recently, and Microsoft shut off OpenGL support in the Win9X line as quickly and completely as it could afford. You can say similar things about stencilling, full-scene antialiasing, curve/surface support, and probably a dozen other cases in which it's taken a while for D3D to catch up to OpenGL. Even multitexturing shipped as an OpenGL extension (from 3Dfx) before it shipped in D3D.
Also, check the OpenGL Architecture Review Board meeting minutes. The number of OpenGL extensions that are being cranked out per quarter has gone up, not down, in the past year.
Keep an eye on the hardware for the next year or so; I think you'll be surprised at how many of the new DX8 features aren't supported at all, or aren't supported in a consistent way across vendors.
With respect to texture management, there's always been a great deal of misunderstanding about the differences between OpenGL's memory usage and D3D's. The fundamental problem is that kernels in the Win9X line can destroy the contents of texture memory without warning the driver first, so there's no way for the driver to save the textures to main memory. D3D deals with this by simply notifying applications that the data has been lost; OpenGL drivers on Windows deal with it by keeping a main-memory copy so that the data can be reloaded transparently. (Note that this is a characteristic of the OS, though, not the APIs; OpenGL on Linux doesn't have to keep a separate copy of textures, because the kernel doesn't misbehave.)
The problem with the D3D approach is that the app doesn't necessarily have a copy of the texture to reload, particularly if the texture was created dynamically (like a Perlin noise texture or an environment map created by rendering in the framebuffer). So it's a burden for the app developer to deal with the situation.
Obviously the best solution is to fix the bogus behavior in Windows, but Microsoft has no interest in doing that. The fallback is probably to add a Windows-specific extension to OpenGL to allow textures to evaporate when necessary. Tim suggested this at one time, but as far as I know never managed to convince any IHV to support it. It would be interesting to know why.
In the meantime, we can at least be amused that Microsoft now supports OpenGL-style driver-managed textures in D3D, and recommends that people use them. Like so many other features in D3D that started out different from OpenGL, and then eventually were changed to be like OpenGL. (Anyone noticed that DX8 vertex shaders require a vertex data representation that looks like OpenGL vertex arrays rather than the vertex structures in DX7?) :-)
You have valid concerns, and I don't want make light of all of them. But I did want to inject a dose of realism about a few things:
Bottom line, I think you're correct that more needs to be done to support graphics and games in the open-source world. But I also believe that the game is far from over.
With regard to testing, please see the project I've been working on recently, glean. I can certainly use more contributions.
I've had my Replay box for four months. I find it somewhat easier to control (more predictable recording and storage-management behavior) than a friend's TiVo.
Initially I chose Replay because TiVo had plans to use advertising to subsidize schedule subscriptions, and Replay didn't. However, from what I can see, both companies are still fine-tuning their strategies.
I've had one problem, which turned out to be at Replay's end -- there was a period of a few days when my Replay couldn't make the phone connection to download the schedule information. During that time Replay's Customer Service was extremely helpful, even giving me the maintenance codes to look at diagnostic output from Linux.
WRT recording problems, the only glitch I'm dealing with at the moment is that Replay allows a little slop in program start/end times, so that it catches shows that slip due to scheduling problems (like sports events). However, this means that you can catch two episodes of a show if they run at back-to-back times -- for example, in my area, new episodes of Voyager run at 21:00, but my Replay box will also catch the rerun that starts at 22:00.
All in all, I'm happier with my Replay than my friend is with his TiVo.
Allen
Synthesis takes performance to a level that's impossible to match with code written statically, by using things like address information that's known only at execution time, as well as knowledge of how multiple reusable components are dynamically connected.
Check it out (gzipped PostScript file): Synthesis: An Efficient Implementation of Fundamental Operating System Services.
I also recommend Christensen's book; Linux has many of the characteristics of the disruptive technologies he discusses, and his insights certainly have prompted me to look at the industry in a new light. However, I don't believe the Innovator's Dilemma was the primary problem that led to SGI's failure. Christensen does a good job of characterizing the ``flight upmarket'' that established firms do in the face of disruptive innovations. Although SGI maintained a strong presence in the high end (the high-end graphics group was still showing significant profit, last I heard), for years it was pushing actively downmarket into the ``disruptive'' areas -- with NT-based systems, and more importantly, with projects like Nintendo 64. I suspect the fundamental problem with SGI was not that it failed to handle disruptive innovation, but that it failed to remain competitive within its core markets. Sun, in particular, avoided this problem. Arguably so did HP. But SGI was late with new machines in its traditional strongholds of CAD and content-creation, and when the new machines shipped they were underwhelming in terms of price or price/performance. Like most SGI veterans, I have opinions as to why this happened despite the fact that everyone from senior management to the lab technicians saw the market shifts occurring. But I'll skip that for the moment. The Innovator's Dilemma is an excellent work, and well worth reading, especially in the context of Linux. But be careful when applying it to any particular corporate failure; it's not the only reason technology companies stumble! Allen
Just a general note about something that's not well-understood outside the OpenGL community: OpenGL is a hardware abstraction API that's designed to be the lowest-level interface to graphics hardware. It might seem large compared to common 2D APIs, but in fact it barely covers the hardware functionality available on PC graphics cards that will be shipping by the end of this year. (In fact, in a number of cases it has already been necessary to extend the API to cover special features in existing hardware.)
The DRI is intended to give OpenGL direct access to hardware that also supports X, without the overhead of another driver interface layer. If one were to attempt to create such a layer, it would necessarily be about as large and complex as OpenGL, and that's not a win with respect to software development effort or performance.
Of course it is possible to use OpenGL without X. In such a case you might not need a DRI, because OpenGL might be the native graphics interface. That's beyond the scope of current projects, but might be quite reasonable for a future project (putting Linux and OpenGL onto a console-class machine, for example).
In the meantime, Precision Insight's DRI is intended to solve the specific problem of providing high-performance OpenGL without compromising compatibility with X. The end result should be excellent -- not only will it be possible to play OpenGL-based games like Q3A, but it will be practical to use OpenGL to accelerate graphics operations that have no support in X today. (Consider using OpenGL hardware-accelerated alpha blending, stencilling, and texturing in Enlightenment.)
Allen
(Former OpenGL guy at SGI, now project advisor at Precision Insight)
Analog magazine had an article a few months ago
describing how to duplicate Farnsworth's fusion
system with roughly high-school level physics lab
equipment. Recommended. Wear your lead BVDs.