PDA

View Full Version : Should Microsoft enable OpenGL to run as an ICD under Windows Vista's Aeroglass



Khronos WebMaster
08-05-2005, 11:30 AM
Microsoft's current plan for OpenGL on Windows Vista is to layer OpenGL over Direct3D in order to use OpenGL with a composited desktop to obtain the Aeroglass experience. If an OpenGL ICD is run - the desktop compositor will switch off - significantly degrading the user experience. In practice this means for OpenGL under Aeroglass:
OpenGL performance will be significantly reduced - perhaps as much as 50% OpenGL on Windows will be fixed at a vanilla version of OpenGL 1.4 No extensions will be possible to expose future hardware innovations
It would be technically straightforward to provide an OpenGL ICD within the full Aeroglass experience without compromising the stability or the security of the operating system.

knackered
08-05-2005, 01:42 PM
I don't understand why you need to poll opengl developers about this. Just take a look at the software being developed, look at the various sectors, how many apps are written using GL exclusively on Windows? Not many I should imagine. A big reason people choose OpenGL is for platform independence - if microsoft can't provide decent support for OpenGL then these apps will simply not be deployed on Windows OS, unless a customer pays a premium for d3d port.

al_bob
08-05-2005, 01:53 PM
if microsoft can't provide decent support for OpenGL then these apps will simply not be deployed on Windows OS, unless a customer pays a premium for d3d port.Would you pay a premium to play your favorite games in Windows? Or is a worse user experience compared to (say) Windows XP acceptable?

Korval
08-05-2005, 03:13 PM
If an OpenGL ICD is run - the desktop compositor will switch off - significantly degrading the user experience.In what way will this degrade the user experience? Like, if I'm running a full-screen GL game, what would I be losing?

AlexH
08-05-2005, 04:01 PM
Originally posted by Korval:

If an OpenGL ICD is run - the desktop compositor will switch off - significantly degrading the user experience.In what way will this degrade the user experience? Like, if I'm running a full-screen GL game, what would I be losing?Absolutely nothing. As far as I see it, the story is a complete over-reaction, and contains a lot of technical misunderstandings and misinterpretations.

First, MS will in fact ship Windows Longhorn/Vista with their own GL 1.4 implementation, which is quite an achievement for them compared to their current 1.1... But they will obviously not prevent ATI/NV from releasing more up to date ICDs. And the statement that no extensions will be supported anymore is complete bull.

Second, yep, the new Windows desktop and GUI system is based on DX. Of course it is, did anyone really expect that they would base such a core component of Windows on OpenGL ? Come on. And it is perfectly understandable that they will layer any other API performing GUI rendering onto DX, simply from a technical point of view (ie. providing a common interface point).

In practice, that means that your OpenGL rendered new GUI buttons or custom controls will go through a DX layer. So what ? Who would use GL for such a task anyway ? If I see one more 3D animated paperclip or "search function dog" I will kill myself, and I won't give a damn about whether it is rendered in D3D or OGL.

OK, granted, serious applications using GL as an inherent part of their GUI (eg. CAD applications) might experience a performance hit, but there will be workarounds. Probably by switching off some GUI eyecandy, ie. the first thing any professional user is going to do anyway.

And all this doesn't even apply to an application running in fullscreen, or simply in an exclusive Window. A game is such an application.

Where is the problem then ?

Hlz
08-05-2005, 04:49 PM
Aeroglass looks like it's going to be a real oinker.

The multi-GPU compositing stuff is really cool though.

http://www.sgi.com/products/visualization/downloads/adv_scalablegraphics.pdf

This trend is going to lead to some seriously good kick-ass.

sqrt[-1]
08-05-2005, 04:50 PM
Originally posted by AlexH:

