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.
_______________________________________________
waffle mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/waffle
