Native Client in Chrome has switched to a new PPAPI proxy

[Bill Budge]

The old SRPC proxy used to make PPAPI calls to the browser has been replaced with one based on Chrome's IPC proxy. This is part of our effort to allow Pepper calls off the main thread. While we have spent a lot of time testing the new proxy, we expect that this will cause some issues with NaCl apps.

The CL that switched the proxy landed as r166753 in Chrome and has been in Canary for several days now. This changes the --enable-nacl-ipc-proxy flag to --enable-nacl-srpc-proxy and makes the IPC proxy the default. The old SRPC proxy is still available but behind the new flag.

Known issues:

• Some apps run slower with the new proxy. We have a CL in progress to solve this issue.
  
• Startup error reporting to the page is not as good as before because the NaCl plugin doesn't drive the proxy any more.
  
• "MoriRT Snake" demo crashes while loading.
  
• "From Dust" audio glitches.
  

Here is the bug tracking this issue.

http://crbug.com/116317

Please file bugs when you find problems. If you can be specific as to what is failing in your app and provide reproducing apps and pages it will help us fix these faster.

[Robert Isaacs]

(This failed to post before, so apologies if I double post)

Yikes, this change really seems to impact my site: http://www.naclbox.com

Are there changes that you expect we will need to make to our applications to fix the performance impact of this, or do you expect that you will be able to improve the performance to where it was before the change?

[Brad Chen]

It's good that you called this to our attention. We are fixing everything we can find, but without help from folks like you to find problems it is hard to find everything. There are some performance-related fixes in the pipe that hopefully will help your system, but without knowing more precisely what you are testing and what performance changes you are seeing it's hard to say for sure. It would be helpful if you could describe more precisely what you are testing (app, browser version, OS, hardware etc.) and what kind of performance regression you are seeing, so we can be sure we can reproduce it ourself.

Brad

--
You received this message because you are subscribed to the Google Groups "Native-Client-Discuss" group.

To view this discussion on the web visit https://groups.google.com/d/msg/native-client-discuss/-/Z0sRYgp8x34J.

To post to this group, send email to native-cli...@googlegroups.com.
To unsubscribe from this group, send email to native-client-di...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/native-client-discuss?hl=en.

[Bill Budge]

I just tried a NaClBox game on Mac and it seems to work. What issues are you seeing? We think we have a fix for any slowdown you might be seeing.

[Robert I.]

Hi Bill,

I am working on a copy of Windows 7 x64 and am using Chrome Version 24.0.1312.14 beta-m.  The game that I am trying on my machine is Descent..  You can check it out here:

http://www.naclbox.com/gallery/descent

It is running very slowly... maybe 5 fps.  On Chrome 23, the game runs at full speed.

Please let me know if you need any more details.

Thank you,

Robert

--
You received this message because you are subscribed to the Google Groups "Native-Client-Discuss" group.

To view this discussion on the web visit https://groups.google.com/d/msg/native-client-discuss/-/vTPjmL6YNN0J.

[Bill Budge]

I can replicate this on Mac too. The frame rate is slow and uneven, audio is choppy, even with our upcoming performance fix. Something is wrong for sure. I'm looking into it.

Robert

To unsubscribe from this group, send email to native-client-discuss+unsub...@googlegroups.com.

[Bill Budge]

One thing that looks odd is that NaClBox games look like 2d apps but issue PPB_Graphics3d SwapBuffers calls.

Is there a reason to be calling SwapBuffers?

[Roland McGrath]

On Tue, Nov 20, 2012 at 1:53 PM, Bill Budge <bbu...@google.com> wrote:
> One thing that looks odd is that NaClBox games look like 2d apps but issue
> PPB_Graphics3d SwapBuffers calls.
>
> Is there a reason to be calling SwapBuffers?

Even if apps are doing suboptimal things, the starting point should be to
expect equivalent or better performance from a newer Chrome version (with
the IPC proxy) as from an older Chrome version (with the SRPC proxy). If
there is a legitimate reason for some particular usage pattern of PPAPI
calls to have a noticeable performance regression from the old proxy to the
new proxy, we need to document and explain that very thoroughly.

[Bill Budge]

From the point of view of the proxy code, here is your app's typical update cycle:

2d Paint

2d Flush

3d Async Flush

3d Async Flush

3d SwapBuffers

3d SwapBuffers Ack

