[Turned out to be a debugger bug] My Intel GL_VERSION says 4.3 but wglGetProcAddress doesn't find plain functions Khronos's doc pages check off by version?

Am I doing something wrong? I kind of assumed a page like this one (glSamplerParameter - OpenGL 4 Reference Pages) that says these functions are in 3.2 would be required to be enumerated by that version and later?

Using wglCreateContextAttribsARB to specify the version, core profile (no compatibility thingy, not sure about this one) it says version 4.3, but so does my control panel. wglGetProcAddress seems to act like 3.0 maybe. I feel like I’m missing something. But why is this so confusing too :frowning: anyway I hope I’m missing something or I will throw up my hands.

Thank you all!

Ver 3.3+. See:

While not the spec, you can also get a quick clue when this might have been added from the standard glext.h file:

Notice that it lists PFNGLSAMPLERPARAMETERFPROC and glSamplerParameterf() first under GL_VERSION_3_3.

You mentioned Intel. What specific driver and driver version are you using? Someone here that runs Intel GL drivers can probably set you straight here.

1 Like

GL_VERSION returns “4.3.0 - Build 20.19.15.4835”.[1] After turning in last night I thought maybe it wanted a construction like wglGetProcAddress("wglGetProcAddress") but that doesn’t work either.

Someone here that runs Intel GL drivers can probably set you straight here.

I kind of assume any public software has to also function on Intel. I don’t understand how it can say it’s version 4.3 if it doesn’t have these APIs, unless these aren’t first-class APIs. Khronos’s docs give the impression they are first-class. glSamplerParameteri is just one example I give. I need a host of APIs that can’t be emulated.

I feel like I must be missing a step, but don’t know why it’s so abstruse either. For reference below is my working code. At the end wglGetProcAddress returns zero for things I’d not expect, such as glClearDepthf and glSamplerParameteri but returns nonzero for glBindBufferRange that I think is 3.0, making me to think I’m missing something in WGL that enables additions that came after 3.0. I think 3.0 is a magical cut off point in the OpenGL timeline, already WGL is a bewildering API since Microsoft doesn’t update it, there’s only word of mouth to go on, or the absurdist extension registry system, e.g. things like wglCreateContextAttribsARB. I think there must be something else like that. Still I’m looking at some wxWidgets code for reference and not seeing anything else in it not present here.

	SetPixelFormat(dc,i,&pfd);

	HGLRC c = wglCreateContext(dc);
	
	if(!c) err:
	{
		ReleaseDC(DDRAW::window,dc); return 0; 
	}

	wglMakeCurrent(dc,c);

	void *f = wglGetProcAddress("wglCreateContextAttribsARB");
	wglMakeCurrent(0,0);
	wglDeleteContext(c);
	if(!f) goto err;

	const int al[] = 
	{
		0x2091,4, //major
		0x2092,3, //minor
		0x2094,DX::debug, //flags
		0x9126,1, //core profile
		0
	};
	c = ((HGLRC(WINAPI*)(HDC,HGLRC,const int*))f)(dc,0,al);
	if(!c) goto err;

	wglMakeCurrent(dc,c);

EDITED: I’ve been working with ANGLE and somewhat frustrated by its incompleteness, and so turned to plain OpenGL for comparison. I’m pretty sure it gets a proper 4.3 context or is able to find the extensions. I think I will have to break into its code later today or tomorrow to see what it does differently. It’s the only strategy I have left.

[1] Intel’s control panel calls this number “Driver version”. Thanks!

It’s not expected to do so either. wglGetProcAddress will not return any function pointers explicitly exported by “opengl32.dll”.. That means any core 1.1 OpenGL functions or any core WGL functions.

If you want to make a function pointer loader that always gets function pointers regardless of such things, you must also try GetProcAddress on “opengl32.dll”, as shown in the example in the link.

1 Like

Although I was aware of this, this was part of the problem I had. The real problem was (it turned out) Visual Studio’s debugger is telling me about half of the global function pointers are 0 when actually they aren’t.

I had some assert lines to a few of the pointers, starting with glEnable since I didn’t expect to get its pointer with wglGetProcAddress, but also in the debugger the others appeared to be “0x00000000” too. So I took the debugger at its word. If I had fixed glEnable it would have passed the assert lines.

I don’t know what else to add, sorry. I don’t know how constructive this topic/thread is since it really came down to a VS visualizer bug! I’m not sure this post qualifies as a “Solution” since it’s really not one. Maybe since we’re all mods here it can be safely deleted.

I apologize for taking everyone’s time :heart:

Glad you got a line on your problem. I’ve had my share of problems with MSVS, but I haven’t seen this.

If I were you, I’d want to know exactly what’s going on here. A few options to consider:

  • In your app, are there possibly multiple instances of function pointers / functions in different scopes, with you populating one and MSVS displaying the other (?)
  • Do you have all the appropriate compile+link options enabled in your build to maximize debug info available to the MSVS debugger?
  • It may be an MSVS bug, but I wouldn’t default to that and not do any other checking first.

No, I’d disagree. This thread could be very useful to the next guy that hits a similar issue. It’s enough to call into question the results they’re seeing in the debugger and make them dig deeper there to ensure they’re tracking reality (with printfs/code checks/etc.).

Also, are you sure this is a MSVS bug? Could it be something about how you’ve built your app, or the settings you have active in MSVS, or some extension you have plugged into MSVS that may be fouling up the results displayed in variable watch windows?

1 Like

I suppose the only value it has is if someone has this particular problem they can find reassurance they’re doing things right, or a recipe for how to do it. My thinking was this doesn’t address the debugger problem because it’s not about that, and it’s not really relevant to the problem at hand.

For what it’s worth 1) for this project I was using a pretty old version of VS (2010) so this bug may be solved now in new versions (I suppose I could check) but also I have experienced troubles with globals in every version of VS so it doesn’t surprise me really. But this is a first time I’ve seen this. 2) There was no name clash or anything, there must be a cache for values in the debugger that has limits, or something like this. The globals were defined in sequence and after initialization about half were zero according to the debugger, and the distribution looks very random and even. Mostly every other one, but sometimes with runs of two or three. It may have something to do with memory layout, maybe just internal failure. MSVC2017 is completely unusable because it has internal (compiler) memory overwriting bugs throughout its templates implementation. It’s not unheard of for the compiler or debugger to overwrite its own memory with junk data, they’re programs too, which could also explain it.

Edited: For the record (if anyone cares) how it went down is after I confirmed ANGLE worked and my context had the same set of extensions and same entry points, I just set a local variable to one of the missing functions that happened to be the first one ANGLE loads, and it was nonzero. Then I scratched my head for a while until there was nothing left to do but try to assign that pointer to the global variable, and… the global was still 0 to the debugger. So I had to rule out every possibility until it came down to what seemed least likely :slight_smile:

Follow-up: The debugger bug was present in VS2019, but it could depend on what “platform toolset” the project uses. I don’t think I want to go the distance to mess the project (or copy it) to build it with 2019 to find out if the bug goes away or not. (If MS cared about user feedback I might, but I’m sure if I submitted it to their feedback system this would go nowhere.) (I do know debugging the new DLL with ANGLE with VS2010 changes versus 2019. 2019 has better std container inspection, so I don’t think the debugger is fully tied to the platform toolset, and I wouldn’t be surprised if the bug exists in 2019.)