OpenGL (Vulkan ?) port

[vlj]

I've ported TressFX 2 a year ago to OpenGL here :
https://github.com/vlj/YAGF/tree/master/examples/TressFX
It's using a simple framework I wrote while learning DX12.

The TressFX 2 SDK was included with an AMD helper library for D3D11 which loaded Ruby's head mesh, and enabled an UI controlling some parameters. Is there a port of this library on top of OpenGL or Vulkan ? It would ease integrating my GL port to the official SDK if maintainers agree.

[khillesl-AMD]

Wow! That's fantastic! (I confess I didn't actually try it yet, but it looks like you've done the right things to make it work - and that's no small undertaking).

We may not implement that same helper library in multiple APIs, but we do intend to make the sample more cross-API friendly (as well as TressFX itself, which we also want more cross-engine friendly). I can't say when, though.

[spacekookie]

I am curious about this. Wherever I've gone and read stuff about GPUOpen (including the current wikipedia article) it's said that Linux was one of the supported operating systems.

However the current code base only contains DX11 code (and thus...less than ideal for Linux compatibility :P ). Was that just always the case with TressFX or is the information about GPUOpen on wikipedia wrong?

And...in either case, what's your roadmap when it comes to OpenGL/ Vulcan?

[jstewart-amd]

From a GitHub Organization standpoint, there are three parts to GPUOpen:

1. Effects
2. Libraries & SDKs
3. Tools

You can find GPUOpen projects that run on Linux in Libraries & SDKs and Tools. For example:

• Anvil
• CodeXL

Effects are currently DX11-only, because they are primarily targeted at game developers, and DX11 was the dominant (by far) API on PC at the time the effects were first developed.

Now that the industry is moving to DX12 and Vulkan, these effects will be updated to the new APIs. But it's too early in the process to lay out a specific roadmap for you.

Regarding @vlj's original question, the utility code referred to in the original post is a combination of AMD_SDK from AMD and DXUT from Microsoft. All of that code is on GitHub under the MIT license, and so any motivated community member can do their own port. A DX12/Vulkan DXUT would be super handy. :)

[vlj]

I'm porting TressFX to vulkan using my previous code, I'll need to catch up with the improvements made in 3.0 (skinning support) and 3.1. I'll use a custom app to see the result though instead of a "VKUT" (which would take much more time to port unfortunatly)

[khillesl-AMD]

That's great! I'd suggest prioritizing "shortcut" in 3.1 over the skinning.

[vlj]

I finished most of the port, however according to render doc the simulation part takes 8ms to execute instead of around 1ms with dx11 sample. On the other hand the ppll OIT part takes the same amount of time.

Are buffer barrier important in vulkan? I take care of image layout transition and access mask however I have no idea if buffer access mask do something in the driver. At the moment the debug layer don't complain and it works fine but it might help performance.

[vlj]

With buffer barrier Sim perf went to 3ms instead of 8. It's still twice as much as dx11 but maybe it's because of some parameter mismatch.

[vlj]

I have an issue about shortcut code, it does atomic operation on a 16 bits float buffer but glsl doesn't accept non 32 bit atomic operation. I'm extending the size to 32 bits uint but it will increase bandwidth consumption.

[vlj]

I've added wip here : #21

[vlj]

I updated the PR.

[PooyaEimandar]

Hi there
What is the current status of vulkan port?