2d Flush Ack

From the NaCl logging output, I can see long waits after SwapBuffers and before the Ack messages.

I'm speculating that this is triggering some worst case blocking behavior in our proxy. These messages are really part of the implementation of the proxy. I'm not sure what PPAPI calls are generating these without the source to the app.

cc'ing Nicholas and Brett who may have some insight.

On Tuesday, November 20, 2012 1:11:51 PM UTC-8, Bill Budge wrote:

[Robert I.]

Hi Bill,

It is definitely possible that I am doing something sub-optimally.  It certainly wouldn't be the first time.  :)

I am using open gl so that I can use the graphics hardware to scale the screen when the user chooses fullscreen mode.

In the PaintCallback, I am executing the following code:

int width = data->size().width();

int height = data->size().height();

rendering = true;

glViewport(0, 0, 640, 480);

glClear(GL_COLOR_BUFFER_BIT);

GLfloat vVertices[] = { -1.0f,  1.0f, 0.0f,  // Position 0

                            0.0f,  0.0f,        // TexCoord 0 

                           -1.0f, -1.0f, 0.0f,  // Position 1

                            0.0f,  1.0f,        // TexCoord 1

                            1.0f, -1.0f, 0.0f,  // Position 2

                            1.0f,  1.0f,        // TexCoord 2

                            1.0f,  1.0f, 0.0f,  // Position 3

                            1.0f,  0.0f         // TexCoord 3

                         };

GLushort indices[] = { 0, 1, 2, 0, 2, 3 };

glUseProgram(program);

glVertexAttribPointer(positionLoc, 3, GL_FLOAT, GL_FALSE, 5 * sizeof(GLfloat), vVertices);

glVertexAttribPointer(texCoordLoc, 2, GL_FLOAT, GL_FALSE, 5 * sizeof(GLfloat), &vVertices[3]);

glEnableVertexAttribArray(positionLoc);

glEnableVertexAttribArray(texCoordLoc);

if (data->data() != NULL) {

glTexSubImage2D(GL_TEXTURE_2D, 0, 192, 32, width, height, GL_RGBA, GL_UNSIGNED_BYTE, (char *)data->data());

}

glActiveTexture(texture);

glBindTexture(GL_TEXTURE_2D, texture);

glUniform1i(samplerLoc, 0);

glDrawElements ( GL_TRIANGLES, 6, GL_UNSIGNED_SHORT, indices );

context_.SwapBuffers(pp::CompletionCallback(&flushCallback, this));

flush callback simply does the following:

void NaclBoxCcInstance::FlushCallback(int32_t result) {

rendering = false;

}

To view this discussion on the web visit https://groups.google.com/d/msg/native-client-discuss/-/nl3h8YaWyHoJ.

To post to this group, send email to native-cli...@googlegroups.com.

To unsubscribe from this group, send email to native-client-di...@googlegroups.com.

[John McCutchan]

On Tue, Nov 20, 2012 at 4:38 PM, Robert I. <rob...@naclbox.com> wrote:

Hi Bill,

It is definitely possible that I am doing something sub-optimally.  It certainly wouldn't be the first time.  :)

I am using open gl so that I can use the graphics hardware to scale the screen when the user chooses fullscreen mode.

In the PaintCallback, I am executing the following code:

int width = data->size().width();

int height = data->size().height();

rendering = true;

glViewport(0, 0, 640, 480);

glClear(GL_COLOR_BUFFER_BIT);

GLfloat vVertices[] = { -1.0f,  1.0f, 0.0f,  // Position 0

                            0.0f,  0.0f,        // TexCoord 0 

                           -1.0f, -1.0f, 0.0f,  // Position 1

                            0.0f,  1.0f,        // TexCoord 1

                            1.0f, -1.0f, 0.0f,  // Position 2

                            1.0f,  1.0f,        // TexCoord 2

                            1.0f,  1.0f, 0.0f,  // Position 3

                            1.0f,  0.0f         // TexCoord 3

                         };

GLushort indices[] = { 0, 1, 2, 0, 2, 3 };

glUseProgram(program);

glVertexAttribPointer(positionLoc, 3, GL_FLOAT, GL_FALSE, 5 * sizeof(GLfloat), vVertices);

glVertexAttribPointer(texCoordLoc, 2, GL_FLOAT, GL_FALSE, 5 * sizeof(GLfloat), &vVertices[3]);

