PDA

View Full Version : OpenGL support in WinXP64 and/or Longhorn



davej
06-06-2004, 09:17 AM
An article on Gamasutra ( link (http://www.gamasutra.com/features/20040603/pournelle_01.shtml) ) 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

Corrail
06-06-2004, 09:22 AM
Take a look at this power point presentation:
http://download.microsoft.com/download/1..._WINHEC2004.ppt (http://download.microsoft.com/download/1/8/f/18f8cee2-0b64-41f2-893d-a6f2295b40c8/TW04079_WINHEC2004.ppt)

OpenGL will be included in Windows Longhorn but only version 1.2

davej
06-06-2004, 09:31 AM
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... :)

jwatte
06-06-2004, 09:38 AM
Hey, 1.2 support is a huge improvement over 1.1!

SirKnight
06-06-2004, 07:51 PM
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! :)

-SirKnight

pkaler
06-06-2004, 09:11 PM
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.

Ventura
06-06-2004, 11:25 PM
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 :(
M.

gvm
06-06-2004, 11:30 PM
do we really need windows? ;)

Korval
06-07-2004, 12:31 AM
do we really need windows?Um, yes. Seeing as how Windows is the dominant platform for personal computers and all.

harsman
06-07-2004, 12:59 AM
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 ;)

Korval
06-07-2004, 01:43 AM
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.

krychek
06-07-2004, 02:24 AM
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. :D

davej
06-07-2004, 03:35 AM
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 (http://www.scitechsoft.com/products/ent/gld_home.php) ). :) 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

davej
06-07-2004, 03:48 AM
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 ;) 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

Christian Schüler
06-07-2004, 04:49 AM
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?

davepermen
06-07-2004, 06:22 AM
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 :D

V-man
06-07-2004, 06:35 PM
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.

tranders
06-08-2004, 11:47 AM
Originally posted by harsman:
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 ;) 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

Korval
06-08-2004, 12:59 PM
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.

jwatte
06-08-2004, 01:07 PM
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.

evanGLizr
06-08-2004, 04:57 PM
Originally posted by jwatte:


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.Hmmmm why is that? It should be just
1. Set front material, cull backfaces, render
2. Set back material, invert normals, cull frontfaces, render

That's assuming culling is originally off, if culling is on it's even easier (you only need to render whatever material is not going to be culled).

jwatte
06-08-2004, 07:15 PM
I thought I was obvious enough.

Suppose you have four triangles, two facing you, and two facing away, all overlapping in screen space. If blending is on, the result of the drawing will very much result in the drawing order of those individual triangles. If you draw them all with no back culling, they will very likely hit the screen in a different order than if you first draw only the front-facing ones, and then draw only the back-facing ones.

Similarly, when Z write is on, you get the same order dependency.

If you're prepared to constrain yourself to convex outwards-facing meshes only (possibly not closed) then the ordering will be correct if you first draw back-facing, and then front-facing. But that's an awfully limiting restriction to put on your art.

tranders
06-08-2004, 07:21 PM
Originally posted by Korval:
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.Sure, you can draw the surfaces twice to emulate 2-sided lighting and materials, but if D3DX does not handle this intrinsically (i.e., only send the data once), you can count on a significant performance hit. I'm sure that Microsoft is not worried about that aspect of their design. Longhorn has no restriction regarding legacy hardware (i.e., Longhorn will run on any graphics card). IMO, it would be a tremendous mistake if Longhorn OpenGL required a specific level of HW D3D support.

Implementing a state engine on top of D3D is fairly trivial and doesn't require any significant changes to D3D proper since most OpenGL state settings are USER mode settings anyway. That fits in neatly with the move back to USER mode doesn't it? Go figure.

Considering that MSFT chose OpenGL 1.2 as the baseline leads me to believe that OpenGL fragment/vertex shaders will get the short end of the stick (if any stick at all) since most of those extensions require 1.3 or 1.4. I could be mistaken, but probably not.

While interactive performance is always important, stability and reliability of the printed page (or generated image) for CAD applications is mandatory (try dragging a 10 year old workstation into a court room). If my hardcopy/archive output is dependent on a graphics driver from XYZ corporation, then my development and support effort just got that much more difficult. I can only hope that there will continue to exist a generic/software option.

-- tim

evanGLizr
06-08-2004, 08:51 PM
Originally posted by jwatte:
I thought I was obvious enough.

You were, indeed, it was just me being thick, you are completely right.

V-man
06-08-2004, 10:12 PM
So what does it matter that MS decided to update GL?

You should update your drivers, plus it would be better if MS supplied each vendors GL drivers on the Windows installation CD.

Besides, I have a feeling MS is bull****ting about updating openglXX.dll so dont get to excited.

tranders
06-09-2004, 04:56 AM
Originally posted by V-man:
So what does it matter that MS decided to update GL?

You should update your drivers, plus it would be better if MS supplied each vendors GL drivers on the Windows installation CD.

Besides, I have a feeling MS is bull****ting about updating openglXX.dll so dont get to excited.Keeping drivers up to date is not the issue. For instance, if my application experiences serious graphics problems due to bugs in the driver, I can simply drop the acceleration slider in the troubleshooting tab all the way to the left and effectively disable the 3D portion of the graphics card. My application may run slow because OpenGL is running in the generic software pixelformat provided by Microsoft, but at least I can meet my deadline. However, if my BASELINE depends on 3D hardware support (and its associated driver), I will probably still have problems. Driver bugs tend to take weeks (not days) to resolve (if ever) and high-end applications get little or no support from graphics card vendors if the application is running on a consumer level card (e.g., GeForce vs Quadro).

I agree that MSFT is probably not overly concerned with making sure that Longhorn OpenGL is as reliable as it is on today's OS'es. However OpenGL 1.2 is a much better API than 1.1 regardless of how this all falls out.

-- tim

V-man
06-09-2004, 04:34 PM
Originally posted by tranders:
[B]
My application may run slow because OpenGL is running in the generic software pixelformat provided by Micros ....

I agree that MSFT is probably not overly concerned with making sure that Longhorn OpenGL is as reliable as it is on today's OS'es. However OpenGL 1.2 is a much better API than 1.1 regardless of how this all falls out.

-- tim[/QB]So what you need is a reference rasterizer, which is something I need sometimes as well. Use Mesa, cause it's not that bad (some bugs, but it supports 1.5 and plenty of none-core extensions).

My previous post was about not expecting much from MS. GL 1.2 was suppose to be delivered 4 years ago, with Win2000.

Then they said it was going to be released with SP1, then they said SP2, ....

Instead, they released WinXP with GL beeing a D3D wrapper, and the OpenGL scrensavers (flower box, pipes, ...) converted to D3D.

Why did they dedicate time for rewritting screensavers?

If I'm wrong, feel free to egg me.

gaby
06-10-2004, 05:46 AM
I think OS X is the most advanced system now, and is better than Longhorn for lot of feature, including graphics, both for realtime and deffered. It support native PostCript, really fast font rendering, and is entirelly based on an open GL window realtime compositing sub systém (all is shadowed, transparent)...

When working on OS X, all is extremlly fast and all time perfect (10 seconds to boot !).

But, Apple build the computers and is an ARB member...

If you want to be impressed by a really beautifull technology, try mac OS X on the last dual G5 processor mac (the mainbord have 2 front side bus at 1.2 Ghz !!! - 20 GBps bandwide).

So, I think that MS is trying to do something really difficult and might have lot of stability problems at the graphic level too...

Just my opinion.

Gaby