Re: varying pointers to varying types

Hmmm.. As far as I can tell, that's a bug in ispc. To summarize: a uniform pointer to varying data is a single scalar pointer, but when it's dereferenced, because it's pointing to varying data, there's an implicit indexing by programIndex. (Alternatively, it's a vector load.) A varying pointer to

Re: all, any, none rationale

Hm, strange. Here's the implementation of all() from the ispc stdlib: __declspec(safe) static inline uniform bool all(bool v) { // As with any(), we need to explicitly mask v with the current program mask // so we're only looking at the current lanes #if (ISPC_MASK_BITS == 1) return

Re: Does ISPC could solve this kind of pattern

ispc should have no problem vectorizing a computation of that form. Thanks, Matt On Thu, Jun 22, 2017 at 5:51 AM, timothée ewart wrote: > Hello, > > I am solving *N* ODE system using Runge Kutta 4.5 with adaptive step, the > consequence of this is the following

Re: is there an ispc intrinsic similar to countbits() in hlsl?

I believe that popcnt() in the standard library is what you're looking for. ("Population count") Matt On Sat, Oct 15, 2016 at 9:27 AM, Morten Mikkelsen wrote: > is there an ispc intrinsic similar to countbits() in hlsl? > >

Re: getting an unpleasant lack of symmetry for a cross product with avx2 target only.

I'm sorry, but I'm not quite following what you're expecting versus what you're seeing. e.g. if I compile that with --target=avx2, I see a series of three multiplies followed by FMA instructions, which seems about as good as it gets. Is it that you're expecting that if you have code that does