[RFC] C-source code writing functionality for ApiTrace (glx/egl)

[José Fonseca]

Hi,

This feature has been requested in the past, and you can read my general
comments about it on
https://github.com/apitrace/apitrace/issues/351#issuecomment-111272395 .

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.)


Looking in particular to your implementation, there are a few things that
would need to change in order for me to merge it:


- 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

  Above all, I can't allow C dumping to create maintenance burden for the
regular `apitrace retrace`.

  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.


-  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:

   - replace texture names into variable names, e.g,

        glGenTextures(n = 1, textures = &1)
        glBindTexture(target = GL_TEXTURE_2D, texture = 1)

   into

        GLint texture1;
        glGenTextures(1, &texture1)
        glBindTexture(GL_TEXTURE_2D, texture1)

  so they can be swizzled.  Ditto for  uniform locations, fbos, etc.

  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.


- 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.


Jose


On Mon, Sep 21, 2015 at 11:00 AM, Juha-Pekka Heikkila <
juhapekka.heikkila at gmail.com> wrote:

> Hi,
>
> I've been writing feature for ApiTrace to get it to dump source codes
> for the traces. I think it now reached some kind of 'alpha' level, thus
> if someone else has ideas about such feature maybe voice in opinions.
>
> This new feature is triggered as your give "--csource" parameter to
> ApiTrace when replaying a trace, this will cause creation of folder
> called <your trace>_c_source_code. Inside this new folder will be
> Makefile, stub c code to setup glx or egl, needed data in their own
> source file and frame_XXX.c for each frame.
>
> This solution is not yet 100% all perfect solution but it works for some
> applications, others will still need some manual work.
>
> Things to know
> * Shaders are not yet mapped to match the trace. This mean trace coming
> from another computer probably may not work. For now this can be
> bypassed by replaying trace and tracing this replay.
> * Shaders with multiple shader source strings have hard coded limit of
> 65k/string for now.
> * Linux only.
> * In mid frame I drop out all glx/egl calls with exception of swap
> buffer calls (I don't know if this will be a problem)
> * My Makefiles set CC point to clang, this is because for me clang was
> essentially faster to compile generated sources. Other than speedier
> compilation gcc works equally for me with the generated source codes.
>
> All in all this is still bit hack-ish looking but start to work for some
> things already.
>
> My branch for testing can be found here:
> https://github.com/juhapekka/apitrace-1/tree/c_source_code_writer
>
> Example usage:
> apitrace retrace --csource <your trace>
> cd <your trace>_c_source_code
> make
>
> Once you have your trace written out it should be enough to go to the
> newly created folder and type in "make" and be prepared for quite long
> wait, data.c will take normally quite a while to compile as it will have
> textures inside it - because of this I've already though about at first
> stage writing each blob into their own file to speed up compilation when
> using j parameter for make, later just dump all textures as binary.
>
> Anyhow, any comments are welcome.
>
> /Juha-Pekka
> _______________________________________________
> apitrace mailing list
> apitrace at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/apitrace
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/apitrace/attachments/20150921/86f9d497/attachment.html>