[waffle] nacl backend

[Tapani]

On 12/10/2014 07:39 AM, Chad Versace wrote:
>> On 12/09/2014 04:15 AM, Tapani Pälli wrote:
>> Hi;
snip 8<
>
>> 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.

Using c++ seemed more natural choice as nacl documentation and examples 
all refer in to that but it looks like the c++ objects use c api below 
which could be used directly. I will take a closer look at this approach 
when I have c++ version working in a robust way (fixing swapbuffers 
problem described below).

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

One needs to use "create_nmf.py" tool from nacl_sdk to create a nmf file 
that describes what libraries are used and how to load the 
gl_basic_nacl.nexe, then create a html file that uses embed tag to load 
nmf file, I can include example html file as part of example and run 
create_nmf.py as part of build process to ease the pain. There is still 
requirement to run a web server to serve these files though, there is 
one provided by the nacl_sdk as part of tutorials that I've been using 
during testing.

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

One way would be to pass optional void* argument for waffle_init 
('platform_data' or such) or provide a waffle_platform_init that is only 
used by those platforms that require special treatment. I think 
currently I could abuse waffle_display_connect() to pass a pointer to 
the backend but did not want to do this. Of course ideally existing 
waffle apps would 'just work' without modifications or minimal 
modifications, this has been my goal.

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

This is primarily only to isolate c++ and offer c API for waffle 
internal interfaces, like the android backend does. I have there a 
special thread that handles swapbuffers but let's see if this is required.

The problem I have with swapbuffers is that I cannot guarantee if the 
swap finished before waffle app submits a new one, This is what the 
swap_thread tries to deal with. I get bad results (even unresponsive 
browser tab) if I just queue new swap to happen when previous one is in 
flight. I'm currently debugging why all this happens. So currently 
things work as long as app does not bomb the backend with swaps.

Typical render loop in NaCl works so that you call swapbuffers and 
provide it a callback which gets called when swap finishes (callback is 
mandatory), then after this callback you can continue safely. So I think 
"ideally" waffle app would be called back from 
waffle_window_swap_buffers but this would be completely nacl specific 
and not ideal.

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

Thanks, I'll follow these steps!

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