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
{
> 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;
> }
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
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 Fri, Apr 26
'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 analysis above.
>
> Thanks,
> Matt
>
>
> On Thu, Apr 2
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.
((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,
> Matt
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
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 at i
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
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
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 <brian.ja...@gmail.com
> > wrote:
>
>> When upgrading to 1.9.2
lures. And I don't think that's going to change.
>
> On Thu, Nov 2, 2017 at 5:12 PM, Brian Green <brian.ja...@gmail.com
> > wrote:
>
>> I am encountering a crash when combining the generic-x1 target at the -O0
>> flag. For example:
>>
>> foo.ispc:
>&g
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)
{
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
15 matches
Mail list logo
