error C3581: 'void (const Concurrency::extent<_Rank> &,_Value_type *) restrict(cpu, direct3d)': unsupported type in direct3d restricted code
Sunday, November 20, 2011 3:24 AM
I am experimenting with porting a CUDA C app to C++ Amp and I had the above error (see below for more error details). Here are the structures I use:
template<typename T = float> // the underline type (float, double, etc
/// this is the data
size_t vSize = 1000000;
std::vector<TRecData_T<float> >data_(vSize );
// load the data (code not shown)
// create the C++ Amp wrapper
concurrency::array_view<TRecData_T<float>, 1> a(vSize , data_);
///// now process it with C++ Amp. Here I get the error about unsupported __int64 data type.concurrency::parallel_for_each(a.grid, [=](concurrency::index<1> idx) restrict(direct3d)
Please note that here I do not show the return type or the implementation. However it is not needed because as is, this this will generate an error about unsupported __int64 data type. The actual error message is a lot longer with errors about the other types been not supported but, I suspect that it is because if this first error.
I guess the question is: is this a real restriction in C++ Amp or am I doing something wrong?
Sunday, November 20, 2011 10:57 PMOwner
Yes, the error message you are receiving is correct, and you are running into one of the restrictions of restrict(direct3d). __int64 is unsupported, sorry. We will be relaxing restrictions as we release additional versions, but not in this first release. Please let us know if we could improve the error message to make this clearer...
Sunday, November 20, 2011 11:58 PM
Thanks for the quick replay. My problem is that I need to be able to just pass a pointer around. It is NOT used for any processing inside the GPU but I need it so I know what records were processed. Using just an int will not do it because of pointers in 64 bit. Maybe I can store the pointer as a double? Looks strange but if it works!
Monday, November 21, 2011 7:18 AMOwner
Yes, working around this issue by using an alternative storage would work.
I wouldn't go down the "double" path because relying on hardware/driver support for double is not robust.
Instead, you could create a struct of ints and use that to cater for both 32 and 64 bit compilations... Please post back if you get that working, and in parallel one of our guys here may work on such a sample to be released at a later date...
Tuesday, November 22, 2011 5:09 AM
Well I solved the above issue but now I run into another restriction. From C++ Amp here is a fragment:
The function can declare only int, unsigned int, float, and double variables, and classes and structures that contain only these types.
I have a buffer with float numbers but they are kind of compress and I need to process the data by using char*. My algorithm will eventually get the floats out of these compressed chars but, the point is that I need to be able to declare functions taking params as char* and variables as char* inside these functions to be processed on the GPU. Are there any plans to add support for more types then those specified in the docs?
Wednesday, November 23, 2011 10:57 PM
While we will not be adding support for 8 bit integer data types directly, you will have a couple of ways to consume data that is comprised of such entities.
The first option you have is to read the data as integers, and extract 8-bit characters out of them using bitwise operations. We have been using that technique internally in the implementation of OpenCL benchmarks which used chars, and saw that there is no benefit to using chars directly, in fact quite the opposite. We will be blogging about that soon. (This is the main reason why DX doesn’t support 8-bit integers at this point: it’s mostly an anti-pattern on today’s hardware).
The second option which is currently not available but which will be available soon is to use textures. We are currently working on adding texture support. Using 1D textures, you will be able to consume strings of 8-bit and 16-bit characters. The data type that you’ll retrieve will still be int, but each such int will be the result of reading 8-bits or 16-bits of backing storage (depending on the texture format).
Yossi Levanoni, Principal Architect Parallel Computing Platform, Microsoft
Thursday, November 24, 2011 2:19 AM
Thanks for this detailed answer. I will try your suggestions.
Tuesday, December 13, 2011 5:01 PM
I have published a short blog post explaining how pointers may be wrapped to be passed through the C++ AMP. It is available on our team blog: