Previously the Metal backend used a manual mutex system to make sure the
BufferSetSubData didn't have data races with reads from the GPU. Replace
this with a non-hacky version
- Make the Buffer objects allocated on the GPU
- Make SetSubData use a ResourceUploader that allocates a CPU buffer
and schedules a CPU->GPU copy.
- Have a list of pending commands and a finished command serial to
order operations and track when resource become unused.
No functional changes intended, but there are a couple additional
cleanups:
- Use anonymous namespaces instead of static functions
- Don't store an extra Device pointer in objects
Unfortunately you can't template on const-ness in C++ so we have to
duplicate all the iterator code for SerialQueue (that, or introduce very
heavy templating).
We want to test BufferMapRead validation using the null backend. To get
closer to conditions on a real backend, we call the callback only on the
next Queue::Submit. This is because on real backends, we would have to
wait for the GPU to be finished with the buffer, to be sure the correct
data is read.
- defaults to depth and stencil tests off
- whether or not depth and stencil tests are enabled is inferred from the comparison functions and stencil operations
- only one stencil reference. D3D12 does not support separate references
- change SetDepthWriteMode to SetDepthWriteEnabled and use a bool instead of enum
- Create PersistentPipelineState class for OpenGL backend with simple state tracking
- Add validation so DepthStencilState properties are only set once
- Update API usage in HelloDepthStencil
- refactor tracking of the DepthStencilState in the Metal backend
- validate that compute pipeline does not have a depth stencil state
Add depth and stencil tests. This is currently only implemented for the
OpenGL API. HelloDepthStencil is a test using the depth and stencil
buffers to do reflections. Currently clearing / stencil clearing is not
working properly.
This makes sure it works correctly with the ScanForward Math type.
However this isn't a very good fix, the right solution would be to
detect whether we are compiling in 32bit or 64bit and use one of
ScanForward32 or ScanForward64.
