This was found during some changes in Google3.
Also renames BitsPerWord to kBitsPerWord.
Bug:
Change-Id: I80cfe3a391963c2da376a7d8eadfc2797df01894
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/19286
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
Rendering +-INIFNITY with these formats results in a NaN when using
Swiftshader. Temporarily disable these tests while the Swiftshader issue
if being resolved.
Bug: dawn:283
Bug: swiftshader:147
Change-Id: I6e7c91ff72d0b4b6423175f5ab8586fdea42bb53
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/19083
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
Skia uses more warnings than Dawn, enable in Dawn directly so that
rolls of Dawn into Skia don't introduce warnings. These warnings
seem useful anyway.
Bug: chromium:1064305
Change-Id: I13dc776af84151131584a95caeee2cd21ae80fea
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/18964
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
This reverts commit c7f454c24191131eb29b8f33f0e9d5b1702fd289
and relands commit 2479860e4bb0ef5a12d269557a088bace53f0f30.
> D3D12: Stage BindGroups on CPU descriptor heaps.
>
> Instead of directly populating GPU heaps, pre-encoded
> BindGroups are staged on CPU heaps then copied over
> to the GPU. Non-shader visible allocators are stored
> on the BGL, which hands out fixed-size chunks to
> simplify memory managment. To enable memory re-use,
> CPU allocations are tied to the lifetime of BindGroup
> objects.
Reason for revert: We can reland this CL now that the CTS suppression merged.
Note: Adds validation to ensure binding size > 0.
Bug: dawn:155
Bug: dawn:375
Change-Id: I75b9773bbb7c70bcea803a7ad8b6480d21ea90f7
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/18904
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: Kai Ninomiya <kainino@chromium.org>
This reverts commit 2479860e4bb0ef5a12d269557a088bace53f0f30.
Reason for revert: Causes WebGPU CTS failures
Original change's description:
> D3D12: Stage BindGroups on CPU descriptor heaps.
>
> Instead of directly populating GPU heaps, pre-encoded
> BindGroups are staged on CPU heaps then copied over
> to the GPU. Non-shader visible allocators are stored
> on the BGL, which hands out fixed-size chunks to
> simplify memory managment. To enable memory re-use,
> CPU allocations are tied to the lifetime of BindGroup
> objects.
>
> BUG=dawn:155
>
> Change-Id: I402e6686c96f7450a077c627c8499600979e426c
> Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/18100
> Commit-Queue: Bryan Bernhart <bryan.bernhart@intel.com>
> Reviewed-by: Corentin Wallez <cwallez@chromium.org>
TBR=cwallez@chromium.org,enga@chromium.org,rafael.cintron@microsoft.com,bryan.bernhart@intel.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: dawn:155
Change-Id: I3dfae3e15e2bc21de692513725c9cf3ca38110b5
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/18860
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Instead of directly populating GPU heaps, pre-encoded
BindGroups are staged on CPU heaps then copied over
to the GPU. Non-shader visible allocators are stored
on the BGL, which hands out fixed-size chunks to
simplify memory managment. To enable memory re-use,
CPU allocations are tied to the lifetime of BindGroup
objects.
BUG=dawn:155
Change-Id: I402e6686c96f7450a077c627c8499600979e426c
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/18100
Commit-Queue: Bryan Bernhart <bryan.bernhart@intel.com>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Fixes compiler error on Linux about bare nullptr_t not existing.
Bug:
Change-Id: I1eb97d40e9ff564775d4ec7bbc54430481475f34
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/18320
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Ben Wagner <bungeman@chromium.org>
Previously the surface extensions were only enabled so we could import
VkSurfaceKHR's created from GLFW. To implement the webgpu.h
surface-based swapchains, we are going to use the extension entrypoints
too.
This changes vulkan_platform.h to set defines that make vulkan.h expose
the entrypoints and datatypes for all the Vulkan extensions we might
care about for a given compilation configuration.
Bug: dawn:269
Change-Id: If4202ff5e31c816eccb5f5381bd36b660a3b6c5b
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/17964
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
VulkanFunctions handles the storing of Vulkan function pointers so Dawn
doesn't need the declarations for Vulkan entrypoints.
Bug: dawn:269
Change-Id: I25f05d4a82fd31a60b22257261e940ce276f5eac
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/17960
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
A Chromium's LinkedList class to Dawn. Implementation and header are
a direct copy/paste. This is to be used to implement an LRU Cache
for the ResidencyManager class.
Bug: dawn:193
Change-Id: I7cb02649590be4db0fe54c9d80557ac49efc34de
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/16380
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
Adds CMake support for:
- Generating the Dawn headers and C++ wrappers
- libdawn_wire
- libdawn_native with the Metal backend for now
- All the examples.
Bug: dawn:333
Change-Id: I6ffbe090b0bd21d6a805c03a507ad51fda0275ca
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/15720
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Dan Sinclair <dsinclair@chromium.org>
Overriding VK_DEFINE_NON_DISPATCHABLE_HANDLE changes the function
signatures of Vulkan functions, changing their ABI and making us
incompatible with real drivers. This removes that magic, and replaces it
with an explicit wrapper, VkHandle, which has much of the same
functionality as the original VkNonDispatchableHandle.
It adds definitions for dawn_native::vulkan::VkBuffer et al, which
shadow the native ::VkBuffer et al. This retains type safety throughout
the Vulkan backend without changing every single usage.
Notably, the following things had to change:
- An explicit conversion from VkBuffer* to ::VkBuffer* is needed for
arrays. This is implemented as a reinterpret_cast, which is still
safe as the new VkHandle still has the same memory layout properties
as VkNonDispatchableHandle did.
- When pointing to a VkHandle as an output pointer, it's now necessary
to explicitly get the native ::VkBuffer (via operator*) and point to
it.
Previously reviewed on:
https://dawn-review.googlesource.com/c/dawn/+/15580
Bug: chromium:1046362
Change-Id: I7d34ec38a805025f92165ea9a7ee07ae5c182076
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/15641
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Commit-Queue: Kai Ninomiya <kainino@chromium.org>
This reverts commit 4e17d5c2483b63d4863162d692a1a961d1dcb958.
Reason for revert: broken on chromeos
Original change's description:
> Remove VK_DEFINE_NON_DISPATCHABLE_HANDLE magic, use explicit VkHandle wrapper
>
> Overriding VK_DEFINE_NON_DISPATCHABLE_HANDLE changes the function
> signatures of Vulkan functions, changing their ABI and making us
> incompatible with real drivers. This removes that magic, and replaces it
> with an explicit wrapper, VkHandle, which has much of the same
> functionality as the original VkNonDispatchableHandle.
>
> It adds definitions for dawn_native::vulkan::VkBuffer et al, which
> shadow the native ::VkBuffer et al. This retains type safety throughout
> the Vulkan backend without changing every single usage.
>
> Notably, the following things had to change:
> - An explicit conversion from VkBuffer* to ::VkBuffer* is needed for
> arrays. This is implemented as a reinterpret_cast, which is still
> safe as the new VkHandle still has the same memory layout properties
> as VkNonDispatchableHandle did.
> - When pointing to a VkHandle as an output pointer, it's now necessary
> to explicitly get the native ::VkBuffer (via operator*) and point to it.
>
> Bug: chromium:1046362
> Change-Id: I9c5691b6e295aca1b46d4e3d0203956e4d570285
> Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/15580
> Reviewed-by: Austin Eng <enga@chromium.org>
> Reviewed-by: Kai Ninomiya <kainino@chromium.org>
> Commit-Queue: Kai Ninomiya <kainino@chromium.org>
TBR=cwallez@chromium.org,kainino@chromium.org,enga@chromium.org
Change-Id: I500df2e34fd0f245ad04c517ff028ddd7bb5a2bf
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1046362
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/15620
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Commit-Queue: Kai Ninomiya <kainino@chromium.org>
Overriding VK_DEFINE_NON_DISPATCHABLE_HANDLE changes the function
signatures of Vulkan functions, changing their ABI and making us
incompatible with real drivers. This removes that magic, and replaces it
with an explicit wrapper, VkHandle, which has much of the same
functionality as the original VkNonDispatchableHandle.
It adds definitions for dawn_native::vulkan::VkBuffer et al, which
shadow the native ::VkBuffer et al. This retains type safety throughout
the Vulkan backend without changing every single usage.
Notably, the following things had to change:
- An explicit conversion from VkBuffer* to ::VkBuffer* is needed for
arrays. This is implemented as a reinterpret_cast, which is still
safe as the new VkHandle still has the same memory layout properties
as VkNonDispatchableHandle did.
- When pointing to a VkHandle as an output pointer, it's now necessary
to explicitly get the native ::VkBuffer (via operator*) and point to it.
Bug: chromium:1046362
Change-Id: I9c5691b6e295aca1b46d4e3d0203956e4d570285
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/15580
Reviewed-by: Austin Eng <enga@chromium.org>
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Commit-Queue: Kai Ninomiya <kainino@chromium.org>
The _BitScanReverse64 intrinsic only exists when compiling for 64bit.
Replace it by two calls to _BitScanReverse (the 32bit one) when on
32bit.
Bug:
Change-Id: Ie294327ec914b0ca4a73732e4b78c1f2a08f100f
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/15321
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
This is another step to implement webgpu.h swapchains, Surface is
essentially a union type of all the types of windows that can be used to
create swapchains.
Changes to allow implementing wgpu::Surface and test its creation are:
- Add GLFWUtils.cpp/.h/_metal.mm that contains helpers used to use
WebGPU with GLFW. This deprecates BackendBinding.h that will be removed
when the NXT swapchain is removed.
- Add a `dawn_use_x11` GN variable to factor all the places in BUILD.gn
where we checked whether we should use X11.
- Add a `supports_glfw_for_windowing` GN variable in the main BUILD.gn
file to control which configuration tests and samples using GLFW can be
built.
- Add a ObjCUtils.h to contain some ObjC functionality that we'd need
in files that otherwise would be C++ (so that they can be compiled on
all platforms).
Bug: dawn:269
Change-Id: I25548142a1d1d1f05b0f4d71aa3bdc4698d19622
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/15081
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
The way in which the Result class is used in Dawn can be fragile
with respect to memory management because the caller of AcquireError
must know they need to delete the returned pointer or a memory leak
will occur. We've had a couple of instances where developers have
accidentally left out the delete call and managed to get past code
review.
This CL changes the Result class so that it assumes the error is
allocated on the heap and forces the caller to use unique_ptr when
calling AcquireError.
Bug:dawn:320
Change-Id: I13ec953b0c37eaafbd6ce93c2f719b4743676acb
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/14960
Reviewed-by: Austin Eng <enga@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Rafael Cintron <rafael.cintron@microsoft.com>
Due to significant performance regressions on Intel Gen11 Graphics,
temporarily disable use of the D3D12 Render Pass API until a workaround
infrastructure can be implemented.
Bug: dawn:310
Change-Id: I994a2c2a0f6a3b61c48b083c73d6e0d3f8910dfa
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/14663
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Brandon Jones <brandon1.jones@intel.com>
Currently, when we hit an assertion failure, the fuzzer stops
immediately without producing a crash. This patch makes it so that we do
a hard abort instead which will be caught.
Bug: dawn:295, dawn:293
Fixes: dawn:293
Change-Id: Ie00074e84b51c9aa364aba96c11a35659bbba740
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/14682
Commit-Queue: Austin Eng <enga@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
This will enable fuzzing the Vulkan backend with randomly injected
errors to help ensure the backend properly handles all errors. It also
redefines VkResult in the dawn_native::vulkan namespace such that a
VkResult cannot be used unless it is explicitly wrapped.
Bug: dawn:295
Change-Id: I3ab2f98702a67a61afe06315658a9ab76ed4ccc3
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/14520
Commit-Queue: Austin Eng <enga@chromium.org>
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Inlining these hot functions decreases CPU time in perf tests for
DrawCallPerf.Run/Vulkan by roughly 12% (55 to 47ns) and increases
binary size by about 0.16% (~4kB).
Bug: dawn:304
Change-Id: I84e5d011defe88d6f1492dcb54e421c3d1bf099f
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/14000
Commit-Queue: Austin Eng <enga@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
The LogMessage::LogMessage constructor was redefining a symbol that
exists in re2 inside of Chromium. So we namespace Log inside dawn:: to
avoid the conflict.
BUG=dawn:302
Change-Id: Ida349208e2c6fe9ac032e1bd8cd442dff0b3f6bc
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/14320
Commit-Queue: Austin Eng <enga@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
On Android iostream doesn't appear in logcat, the system log that's
often used for printf debugging. Introduce Chromium/ANGLE like logging
that looks like the following:
InfoLog() << stuff << stuff;
This makes sure the message is put in logcat on Android and removes
static initializers from <iostream>
BUG=dawn:286
Change-Id: Ie0d018f49bcac1a7b740739a6e59d45ae6728638
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/14102
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: David Turner <digit@google.com>
Reviewed-by: Austin Eng <enga@chromium.org>
Deploy self-built Vulkan validation layers instead of system installed
one. And it will reuse third_party/angle's Vulkan validation layers if
building with chromium.
Bug: dawn:150
Change-Id: I94e26f7a152fb2a1c39bcb102d60024f4d65eee6
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/11120
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
More concretely this makes Result<T*, E*> able to be move-constructed
from Result<ChildClassOfT*, E*> for free.
BUG=dawn:19
Change-Id: Iea2b8997079ac3bfcf270d6b73a79cf5cac2c06f
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/11860
Reviewed-by: Austin Eng <enga@chromium.org>
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Previously dawn_native files were in src/dawn_native/ while generated
files were in dawn_native/. This makes some things complicated when
integrating in other source trees so normalize all generated files to be
in paths that match the main tree.
BUG=dawn:225
Change-Id: I5b3e04d37a16251143578dfb7a31445b229fe4ac
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/11300
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
The Fuchsia platforms relies on a number of Vulkan extensions
that have not been upstreamed to Khronos yet, and thus are not
part of the official Vulkan headers (i.e. <vulkan/vulkan.h>).
This CL adds a new header under src/common/ that contains these
declarations, extracted from the Fuchsia source tree, and ensures
they are included automatically from <common/vulkan_platform.h>
This is necessary to support certain features when building
Dawn on Fuchsia.
IMPORTANT NOTE: Some of the things declared in this header will
change once everything is upstreamed, which will require updating
the source code using them. For example,
VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_TEMP_ZIRCON_EVENT_BIT_FUCHSIA
Will likely be renamed officially as:
VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_ZIRCON_EVENT_BIT
And will be assigned a new value by Khronos.
BUG=dawn:221
Change-Id: If88a1dd06083a01d7b34b5cf5ab93f4e3f3681eb
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/10940
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: David Turner <digit@google.com>
Enable the Vulkan backend when building Dawn with
the Chromium build system for Fuchsia. To make this
work properly the following is required:
- Modify VulkanInfo.cpp and BackendVk.cpp to correctly probe
the Fuchsia swapchain layer and its layer extension, as well
as enabling them when creating a new VkInstance.
- Modify VulkanFunctions.cpp to load the Fuchsia swapchain
related extension for this platform only.
- Provide a small mock GLFW library for Fuchsia under
src/utils/Glfw3Fuchsia.cpp, since the upstream project
does not support this platform at all. Its purpose is
only to allow the creation of the right VulkanBinding
instance, which depends on the creation of a display
surface for latter swapchain creation.
- Add //third_party/fuchsia-sdk:vulkan_base and
//third_party/fuchsia-sdk:vulkan_validation as
data_deps of the libdawn_native_sources target in
order to ensure that the Fuchsia package created by
the build system will include the correct Vulkan
libraries (loader and validation layers).
This builds correctly, and both dawn_unittests and
dawn_end2end_tests will run on a real Fuchsia device
or inside the Fuchsia emulator, using either GPU
virtualization or a software-based renderer.
Note: dawn_unittests will also run inside QEMU, but
not dawn_end2end_tests, since the latter requires
proper GPU emulation which is not available in this
environment.
NOTE: All end2end tests pass using a device with
an "Intel HD Graphics 615 (Kaby Lake GT2)"
adapter. However:
- For some reason, a single test takes up
to 129 seconds to pass
(BufferSetSubDataTests.ManySetSubData/Vulkan).
- The test process crashes inside VkDestroyInstance(),
apparently inside the Fuchsia-specific imagepipe
layer (which implements swapchain support).
This is likely a bug in the layer itself, and
not Dawn.
Also, may end2end tests will crash when run inside
the Fuchsia emulator (which uses GPU virtualization
to talk to the host GPU). The crashes happen inside
libvulkan-goldfish.so, the emulator-specific Vulkan
ICD on this sytem. Not a Dawn bug either.
Bug=dawn:221
Change-Id: Id3598b673e8c6393f24db728b8da49fdde3cac76
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/8963
Commit-Queue: David Turner <digit@google.com>
Reviewed-by: Austin Eng <enga@chromium.org>
This is to match the naming convention of WebGPU's WebIDL and webgpu.h
BUG=dawn:22
Change-Id: Ia91c5a018403e6a72eb0311b5f1a072d102282a2
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/10461
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
This test was failing consistently on win-msvc-dbg and occasionally
on win-msvc-rel. It's suspected the hardware does not properly
support __lzcnt64 so the function is implemented with _BitScanReverse64.
Bug: dawn:213
Change-Id: I0712f87787aad4aad7233bfb72846ec3dba96239
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/10481
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Commit-Queue: Austin Eng <enga@chromium.org>
This CL removes undefined behavior from NextPowerOfTwo(0). Currently on
Linux, calling NextPowerOfTwo(0) simplifies down to:
- 1ull << (64 - __builtin_clzll(0 - 1));
- 1ull << (64 - __builtin_clzll(INT_MAX));
- 1ull << (64 - 0);
- 1ull << 64
Since 64 is the same width as the long long in our left operand, this
left shift results in undefined behavior (C++11 standard 5.8.1). For a
default Chrome compile, this does not cause any issues; 1ull << 64
results in 0.
In ChromeOS, however, we compile with ThinLTO which, among other things,
inlines various functions in the interest of performance. When
NextPowerOfTwo is inlined, the undefined behavior of our invalid left
shift borks the stack which causes the Math.NextPowerOfTwo unit test to
fail.
BUG= chromium:993457
TEST= verified that Math.NextPowerOfTwo now passes with LTO
Change-Id: I2702ba0b780203643da1d98ad0380098c7b3eab0
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/10180
Reviewed-by: Austin Eng <enga@chromium.org>
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Commit-Queue: Brian Ho <hob@chromium.org>
This CL updates a few flags to support Chrome OS:
- Disables the OpenGL backend on Chrome OS builds.
- Removes the X11 dependency for Chrome OS builds because we do not
support X11.
- Removes the XCB dependency (again, no X11).
BUG=chromium:993457
TEST=e2e and unit tests build and pass on Intel Chrome OS devices
Change-Id: I1cb06453ccc94d1b68a6998ea635bddd6fb7b5ad
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/10100
Commit-Queue: Kai Ninomiya <kainino@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
In a typical graphics application it is a common usage to update some uniforms once per draw,
and such uniforms include the word positions, orientations, and so on. In the current state of
WebGPU, this means that for each draw call we have to create a new bind group to set the right
uniform values. Bind group creation is expected to be more expensive than
recording draws because a memory allocation is required.
The functionality of dynamic buffer offset is to reduce the number of bind groups that need to
be created.
The patch implements dynamic buffer offset on D3D backend using root descriptor.
Bug=dawn:55
Change-Id: Ia713a4edb3c0ab8f3bba048d7813f343e9dee166
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/9040
Commit-Queue: Shaobo Yan <shaobo.yan@intel.com>
Reviewed-by: Austin Eng <enga@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Skia-dawn found these; not sure why Chrome and Dawn standalone don't.
Change-Id: I43706fbaca94d1718de0be727151dd8f3a191df2
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/9220
Commit-Queue: Kai Ninomiya <kainino@chromium.org>
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
The existing implementation of Result with tagged pointers was not able
to handle constant pointers for the result. This is required in
follow-up CLs to return internal formats in a ResultOrError.
This CL extracts the tagged pointer logic out of Result<T*, E*> so it
can be shared with Result<const T*, E*>.
Tests are also added to cover Result<const T*, E*>.
BUG=dawn:128
Change-Id: Id19ae8e1153bcfcaf94d95ac314faf2b23af6f91
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/9100
Commit-Queue: Kai Ninomiya <kainino@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
