Thats really unfair and ugly.
It seems MS is REALLY afraid in competition - so instead of just building the best operating system they use their dominance to kill all other competitors and force developers to use ONLY their APIs.
Please write to NVIDIA, ATI and whoever that they should create preasure on MS that this won’t happen.
lg Clemens
Originally posted by Korval:
The generic implentation has always been a fall-back implementation anyway. It was never intended to be used as the primary implementation on shipping products. And the fact that this implementation is clearly superior to their previous one is cause for celebration.
While the software rasterizer is not recommended for production work, it is in many cases the only pixelformat that will allow high-end applications to work on certain graphics configurations. If Vista does not provide a software rasterization pathway, then ALL OpenGL applications will be at risk regardless of the selection of “OpenGL on D3D” or a native ICD. The primary need for the software OpenGL rasterizer is not for the production workers - it’s for the managers and field personnel that don’t have access to the latest and greatest hardware; the graphics vendors have either discontinued support for the graphics cards or are not capable of supplying decent support for any 3D graphics technology. WRT laptops and mobile workstations, the graphics drivers are almost always unsupported by the graphics card vendor and support has to come from the OEM vendor (i.e., the laptop manufacturer). These drivers are rarely up to date and tend to lag weeks or months behind the latest patches from the graphics vendor. While the primary graphics card vendors produce excellent drivers and are usually very quick to respond to major problems, they are not perfect and there will continue to be bugs in the drivers that will prevent an application from running. It is naive to believe that there are no similar bugs in D3D.
Originally posted by rtargosz:
- When I left, the driver supported over 80% of OpenGL 1.4, with plans to continue implementing support for extensions most used by the target applications. We were even able to run Doom 3 in some limited modes over 6 months ago (some functions were NULLed out for testing).
Given that quote, it is simply speculation that the “OpenGL on D3D” implementation will even be sufficient for “non-targeted” applications. It is easy to get an application run if over 20% of the graphics engine does nothing – you just don’t get to see 20% of your data
– tranders
Support may never be up to snuf on Windows Vista so…
Why not put in more requests/pressure to get the PS3 platform to support MacOS X (Tiger and beyond) and Linux. This platform is a huge win for OpenGL and with(if) Mac and Linux support is there a general purpose platform to boot. I’ve read that the capability is there (Mac/Linux hard drive…) and I wouldn’t think sony/ibm/toshiba would be against it either.
To far fetched?
I don’t think that a few games (10 at most?) that don’t work on WinVista will stop MS from doing it’s move, but, WILL Doom 3 engine based games run well on windows vista???
About Maya and other high-end GL apps, probably MS will release something like WinVista Workstation that will include the ICD. What do the video card industry people think about this???
As independent game developer, I was looking forward to develop average/budget games for Windows/Linux/Mac. Naturally OpenGL is only, and for me preferred solution. If IHVs don’t see future of their decisions, let it be. Do I have to write for each platform in its own 3D API??? Where is this industry going, wake up it’s 2005.
I don’t see why should I write emails, like there is no importance in OpenGL - open and portable standard that is only D3D competitor on windows, and winner on all other platforms - so we all have to “write” to them to “support” and “backup” something. And if enough emails arrive, they will consider it. It is ridiculous. I just don’t get the point of writing to you. If you are brain dead, my letter is surly not going to change that fact.
And I had nothing against Microsoft before this Vista crap. XP really works fine, has OpenGL, DirectX tons of free libraries and friendly development environment. You can do what you like on it. And now, suddenly, all that has to change? Now, I really see Microsoft and Vista as cancer in computing society. So IHVs use your brain, or don’t use it. If it has to come to this – for us to write you emails - than you simply are morons and should consider changing your management staff or who ever got this idea. Do whatever you like.
Originally posted by Korval:
The generic implentation has always been a fall-back implementation anyway. It was never intended to be used as the primary implementation on shipping products.
You can’t describe an OpenGL implementation as a fallback if there’s nothing to fall back from. Users think of the OS as being the GUI. If installing an ICD switches off a major feature of the GUI then ICDs will be viewed as a nasty hack that cripples their OS. You cannot tell users to cripple their OS just to run your app, hence the ICD route is strictly for hobbyists and specialist apps.
Originally posted by Korval:
And the fact that this implementation is clearly superior to their previous one is cause for celebration.
I’m not breaking out the champagne just yet. The GL->D3D shim will be good enough to maintain compatability with existing apps (Maya etc), but also clearly signposted as a dead-end to discourage any further OpenGL development.
Like I said in a previous post, the best way I can see to discourage Microsoft from taking this route is by getting facts on the ground ASAP - apps that refuse to run on less than 2.0.
If a user runs a GL2 app on Vista and it breaks the GUI, they’ll think the app’s broken. But if they see the app working fine on XP first, they’ll think that Vista is broken. And Microsoft really dislikes people thinking of their products as broken.
Both you and korval are both being clowns, you both advocate Microsoft’s current OpenGL Vista strategy as positive, when the majority of the people here making articulate posts do not.
So? Just because a lot of people are on one side doesn’t make them right.
And I am not advocating the current Vista strategy. I just don’t see it as the end of the world that so many alarmists on this forum think that it is.
I also don’t think that it’s going to matter to Microsoft or the IHVs what we think too much. The IHVs are both aware of the situation (the actual situation, as opposed to what keeps getting tossed around here), and they want to provide a solution for it. They may get Microsoft’s help (it has not been said if they’ve asked for it yet) or they may have to figure it out on their own from a more stable version of Vista. In either case, once they fix it, it’s fixed.
People who have already invested their time in developing their apps past openGL 1.4 on windows are going to get screwed by this, myself included. Anyone developing windows using Aero will not be able to take advantage of OpenGL past 1.4.
See, that’s the problem with this whole issue. There’s so much disinformation out there that people say things like this, which are just not true.
The only part of Aero that is affected by the use of an ICD is desktop compositing. That’s all. The rest works just fine. So, in the absolute worst case, what we will see in the shipping product (as opposed to the beta product combined with XP drivers we see today) is that the activation of an ICD deactivates desktop compositing.
The primary need for the software OpenGL rasterizer is not for the production workers - it’s for the managers and field personnel that don’t have access to the latest and greatest hardware; the graphics vendors have either discontinued support for the graphics cards or are not capable of supplying decent support for any 3D graphics technology.
Your lamentations of not having a Microsoft-provided software OpenGL 1.1 implementation do not concern this issue. MesaGL is still out there, and it is well past 1.1 (and it’s faster than the old Microsoft generic implementation). If people want to use it, they are free to do so. The fact that the generic implementation is no longer software based is pretty much irrelevant to this discussion.
I can understand that you don’t like it. And I can understand that there is a class of people for whom this will create problems. But this class of people is largely tiny and not terribly relevant. Plus, the Microsoft generic implementation was almost certainly not bug-free, so not terribly much changes in this case.
Lastly, people using not-entirely-advanced hardware probably aren’t going to switch to Vista to begin with, so there’s not even a problem.
You can’t describe an OpenGL implementation as a fallback if there’s nothing to fall back from. Users think of the OS as being the GUI. If installing an ICD switches off a major feature of the GUI then ICDs will be viewed as a nasty hack that cripples their OS. You cannot tell users to cripple their OS just to run your app, hence the ICD route is strictly for hobbyists and specialist apps.
You are aware, of course, that every time someone downloads the drivers (D3D and OpenGL) from an IHV, they’re getting an ICD with that, yes? So they will have ICDs whether they wanted to have them or not. Every game sold, as part of the readme or other instructions, say to update your drivers to the latest revision for your graphics card. Granted, not too many people actually do, but it’s still there and it’s still recommended.
So people are going to have ICDs and it is up to applications as to whether to use the ICD or the generic implementation. There’s almost always going to be something to fall back from.
Originally posted by Korval:
[b]You are aware, of course, that every time someone downloads the drivers (D3D and OpenGL) from an IHV, they’re getting an ICD with that, yes? So they will have ICDs whether they wanted to have them or not. Every game sold, as part of the readme or other instructions, say to update your drivers to the latest revision for your graphics card. Granted, not too many people actually do, but it’s still there and it’s still recommended.
So people are going to have ICDs and it is up to applications as to whether to use the ICD or the generic implementation. There’s almost always going to be something to fall back from.[/b]
Ah, that sounds ok. I was assuming that Vista would need to reboot into a regular XP-style GUI to enable ICDs, but it sounds like you’re saying that only the compositor needs to be stopped and that this can be done on-the-fly. You have concrete information that this is the case?
And yep, I’m aware of what an ICD is and how they’re distributed.
And I am not advocating the current Vista strategy. I just don’t see it as the end of the world that so many alarmists on this forum think that it is.
It is apparent that you downplay this issue. If the topic is not important to you, why do you answer and post with such carefully chosen words? If some people take some action which affects other people in a negative way, of course a reaction can be expected. Company execs are not pleased of these additional costs given by Microsoft, and I hope they solve the problem with a one-time investion relieving them from such surprises in the future: Porting their professional graphics apps to another OS! It is easy for customers to change the OS of one of their workstations from Windows to Linux, as most of them already use those systems. It is well known that Microsoft pays lobbyists to turn matters to their favor, but I think this time it is very difficult to cover their motivation. They would argue as you do, but we have already seen that such an attempt would be uncovered easily.
I also don’t think that it’s going to matter to Microsoft or the IHVs what we think too much. The IHVs are both aware of the situation (the actual situation, as opposed to what keeps getting tossed around here), and they want to provide a solution for it. They may get Microsoft’s help (it has not been said if they’ve asked for it yet) or they may have to figure it out on their own from a more stable version of Vista. In either case, once they fix it, it’s fixed.
If it is fixed, we had luck. But you cannot bet on it. Users do not like a degraded visual experience, and most of them do not understand the issue deeply enough to know who is responsible. They assume a coding error in the application and call their application vendor. Even if they are told by them who is responsible, they expect the application vendor to solve the issue. This is not amusing, that is why I would tell the customers that the next version of the application runs perfectly on Linux, so that the customers can choose among options they deserve to have.
Your lamentations of not having a Microsoft-provided software OpenGL 1.1 implementation do not concern this issue. MesaGL is still out there, and it is well past 1.1 (and it’s faster than the old Microsoft generic implementation).
Mesa is slower than D3D with hardware acceleration, other comparisons are irrelevant to the user experience. OpenGL is not inferior technology but appears to be, because Microsoft has found a way to play a foul using uncompetitive means. nVidia’s OpenGL implementation gives this API an edge, and Microsoft cannot help other than to forbid their new desktop to cooperate.
I can understand that you don’t like it. And I can understand that there is a class of people for whom this will create problems. But this class of people is largely tiny and not terribly relevant. Plus, the Microsoft generic implementation was almost certainly not bug-free, so not terribly much changes in this case.
Lastly, people using not-entirely-advanced hardware probably aren’t going to switch to Vista to begin with, so there’s not even a problem.
This shows very clearly your motivation. You want to distract the readers from the main issue. The Microsoft generic implementation is not important, no one in the professional graphics or games field wants to use a software-only renderer today. If you count the OpenGL applications which do not have a D3D rendering path, and then add the companies using OpenGL in-house for some components, I would not say the class of people being concerned is irrelevant.
You are aware, of course, that every time someone downloads the drivers (D3D and OpenGL) from an IHV, they’re getting an ICD with that, yes? So they will have ICDs whether they wanted to have them or not. Every game sold, as part of the readme or other instructions, say to update your drivers to the latest revision for your graphics card. Granted, not too many people actually do, but it’s still there and it’s still recommended.
Of course they can download the ICD, and many gamers do, as the original driver is not up to par. But then they have a degraded user experience when starting an OpenGL application (disabled composition manager), already forgotten? Of course, some glitches are not important, I know… Sort of a blue screen of the application, destabilizing the system… Very funny indeed!
Gamedev.net has a remark from ati dev who thinks this is going to be fixed and become a non-issue. I agree with him because barthold from 3dlabs also mentioned this not being an imposiblity to fix. If MS really wanted to kill gl they would have blocked arb from using their IP rights while back.
This issue reminds me of Y2K precisely because we didn’t have enough info about possibility of fixing it and how hard or easy that would be. So people pre-empted to doom and issue became overblown. I remember a tv interview with a guy who build a shack and stuffed it with food and survival gear and in the end Y2K came and gone w/o problems.
(Sorry that this is my first post here, but this topic really disturbs me)
Does anyone else here think that Microsoft might just be over-stepping their boundries a little bit? I mean after all it has already been recognize that Microsoft will use it's monopolistic hold on the OS market to crush it's competitors .
If so then it seems like now's the time to take action especially since unlike previous years Microsoft is actually losing court cases against them . I mean it’s obvious enough that this uneccesary restriction against OpenGL is soley aimed to force hardware and software developers to only use DirectX, this same/similiar thing didn’t go too well for Internet Explorer or Windows Media Player .
Either way, this seems like the opportune moment for the Linux community to get working hardcore on some major innovations, or at least a nice distribution aimed toward regular users . If only they could get good enough media coverage and such to let everyone know they exist.
Then again I could just be another typical “Anti M$ Hippie”…
Originally posted by Korval:
[b]Your lamentations of not having a Microsoft-provided software OpenGL 1.1 implementation do not concern this issue. MesaGL is still out there, and it is well past 1.1 (and it’s faster than the old Microsoft generic implementation). If people want to use it, they are free to do so. The fact that the generic implementation is no longer software based is pretty much irrelevant to this discussion.
I can understand that you don’t like it. And I can understand that there is a class of people for whom this will create problems. But this class of people is largely tiny and not terribly relevant. Plus, the Microsoft generic implementation was almost certainly not bug-free, so not terribly much changes in this case.
Lastly, people using not-entirely-advanced hardware probably aren’t going to switch to Vista to begin with, so there’s not even a problem.[/b]
First, MesaGL is far from being a polished, professional graphics library that would pass muster against an ISO9000 audit. If you’ve never had to deal with one of those beasts, then you know nothing about professional application development. MesaGL would be an absolute last resort simply because of the added headache of delivery, support, and maintenance. FWIW, it is not as fast as the current OpenGL 1.1 software rasterizer in many ways and while there are “issues” with the current generic offering, they are well defined and avoidable. If you don’t know how to work around these problems, then you know less than you believe about that implementation.
I think your estimates on how many people could be affected by this is understated. One single engineering software company recently announced 2 million active desktop users. That company represents only a fraction of total users and only represents a fairly narrow scope of the total market. Relatively speaking, the people that would be affected by the lack of a decent fallback scenario is significantly less than that, but it is worth noting that those people are the ones that are selling the software or making the decisions about what to buy and when.
Windows XP is being sold TODAY on less-than-capable machines and some high-end applications still require those machines to run in software OpenGL – even if they are only being used for reviewing data. I would not expect those conditions to change when they start shipping with Vista. To think otherwise is naive.
–tranders
It is apparent that you downplay this issue.
I think there are enough end-of-the-world scenarios and conspiracy theories going around the web already on this issue; I don’t feel the need to add to them.
If you feel that I am specifically downplaying the issue, perhaps it is you who are “up-playing” it? Perhaps I’m looking at it from a cold, rational perspective and you’re in ther camp that wants to say that this is the most horrible thing ever and it will destroy OpenGL.
It is well known that Microsoft pays lobbyists to turn matters to their favor, but I think this time it is very difficult to cover their motivation.
And therein lies the problem. You hate Microsoft, so you are senstive to anything that Microsoft does that affects you in any way negatively. Couple that kind of attitude with the rampant exaggeration of the facts of what this problem entails, and you have mass hysteria.
Since you’re utterly convinced that your position is right, you see any less inflamitory position, irrespective of arguments, to be that of an appologist.
There’s got to be a sociology paper in this somewhere.
OpenGL is not inferior technology but appears to be, because Microsoft has found a way to play a foul using uncompetitive means.
Even if your statement against Microsoft is true (and it is purely conjecture at this point, as there are plenty of rational reasons why interfacing OpenGL ICDs to Direct3D runtimes would be something that ICD developers would have to work out), that statement has nothing to do with the actual problem. How it got there is not terribly relevant (except in how it relates with the problem at hand), and attacking Microsoft is of no value. The purpose should be finding a solution.
Your personal hatred of Microsoft has nothing to do with the problem.
This shows very clearly your motivation. You want to distract the readers from the main issue. The Microsoft generic implementation is not important, no one in the professional graphics or games field wants to use a software-only renderer today. If you count the OpenGL applications which do not have a D3D rendering path, and then add the companies using OpenGL in-house for some components, I would not say the class of people being concerned is irrelevant.
Let me get the facts straight, because I fail to grasp the logic of what you’re saying.
Right now, we have ICDs and the generic implementation. ICD’s are hardware, the generic implementation is pure (crappily written, I might add) software and frozen at GL 1.1. Buggy as well.
What Vista will give us is ICDs and a new generic implementation that is frozen at 1.4, and is hardware based and therefore faster than before.
Ignoring for the moment the issue of deactivating desktop compositing due to using an ICD (which is a separate issue and, according to JD, will likely be fixed, thus truly becoming a non-issue), your argument in this passage seems to be that advancing the generic implementation to 1.4 and making it fast enough to be useable is… bad?
Is it full D3D speed? No, of course not. But nobody was complaining about the speed of the generic implementation before. If you only had one apple before, and someone offers you five, it seems inappropriate to tell them off for not giving you 9.
Tranders has an actual point about needing an implementation that simply functions and not wanting the generic implementation to be based on the vagaries of hardware drivers. Though I might suggest that it is equally dubious to expect OS code to be either rock-solid stable or to never change (particlarly Microsoft code).
First, MesaGL is far from being a polished, professional graphics library that would pass muster against an ISO9000 audit.
Are you, by chance, suggesting that Microsoft’s OpenGL implementation would pass such an audit? Because that seems unlikely for a piece of code that hasn’t been updated in upwards of a decade.
If you don’t know how to work around these problems, then you know less than you believe about that implementation.
If a company is willing to work around problems in the generic implementation just to get their GL app up and running on it, it stands to reason that said company has the development time to work around a different set of problems in MesaGL. Both Mesa and the 1.1 software implementation are stable (Mesa particularly so when you decide not to update it). Plus, since Mesa’s source is available, they can actually go and fix the problems that they’d rather not work around. Not an easy thing in all cases, of course, but that’s beside the point.
Microsoft never committed to providing a rock-solid stable software implementation for people to rely on (particularly when that reliance is on buggy functionality). The only reason they didn’t pipe their 1.1 stuff through D3D is because D3D didn’t exist at the time. Microsoft is interested in performance in terms of graphics, and performance comes from driver dependence. If a developer needs driver-independence, they should have been using a real software implementation.
What if Microsoft said that they were changing their generic implementation to be MesaGL? If they were just going to take the Mesa source and plop it down as their generic implementation? What if Microsoft were to make bug fixes to their implementation that makes workarounds break?
Reliance on someone elses code, particularly when you have no assertions or guarentees that this code will never change, is just begging for trouble.
They’re going to have to accept the switch to a faster renderer that may not be as obviously stable in some ways. I’m going to have to learn an entirely new API for interfacing with Windows. We all have stuff to do when faced with major OS changes. It’s a fact of life; get over it.
I don’t see why anyone would want to update to Vista anyway. I don’t see any significant difference between XP and Vista, and I find that my Linux distro. works miles better than any Microsoft product ever has.
The only people likely to update to Vista are Universities or Businesses who have a contract with Microsft to receive their latest software. I doubt home users will go out of their way to buy a copy of Vista, as what is Vista going to do that XP doesn’t already do for them?
Most PC games companies will produce games with the knowledge that the majority of their consumers will be running XP and not Vista. What is more from Microsoft’s point of view Vista is not an operating system for playing games. That’s what the Xbox is for. It is reckoned that Microsoft plan to sell the Xbox OS for you to install on your home PC so you can play Xbox games will improved resolutions and frame rates and such. Besides this, both Nintendo and Sony use OpenGL for their hardware. Sony’s Cell processor and GPU is OpenGL based.
It is completely wrong of Microsoft to implement OpenGL in the form of a wrapper for DirectX but I doubt this move will have any serious dent on the use of OpenGL. I personnely doubt Vista will be such a popular incarnation of Windows anyway.
But the answer is simple. Don’t use Vista, use the system and the distribution that suits YOUR OpenGL needs, not the needs of Microsoft. If you HAVE to have Vista installed to use a particular application or play a particular game then I guarantee you that that piece of software ISN’T worth buying and ISN’T worth using.
Originally posted by rtargosz:
… Whether it will also lose share in the rest of the ISV world is entirely dependant on the ability of the ARB to innovate…
How?
If there is no GL support beyond 1.4 and extensions
are disabled, the ARB can innovate what they want;
It wouldn’t work on M$ in windowed mode…
using GL would mean crippled windows compared to D3D
yeah, it’s entirely up to the ISVs and the ARB
:rolleyes:
I have been reading in PCFormat that AMD has sued Intel becuase they have been paying retails to only have amd proccessors amount to 10% of the market sales, isn’t that what microsoft are doing with graphics card manufacturers? so if this happens are they liable to be sued?
I think getting ride of openGL support will impact windows massively becuase lots of game use GL eg Half life 2
Originally posted by Korval:
Right now, we have ICDs and the generic implementation. ICD’s are hardware, the generic implementation is pure (crappily written, I might add) software and frozen at GL 1.1. Buggy as well.
What Vista will give us is ICDs and a new generic implementation that is frozen at 1.4, and is hardware based and therefore faster than before.
Of course it’s better to have accelerated OpenGL 1.4 (though with worse performance that the same 1.4 drivers on XP) than software OpenGL 1.1. What this topic is about is that on earlier MS products, vendor ICD’s provided an enhancement of the system by bringing hardware acceleration and new extensions at no cost. Now, on Vista, the hardware ICDs doesn’t integrate seamlessly on the OS anymore, and furthermore disable vital parts of the OS in order to run while they are installed.
The fact is that before, MS OpenGL software implementation was an aid in the rare cases an ICD were not installed, while MS Vista’s OpenGL 1.4 implementation is designed to be the first one to use and to fall back to hardware ICDs only in rare cases. Even MS’s 1.4 is far better than MS’s 1.1, the former is far worse than any actual hardware vendor GL driver. That’s what is wrong.
Originally posted by Korval:
Right now, we have ICDs and the generic implementation. ICD’s are hardware, the generic implementation is pure (crappily written, I might add) software and frozen at GL 1.1. Buggy as well.
The OpenGL 1.1 softare implemenation was written by SGI as the official OpenGL reference port. Microsoft simply ported that into Windows with little or no modifications. I’m not sure why you think it is poorly written simply because it is 10 years old and hasn’t been updated to support the current feature set of 1.5 or 2.0. I have personally used its inherent stability to prod graphics card vendors to fix bugs in their drivers.
What Vista will give us is ICDs and a new generic implementation that is frozen at 1.4, and is hardware based and therefore faster than before.
It has yet to be determined if “OpenGL on D3D” will provide any implementation that could be considered GENERIC in the current meaning of the word (i.e., software only and isolated from hardware or other external sources of “interference”). Speed is not what is at issue here.
Though I might suggest that it is equally dubious to expect OS code to be either rock-solid stable or to never change (particlarly Microsoft code).
EVERY OS is “expected” – even required – to provide rock solid and stable code, otherwise no application would ever survive beyond a single service pack. OpenGL has been a core technology since Windows NT 3.51 (which was IMO the first usable NT version), so there is every reason to expect this support to continue.
Are you, by chance, suggesting that Microsoft’s OpenGL implementation would pass such an audit? Because that seems unlikely for a piece of code that hasn’t been updated in upwards of a decade.
Precisely. OpenGL is an open standard that is supported by bylaws and review board directed controls. These are the types of things that ISO9000 auditors live for and are what puts it light-years ahead of MesaGL. Guaranteed quality control and documentation are crucial to this type of certification – neither of which exists with MesaGL (no malice towards Brian Paul who I think has done an admirable thing).
If a company is willing to work around problems in the generic implementation just to get their GL app up and running on it, it stands to reason that said company has the development time to work around a different set of problems in MesaGL.
You fail to grasp to purpose of a failsafe scenario. The workarounds are not to get the application to work – they work just fine with full ICD acceleration – the workarounds are to make the application function reliably under the worst possible conditions – a catastrophic failure of the 3D graphics subsystem (e.g., a buggy or unsupported driver, unexpected conflicts caused by other applications, etc.). Attempting to do the same with MesaGL is vastly more demanding for reasons previously described.
Microsoft never committed to providing a rock-solid stable software implementation for people to rely on (particularly when that reliance is on buggy functionality).
That is exactly what Microsoft promised as long as high-end professional applications would be willing to port their OpenGL applications to the Windows platform. That promise is on the verge of being broken.
I’ve said enough about this so I’ll stop.
–tranders
It is completely wrong of Microsoft to implement OpenGL in the form of a wrapper for DirectX but I doubt this move will have any serious dent on the use of OpenGL.
Why? The DirectX wrapper isn’t the problem (unless you’re Tranders); it’s the interaction between ICDs and desktop compositing that is the problem in question. For the most part, the D3D wrapper is a good thing, as Azdo accepts.
Apple provides a wrapper for their OpenGL too. They implement many parts of OpenGL, thus allowing their IHVs to write… less complicated GL drivers. This functions very similarly to how D3D works on Windows. There’s the OS-provided half of the code, and there’s the IHV-provided driver. The difference is, besides the GL/D3D differences, that IHV’s can expose extensions under AppleGL, while D3D doesn’t (yet. Microsoft apparently wants to allow this in the future) allow such things.
It would actually not be a bad idea for Microsoft to do with OpenGL what Apple does. That is, drop the ICD mechanism entirely and just convert the GL calls into graphics driver calls. It’s different from being a D3D wrapper, because D3D is also talking to the graphics driver. It would be lower-level and therefore faster, but it would have the same performance penalties of D3D (that being that the Microsoft-provided code does marshalling, so any glEnd-equivalent call will provoke a driver call. IHV ICDs can avoid this by doing more intelligent, hardware-specific marshalling).
If there is no GL support beyond 1.4 and extensions
are disabled, the ARB can innovate what they want;
It wouldn’t work on M$ in windowed mode…
Please read the thread. There is quite a bit of misinformation in your post, and this thread corrects it.
What this topic is about is that on earlier MS products, vendor ICD’s provided an enhancement of the system by bringing hardware acceleration and new extensions at no cost. Now, on Vista, the hardware ICDs doesn’t integrate seamlessly on the OS anymore, and furthermore disable vital parts of the OS in order to run while they are installed.
ICDs do still integrate into the OS just fine. And they don’t “disable vital parts of the OS” when they are installed; they only disable desktop compositing, and only when they are activated. Anything else is misinformation.
Remember: ICDs come with graphics drivers. And people (particularly gamers) will still be updating their graphics drivers regularly. Driver developers will not be shutting down parts of the OS just because a user decided to install their drivers.
I have been reading in PCFormat that AMD has sued Intel becuase they have been paying retails to only have amd proccessors amount to 10% of the market sales, isn’t that what microsoft are doing with graphics card manufacturers? so if this happens are they liable to be sued?
No. This is nothing like the AMD/Intel case.
OpenGL is not a company; it is a specification. So, even if this were a coordinated attempt to stimy GL development on Windows (a point that I do not conceed), it is not a violation of any anti-trust laws because it has little to no effects on a company. Seeking to inhibit people’s uses of a specification on a platform is not against the law.
The fact is that before, MS OpenGL software implementation was an aid in the rare cases an ICD were not installed, while MS Vista’s OpenGL 1.4 implementation is designed to be the first one to use and to fall back to hardware ICDs only in rare cases.
That is also misinformation/erronous. The ICD mechanism is not changing. It will not suddenly start turnning accelerated pixel formats into generic pixel formats. If your app has been getting accelerated pixel formats, and an appropriate driver has been installed on the machine, it will still get accelerated pixel formats under Vista.
It is only in the cases where a user gets (or a program wants) a generic pixel format that they will get this expanded version.
It has yet to be determined if “OpenGL on D3D” will provide any implementation that could be considered GENERIC in the current meaning of the word (i.e., software only and isolated from hardware or other external sources of “interference”). Speed is not what is at issue here.
The term “generic” in terms of the ICD mechanism and GL’s implementation on Windows has meant the Microsoft-supplied OpenGL implementation. It has never meant “software”, and to assume that it has to is wrongheaded. It is simply the default implementation for the cases when no ICD is installed.
Does MacOS have a generic implementation at all, software or otherwise? I know all its graphics work is done through OpenGL, and I know that, as long as hardware drivers are installed, all windows will be rendered through those drivers. I also know that Apple writes part of the implementation on Macs, thus providing MacOS IHVs with an internal API (plus extension support) that they build their drivers to.
As such, I’m not certain it does. After all, since all drawing commands go through GL, it would be exceptionally slow to draw lines, etc through software OpenGL rather than through a special-case, 2D-based renderer.
Does Linux provide a generic implementation, software or otherwise? I don’t think it does, though some distros ship with MesaGL.
If neither Linux nor MacOS provide software fallback implementations, if they both can accept the vagaries of IHV drivers, why shouldn’t Windows do the same? They’re already providing more by providing any kind of generic fallback. Why force them to make a slow one?
That is exactly what Microsoft promised as long as high-end professional applications would be willing to port their OpenGL applications to the Windows platform. That promise is on the verge of being broken.
I’ve never heard of this alleged promise. Even if they did, there are more important things at stake here. Besides, if neither Linux nor MacOS provide a software GL, what were they relying on before Windows? I’m willing to accept Microsoft breaking this alleged promise. It’s not like the ISVs have someone else to turn to (besides MesaGL).
First I apologize to the group for breaking my promise to stop responding, but …
Originally posted by Korval:
The term “generic” in terms of the ICD mechanism and GL’s implementation on Windows has meant the Microsoft-supplied OpenGL implementation. It has never meant “software”, and to assume that it has to is wrongheaded. It is simply the default implementation for the cases when no ICD is installed.
Here’s a quote directly from Microsoft’s own current documentation for DevStudio 2003 regarding the PIXELFORMATDESCRIPTOR:
PFD_GENERIC_FORMAT
The pixel format is supported by the GDI software implementation, which is also known as the generic implementation. If this bit is clear, the pixel format is supported by a device driver or hardware.
PFD_GENERIC_ACCELERATED
The pixel format is supported by a device driver that accelerates the generic implementation. If this flag is clear and the PFD_GENERIC_FORMAT flag is set, the pixel format is supported by the generic implementation only.
© 2002 Microsoft Corporation. All rights reserved.
I believe that’s pretty clear language describing the generic implementation. BTW, I find that it is always useful to do a little bit of research so that I get my facts straight before responding to posts.
–tranders
