Hello! Noob here trying to get started, having trouble building / integrating Dawn, hoping someone can point me in the right direction.

[Joseph Chow]

Hello!

First off just a quick disclaimer - still somewhat new towards building more complicated projects like Dawn so please bear with me. I will try to give as much detail as possible.

I am trying to get Dawn up and running on Win 10. I am able to follow the build instructions found here with no issues. I can't remember if I tried debug builds but I have definitely attempted(I say attempted cause I can't say for certain) doing a release build by adding "is_debug=false" to the args file that opens up in a text editor. No other arguments are added.

However, trying to integrate the built code is proving to be problematic.

Quick details

• VS Studio 2017  (I know 2019 is out but keeping older version to ensure compatibility with something else I use commonly)
  
• Win 10 SDK 10.0.17763.0
• Win 10 OS build 18362.592
• Running things in Command Prompt
  

When attempting integration

• I include all of the ".lib" files
• I include all of the headers found in "/src"
• I include all of the generated headers found in /out/Release/gen/src
• So far I am creating a new Console application in VS and going from there. I have not tried to do something like building with ninja.
  

So I guess to put it simply, the fundamental issue is that I don't know what I need to include in the cpp project I'm looking to integrate Dawn into. My first baseline test is to just get the sample triangle app up and running, however I keep running into issues with missing symbols.

Take for instance the following

#include "utils/BackendBinding.h"
#include "GLFW/glfw3.h"

int main()
{
    static std::unique_ptr<dawn_native::Instance> instance;
    static utils::BackendBinding* binding = nullptr;

    static GLFWwindow* window = nullptr;

    // Create the test window and discover adapters using it (esp. for OpenGL)
   
    window = glfwCreateWindow(640, 480, "Dawn window", nullptr, nullptr);

    instance = std::make_unique<dawn_native::Instance>();
    instance->GetAdapters();
}

When compiling, Visual Studio complains about the "GetAdapters" call.

Error    LNK2001    unresolved external symbol "public: class std::vector<class dawn_native::Adapter,class std::allocator<class dawn_native::Adapter> > __cdecl dawn_native::Instance::GetAdapters(void)const " (?GetAdapters@Instance@dawn_native@@QEBA?AV?$vector@VAdapter@dawn_native@@V?$allocator@VAdapter@dawn_native@@@std@@@std@@XZ)    ConsoleApplication1    C:\Users\sortofsleepy\Documents\dawn-test\ConsoleApplication1\ConsoleApplication1.obj    1    

As best I can tell, it's something to do with the underlying call within the "InstanceBase" class, but for the life of me I can't figure out why.

There are a few other calls as well that result in a LNK2001 error as well.

Can someone point me in the right direction?

Any help is very much appreciated!

[Kai Ninomiya]

I can't give a conclusive answer right now, but here are some tips that might get you in the right direction:

- Add dawn_complete_static_libs = true to the gn args (and then rebuild Dawn).

- Right now the dawn_complete_static_libs flag is somewhat incomplete, so you'll need some additional libs as well. Here's a complete list that worked for me, from

https://github.com/kainino0x/webgpu-cross-platform-demo/blob/master/CMakeLists.txt#L44-L50

"${DAWN_BUILD_DIR}/obj/libdawn_native.a"

"${DAWN_BUILD_DIR}/obj/libdawn_utils.a"

"${DAWN_BUILD_DIR}/obj/src/dawn/libdawn_proc.a"

"${DAWN_BUILD_DIR}/obj/third_party/shaderc/libshaderc_spvc/spvc.o"

"${DAWN_BUILD_DIR}/obj/third_party/shaderc/libshaderc_spvc/spvc_private.o"

"${DAWN_BUILD_DIR}/obj/third_party/shaderc/libshaderc_spvc/spvcir_pass.o"

"${DAWN_BUILD_DIR}/obj/third_party/SPIRV-Tools/libspvtools_opt.a"

(I haven't tried this on Windows. Since you're on Windows, you probably have to change all the .a to .lib. Not sure about the .o files.)

--
You received this message because you are subscribed to the Google Groups "Dawn Graphics" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dawn-graphic...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dawn-graphics/79300fc2-3620-48f1-af94-17225fec9266%40googlegroups.com.

[Joseph Chow]

Interesting! I had tried linking a few of the built .lib files in the obj folder but VS spit back a message saying it wasn't able to read those files. I will try adding the static libs flag and see what happens.

Thanks for the tip!

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

[Felix Maier]

I don't know how you build your test project where dawn gets embedded, but I remember getting weird linking errors on Windows. They were caused because my main project was built using MSVS, while dawn got built using clang.

I fixed them by adding is_clang=false to the dawn GN args, so MSVS is used for dawn as well.

[Joseph Chow]

Oh! I didn't know Clang was getting used - I got a couple compiler related errors at first when building that were pointing to issues related to my visual studio install so I kinda naturally assumed things would get built

with MSVS and didn't pay too much attention to the output.

Thanks for the tip! I will keep that in mind when I try this again.

[Éric Renaud-Houde]

Hi all,

I'm certainly interested in this process as well -- trying the same thing on Win10 (SDK 10.018362) with VS2019. Looks like Dawn could make a great desktop graphics library! While my build process also succeeded, I've noticed that the examples don't seem to work: I only get a blank (white) window without any hooked swapchain or graphics.

Otherwise, I am also facing this linking error in a test VS application. I thought manually copying over the dll(s) could help, but no. Then I remembered about the __declspec( dllimport ) flags, which are present in webgpu.h as WGPU_EXPORT. However, their internal library use seem limited so unsure if a particular preprocessor define that would really help here?  I could be mistaken, but the full list of required includes seem to be: dawn\src, dawn\src\include, dawn\out\$(Configuration)\gen\src, dawn\out\$(Configuration)\gen\src\include ?

