13 October 2016

Apitrace maintenance

Lots of individuals and companies have made substantial contributions to Apitrace. But maintenance has always rested with me, the original author.

I would prefer have shared that responsibility with a wider team, but things haven't turned out that way. For several reasons I suppose:

  • There are many people that care about one section of the functionality (one API, one OS), but few care about all of them.
  • For all existing and potential contributors including me Apitrace is merely a means to an end (test/debug graphics drivers or applications), it's not an end on itself. The other stuff always gets the top priority.
  • There are more polished tools for newer generation APIs like Vulkan, Metal, Direct3D 12. These newer APIs are much leaner than legacy APIs, which eliminates a lot of design constraints. And some of these tools have large teams behind them.
  • Last but not least, I failed to nurture such a community. I always kept close control, partly to avoid things to become a hodgepodge, partly from fear of breakage, but can't shake the feeling that if I had been more relaxed things might of turned out differently.

Apitrace has always been something I worked on the spare time, or whenever I had an itch to scratch. That is still true, with the exception that after having a kid I have scarcely any free time left.

Furthermore the future is not bright: I believe Apitrace will have a long life in graphics driver test automation, and perhaps whenever somebody needs to debug an old OpenGL application, but I doubt it will flourish beyond that. And this facts weighs in whenever I need to decide whether to spend some time on Apitrace vs everything else.

The end result is that I haven't been a responsive maintainer for some time (long time merging patches, providing feedback, resolving issue, etc), and I'm afraid that will continue for the foreseeable future.

I don't feel any obligation to do more (after all, the license does say the software is provided as is), but I do want to set right expectations to avoid frustrating users/contributors who might otherwise timely feedback, hence this post.

2 comments:

mupuf said...

Thanks for the update José!

This is all understandable and I can relate (maintaining a Qt-based Arduino IDE and failing at making a real community around it despite the interest, because I just could not care enough to make it happen).

I would however like to say that I work a lot of automating the testing for the Graphics Stack and apitrace is so far my tool of choice for game testing and you should see patches coming your way whenever I get time to improve the performance of the retracing & frame dumping.

You also know that I deeply care about performance counters and I really hope we can finish Alex's implementation of the profiling view, since it improves so much the workflow when debugging performance problems.

Finally, thanks for your work! Apitrace has gone a long way and is a solid tool!

mark said...

FWIW, at steam dev days I was asking about tools and nearly every game developer I spoke to in the Linux space relies on apitrace. Other tracing solutions are often broken.

Also, I have interviewed job candidates working on internal driver tools that were really just forks of apitrace.

It may be hard for you to get a feel for the impact of of your work, but in my opinion it is increasing in relevance as linux platforms become more important.