Triple buffering?

[Tyson Jacobs]

 I was wondering why Angle does not use triple buffering. 

It seems like you are leaving a lot of performance on the table by not supporting it. 

[Nicolas Capens]

Hi Tyson,

ANGLE renders everything into an offscreen texture, which at a glSwapBuffers is rendered upside down into the swap chain's back buffer. This is to account the difference between D3D and GL coordinate systems.

So it's kind of like triple buffering already. I'm not sure if much can be gained from having actual triple buffering. That said, I'm currently looking into performance issues that affect our D3D11 back-end which appears to be related to synchronization. So I'll check if triple buffering has any effect on it.

Cheers,
Nicolas

On Sun, May 18, 2014 at 3:08 AM, Tyson Jacobs <tjc...@gmail.com> wrote:

 I was wondering why Angle does not use triple buffering. 

It seems like you are leaving a lot of performance on the table by not supporting it. 

--
You received this message because you are subscribed to the Google Groups "angleproject" group.
To unsubscribe from this group and stop receiving emails from it, send an email to angleproject...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tyson Jacobs]

Hi Nick, 

Thanks for the reply. That sounds like it should be as good as triple buffering, apart from the extra copy. I was trying to figure out why ANGLE was significantly (~15-20 percent) slower than OpenGL on my laptop, despite the fact that CPU utilization is MUCH lower with ANGLE. The GPU is a pre-HD intel, and the GL drivers are that awful. 

Maybe the copy has something to do with the speed difference? I'm running at 720p, so that is a non-trivial amount of bandwidth for the laptop's not so fast system memory. Would sticking an extra instruction at the end of the vertex shader be a better approach? 

[Nicolas Capens]

Hi Tyson,

We've actually just fixed an issue where 'duplicate' vsync was making things 20% slower. It should be patched in Chrome Canary today. Could you give it a try?

Thanks,
Nicolas

On May 23, 2014 7:01 PM, "Tyson Jacobs" <tjc...@gmail.com> wrote:

Hi Nick, 

Thanks for the reply. That sounds like it should be as good as triple buffering, apart from the extra copy. I was trying to figure out why ANGLE was significantly (~15-20 percent) slower than OpenGL on my laptop, despite the fact that CPU utilization is MUCH lower with ANGLE. The GPU is a pre-HD intel, and the GL drivers are that awful. 

Maybe the copy has something to do with the speed difference? I'm running at 720p, so that is a non-trivial amount of bandwidth for the laptop's not so fast system memory. Would sticking an extra instruction at the end of the vertex shader be a better approach? 

On Sunday, May 18, 2014 2:08:32 AM UTC-5, Tyson Jacobs wrote:

 I was wondering why Angle does not use triple buffering. 

It seems like you are leaving a lot of performance on the table by not supporting it. 

--

[Tyson Jacobs]

Sounds promising! This is a desktop application however. I would test it, but I'm not seeing that changeset? 

[Nicolas Capens]

On Mon, May 26, 2014 at 11:46 PM, Tyson Jacobs <tjc...@gmail.com> wrote:

Sounds promising! This is a desktop application however. I would test it, but I'm not seeing that changeset? 

Sorry, I assumed it was a WebGL application. The 20% performance increase was due to a Chrome-specific frame synchronization issue. Either way I checked that ANGLE itself effectively achieves triple buffering through its off-screen inverted texture. Using other swap methods doesn't improve performance any further, except for SWAP_EFFECT_FLIP_SEQUENTIAL, which is only available on Windows 8.1. We probably won't look much into that before that OS has gained substantially more adoption. The advantage of FLIP_SEQUENTIAL isn't that significant anyway.

However, it's possible that we could gain some performance by using two off-screen textures to render into. Currently as we render from it into the back buffer, the rest of the GPU has to wait for that to finish before it can commence drawing into it again. By swapping the textures ourselves the draw commands could be executed concurrently. I don't know if that would really gain us much (the GPU is busy either way), but it's worth a try...

[Tyson Jacobs]

Ah, I see. Do you think my idea holds any promise, of abandoning the off-screen texture entirely, and achieving the screen flip through a negation tacked on to the end of every vertex shader?

[Shannon Woods]

We currently *do* perform a negation of the Y-coordinate in vertex shaders-- this is why we then perform a flip during swap. We do this because DirectX essentially performs its own y-flip during the viewport transformation, so if you perform off-screen rendering to textures, they'll be stored upside down. Our y-negation in the shader is to counteract that implicit flip. DirectX has another effective flip when presenting to the screen (as its origin is at the upper-left, rather than the lower-left as in GL), so we also counter that one, with the flip on swap. The end result is that both on-screen and off-screen scenes are rendered in the orientation GL expects.

We have in the past investigated, and for a time used, an alternate approach, which involved storing all texture data with the y-axis inverted, and inverting every texture lookup operation in every pixel shader. This avoids the full-screen copy, but has its own downsides-- it adds the overhead of flipping every texture on load, and adds code complexity. This approach was in use by ANGLE for a time, and spent time live in Chromium, but it was ultimately determined that it did not, on average, outperform (and possibly underperformed, IIRC) the offscreen rendering case, so it was switched back.