I am encountering weird behavior with latest 5.0 and 5.1 RC versions of nSight Visual studio edition, together with VS2015 Community Update 3. Windows 10 x64 machine with GTX 660ti. Driver version 368.39.
I am trying to enter frame debugging with very basic OpenGL application, but its blocked by message of unsupported api usage:
Unsupported function(s) were in use: glGetIntegerv, glGetString, glClear
Unable to capture frame due to API usage unsupported by Nsight.
As an example, glGetIntegerv is perfectly supported on GL4.5 according to the version support table on this page (glGet - OpenGL 4 Reference Pages), but NSight does not support it?
glClear is also there and supported on GL 4.5 (glClear - OpenGL 4 Reference Pages), as is glViewport which is also apparently unsupported.
Any OpenGL program is going to have a hard time without being able to clear the colour and depth buffers, no? Is it possible this is a bug?
I have:
Windows 10 x64
VS2015 Community 14.0.24720 Update 1
NSight 5.0.0.15294
GTX970 and Driver Version 368.39
I am seeing the same problem, any help would be greatly appreciated.
It was working fine for several months until a few days ago the same errors started appearing. I know it is not related to the code base as a colleague is not experiencing the same problem on his machine. I have tried updating drivers and reinstalling NSight, neither made any difference.
I have Windows 10 Pro 1151 build 10586.494
I don’t have anything running that would hook into the program.
I also tried to delete the AppData folder too and this has not worked.
I do a quick gloom for the dlls you pasted, it looks OK. I take a try on the same machine as yours: Win10 10586, VS2015 Update 3, 5.1 RC, 368.39, Yes, I can repro your issue now.
I am thinking that might be due to you are using some newer driver and 5.1 RC is bundled with 361.91. On the other hand, I also take a try on some internal latest version of Nsight, that works fine with latest driver.
Happy to report that using the 361.91 driver allows nSight to function as expected.
Thanks for the information, although either a new driver or a new version of nSight is required, we can’t and shouldn’t have to run an old driver to have this working.
I think the reason is that wglGetProcAddress() on 368.81(maybe after 368) returns valid function potinter for old OpenGL function like glEnable, and nsight doesn’t seem to support these functions.
But nsight still supports old OpenGL function from GetProcAddress() with opengl32.dll.
So if your app uses old OpenGL functions from GetProcAddress()+opengl32.dll instead of wglGetProcAddress(), unsupported function is not resported.
Do you have any plans to make nsight support these functions from wglGetProcAddress()?
@finlaybob, Yes, we are working on the release for sure.
@sizwk, I think the GetProcAddress() with opengl32.dll just get the very old OGL functions from MSFT, that’s not recommended way to use OGL. I am not sure about your meaning, Nsight do support OGL core functions which comes from wglGetProcAddress() [actually, Nsight do support some old OGL functions, but that’s limited], the key here is you need use corresponding driver.
On driver 365.19, wglGetProcAddress(“glEnable”) returned 0.
So the valid pointer was got from GetProcAddress()+opengl32.dll.
On driver 368.22, wglGetProcAddress(“glEnable”) returned a valid pointer(not any of 0, 1, 2, 3, -1).
So the calling glEnable() became jump to this pointer.
In this situation, Nsight reported “glEnable is unsupported function”