Slashdot Mirror
OpenGL 3.0 Released, Developers Furious
ikol writes "After over a year of delays, the OpenGL ARB (part of the Khronos industry group) today released the long-awaited spec for OpenGL 3.0 as part of the SIGGRAPH 2008 proceedings. Unfortunately it turns out not to be the major rewrite that was promised to developers. The developer community is generally furious, with many game developers intending to jump ship to DX10. Is this the end of cross-platform 3d on the cutting edge?"
Everyone knows x.0 releases are Beta anyway.
/ducks
OpenGL 3.1 will rock
Is this the end of cross-platform 3d on the cutting edge?"
Probably not. As long as DX remains solely in the hands of MicroSoft; there will be use for other forms of cross-platform 3D. More so as the "none-MS" OSes continue to grow in numbers.
The Long Now Foundation
Jumping ship to DX10 would be nice, if it were cross-platform. (No, Xbox + PC does not count as "cross-platform".)
Unfortunately for those of us on Linux/Mac, a lot of Windows developers don't care.
Unfortunately for those of you who think you don't care about this, consider that porting an app generally improves it, and can shake out bugs which aren't as apparent on the other platform -- which means potentially less reliable games, even if you're only on Windows.
And unfortunately for those of us who hate Vista, that's kind of a requirement for DirectX 10. At least with OpenGL, those in charge have no agenda to push Vista -- so an OpenGL 3.0 game should run on XP, if it runs on anything.
Don't thank God, thank a doctor!
jump ship to DX10
And when they do they wander into Direct/Input/Sound/Video/Play/etc. OpenGL does 3D rendering. The rest? Cobble it together from whatever other obsolete scraps are available.
The non-Microsoft "stacks" suck. Bottom line.
The concept of a 2D "layer" still hasn't impinged on the basic SDL API. Couldn't believe it when I learned that.
I guess professional game developers don't care that Microsoft owns the machinery of their livelihoods. They sure aren't contributing to their own independence in any noticeable way.
Heh - Games developers may have that luxury, but 3D/GC vendors certainly don't. So unless someone decides to port DX10 to OSX (*snort*) or Linux (sing it with me now: "render farms!"), OpenGL will continue to have a decently-sized userbase for a very long time.
IMHO, anyone making the claim that they're going to suddenly jump to DX10 is only making noise; nobody is dumb enough to cut off the fastest-growing consumer market sectors.
(...besides, doesn't the PS3 use OGL, or do they use some other home-brewed library set? Not sure there...)
Quo usque tandem abutere, Nimbus, patientia nostra?
What do you means DirectX10 isn't cross platform? It runs in all six versions of Windows Vista!
Not much unlike the one XFree86 fell down.
It needs to be forked. We need a fork of the 3D library, much like Xorg was forked.
The fork/rewrite should be more like DX10 than like OpenGL.
The library needs to be able to interoperate with current and future video hardware, so that all hardware acceleration features will be available to applications using the 3D library...
That means providing an underlying interface compatible with both the OpenGL and DX10 ABIs and conventional hardware drivers.
OpenGL isn't from the open source community, actually. It's "open" is the old "open systems" open, which is rather less open.
While people might say linux uses opengl, a lot of the time it's using mesa, which implements the opengl specifications but is NOT a certified opengl implementation.
(This revised 3.0 might be good news for mesa, as the originally threatened backward-incompatible 3.0, that, perhaps contrary to this slashdot "story" most opengl folk decided they didn't like, looks like it might be implementable without certain patent issues biting).
Part of the reason for DX's success is that nobody else seems interested in developing anything to compete with it. OpenGL is the only cross platform 3D API I'm aware of and it and DX are all that there is these days. GLs problem is that it isn't keeping up with the hardware. The "just use vendor specific extensions" isn't a realistic solution in most cases. Thus GL is suffering and DX is winning by default.
If someone like Apple did develop a good 3D API, it might do well. However nobody seems interested.
Is this the end of cross-platform 3d on the cutting edge?
it isnt. because OpenGL ARB is gonna play it nice, and revise their specs, therefore pleasing developers and therefore GAMERS as much as they can, and fix the matter, wont you now ? dont make us wait.
Read radical news here
Thing is it's not even close to being easy to use anymore. Especially not if you're interested in performance.
Because of the two decades of crud that has accumulated, there are so many ways of falling off the fast path in OGL, and it's next to impossible to know beforehand what will and will not work. Drivers are also a bitch to develop and maintain because of the size of the thing, which makes things even worse since what works on Nvidia may not work on ATI and vice versa.
The only way to fix this is a good cleanup to bring it in line with modern hardware. What they did was add even more crud.
I never had the impression OpenGL was trying to be a games platform. I think there are two distinct 3D libraries needed. One for actuate rendering, where its ok to take several minutes (or days) to render an image, and then the games platforms. I would rather see OpenGL be mathematically correct and be a great rendering engine. Not a games engine. Then if we need a competitor to DirectX on Linux/Mac, maybe we could persuade Sony or Nintendo to open source their games engines. After all the PS3 and Wii are the main competitors to DirectX. Not sure what the chances are, but maybe open sourcing their environment would put more interest back into PS3 development (which really seems to be lacking).
.
Vista is approaching 20% of the market. Top Operating System Share Trend You can't expect expect Linux ports if entry level DX9l/DX10 outperforms OGL.
...and probably irrelevant in the longer term.
This is not the first time this has happened. GL2 was also supposed to be a cleanup, but turned out to be anything but. This latest fiasco is more significant as a failure of governance than of technology. All the right ideas were there; they were published in some detail over a year ago in the Pipeline newsletters. But the ARB very obviously a) can't agree to get anything meaningful done, and b) now has subzero credibility with developers. It's not coming back from that.
So yes, I think cutting-edge cross-platform 3D is dead for the next 2-3 years. Let's face it, it was never exactly healthy. It's not the end of the world. Linux share is currently growing mostly at the low end, netbooks etc, while the Mac seems to be thriving despite the fact that Apple doesn't give a flying fsck about gaming and never has.
Fast forward a couple of years, though, and things like Larrabee will be hitting the market; embarrassingly parallel hardware that can be programmed with standard languages and tools. The API's role as gatekeeper of functionality will be gone. And suddenly, 3D rendering libs can be written by anyone with the time and expertise, without having to go through Microsoft or the ARB or NV or AMD/ATi or Intel or anyone. Experimentation, competition, cross-fertilization, evolution. Remember Outcast's voxel engine? Seen things like Anti-Grain? This will happen.
(Or, yes, people could just reimplement the DXwhatever API directly, but that would be a little disappointing.)
Today was not a good day, by any stretch of the imagination. But it's not the end.
DirectX 11.0 will be released on nVision 2008, 25-27 augusti.
The OpenGL consortium had to release opengl now to be take the egde. Too bad it had to be "finished" in a hurry.
ATI supports openGL, Intel added full support as well when they implemented DX10 (only one chipset has these so far iirc though).
The apparent failure of OpenGL to provide a significant rival to DX10 sucks though, especially since the DX10 on Vista only might have provided game makers an incentive to jump ship in order to get bleeding edge graphics onto XP systems.
Liberte, Egalite, Fraternite (TM)
That's an old perpetuated myth, that the value of D3D has anything to do with the satelite APis.
Let's confront it with facts:
- Direct3D is the absolutely dominant component of DirectX, in terms of received and deserved attention by users. As well as R&D effort by MSFT. It's the advancement of D3D that drives MSFT to release every next version of DirectX.
- Each component of DX is a completely indepependent API, sharing only design convention. OpenGL games on Windows use DirectInput for input, perfectly ignoring Direct3D.
- funnily, the satelite APIs are actually being phased out by MSFT. DirectPlay was always thoroughly ignored by the industry. For DirectSound and DirectInput there are replacement already. Not to mention the fate of hardware acceleration of DirectSound in Vista.
D3D and DX are de facto interchangable terms. Get over it.
Not handling sound/input by OpenGL is absolutely irrelevant in discussion about it's applicablity.
Professional apps (CAD/simulators/visualizations...) make up the majority of the OpenGL market and they have to be supported for decades (no, military or airlines do not buy a new training system every two years ...)
So breaking compatibility is deal breaker. This is exactly what OpenGL 3.0 is about. I am developing OpenGL applications for a decade now and all are still running and being used. How many 10 year old games can you actually get working today? God forbid - on Vista? That is the difference.
Also, the "newest features not supported by OpenGL" - how many "newest features" are your typical games actually using? Perhaps one or two and they are optional, because the game must run even on not bleeding-edge hardware (how many games are DX10-only? - commercial suicide ...)
So to wrap this up - the title is EXTREMELY misleading and making up a storm where one doesn't exist.
That would have been back in the mid to late 1990's. The Indy's (those flattish sparkly blue workstations) were the first to have a software implementation of OpenGL.
OpenGL was designed primarily so that third party graphics card manufacturers could write device drivers compatibile with the CAD and scientific-visualisation markets. The developers didn't really care much about 3D sound, real-time physics engines or AI. All they needed was a GUI and one or more hardware accelerated 3D graphics contexts for applications to run. The most complicated lighting models at the time were smooth shaded textures geometry using point light sources.
Now, modern game engines will be using multiple vertex and fragment shaders for things like relief mapping, occlusion mapping, reflection, refraction, BRDF, BTF, spherical harmonics, environment mapping, ambient shadow-mapping, real-time radiance, particle systems animated using textures and feed-back loops. Current research is attempting to include Computation Fluid Dynamics for animating dust around racing cars (EA), the use of Partial Differential Equations to synthesize the spots, stripes and spirals for virtual creatures (Spore), and that's just the visual part of the game. Then there is 3D surround sound, the physics (collision detection between animated characters, their environment, and everything else), along with multi-player network support (sockets).
To make a PC game that sells, it is going to have the visual appeal that takes the graphics hardware to its full potential. This means having people experienced in all of these fields or having the budget to afford middleware. Only large companies can really do this now.
Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
DX11 brings "compute shaders" to the table, which is a Good Thing - forcing a standard for GPU computation, allowing say hardware accelerated physics libraries to run on GPUs from multiple vendors.
Windows 7 is the usual product development cycle, and it was in the pipeline before Vista was even beta.
3laws: No freebies, no backsies, GTFO.
MPC: So, you said Rage is a 60Hz game. Is it an OpenGL or DirectX game?
JC: Itâ(TM)s still OpenGL, although we obviously use a D3D-ish API [on the Xbox 360], and CG on the PS3. Itâ(TM)s interesting how little of the technology cares what API youâ(TM)re using and what generation of the technology youâ(TM)re on. Youâ(TM)ve got a small handful of files that care about what API theyâ(TM)re on, and millions of lines of code that are agnostic to the platform that theyâ(TM)re on.
MPC: Are you using DirectX 9 equivalent? For Doom 4 as well?
JC: Yes to both. Itâ(TM)s one of those things I get asked a lot. Whatâ(TM)s big and exciting for DirectX 10 or DirectX 11? Thereâ(TM)s not a whole lot of⦠really not a whole lot. The big touted geometry shaders were in many ways, a mistaken belief that people desperately wanted to create stencil shadow volume.
So less than a month ago John said that he's still developing with OpenGL and that DX10 isn't really a worthwhile improvement.
And congratulations on referring me to something he said ages ago, when you find something more recent feel free to reply
Oh and source of interview: http://www.maximumpc.com/article/features/e3_2008_the_john_carmack_interview_rage_id_tech_6_doom_4_details_and_more?page=0%2C0
but to 90% of the market it's irrelevant since they don't run Vista and therefore don't have DX10, OpenGL is competing with DX9, not 10, and winning.
<sarcasm>Yes, because game developers look to the now and not the future.
When FPS Games take multiple years to develop, its a well known fact game designers program it with current generation graphics in mind. They never plan ahead 1-3 years so that at release they have a game that will push grahpics to the limit</sarcasm>
Honestly, the biggest supporters of OpenGL i can think of have been ID Software and Epic MegaGames, and i expect even Carmack would be getting tired of working around a primitive framework with minimal support for modern and future graphical features.
To avoid criticism; Say nothing, Do nothing, Be nothing.
If you want to make a game that runs on Xbox, you will be using an advanced version of DirectX 9. Most companies would probably stick to normal DirectX 9 so that they could just be recompiled for Windows XP and Vista. Especially since most gamers are still running XP. Gaming rigs are one of the exceptions to the major computer companies being able to still sell XP.
As for where do I get the information for DX10 not running on the Xbox, read below.
1up reports that ATI has debunked a rumor that Xbox 360 could be upgraded to support DirectX 10 via a patch. "Xbox360 cannot run DX10," an ATI spokesperson told 1up. Currently, Microsoft's console runs an advanced version of DirectX 9, which, according to ATI, features "memory export that can enable DX10-class functionality such as stream-out."
http://www.joystiq.com/2006/08/24/xbox-360-cant-run-directx-10-confirms-ati/
Microsoft, Apple, Google, Amazon what's the difference? All steal money from devs and control with walled gardens.
It also allows you to pick libraries that have been made by experts in the area the lib focuses on.
Are you implying that Microsoft just throws whomever at the various portions of directx? The networking guy programs directsound, the sound guy programs directinput, the janitor programs direct3d? I don't generally stand up to defend MS, but I'm willing to bet that they have plenty of money and clout to get various experts to program their specs. And I know it's totally anecdotal, but most game developers I know or whose opinions I've read seem to feel that directx is a more intuitive and feature-rich platform.
All I've really seen of the PS3 dev kit is what was on display at GDC. The Sony guys talked about GL ES and NVIDIA's Cg toolchain for shaders, so that's what I posted. This, however, sounds a lot more like what I expected from Sony and is right in line with the PS2 dev kit (emphasis mine):
Sony supply an alternative low level api called libGcm.
If libGcm is what I think it is (macro'd constants to build push buffers + raw DMA access) then pretty much nobody will be using the GL stuff. Coding right to the hardware is what PlayStation development is all about.
While the gaming community is growing at an awesome rate, I doubt its the same size, and definitely not bigger than the hollywood industry. Coming from the special effects/render farm industry, I can tell you that every single movie that makes it to the big screen today, is in one way or many, made with products that use OpenGL. The gaming community/developers of course are frustrated that opengl is not dx10, but lets face it, hollywood has an endless budget, and a lot of say. This story does not surprise me, and opengl is still going to be the best cross-platform solution for many (and most) 3d technologies, less gaming.
.
FIY:
We collect data from the browsers of site visitors to our exclusive on-demand network of live stats customers. The data is compiled from approximately 160 million visitors per month.
Additional estimates about the website population:
76% participate in pay per click programs to drive traffic to their sites.
43% are commerce sites
18% are corporate sites
10% are content sites
29% classify themselves as other (includes gov, org, search engine marketers etc.. About Our Market Share Statistics
Net Applications stats are global.
Its clients - for reasons which should be blindingly obvious - are interested only in meaningful stats about users, not licenses.
Plenty of people are buying computers with Vista and switching to another OS, or downgrading to XP.
The numbers simply aren't there to support this argument.
Take a look at this extension: http://www.opengl.org/registry/specs/EXT/direct_state_access.txt This is actually quite significant. I think it could form the basis of the object system that was promised but not delivered.
"Politicians and diapers must be changed often, and for the same reason."
Please stop modding up this troll.
That article is 6 years old.
Most of those patents are hardware patents totally irrelevant for OpenGL (or Direct3D for that matter).
Also, Microsoft is not a member of the group that actually writes the OpenGL specification. They have no vote on what gets in OpenGL or don't.
Of course this might give them leverage on some of the hardware vendors (like Nvidia) that will have to implement the new OpenGL standard in the future. But history does not show them trying to use this in any way against OpenGL.
But claiming they "own OpenGL" is nonsense.
Basically they've got tangled in the implementation details and decided to play it safe with OpenGL 3.0 instead of starting from scratch.
========
What happened to Longs Peak?
In January 2008 the ARB decided to change directions. At that point it had become clear that doing Longs Peak, although a great effort, wasn't going to happen. We ran into details that we couldn't resolve cleanly in a timely manner. For example, state objects. The idea there is that of all state is immutable. But when we were deciding where to put some of the sample ops state, we ran into issues. If the alpha test is immutable, is the alpha ref value also? If we do so, what does this mean to a developer? How many (100s?) of objects does a developer need to manage? Should we split sample ops state into more than one object? Those kind of issues were taking a lot of time to decide.
Furthermore, the "opt in" method in Longs Peak to move an existing application forward has its pros and cons. The model of creating another context to write Longs Peak code in is very clean. It'll work great for anyone who doesn't have a large code base that they want to move forward incrementally. I suspect that that is most of the developers that are active in this forum. However, there are a class of developers for which this would have been a, potentially very large, burden. This clearly is a controversial topic, and has its share of proponents and opponents.
While we were discussing this, the clock didn't stop ticking. The OpenGL API *has to* provide access to the latest graphics hardware features. OpenGL wasn't doing that anymore in a timely manner. OpenGL was behind in features. All graphics hardware vendors have been shipping hardware with many more features available than OpenGL was exposing. Yes, vendor specific extensions were and are available to fill the gap, but that is not the same as having a core API including those new features. An API that does not expose hardware capabilities is a dead API.
Thus, prioritization was needed, and we made several decisons.
1) We set a goal of exposing hardware functionality of the latest generations of hardware by this Siggraph. Hence, the OpenGL 3.0 and GLSL 1.30 API you guys all seem to love ;\)
2) We decided on a formal mechanism to remove functionality from the API. We fully realize that the existing API has been around for a long time, has cruft and is inconsistent with its treatment of objects (how many object models are in the OpenGL 3.0 spec? You count). In its shortest form, removing functionality is a two-step process. First, functionality will be marked "deprecated" in the specification. A long list of functionality is already marked deprecated in the OpenGL 3.0 spec. Second, a future revision of the core spec will actually remove the deprecated functionality. After that, the ARB has options. It can decide to do a third step, and fold some of the removed functionality into a profile. Profiles are optional to implement (more below) and its functionality might still be very important to a sub-set of the OpenGL market. Note that we also decided that new functionality does not have to, and will likely not work with, deprecated functionality. That will make the spec easier to write, read and understand, and drivers easier to implement.
3) We decided to provide a way to create a forward-compatible context. That is an OpenGL 3.0 context with all deprecated features removed. Giving you, as a developer, a preview of what a next version of OpenGL might look like. Drivers can take advantage of this, and might be able to optimize certain code paths in the forward-compatible context only. This is described in the WGL_ARB_create_context extension spec.
4) We decided to have a formal way of defining profiles. During the Longs Peak design phase, we ran into disagreement over what features to remove from the API. Longs Peak removed quite a lot of features as you might remember. Not coincidentally, most of those features are marked deprecated in OpenGL 3
As a developer I'd like to see OpenGL ES given priority over OpenGL. OpenGL ES matches the hardware much better than OpenGL does.
OpenGL itself could be implemented as a library on top of OpenGL ES. This would move all the legacy crud out of the main driver and make the jobs of driver writers a lot easier (an OpenGL ES driver is a lot smaller than an OpenGL driver).
OpenGL ES could become the basis for Linux graphics drivers instead of OpenGL (why does a window manager need all those OpenGL functions? It doesn't...)
No sig today...
No DX10 _IS_ BS. If it was so great why not implement it into XP? To entice people to upgrade to Vista? Why are they working on a new rewrite for Windows 7 if DX10 is so hawt. And by the sound of things you won't be able to get DX11 unless you get Windows 7. Thats not exactly showing a lot of love for their users.
Seems to me all modern day corporations are all just trying to screw over the consumer. Fan boys get it the worst.
As far as prettier in DX10 vs DX9. I don't see it. Yes i've seen the before and after videos. I've stared at lots of jungle leaves. I see a subtle difference but nothing FAR superior. IMHO those who claim they see a night and day difference in DX10 is basically going along with the king's new clothes syndrome. If DX11 has ray-tracing in it than it will be far superior. If its more improved shading on jungle leaves I could give a flying f- less about it.
I'm curious - what Tool Set Of The Gods do you use to write this "cutting edge" software you are talking about?
Depends if you think that DX being closed source is a problem. I'd tend to err on the side that it isn't.
I have been part of the Khronos group previously (though not on openGL), but in general it tends to involve very long e-mail discussions about how X is broken. Half the people will agree. The other half will admit it's broken, but will be reluctant to change it because it'll require additional work for their companies (i.e. it'll cost them money to make that change). So whilst everyone may agree that a change is needed, very few people will vote to change it.
The result of months of e-mail discussions is basically not a lot. Unfortunately that's what happens with design by commitee. So whilst moving GL from the ARB to the Khonos group was well intentioned, I suspect that not very much has changed (as I think has been demonstrated with the GL3 spec).
The simple reason D3D keeps moving forward is that a dictator driven API can, and does, break the API in order to make progress. The sucky thing is that it's Windows only. If it was available on linux/mac/windows XP, then I'd gladly switch to D3D10....
OpenGL is perfectly adequate for the vast majority of graphics applications out there, including games, (e.g. Spore).
adequate != ideal
Unfortunately, OpenGL in it's current state is far from ideal. It's the ease of use of D3D when compared to OpenGL that makes developers targetting the Windows platform use D3D. Not to mention the maths library. The debugging tools (Pix). The samples. The documentation. Etc Etc.
DX9/10 is not critical for *keeping* developers on windows. The sheer number of windows users does that well enough already.
Developing with OpenGL is do-able (It's core to the App's i work on), but when you get support tickets with things like:
* Texturing has errors on a Voodoo 5.
* Crashes on ATI radeon.
* Widgets not visible on Intel X3100.
* Overlay's not visible on 3D labs Wildcat
It does start to get a little bit depressing....
Granted, there are probably large portions of the code that constitute algorithms and data structures that don't need to have GUI-specific code in them. We have all seen designs where GUI calls are dispersed in those algorithms when they can be put elsewhere.
But on the other hand, perhaps as much as half the lines of code in one of these apps has something to do with the GUI or the expression of the data into the graphical display. Suppose your target was OpenGL, but to not get too "locked down" to OpenGL, you abstracted the calls to OpenGL with some kind of wrapper. OK, now the edict comes down from the PHB to change everything over to DX10 or OpenGL 3.XXX, you say, "Piece of cake, I will just rewrite that wrapper."
Fine, but you are probably using the capabilities and perhaps quirks of OpenGL. At some deep level, you are probably tied to the way of thinking OpenGL has about how to do graphics. You have this wrapper, but is most likely one of Joel Spolsky's "leaky abstractions" of OpenGL anyway, and it may be far from trivial to adapt this wrapper to the Next Best Thing.
The other approach you can take is say, "I don't want the fortunes of my CAD/CAM program tied to OpenGL, I will only use a minimal subset of OpenGL that appears to be common to DX and some other things. I won't even wrap to some of the fancier features of OpenGL so I don't get stuck -- if I need those features, I will implement them myself." This is essentially the Sun Java-Swing approach -- they code to the absolute bare essentials of the underlying GUI on whatever platform and they implement the bulk of what a GUI and a widget rendering library needs to do, essentially reinventing what a lot of Windows-GTK-QT-Quartz does in Java code.
You can take the Java-Swing approach and indeed have API-specific code now contained to a small area. You can do this because a large area of your code is essentially your own home-brew buggy reimplementation of a lot of what is in OpenGL. Sun got a lot of criticism for Swing for the low performance for doing this, and implementing Swing I imagine was a major undertaking, but Swing exists and it has been around long enough for incremental improvement to get it to the point of usability for what a lot of people want to do with it.
But to suggest that having OpenGL calls interspersed through half of a CAD/CAM app is "bad design" is perhaps optimistic thinking regarding how cleanly such an app can be separated into modules. The whole point of OpenGL is that it is platform neutral, and that OpenGL is in fact the wrapper to the underlying graphics library on the various ports of your app. So what you are saying is that the developer of a major CAD/CAM package has to have an in-house wrapper to what is already a platform-independent graphics wrapper because use of OpenGL constitutes lock-in to a platform?
All problems stem from one company. Microsoft. Microsoft has been the reason that Vista's adoption is 1/2 what it was and it is the reason we have that much of an adoption as it is. What do I mean?
Microsoft is forcing vendors to sell Vista instead of XP. Microsoft is also forcing hardware vendors to implement BIOS hacks to keep transitions from Vista to XP. This is evidenced by many factors, such as the lack of available XP drivers for these new pre-fab pre-installed Vista boxes.
Keep in mind that this is not the case with custom built. Custom built machines can take XP or Vista, or any other.
I remember back a while ago about the Foxconn debacle. I think there's something similar going on here. When you attempt to install XP on various hardware that came pre-installed with Vista you can get the OS installed. But if you attempt to install drivers for those components, if you can find them, there is an almost complete failure to get these components to function.
This is not the case with all manufacturers. It is the case with Gateway and with Toshiba. Both of these manufacturers are forcing Vista installs. It may be with a few chipset packages such as the Intel GM/GL 965. But it is happening.
After a successful install of XP (after verifying that the components work under Vista) and then attempt to install say the wireless, wired, sound, SMBUS drivers, you'll get messages from the installers informing you that the devices aren't present.
You can confirm that this is a BIOS level function due to the fact that if you take a component from a machine that came pre-installed with XP and put it into the new machine where you have removed Vista and installed XP, that component's driver installer will also tell you that the device is not present, even though it was properly installed in another machine.
This clearly is an attempt by Microsoft to mandate to the manufacturers that they are not to support XP any longer even if the customer has chosen to do this on their own.
We did not have this situation when going from Win2k to XP nor from Win98 to XP. It appears to be an issue specifically with going from Vista to XP. It appears to be a bios level hack which creates the situation.
Contact with others has confirmed the situation. Many have reported that this is occuring and the consensus is that it is a mandate by Microsoft to prevent users from running XP on these older machines.
As I said, it isn't all machines. It is a new tactic being implemented on newer hardware in an attempt to force us to stay with Vista.
One has to ask why this is the case. Why on earth is Microsoft so hell bent on forcing us to Vista? Is it some hidden back door? Why would Microsoft care which OS we run given that we have paid them for Vista and paid a second time for XP? What is their motive for mandating this type of issue? Why would they dictate that the sales support for XP has been dropped so quickly?
Something is awry here.
You can lead a man with reason but you can't make him think.