Miscellaneous patches on github

[Nigel Stewart]

Jose,

This way the burden is on the Regal build to turn off things such as
apitrace logging mechanism and backtrace functionality.  One major
disadvantages of a global TRACE_REGAL - it would be messy for toggling
specific areas of functionality, such as backtrace.  In the pipeline I
also have a TRACE_TLS=0 patch (in progress) that I think would be
pretty ugly lumped together with backtrace and logging.  TRACE_TLS=0
seems necessary for stlport-linked C++ on Android.  (No RTTI, no
exceptions)  But Regal would only want to set TRACE_TLS=0 for Android,
I think.

- Nigel


- Nigel

On Thu, Jul 18, 2013 at 11:12 AM, José Fonseca <jose.r.fonseca at gmail.com> wrote:
> On Thu, Jul 18, 2013 at 4:32 PM, Nigel Stewart <nigels.com at gmail.com> wrote:
>>
>> Hello all,
>>
>> Another batch of Regal-related apitrace patches for your scrutiny and
>> opinion:
>
>
> I'll go over them as soon as possible. I really haven't had much time in or
> out of work for apitrace maintenance over the last weeks... :-/
>
>>
>> 1. Conditionally compile-out os::log with -DTRACE_OS_LOG=0
>> https://github.com/apitrace/apitrace/pull/164
>> Allows Regal to handle the apitrace logging.
>>
>> 2. glretrace: GLX and WGL support for ES2/EGL traces.
>> https://github.com/apitrace/apitrace/pull/165
>> egltrace isn't happy with my NVIDIA driver, but glretrace works.
>>
>> 3. glimports: Check for iOS and skip OpenGL and CGL as appropriate.
>> https://github.com/apitrace/apitrace/pull/167
>> Needed for the iOS build of Regal
>>
>> 4. Opt-out of backtrace support with -DTRACE_BACKTRACE=0
>> https://github.com/apitrace/apitrace/pull/168
>> I didn't spend much time with the backtrace functionality, but my
>> initial feeling was that it was too platform-specific for Regal purposes.
>> Also, I'm concerned about jeopardizing the ease of building Regal.
>
>
> I'm a bit concerned about 1 and 4.  I don't want to have  -DFOO -DBOO for
> every bit of functionality that Regal builds wants or not. I'd rather have
> only one  -DREGAL_BUILD (or something like that) that does everything that
> needs to be done for regal builds. This way it is clear what are the
> differences for Regal.
>
> In short, it is as if Regal builds were a different (sub)platform (which
> sort of is true anyway).
>
> Jose
>
>>
>> I think the risk of side-effects for the vanilla apitrace builds are
>> minimal,
>> these don't add any value to apitrace except to harmonize with Regal
>> using it as an optional (statically linked) layer.
>>
>> I'd like to announce the Regal support for apitrace around Siggraph
>> timeframe,
>> next week.  The Regal branch of apitrace isn't perfectly aligned with
>> upstream,
>> but progress is being made here.
>>
>> https://github.com/p3/regal
>>
>> Thanks in advance,
>>
>> - Nigel
>>
>>
>> On Fri, Jul 5, 2013 at 12:23 PM, Nigel Stewart <nigels.com at gmail.com>
>> wrote:
>> > Hello all,
>> >
>> > Cross-posting here on the mailing list of additional opinions and
>> > eyeballs.
>> >
>> > 1. Resolve C4267 MS compiler warnings
>> > https://github.com/apitrace/apitrace/pull/156
>> > Use explicit c-casting to appease the MS compiler.
>> >
>> > 2. Support for Mac OS X 10.5 Leopard
>> > https://github.com/apitrace/apitrace/pull/157
>> > CGLShareGroupObj and IOSurfaceRef were added 10.6 SDK.
>> > Still builds for 10.5 with some modest workarounds.
>> >
>> > 3. Replace dynamic_cast with virtual functions
>> > https://github.com/apitrace/apitrace/pull/158
>> > apitrace can be built with without RTTI if dynamic_cast is avoided.
>> >
>> > These originate from our effort to integrate apitrace into Regal as a
>> > dispatch layer.  These patches bring the projects into closer
>> > alignment.
>> > https://github.com/p3/regal
>> >
>> > - Nigel
>> _______________________________________________
>> apitrace mailing list
>> apitrace at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/apitrace
>
>