6 Replies Latest reply on Jan 16, 2014 7:24 AM by nmanjofo

    Feature request




      CodeXL is very nice tool,but there are some things I've noticed so far:


      - GL_PATCHES constant is not recognized by debugger, it outputs UNKNOWN to the log (f.e. glDrawArrays(UNKNOWN, 0, 64) )

      - VBOs can't be visualized as geometry (or I haven't figured out how)

      - I have a Shader Storage Buffer of size 4 (= one integer). I can't see it's content, it says "VBO is unavailable" all the time. It's used as an ouput for compute shader, threads increment it using atomic add. But I can see content of other buffers without any problem.


      Also, I would love to see Compute Shader debugger in this tool, that would be really nice, provided that OCL debugger is present. And also please add VAO listing to Explorer, and which VBOs are bound to them, because otherwise I need to manually look up it's VBOs in the code and I have a lot of them, so it takes time.



      Thank You!

        • Re: Feature request

          Hi nmanjofo,


          1. This issue is an oversight in the updated support for OpenGL 4.x - it only happens with some APIs (namely glBegin, glDrawArrays, glDrawElements and glDrawElementsBaseVertex). It is now fixed in our code base and will be resolved in the next CodeXL release. Thanks for your report!

          2. This is a feature request we have on our table for quite a while, but it is not as simple as you'd expect. Since a VBO is just raw data, it is quite complicated to show it as geometry (a point cloud or a primitive), as it requires the context of: data type, number of axes (2, 3, or 4), transformation matrix for each point, strides if relevant, and so forth. We are trying to figure out what is the best and most correct way to get this information from the user, and will hopefully add it in a future CodeXL version.

          3. We are not aware of any issue that could cause such a VBO to not appear, if you would send us a minimal application that reproduces the issue we could look into it. Source would be nice but not necessary, just binaries are enough.

          4. Compute shader debugger is also on our roadmap (and shader debugger in general), again we will hopefully add it in a future version.

          5. I will add VAO support to our feature request list, thank you for your suggestion.



            • Re: Feature request

              Thank You for responding!


              The app I'm working on is quite big, I need to put it into some working condition. Or if CodeXL log would be sufficient, I can generate one and send it to You.

                • Re: Feature request

                  The log might be helpful (it can be found in your computer's %TEMP% folder, named CodeXL-<username>.log and CodeXLServers-<username>.log

                  However, we would probably need an application that reproduces the issue in order to


                  We do not require your entire application, just a minimal sample that reproduces the same issue.

                  If you could provide binaries for such a minimal test case, it would be most helpful.


                  Regarding the format selection for buffers, it is a known inconvenience and we are considering several options about it, such as allowing the user to choose the default format; or a default format per buffer name.

                  Hopefully this will be addressed in an upcoming version of CodeXL.

                • Re: Feature request

                  Also forgot to mention - when I open up buffer during debug, I usually switch from vec3 to something else. But when I start the debugging over, I need to change it from vec3 again. Could you possibly fix this? Ideally add per-buffer setting.

                • Re: Feature request

                  I have also found out that f.e. stencil buffer visualization is not working correctly. When I resize the view, hovering mouse over the picture shows wrong values. I'm attaching screenshot - that red cross is the place where I hovered cursor, it shows 0 which is incorrect.