Add macro so that gpu trace marker can add an arg to the TRACE_EVENT it makes

Add macro so that gpu trace marker can add an arg to the TRACE_EVENT it makes

BUG=skia:

Committed: https://skia.googlesource.com/skia/+/93a37bc91a40a7cd14f9f8eca6097535ab1099e4

[egdaniel, 2014-07-09 20:56:00]

So with the new macro I've added, we can place the debug marker as well as the
trace event which will include an arg and value (example added in GrContext). We
are limited to only adding one arg to the trace event since internally we are
already adding one arg for our ID number (to connect back to the debug markers),
and trace events only goes up to TRACE_EVENT2.

The new macro has _ARG appended to the end of it which is not the prettiest. I
could make a single GR_CREATE_TRACE_MARKER macro that can take a variable number
of args but I would not be able to clearly limit users from inputting more that
1 arg/value pair (which is why trace event explictly use T_E0,1,2). Thoughts on
which version of the macro you like better?

[bsalomon, 2014-07-09 21:40:51]

On 2014/07/09 20:56:00, egdaniel wrote:
> So with the new macro I've added, we can place the debug marker as well as the
> trace event which will include an arg and value (example added in GrContext).
We
> are limited to only adding one arg to the trace event since internally we are
> already adding one arg for our ID number (to connect back to the debug
markers),
> and trace events only goes up to TRACE_EVENT2.
> 
> The new macro has _ARG appended to the end of it which is not the prettiest. I
> could make a single GR_CREATE_TRACE_MARKER macro that can take a variable
number
> of args but I would not be able to clearly limit users from inputting more
that
> 1 arg/value pair (which is why trace event explictly use T_E0,1,2). Thoughts
on
> which version of the macro you like better?

Is the T_E limited to 2 because that's all that someone felt like typing or is
it a fundamental limit of the tracing system? Maybe we should call this
GR_CREATE_TRACE_MARKER1 or GR_CREATE_TRACE_MARKER_ARG1 in anticipation of 2, 3,
etc.

[egdaniel, 2014-07-14 19:17:55]

updated macros and changed internal macros to use variable arg list to reduce
the number of internal macros needed especially if we do ever increase the the
number of allowable args

[bsalomon, 2014-07-15 13:39:05]

On 2014/07/14 19:17:55, egdaniel wrote:
> updated macros and changed internal macros to use variable arg list to reduce
> the number of internal macros needed especially if we do ever increase the the
> number of allowable args

As long as all of our compilers support macro var args, lgtm.

[egdaniel, 2014-07-21 14:22:38]

The CQ bit was checked by egdaniel@google.com

[commit-bot: I haz the power, 2014-07-21 14:23:39]

CQ is trying da patch. Follow status at
 https://skia-tree-status.appspot.com/cq/egdaniel@google.com/379223004/20001

[commit-bot: I haz the power, 2014-07-21 14:34:50]

FYI, CQ is re-trying this CL (attempt #1).
The failing builders are:
  Build-Win-VS2013-x86-Debug-Trybot on tryserver.skia
(http://108.170.220.76:10117/builders/Build-Win-VS2013-x86-Debug-Trybot/builds...)

[commit-bot: I haz the power, 2014-07-21 14:44:20]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-07-21 14:44:21]

Try jobs failed on following builders:
  Build-Win-VS2013-x86-Debug-Trybot on tryserver.skia
(http://108.170.220.76:10117/builders/Build-Win-VS2013-x86-Debug-Trybot/builds...)

[egdaniel, 2014-07-21 20:36:46]

The CQ bit was checked by egdaniel@google.com

[commit-bot: I haz the power, 2014-07-21 20:37:06]

CQ is trying da patch. Follow status at
 https://skia-tree-status.appspot.com/cq/egdaniel@google.com/379223004/40001

[commit-bot: I haz the power, 2014-07-21 20:48:01]

Change committed as 93a37bc91a40a7cd14f9f8eca6097535ab1099e4