Probably not the most efficient implementation, but works.
Issues:
* Doesn't seem to render until the second frame. No clue why, yet.
* Hardcoded 640x480 in more places.
* Creates new FBOs for every subpass every frame. Should be done at Framebuffer build or CommandBuffer build time.
This helps Visual Studio users have less clutter in their solution
explorer. This also updates spirv-tools to a newer version that folders
itself. This also updates spirv-headers so that spirv-tools compiles.
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.
Buffers with MapRead allowed are created on the READBACK heap and always
add the D3D12_RESOURCE_STATE_COPY_DEST state (required by D3D12).
Likewise MapWrite adds the D3D12_RESOURCE_STATE_GENERIC_READ state and
places resources on the UPLOAD heap. Because these states are
required, transitions for mapped buffers do nothing.
This makes rendering of the samples have the wrong colors on the Metal
backend, but using BGRA made end2end tests fail. The rendering color
will be fixed when the WSI is introduced.
Extract descriptor offset computation and CPU descriptor recording to
BindGroupLayout and BindGroup. Refactor descriptor heap allocation to
copy from a large CPU heap to a GPU heap.
Visual Studio 2017 is able to build CMake-based projects directly be
opening the folder containing the CMakeLists.txt. However when doing
this shaderc is not able to find the Python executable (it uses
find_program instead of the special Python CMake module). Help shaderc
by setting the PYTHON_EXE variable before including its CMakeLists.txt
Kai Ninomiya
Corentin Wallez
Austin Eng
Kai Ninomiya