Add a project for Vulkan port. #21
Conversation
|
I updated the PR. I also fixed several bug from previous version : shortcut algorithm doesn't have random black point anymore, tangent computation is now split in a separate compute shader. The PR can be reviewed now I think. |
|
Thanks, @vlj. We will review this shortly. |
|
Any updates? |
|
I haven't got around to review it yet. Hope is to do get some time next week. |
| @@ -167,10 +184,18 @@ struct TressFX_HairBlob | |||
|
|
|||
| struct TressFX_SceneMesh | |||
| { | |||
| #ifndef VULKAN | |||
There was a problem hiding this comment.
Please change this to something like
#if AMD_TRESSFX_VULKAN
#elif AMD_TRESSFX_DIRECT3D11
#else
#error
#endif
| VkResult vr; | ||
| // Create the screen quad vertex buffer(use StandardVertex for simplicity) | ||
| const StandardVertex screenQuad[6] = { | ||
| {XMFLOAT3(-1.0f, -1.0f, 0.0f), XMFLOAT3(0.0f, 0.0f, 0.0f), |
There was a problem hiding this comment.
Seems like it would be easier to create a screen-covering triangle: https://anteru.net/blog/2012/03/03/1862/ Doesn't need any buffers to start with!
|
First of all: Thanks for the contribution! I've looked at the code (haven't actually run or profiled the thing yet) and found a couple of issues - could you please take a look at them? |
|
Sorry for the delay, I updated the PR following some of your comments. I will break some functions into smaller part later but in the meantime you can have a look at the code. By the way TressFX currently relies on DirectX11.h for some types, namely UINT and the XMMATRIX/XMVECTOR... however directxmath is available with an open source licence here : https://github.com/Microsoft/DirectXMath |
vlj
force-pushed
the
vulkan
branch
3 times, most recently
from
68d9d2d to
84ff715
Compare
|
Any progress? |
Here is the current state of my Vulkan port. It's based the master branch from may hence the conflicts.
The classic TressFX algorithm is implemented as well as the Shortcut version (but not the deterministic variant). The skinned version is not implemented.
It follows the DX11 interface as much as possible. SRV are replaced with ImageView and d3d context with command Buffer and extra parameters were added to switch between constant buffers (to avoid synchronisation). Since the command buffer creation is left to the user it's possible to run simulation and rendering on separate command buffers and submit them on different queue.
Calling multiple time Asset load/processing is likely not safe since there is no lifetime tracking. I think the API should be extended to free some resources like Mesh or render target without having to release the TressFx object.
I initially write the TressFX algorithm with a single renderpass but I finally use separate passes because I wasn't sure buffer were properly flushed without an explicit barrier. It didn't change performance as far as I can tell so I opted for the safest path.
Performance wise the rendering part is as fast as DX11 code on a HD 7750 and on a geforce card. The simulation is slower : it takes 3ms instead of 1ms on the hd 7750 and even more on the geforce, I will switch to storage buffer instead of image buffer in the compute shader to see if it solves the performance.
Compatibility wise the algorithm works as expected on radeon card. Congrats for the state of your vulkan implementation ! On geforce card using uniform buffer inside a compute shader is hanging the gpu so I had to use storage buffer to store constant data. It didn't change performance on radeon.
There is also a small bug where some random pixels are not drawn, I wonder if it's not an issue with stencil op.
I wrote a very basic viewer using a custom framework here : https://github.com/vlj/YAGF it's the "TressFX.Vulkan" project.
I wrote a small script in python that replaces include and transform spv file into a single precompiled .h file. I still have to figure out how to integrate amd_tressfx_vulkan properly with premake.