Archives Discussions

[vvuk]

Howdy, I'm trying to use CodeXL 1.3.4903 on Windows (Win8, 64-bit) to debug a GL app.  The app uses multiple threads and multiple GL contexts, all in the same share pool (more specifically, all GL contexts do a wglShareLists with an initial context).

I see all GL function calls, but can't examine any resources, especially textures.  In the context list, I see "GL Context 1 (deleted)", "GL Context 2", and "GL Context 3 (shared - GL2)", and "GL Context 4 (shared - GL2)".  Contexts 3 and 4 only have the static buffers listed.  Context 2 has textures, render buffers, FBOs, VBOs, etc.  However, under Textures, I only see "Default Texture 2D - Unit 0" repeated 3 times, and "Default Texture 2D - Unit 6".  Under Render Buffers I have a bunch of stencil RBs; that's all correct, double-clicking Render Buffers though shows me a bunch of "Render Buffer data is not available at this time." rectangles.  Under Frame Buffer Objects, I see a bunch of FBOs (FBO 1 - 30, all created by the app), and underneath each I see a texture and a renderbuffer (stencil).  The Textures are IDs that I'd expect, e.g. Texture 42, Texture 51.

Double-clicking any of these Texture objects, or right-clicking and selecting "Open Texture 42" does nothing.  Literally nothing -- the properties in the bottom left don't update, no new window is opened, no error, nothing.

Seems like there are two problems -- the list under "Textures" is incorrect/broken.  It should be listing all active textures.  Second, even when I do have a Texture object, I should be able to open it.

Is there anything that I can do to fix this?  The app in question is Firefox, with some patches applied -- I'm happy to package up a zip file if it would be useful for someone at AMD to debug and see what's going on.

Thanks!

[urishomroni]

Hi vvuk,

1. The issue you are reporting with FBOs is a known issue which will be fixed in a future CodeXL version. The FBO links should bring you to the object (i.e. the render buffer or texture) as expected.

2. The textures not appearing is not an issue we've seen. Could you provide us with a sample application that reproduces this issue? Sources would be helpful, but not necessary - we just need to binaries.

3. The render buffers not being shown is usually an API limitation. Namely, render buffers are sometimes unreadable, if they are attached to an active framebuffer, or to an inactive framebuffer, and other such statuses.

To work around this, try setting a breakpoint on API functions like glBindFramebuffer, glBindRenderbuffer, wglMakeCurrent, wglSwapBuffers, glFramebufferRenderbuffer, etc. the breakpoints will hit just before the function is executed. You might also want to try to perform a single API step (F10) after each of these breakpoints, and see if the change the API function made helped.

Hope this helps,

[vvuk]

Hi Uri,

Good to hear about the first issue.  For the second, I've created a zip file with the app at http://people.mozilla.com/~vladimir/misc/firefox-win64-gl-for-amd.zip

1. Unzip this somewhere, on a 64-bit Windows machine (Win7/8)

2. cd firefox-gl

3. Confirm that it runs: "firefox.exe -no-remote -profile profile"  (the rendering will be wonky; that's the bugs I'd like to debug )

4. There's a shutdown assertion crash (this is an opt-debug build)

For CodeXL, the config is straightforward... firefox.exe as the binary, the firefox-gl directory as the working directory (so that it can find the "profile" subdir).  Run it in CodeXL, then hit pause.  When it pauses, examine any of the contexts, especially #2 (which should be the root of the share context list).  The Textures there have almost no textures listed beyond 4 texture units.

