Returning COM for getters needlessly refcounts which wastes CPU cycles
in critial sections and floods PIX traces with [Add/Release]Ref.
BUG=dawn:212
Change-Id: Ifa853f2d5f78a450fdb7ffb9492f0d08dfbcdd37
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/21364
Commit-Queue: Bryan Bernhart <bryan.bernhart@intel.com>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
RefCounted (and derived) destructors should be protected on the class
to ensure the objects can ONLY be destructed by calling Release. This
avoids errors cause by destroying objects out from under code which
has an active reference count.
Unfortunately, many of the 'base' classes must continue having public
destructors because they are used as "blueprint" objects created on
the stack.
Added final on most-derived classes.
Ideas for future improvement:
- Change "base" objects to have protected destructors but create new
blueprint objects that privately derive from base objects. This
limits the blueprint object's usefulness to only be a blueprint.
- Modify createX methods to return Ref<Object> instead of Object*
Change-Id: I6f3b3b178118d135c4342cb912e982a3873d71af
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/18780
Commit-Queue: Rafael Cintron <rafael.cintron@microsoft.com>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
BUG=dawn:301
Change-Id: Ia7982cfe40abb28ab786c8941e269bded11468ee
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/14282
Commit-Queue: Ryan Harrison <rharrison@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
This is the first step for having a fully operational SPVC usage
path. This version of SPVC integration uses SPVC for setting up the
options to the compiler, but a lot of the actual interaction with
spirv-cross is done in Dawn, just via SPVC's compiler object.
Future CLs will migrate more of the spirv-cross interaction to using
the SPVC API, eventually removing the need for Dawn to know about
spirv-cross.
BUG=dawn:288
Change-Id: I68e0773f910d7fe967235b6987b3debe1d13883f
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/14143
Commit-Queue: Ryan Harrison <rharrison@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
This is to match the work in progress webgpu.h header.
BUG=dawn:22
Change-Id: I0904297bb4411b12f9d99e8457d32613058ef9b2
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/9380
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
The contents of PipelineStageDescriptor were inlined inside of
ComputePipelineDescriptor. This changes updates
ComputePipelineDescriptor to contain PipelineStageDescriptor to match
WebGPU.
Bug: chromium:877147
Change-Id: Ic030b7bd7a237945cbbaf4c567cc361940e1ad00
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/6400
Commit-Queue: Kai Ninomiya <kainino@chromium.org>
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
When both the vert and frag shaders have a UBO binding, the D3D12
backend was using register offset 0 for both, causing a collision,
and the wrong constant value used in one of the shaders.
The fix is to use the binding offsets computed by the BindGroupLayout,
since they know about all of the bindings, not just the ones computed
for each shader. This made it necessary to defer shader compilation
until pipeline layout creation time (as is done in the Metal backend
for similar reasons).
Finally, those bindings offsets computed by the BGL include an offset
for the CBV, UAV and SRV subgroups, so we must add the same register
offset when assigning the BaseShaderRegister to the descriptor ranges
in the PipelineLayout constructor so that they match.
Bug: dawn:20
Change-Id: I18287bf1c06f06dd61288e12da64752f54634466
Reviewed-on: https://dawn-review.googlesource.com/c/1960
Reviewed-by: Stephen White <senorblanco@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Stephen White <senorblanco@chromium.org>
Linking against their .lib makes loading Dawn fail on systems that don't
have the DLLs. This happens for example on Windows7 that doesn't have
d3d12.dll. Instead we dynamically load functions pointers from these
DLLs at d3d12::Device startup.
Change-Id: I4d01a12d0f91bec45bf125450d2c08aaa9ff9fac
This includes a bunch of fixes for clang warnings in Windows specific
code that was only compiled by MSVC previously. This also tidies up some
BUILD.gn issues on Windows.
