» Dynamic DX11 Buffers in VL
This site relies heavily on Javascript. You should enable it if you want the full experience. Learn more.

Dynamic DX11 Buffers in VL

Dynamic Buffers

Current vvvv alpha and upcoming vvvv beta36 has a new set of nodes that allows you to quickly upload data from VL to the graphics card. We had a WIP forum discussion about it here: VL - Custom Dynamic Buffer

On the VL side the nodes are called ToBufferDescription and we have them for the basic data types that usually hold big chunks of data: Spread, Array, IntPtr and Stream. The vvvv side is rather easy and only has one node called UploadBuffer (DX11.Buffer).

Primitive Data Types

Primitive types work out of the box and don't need any special treatment. Just make sure you define the correct Buffer type in the shader. This works for Integers, Floats, Vectors and so on, everything that is available in the shader as primitive type. Here is an example for Float32:

The only exception is Matrix it needs to be transposed in order to work like a normal transformation input. If you send a large amount of individual matrices to the shader the most efficient way is to do the transpose in the shader directly:

If the same matrix is re-used very often or you don't have access to the shader code simply transpose in VL:

Custom Data Types

If you want to define your own data types like light information or a custom vertex type in the shader then you need to pack the data accordingly in the buffer description. For this task the ToBufferDescription (Stride) nodes are used. They allow you to make a buffer description out of primitive types like float or even byte and set the stride size of your custom type in bytes so that the shader can read the custom type directly out of the buffer.

Matrix hint: If you define a matrix in a custom type in the shader you can use the row_major modifier to automate the transpose operation.

struct MyLightType
{
    float3 Direction;
    float Brightness; 
    row_major float4x4 Transformation; //set matrix type
};

Performance hint: If you can, design your custom types in a way that the byte count is a multiple of 16, sometimes it makes sense to insert unused floats as padding:

//would have 20 bytes, but blown up to 32 bytes (2 x 16) for faster read performance
struct Circle
{
    float4 Position;
    float  Radius;
    float pad0;
    float pad1;
    float pad2;
};

More info: https://developer.nvidia.com/content/understanding-structured-buffer-performance

Custom types in C#

If you are a C# coder you can also define a struct in C# with attribute StructLayout(LayoutKind.Sequential) and the same byte layout, import it in VL and pass that directly into the buffer. Then you don't need the node with version StrideSize because the data type size already matches.

[StructLayout(LayoutKind.Sequential)]
public struct Circle
{
    public Vector4 Position;
    public float Radius;
    float pad0;
    float pad1;
    float pad2;
 
    public Circle(Vector4 position, float radius)
    {
        Position = position;
        Radius = radius;
    }
}

Dynamic Raw Buffers

While in the process of doing the dynamic buffer nodes it was easy to add raw buffers. These buffers are from older shader models and can only be filled with bytes. On the shader side however you can also define Custom types. Only difference in HLSL is that you write Buffer<YourType> instead of StructuredBuffer<YourType>.

The node set is basically the same except that the VL part is not generic and only accepts bytes as input. The node names are ToRawBufferDescription in VL and UploadBuffer (DX11.Buffer Raw) in vvvv.

Raw buffers have no advantage except when you have to deal with an older graphics card, driver or shader code.

Examples

A VL patch with shader code can be found in latest alphas girlpower\VL\DX\DynamicBuffersAndTextures.v4p. And it is also used by @mburk for material management in his latest superphysical pack.

So now you can start sending your data up to the card and enjoy the speed. As always, if any questions arise hit us up in the forums.

yours,
devvvvs

tonfilm, Thursday, Feb 1st 2018 Digg | Tweet | Delicious 3 comments  
velcrome 17/05/2018 - 21:50

This is really cool and I think I will try to use it in our current project.

Found a really cool Game of Life easteregg inside, much much appreciated.

Was there a reason why you could not implement UploadBuffer (DX11.Buffer) in vl too? I ask because I am interested in the nitty-gritty technical details, why the actual gpu upload was eventually moved out of vl to this (proprietary) vvvv plugin.

Game of Life looks great in VL after all, including easy array swapping. Much recommended reading material I'd say.

could not resist:

PatchSnippet

Elias 18/05/2018 - 13:53

I think the reason was that one needs to implement the IDX11ResourceHost interface for it to work. This interface would need to be implemented by the VL hosting layer and forwarded to the VL node itself.

tonfilm 18/05/2018 - 13:56

Yes that is right, it would be rather complicated to implement the interfaces, also we wanted to avoid the dependency to vvvv and DirectX in VL.

  • 1

anonymous user login

Shoutbox

~2h ago

io: A vvvvery vvvvriendly vvvvestival, ed. 2018 http://keroxen.com/

~1d ago

microdee: @synth: use beta37 for Notuiv and install it with vpm. this article describes why md.ecosystem-update

~1d ago

mburk: @synth Check github for superphysical Beta37. Deferred+Forward Branch.

~2d ago

synth: Getting red nodes on VL stuff, mostly SuperPhysical, Notuiv and CraftLie. Only me or there is something broken?

~2d ago

joreg: reminder: we'll do a #vvvv #vl workshop as part of #retune18 in #berlin this friday: vvvvvl-workshop-at-retune-2018 #visualprogramming #dotnet

~6d ago

tonfilm: how about debugging your #dx11 #GPU frames? debug-dx11-frames-with-nvidia-nsight

~8d ago

mrboni: Anyone know where I can get an Etherdream ILDA unit in the UK / West Europe delivery this week?https://ether-dream.com/

~9d ago

tobyk: @catweasel Re:KiNet yes, its pretty similar to artnet but with some different magic numbers. I can send you what I've used before.

~10d ago

microdee: @Hadasi: "read the field manual" I knew a slightly more explicit version of that abbreviation :D