Upload those vertices and indices into buffers. 

--
John McCutchan <jo...@johnmccutchan.com>

[Noel Allen]

You are mixing 2D and 3D?  

I think this is going to be sub-optimal no mater what happens in the proxy.

Can you always render to a texture then render that to a 3D screen?  I believe we've generally seen the 3D pipe to be faster than 2D.  So your best bet I believe is to always render to the texture, then push that.  That way you should only have a single SwapBuffer callback to wait for.   If you want even faster performance you could use two different textures and basically have a double buffer system, letting you draw into the second while waiting for the first one to complete the callback.

-Noel

On Tue, Nov 20, 2012 at 4:38 PM, Robert I. <rob...@naclbox.com> wrote:

[Nicholas Fullagar]

Hi Robert, take a look at the SDK example hello_world_gles.  It should be in your SDK, but if not, you can browse the current code here (it may need a couple of small changes to match PPAPI version in your SDK)

http://src.chromium.org/viewvc/chrome/trunk/src/native_client_sdk/src/examples/hello_world_gles/

On Tue, Nov 20, 2012 at 4:38 PM, Robert I. <rob...@naclbox.com> wrote:

[Robert I.]

Hi Roland,

I was thinking along those lines too.

I am getting some good advice for optimizing the 3D calls in my app.

I will try out the suggestions, but if maintaining parity with previous versions of Chrome is important then whatever has changed in Chrome beta has caused a pretty significant difference in the performance characteristics.

The extent of the 3D in the app is to copy data to a texture and stretch it to the size of the screen.  It's been working well for several Chrome revisions (since Chrome 16 iirc).

I'll try some of these pointers and report back but it might be worth tracking down whatever I am triggering in case it affects other apps.

Thanks!

Robert

--
You received this message because you are subscribed to the Google Groups "Native-Client-Discuss" group.

To post to this group, send email to native-cli...@googlegroups.com.

To unsubscribe from this group, send email to native-client-di...@googlegroups.com.

[Robert I.]

Hi Noel,

It's been a while since I have looked at the code but my goal on mixing the two was to use 3D for scaling when opengl was available and fallback to 2d rendering when the video card was blacklisted or otherwise unusable.

I wanted to do this with a single executable too.  It seemed to work until the latest beta.

Maybe that is causing this?

[John Bauman]

You could try using only 3D, but fall back to 2D if that fails.

[Bill Budge]

Hi Robert,

The performance changes for your app are no doubt caused by the switch to the new proxy, which sends Pepper calls from the plugin to the browser. The old SRPC proxy is synchronous, meaning that one side blocks while the other side runs. So either the plugin or the renderer is blocked at any time. The new IPC proxy is asynchronous, meaning that both sides run simultaneously.

We are making this change to allow Pepper calls to be made from any thread. This should improve overall performance of NaCl apps, since the renderer and plugin can run in parallel. However, the latency for individual Pepper calls should be worse, since when the plugin makes a call, and the message is sent to the renderer, it isn't blocked and ready to receive it as in the old proxy.

We are testing lots of apps to make sure we don't regress performance. Even though we believe the new proxy will be better, apps have been written and tuned to run well on the old proxy. So far, most apps seem to run well with the new proxy. I'm guessing that your app triggers a pathological latency issue in the new proxy, causing the slowdown and stuttering. Maybe we can fix this in our code. If not, we'll work with you to modify your app.

To unsubscribe from this group, send email to native-client-discuss+unsub...@googlegroups.com.

[Robert Isaacs]

That sounds great.  

I will try over the next few days to take out my 3D to 2D fallback logic and maybe split the application into two versions and let you know if that improves the performance.

Thank you for all of your help.

Robert

[Jim]

