Jump to content
  • Advertisement
Sign in to follow this  
Foxito Foxeh

OpenGL About different OpenGL Versions

This topic is 862 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I've been working for at least half year in raw OpenGL by making calls to OpenGL32.DLL in windows System32 library. The problem is: I know there are different GPU drivers. Ones support some version of OpenGL, another ones superior versions and I know all support 1.x version...

 

The problem is: what versions do Windows use in OpenGL32.DLL
I have noticed there are a lot of versions from this library. When I used Windows 7 versions was 5 or 6, now in Windows 10 version is 10.0.

 

Are there some changes in OpenGL32.DLL versions? Since I program raw code scratch from library calls, can I use later versions (2.0 or 3.x) from this DLL? I mean, how do I know which are the functions OpenGL32.DLL has on each version? Do Windows 10 OpenGL32.DLL version 10.0.1 has OpenGL3 or 4 functions?

 

What are the disadvantages of using the OS core opengl library?

Why is it not recommended to use OpenGL 1.x? Do GPU companies will stop using it? What will happen to applications maden by calling OpenGL32.DLL?

 

I understand very good how OpenGL works but not how drivers and extensions work. (I have always used the standard 1.1, not extensions)

 

I tried searching information about different OpenGL32.DLL versions but all seem to point to old 2.0 which has very old documentation about it's bytecode functions. They're the basic ones from gl.h but... Where is the rest of the new versions code? Are there other OpenGL DLL's to use in extensions? For example, GLU32.dll is another one which offer quadrics and some complex 3D shapes but it also come natively in Windows System32 libraries. Are there other DLL's to enable Opengl 2.x and above use? I readsomething about GLEW. Do GLEW has a GLEW32.DLL file which comes native in Windows? Do this allows me to use different OpenGL versions? Do I have to install more stuff to enable it?

That's what I think is annoying from OpenGL. I don't want my app users to install extra stuff, everything should be already managed by the OS, as OpenGL1.1 does in OpenGL32.DLL on Windows. For example, DirectX natively comes in Windows with different versions (9, 10, 11) so I can directly program to it, but in OpenGL I still can't understand how to use different versions, and it's kind of annoying :c

 

I'd like to make raw calls to OpenGL but, where or how do I use new OpenGL 2.x, 3.x or 4.x functions?

Share this post


Link to post
Share on other sites
Advertisement
OpenGL32.dll does not implement OpenGL. It is just the interface between you and whatever the graphics driver offers (or, if no suitable graphics driver is installed the default implementation Windows offers).

Out of the box you will never have anything above OpenGL 1.1 on Windows (unless Microsoft change their policy on this which seems unlikely after all this time). In my personal opinion OpenGL 1.1 is completely useless to do anything interesting. It's missing important features and the only way it allows you to work is horribly inefficient and in a way that is far removed on how you would do anything today (or a decade ago).

So, on Windows you have to query everything above OpenGL 1.1 using the extension mechanism. Obviously you can do that by hand but that is a lot of boring work with a potential for really nasty and annoying errors. There are lots of simple helper libraries for this though, for example GLEW and glbinding immediately come to mind. Edited by BitMaster

Share this post


Link to post
Share on other sites

Ohh that's what I was trying to understand @mhagain, I didn't know how OpenGL driver worked, didn't know that OpenGL32.DLL is an invoker of GPU driver.

By performance, I really haven't noticed performance issues an I have achieved a lot of functionalities with 1.1 in modern (2013 - 2015) nVidia - Radeon - Intel APU/GPU's. It's not "one frame per second" as you said and I have done all by hand. Maybe there are some things you can't achieve so easily in 1.1 but I will discover it later.

I haven't tried to call OpenGL in a machine without GPU drivers to see if it's software emulated or if it doesn't work.

By what BitMaster said, I now undertand that the bytecode from the DLL is a common interface for GPU drivers. Thanks, that was really helpful from both of you. That was an interesting doubt I had but didn't find some information about it in google :P Thanks!

 

So if I really understood, actually what I'm doing when calling opengl32.dll, I'm invoking OpenGL driver from the GPU but not specifically version 1.1, but version my GPU driver support and that version still support some of the old API functions (As wglCreateContext, etc.) but not specifically 1.1 version, but 1.1 API functions over a different OpenGL version?
So that's why there's a lot of people on the net that say "Do not use 1.1 API functions", because now days, recent OpenGL drivers still support old 1.1 fuctions, but they will be removed cause they're deprecated.

So in summary: I'm not actually using OpenGL 1.1, i'm using the X version my GPU support but that X version still support old 1.1 functions and I'm calling them. Is that correct?

Share this post


Link to post
Share on other sites

As mhagain mentioned, the windows dll is just an interface that is used because microsoft thought over a century of computer technology far from today that it would by great to use OpenGL in there OS and as I remember correctly (I read an articel some years ago) then decided to fiddle on a similar graphics interface on there own that was in the first versions not even as performant as the similar GL implementation was but got better the reason because they had money and didnt let anybody else fiddle on it. On these days there own "super graphics" was born under the name Direct3D.

 

