summaryrefslogtreecommitdiff
path: root/tools/gfx/cpu/render-cpu.cpp
AgeCommit message (Collapse)Author
2021-04-29`gfx` DebugCallback and debug layer. (#1822)Yong He
* `gfx` DebugCallback and debug layer.
2021-04-24Remove resource `Usage` from `gfx` interface. (#1813)Yong He
* Fix `model-viewer` crash when using Vulkan. Fixing an issue in shader object layout creation for to make sure a correct descriptor set layout is calculated for types that need an implicit constant buffer. * Fix formatting. * Fixes. * Fix memory leak in vulkan. * Remove resource `Usage` from `gfx` interface.
2021-04-08Improve robustness of gfx lifetime management. (#1788)Yong He
* Improve robustness of gfx lifetime management. * fix clang error * fix clang error * Fix clang warning
2021-04-05Transient root shader object. (#1782)Yong He
2021-03-31`gfx` explicit transient resource management. (#1774)Yong He
2021-03-24Reimplement Vulkan shader objects. (#1764)Yong He
* Reimplement Vulkan shader objects. This change reimplements Vulkan shader objects in the `gfx` layer so that it is no longer layered on top of the `DescriptorSet` abstraction. Since this is the last implementation that uses `DescriptorSet`, the change also removes all `DescriptorSet` related API from public `gfx` interface. The Vulkan implementation now passes all test cases, but it still have two issues: 1. The PushConstant setting is not correct, this is because we don't seem to be able to get correct reflection data about the size of push constants for an entry-point. 2. The `shader-toy` example can't run on Vulkan, because it currently sets nullptr to `Texture` bindings, and this change doesn't properly handle setting resource to null in `ShaderObject`s yet. If we can use the `nullDescriptor` feature on vulkan, this implementation will be simple. However we still want to decide whether we want to use a Vulkan 1.2 feature for this. * Fix up
2021-03-18Remove `DescriptorSet` from D3D11 and GL devices. (#1761)Yong He
2021-03-12Cleanup CPU renderer. (#1752)Yong He
2021-03-12Add a CPU renderer implementation (#1750)Tim Foley
* Add a CPU renderer implementation This change adds a CPU back-end to `gfx` and ensures that most of our existing CPU tests pass when using it. Detailed notes: * Most of the CPU renderer implementation is copy-pasted from the CUDA case, so they share a lot of similar logic * The main addition to the CPU renderer is a semi-complete implementation of host-memory textures. The logic here handles all the main shapes (Buffer, 1D, 2D, 3D, Cube) and all the currently-supported `Format`s that are sample-able as-is (no D24S8). The implementation is not intended to be fast, and it currently only does nearest-neighbor sampling, but otherwise it tries to avoid cutting too many corners and should be ar reasonable starting point for a more complete (but not performance-oriented) implementation. * Refactored the CPU prelude `IRWTexture` interface to inherit from `ITexture`, since in most cases a single type will end up implementing both. It might be worth it to collapse it all down to a single interface later. * Changed the CPU prelude `ITexture`/`IRWTexture` interface so that it takes both a pointer *and* a size for output arguments. This change seems necessary to allow a shader variable declared as a `Texture2D<float>` to fetch a single `float` when the underlying texture might be using RGBA32F. * Added to the `IComponentType` public API so that we can query a "host callable" for an entry point and not just a binary. * Turned off the `-shaderobj` flag on two tests that weren't yet compatible with shader objects but still had the flag left in on the path (since previously the CPU path always used the non-`gfx` non-shader-object logic anyway) * Disabled one test (`dynamic-dispatch-11`) that relied on the `ConstantBuffer<IInterface>` idiom that we know we are planning to chagne soon anyway. * Made a few changes to the CUDA path to bring it into line with what I added for the CPU path. These were mostly bug fixes around indexing logic for sub-objects and resources. * fixup