Drivers instead of Implemntation

With the upcoming GL 3.0 and even with the concurrent robust fullfeatured versions, it would be great to have a more professional and robust interface to the core functionality. While giving the new framework/API the context and windowing management functionalities, the core API should be available as a separate driver provided by IHVs. The OpenGL centralized context manager service is respoinsble for:

Context Creattion and Management

Windowing system interaction

Default software implementation fully supporting the latest specification

Access to the hardware acclerated core features when the ICD driver is installed.

The generalized gl context service is implemneted and maintained by ARB/Khronos…

It should provide a minimal hardware driver interface specification to make it easy and trivial for hardware vendors to write DRIVERS instead of IMPLEMENTATIONS.

Khronos doesn’t have, you know, programmers, who would be required to develop and maintain the client-side code. Plus, the OpenGL ARB’s having enough of a problem making one specification. Producing a spec for IHVs and for programmers is more than they can actually do.

Lastly, let’s not forget that D3D tried the whole “IHVs only write driver code” thing, and it didn’t work very well for high-performance cases. IHVs are the only ones who can do marshalling in a performant manor. And that is why D3D10 changed the model, allowing IHV code client-side.

so OpenGL outperforms D3D?

so OpenGL outperforms D3D?

If that is your bottleneck, then yes. Though, as I pointed out, D3D10 has it too.

You mean something like this?

Default software implementation fully supporting the latest specification

I don’t want any “defaults”. I don’t want any fallbacks to software mode. If they can make a sample implementation, that’s cool.

It should provide a minimal hardware driver interface specification to make it easy and trivial for hardware vendors to write DRIVERS instead of IMPLEMENTATIONS.

If there was a “sample implementation”, this would be possible.

Maybe off-topic but i got a question regarding this OGL vs D3D thingy, sorry if the question is so… naive.

What was the idea behind D3D? I mean, there is an open standard api called OGL, which you have been part of, hence you can change/add anything you want. Then you leave and make another api and then stop supporting OGL. It is not same but there is a similar(?) example. C++ and C#, while a lot of people using C#, MS implementation of C++ compiler is one of the best if not the best.

What I exactly mean something like Mac OS X interface to OGL. A Unified Context Manager and Windowing System Interfacing API.

What was the idea behind D3D?

The idea behind D3D was to make a fast, low-level interface to graphics hardware. OpenGL wasn’t that, and that was what Microsoft felt they needed. Also, there’s the fact that DirectX was something Microsoft was working on: low-level interfaces to 2D blitting, sound, and input hardware. It seems a little silly to have all of those pieces in one API set and then have to go to OpenGL for 3D graphics. Especially if you want to leverage some 2D blitting through DirectDraw in your 3D application (something that OpenGL made impossible to be fast).

which you have been part of, hence you can change/add anything you want.

That’s patently untrue. Microsoft couldn’t simply will OpenGL into changing things. Look how much time and effort it’s taking to make a new API. Or even how long it took to get basic render-to-texture support through FBO. Microsoft wouldn’t have made that process any smoother.

The fact is that OpenGL changed too slowly for what Microsoft wanted to do, and couldn’t interface with things Microsoft wanted it to interface with. And it wasn’t as low-level as Microsoft wanted it. So they “made” (D3D v3.0, the first version, was purchased by Microsoft) D3D.

Since we switched the topic to why D3D ever exist, I would like to add that D3D has been approaching OpenGL in every version and I again anticipate this and you guys gonna find it someday in the DX Doc, D3D has been deprecated and we recommend using OpenGL instead, the same as what happened to DirectDraw, DirectPlay…LOL

Blitting never been accelerated only by DirectDraw, fake. Prove it? Textured screen quads outperforms blitting.

Vista runs a significant amount of the IHV code in the user space. This is true for all Direct3D versions if you have a WDDM driver. But these DLLs still contains a driver that implements a driver interface and not the Direct3D API. While some of the functions in this interface looks quite similar to the Direct3D methods other are complete different. I can go in the details but if you don’t write drivers by your own it is somewhat boring.

The history of the 3D part of DirectX is another confusing story. At this time DirectX was owned by the Windows 9x team. They were aware that there is a need to support 3D as part of DirectX but they although known that they haven’t not enough man power to create a complete API by their own in short time. There first idea was using the OpenGL implementation from Windows NT. But the Windows NT team wasn’t willing to give it away. You may need to know that the Windows NT and Windows 9x team doesn’t like each other to understand this. Still in the need of a 3D software package they buy RenderMorphics. As their software was somewhat higher level than a 3D API the first versions of Direct3D contains a complete scene graph called “retained mode”. The lower level part called “immediate mode” looked more like some kind of abstraction layer for different hardware and maybe it was a modified version of this from RealityLab (the software that RenderMorphics had done before). Developers don’t like it because it was too complicated and the retained mode was to slow and inflexible.

Over the time the retained mode was removed and a modified immediate mode becomes the driver interface that was used by a new runtime. Unfortunately this driver interface was never build with the system design from Windows NT in mind. And therefore it resulted in a high call overhead there.

On the Mac, they have added all sorts of features but they come as agl functions. agl functions are considered part of the Mac’s API.

I’m not sure if he above information is true about D3D. It’s typical of MS to want to control the industry and to put others out of business. It is my understanding they wanted to control the 3D market so first, GL came to NT. But that wasn’t enough for them. They needed to create D3D in order to become dictators. That’s my interpretation.

It is true. You should consider something else that is typical for Microsoft. They are always late on the party not to say they are the last.

I’m not sure if he above information is true about D3D. It’s typical of MS to want to control the industry and to put others out of business.

So, you believe Microsoft is the badguy; therefore, you must interpret everything that happens from that perspective. You’re basically starting from the conclusion and then building the reasoning behind it.

They needed to create D3D in order to become dictators.

And precisely what kind of dictatorship did they get with Direct3D? They can’t specifically dictate to IHVs exactly what they put into it. They have to work with IHVs to develop the featureset for each version of D3D.

I mean, look at D3D 8. Pixel Shader Models 1.0 through 1.3 were basically nVidia’s NV20 hardware. Pixel Shader Model 1.4 was basically ATi’s R200 hardware. That’s not Microsoft dictating to anyone; that’s ATi and nVidia telling Microsoft what their API would look like.

So exactly how much of a dictator is Microsoft in terms of 3D hardware?

Just to interfere with off-topic now, MS is not dictating. Their products are appealing to developers, that’s all.

And about using D3D over OGL in game industry, think of it like this. I’m developing an engine, it gonna run under Windows, it gonna use DirectInput, DirectSound, and OGL??? Come on, lets the code be more consistent and it’s already using the “ugly” COM thing, so there will be no big deal preferring D3D.

  • Misinformation Alert *

What he means that back then, when you made use of some features like stencil or accumulation buffer, it would run super slow.
They coded the missing parts of the GPU in software.

D3D doesn’t offer a software fallback. So whatever feature it offers in its capbits is hw accelerated. It was limited, yet it was straight to the metal.

Direct3D 9 support software fallbacks but they need to be requested from the application.

The only software fallback that exists in the release version is vertex processing and yes, you have to explicitly request it.

Microsoft offers an additional software device for Direct3D 9 (not the ref rast). But as it is not part of the SDK this is not well known.