Someone said in a forum I read, that the OGL drivers on windows, make use of D3D calls.
Can anyone dismiss or support this statement with concreete proof?
Google give lots of crap, but a guy on that forum gave a link to a newsgroup post from 2001 that said that the OGL dlls are dependant on the D3D ones. Since I don’t have windows, I can’t check that, but I guess that the OGL dlls provided by MS can be dependent like that. Question is, doesn’t the manufacturer provide it’s own dlls for windows OGL support?
This is entirely untrue. Graphics card manufacturers supply their own implementations of OpenGL within their drivers. It is this implementation scheme that makes the use of wglGetProcAddress necessary for using anything in OpenGL above version 1.1.
Now, what you may have been reading about was WineX. This software allow graphics programs written for windows using DirectX to be run under Linux by translating the D3D code into OpenGL calls.
If that’s not the case, then the post you read was an out and out lie, written by someone that simply didn’t know what they were talking about, or part of a larger conversation that you haven’t seen.
leeman’s first paragraph is correct but it’s not complete.
On WinXP, MS redid opengl32.dll, what was once a software implementation of GL 1.1
It is a wrapper that makes D3D calls.
Of course, if you have drivers installed from a manufacturer, opengl32.dll routes GL function calls to the video driver which may or may not be a wrapper.
3D labs, NVidia, ATI and other don’t use a wrapper. Matrox uses a wrapper.
I don’t know any others.
Originally posted by V-man:
[b]leeman’s first paragraph is correct but it’s not complete.
On WinXP, MS redid opengl32.dll, what was once a software implementation of GL 1.1
It is a wrapper that makes D3D calls.
[/b]
Almost . On XP there’s a very limited OpenGL-over-D3D implementation, which normally kicks in only when you play quake3 or similar.
For the rest of the cases, you get the usual software GDI implementation .
[b]
Of course, if you have drivers installed from a manufacturer, opengl32.dll routes GL function calls to the video driver which may or may not be a wrapper.
3D labs, NVidia, ATI and other don’t use a wrapper. Matrox uses a wrapper.
I don’t know any others.[/b]
There’s another datapoint here, some Win9x ICDs use DirectX functionality. For example, I believe Nvidia required DirectDraw for their ICD to work (I had to suffer a problem related to that , only fixed when you ran some D3D app before any OpenGL app, others had the same problem).
The reason to require DirectDraw I believe is related to the need to lock the frontbuffer to avoid race conditions with GDI when rendering to the frontbuffer, although in some implementations it may also be used to deal with the video memory in general (DirectDraw used to provide a video heap manager).
IIRC Microsoft’s implementation also makes use of DirectDraw in order to render to the frontbuffer (you can easily see that opengl32.dll depends on ddraw.dll, maybe that’s what the reference of the original poster meant).
“detect process name” sort of thing? I’m gone try it for myself sometime.
Overall, MS has been making changes to opengl32.dll at every OS release.
It’s only in win2k and future OSs that opengl32 has a dependency on ddraw.dll
I guess there is a boost when blitting or whatever it does on the Ddraw surface.
Note, Mesa has support for ddraw on Windows.
Using ddraw to allocate buffers is not necessarily a bad thing. It won’t hinder GL’s performance.
DirectDraw used to provide a video heap manager
Yes, I have heard that many vendors make use of it. The links you have there are all true.
Originally posted by V-man: “detect process name” sort of thing?
Maybe
Overall, MS has been making changes to opengl32.dll at every OS release.
It’s only in win2k and future OSs that opengl32 has a dependency on ddraw.dll
Completely right, in Win9x they use an ancient and almost forgotten interface called DCI ( Display Control Interface ) as you can see by the dependency on dciman.dll. I think that it’s because Win9x by default doesn’t come with DX/DDraw installed, while XP/2K both install and initialize DirectDraw at boot time.
I guess they also use the 16-bit lock to achieve Win9x serialization (archeological note).
I guess there is a boost when blitting or whatever it does on the Ddraw surface.
Exactly, the advantage is that you can lock the DirectDraw primary surface (the desktop) and access it directly rather than having to rely on GDI to perform blits from your software render buffer to the desktop.
Note, Mesa has support for ddraw on Windows.
Using ddraw to allocate buffers is not necessarily a bad thing. It won’t hinder GL’s performance.
Re using DDraw for locking the frontbuffer, the problem is that you cannot lock the primary surface for a long time, so they must be locking and unlocking the surface continually. This causes serialization with GDI, so we could say that it’s not the best approach for high speed rendering.
Re Mesa, I know it used to work in Windows, but I’m not current on how uptodate the windows layer is (the last time I looked at changelog of the windows files it was kind of ancient). One of my plans is to give it a spin sometime and hack a bit the source for some evil purposes.
“Do not use this function; use the latest DirectX Graphics interfaces to communicate with your DirectDraw-supported driver instead.”
Exactly, the advantage is that you can lock the DirectDraw primary surface (the desktop) and access it directly rather than having to rely on GDI to perform blits from your software render buffer to the desktop.
Accessing it directly, means beeing able to read and write to video memory? If they are using ddraw in their sofware implementation, I think they have to render to main memory, then blit to a ddraw surface.
Note, Mesa has support for ddraw on Windows.
Using ddraw to allocate buffers is not necessarily a bad thing. It won’t hinder GL’s performance.
Re using DDraw for locking the frontbuffer, the problem is that you cannot lock the primary surface for a long time, so they must be locking and unlocking the surface continually. This causes serialization with GDI, so we could say that it’s not the best approach for high speed rendering.
Re Mesa, I know it used to work in Windows, but I’m not current on how uptodate the windows layer is (the last time I looked at changelog of the windows files it was kind of ancient). One of my plans is to give it a spin sometime and hack a bit the source for some evil purposes.
In terms of ddraw, I don’t think they would change anything, but it’s up to date in terms of support for GL 1.5, ARB_vertex_program, ARB_fragment_program.
The cool thing is with the shaders, it means they generate instructions in heap memory.
Just to throw a monkey wrench into the discussion, Scitech has a product (GLDirect, see www.scitechsoft.com/products/ent/gld_home.php)) which apparently routes OpenGL calls thru DirectX.
The only reason I bring it up is, back in the dark ages (1997 or so) not all hardware-accelerated video cards supported OpenGL, but a number supported DirectX. To get hardware acceleration for OpenGL games, the trial version of Scitech GLDirect sped things up a bit.
. On XP there’s a 