Fix broken links in docs
Change-Id: I795fd03a34f8faeaf0bf6ac7207267cebca8a5b8 Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/132622 Reviewed-by: Corentin Wallez <cwallez@chromium.org> Kokoro: Kokoro <noreply+kokoro@google.com> Commit-Queue: Albin Bernhardsson <albin.bernhardsson@arm.com>
This commit is contained in:
Albin Bernhardsson
Dawn LUCI CQ
parent
978bc129a0
commit
04cef273d6
|
|
@ -2,11 +2,11 @@
|
|||
|
||||
Dawn relies on a lot of code generation to produce boilerplate code, especially webgpu.h-related code. They start by reading some JSON files (and sometimes XML too), process the data into an in-memory representation that's then used by some [Jinja2](https://jinja.palletsprojects.com/) templates to generate the code. This is similar to the model/view separation in Web development.
|
||||
|
||||
Generators are based on [generator_lib.py](../generator/generator_lib.py) which provides facilities for integrating in build systems and using Jinja2. Templates can be found in [`generator/templates`](../generator/templates) and the generated files are in `out/<Debug/Release/foo>/gen/src` when building Dawn in standalone. Generated files can also be found in [Chromium's code search](https://source.chromium.org/chromium/chromium/src/+/main:out/Debug/gen/third_party/dawn/src/).
|
||||
Generators are based on [generator_lib.py](../../generator/generator_lib.py) which provides facilities for integrating in build systems and using Jinja2. Templates can be found in [`generator/templates`](../../generator/templates) and the generated files are in `out/<Debug/Release/foo>/gen/src` when building Dawn in standalone. Generated files can also be found in [Chromium's code search](https://source.chromium.org/chromium/chromium/src/+/main:out/Debug/gen/third_party/dawn/src/).
|
||||
|
||||
## Dawn "JSON API" generators
|
||||
|
||||
Most of the code generation is done from [`dawn.json`](../dawn.json) which is a JSON description of the WebGPU API with extra annotation used by some of the generators. The code for all the "Dawn JSON" generators is in [`dawn_json_generator.py`](../generator/dawn_json_generator.py) (with templates in the regular template dir).
|
||||
Most of the code generation is done from [`dawn.json`](../../dawn.json) which is a JSON description of the WebGPU API with extra annotation used by some of the generators. The code for all the "Dawn JSON" generators is in [`dawn_json_generator.py`](../../generator/dawn_json_generator.py) (with templates in the regular template dir).
|
||||
|
||||
At this time it is used to generate:
|
||||
|
||||
|
|
@ -89,7 +89,7 @@ A **record** is a list of **record members**, each of which is a dictionary with
|
|||
|
||||
## Dawn "wire" generators
|
||||
|
||||
The generator for the pieces of dawn_wire need additional data which is found in [`dawn_wire_json`](../dawn_wire.json). Examples of pieces that are generated are:
|
||||
The generator for the pieces of dawn_wire need additional data which is found in [`dawn_wire_json`](../../dawn_wire.json). Examples of pieces that are generated are:
|
||||
|
||||
- `WireCmd.cpp/.h` the most important piece: the meat of the serialization / deserialization code for WebGPU structures and commands
|
||||
- `ServerHandlers/Doers.cpp` that does the complete handling of all regular WebGPU methods in the server
|
||||
|
|
@ -112,7 +112,7 @@ The schema of `dawn_wire.json` is a dictionary with the following keys:
|
|||
|
||||
## OpenGL loader generator
|
||||
|
||||
The code to load OpenGL entrypoints from a `GetProcAddress` function is generated from [`gl.xml`](../third_party/khronos/gl.xml) and the [list of extensions](../src/dawn/native/opengl/supported_extensions.json) it supports.
|
||||
The code to load OpenGL entrypoints from a `GetProcAddress` function is generated from [`gl.xml`](../../third_party/khronos/gl.xml) and the [list of extensions](../../src/dawn/native/opengl/supported_extensions.json) it supports.
|
||||
|
||||
|
||||
## Dawn lpmfuzz generator
|
||||
|
|
|
|||
|
|
@ -9,11 +9,11 @@ Example of backend facilities are GPU memory allocators or the backing API funct
|
|||
|
||||
### Error Handling
|
||||
|
||||
Dawn (dawn_native) uses the [Error.h](../src/dawn/native/Error.h) error handling to robustly handle errors.
|
||||
Dawn (dawn_native) uses the [Error.h](../../src/dawn/native/Error.h) error handling to robustly handle errors.
|
||||
With `DAWN_TRY` errors bubble up all the way to, and are "consumed" by the entry-point that was called by the application.
|
||||
Error consumption uses `Device::ConsumeError` that expose them via the WebGPU "error scopes" and can also influence the device lifecycle by notifying of a device loss, or triggering a device loss..
|
||||
|
||||
See [Error.h](../src/dawn/native/Error.h) for more information about using errors.
|
||||
See [Error.h](../../src/dawn/native/Error.h) for more information about using errors.
|
||||
|
||||
### Device Lifecycle
|
||||
|
||||
|
|
@ -26,7 +26,7 @@ The device lifecycle is a bit more complicated than other objects in Dawn for mu
|
|||
- A device can become "disconnected" when a TDR or hot-unplug happens.
|
||||
In this case, destruction of the device doesn't need to wait on GPU commands to finish because they just disappeared.
|
||||
|
||||
There is a state machine `State` defined in [Device.h](../src/dawn/native/Device.h) that controls all of the above.
|
||||
There is a state machine `State` defined in [Device.h](../../src/dawn/native/Device.h) that controls all of the above.
|
||||
The most common state is `Alive` when there are potentially GPU commands executing.
|
||||
|
||||
Initialization of a device looks like the following:
|
||||
|
|
@ -62,7 +62,7 @@ Toggles can be queried using `DeviceBase::IsToggleEnabled`:
|
|||
bool useRenderPass = device->IsToggleEnabled(Toggle::UseD3D12RenderPass);
|
||||
```
|
||||
|
||||
Toggles are defined in a table in [Toggles.cpp](../src/dawn/native/Toggles.cpp) that also includes their name and description.
|
||||
Toggles are defined in a table in [Toggles.cpp](../../src/dawn/native/Toggles.cpp) that also includes their name and description.
|
||||
The name can be used to require enabling of a toggle or, at the contrary, require the disabling of a toogle.
|
||||
This is particularly useful in tests so that the two sides of a code path can be tested (for example using D3D12 render passes and not).
|
||||
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ Dawn uses Chromium's continuous integration (CI) infrastructure to continually r
|
|||
For additional information on GPU testing in Chromium, please see [[chromium/src]//docs/gpu/gpu_testing_bot_details.md](https://chromium.googlesource.com/chromium/src.git/+/main/docs/gpu/gpu_testing_bot_details.md).
|
||||
|
||||
## Dawn CI/Try Builders
|
||||
Dawn builders are specified in [[dawn]//infra/config/global/cr-buildbucket.cfg](../infra/config/global/cr-buildbucket.cfg). This file contains a few mixins such as `clang`, `no_clang`, `x64`, `x86`, `debug`, `release` which are used to specify the bot dimensions and build properties (builder_mixins.recipe.properties). At the time of writing, we have the following builders:
|
||||
Dawn builders are specified in [[dawn]//infra/config/global/cr-buildbucket.cfg](../../infra/config/global/generated/cr-buildbucket.cfg). This file contains a few mixins such as `clang`, `no_clang`, `x64`, `x86`, `debug`, `release` which are used to specify the bot dimensions and build properties (builder_mixins.recipe.properties). At the time of writing, we have the following builders:
|
||||
- [dawn/try/presubmit](https://ci.chromium.org/p/dawn/builders/try/presubmit)
|
||||
- [dawn/try/linux-clang-dbg-x64](https://ci.chromium.org/p/dawn/builders/try/linux-clang-dbg-x64)
|
||||
- [dawn/try/linux-clang-dbg-x86](https://ci.chromium.org/p/dawn/builders/try/linux-clang-dbg-x86)
|
||||
|
|
@ -23,16 +23,16 @@ Dawn builders are specified in [[dawn]//infra/config/global/cr-buildbucket.cfg](
|
|||
|
||||
There are additional `chromium/try` builders, but those are described later in this document.
|
||||
|
||||
These bots are defined in both buckets luci.dawn.ci and luci.dawn.try, though their ACL permissions differ. luci.dawn.ci bots will be scheduled regularly based on [[dawn]//infra/config/global/luci-scheduler.cfg](../infra/config/global/luci-scheduler.cfg). luci.dawn.try bots will be triggered on the CQ based on [[dawn]//infra/config/global/commit-queue.cfg](../infra/config/global/commit-queue.cfg).
|
||||
These bots are defined in both buckets luci.dawn.ci and luci.dawn.try, though their ACL permissions differ. luci.dawn.ci bots will be scheduled regularly based on [[dawn]//infra/config/global/luci-scheduler.cfg](../../infra/config/global/generated/luci-scheduler.cfg). luci.dawn.try bots will be triggered on the CQ based on [[dawn]//infra/config/global/commit-queue.cfg](../../infra/config/global/generated/commit-queue.cfg).
|
||||
|
||||
One particular note is `buckets.swarming.builder_defaults.recipe.name: "dawn"` which specifies these use the [`dawn.py`](https://source.chromium.org/search/?q=file:recipes/dawn.py) build recipe.
|
||||
|
||||
Build status for both CI and Try builders can be seen at this [console](https://ci.chromium.org/p/dawn) which is generated from [[dawn]//infra/config/global/luci-milo.cfg](../infra/config/global/luci-milo.cfg).
|
||||
Build status for both CI and Try builders can be seen at this [console](https://ci.chromium.org/p/dawn) which is generated from [[dawn]//infra/config/global/luci-milo.cfg](../../infra/config/global/generated/luci-milo.cfg).
|
||||
|
||||
## Dawn Build Recipe
|
||||
The [`dawn.py`](https://cs.chromium.org/search/?q=file:recipes/dawn.py) build recipe is simple and intended only for testing compilation and unit tests. It does the following:
|
||||
1. Checks out Dawn standalone and dependencies
|
||||
2. Builds based on the `builder_mixins.recipe.properties` coming from the builder config in [[dawn]//infra/config/global/cr-buildbucket.cfg](../infra/config/global/cr-buildbucket.cfg).
|
||||
2. Builds based on the `builder_mixins.recipe.properties` coming from the builder config in [[dawn]//infra/config/global/cr-buildbucket.cfg](../../infra/config/global/generated/cr-buildbucket.cfg).
|
||||
3. Runs the `dawn_unittests` on that same bot.
|
||||
|
||||
## Dawn Chromium-Based CI Waterfall Bots
|
||||
|
|
@ -48,7 +48,7 @@ The Builder and Tester bots are additionally configured at [[chromium/tools/buil
|
|||
Finally, builds on these waterfall bots are automatically scheduled based on the configuration in [[chromium/src]//infra/config/buckets/ci.star](https://source.chromium.org/search?q=file:ci.star%20%22Dawn%20Linux%20x64%20Builder%22). Note that the Tester bots are `triggered_by` the Builder bots.
|
||||
|
||||
## Dawn Chromium-Based Tryjobs
|
||||
[[dawn]//infra/config/global/commit-queue.cfg](../infra/config/global/commit-queue.cfg) declares additional tryjob builders which are defined in the Chromium workspace. The reason for this separation is that jobs sent to these bots rely on the Chromium infrastructure for doing builds and triggering jobs on bots with GPU hardware in swarming.
|
||||
[[dawn]//infra/config/global/commit-queue.cfg](../../infra/config/global/generated/commit-queue.cfg) declares additional tryjob builders which are defined in the Chromium workspace. The reason for this separation is that jobs sent to these bots rely on the Chromium infrastructure for doing builds and triggering jobs on bots with GPU hardware in swarming.
|
||||
|
||||
At the time of writing, the bots for Dawn CLs are:
|
||||
- [chromium/try/linux-dawn-rel](https://ci.chromium.org/p/chromium/builders/try/linux-dawn-rel)
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ use_dawn = true # Required to build Dawn
|
|||
use_cfi_icall=false # Required because Dawn dynamically loads function pointers, and we don't sanitize them yet.
|
||||
```
|
||||
|
||||
A Chromium checkout is required for the highest optimization flags. It is possible to build and run `dawn_perf_tests` from a standalone Dawn checkout as well, only using GN arg `is_debug=false`. For more information on building, please see [building.md](./building.md).
|
||||
A Chromium checkout is required for the highest optimization flags. It is possible to build and run `dawn_perf_tests` from a standalone Dawn checkout as well, only using GN arg `is_debug=false`. For more information on building, please see [building.md](../building.md).
|
||||
|
||||
### Terminology
|
||||
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ Requirements:
|
|||
|
||||
## Building Tint with coverage generation enabled
|
||||
|
||||
Follow the steps [to build Tint with CMake](../README.md), but include the additional `-DDAWN_EMIT_COVERAGE=1` CMake flag.
|
||||
Follow the steps [to build Tint with CMake](../building.md), but include the additional `-DDAWN_EMIT_COVERAGE=1` CMake flag.
|
||||
|
||||
## Generate coverage information
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue