scrap opengl32.dll

[l_belev]

this is windows-specific

I was wondering what do we need opengl32.dll for?
today it only serves as a standard rendezvous point for the gl apps and the gl driver. other than that it is useless and only stays in the way.

Wouldn't it be nice if the ARB approve standard name for a new dll (say arbopengl.dll) that the HW vendors will place in the windows system directory (system32) along with their ICDs.
Of course we still will need to support the old path through opengl32.dll for backward compatibility.

Using the new dll, we may have new cleaner and up-to-date way to setup opengl contexts under windows.
for example:

int glWGetNumDevices();
BOOL glWGetDeviceDescr(int dev, GLWDEVICEDESCR &descr);
GLWContext glWCreateContext(int device, int *attribs);
BOOL glWMakeCurrent(GLWContext ctx);
GLuint glWCreateRenderBufferForWindow(GLWContext ctx, HWND wnd, BOOL single_buffered);
BOOL glWSwapBuffers(GLWContext ctx, GLuint rbuf, int vsync);

glWCreateContext can receive a zero-terminated attribute list that can specify things like minimal required opengl version, compatibility or core profile, etc.
These contexts will not have a default frame buffer.
Instead drawing to a window will be enabled by the function glWCreateRenderBufferForWindow. It returns name of a renderbuffer object (that can be attached to framebuffer objects and combined with depth buffers, etc.). Using glWSwapBuffers will show the current content of that renderbuffer object to it's associated window, automatically doing a vertical synchronization as specified by the vsync parameter. single-buffered ones may not be supported if that is a problem.

what do you think?

EDIT: ah yes, the format of the "window renderbuffers" can not be specified by the app. it is chosen by the implementation in unspecified way (e.g. it may be linked to the current windows video mode as set by ChangeDisplaySettings).
get rid of the pixel formats!

[glfreak]

I completely agree on scrapping the ancient OpenGL32.DLL along with the window-system dependent context management stuff.

However I think the problem is the mechanics of the window and context management and interaction with the HW is something requires licensing or a specification from the platform vendor since it involves the operating system internals, which they may not give away easily.

Another issue can be driver quality again. This means unless they they come up with a reliable and conformance test, drivers may screw things up at context initialization stage, which is terrible.

I would suggest an SDK approach, and I don't mean the current OpenGL SDK (wrappers + tutorials ). OpenGL implementation has to be layered on top of a minimal driver (provided by the IHV) and a software rendering path. The GL SDK should always default to the HW accelerated rendering path whenever possible unless a feature is missing, because the driver/hw is not up to date with the current SDK version, then it uses the software renderer.

[l_belev]

i doubt a licensing is required because the example of OpenCL.

on the question about the driver quality, i dont see how a new dll can change what we have now for the better or for the worse.
it's not like microsoft is requiring from the HW vendors to pass any conformance test when it comes to opengl. in all cases its entirely up to their good will.

[mhagain]

If you're going to suggest retaining a software fallback path, then PLEASE, and this is more important than scrapping a dll, PLEASE give developers a means of detecting in code when this path will be triggered. That's all I want.

[l_belev]

do you mean retaining the old microsoft software opengl implementation?
of course it is excluded. the new dll will have nothing to do with microsoft (as is is the case with OpenCL already).

[Alfonse Reinheart]

OK, let's say you were to get IHV support for this. How would you implement it? Microsoft controls Win32, which is the basis of all window rendering. Direct3D and WGL are both built on top of it. They only reason they can drill through the normal window drawing systems is because Microsoft put specific hooks in Win32 to allow D3D and WGL to drill through it and render to a specific location of the screen.

IHV's can control a lot. But they can't control the OS itself (which is why WGL and GLX are provided by non-OpenGL stuff). You cannot force a Windows window to be rendered via direct GPU commands, not without Windows being aware of it and mediating the process. Why do you think OpenGL32.dll exists to begin with?

The absolute best you might do is layer OpenGL on top of D3D, but that's going to come with its own deficiencies and issues.

OpenCL can end-run around this because it doesn't draw anything. It doesn't need to associate with Win32 in order to work; it talks directly to the driver. So the only way for what you suggest to work would be to have no default framebuffer at all.

