can I use apitrace to trace OpenGL leaks ?

[comicfans]

is there any scripts to help trace OpenGL object leaks ? (textures/buffers not deleted) if not , I'm planning to implement some basic leak trace function . any suggestion ?

[jrfonseca]

is there any scripts to help trace OpenGL object leaks ? (textures/buffers not deleted)

No, not directly.

if not , I'm planning to implement some basic leak trace function . any suggestion ?

It's feasible to do so in apitrace, but a fair amount of work, either:

• while retracing, you'd need to keep track of all live objects for all contexts in a share group, and whenever the last GL context of the share group is destroyed you would dump all objects still alive.
• or you'd write a Python script that would do the above

One way or the other, I'd imagine it would take 2-4 weeks to get this working reliably and across most objects.

If you're determined to pursue this I can give a more detailed explanation. But there might be simpler alternatives as below.

What OS and GPU are you developing on?

If you're developing on Linux with open-source Mesa drivers, it would be much easier to implement this on the Mesa drivers themselves -- they already keep track of live objects -- so it would be just a matter of adding a KHR_debug callback to the apitrace notifying of the live application. I'd expect it would take no more than a couple of days to implement this. I'm familiar with Mesa source code, so I can also give you a few hints on this.

Another strategy is to use a C/C++ structure/object for every OpenGL object. and ensure every OpenGL object is only created/destroyoed through these wrapper structures. Then you could use an ordinary C/C++ memory leak detector (e.g., valgrind, or whatever): if the OpenGL object leaked, the C/C++ object would leak too, and vice/versa. Most C/C++ applications will probably wrap OpenGL objects on C/C++ objects anyway. The drawback is of course you'd have to do it for every application.

[comicfans]

while retracing, you'd need to keep track of all live objects for all contexts in a share group, and whenever the last GL context of the share group is destroyed you would dump all objects still alive.

I'll try this, but may take care only one context at first. OpenGL object create/destroy all spell as Gen/Delete, so I think a common "GLObj" with Tex/Shader/xxx enum is enough for leak tracing .I'm not familiar with python so seems cli_dump can be my template.

it would be much easier to implement this on the Mesa drivers themselves

sadly I work with both linux and windows, with some 3rd party libs, so hack on apitrace seems easier for me.

[jrfonseca]

Gen/Delete

Gen* doesn't really do much these days. TexImage/TexStorage is what actually does the work nowadays. But maybe that's close enough.

seems cli_dump can be my template.

I'm not familiar with python so seems cli_dump can be my template.

I don't think that's a good way to go about it.

If you want to do this while running glretrace, then you need to modify retrace/glretrace.py to inject your C++ code (or at least inject hook calls into your C++ functions that do the work you need). This is because most of apitrace C++ code is actually generated from Python scripts, particularly deserializing state.

On the other hand, if you're going to write a "state tracker", ie, not do this while retracing, then a scripting language like Python is the ideal.

Trying to do with with pure C++, based of cli_dump will take a lot of manual labour (deserializing all arguments), and the code will quickly rot as nobody will maintain it.

The reason that apitrace even exists without an army of developers behind it is because we use code generation to cope with the several thousands of OpenGL API functions. All efforts to add features that try to accomplish something based on sheer brute force have and will continue failing.

I hope this makes sense.

[comicfans]

Thanks for advices . so I'll try python way

[comicfans]

On the other hand, if you're going to write a "state tracker", ie, not do this while retracing, then a scripting language like Python is the ideal.

a little questions: which script I can reference to do same thing likes cli_dump
Parser.parse_all ? or if I should parse output from cli_dump ?

[comicfans]

since I need a quick working prototype for my work's deadline,so I've still implemented this basic check in C++ part (comicfans@7a77d4a). it adds cli command: apitrace leak-trace and qapitrace->Trace->LeakTrace entry
(Leak information appears in error window , click jump to generate call).
I'm not sure if this modify way fits apitrace's requirements.
if yes, I'd like to normalize this prototype better and create a pull request.
Thanks for advices.

[jrfonseca]

I also just pushed a quick prototype to https://github.com/apitrace/apitrace/tree/leaks .

It only detects texture leaks, and does not keep track of current context across multiple threads, not shared contexts.

But this should get your started.

[comicfans]

Greate help ,but I can only spend my spare time on this so I can't guarantee the completeness.

[jrfonseca]

Understood. My main job is not working on apitrace neither -- just something I do to make ends meet at work and on spare time, though not much of the latter lately.

Rather than achieving completeness from the start, my main goal as maintainer is try we follow a least resistence path towards completeness.

I integrated your GUI changes with the python script.

[jrfonseca]

I think the Python script is now as capable as your C++ code. But I think long term it should be easier to maintain.

Let me know if it still works for you.

If it still works for you, I see no impediment to get this merged into master. I don't plan to do further work myself, but hopefully others can weigh in.

[jrfonseca]

Just noticed I had forgotten to add gui/leaktracethread.{cpp,h} to the git repos. So I pushed all the changes again.

[comicfans]

Greate, I'll try later.

[jrfonseca]

I've merged into master. Thanks.

Feel free to contribute further improvements anytime.

I think a note in docs/USAGE.markdown about this would be useful.

[comicfans]

I've found lastest windows binary package didn't contain leaks.py,

[jrfonseca]

Ah. I forgot to add it..

I'll fix it. I should probably add an wildcard to include app *.py in scripts subdir, as I keep forgetting this.