Let me know if this is enough; I can also provide source (just have to push the work-in-progress patches somewhere.

Thanks,

- Vlad

[urishomroni]

Hi Vlad,

We have setup the configuration with Windows 8 64-bit in our labs and extracted the binaries, running a few tests with your application.

What we're seeing here, are a few things different from what you're describing:

* The deleted OpenGL context 1 does not appear. Instead 5 contexts appear, and most of the contexts are shared to GL context 1. Otherwise, your description of the contexts' status is accurate (replace 2 with 1)

* The textures are all appearing properly under Context 1's textures node.

* Double-clicking a render buffer in the tree does not open a window, instead of opening one that says "not available". We are currently looking into this issue.

Please provide the following information:

1. Are you using the standalone CodeXL or the Visual Studio extension?

2. What happens when you use the other version? Are the results the same?

3. What graphics hardware are you using on the machine? What display / OpenGL driver version?

4. Try setting a breakpoint on glBindTexture. Do you see the function being called / hit? Do the parameters look reasonable?

4'. In the CodeXL OpenGL State variables view, set the state variables GL_ACTIVE_TEXTURE and GL_TEXTURE_BINDING_2D, and make sure they make sense when glBindTexture is called (e.g. when it is called with texture name 0, make sure that GL_TEXTURE_BINDING_2D is some other number. You might want to add a breakpoint on glActiveTexture for this as well, to see if the texture units are managed correctly as well.

5. Try setting a breakpoint on "Break on OpenGL Errors" (under the Error / Warning tab in the CodeXL breakpoints dialog). Do you see any errors? Namely, what functions are the errors occurring on? glBindTexture? glActiveTexture?

6. Try setting a breakpoint on glDeleteTextures and see if your application is deleting any textures as they are being used or bound to a texture unit.

Thanks,

[vvuk]

I've tested on two machines, one a laptop with a nvidia 765M + Optimus (on both the intel and nvidia GPUs), as well as a desktop with a GTX 670.  Same behaviour on both, including the deleted context 1.  I'll give it a try with an AMD card tomorrow; I'll also check if we have any differing paths for AMD vs NV, but we shouldn't.

1. Are you using the standalone CodeXL or the Visual Studio extension?

- Using standalone CodeXL

2. What happens when you use the other version? Are the results the same?

- Results are the same; I did end up uninstalling the VS extension because it caused significant issues with VS (the crash issue reported elsewhere)

3. What graphics hardware are you using on the machine? What display / OpenGL driver version?

- Nvidia 765M + Optimus (331.65 + latest Intel); GTX 670 (331.93)

4. Try setting a breakpoint on glBindTexture. Do you see the function being called / hit? Do the parameters look reasonable?

Interesting -- I get no breaks on glBindTexture at all.  Setting a breakpoint on glActiveTexture works, as do other calls, but not on glBindTexture.  I'll add some instrumentation to figure out exactly which glBindTexture symbol we're binding to; I wonder if we're somehow getting the wrong one (i.e. a non-intercepted one).  That could certainly cause weirdness!

4'. In the CodeXL OpenGL State variables view, set the state variables GL_ACTIVE_TEXTURE and GL_TEXTURE_BINDING_2D, and make sure they make sense when glBindTexture is called (e.g. when it is called with texture name 0, make sure that GL_TEXTURE_BINDING_2D is some other number. You might want to add a breakpoint on glActiveTexture for this as well, to see if the texture units are managed correctly as well.

This all looks correct to me, except for not being able to break on glBindTexture.  That seems like the issue.

5. Try setting a breakpoint on "Break on OpenGL Errors" (under the Error / Warning tab in the CodeXL breakpoints dialog). Do you see any errors? Namely, what functions are the errors occurring on? glBindTexture? glActiveTexture?

No errors.

[urishomroni]

vvuk wrote:

4. Try setting a breakpoint on glBindTexture. Do you see the function being called / hit? Do the parameters look reasonable?

Interesting -- I get no breaks on glBindTexture at all.  Setting a breakpoint on glActiveTexture works, as do other calls, but not on glBindTexture.  I'll add some instrumentation to figure out exactly which glBindTexture symbol we're binding to; I wonder if we're somehow getting the wrong one (i.e. a non-intercepted one).  That could certainly cause weirdness!

4'. In the CodeXL OpenGL State variables view, set the state variables GL_ACTIVE_TEXTURE and GL_TEXTURE_BINDING_2D, and make sure they make sense when glBindTexture is called (e.g. when it is called with texture name 0, make sure that GL_TEXTURE_BINDING_2D is some other number. You might want to add a breakpoint on glActiveTexture for this as well, to see if the texture units are managed correctly as well.

This all looks correct to me, except for not being able to break on glBindTexture.  That seems like the issue.

That would definitely do it, the CodeXL OpenGL server uses calls to glBindTexture to determine the currently bound texture.

If, as you say, the GL_TEXTURE_BINDING_2D value is correct, perhaps we should add an option to use the OpenGL state instead of the OpenGL API trace to determine the active texture object (which would essentially work around this issue when it happens) - though obviously CodeXL can't expect to have partial interception.

Perhaps the application (or some subordinate library) is using an extension that does not exist on AMD hardware, which replaces glBindTexture with something else.

Do let us know the results of your research.

Thanks for the details,

[vvuk]

Uri Shomroni wrote:

That would definitely do it, the CodeXL OpenGL server uses calls to glBindTexture to determine the currently bound texture.

If, as you say, the GL_TEXTURE_BINDING_2D value is correct, perhaps we should add an option to use the OpenGL state instead of the OpenGL API trace to determine the active texture object (which would essentially work around this issue when it happens) - though obviously CodeXL can't expect to have partial interception.

Perhaps the application (or some subordinate library) is using an extension that does not exist on AMD hardware, which replaces glBindTexture with something else.

Do let us know the results of your research.

Ah ha!  One problem identified.

We link to opengl32.dll fully dynamically; we load it at runtime.  We are using wglGetProcAddress to get the address of all GL symbols, including the ones that are normally exposed by opengl32.dll -- such as glBindTexture.  The interception DLLs that CodeXL is putting in place are returning the underlying native opengl32.dll's function for glBindTexture (and presumably the other core functions).  glActiveTexture isn't exposed by opengl32.dll directly, and wglGetProcAddress works correctly.

Changing our code to do a direct GetProcAddress on the CodeXL interceptor opengl32.dll gets us the right glBindTexture pointer.  Sounds like this is a bug in the implementation of your wglGPA?  (I'm pretty sure it's supposed to work on all GL symbols, but not 100%)

With that change, that gets me to a place where I now see all textures listed under GL context 2.  However, the majority of those have "Texture data is not available at this time".  I'm wondering if CodeXL requires the context to be current before it can access texture data?  We create one background context that we use as our share group "root", but it's never actually made current beyond the initial creation.  The other contexts that are actively used for rendering only have static buffers underneath them.  Any ideas?  Edit: if I double-click a texture then it actually seems to successfully load, and I see it in the list.  So the only issue is that the texture data doesn't seem to be proactively loaded when the full Textures tab is opened.

Also -- I think the reason for why I have a deleted GL context #1 and you don't is that we end up creating a context, checking wgl extensions, and then if ARB_robustness is supported, we destroy that context and create a new one with the robustness flags set.  If I force robustness to false, then I see GL Context 1 as the main one and the one that things share with.