DX10 on XP, through OGL wrapper?

[Hector]

But in OGL you have to deal with propietary extensions and the fact that the OGL Api takes years to move to a new version which adds support for the features that are available through direct x (how long did it take to make ARB official?).

 

[retrox]

Right.. what a shame though that they didn't think of that before MS decided to fix theirs...

Right. And what a shame it took MS 10 revisions of their API to realize that a switch to kernel mode for draw calls was not the smartest thing to do.

 

[retrox]

But in OGL you have to deal with propietary extensions and the fact that the OGL Api takes years to move to a new version which adds support for the features that are available through direct x (how long did it take to make ARB official?).

(by ARB I assume you meant VBO)

I think there is some contradiction here.

On one hand, OpenGL proprietary extensions are the _fastest_ way for developpers to access new functionnality (no need to wait for MS next API overhaul). Depending on the type of audience targeted by the application, it can be a very valuable option.

On the other hand, it is true that OGL standardization process is slower than D3D. It can be seen as an advantage or a disadvantage. The good thing is that new OGL versions most often do nothing but incorporate proven existing multi-vendor extensions in the standard. This ensures that a) there is enough support for standard features, and b) these features are actually usefull to a significant number of OGL applications. The bad thing is of course that until it happens, developers are left with the extension mechanism.

 

[Rodéric]

The bad thing is of course that until it happens, developers are left with the extension mechanism.

Which you cannot escape on Windows anyway since OpenGL DLL is never updated (that could help OpenGL get some market share).

 

[retrox]

Which you cannot escape on Windows anyway since OpenGL DLL is never updated (that could help OpenGL get some market share).

Technically yes, but I was more refering to the fact that it's easier to target say OpenGL 1.5 or 2.0 than 1.1 + ARB_multitexture + ARB_VBO + ARB_multisample + ...

The OpenGL DLL problem under Windows is more of a strategic risk than a real technical obstacle. Hardware and software vendors have been circumventing this "feature" for so long now. The risk is that MS ditch OpenGL altogether. They tried to do it with Vista. Thankfully the community and hardware vendors fought for decent support of OpenGL under Vista. Maybe they'll try again for their next OS.

See what is happening in the hardware-accelerated audio world. With direct sound 3D being software only in Vista, Creative has no other choice but to implement their hardware acceleration driver outside DirectX (OpenAL driver). And then write a wrapper to map DirectSound calls to OpenAL so that DirectSound applications (read: the vast majority of games) can use hardware acceleration. That's fine some might say. Well, the fact is that it's certainly not an easy task, it costs money to Creative, and it's not clear if anything that's not X-fi-class hardware will ever get this wrapper. People with Audigy hardware might very well find themselves with a nice set of DACs instead of a powerful DSP. [ /not so much offtopic ]

 

[Xmas]

Then you didn't get the point. GPU doesn't need to do multithreading between applications, but between rendering tasks. In simple terms -- say that in order to render the next frame it needs a texture with higher level of detail which is not in local memory and it stalls waiting for DMA transfer to finish.

In the meantime you turn sharp 180° in your shooter because a zombie is attacking you from behind. With DX10.1 GPU will not wait for above mentioned texture to load but will jump to render what is behind you, because it already has all textures/data in memory for that view.

Without DX10.1 your game will freeze for a split second and you will be dead.

That doesn't make sense at all. The GPU has always been free to do pretty much whatever it deems necessary to hide latency (but the number of frames that may be buffered is actually limited).

This multithreading is not about hiding latencies, it's indeed about giving multiple render contexts (usually multiple applications) each their fair share of the GPU.

EDIT:
Lets not forget that game developers want to sell their games and they can't expect to sell many copies if the game is DirectX 10 only. So they will have to maintain two code paths -- one for DX9 and one for DX10. Of course, the only sane alternative to that madness is to ditch DX completely and start writing OpenGL game engines with portability in mind. Once games start appearing for Mac and Linux those platforms will gain wider support both from IHVs and from end users.

Developers who want SM4 level effects in their games need two "code paths" for OpenGL, too.
And Microsoft's FX framework helps a lot with the transition. Having two renderer paths isn't really that much of a problem.

But in OGL you have to deal with propietary extensions and the fact that the OGL Api takes years to move to a new version which adds support for the features that are available through direct x (how long did it take to make ARB official?).

The original target date for OpenGL Mt Evans is October 2007. So wth a bit of luck we will see OpenGL catch up less than a year after D3D10 public availability. Several D3D10 features are already available through EXT extensions.

The OpenGL DLL problem under Windows is more of a strategic risk than a real technical obstacle. Hardware and software vendors have been circumventing this "feature" for so long now. The risk is that MS ditch OpenGL altogether. They tried to do it with Vista. Thankfully the community and hardware vendors fought for decent support of OpenGL under Vista. Maybe they'll try again for their next OS.

Microsoft could ditch OpenGL, but that doesn't prevent IHVs from offering OpenGL drivers.