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

[José Fonseca]

On Mon, Sep 21, 2015 at 5:31 PM, Arthur Huillet <arthur.huillet at free.fr>
wrote:

> On 2015-09-21 13:29, José Fonseca wrote:
>
>> 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.)
>>
>
> I want to say that a C-dumping feature can be very useful for certain use
> cases that retrace/trim don't cover very well.
> One case is for driver developers to quickly create non-regression tests.
> Another is to more easily modify the trace (sed is pretty terrible), in
> order to trim it manually (needed more often than not on complex
> applications!) and then modify some parameters (to test various workarounds
> and hypotheses).
> Performance testing may be argued to be a third case (you can't really use
> glretrace for that).
>
> I don't know overall how much value this really brings to Apitrace, but it
> certainly is greater than zero for driver development. For application
> development I am not so sure


The use case you explain above actually proves my point very nicely:

Rather than putting time on reinventing the wheel under the C-dumping
flavour, we might as well spend it on (1) getting trimming working right,
or (2) allow creating traces from an ASCII dumps (so that you can do what
you witthout C compiler intervertion.)

(1) might be as hard or a bit harder that implementing C-dumping (but
unlike C-dumping has huge value).  Implementing (2) at least an order of
greatness simpler than trying to get C-dumping on-par with glretrace.

As I said on issue 351, traces are the cornerstone of apitrace.  There are
issues with traces of course, but if we all weigh on fixing them (reduce
read/write overhead, make them more editable, trim, etc) then everybody
(application developers, implementors, alike) end up benefiting.  If we all
try to come up with solutions that bypass traces and scratch our itch,
we'll end up with a bunch of half-useful "YMMV" features, that works for
whomever wrote it and nobody else.

Jose
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/apitrace/attachments/20150921/983561e1/attachment-0001.html>