Zeckensack is right – nobody in their right mind should attempt to bypass the OpenGL driver mechanism provided by the OS. Especially not in order to support hardware that will never have another driver update again (3dfx), or to make use of an OpenGL implementation that was discontinued a long time ago (SGI).
You obviously haven’t read the whole thread… Just before I jump to the point, I’m not being abusive, Korval is simply just starting to get annoying. He keeps changing the thread’s focus, and misleads the topic, and other people trying to read the thread to think things that are not only wrong, but completely off topic.
Now, to get to the point .
Originally posted by zeckensack: I think a far better way of solving this all is just wrapping a few hundred wglGetProcAddress calls into a library, rather than trying to replace the ICD loading mechanism.
That is EXACTLY what I am suggesting. I’m saying we should write one wrapper library using wglGetProcAddress calls. So you’ve just basically (even though you didn’t intend to, took my point of view). Although I was thinking of making it a bit more cross-platform (you know, by doing glx calls under linux etc.)
The only thing is that I am suggesting that we do this for the full OpenGL library, not just the extensions. And by doing it that way, we can support all current cards via opengl32.dll, or earlier cards by a custom dll name that can be supplied.
Originally posted by zeckensack: Now you could argue that you just would load NVOGL.DLL yourself and hope that it falls back to software itself. But …
Well, obviously you wouldn’t tell it to load NVOGL.DLL, that would just be stupid, you’d tell it to load opengl32.dll cause that implementation will know how to use the nvidia ICD. The only time when changing it away from opengl32.dll would be for cards that doesn’t support opengl32.dll.
And even then, I’m just saying that is one of the advantages to dynamically loading opengl32.dll. I never said that is why we should do it. But that idea seems to be dominating the chat now, and all I wanted was an OK, go do it from the ARB.
Originally posted by zeckensack: the ICD isn’t even designed to know about pfds
Yes I know, that’s why I said “it’s part of the GDI”… again, why does the topic keep going to the PFD’s? Nothing changes, most of us will still keep loading opengl32.dll, in which case it would be functionally equivalent linking with the library using the current headers/lib file. So even if OpenGL is dynamically loaded, it will still know it should be forwarded to the nvidia based ICD (because opengl32.dll would handle that ‘automatically’)
All I was saying was that that was ONE of the advantages of dynamically loading the dll. For me, the main advantage is the ability to easily add on to the header without breaking compatibility with software based on earlier versions of OpenGL (apart of having to call an init function, but we may even be able to bypass that somehow… possibly by making it a statically linkable library, but that is undecided). The other main advantage is that we would be able to then build an official OpenGL SDK, something that is sorely needed in my opinion (please note the ‘in my opinion’ comment).
I mean, you guys want to compete with Direct3D, and functionally OpenGL is great, but things are getting more complex, but nothing seems to be done about it, so it is essentially getting harder for beginners to get into using OpenGL’s more advanced (and fun) functions simply because there is no generic OpenGL sdk, and the headers are horribly outdated. The biggest thing Direct3D has going for it is its complete SDK, that is what is attracting most (Windows) programmers to use it. By building not only better and more complete headers, but also combining that with an official SDK with demos etc, we could boost OpenGL’s popularity and ultimately, help the ARB to get even a larger portion of the market.
I’m just saying that it’s time to jump out and make OpenGL even greater than it already is. And now, with GL2 underway, that is good, but I can already see them releasing GL2 as a collection of extensions. So it might as well be OpenGL 1.6, cause we’d still be using the 1.x header. And until someone steps out of the crowd and says, let’s make a new header file, thing’s are gonna stay this way up to OpenGL 10 (whenever that might be) by which time all functionality will basically have to be dynamically loaded at runtime anyways.
Originally posted by Tom Nuydens: nobody in their right mind should attempt to bypass the OpenGL driver mechanism provided by the OS
I never said that, that’s why I don’t want Korval posting to this thread, he keeps changing the topic of the thread. Or rather, says something that makes someone else say something else and pretty soon afterwards, people are putting words in my mouth. No one’s changing the way the ‘driver mechanism’ works.
We’re only making it dynamically load opengl32.dll instead of linking directly to it. This is done as an attempt to regain control over the OpenGL headers, help in making things more cross-platform compatible (by not requiring different methods of loading the core GL functions), and would help modernize the OpenGL headers. And ultimately, if we act quickly, we’d be able to make a set of OpenGL 2.0 headers. With the amount of core functions constantly increasing, and the API getting more complex, I believe it is important to build a standard set of official headers and possibly a more complete (generic) SDK to help bring OpenGL into the future.
Originally posted by Tom Nuydens: you could have written your own in the time that you spent here argueing with Korval.
LOL. Indeed . But I actually indend on writing the majority of it myself, all I wanted was really aproval from the ARB, and perhaps help in getting a small team together who could help in keeping things cross-platform compatible. And obviously others who could test the new headers, give feedback, that kind of thing.
And just to repeat myself, we’re not changing the way the os chooses the driver or anything dodgie of that sort, we’re not changing the way pfd’s work, if you call the init function with no implementation dll specified, it will automatically load the OS default, and nothing changes.
Thanks for your feedback, and I hope that helped clear things up.
DJ
[This message has been edited by DarkJedi (edited 03-07-2003).]
Korval, I’ve already wasted enough time on you, I skimmed over your posted message, and you’re wrong on every account.
Every account? Well, I wrote:
What you’re looking for is an alternative OpenGL32.lib that allows the person to select a .dll.
And, later, you wrote:
That is EXACTLY what I am suggesting. I’m saying we should write one wrapper library using wglGetProcAddress calls. So you’ve just basically (even though you didn’t intend to, took my point of view). Although I was thinking of making it a bit more cross-platform (you know, by doing glx calls under linux etc.)
The only thing is that I am suggesting that we do this for the full OpenGL library, not just the extensions. And by doing it that way, we can support all current cards via opengl32.dll, or earlier cards by a custom dll name that can be supplied.
Since said library would replace OpenGL32.lib, but provide the same (and greater) functionality, it is exactly as I said. So, unless you want to change what you say you want, I am, indeed, correct that what you’re looking for is an alternative OpenGL32.lib that allows you to select a .dll.
As such, I was not wrong on all accounts.
And I really don’t believe you’ve dynamically loaded any dll’s. It sure as hell doesn’t seem like it from the stupid arguments you put forth.
Your beliefs do not change reality.
And again, for the second time, it doesn’t magically load the right dll, it loads opengl32.dll and expects it to handle the rest, unfortunately some cards don’t work via opengl32.dll.
So, allow me to understand something. When I link to OpenGL32.lib, and set the correct pixel format and request a render context, OpenGL32.lib (or something that it does behind the scenes that I, personally, don’t care about. If linking to OpenGL32.lib causes it indirectly, it is still the cause) does not, in fact, go out and load the nVidia GL implementation? So, all this time, I’ve been getting hardware acceleration on Microsoft’s GL implementation. Microsoft must be constantly updating their implementation, then, since it has been exposing all kinds of nVidia extensions for years now.
I’m aware of the sequence of events that cause a GL implementation to be loaded. And yes, it does happen magically behind the scenes when I link in OpenGL32.lib. I don’t care if that causes the load of 50 .dll’s, 40 .exe’s, and a bunch of COM-based garbage. If linking to GL32.lib causes my code to, eventually, link its implementation to nVidia’s GL, then linking to OpenGL32.lib causes me to link, eventually, to nVidia’s GL.
As for no one using Mesa… You are aware that mesa is the most widely used OpenGL implementation under the linux platform right? I hope you don’t bother replying but I can already see you saying ‘Why should we support the linux platform’.
Actually, I was going to say, “What alternatives to they have on Linux to Mesa?”
Not only that, is passing no .dll to the Linux implementation of this library you want to create reasonable? I mean, OpenGL32.dll is a reasonable default for Windows, but does Linux have a similar mechanism?
So please, stop dominating this thread with incorrect, and meaningless crap. If you don’t want to load OpenGL dynamically (not like you even know what that means) then don’t reply to this thread. You don’t have a clue what you’re doing, and you haven’t done the research I asked you to do before replying again.
Some of us actually have things to do, so unless you have anything correct and intelegent to say, please stay out of the conversation. And keep your replies short and to the point because random rambling just wastes my (and everyone else’s) time.
Try and actually post something constructive for a change (to some other thread please).
Random rambling? Take a good look at your first post. What does any of that have to do with making a library to dynamically load OpenGL? Indeed, you only mentioned dynamic loading in your fifth post. You spent the vast majority of your first posts talking about “headers” and so forth that have very little to do with the actual question at hand. Any library needs to have header files shipped with it, but header files don’t necessitate, or imply, a library.
We’re only making it dynamically load opengl32.dll instead of linking directly to it. This is done as an attempt to regain control over the OpenGL headers, help in making things more cross-platform compatible (by not requiring different methods of loading the core GL functions), and would help modernize the OpenGL headers. And ultimately, if we act quickly, we’d be able to make a set of OpenGL 2.0 headers. With the amount of core functions constantly increasing, and the API getting more complex, I believe it is important to build a standard set of official headers and possibly a more complete (generic) SDK to help bring OpenGL into the future.
#1: Why are the GL headers not “under control”? GL implementations have the right to expose whatever extensions they want. And, I believe that they don’t necessarily have to bow to the ARB to get approval for them. As such, you can never have full control of the headers for any particular implementation. People are still going to need their glExt.h or glATi.h.
#2: What does dynamic loading of OpenGL32.dll have to do with control of the headers? These are two relatively independent concepts. Sure, you need a header to define the appropriate function pointers for your dynamically loaded function pointers, but other than that, these concepts are fairly separate.
#3: OpenGL 2.0 is not nearly in a state to have headers, let alone a library that will load function pointers (especially since we don’t even know whether OpenGL32.dll will support 2.0). When the GL 2.0 spec is finalized, then, and only then, will you be read to write your headers and make your library (though the second part may depend on what Microsoft chooses to do or not do with GL32.dll).
#4: With all this talk of dynamic loading of GL, what about those platforms that statically load GL? Say, an SGI-box that statically links to its GL implementation. Or some other UNIX machine that may statically link to GL? Your library and header files (because they define function pointers rather than functions declarations) are useless to them. It may work on Win32 and Linux, but other platforms find this library useless.
But I actually indend on writing the majority of it myself, all I wanted was really aproval from the ARB, and perhaps help in getting a small team together who could help in keeping things cross-platform compatible.
Considering #4, I doubt you’re going to get ARB support. But you don’t really need ARB support. You just need to update your library with every driver update that exposes new extensions from every vendor.
I still contend that this functionality doesn’t belong in official GL distributions.
Well, you’ve asked some intelegent questions this time, so I’ll actually answer them (I was planning to not bother replying anymore). But I guess people can surprise you.
Every account? Well, I wrote:
What you’re looking for is an alternative OpenGL32.lib that allows the person to select a .dll.
Well, not really sure that would work, as I said, it could be implemented as a static library, well, possibly, although I can’t say I’ve tested this myself.
It would more likely be a .h and a .c that handles it, although, as I said, not really sure on that one. Either way the functionality supported by the new headers has to be easy to add compatibility for other OS’s.
But yes, that is the basic idea, either a replacement .lib that loads the GL dll you specify, or a .c that replaces linking to the .lib
And I really don’t believe you’ve dynamically loaded any dll’s. It sure as hell doesn’t seem like it from the stupid arguments you put forth.
I still don’t believe you’ve completely dynamically loaded the GL libraries, it’s just that you keep saying things that argue with you actually trying it.
So, allow me to understand something. When I link to OpenGL32.lib, and set the correct pixel format and request a render context, OpenGL32.lib (or something that it does behind the scenes that I, personally, don’t care about. If linking to OpenGL32.lib causes it indirectly, it is still the cause) does not, in fact, go out and load the nVidia GL implementation? So, all this time, I’ve been getting hardware acceleration on Microsoft’s GL implementation. Microsoft must be constantly updating their implementation, then, since it has been exposing all kinds of nVidia extensions for years now.
It will basically ‘forward’ the commands to the right driver (ICD), yes… But not all cards support the opengl32.dll file, as in, not all of them have an ICD for it.
Again, just commenting on your extension joke, if we did this, I wouldn’t aim to support vendor specific extensions, unless there is a really big demand for it. It is mostly about core functionality. I would however, expose our extension loading mechanism so people could create more portable applications by getting the pointers via a standard set of functions that work on ‘all’ platforms.
And hopefully, eventually, I’d get around to updating the docs, and modernising them, and if everything goes right, we may have a real OpenGL SDK in a few years time… One that concentrates on the core functionality. (As microsoft has done for Direct3D for years now)
Actually, I was going to say, “What alternatives to they have on Linux to Mesa?”
Well, that used to be true, however, nowadays, nvidia has their own implementation. If you link directly to it, your application will require libGLcore or something arather (which is an nvidia specific library). Or something along those lines.
I mean, OpenGL32.dll is a reasonable default for Windows, but does Linux have a similar mechanism?
To some degree, yes, I’d say the default would be to load mesa since that is widely used under linux. Since I’m mostly a Windows programmer I’m not too sure, but I do know that you can specify your GL library to use for X, so I guess you could retrieve that information somehow, but I’d leave that up to the linux guru’s to figure out.
Random rambling? Take a good look at your first post. What does any of that have to do with making a library to dynamically load OpenGL? Indeed, you only mentioned dynamic loading in your fifth post.
No, I said:
“I would suggest making a gl2.h for people to include which automatically gets pointers to all the core functions”
That is called dynamically loading OpenGL…
#1: Why are the GL headers not “under control”? GL implementations have the right to expose whatever extensions they want. And, I believe that they don’t necessarily have to bow to the ARB to get approval for them. As such, you can never have full control of the headers for any particular implementation. People are still going to need their glExt.h or glATi.h.
Again, this has nothing to do with extensions, it is about core functionality, so the driver will continue to add additional functions as extensions as it has been done over the last few years. The headers are not ‘under control’ because right now, they are not being updated. So when OpenGL 4 or something comes out, we will still probably be using the 1.x headers, have documentation up to OpenGL 1.1, and no SDK with good examples of the core functionality.
This is an attempt to gain back this control, and start updating the headers again to support the core OpenGL functionality.
#2: What does dynamic loading of OpenGL32.dll have to do with control of the headers? These are two relatively independent concepts. Sure, you need a header to define the appropriate function pointers for your dynamically loaded function pointers, but other than that, these concepts are fairly separate.
Well, since you just about have to dynamically load the entire GL library anyways (because so much functionality has been added since OpenGL 1.1), you might as well dynamically load the entire library and bypass some problems on the current headers in the process.
That is one way of looking at it, the other, and the way I like looking at it, is good coding practice. If we just started bunging on core functions as pointers in the current headers, we would create a huge mess in the OpenGL headers, it is much better to rewrite them and do everything the same way. See, if we just added on to the current ones it won’t help in readability, nor will it help with maintainability.
But yeah, technically you could just add on to it, but as I said, it is better to just rewrite it.
OpenGL 2.0 is not nearly in a state to have headers, let alone a library that will load function pointers (especially since we don’t even know whether OpenGL32.dll will support 2.0). When the GL 2.0 spec is finalized, then, and only then, will you be read to write your headers and make your library (though the second part may depend on what Microsoft chooses to do or not do with GL32.dll).
Well, I hate to burst your bubble, but I don’t think there will be a gl2.dll. They can add GL2 support to the ICD’s just like extensions can be added. And I’d say that would be the way they’ll do it. I don’t really see them creating a new lib/dll/headers for the OpenGL library. GL2’s functions will (and I’m 99% sure) be exposed via extensions. Just like everything has been done for GL 1.x
So we just have to wait for the specs, then add the supported core functions to the new headers.
#4: With all this talk of dynamic loading of GL, what about those platforms that statically load GL? Say, an SGI-box that statically links to its GL implementation. Or some other UNIX machine that may statically link to GL? Your library and header files (because they define function pointers rather than functions declarations) are useless to them. It may work on Win32 and Linux, but other platforms find this library useless.
Most of the platforms do support dynamically loading OpenGL, but yeah, there is definately a chance that there is a dodgie platform that doesn’t support it. But of course nothing stops a person from sticking to the original headers. If worse comes to worse.
Of course if that happened, a person could always release a functionally equivalent header for that platform.
Considering #4, I doubt you’re going to get ARB support. But you don’t really need ARB support. You just need to update your library with every driver update that exposes new extensions from every vendor.
Yeah, getting ARB support would be difficult, and probably time consuming, but I want them to think about it at an ARB meeting. If they want to compete with Direct3D they have to be willing to take on its SDK head on. As I’ve said, that is basically what Direct3D has going for it.
If I got enough people on a team, creating such an SDK would be possible, this would include new headers, new documentation (based on the original docs), examples, and possibly a few graphics papers. But all aimed at core, non-extended OpenGL.
I still contend that this functionality doesn’t belong in official GL distributions.
Well, what official GL distributions??? That is the entire problem, there is no general GL SDK’s, or anything, we’re running on old headers, with outdated documentation, no official example code that demonstrates the newest added functionality.
So in my opinion, an official SDK is something that is sorely needed. And the first step is to create new headers that are easily extendable. And that is my proposal, we need to do this, then think of other things like updating the documentation and such.
I didn’t really want to bring the second step into the conversation till the new headers were finished, but I’ve pretty much spilled it all out now.
Wow, this is an entire essay!
Sorry I was so hard on you,
DJ
[This message has been edited by DarkJedi (edited 03-07-2003).]
I really don’t understand why this post turned into a huge argument about how to load function pointers.
I didnt read the entire thread, but if you read my first post (at the very top), I said that a new lib and dll would be nice.
I’m not saying opengl32.dll and opengl32.lib and etc should be replaced with updates.
A new dll, lib and h should be provided.
It’s sort of a fresh start.
Average Joes who want to run 2.0 software & games should get the new dll and update their drivers.
That’s what people with Win95 did!
So in this case, driver development for pre-2.0 would freeze, and a new version will be provided.
Companies just supply the pre-2.0 and post 2.0 drivers with their setup.exe
Thanks for your post V-man… Although a replacement dll would have been nice there are some drawbacks to that approach.
For one thing, you couldn’t then support GL2 as an optional feature. So if Doom 3 decided to use GL2 then it would require GL2… whereas, it is better if it can still fall back and use OpenGL 1.x.
So there are pretty big advantages of doing it the dynamic loading way, as apposed to forcing the user to have gl2.dll or whatever…
.