The Dawn backend seems to be causing some problems

[guodong chen]

In short, my application supports both Opengl and Dawn backends.
When I open support for both Dawn and Opengl, it looks like this.
skia_enable_gpu = true
skia_use_metal = true
skia_use_gl = true
skia_use_dawn=true
skia_use_vulkan=false

application will fail when using Opengl to build SkSurface.

If I turn off the compile option on the Dawn backend, everything is fine

GrGLFramebufferInfo info;

info.fFBOID = (GLuint)framebuffer;

info.fFormat = format;

GrBackendRenderTarget target(width, height, 0, 0, info);

SkSurfaceProps surface_props;

auto surface = SkSurface::MakeFromBackendRenderTarget(

env->gr_context_.get(),

target,

kBottomLeft_GrSurfaceOrigin,

kRGBA_8888_SkColorType,

nullptr,

&surface_props);

I'm pretty sure info.fFormat= format; Is a valid value. 

But when I tracked down the Skia code, I realized

this file skia/src/gpu/ganesh/GrBackendSurface.cpp and In the following code

#ifdef SK_GL

GrBackendRenderTarget::GrBackendRenderTarget(int width,

int height,

int sampleCnt,

int stencilBits,

const GrGLFramebufferInfo& glInfo)

: fWidth(width)

, fHeight(height)

, fSampleCnt(std::max(1, sampleCnt))

, fStencilBits(stencilBits)

, fBackend(GrBackendApi::kOpenGL)

, fGLInfo(glInfo) {

fIsValid = SkToBool(glInfo.fFormat); // the glInfo must have a valid format

}

#endif

glInfo.fFormat It just magically becomes 0, so Is it a hidden memory error? 

My platform is MAC system M1 chip.

[Greg Daniel]

Can you share your code where you are setting up the GrGLFramebufferInfo and GrGLBackendRenderTarget? Have you tried putting a breakpoint right before our in the GrGLBackendRenderTarget constructor to see what the value of the infos format is?

Also is you're just using GL and Dawn, you don't need skia_use_metal or skia_use_vulkan enabled.

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/skia-discuss/1a7f3f56-dc99-4b40-8fec-bbd4f18c3bf8n%40googlegroups.com.

[guodong chen]

Can you share your code where you are setting up the GrGLFramebufferInfo and GrGLBackendRenderTarget?

After I initialize Opengl's environment with GLFW, I initialize GrGLFramebufferInfo and GrGLBackendRenderTarget.

Have you tried putting a breakpoint right before our in the GrGLBackendRenderTarget constructor to see what the value of the infos format is?

Instead of using single-step debugging, I directly modified the SKIA code to add printf, like this

// in my code

GrGLFramebufferInfo info;

info.fFBOID = (GLuint)framebuffer;

info.fFormat = format;

printf("%x %d\n", &info, info.fFormat);

GrBackendRenderTarget target(width, height, 0, 0, info);

// in skia code

#ifdef SK_GL

GrBackendRenderTarget::GrBackendRenderTarget(int width,

int height,

int sampleCnt,

int stencilBits,

const GrGLFramebufferInfo& glInfo)

: fWidth(width)

, fHeight(height)

, fSampleCnt(std::max(1, sampleCnt))

, fStencilBits(stencilBits)

, fBackend(GrBackendApi::kOpenGL)

, fGLInfo(glInfo) {

printf("%x %d\n", &glInfo, glInfo.fFormat);

fIsValid = SkToBool(glInfo.fFormat); // the glInfo must have a valid format

}

#endif

I compared the addresses of the variables and found that they were same. But when passed to SKia, glinfo.fformat becomes 0.

When I turn off skia_use_dawn and keep Metal and GL everything will be fine.

That's all I got from debugging

[Greg Daniel]

Can you share the code where you set up those two structs in your code? Can you add more printf statements throughout your code to see when the format goes to zero on the GrGLFramebufferInfo?

To view this discussion on the web visit https://groups.google.com/d/msgid/skia-discuss/e674e0e0-5f52-4c3d-9e52-0bb9afa42440n%40googlegroups.com.

[guodong chen]

This is the SKIA code I pulled this afternoon and added debugging information output with it

This is my own code

Debugging information output

As you can see from the output

//in my code

start file:source/creator/gfx/ui/xw/x/opengl/backend_sk_surface.cc@32 6f0962a8 32856

//in skia code

debug file:../../src/gpu/ganesh/GrBackendSurface.cpp@1059 6f0962a8 0

//in my code
end  file:source/creator/gfx/ui/xw/x/opengl/backend_sk_surface.cc@34 6f0962a8 0

You can see that the address is the same, but the value has changed inexplicably

I tried it again and turned off Dawn's compile options and everything worked fine

[guodong chen]

At first I wondered if SKia's header file didn't match the compiled library. But it soon became clear that was not the problem

[guodong chen]

I tried to shut down Dawn again, and from the output everything was fine

[Greg Daniel]

Wow this is certainly a weird issue. At first I was wondering if it has something to do with initializing the value inside of a union and the compiler getting confused when Dawn was an option in the union. But as you can see here we don't actually even put the Dawn object into the union for GrBackendRenderTarget, https://source.chromium.org/chromium/chromium/src/+/main:third_party/skia/include/gpu/GrBackendSurface.h;l=650.

Out of curiosity does the fGLInfo on GrBackendRenderTarget end up with the right value? It seems really weird that the const ref that is passed into the constructor is getting modified. I wonder if something is going wrong with the default copy constructor of GrGLFramebuferrInfo. Can you test out adding a copy constructor here, https://source.chromium.org/chromium/chromium/src/+/main:third_party/skia/include/gpu/gl/GrGLTypes.h;drc=f97e7e130b02a0fee5a06aa9cdf25d3a0a3715d0;l=189, and see if that fixes anything?

To view this discussion on the web visit https://groups.google.com/d/msgid/skia-discuss/1f75af27-979f-42d7-9256-fe3bf3c23b63n%40googlegroups.com.

[Brian Salomon]

On Mon, Sep 26, 2022 at 8:28 AM guodong chen <chenguodo...@gmail.com> wrote:

At first I wondered if SKia's header file didn't match the compiled library. But it soon became clear that was not the problem

It needs to be the same header but the including code must also be compiled with the same Skia preprocessor macro values. Is it possible that is not the case?

Brian

To view this discussion on the web visit https://groups.google.com/d/msgid/skia-discuss/5f73eba5-7997-43c1-a206-699bd6d3b4e7n%40googlegroups.com.

--

Brian Salomon |

Office Hours: go/bsalomon-office |

bsal...@google.com

[guodong chen]

Yes！ your words woke me up, I tried it and it seems to be all right

Thank you very much @Brian Salomon @egda...@google.com