OpenGL support in WinXP64 and/or Longhorn

An article on Gamasutra ( link ) from the WinHEC says Microsoft have accepted that they’ll have to start supporting OpenGL again.

The relevant text is:

OpenGL is now a grudgingly accepted citizen. Since late in the NT 4.0 era, Microsoft hasn’t wanted to support OpenGL, preferring to evangelize DirectX as the One True Way to display 3D. Between the graphics chip vendors doing their own OpenGL drivers, and the big CAD companies continuing to require it, Microsoft has put OpenGL support back into the operating system, so you can rely on it being there.
Has anybody heard this elsewhere or got any more information?

dave j

Take a look at this power point presentation:
http://download.microsoft.com/download/1…_WINHEC2004.ppt

OpenGL will be included in Windows Longhorn but only version 1.2

I guess they are still only going to do the bare minimum to support CAD software. Now if we could just get all the CAD developers to require GLSL… :slight_smile:

Hey, 1.2 support is a huge improvement over 1.1!

Originally posted by jwatte:
Hey, 1.2 support is a huge improvement over 1.1!
Heck yeah, this is some very good news if you ask me. Score one for OpenGL! :slight_smile:

-SirKnight

Awesome! Finally, OpenGL 1.2 in 2006-2007 when Longhorn is released and then 2007-2008 when end users actually start to deploy it in enough numbers.

That was sarcasm by the way.

Microsoft will begrudgingly support it if there is competition.

That either means OS X on cheap hardware or IBM/Sun/SGI/Novell figuring out how to deploy a Unix as a business desktop.

Nice if it happens. But I’m not holding my breath for any of those scenarios.

Does it not scare anyone that that presentation bascially states that all OpenGL will sit ontop of an internal wrapper to Direct3d??
This might force any freedom that opengl had down a software path if it comflicts with direct3d?
And also might mean that we will loose OpenGL’s primitive draw advantage that is has over direct3d??
1.2 only sux too.
Reading that presentation meakes me realise that opengl needs to start mooving Fast if its going to even try to keep up with direct3d :frowning:
M.

do we really need windows? :wink:

do we really need windows?
Um, yes. Seeing as how Windows is the dominant platform for personal computers and all.

OpenGL will only “sit on top of” D3D in the sense that the default MS OpenGL implementation will try translate to D3D calls if there is no ICD available. The diagrams make it quite clear that when an ICD is installed, it handles everything directly.

As a side note, did yuo guys notice that the new driver model for D3D is OpenGL-style (most code in user space)? They must be envious of that lower per batch overhead :wink:

As a side note, did yuo guys notice that the new driver model for D3D is OpenGL-style (most code in user space)? They must be envious of that lower per batch overhead
Yes, but that’s not a good thing for OpenGL; it strips away one of the few remaining advantages of OpenGL as a platform.

Though such a decision starts to confer the negatives of OpenGL upon D3D, namely that writing drivers becomes a more involved process.

What would really be nice is if someone would write a ICD for OpenGL (one including things like VBO, vertex/fragment programs, maybe even glslang, though that one’s a bit more difficult) that actually does D3D translation (and emulation where necessary). The reason for this would be for non-nVidia/ATi card makers that can’t be bothered to make their own decent GL implementation.

Atleast Microsoft is pushing for new features in GPU with its DX Next spec which has to be fully supported by the hardware for Longhorn. Looking at the slides, it looks even worse for (new) opengl driver writers and even developers. The drivers need to support only the latest interface of D3D, the OS layers backward compatibility on top of it. The tools for debugging also seem to be pretty nifty.

Its time for an openglARB32.dll with similar functionality. :smiley:

Originally posted by Korval:
What would really be nice is if someone would write a ICD for OpenGL (one including things like VBO, vertex/fragment programs, maybe even glslang, though that one’s a bit more difficult) that actually does D3D translation (and emulation where necessary). The reason for this would be for non-nVidia/ATi card makers that can’t be bothered to make their own decent GL implementation.
You mean like GLDirect ( link ). :slight_smile: It doesn’t say what version it supports but, since it’s based on Mesa, it may be quite recent. It being based on Mesa also means it has to be free.

dave j

Originally posted by harsman:
As a side note, did yuo guys notice that the new driver model for D3D is OpenGL-style (most code in user space)? They must be envious of that lower per batch overhead :wink:
Microsoft were criticized when they moved the video drivers into kernel space (was it with NT4? - I can’t remember) because it is a security risk to have 3rd parties writing kernel code. That fact that they’ve moved it back to user space probably has more to do with their new focus on producing less hackable systems.

dave j

The article also said that newer versions of Windows have the no-execution flag set. Does this mean we cannot use runtime code generation anymore?

no, it just means you have to specify your code as such. (softwire yet takes care for this, for example).

you have to specifically request it by the os. this makes all non-modificable code 100% save.

or so :smiley:

Originally posted by Korval:
What would really be nice is if someone would write a ICD for OpenGL (one including things like VBO, vertex/fragment programs, maybe even glslang, though that one’s a bit more difficult) that actually does D3D translation (and emulation where necessary). The reason for this would be for non-nVidia/ATi card makers that can’t be bothered to make their own decent GL implementation.[/QB]
There are a handful of wrappers out there, including D3D to GL.

What’s really weird is that some drivers, like that of Matrox are GL -> D3D wrapper but they are extremely buggy.

Side note : XGI seems to be on the ARB now. Thumbs up to them. Maybe they will have GLSL soon.

Originally posted by harsman:
[b]OpenGL will only “sit on top of” D3D in the sense that the default MS OpenGL implementation will try translate to D3D calls if there is no ICD available. The diagrams make it quite clear that when an ICD is installed, it handles everything directly.

As a side note, did yuo guys notice that the new driver model for D3D is OpenGL-style (most code in user space)? They must be envious of that lower per batch overhead :wink: [/b]
It’s going to be pretty hard to implement OpenGL on top of legacy D3D systems considering that D3D doesn’t intrinsically support two-sided lighting or two-sided materials. Currently, the “nice” thing about having the Microsoft OpenGL pipeline going through software is that it can be used to isolate an application from really bad ICDs. It will be interesting to see how Microsoft addresses this accelerated path on cards that don’t support basic functions such as shaders (to address the two-sided issues), stencil planes, user clipping planes, etc. At least with the current MS software path, I have a reasonable chance of generating a bitmap that looks decent on any configuration – albeit slower than I might like.

– tim

Isn’t 2-sided lighting pretty easy to emulate? Can’t you just render the object twice?

And nothing says that their D3D layer made direct calls to D3D. They can take the time (depending on how much they care about a good GL implementation) to turn various GL commands into a sequence of D3D ones. And, if they’re going to make a functioning implementation at all, they still have to accept GL state that legacy D3D doesn’t support, and thus emulate it in some fashion.

Besides, since this is their GL layer, it doesn’t have to use legacy D3D. It can use D3D 9 or D3D Next (in Longhorn), since these calls, for hardware that doesn’t support it, will be converted into the proper D3D version by the D3D subsystem itself. So another system would be required to emulate things that D3D Next doesn’t support, but that’s already planned.

And some people care about performance more than a bitmap that “looks decent on any configuration”. I would love to have a, perhaps slower, nearly fully functional generic driver that I could fall back on if I’m using fairly low-end GL features. Though I really wish they’d try to adapt OpenGL versions greater than 1.2. At least provide the entrypoints for them, even if they don’t use them.

Isn’t 2-sided lighting pretty easy to emulate? Can’t you just render the object twice?

If Z testing and writing is on, and blending is off, then this is often possible. If these preconditions are not true, then it’s not equivalent.