Where is the problem then ?The problem is it appears that if you install drivers that come from ATI/Nvidia to get correct OpenGL, it disables all the UI eye candy. (Not a problem for professionals but Joe user will complain) (NOTE that drivers from windows update don't have OpenGL support)

So computers will be in one of two states:
- Correct OpenGL + No UI eye candy
- Wrapper OpenGL (1.4, no shaders) + UI eye candy.

What do you think Joe user will want?
How about people selling these computers at Dell etc? I am sure they want to show off UI eye candy more than have correct OpenGL support.

Yes this is guesswork until longhorn actually ships, but it seems to be what is going to happen.
See my rant:
http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=12;t=000001

Coconut
08-06-2005, 12:29 AM
Not if you are developing window-based applications. That means I will be getting phone calls from my Joe customers complaining my app screwing up their other applications which hell knows how they are going to use the new eye candy thing.
I have a feeling that I will end up writing code on DX......

M/\dm/\n
08-06-2005, 03:13 AM
If they are goin to do something like that, then i hope they get teared apart because of antimonopoly law.

knackered
08-06-2005, 09:38 AM
Originally posted by al_bob:

if microsoft can't provide decent support for OpenGL then these apps will simply not be deployed on Windows OS, unless a customer pays a premium for d3d port.Would you pay a premium to play your favorite games in Windows? Or is a worse user experience compared to (say) Windows XP acceptable?I'm not talking about games, I'm talking about visualisation, simulation, VR etc. If microsoft shaft their GL support, these applications will become linux-exclusive applications over-night - so the state-of-the-art effects combined with stuff like quad buffered stereo and 6DOF tracking, in other words *really cool stuff* will only be seen on linux. From a marketing standpoint, this is not a good, forward thinking decision for microsoft to make...if indeed they have made that decision, which I doubt.

Korval
08-06-2005, 09:43 AM
The problem is it appears that if you install drivers that come from ATI/Nvidia to get correct OpenGL, it disables all the UI eye candy.That sounds rather silly, to disable UI features just for installing drivers. It makes more sense for these features to be disabled by the use of their implementation, not by installing it.

Plus, neither nVidia nor ATi provides separate OpenGL drivers. They simply have graphics drivers. So, unless they plan on changing this for Vista, clearly your supposition is wrong. People aren't going to like D3D driver updates (ie, graphics driver updates) to damage their UI settings.


If they are goin to do something like that, then i hope they get teared apart because of antimonopoly law.And precisely how is this a violation of anti-trust laws? OpenGL is not a company; it is a specification. A document. It's OK to shut your system out of a document. You don't have to make your OS be able to use OpenGL, and to not do so is hardly illegal.

*--*

I'm thinking that this entire thread is alarmist and decidedly anti-Microsoft on an issue that there is far too little information about to make any decisions one way or another.

execom_rt
08-07-2005, 12:57 AM
See this 6 months old thread. (http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=3;t=013108;p=2#0000 56)

I was saying :
"And finally, in Longhorn, OpenGL will be on top of DirectX 10. It will be wrapper (GL->DX) "for security reasons". That, will be a killer.

(see http://www.theinquirer.net/?article=21077 )"

I think it what's is happening.

I guess the best solution is to write an OpenGL ICD using DirectX 9 API for texture and memory management + viewport rendering and keep the rest (was is 'really' OpenGL like GLSL or other). It has been done before (some old OpenGL renderers was using DirectDraw for some operation). Performance hit should be minimal, but psychologically, OpenGL will look less attractive.

In counterpart, support for Sis, Intel, or Matrox would be handled by a common code base, but since thoses renderers doesn't meet the requirement for Aero glass ...

Finally, this will slow down the 'innovation' for adding features in OpenGL ...

Yes it's a killer.

dorbie
08-07-2005, 01:47 AM
Groan, it's not even clear what this means, there's just a bunch of panicked mouth breathers predicting doom.

As far as I can tell desktop eye candy will have to be written in D3D or if it uses OpenGL it'll have to be version 1.4 or earlier and there's no information on what additional hooks NVIDIA, ATI et. al. will have.

There's nothing that says you won't be able to develop in OpenGL 2.0 on windows delivered as always by your favorite hardware maker and NOT by Microsoft.

There just aren't enough facts to fully understand what this means and there's definitely a shortage of good informed analysis.

Maybe this means some bad things but as far as I can tell, worst case an OpenGL app using the latest stuff won't play well with the eye candy stuff, and we don't even know that for sure.

By default on a vanilla system OpenGL will run **faster** and be more functional if you consider that currently without IHV drivers it's software fallback or worse, not even installed. So the sky is not falling, yet.

Coconut
08-07-2005, 04:19 AM
The thread posted on the homepage has a post by Barthold from 3DLabs and he seems pretty sure about that.

Dorbie, don't you think your google earth would "look" inferior if Micorsoft comes out with their BS version that has the eye candy enabled?

V-man
08-07-2005, 06:37 PM
Originally posted by Korval:
And precisely how is this a violation of anti-trust laws? OpenGL is not a company; it is a specification. A document. It's OK to shut your system out of a document. You don't have to make your OS be able to use OpenGL, and to not do so is hardly illegal.

*--*

I'm thinking that this entire thread is alarmist and decidedly anti-Microsoft on an issue that there is far too little information about to make any decisions one way or another.[/QB]I don't know if it is a violation of antitrust law. MS has attempted to bring down GL for a long time and it's getting old.

When you write a song that is so popular that it becomes part of culture, you no longer own it, IMO. Same with Windows. The public owns it. They should be forced to support GL. Again, just my opinion.

Jan
08-07-2005, 11:43 PM
V-Man: That's an interessting thought, and i kind of agree, but you can't formulate a fair law for such a case. It wouldn't be right.

Afterall Windows is a product of a company. I couldn't understand on which law the european government was able to force MS to sell it without the Media Player. I don't think that's fair, either. In the end MS can do with their software, what they want. Only because everyone uses their software (although we COULD all use linux), doesn't really justify to force them what to include and what to exclude in their product.

But of course i am all for forcing them to include real OpenGL-support! ;-)

Jan.

PixelDuck
08-09-2005, 01:20 AM
The problem assosiated with this is the law of the masses. If the majority of the people are using some product it has to be taken into account that this fact has some implications on the product and the developer of that product has to take responsibility for it's actions regarding the product. For instance, you have to have laws for discrimination of certain users. The company could for instance say that all people named John could not use the product and still not lose any/alot of profit since there are so many people using it that you can't get everyone to change to using some other product just like that... This should be illegal even though the developer should have full control over its product.

The problem just is that one can't forget about the people dependent on some solutions. It shouldn't be legal to kill companies by making decisions about ones products that could lead to it... And since this does have serious implications on companies that develope using OpenGL it should be affected by laws against missuse of monopoly.

Korval
08-09-2005, 09:57 AM
It shouldn't be legal to kill companies by making decisions about ones products that could lead to it...You'd have a hard time arguing that this decision was killing any company. And that's assuming that this decision means what some people are saying it means, as that has not been fully determined yet.


And since this does have serious implications on companies that develope using OpenGL it should be affected by laws against missuse of monopoly.In what way? Microsoft has the choice to use whatever graphics API they want. They don't even have to provide an OpenGL API at all, yet they do and continue to do so. They're even updating it for Vista; getting the Microsoft implementation won't suck as much as it used to. If Microsoft didn't provide the API through the ICD mechanism, game developers would all be using Direct3D.

The worst that happens is that use of an OpenGL ICD turns off Aeroglass until the ICD is deactivated. For all we know, it may just turn off Aeroglass for just that window, not the desktop as a whole. There isn't enough information to be concerned about this yet.

And what implications does this have for OpenGL developers? For me, the major change for Vista is making Win32 a legacy API at all; this has far more impact to Windows developers, as it forces them towards .NET WinForms stuff in order to get new functionality. This is a far more substantial change for developers than switching to D3D from GL, even if they had to (which they clearly don't).

knackered
08-09-2005, 10:01 PM
I'd imagine that in the end, using opengl in a windowed app will be exactly the same as now, except instead of blitting the framebuffer into video memory the driver will copy it into a d3d texture. I can't imagine why it would be anymore complex than that.
I just wonder how quad buffered stereo is going to work....and gen-locking, for that matter.

dorbie
08-10-2005, 09:42 AM
Hlz, the multi-GPU compositing is cool, but not as cool as it could be.

At SGI I came up with a plan to implement a "physical incarnation of a BSP tree", where compositing would use destination alpha and sorting muxes for a tree of binary compositors.

Initially I couldn't convince the great & the good there that it would render correctly (it's trivially obvious that it would). I wrote up a patent summary on it and they sat on it for years without wanting to proceed with the filing process :-)

So imagine a binary tree of sorted compositors where you can dedicate a rendering subsystem (pipe/card) to each leaf in the scene and draw the leaf contents & composit in any order for any viewpoint to produce a correct image on the screen. Data set size also scales linearly with pipes for stuff like volume rendering.

All you need to do to determine composit order in the tree is test the eye against the plane equation for than switching compositing node. It was a beautiful thing, and a significant improvement on more complex designs.

knackered
08-10-2005, 10:45 AM
I'm not sure what you mean dorbie. Are you talking about each leaf node renders, say, a geogroup in a scenegraph, from different points of view into buffers, then composite the appropriate render into the final scene?

dorbie
08-10-2005, 12:25 PM
Exactly, a leaf is held on a system with a graphics pipe, for something like volume rendering you store a region of the volume in texture memory locally on the card. Of course that's not a hard limit you can hold more on each leaf e.g. for stuff like animation. You can zbuffer within a leaf etc, and even clip between leaves along BSP boundaries, the important thing is that the planes (hardware switching video compositing nodes) define the boundaries between the leaves. Now, some of this is similar to the way the existing compositor works (or was intended to) but it's fugly the way they've built it compared to my BSP and a binary hardware tree design.

To recap, imagine a classic BSP where each leaf is a graphics card and each plane is a switching compositor (using video alpha), your software to run the thing becomes trivial and applications can easily exploit it with very minimalist middleware support.

Hlz
08-10-2005, 06:41 PM
Dorbie, that sounds extra cool. I like anything with trees in it :-). I like the idea of taking the problem to the streets, as it were. It really makes sense, with a clever node/leaf/zone manager. A wired version of this thing would make for some heavy metal kick ass.