It impacted Torapp guilloche designer too. (http://www.torapp.info/en/s/torsec.html)
The application runs smoothly in chromium 23 stable version but hangs in chrome 25.0.1323 dev.
It is tested under
Linux 3.4.4-3-ARCH #1 SMP PREEMPT Tue Jul 3 15:35:13 UTC 2012 i686 GNU/Linux.
Thanks
Jim

[Jim]

I am using PPAPI dev API, which should be the reason for hang.

[Bill Budge]

Thanks for that extra hint. It's very helpful.

Not all 'Dev' APIs are proxied yet, but we plan to add most of them. I'll check which ones your app is using.

[Robert Isaacs]

Hi Bill,

I found the problem tonight.

It seems that operations to an unbound (Graphics2D) context is very slow with the new proxy (or at least in Chrome 24).  I was drawing to a pp::ImageData object with an unbound graphics 2D object.  I found that if I bound that object, the speed of the application returned to normal.

As it turns out, I do not actually need the graphics2d object at all, and have converted my code to just write to an offscreen buffer.

I hope that information helps somehow, but my problem is solved.

Thanks!

Robert

On Wednesday, November 21, 2012 9:54:16 AM UTC-5, Bill Budge wrote:

[Bill Budge]

Thanks for tracking this down Robert.

I'll find out if this is something we can fix in the new proxy. Otherwise, we should probably have a note in the documentation warning about this.

Bill

[Brett Wilson]

This is probably related to this change on trunk:
http://src.chromium.org/viewvc/chrome/trunk/src/webkit/plugins/ppapi/ppb_graphics_2d_impl.cc?r1=156915&r2=159112
and is unrelated to the proxy switch.

We added some delays for Graphics 2D flush for invisible Graphics2D
objects. Before we would issue the flush callback immediately. But
this will actually lead to spinning the CPU painting while the plugin
isn't visible (even faster than when you're visible), which is
obviously not what we want.

Brett

>>>>> native-client-di...@googlegroups.com.

>>>>> For more options, visit this group at
>>>>> http://groups.google.com/group/native-client-discuss?hl=en.
>>>>>

> --
> You received this message because you are subscribed to the Google Groups
> "Native-Client-Discuss" group.

> To view this discussion on the web visit

> https://groups.google.com/d/msg/native-client-discuss/-/sZddlsff8DwJ.

>
> To post to this group, send email to native-cli...@googlegroups.com.
> To unsubscribe from this group, send email to

> native-client-di...@googlegroups.com.

[Jim]

I am using the font dev API.

[Brett Wilson]

Hi Jim,

Unfortunately, that API won't work. We hope to eventually have some
replacement APIs for doing fonts, but will never support that exact
API in Native Client in a stable way. In the new proxy, it won't be
implemented at all.

The problem is that the current Font_Dev API is a wrapper around the
WebKit font rendering, but WebKit is in a separate process. With the
old proxy, calls between the two processes were synchronized such that
only one was running at a time. This makes synchronous calls fast but
throughput is slower since you can't be sharing CPUs. In the new proxy
we do the reverse, where both processes run independently.
Unfortunately, this makes synchronous calls like what would be
required for font rendering unacceptably slow since both processes
have to stop what they're doing and synchronize.

Brett

> --
> You received this message because you are subscribed to the Google Groups
> "Native-Client-Discuss" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/native-client-discuss/-/ZJDVbP8nZ_YJ.

[Jim]

Ｉ donot mind adapting my application to any possible new font APIs  as long as it is at least as flexible as the current one.
The font API is important in that most applications need to show some kind of text, and embedding fonts and using freetype library are pretty lousy.

Does google have a plan to have a stable font API, the current font API seems to be in dev for ever.
Thanks
Jim

> native-client-discuss+unsub...@googlegroups.com.

[Brett Wilson]

On Tue, Nov 27, 2012 at 5:44 PM, Jim <jamesf...@torapp.info> wrote:
> Ｉ donot mind adapting my application to any possible new font APIs as long
> as it is at least as flexible as the current one.
> The font API is important in that most applications need to show some kind
> of text, and embedding fonts and using freetype library are pretty lousy.
>
> Does google have a plan to have a stable font API, the current font API
> seems to be in dev for ever.

I wouldn't expect this in the short term. Although this is clearly
needed, you're the first person I've personally heard asking (I think
most people are doing games and already have text rendering inside
them).

As I mentioned, we can't do font rendering as flexibly as the current
API without significant work, and the current API doesn't really do
what everybody needs (if you want to do lower-level text layout it's
not usable). The API we would likely support in the future is a way to
get at the FreeType font files so you can use Harfbuzz/FreeType/Skia
to do your layout and render them yourself without having to actually
ship fonts. Potentially there could also be a very simple opaque text
rendering facility for simple uses, but this would be more restricted
than the current API (implementation of which from scratch would be
very complicated).

Brett

[Jim]