I ran into a couple more things trying this build for the first time yesterday, which I might as well share:

• Python 2 requirement for depot tools
• set DEPOT_TOOLS_WIN_TOOLCHAIN=0 to use the locally installed toolchain

Not too sure how to trigger a clean rebuild, but I will try the static non-clang approach as well.

To unsubscribe from this group and stop receiving emails from it, send an email to dawn-graphic...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dawn-graphics/65bdea3f-f989-4e51-b698-779fc28a874d%40googlegroups.com.

[Joseph Chow]

@Éric - not sure how much this will help since your situation sounds a bit different(examples worked for me) but just a quick update since I just happened to try things again, turning off clang seemed to fix things and my linking errors appear to be gone. Not sure if the static library setting did anything though as

I'm still getting dlls generated.

Includes list sounds right based on what the examples look like; at least those are all the folders I'm including as well.

To view this discussion on the web visit https://groups.google.com/d/msgid/dawn-graphics/65bdea3f-f989-4e51-b698-779fc28a874d%40googlegroups.com.

[Éric Renaud-Houde]

Ok thanks, good to know.

The test samples work (all tests seem to pass), but not the demo graphic ones. Those don't require any launch arguments (to select the backend or something), do they?

Cheers,

To unsubscribe from this group and stop receiving emails from it, send an email to dawn-graphic...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dawn-graphics/096592f1-61a6-408a-83fd-e08b35c2af29%40googlegroups.com.

[Éric Renaud-Houde]

Apologies, just saw the InitSample method, and the required launch arguments as one would expect!

[Kai Ninomiya]

Ah yes, I'm sorry I forgot about the is_clang thing. Glad things are looking good so far.

I've filed a bug about fixing dawn_complete_static_libs. https://crbug.com/dawn/327

To view this discussion on the web visit https://groups.google.com/d/msgid/dawn-graphics/CADdbm6LfCsMZpNUnxxr5DnXuOFuAhosh8pc2LbCfC-WS2XJ2RQ%40mail.gmail.com.

[Corentin Wallez]

We've been focusing on the GN build of Dawn at the moment, and using this as part of another build is notoriously difficult. What we should have is a CMake-based build for at least the core Dawn libraries and maybe samples to check things work that's maintained as best effort.

To view this discussion on the web visit https://groups.google.com/d/msgid/dawn-graphics/CANxMeyC3vM2M4QfYAq2dvffxo9CrQ1jNmSZ%3Dz-XpnHFFSTn2ag%40mail.gmail.com.

[Joseph Chow]

@Kai - no worries! And thanks for filing the bug.

Although unfortunately I'm still running into issues :( 

Seems like it's basically the same deal with not being able to find the appropriate function, but this time in the built .dlls instead of the built libraries hahaha.

Will keep investigating when I have time during the week.

On Monday, January 27, 2020 at 3:20:39 PM UTC-8, Kai Ninomiya wrote:

Ah yes, I'm sorry I forgot about the is_clang thing. Glad things are looking good so far.

I've filed a bug about fixing dawn_complete_static_libs. https://crbug.com/dawn/327

On Mon, Jan 27, 2020 at 7:05 AM Éric Renaud-Houde <eric.re...@gmail.com> wrote:

Apologies, just saw the InitSample method, and the required launch arguments as one would expect!

Cheers,

To view this discussion on the web visit https://groups.google.com/d/msgid/dawn-graphics/096592f1-61a6-408a-83fd-e08b35c2af29%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Dawn Graphics" group.

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

To view this discussion on the web visit https://groups.google.com/d/msgid/dawn-graphics/CADdbm6LfCsMZpNUnxxr5DnXuOFuAhosh8pc2LbCfC-WS2XJ2RQ%40mail.gmail.com.

[Joseph Chow]

Ok! Some progress. Finally things build and I can run without any issues, crossing my fingers this'll work but I suspect I may come back with more issues.

It seems that in my case, for whatever reason, adding the "dawn_complete_static_libs" is what is causing issues.

• dlls still get generated (not sure if this is actually an issue but unexpected nonetheless)
  
• There are additional library files that get generated in "<directory>/obj" that appear to be complete static libraries based on their file size, however including them seems to result in some kind of DirectX error as far as
  I can tell - "DXGI_DEBUG_ALL" comes back as an unresolved external symbol; from limited research it's my understanding that DirectX is included with Windows now so I am not sure how to debug this. 
• The interesting difference with building without clang is that for me, now the samples don't work. I'm pretty certain that when building with Clang, all the samples were fully functional.
  Based on the console message, it's something to do with Command buffer flushing, in the sample's utility files, the "DoFlush" command fails to pass an assertation
• Another note - I don't remember the exact combination of files at this point haha but I do remember the debug level of some of the libraries being an reported back by VS as an issue as well.
  

I know things are still under development but like Corentin suggested, something somewhat simpler like a CMake based build would be great whenever you folks get around to it.

[Joseph Chow]

Alright! While I did eventually run into more issues, I think (*crosses fingers), I am more or less set for the time being. Hoping no more issues crop up haha.

For anyone else that might stumble into issues like I did and come across this thread, I wrote down some steps here.

But a quick tldr' for the Dawn / Chrome team on the additional issues

• I got over the DirectX hurdle after I saw the option to disable the DirectX backend.
  
• The Shaderc library kept getting compiled with a few missing symbols, fortunately I had another build of Shaderc already available that seems to integrate fine.