Does anybody know the state of half precision floating point support in OpenCL as implemented by Apple.
According to OpenCL 1.1 spec The following statement should enable half2:
#pragma OPENCL EXTENSION cl_khr_fp16 : enable
but when I come to build the kernel the compiler throws a message such as
error: variable has incomplete type 'half4' (aka 'struct __Reserved_Name__Do_
The following thread ask a similar question : OpenCL half4 type Apple OS X
But this thread is old. Can anyone please tell me if the half precision is supported by apple recently?
When you want to know if a extension is supported by a specific implementation (regardless if it's Apple's or another), just use the function
cl_int clGetPlatformInfo(cl_platform_id platform,
cl_platform_info param_name,
size_t param_value_size,
void *param_value,
size_t *param_value_size_ret)
passing the value CL_PLATFORM_EXTENSIONS for the param_name argument. it'll return a space-separated list of extension names.
Note that this list must returns the extensions "supported by all devices associated with this platform".
So it means that even if the platform supports the cl_khr_fp16 extension but not your device, it won't appear in the list.
To know the extension available on your device use
clGetDeviceInfo(...)
with the value CL_DEVICE_EXTENSIONS for the param_name argument.
For a generic answer to OpenCL extension querying see CaptainObvious' answer above (https://stackoverflow.com/a/17425167/5394228).
I asked Apple Developer Support about this and they say that half support is available in Metal and there are no plans to add new functionality to OpenCL now. (they answered Nov 2017)
Related
I have to use a Microchip PIC for a new project (needed high pin count on a TQFP60 package with 5V operation).
I have a huge problem, I might miss something (sorry for that in advance).
IDE: MPLAB X 3.51
Compiler: XC8 1.41
The issue is that if I initialize an object to anything other than 0, it will not be initialized, and always be zero when I reach the main();
In simulator it works, and the object value is the proper one.
Simple example:
#include <xc.h>
static int x= 0x78;
void main(void) {
while(x){
x++;
}
return;
}
In simulator the x is 0x78 and the while(x) is true.
BUT when I load the code to the PIC18F67K40 using PICKIT3, the x is 0.
This happening even if I do a simple sprintf, and it does nothing as the formatting text string (char array) is full of zeros.
sprintf(buf,"Number is %u",x")
I can not initialize any object apart to be zero.
What is going on? Any help appreciated!
Found the problem, The chip has an errata issues, and I got the one which is effected, strange, Farnell sells it. More strange that the compiler is not prepared for that, does not even give a warning to say to be careful!
Errata note:
Module: PIC18 Core
3.1 TBLRD requires NVMREG value to point to
appropriate memory
The affected silicon revisions of the PIC18FXXK40
devices improperly require the NVMREG<1:0>
bits in the NVMCON register to be set for TBLRD
access of the various memory regions. The issue
is most apparent in compiled C programs when the
user defines a const type and the compiler uses
TBLRD instructions to retrieve the data from
program Flash memory (PFM). The issue is also
apparent when the user defines an array in RAM
for which the complier creates start-up code,
executed before main(), that uses TBLRD
instructions to initialize RAM from PFM.
I got this warning when building beta release of SageMath 6.1 on OSX 10.9.1, with 64 bit processor:
extra.cc:940:30: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
Can you give an example of the command which can cause this kind of warning?
The post here says that there is no way to do it:
void *ptr = ...;
int x = (int)ptr;
...
ptr = (void *)x;
which is invalid according to the source.
Gcc version
$ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin13.0.0
Thread model: posix
The link is correct. The issue is that neither an int nor a pointer has a standard size, but on a 32-bit system they are most likely to both be 32-bits, whereas on a 64-bit system, a pointer is 64-bits wide while an int is still likely 32-bits.
Can you give an example of the command which can cause this kind of warning?
On a 64-bit system using glibc, take an int and cast its value to a pointer:
int x;
void *p = (void*)x;
Of course, if the issue is that pointers are twice the size of ints, this all by itself isn't a problem, it just throws a warning. The reason this kind of thing should throw a warning is that it could, in a "not all by itself" context, indicate a serious mistake.
So, it's not a good programming practice but it does not have to indicate a real error -- e.g., p += (void*)x will do the same thing, and this is more obviously likely innocuous, although the cast is unnecessary (and causes the warning).
I notice all kinds of (hopefully) innocent warnings like this when compiling even widely used, well aged software. You just have to trust that the people who've put it together are aware of this and aren't phased because they are sure there isn't a real issue, just a spurious warning. They could almost certainly still eliminate them, but GCC is notoriously picky (suggest YET MORE parentheses...), and not everyone cares, particularly on portable projects that may be more often built elsewhere.
Does anybody know the state of half precision floating point support in OpenCL as implemented by Apple.
According to http://www.khronos.org/registry/cl/sdk/1.2/docs/man/xhtml/cl_khr_fp16.html
#pragma OPENCL EXTENSION cl_khr_fp16 : enable
should enable support for types such as half4 but when I come to build the kernel the compiler throws a message such as
error: variable has incomplete type 'half4' (aka 'struct __Reserved_Name__Do_not_use_half4')
is there anyway I can have half4 support in Apple's OpenCL?
Thanks.
The latest shipping Apple implementation is on Lion, and it supports OpenCL 1.1. You are looking at the recently released OpenCL 1.2 specification. That simply documents what will be in a given 1.2 implementation of OpenCL, whoever the vendor might be.
The cl_khr_fp16 extension (floating point operations on the 16bit scalar type (half) and vectors of half (half2,half3,half4,half8,half16) is an optional extension to OpenCL 1.0, 1.1 and 1.2.
An OpenCL extension defines a macro of the same name as the extension if it is supported in the OpenCL implementation.
e.g.
#ifdef cl_khr_fp16
#pragma OPENCL EXTENSION cl_khr_fp16 : enable
... // Code using half
#else
#error No FP16 support
#endif
I do not believe Apple are shipping an OpenCL with half support.
I am trying to use a trivial geometry shader but when run in Shader Builder on a laptop with a GMA X3100 it falls back and uses the software render. According this document the GMA X3100 does support EXT_geometry_shader4.
The input is POINTS and the output is LINE_STRIP.
What would be required to get it to run on the GPU (if possible)
uniform vec2 offset;
void main()
{
gl_Position = gl_PositionIn[0];
EmitVertex();
gl_Position = gl_PositionIn[0] + vec4(offset.x,offset.y,0,0);
EmitVertex();
EndPrimitive();
}
From the docs you link to it certainly appears it should be supported.
You could try
int hasGEOM = isExtensionSupported("EXT_geometry_shader4");
If it returns in the affirmative you may have another problem stopping it from working.
Also according to the GLSL Spec (1.20.8) "Any extended behavior must first be enabled.
Directives to control the behavior of the compiler with respect to extensions are declared with the #extension directive"
I didn't see you use this directive in your code so I can suggest
#extension GL_EXT_geometry_shader4 : enable
At the top of your shader code block.
I've found this OpenGL Extensions Viewer tool really helpful in tracking down these sorts of issues. It will certainly allow you to confirm Apple's claims. That said, wikipedia states that official GLSL support for geometry shaders is technically an OpenGL 3.2 feature.
Does anyone know if the EXT_geometry_shader4 implementation supports the GLSL syntax, or does it require some hardware or driver specific format?
Interestingly enough, I've heard that the compatibility claims of Intel regarding these integrated GPUs are sometimes overstated or just false. Apparently the X3100 only supports OpenGL 1.4 and below (or so I've heard, take this with a grain of salt, as I can't confirm this).
On my HP Laptop, with an Intel x3100 using Windows 7 x64 drivers (v8.15.10.1930 (9-23-2009)) directly from Intel's website, the extension "EXT_geometry_shader4" (or any variation of it) is NOT supported. I've confirmed this programmatically and using the tool "GPU Caps Viewer" (which lists detected supported extensions, amongst other useful things). Since Windows tends to be the primary subject of driver development from any vendor, it's unlikely the OSX driver is any better, and may in fact have even less supported extensions.
I have been using Unimotion in my application to read motion sensor values for Apple laptops, but have been unable to port the code to 10.6 64-bit. (I have also tried SMSLib and had the no luck either.)
Is there any simple 10.6 compatible
SMS API?
If there is no alternative, I am also considering patching one of the libraries. Both Unimotion and SMSLib use the following call, which has been deprecated in 10.5 and removed from 10.6 64-bit:
result = IOConnectMethodStructureIStructureO(
dataPort, kernFunc, structureInputSize,
&structureOutputSize, &inputStructure,
outputStructure);
Is there any simple way to replace
this with new IOKit calls?
(This post did not really get me much further)
If there is no alternative, I am also considering patching one of the libraries. Both Unimotion and SMSLib use the following call, which has been deprecated in 10.5 and removed from 10.6 64-bit:
result = IOConnectMethodStructureIStructureO(
dataPort, kernFunc, structureInputSize,
&structureOutputSize, &inputStructure,
outputStructure);
Is there any simple way to replace this with new IOKit calls?
That very document suggests replacements. What about this one?
kern_return_t
IOConnectCallStructMethod(
mach_port_t connection, // In
uint32_t selector, // In
const void *inputStruct, // In
size_t inputStructCnt, // In
void *outputStruct, // Out
size_t *outputStructCnt) // In/Out
As far as I can tell, there should be no difference except for the order of the arguments. That said, I've never used I/O Kit, so I could be missing some critical conceptual difference that will make this call not work as the old one did.
I haven't used this in 10.6, but does this work?
http://code.google.com/p/google-mac-qtz-patches/