Hi,
I have a matrix of shape mat=(1, neles) which I need to use inside a 2-d kernel. Now I am using it with specifications
mat='in broadcast-col fpdtype_t'
and it has been allocated with
self._be.const_matrix(mat, tags={'align'})
Everything works fine for the other backends except for HIP which complains with
[nid002795:1710089] Signal: Segmentation fault (11)
[nid002795:1710089] Signal code: Address not mapped (1)
Any idea?
The first thing I’d do is dump the HIP source code for the resulting kernel and look at how that variable is accessed. Then look at how that array (which will be suffixed with a _v) is accessed. Combine this with the limits (block/grid) of the kernel and you should be able to figure out what is going on and where things are going out of bounds.
Next, try changing the specification to:
mat='in broadcast-col fpdtype_t[1]'
which I am reasonably confident should work (this code path gets tested quite extensively by both the flux and turbulence generation kernels).
Regards, Freddie.
Thanks for the hints.
I was able to sort it down to the integrators. If using the rkvdh it can run (e.g. rk45 or rk34), with the standard integrators (e.g. rk4) I face that error.
I can’t figure it out why…
This does not seem like something which would be related to adding an extra broadcast column. Is RK4 fine with just regular PyFR without any modifications?
It is true that RK4 and RK45 take very different code paths although they are all quite well tested.
Regards, Freddie.
Hi,
there was an environment clash with a wrong pick of the axnpby mako template referring to a version where also nrow was passed as argument.
Thanks for the help!
Okay, so just to confirm that everything in terms of broadcast-col appears to be working on HIP?
Regards, Freddie.
Yes as far as I can tell, if I’ll face any error I will update you. Both mat='in broadcast-col fpdtype_t[1]' and mat='in broadcast-col fpdtype_t' were ok