search

jspanchu / webgpu-dawn-binaries

12 stars 1 forks source link

Specify which version of Dawn is used #6

Open eliemichel opened 1 month ago

eliemichel commented 1 month ago

How can one know which tag/commit of Dawn repo was used to build the binary releases? I am interested in adding an option in WebGPU-distribution to fetch prebuilt binaries from your setup but I need to know precisely which daily Dawn tag is used.

jspanchu commented 1 month ago

Hey! I would suggest not yet doing that because this was merely an experiment to convince myself it could be done. Based on advice from the mailing list, after some CMake improvements are landed upstream, I will update the workflow in https://github.com/google/dawn to publish prebuilt alpha binaries (in 1-2 weeks assuming all reviews go smoothly)

How can one know which tag/commit of Dawn repo was used to build the binary releases?

Eh, you're probably not gonna like what I did here. I decided on my own about versioning dawn since I needed a proper semantic version and dawn did not have one. However chromium had them and dawn's tags directly line up with chromium's patch version.

The patch version from the release binary directly corresponds to the 'dawn@chromium/xyzw' tag. For example, in webgpu-dawn-v127.0.6535.0, it means the dawn@chromium/6535 tag was built from source.

eliemichel commented 1 month ago

Oh that's great if you're going to be able to merge this into Dawn's official mirror :) I had started doing my own version of this but you're ahead of me so I'm going to let you do it, let me know if I can help in any way!

Also having a binary release of tint would be great as well, ideally in a separate zip. :)

jspanchu commented 1 month ago

Yea, that's the end goal.

Also having a binary release of tint would be great as well, ideally in a separate zip. :)

Good idea. I have not thought about that, but should be relatively easy, libtint can be bundled up similar to webgpu_dawn.

Would be nice to upstream all of it in dawn's workflow instead of having it scattere across different repos. Since we can configure the github workflow to run on each merge, it should start setting of alarm bells among dawn devs when someone's change broke something we use outside of chromium, like your fetch_dawn_dependencies, etc.

eliemichel commented 1 month ago

Good idea. I have not thought about that, but should be relatively easy, libtint can be bundled up similar to webgpu_dawn.

I meant the tint command line tool (something like the tint_cmd target), though libtint is interesting as well (but isn't it part of libdawn already?). The tint command line tool is very handy, but the impossibility to download a prebuilt version makes any automation pipeline relying on it a bit painfull!

Would be nice to upstream all of it in dawn's workflow instead of having it scattere across different repos.

I agree, plus Dawn's continuous testing infrastructure builds it tens of time per day, only the artifacts are not made available...