GPU tessellation quality

[Dean McNamee]

I have Skia with the GPU backend running on a small ARM Broadcom
VideoCore board, and I'm really impressed with how well it's working.

I had a few small questions I wasn't certain about during integration.

Is there any settings or influence over what decisions are made in the
GPU renderer? For example, I did some tests drawing a circle, and at
larger radiuses you start to see the polygons, the perimeter is
slightly yet noticeably a bit flat, it looks like it has 20-30 edges
from the tessellation. I didn't see any sort of 'quality' choices,
are these sort of decisions fixed, or made based on the hardware
capabilities at runtime?

Additionally I wasn't sure exactly how best to set up the surface. I
am drawing directly to the default framebuffer via
wrapBackendRenderTarget. What I wasn't sure about with
GrBackendRenderTargetDesc is, does Skia have any preferences about the
config? Is it better to have a stencil? How does using multisampling
compare with what Skia will do with fSampleCnt is 1? Right now I just
used the most maxed out config, with stencil and 4 multisamples. It
would be nice to save a bit of memory so I was wondering what effect
stenciling/etc has on the backend.

Thanks!
-- dean

[Cary Clark]

Dean

When you draw the circle, is it filled or stroked?

Thanks

Cary

-- dean

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

[Dean McNamee]

Hi Cary,

It's filled. I should mention that the Skia version I'm using is from July.

Thanks

[Mike Reed]

Can you create a skfiddle.com that shows the problem? That is the single best way to enable us to diagnose it.

[Dean McNamee]

Hi Mike,

I couldn't really reproduce it with the online fiddle, which is why I
asked if there is any runtime adaptation based on the underlying
hardware? I've attached a grab of the framebuffer that illustrates
the example. In this case it's just a clear() and then drawCircle().

If there have been recently changes in the GPU code related to this, I
can work through rolling to the newest code.

Thanks!

[Cary Clark]

It looks like antialiasing is not turned on. What do you get if you call

paint.setAntiAlias(true);

[Dean McNamee]

Hi Cary,

Anti-aliasing is definitely on, but now that you asked, if I set
setAntiAlias(false) it doesn't seem to make a difference.

I imagine the fact that there is some anti-aliasing happening comes
from the fact that the framebuffer has multisampling. I am using EGL
with a multisampling buffer with 4 samples, and I set fSampleCnt to 4
when I set up the render target. If I don't use multisampling then it
is very un-antialiasing, even with setAntiAlias(true)

To me it looks more of a matter of too low of a polygon count, but I
don't know how the GPU circle drawing is implemented so maybe there is
something else.

Just for completeness here is the EGL config:

EGLint attrs[] = {
EGL_RED_SIZE, 8,
EGL_GREEN_SIZE, 8,
EGL_BLUE_SIZE, 8,
EGL_ALPHA_SIZE, 8,
EGL_DEPTH_SIZE, 24,
EGL_STENCIL_SIZE, 8,
EGL_SURFACE_TYPE, EGL_WINDOW_BIT,
EGL_RENDERABLE_TYPE, EGL_OPENGL_ES2_BIT,
EGL_SAMPLE_BUFFERS, 1,
EGL_SAMPLES, 4,
EGL_NONE
};

And the render target description:

rt_desc.fWidth = width; rt_desc.fHeight = height;
rt_desc.fConfig = kSkia8888_GrPixelConfig;
rt_desc.fRenderTargetHandle = 0;
rt_desc.fOrigin = kBottomLeft_GrSurfaceOrigin;
rt_desc.fSampleCnt = 4;
rt_desc.fStencilBits = 8;


This also leads back to my original question, how does Skia use the
depth buffer? Stencil buffer?

Thanks again,
-- dean

On Fri, Oct 17, 2014 at 7:41 PM, 'Cary Clark' via skia-discuss

[Mike Reed]

http://www.skfiddle.com/c/2bb1f206ed1a9f16a783cf49e27b5cce

That looks smooth to me, so perhaps the difference does lie in how you're initializing GL or the GrContext?

[Dean McNamee]

I did some more experiments, and everything looks good if I turn off
multisampling and set fSampleCnt to 0. So it looks like when the
surface is set up for multisampling, Skia make some different
decisions and wobbly circles. Is it possible to try skfiddle with
multisampling configurations?

On Fri, Oct 17, 2014 at 9:18 PM, 'Mike Reed' via skia-discuss

[Joe Gregorio]

[+Greg] for the skfiddle feature request.

[Greg Humphreys]

Good idea, I'm definitely looking for the right set of initialization options to add to fiddles; I'll put this one on the list.

Greg Humphreys | Software Engineer [skia, chrome] | hum...@google.com | 434-260-0543

[Brian Salomon]

Hey all,

I was out when this thread went down. We do render paths differently when MSAA is enabled. It isn't a configuration that is currently shipping in Chrome so there has been less attention to the quality. It wouldn't surprise me if the tessellation calculation constant isn't well tuned.

B

[Dean McNamee]

I am working on a mobile/embedded platform, so I thought multisampling
might be smart from a performance perspective. What are the main
differences in rendering? Any way I should help with MSAA turning?

Thanks!
-- dean

[Brian Salomon]

Hey Dean,

If you're on a device where MSAA performance is good (and not buggy) it is probably advisable to use it. It means we fall back to sw rasterization much less often. The tessellation is controlled b the "tol" value calculated in GrefaultPathRenderer.cpp.

Brian