Intel integrated GPU

[Bdot]

Originally Posted by Prime95

Is it because one vector is unsigned and the other is signed?

Hmm. Hard to believe. Normally, signed/unsigned mismatch is just a warning. It's true that the (boolean) result of a comparison is signed in OpenCL. Therefore I have the ternary there that should provide unsigned long ("<n>UL"). But here, it seems more like there is no way of promoting an unsigned long ("ulong") to a vector ("ulong2"). Normally, that promotion should be implicit - but not here. Even explicit type cast did not work.

Maybe you or kracker could try a few more things, like

r2 += ((r1!=0)? (ulong_v)1UL : (ulong_v)0UL);

or have it select the size automatically?

r2 += ((r1!=0)? 1 : 0);

or integrate the addition into the selection:

r2 = ((r1!=0)? r2+1 : r2);

or ... almost worst case (because threads take a different code path):

if (r1!=0) ++r2;

or ... really worst case (because this is really a function call for conversion):

r2 += convert_##ulong_v((r1!=0)? 1UL : 0UL);


I did not try any of those - possibly some won't even work on AMD. If you find something that works, let me know

[kracker]

r2 += ((r1!=0)? (ulong_v)1UL : (ulong_v)0UL);
works Do you want -st with that?

[Prime95]

Errors when building with TRACE_KERNEL=2

This compiler is very picky.

[Prime95]

I've just started to look at the code. My OpenCL knowledge is near zero.

Anyway, this code scared me:

// AS_UINT is applied only to logical results. For vector operations, these are 0 (false) or -1 (true)
// For scalar operations, they result in 0 (false) or 1 (true) ==> to unify, negate here
#define AS_UINT_V -as_uint

It looks like this is typecasting to an unsigned and then negating it. Shouldn't you negate it while it is a signed int, as in:

// AS_UINT is applied only to logical results. For vector operations, these are 0 (false) or -1 (true)
// For scalar operations, they result in 0 (false) or 1 (true) ==> to unify, negate here
#define AS_UINT_V(x)  as_uint(-(x))

[Bdot]

Originally Posted by Prime95

I've just started to look at the code. My OpenCL knowledge is near zero.

Anyway, this code scared me:

// AS_UINT is applied only to logical results. For vector operations, these are 0 (false) or -1 (true)
// For scalar operations, they result in 0 (false) or 1 (true) ==> to unify, negate here
#define AS_UINT_V -as_uint

It looks like this is typecasting to an unsigned and then negating it. Shouldn't you negate it while it is a signed int, as in:

// AS_UINT is applied only to logical results. For vector operations, these are 0 (false) or -1 (true)
// For scalar operations, they result in 0 (false) or 1 (true) ==> to unify, negate here
#define AS_UINT_V(x)  as_uint(-(x))

You are correct with your observation. In the past, I did not care too much about VECTOR_SIZE=1 as it does not fit the AMD GPUs very well.
On the other hand, again, signed/unsigned issues are only warnings - apart from a right shift and mul_hi, they don't differ in their operations. I think I use AS_UINT only for additions/subtractions, but I did not verify that.

Regarding the TRACE_KERNEL, the compiler is right. For VECTOR_SIZE=1, the variables do not have the vector components. To trace the kernels, set at least VECTOR_SIZE=2. Or modify the trace statements to remove the ".s0" everywhere.


I currently have too much other stuff to do to actually dig into that - I hope in two weeks the situation normalizes again.

[Bdot]

Originally Posted by kracker

r2 += ((r1!=0)? (ulong_v)1UL : (ulong_v)0UL);
works Do you want -st with that?

I'll build a PerformanceInfo version when I have time ... but that has to wait a bit.

[Prime95]

If I didn't screw things up too badly, I have a trace for bdot.

[Bdot]

The calculation looks good - no exceptionally big values, all within bounds. What does look odd is the initial shifted value, bb:

cl_barrett15_82: bb=fffff968:ffffffff:1e43:dd5b57:dd5bff:0:0:dd5b57:ffffffff:0:ef:216c0e, bit_max65=5

First, it is supposed to have only one bit set in the whole value, second, only the lower 15 bits of each components should ever be used.

This makes me think that passing this custom type (int180, a struct of 12 uints) does not work and leaves the initial shifted value uninitialized.

I have seen this bug in the AMD drivers two years ago and made a workaround at that time.
Changelog:

version 0.10 (2011-12-19)
- added workaround for compatibility with Catalyst 11.10 and above
...

However, since the GPU sieve was added, that workaround is implemented only in the top level of the functions, where it needs to be passed on one more time. This is OK for AMD, but maybe not for Intel. I'll try to change that.

[Prime95]

Originally Posted by Bdot

What does look odd is the initial shifted value, bb

Sorry, I should have explained what all I did to get it to compile. I commented out the bb initializations and undefined the work around #define. I think it was called something like WA_CATALYST_SOMETHING_OR_OTHER.

The compile problems when tracing are numerous. All the .s0, .s1, etc references are no good. Maybe I'm not working from the latest source?

[Bdot]

Originally Posted by Prime95

Sorry, I should have explained what all I did to get it to compile. I commented out the bb initializations and undefined the work around #define. I think it was called something like WA_CATALYST_SOMETHING_OR_OTHER.

The compile problems when tracing are numerous. All the .s0, .s1, etc references are no good. Maybe I'm not working from the latest source?

OK, WA_FOR_CATALYST11_10_BUG is defined in params.h and mfakto_Kernels.cl. Did you remove it from both?

Regarding .s0, .s1 etc.: I have never before traced with VectorSize=1, when all these values are scalar instead of vectors. Starting with VectorSize=2, the subcomponents need to be addressed by .s0, .s1 ... but I only traced .s0 usually.

[Prime95]

Originally Posted by Bdot

OK, WA_FOR_CATALYST11_10_BUG is defined in params.h and mfakto_Kernels.cl. Did you remove it from both?

I don't have a params.h file.