Static linking and context creation

[Ariel Manzur]

Hi.

I was able to successfully compile angle inside our project (Godot Engine if you're curious, here is my angle branch https://github.com/punto-/godot/tree/angle), I have a an issue with the context, and a question about building:

- Is there any example that could be considered the best way to create a context compatible with the host system? The problem I'm seeing right now is that on computers where our opengl renderer crashes, the angle build shows a grey screen, and we get the error "Program LINK FAILED: Failed to create D3D shaders.". However the same game on the same computer, exported to HTML5 and run from inside Chrome works fine. So it looks like the computer is capable of running the shader, there could be a problem with how I create the context?

- Is there an easy way to enable static linking of everything? I found the "ANGLE_TRANSLATOR_STATIC" macro, but for everything else I had to go into the headers and define all the *APIENTRY stuff. I'm hoping to be able to do this with a macro too, so it'll be easier to merge new versions in the future.

Thanks,

Ariel.

[Geoff Lang]

By creating the eglDisplay with the pain old eglGetDisplay(EGL_DEFAULT_DISPLAY), you should get something that works, ANGLE may try to create several renderers internally until one works.  If you want to manually select a back-end, take a look at the extensions referenced in Choosing-a-D3D-Backend.

As for why you're getting that program link error, my guess is that you're not packaging the d3dcompiler_47.dll along-side the ANGLE dlls.  The D3D backends require it.  We could probably work on improving that message.

Currently, we only support shared libraries because they hold global variables and we don't want to have multiple copies of those variables.  If you're worried about function loading, any GL function loader library that supports GLES should be able to load our entry points using eglGetProcAddress.

--
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.

[Ariel Manzur]

Is this dll provided by the system, or by angle? Right now I'm linking everything statically, so I don't pack any dlls (the user is expected to have directx and all that stuff), and it seems to work (on computers where our gl renderer works, the angle build also works).

I'm creating the display like this eglGetPlatformDisplayEXT(EGL_PLATFORM_ANGLE_ANGLE, EGL_DEFAULT_DISPLAY, displayAttributes); (full function here https://github.com/punto-/godot/blob/angle/platform/windows/gl_context_egl_angle.cpp#L39 ) I think I copied from one of the angle examples. I'll try your suggestion.

The main reasoning for statically linking is that it's easier to build, and easier to distribute. The engine download is just 1 .exe, and the games can be exported as just 1 .exe (or 1 exe and 1 data package). I don't think there's an advantage in having dlls, the end users won't be updating angle on their own for a particular game.. What behavior should I be seeing from these global variables? I also had to define GL_GLEXT_PROTOTYPES.

[Geoff Lang]

The DLL is provided by the system (Windows SDKs and Visual c++ redistributes I believe) and ANGLE copies it to the output directory after building.  We've been unable to rely on our users having it installed so we package it when distributing ANGLE and Chrome.

Your method of creating displays should be equivalent.  The issue is likely the compiler DLL being missing, not an incorrect display being created.

Understood on the easier to build and distribute part but we officially only support the shared libraries for now because the libGLESv2.dll and libEGL.dll names are standardized.  As for the global variables, we store the global per-thread current EGL and OpenGL contexts there.  If libGLESv2 ends up getting linked into multiple DLLs, they will each have a different current context variable and things may break.  You may be fine static linking if you are not using multiple DLLs but it can be risky and you will still likely have to package the d3d compiler DLL.

[Jamie Madill]

On the subject static linking, it's come up before. I'm not sure on how to link to posts in this group, but if you search for a post entitled 'Building libEGL and libGLESv2 as static libraries on Windows' you might get some more helpful information.

[Ariel Manzur]

Is the "d3dcompiler_47.dll" being loaded at runtime with dlopen or similar? Where would I find that code? (I searched the string "d3dcompiler" and it's not present..) Or should I be linking with a "d3dcompiler_47.lib"? I'm not getting any errors at link time, or at dynamic link time, the process starts normally (as far as I remember windows shows a dialog when a dll is missing). I'm just trying to print something there to make sure that's the problem..

Thanks,

Ariel.

[Geoff Lang]

You can find the code in HLSLCompiler::compileToBinary in HLSLCompiler.cpp.

[Geoff Lang]

Sorry, HLSLCompiler::initialize.

[Ariel Manzur]

Thanks.. I see it now. What I don't understand is, if they have the d3d9 dll, why don't they have this d3dcompiler dll? Is it installed with a separate package? If not, is there anything in particular we need from version 47? I also have versions 33-43 on my system, could I make it try all those if 47 fails? I guess packaging the 1 extra dll is not that bad, but I'd prefer to avoid it..

Thanks,

Ariel.

[Geoff Lang]

You could try that.  We've found that all of the D3D compiler versions have various bugs that we've had to work around.  The older ones tended to be much more flaky so your users may experience crashes.