That might be useful for some GPGPU applications. But I'm guessing that most people wanting to render stuff want to actually see it on screen.

[l_belev]

i don't think opengl32.dll really does anything important about the linking between opengl and the windowing system. a while ago i was doing some experimenting with the ICDs and i found they basically do everything on their own. All they need is some form of link to their kernel-space counterparts, which is not hard to accomplish at all.

i'm not very familiar with composition-enabled system but on XP and w7/vista with disabled compisition all that is needed is the client rect and the visible region of a window (the latter can be obtained with the GetRandomRgn function). then the driver just draws over that parts of the screen (the screen is ultimately under the HW driver's control anyway).

edit:
for the composition case maybe something like this may work: since the composition is done on the GPU, then the contents of the windows should be kept in some kind of textures.
then if our driver can find the texture that corresponds to a given window, it can do it's opengl drawing there. remember that the driver has the final word for any GPU resource, including this texture and microsoft's code can not possibly prevent (or even detect if the driver wants to hide it) the driver from drawing there.
then the driver probably will need to "invalidate" that window with some windows api in order to force the window manager to redraw it (doing it's composition) on the screen.

there is the "if" here that the driver can know which is the texture for given window. i don't know if it can obtain that info.

maybe it will not work for other reasons too. as i said im not familiar enough with how the composition works and what are it's relations to the driver.

[Hongwei Li]

opengl32.dll is light and almost does nothing. The reason it exist is it is the common library for all opengl programs and it is stable. While it is loaded, it then loads the ICD and then relies on ICD for the rest.

I agree removing opengl32.dll. My only concern who will provide the replacement. NVidia or AMD? It is a difficult question.

[l_belev]

opengl32.dll is light and almost does nothing. The reason it exist is it is the common library for all opengl programs and it is stable. While it is loaded, it then loads the ICD and then relies on ICD for the rest.

It is light that's true, but the obsolete interface it provides enforces very complicated and ugly opengl setup under windows.
here are 2 examples:
in order for us to use wglCreateContextAttribsARB we have to first create a dummy context with it's dummy window, get proc addresses, destroy the dummys. and only then we can create context in the new way.
also while some gl vendors provide some ways to choose among their gpus, there is no reliable inter-vendor way for that.

I agree removing opengl32.dll. My only concern who will provide the replacement. NVidia or AMD? It is a difficult question.

I think it should come with the ICDs. It should inquire about the installed ICDs (even the ones from other vendors) and should be able to load any and all of them at the same time. opengl32.dll can't load more than one ICD. it doesn't even let you choose which one.
The new dll should present to the application the collection of all gpus in the system from all vendors with unified interface.
Of course still only one current context per thread is allowed, but different threads in a process should be able to have current contexts from different vendors at the same time.
This is not hard to do at all. I was able to do it myself by directly loading the ICDs and using their exported functions (DrvCreateContext, DrcSetContext, etc.)

I imagine the new dll to be extremely tiny. It's only job is to find the ICDs (read from a very standard location in the registry) load each of them to get info about it's gpus and probably unload the unused of them.

Maybe we can even do without a central dll. We (the app developers) can just read the registry ourselves and load the ICD dlls. In such case it would suffice if the ICDs expect that they can be loaded directly (without opengl32.dll) and provide some better and up-to-date exported functions.
For example, one problem (though work-aroundable) is that in order to get any of the newer functions, you need to use DrvGetProcAddress, which without current context returns NULL.
Another problem is when some of the new functions (like UINT wglGetContextGPUIDAMD(HGLRC hglrc) receive as argument a opengl32.dll-ish context handle (instead of driver handle).

[Alfonse Reinheart]

This is not hard to do at all.

Then why haven't you done it? It sounds like you could write this as a simple wrapper library over WGL. So if it's "not hard to do at all," then go do it.

Maybe we can even do without a central dll. We (the app developers) can just read the registry ourselves and load the ICD dlls.

Because reading through the Windows registry for certain specific registry keys and manually loading DLLs is far less obfuscated than creating two windows. I'm sure it'll be lots easier to teach people which registry bits to poke at and which DLLs and functions to load than to just use OpenGL32.dll.