browndeer / coprthr

The CO-PRocessing THReads (COPRTHR) SDK - latest release is v1.6.2 (Freewill)
http://www.browndeertechnology.com/coprthr.html
Other
94 stars 35 forks source link

Missing conversion functions from scalar to vector data types #7

Open Dade916 opened 11 years ago

Dade916 commented 11 years ago

Compiling this (http://code.google.com/p/ocltoys/source/browse/mandelgpu/rendering_kernel_float4.cl) kernel on a Parallella board, I receive the following errors:

[OCLToy] Kernel compilation error: aZx7wJ.cpp: In function ‘void mandelGPU(uint*, int, int, float, float, float, int)’: aZx7wJ.cpp:48:33: error: no matching function for call to ‘_float4::_float4(const int&)’ aZx7wJ.cpp:48:33: note: candidates are: In file included from :0:0: /usr/local/browndeer/include/opencl_lift.h:442:3: note: _float4::_float4() /usr/local/browndeer/include/opencl_lift.h:442:3: note: candidate expects 0 arguments, 1 provided /usr/local/browndeer/include/opencl_lift.h:442:3: note: _float4::_float4(const _float4&) /usr/local/browndeer/include/opencl_lift.h:442:3: note: no known conversion for argument 1 from ‘const int’ to ‘const _float4&’ aZx7wJ.cpp:49:36: error: conversion from ‘float’ to non-scalar type ‘const float4 {aka const _float4}’ requested aZx7wJ.cpp:50:36: error: conversion from ‘float’ to non-scalar type ‘const float4 {aka const _float4}’ requested aZx7wJ.cpp:52:62: error: no matching function for call to ‘_uint4::_uint4(int)’ aZx7wJ.cpp:52:62: note: candida [OCLToy] OpenCL ERROR: clBuildProgram(CL_BUILD_PROGRAM_FAILURE) [7133] clmesg info: cmdsched.c(193): cmdqx0: shutdown

It looks like COPRTHR is missing scalar-to-vector conversion functions.

The same kernel works fine on AMD, NVIDIA, Intel, Apple OpenCL.

browndeer commented 11 years ago

Scalar to vector conversion is supported, but the Apple-inspired syntax for initializing a vector is not supported by GCC (nor ICC nor MSVS ...) so we use a built-in which is what the standard should have used to begin with instead of very problematic syntax, but I cannot change the standard.

Add #include at the top of your kernel, and try this, const uint4 tid = __builtin_vector_uint4(gid4, gid4 + 1, gid4 + 2, gid4 +3);

For actual cast from scalar to vector, e.g., float4 f4 = (float4)scalar_value, this I believe does not work but I will add it to missing feature list - its supposed to but I noticed a problem recently. The work-around is simple, use a built-in like example above.

If someone would like to either, a) change the OpenCL standard to support portable C99 compatible syntax, or b) patch GCC to support altivec-style vector initialization, I would be eternally grateful. I believe a kernel API that is 98% C compliant should be 100% C compliant for big-picture portability, especially when the choice for non-compatible syntax is completely arbitrary and unnecessary, but now we drive off into a discussion of standards design principles.

On this subject, if you use out-of-order swizzle operations, these need to be replaced with the shuffle built-ins - same issue - the "dot operator" is used in C for struct access and should not have been hijacked for other purposes. Since swizzeling is an operation, at minimum it should have used the notation of an operation, e.g., vec.yzx(), but it doesn't. Right now we support things like .xy .yz but not .yx because the last access is not ordered. The shuffle built-in taken from SSE intrinsics, which provides same functionality, is what should be used. Its actually unnecessary since the above built-in can be used for every scenario and this is how we write kernels.

Dade916 commented 11 years ago

The main issue for me is kernel code portability. Does Coprthr define some platform specific symbol ? For instance, something like COPRTHR (with 2 underscores before and after ... it looks like I can not use underscores in GitHub comment, they are just showing the word in bold) ? I could use some #ifdef as work around to this problem.

Dade916 commented 11 years ago

BTW, a related problem. The OpenCL built-in function "convert_()" is not compiled:

const uint4 screenX = ...; const float4 fscreenX = convert_float4(screenX);

The error is:

CVpylb.cpp:91:26: error: no matching function for call to ‘_float4::_float4(const uint4&)’

I guess it is missing conversion function.

Dade916 commented 11 years ago

All logic operators also seems to be not available for OpenCL vector data types.

browndeer commented 11 years ago

There is more than one way to do this, but if you want to #ifdef you can use COPRTHR since this should be defined when a coprthr implementation is compiling a kernel.

Also note that including stdcl.h is safe for kernels compiled with AMD, Nvidia, etc since its designed to not harm anything, e.g., those vector initialization builtins default to the apple syntax.

This may not be what you want so the above macro would seem best.

Sent via BlackBerry by AT&T

-----Original Message----- From: Dade916 notifications@github.com Date: Sun, 14 Apr 2013 02:44:17 To: browndeer/coprthrcoprthr@noreply.github.com Reply-To: browndeer/coprthr reply@reply.github.com Cc: Brown Deer Technologydar@browndeertechnology.com Subject: Re: [coprthr] Missing conversion functions from scalar to vector data types (#7)

The main issue for me is kernel code portability. Does Coprthr define some platform specific symbol ? For instance, something like COPRTHR ? I could use some #ifdef as work around to this problem.


Reply to this email directly or view it on GitHub: https://github.com/browndeer/coprthr/issues/7#issuecomment-16348487