D3D debug layer uses the descriptor size (width) to
validate CBV bounds when directly allocating UBOs.
This causes validation failure when the buffer size
is misaligned (ie. not a multiple of 256B) even
through the underlying resource heap size is always
64KB aligned.
This change always aligns the buffer size to be 256B
to avoid such validation error should sub-allocation
fail.
BUG=dawn:506
Change-Id: Ic9072934cac65cfd25d0e2a20cb364bd3ca88e3b
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/26820
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: Bryan Bernhart <bryan.bernhart@intel.com>
Done by:
- Appending an extra newline at the end of src/**/*.{cpp,h,mm,gn}
except src/tests/*
- Running git cl format --full to format the full contents of every
changed file
Bug: none
Change-Id: Id88fc5ed0c5efbbc93b2c6a305c2f98465fe646d
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/24641
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: Kai Ninomiya <kainino@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>
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>
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>
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 adds the formats to dawn.json, implements support in the Vulkan
backend and adds tests performing basic sampling checks for all formats.
The R8UnormSrgb and RG8UnormSrgb formats skipped because they are not
required in Vulkan (and RG8UnormSrgb is in fact not supported on the
machine used for developing this CL). A PR will be sent to the WebGPU
repo to remove the from the initial list of formats.
The RG11B10Float and RGB10A2Unorm formats of WebGPU are replaced with
B10GR11Float and A2RGB10Unorm that are the formats exposed by Vulkan. It
is likely that all APIs implement them with components stored in that
order.
Each format except depth-stencil ones is tested by uploading some
interesting texel data and checking that sampling from the texture
produces correct results. The goal is to make sure that backends don't
make a mistake in the giant switch statements. There was no effort made
to check the hardware implementation of the formats.
Tests will later be extended to cover rendering and clearing operations
as well as multisample resolve.
It isn't clear if depth-stencil format will support TRANSFER operations
in WebGPU so these are left untested for now.
BUG=dawn:128
Change-Id: I78ac5bf77b57398155551e6db3de50b478d69452
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/8363
Reviewed-by: Austin Eng <enga@chromium.org>
Reviewed-by: Jiawei Shao <jiawei.shao@intel.com>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
This will be used to test NaN is correctly sampled from float16
textures.
BUG=dawn:128
Change-Id: I6e3b79f438e9a48c3a167ab45baf9f9d019ce48b
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/8361
Commit-Queue: Kai Ninomiya <kainino@chromium.org>
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
* clang/gcc: enable -pedantic warnings
* suppress a GCC-specific warning in stb_image
* And some clang-specific warnings
* -Wconversion (clang) -Wold-style-cast (clang+gcc)
and fix a few warnings that show up with these (and a few more with
-Wconversion on gcc, even though that's not enabled by default)
* bunch more warnings
* fixes
* remove merge error
This macro has some advantages over the standard library one:
- It prints the place where the macro was triggered
- It "references" the condition even in Release to avoid warnings
- In release, if possible, it gives compiler hints
It is basically is stripped down version of the ASSERT macros I wrote
for the Daemon engine in src/common/Assert.h
This commit also removes the stray "backend" namespaces for common/
code.
This directory used to contain both the state tracking code for the
backends, and the common utilities that could be used both by the
backends and the rest of the code. Things are now:
- src/common is utility code for the whole repo
- src/backend contains libNXT's code
- src/utils is utility code that we don't want in libNXT
This commit also changes all includes to use global paths from src/
bacause it had to touch a bunch of #include statements anyway.
