» 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.

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.


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.


tonfilm, Thursday, Feb 1st 2018 Digg | Tweet | Delicious 0 comments  
  • 1

anonymous user login


~19h ago

joreg: @eglod: if not, we're doing something wrong... but did you check any of the other timeline options? animation

~19h ago

andresc4: Sometimes people finalize a project and can donate a good amount that month, but nobody knows what will happen on the next one :D

~19h ago

andresc4: @vux as @eno say, I think a 1 time payment of any given value its a good option also

~20h ago

ggml: where id the vl search algorythm implementation discussion?

~20h ago

eglod: @ catweasel, o.k. may be, I have to learn vl. Thank You catweasel! Is this possible with 84 years, what think You?

~22h ago

catweasel: I guess part of the issue, is payment is $ which means transaction fees on every payement will add up!

~1d ago

u7angel: @eno, it is a hassle for us too but its worth it i think.

~1d ago

eno: @vux @u7angel, of course, but an annual fee would be much more convenient for the accounting.

~1d ago

u7angel: @eno, the idea is to generate a steady income to motivate continious development.