Plugin rdyHoudini doesn't work in Houdini 18.5 (and is horribly slow to load)

[danwills]

I noticed rdyHoudini wasn't working in Houdini 18.5, and while trying to work out why it wasn't working I was reminded of how outrageously slow it is/was at loading initial states (particularly anything large) (and generally how prototype-y my approach there was) so I have both fixed the loading-at-all (in 18.5) part and also made it use a far more efficient method to load the initial state fields (which is by far the largest payload of floats in a VTI, massive UX bang-for-buck here).

I haven't tried to commit any of this yet, but now that there's an issue, I'll be cracking on with that!

[forcestatus]

Cool Dan having a crack at this on my new eGPU ruinng a AMD VII :D

[danwills]

About to commit/branch actually so nothing new to see just yet. But very soon.

[danwills]

I think I'll commit things as-is (Houdini-plugin-wise) for the moment even though there is no support yet for the new keywords. If only for the far far faster loading of initial states!

I have looked at the changes @timhutton made on the 'keywords' branch, and they are great and I think I can definitely work with them, but I/we might need to do just one level of refactoring to make the added keyword kernel code sections available to be printed separately by the 'rdy' command and that should in theory allow me to reassemble the parts in Houdini, eventually.

I'd like to commit the current HDA fixes so that ppl can play in H18.5, irrespective of support for the new cool keywords, that can follow shortly.

[timhutton]

What do you need? Below is the kernel generated for advection.vti, with added annotations of the different sections:

__kernel void rd_compute(__global float4 *a_in,__global float4 *a_out)
{
    // A: preamble (unchanged)
    const int index_x = get_global_id(0);
    const int index_y = get_global_id(1);
    const int index_z = get_global_id(2);
    const int X = get_global_size(0);
    const int Y = get_global_size(1);
    const int Z = get_global_size(2);
    const int index_here = X*(Y*index_z + index_y) + index_x;
    float4 a = a_in[index_here];

    // B: parameters now appear here
    const float4 dx = 0.10000000f;
    const float4 timestep = 0.00010000f;

    // C: keywords and the cells they need to access (changed somewhat)
    const float4 a_w = a_in[X * (Y * index_z + index_y) + ((index_x-1 + X) & (X - 1))];
    const float4 a_e = a_in[X * (Y * index_z + index_y) + ((index_x+1 + X) & (X - 1))];
    const float4 x_gradient_a = (float4)(
        a_w.w * -1 + a.y,
        a.x * -1 + a.z,
        a.y * -1 + a.w,
        a.z * -1 + a_e.x) / (2 * dx);

    // D: delta_<chem> (unchanged)
    float4 delta_a = 0.0f;

    // E: insertion of the formula
    delta_a = -x_gradient_a;
    
    // F: output step (unchanged)
    a_out[index_here] = a + timestep * delta_a;
}

[danwills]

I would like to support importing all types of formula VTIs to Houdini so I am hoping that we can separate the code into something that can return each selected section (based on what keywords are in the formula), such that it can both be used by FormulaOpenCLImageRD.cpp as well as by the 'rdy' commandline version to return the relevant snippets of kernel code (to supply to the Houdini plugin with what it would need).

[timhutton]

I don't know if it affects what you're doing but PR #92 changes section C in my comment above slightly. It will now appear as:

    const float4 a_w4 = a_in[X * (Y * index_z + index_y) + ((index_x-1 + X) & (X - 1))];
    const float4 a_e4 = a_in[X * (Y * index_z + index_y) + ((index_x+1 + X) & (X - 1))];
    const float4 a_w = (float4)(a_w4.w, a.xyz);
    const float4 a_e = (float4)(a.yzw, a_e4.x);
    const float4 x_gradient_a = (-1 * a_w + a_e) / (2 * dx);

Note that a_w now contains the cells that are one cell to the west - not the float4 block that was one block to the west. This makes life easier for the user.