I can not agree more that we need an API to expose fonts themself. In fact the text font APIs make me hesitate to developer more applications for NACL (as embedding fonts is not ideal).
I will wait for your new APIs.
Thanks
Jim

[Bill Budge]

There's a proposal for a new font API on Pepper-Dev. Please take a look:

https://groups.google.com/a/chromium.org/forum/#!topic/pepper-dev/_8m6WxnoOfg

[Kriss]

Hiya,

I seem to be hit by this, everything works but is now considerably slower. Swapbuffers now takes several seconds to complete for me. It was slow before compared to a native build but this is ten times worse.  -enable-nacl-srpc-proxy gets me back to the old behavior.

A recent test build is available at http://play.4lfa.com/gamecake/dmazed and most of my nacl specific source can be found at https://bitbucket.org/xixs/lua/src/tip/lua_win_nacl/code/lua_nacl.c however the problem is most likely to be somewhere in the generic opengl code so I'm not sure that is much use.

Any suggestions for what I can try adjusting or how to find out what is stalling?

I suspect I may just be calling far too many opengl functions as I know I have plenty of optimization still to do. However is seems like an extreme performance hit compared to the old version.

[David Michael]

It sounds like it might be the same problem Robert had earlier in this thread:
https://groups.google.com/d/msg/native-client-discuss/LNQA4LRcrvA/Bv6P_BQC_TgJ

"It seems that operations to an unbound (Graphics2D) context is very slow with the new proxy (or at least in Chrome 24).  I was drawing to a pp::ImageData object with an unbound graphics 2D object.  I found that if I bound that object, the speed of the application returned to normal.

As it turns out, I do not actually need the graphics2d object at all, and have converted my code to just write to an offscreen buffer."

And here's Brett's explanation:

https://groups.google.com/d/msg/native-client-discuss/LNQA4LRcrvA/1_nBEAckHU4J

"This is probably related to this change on trunk:

http://src.chromium.org/viewvc/chrome/trunk/src/webkit/plugins/ppapi/ppb_graphics_2d_impl.cc?r1=156915&r2=159112
and is unrelated to the proxy switch.

We added some delays for Graphics 2D flush for invisible Graphics2D
objects. Before we would issue the flush callback immediately. But
this will actually lead to spinning the CPU painting while the plugin
isn't visible (even faster than when you're visible), which is

obviously not what we want."

I hope that helps.

--
You received this message because you are subscribed to the Google Groups "Native-Client-Discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to native-client-di...@googlegroups.com.

To post to this group, send email to native-cli...@googlegroups.com.

Visit this group at http://groups.google.com/group/native-client-discuss?hl=en.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Kr...@xixs.com]

I'm not using Graphics2D at all its all Graphics3D so its probably not exactly the same problem.

One thing I should say is that I started using NaCl a very long time ago so its highly possible that I'm doing something that has been changed but I never noticed so it is only now causing me problems.

With that in mind I've just realized that my sdk is rather out of date so my next step is going to be update the sdk.

--
Kriss

http://boot-str.appspot.com/

http://www.WetGenes.com/

[Kr...@xixs.com]

OK found it, its all my fault.

I was clogging up the main thread too much with a busywait. Previously this wasn't a problem as the gl code still managed to draw. After the change the drawing stalled and I ended up waiting for gl code to complete whilst preventing the gl code from completing...

Hopefully when you complete this transition I'll be able to move everything off of the main thread anyway. :)

Cheers.

[David Michael]

On Fri, Mar 8, 2013 at 2:02 PM, Kr...@XIXs.com <Kr...@xixs.com> wrote:

OK found it, its all my fault.

I was clogging up the main thread too much with a busywait. Previously this wasn't a problem as the gl code still managed to draw. After the change the drawing stalled and I ended up waiting for gl code to complete whilst preventing the gl code from completing...

Thanks. I'm a little surprised it worked OK before, then. Probably because the Flush IPC call happened synchronously, whereas now they're asynchronous, and we have to be able to drain the queue of outgoing messages. (Even still, I'm surprised...)

Sorry there was a behavior change that bit you. We've tried to avoid them as much as possible.

 

Hopefully when you complete this transition I'll be able to move everything off of the main thread anyway. :)

The capabilities should all be there now. See some of the links in my e-mail about the threading support to get you started:
https://groups.google.com/d/msg/native-client-discuss/vTGabHR2Hgo/F--AX86WMmUJ
...and feel free to drop us questions here.