In terms of LLVM, ISPC generates vectorized types for varying types, and
scalar types for uniform. For example:
uniform int func(uniform int x, varying int y);
uniform int
run()
{
uniform int x = 1;
varying int y = programIndex;
uniform int z = func(x, y);
return z;
}
ispc test
I'm not sure I completely understand your input. Is srcRow an array of
uniform float? In terms of output, is dstRow also an array of uniform
float? If so the following function should work:
void run(const uniform float * uniform srcRow, uniform int size, uniform
float * uniform dstRow)
{
I am encountering a crash when combining the generic-x1 target at the -O0
flag. For example:
foo.ispc:
void foo()
{
}
ispc foo.ispc --target=generic-x1 --emit-c++ -o foo.cc
works fine. But...
ispc foo.ispc --target=generic-x1 --emit-c++ -o foo.cc -O0
gives:
llvmutil.cpp:1560: Assertion fa
; failures. And I don't think that's going to change.
>
> On Thu, Nov 2, 2017 at 5:12 PM, Brian Green > wrote:
>
>> I am encountering a crash when combining the generic-x1 target at the -O0
>> flag. For example:
>>
>> foo.ispc:
>>
>>
When upgrading to 1.9.2 from 1.9.1 the following code no longer compiles:
inline void someFunc()
{
static const float scale = 1.0f / 8.0f;
static const float halfScale = 0.5f * scale;
// continue
}
producing the error:
Error: Initializer for static variable "halfScale" must be a
to me. The code to check this kind of
> things was changed in 1.9.2, but reported behavior is not intended.
>
> Please file an issue, I'll have a look.
>
> On Tue, Jan 23, 2018 at 8:14 PM, Brian Green > wrote:
>
>> When upgrading to 1.9.2 from 1.9.1 the following
I'm encountering a hard to understand crash moving to the 1.9.2 compiler in
optimized code.
I have a struct:
struct Vec3f {
float x;
float y;
float z;
};
The following code has worked fine under 1.9.1 and quite far back in both
optimized and non-optimized builds and works fine in non-
The above code will not demonstrate the problem, so don't spend any cycles
staring at it. Sorry.
I'll need to produce a new example...
--
You received this message because you are subscribed to the Google Groups
"Intel SPMD Program Compiler Users" group.
To unsubscribe from this group and st
)
In the debugger, the crash points to the assignment line for v1.
Has anyone seen something similar with 1.9.2?
-Brian
On Thursday, February 8, 2018 at 3:50:16 PM UTC-8, Brian Green wrote:
>
>
> The above code will not demonstrate the problem, so don't spend any cycles
> staring
What is the advantage of this approach versus using the ispc compiler to
generate a .bc that you then JIT using the LLVM API?
-Brian
On Thursday, February 15, 2018 at 7:33:15 AM UTC-8, Ivan Alduan wrote:
>
> Hello,
>
> I am trying to create a JIT version of the ISPC compiler (without
> modifyin
It looks like all(), any(), and none() examine all lanes regardless if
those lanes are active or not. For example,
if (programIndex < 4) {
if (all(programIndex < 4)) {
print("all lanes are less than 4\n");
} else {
print("all lanes are not less than 4\
turn __all((UIntMaskType)__sext_varying_bool(v) | !__mask);
> #endif
> }
>
> (Yes, grungy for various reasons), but in theory it should be factoring in
> the current mask. I wonder if a compiler change broke this; any chance you
> can easily try on an earlier version?
>
> Thanks,
\n",
>> programIndex);
>>
>> }
>>
>> The above for eg. prints "no lanes are less than 4" which is what I'd
>> expect.
>>
>> Thanks,
>> Deepak
>>
>> On Tuesday, April 17, 2018 at 10:53:02 AM UTC-7
I'm running a simple test case that makes me question my understanding of
how varying types are created when varying pointers to varying types are
dereferenced. My understanding was that each pointer would be dereferenced
with the appropriate lane. But this appears to not be the case.
Conside
ng data to have
> the same address value, as you're seeing here, and that then the bug is in
> the code emitted to dereference *av. I am a little surprised that that
> would be broken, though (surely that's in the test suite), so there may be
> something wrong in the an
est, which does exactly what you've described with the
> struct wrapper. So probably we are probably missing the very simple test.
>
> I don't think that something changed in the latest release with respect to
> this bug.
>
> Could you file a bug for that?
>
> On F
Using -> to dereference a struct is incorrectly complaining that it is
being applied to a declared but not defined struct, when the struct in
question is first forward declared:
test.ispc:21:5: Error: Member operator
"->" can't be applied to
declared but not defined struct
gt; uniform A * uniform mA;
> };
>
> export void
> run()
> {
>
> B b;
>
> // BUG: this does not compile ???
> b.mA->mX = 3;
>
>
>
> // but this is fine
>
> // uniform A * uniform a2 = b.mA;
> // a2->mX = 3;
> }
Have you found hyper-threading to have a positive impact vector width
scalability? Among other things, I'm wondering if it can help speed up
gathers. I could test this myself, it just isn't the easiest thing to turn
on and off on production systems.
Cheers,
-Brian
On Wednesday, September 25,
19 matches
Mail list logo