On a slightly different tack, I'm reminded of some research done at UNC, quite a few years back, where they had what amounted to a dedicated GPU for each pixel on the display (or maybe it was just a 4x4 block). I don't know where that research went, but it sounded promising albeit somewhat expensive at the time (1995?). They had a demonstration simulation of several highly detailed F-15 jets flying in formation and it looked great, very smooth.

Jan
08-10-2005, 11:31 PM
Originally posted by Hlz:
I like anything with trees in it :-).Yeah, me too :D
Especially forests :cool:

tranders
08-11-2005, 08:11 AM
Originally posted by knackered:
I'd imagine that in the end, using opengl in a windowed app will be exactly the same as now, except instead of blitting the framebuffer into video memory the driver will copy it into a d3d texture. I can't imagine why it would be anymore complex than that.
I just wonder how quad buffered stereo is going to work....and gen-locking, for that matter.... or high precision accumulation
... or overlay planes
... or ...

I agree with you -- it shouldn't be that hard to connect the OpenGL buffer to a Direct3D surface. The graphic card vendors could all implement an extension that lets the application make the connection:


HANDLE WGL_TRA_BindContextToSurface(HGLRC hRC, LPD3DXCONTEXT pCtx);
void WGL_TRA_ReleaseContextBinding(HANDLE hCtx);These objects are known to the driver (LDDM, DDI, ICD, etc.) and there would only be minimal D3D setup required. The tricky part would be to implement a reliable way to get to the ICD without it being installed (i.e., I seriously doubt that the extension mechanism in "OpenGL on D3D" would pass that on to the driver). I think this is the enhanced "security" that Aeroglass is "providing". Depending on which side of the politcal spectrum you are on, one person's idea of security is another person's idea of protectionism :)

-- tranders