<div dir="ltr"><div><div><div>Hi,<br><br></div><div>This feature has been requested in the past, and you can read my general comments about it on <a href="https://github.com/apitrace/apitrace/issues/351#issuecomment-111272395">https://github.com/apitrace/apitrace/issues/351#issuecomment-111272395</a> .<br><br>The short version is that, while I don't oppose others to implement and maintain such feature, I don't think it is worth my while. Rather than diving attention and effort over two overlapping versions of the same functionality, I'd rather stay focused on just one. (Likewise, I'd much rather see the whole apitrace community betting on `apitrace retrace`, rather than trying to compensate apitrace retrace shortcomings with a C generated code.)<br><br><br></div><div>Looking in particular to your implementation, there are a few things that would need to change in order for me to merge it:<br><br><br></div><div>- implementation of C dumper must be completely disjoint from retrace. Even though a C-dump would duplicate the retrace functionality, there's no practical way for them to share any code as they are fundamentally very different beasts<br><br></div><div> Above all, I can't allow C dumping to create maintenance burden for the regular `apitrace retrace`.<br></div><div><br></div><div> I think the only exception is glws module, and potentially the retrace_{glx,wgl,cgl}. These hand-written modules could probably be refactored into a shared library, which could be used by the generated C code to deal with the GLX/WGL/CGL portions.<br></div><div><br><br></div><div>- I think that C is not the right tool for this job. If this is implemented as a Python script, then this script can import all the specs in apitrace/specs/*.py scripts, and use the API description to do the conversion to C in a generic fashion, such as:<br><br> - replace texture names into variable names, e.g,<br><br></div> glGenTextures(n = 1, textures = &1)<br> glBindTexture(target = GL_TEXTURE_2D, texture = 1)<br><br></div> into<br><br></div> GLint texture1;<br><div><div> glGenTextures(1, &texture1)<br> glBindTexture(GL_TEXTURE_2D, texture1)<br><br></div><div> so they can be swizzled. Ditto for uniform locations, fbos, etc.<br><br></div><div> I know many apitrace potential contributors feel more confortable in C/C++ rather than Python, and that it seems easier to start coding in C than dealing with a new language, but it is misleading. The only reason apitrace manages to cope with the humoungous size of the OpenGL API is because of the API specs and the code generation logic in Python. And if a feature is supposed to cope with the whole breath of the OpenGL API it better make full use of that, or I'm afraid is doomed to failure or obsolescence as new OpenGL versions/extensions get added.<br></div><div><br><br></div><div>- Concerning blobs, yes, you should probably dump and concatenate all blobs into a single binary data file, then mmap it to memory from the dumped C code, and use offsets into it.<br></div><div> <br><br></div><div><div>Jose<br></div><div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Sep 21, 2015 at 11:00 AM, Juha-Pekka Heikkila <span dir="ltr"><<a href="mailto:juhapekka.heikkila@gmail.com" target="_blank">juhapekka.heikkila@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br> <br> I've been writing feature for ApiTrace to get it to dump source codes<br> for the traces. I think it now reached some kind of 'alpha' level, thus<br> if someone else has ideas about such feature maybe voice in opinions.<br> <br> This new feature is triggered as your give "--csource" parameter to<br> ApiTrace when replaying a trace, this will cause creation of folder<br> called <your trace>_c_source_code. Inside this new folder will be<br> Makefile, stub c code to setup glx or egl, needed data in their own<br> source file and frame_XXX.c for each frame.<br> <br> This solution is not yet 100% all perfect solution but it works for some<br> applications, others will still need some manual work.<br> <br> Things to know<br> * Shaders are not yet mapped to match the trace. This mean trace coming<br> from another computer probably may not work. For now this can be<br> bypassed by replaying trace and tracing this replay.<br> * Shaders with multiple shader source strings have hard coded limit of<br> 65k/string for now.<br> * Linux only.<br> * In mid frame I drop out all glx/egl calls with exception of swap<br> buffer calls (I don't know if this will be a problem)<br> * My Makefiles set CC point to clang, this is because for me clang was<br> essentially faster to compile generated sources. Other than speedier<br> compilation gcc works equally for me with the generated source codes.<br> <br> All in all this is still bit hack-ish looking but start to work for some<br> things already.<br> <br> My branch for testing can be found here:<br> <a href="https://github.com/juhapekka/apitrace-1/tree/c_source_code_writer" rel="noreferrer" target="_blank">https://github.com/juhapekka/apitrace-1/tree/c_source_code_writer</a><br> <br> Example usage:<br> apitrace retrace --csource <your trace><br> cd <your trace>_c_source_code<br> make<br> <br> Once you have your trace written out it should be enough to go to the<br> newly created folder and type in "make" and be prepared for quite long<br> wait, data.c will take normally quite a while to compile as it will have<br> textures inside it - because of this I've already though about at first<br> stage writing each blob into their own file to speed up compilation when<br> using j parameter for make, later just dump all textures as binary.<br> <br> Anyhow, any comments are welcome.<br> <br> /Juha-Pekka<br> _______________________________________________<br> apitrace mailing list<br> <a href="mailto:apitrace@lists.freedesktop.org">apitrace@lists.freedesktop.org</a><br> <a href="http://lists.freedesktop.org/mailman/listinfo/apitrace" rel="noreferrer" target="_blank">http://lists.freedesktop.org/mailman/listinfo/apitrace</a><br> </blockquote></div><br></div></div></div></div></div></div></div>