So the old GL support stayed in there for some reason (I think it is realy complicated to nearly impossible removing such 'Driver' interface from the system so they leaved it in) but and thats the difficulty on it, it does in fact do nothing when you have a newer driver installed from your GPU vendor.

The old 1.1 implementation is a software emulation of that what the GPU does. When you call the wingl dll to initialize, they will check if there is an alternative version of gl and load that into the execution space of opengl32.dll, otherwise fallback to the build in functionality.

 

When writing a dynamic linked library what the name says is, it is dynamic so you didnt have real functions that directly link to the dynamic code but function pointers managed by windows that will be bound during runtime when you initialiy first time call that function from your code. For example you call to opengls wglGetProcAddress function then there is something in your code that calls the dll handler of wglGetProcAddress that might look like this

PROC wglGetProcAddressEndPoint(LPCSTR name)
{
  if(!wglGetProcAddressPtr)
    dllHandler.LoadFunction("opengl32.dll", "wglGetProcAddress");

  return wglGetProcAddressPtr(name);
}

(psoydo code just to get a sight of how things work in the MS world)

 

So what does it do is to check if something is bound to the function pointer you were calling if if isnt then ask the dll handler to either load and/or return a function pointer to the memory location where the function was loaded to or crash if it wasnt able to load it.

 

In fact, using dlls take some kind of performance overhead (that is meaningless on any hardware newer than what you got in the 90s) checking every time that the function you were using is bound before calling into it.

 

This way the opengl32.dll decides if it needs to load the software emulation mode or could redirect anything iinto the GPU driver and let it handle anything else. That is the reason why you will get different results when calling something basic like wglGetProcAddress that is implemented into the dll source but returns results based on the gl implementation you qeury when context is created.

 

Thats also the reason why you need to call for a function pointer first that is marked as extension for the specific gl version you decide to use. The dll handler dosent know anything about that because it isnt implemented in the runtime code of opengl32.dll and is never called for that function even if some header file offers it to you. You will either get linker error or null pointer exception when directly call into it from your code.

 

I hope that helps a little understanding the process that goes on "under the hood" of the windows OS. If you work with different versions of GL I would advice to use a wrapper library because they do all the things the dll handler would normaly do but in a way that you dont need to worry about what is implemented into opengl32.dll and what is driver specific.

Share this post


Link to post
Share on other sites

Ohh that's what I was trying to understand @mhagain, I didn't know how OpenGL driver worked, didn't know that OpenGL32.DLL is an invoker of GPU driver.
By performance, I really haven't noticed performance issues an I have achieved a lot of functionalities with 1.1 in modern (2013 - 2015) nVidia - Radeon - Intel APU/GPU's. It's not "one frame per second" as you said and I have done all by hand. Maybe there are some things you can't achieve so easily in 1.1 but I will discover it later.


I strongly recommend against this. You will not learn much useful by working with OpenGL 1.1. You will learn some bad habits which will hinder you and need to be unlearned.

Share this post


Link to post
Share on other sites

I strongly recommend against this. You will not learn much useful by working with OpenGL 1.1. You will learn some bad habits which will hinder you and need to be unlearned.


This.
1000x this.

1.1 is dead.
It is gone.
It is the past.

GPUs have moved on and left it in the dust.
Hell, the term 'GPU' didn't even exist back when 1.1 was a thing.

Forget 1.1 and all the bullshit it brings to the table; 4.x is probably where you want to be, 3.x if you've a fondness for history.

But 1.1... god no... just no.

Share this post


Link to post
Share on other sites

 

4.x is probably where you want to be

 

 

when you want to be a stickler with that then you need to point to Vulkan!

Share this post


Link to post
Share on other sites
Not really.

Vulkan (and D3D12) is basically graphics development on Hard Mode.
Unless you need features of it, such as lower CPU overhead coupled with the ability to generate things across threads or a couple of GPU features, then sure go for it. However it also comes with a shit load of extra work you have to do and the trust that you know wtf you are doing - you can, and will, crash the GPU and at least to start with produce horribly performing code.

But OpenGL (and D3D11) still have their place and allow you to get a lot done without having to worry about basically writing a graphics driver and all the bullshit that goes with it.

Share this post


Link to post
Share on other sites

But OpenGL (and D3D11) still have their place and allow you to get a lot done without having to worry about basically writing a graphics driver and all the bullshit that goes with it.

Exactly this.  There will always be a need for some kind of API that exists at a relatively high level of abstraction and allows people to just make API calls without having to worry about the finer details or hardware-level ugliness that Vulkan and D3D12 provide.  Today that need is filled by OpenGL and D3D11.  In the future it might be a software wrapper around Volkan or D3D12, and when that future happens we can cheerfully forget about today's high level APIs.  But that future hasn't happened yet.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!