[waffle] nacl backend

[Chad Versace]

> On 12/09/2014 04:15 AM, Tapani Pälli wrote:
> Hi;

Hi Tapani :)

> I'm currently working on a NaCl backend for Waffle, I wanted to ask
> for opinions or comments on my current approach.

Great to hear!

> First of all I'm using some c++ in the nacl backend code but AFAIK
> everything of this can be converted to c if c++ is absolutely not
> wanted.

Waffle's Android backend also contains C++, because Android's
SurfaceFlinger APIs require it. So, C++ is allowed in Waffle when it's
needed. And the Mac backend uses Objective-C... ouch :/

In my opinion, having a mixed C/C++/Objective-C codebase can cause a lot
of headaches. So, please try to minimize the amount of C++ code used.
Don't, however, zealously and exclusively use C in you NaCl backend if
that makes your life significantly harder. If the natural NaCl idiom is
C++, then use C++ when iterfacing with NaCl.

Does NaCl really provide C bindings the Pepper graphics APIs? I've never
closely examined the Pepper APIs before.

> 1. Building
>
> User needs to provide path to nacl_sdk and nacl_version (for example
> pepper_38). Maybe will need further additions like the target
> architecture selection (which is currently just hardcoded). For
> toolchain I've selected 'glibc' as waffle requires dlopen() and c99
> support which were not possible when using 'pnacl-clang'. Almost
> everything builds fine, only failures happen for examples and unit-tests
> for different reasons (for example fork() or usleep() are not supported
> + some other symbols caused problems). I've just disabled these for now
> in cmakefiles when nacl is selected and made my own gl_basic_nacl
> example which copies the gl_basic test behavior. I'm slowly migrating it
> to be just like gl_basic but with some minimal changes.

All that sounds good to me.

My big question: How does one run gl_basic_nacl? Do I need to write a
small webpage with javascript glue to load the executable? Does the NaCl
SDK provide magic helpers to run it from the command line?

> 2. Backend
>
> Waffle using application is responsible for creating a pp::Instance,
> either by creating a class or via "PPAPI_SIMPLE_REGISTER_MAIN(main)"
> type of wrapper where it gets created behind the scenes. Currently there
> is no interface to pass this instance to waffle so the backend seeks it
> out by inspecting a pp::Module::InstanceMap that lists all current
> instances.

I'm working on some patches to expand Waffle's public interfaces to
accept flexible parameter lists. Assuming that all current waffle
functions will soon be redesigned to accept more flexible parameters,
which function would you like to pass the pp:Instance into? Or do you
feel that Waffle needs a new entry point for the pp:Instance?

> Swapbuffers is somewhat complicated as it is asynchronous and app might
> go and queue another swap before first one finished.

Have you encountered any strange NaCl requirements regarding threading?
I briefly scanned your code, and did not fully understand what
nacl_container.cpp was for. Could you explain that file?

> When I have a solid solution for this I'm planning to post a set of
> 'WIP patches', maybe just the build system changes at first.

Patches are good! Alpha-quality half-working half-broken patches are
good! Patches that build are really really good!

I recommend this as a patch submission strategy for your NaCl project:

    1. First, submit a skeleton stub implementation of src/waffle/nacl
       along with the CMake changes needed to build it. These patches
       should contain nothing controversial; no calls to the Pepper
       APIs; no example applications. The goal of the first patch series
       is MAKE WAFFLE BUILD ON NACL. Make any build-system shortcuts and
       toolchain assumptions that you need to. As soon as these patches
       arrive, I'll merge it into an integration branch.

    2. Second, submit an example program with a thorough explanation of
       how to run it. It should build and make any needed Pepper calls,
       but of course it won't work yet because Waffle's NaCl backend
       isn't finished yet. Having an example program merged early into
       the tree, before the backend is completed, would allow me and
       others to play with the NaCl backend as you're working on
       completing it.

    3. Third, start submitting the real implementation of the backend,
       making any changes to core Waffle as needed. To simplify the
       effort, focus on getting it working on just one compiler
       toolchain.

    4. Fourth, and partially parallel to 3, start worrying about the
       other toolchains like PNaCl.

> If you feel like testing this, I've pushed a snapshot here:
> http://cgit.freedesktop.org/~tpalli/waffle/log/?h=snapshot

Thanks for posting work-in-progress code with your announcement. It
really helps to have some concrete code to look at. Looking forward to
your patches.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 884 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/waffle/attachments/20141209/3cda0343/attachment.sig>