Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Making WebGPU-NAPI addon @webgpu compliant #5

Open
dcerisano opened this issue Feb 24, 2020 · 3 comments
Open

Making WebGPU-NAPI addon @webgpu compliant #5

dcerisano opened this issue Feb 24, 2020 · 3 comments

Comments

@dcerisano
Copy link
Contributor

dcerisano commented Feb 24, 2020

I just posted an update to your issue in CTS

Could you please create a cts-napi branch here to develop against the napi branch in CTS?

The basic issue is that there are slight differences in WebGPU API between these two repos that should be resolved. The idea to to make everything compliant with the @webgpu spec.

This will likely mean the addition of typescript to the examples here, to ensure the NAPI addon remains compliant and is instantly aware of changes to the @webgpu spec.

@dcerisano
Copy link
Contributor Author

dcerisano commented Jul 24, 2020

The CTS testing for WebGPU-NAPI is proceeding with Kai at Google.
Good news is many of the CTS tests are passing!

Getting an error here, looking into it now. Any suggestions?
I am using a fork of this repo that builds directly against Dawn (the July 10 version)

FATAL ERROR: Error::New napi_get_last_error_info
1: 0x8fb090 node::Abort() [node]
2: 0x8fb0dc [node]
3: 0x8fdc59 [node]
4: 0x90a24b napi_fatal_error [node]
5: 0x7efbf54be1bd [/home/dcerisano/git/cts/third_party/dawn/linux/index.node]
6: 0x7efbf54be76f Napi::Error::New(napi_env__) [/home/dcerisano/git/cts/third_party/dawn/linux/index.node]
7: 0x7efbf55220bf [/home/dcerisano/git/cts/third_party/dawn/linux/index.node]
8: 0x7efbf52fd3cc [/home/dcerisano/git/webgpu-napi/generated/0.0.1/linux/build/Release/libdawn_native.so]
9: 0x7efbf52fd76f [/home/dcerisano/git/webgpu-napi/generated/0.0.1/linux/build/Release/libdawn_native.so]
10: 0x7efbf52f2165 [/home/dcerisano/git/webgpu-napi/generated/0.0.1/linux/build/Release/libdawn_native.so]
11: 0x7efbf550f710 GPUBuffer::mapReadAsync(Napi::CallbackInfo const&) [/home/dcerisano/git/cts/third_party/dawn/linux/index.node]
12: 0x7efbf551fef2 GPUDevice::createBufferMapped(Napi::CallbackInfo const&) [/home/dcerisano/git/cts/third_party/dawn/linux/index.node]
13: 0x7efbf5522f8b Napi::ObjectWrap::InstanceMethodCallbackWrapper(napi_env__
, napi_callback_info__)::{lambda()#1}::operator()() const [/home/dcerisano/git/cts/third_party/dawn/linux/index.node]
14: 0x7efbf5522eba Napi::ObjectWrap::InstanceMethodCallbackWrapper(napi_env__
, napi_callback_info__) [/home/dcerisano/git/cts/third_party/dawn/linux/index.node]
15: 0x906e35 [node]
16: 0xb9160f [node]
17: 0xb92179 v8::internal::Builtin_HandleApiCall(int, v8::internal::Object**, v8::internal::Isolate
) [node]
18: 0x21c116dbe1d

@kainino0x
Copy link

@dcerisano so you were able to reproduce that issue locally? What did you change to make that issue start happening?

@dcerisano
Copy link
Contributor Author

dcerisano commented Jul 27, 2020

I had the LD_LIBRARY path set to the latest build of Dawn. The binaries in the PR are from July 10. We need to roll upstream Dawn changes into WebGPU-NAPI on a regular basis. I included a build.sh in our fork that builds the July 10 version of Dawn (will make it a submodule eventually). Dawn does not have tags, so referencing by commit SHA for July 10.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants