I am trying to compile my first VexCL program using the thrust example and I get the following error message:
raw_ptr is not a member of 'vex::backend::opencl::device_vector'
Here is the code
vex::Context ctx(vex::Filter::Env && vex::Filter::Count(1));
std::cout << ctx << std::endl;
vex::profiler<> prof(ctx);
typedef int T;
const size_t n = 16 * 1024 * 1024;
vex::vector<T> x(ctx, n);
vex::Random<T> rnd;
// Get raw pointers to the device memory.
T *x_begin = x(0).raw_ptr(); // Here is where the error is occurring.
T *x_end = x_begin + x.size();
I do not understand the language well enough. I appreciate any help in this matter.
Thanks
Chris
The thrust example is not the best to start with, as it deals with interfacing VexCL and Thrust (another high-level library that is targeted on CUDA).
So in order to compile the example, you need to use the CUDA backend in VexCL. That is, you need to define VEXCL_BACKEND_CUDA preprocessor macro
and to link against libcuda.so (or cuda.lib if on Windows) instead of libOpenCL.so/OpenCL.lib.
The error you got is because the device_vector class only exposes raw_ptr() method when on CUDA backend.
Related
I am new to OpenSSL and is currently working on a C++ project that has a dependency on OpenSSL. Recently i started using a machine that had openSSL 3.0 installed but is unable to build the project because i get compiler errors like below ( please note that warnings are treated as error in the project)
error: 'MD5' is deprecated
if (!MD5((uint8_t*)key.data(), key.size(), hashOutput)) {
^
/usr/local/Cellar/openssl#3/3.0.0_1/include/openssl/md5.h:52:1: note: 'MD5' has been explicitly marked deprecated here
OSSL_DEPRECATEDIN_3_0 unsigned char *MD5(const unsigned char *d, size_t n,
^
/usr/local/Cellar/openssl#3/3.0.0_1/include/openssl/macros.h:182:49: note: expanded from macro 'OSSL_DEPRECATEDIN_3_0'
# define OSSL_DEPRECATEDIN_3_0 OSSL_DEPRECATED(3.0)
^
/usr/local/Cellar/openssl#3/3.0.0_1/include/openssl/macros.h:62:52: note: expanded from macro 'OSSL_DEPRECATED'
# define OSSL_DEPRECATED(since) __attribute__((deprecated))
^
1 error generated.
Doing some investigation i found that these API's were deprecated in OpenSSL 3.0.0 and now i have three options
Ignore the warnings. They are just warnings. The deprecated functions are still present and you may still use them. However be aware that they may be removed from a future version of OpenSSL.
Suppress the warnings. Refer to your compiler documentation on how to do this.
Remove your usage of the low level APIs. In this case you will need to rewrite your code to use the high level APIs instead.
I choose the third option but even after reading documentations related to OpenSSL, i am still not sure what is the EVP API equivalent of the MD5 method which got deprecated in OpenSSL 3.0.0. If you check the link https://www.openssl.org/docs/manmaster/man3/MD5.html it states that
All of the functions described on this page are deprecated.
Applications should instead use EVP_DigestInit_ex(3),
EVP_DigestUpdate(3) and EVP_DigestFinal_ex(3).
Would be great if someone can provide me some feedback/help or additional resources/links that might help me understand using the high Level OpenSSL API's in general so that i can make it work for my use case i.e MD5 encryption.
I must also mention that i downloaded OpenSSL repo from github and found that the implementation of md5 method is as below
unsigned char *MD5(const unsigned char *d, size_t n, unsigned char *md)
{
MD5_CTX c;
static unsigned char m[MD5_DIGEST_LENGTH];
if (md == NULL)
md = m;
if (!MD5_Init(&c))
return NULL;
#ifndef CHARSET_EBCDIC
MD5_Update(&c, d, n);
#else
{
char temp[1024];
unsigned long chunk;
while (n > 0) {
chunk = (n > sizeof(temp)) ? sizeof(temp) : n;
ebcdic2ascii(temp, d, chunk);
MD5_Update(&c, temp, chunk);
n -= chunk;
d += chunk;
}
}
#endif
MD5_Final(md, &c);
OPENSSL_cleanse(&c, sizeof(c)); /* security consideration */
return md;
}
I hope this example would help (I'm not checking for errors and exceptions in my example, so be aware of that):
Deprecated Implementation
#include <openssl/md5.h>
static void calculate_md5(unsigned char* buf, unsigned int buf_size)
{
unsigned char md5_digest[MD5_DIGEST_LENGTH];
MD5_CTX md5ctx;
MD5_Init(&md5ctx);
MD5_Update(&md5ctx, buf, buf_size);
MD5_Final(md5_digest, &md5ctx);
}
New Implementation:
#include <openssl/evp.h>
static void calculate_md5(unsigned char* buf, unsigned int buf_size)
{
EVP_MD_CTX *mdctx;
unsigned char *md5_digest;
unsigned int md5_digest_len = EVP_MD_size(EVP_md5());
// MD5_Init
mdctx = EVP_MD_CTX_new();
EVP_DigestInit_ex(mdctx, EVP_md5(), NULL);
// MD5_Update
EVP_DigestUpdate(mdctx, buf, buf_size);
// MD5_Final
md5_digest = (unsigned char *)OPENSSL_malloc(md5_digest_len);
EVP_DigestFinal_ex(mdctx, md5_digest, &md5_digest_len);
EVP_MD_CTX_free(mdctx);
}
I have made a program to take in float inputs from a user to create a dynamic array (Then use those inputs with functions to find basic stuff like max,min,sum,avg but that stuff works fine so I don't think Ill include that here for the purpose of not creating a wall of code).
It works about half the time and while I have some theories about the cause I cant put my finger on a solution.
int main() {
int Counter = 0;
float *UsrIn = nullptr;
float Array[Counter];
My first thought was that the part below was the issue. My class hasn't really gone over what notation (I assume it refers to bytes so maybe scientific notation would work) to use with new that I can recall. I just tried 20 for the sake of testing and it seemed to work(probably a silly assumption in hindsight).
UsrIn = new float[(int)20];
cout << "Enter float numbers:" << endl;
cout << "Enter '9999999' to quit:" << endl;
cin >> *UsrIn; // User Input for pointer Dynamic Array
Array[Counter] = *UsrIn;
while(*UsrIn!=9999999) // User Input for Dynamic Array
{
Counter++;
UsrIn++;
cin >> *UsrIn;
Array[Counter] = *UsrIn;
}
delete UsrIn;
delete[] UsrIn;
My other thought was that maybe a pointer address was already in use by something else or maybe it was invalid somehow. I don't know of a way to test for that because the crash I occasionally get only happens when exiting the while loop after entering "9999999"
As a side note I'm not getting any warnings or error messages just a crashed program from eclipse.
Variable-length arrays are not universally supported in C++ implementations, although your compiler clearly supports them. The problem, from what you've described, is with this code:
int main() {
int Counter = 0;
float *UsrIn = nullptr;
float Array[Counter];
You're defining a variable-length array of size 0. So, although you're allocating 20 entries for UsrIn, you're not allocating any memory for Array. The intention of variable-length arrays is to allocate an array of a given size where the size is not actually known until run time. Based on your other code, that's not really the situation here. The easiest thing to do is just change the Array size to match your UsrIn size, e.g.:
float Array[20];
If you really want more of a dynamic behavior, you could use std::vector<float>
std::vector<float> Array;
...
Array.push_back(*UsrIn);
I'm working on integrating T-Cube motor controller (http://www.thorlabs.de/newgrouppage9.cfm?objectgroup_id=2419) into the software based on Qt-4.8.1 package. Due to there is no manual or any sort of tutorial how to retrieve ActiveX object and how to call methods I did the following.
1) Looked through Windows registry looking for words similar to motor controller name. Found a candidate with CLSID "{3CE35BF3-1E13-4D2C-8C0B-DEF6314420B3}".
2) Tried initializing it in the following way (code provided is shortened, all result checks are removed in order to improve readability):
HRESULT h_result = CoInitializeEx(NULL, COINIT_MULTITHREADED);
pd->moto = new QAxObject();
initialized = moto->setControl( "{3CE35BF3-1E13-4D2C-8C0B-DEF6314420B3}" );
QString stri = browser->generateDocumentation();
obj->dynamicCall("SetHWSerialNum(int)", params);
QVariantList params;
params << 0;
params << 0.0;
int result = pd->moto->dynamicCall("GetPosition(int, double&)", params).toInt();
value = params[1].toFloat();
QVariantList params;
params << 0;
params << dist;
params << dist;
params << true;
int result = pd->moto->dynamicCall("MoveRelativeEx(int, double, double, bool)", params).toInt();
3) generateDocumentation() method gives perfect description of ~150 methods.
4) All dynamicCall() invocations cause "Error calling ...: Unknown error", where "..." is a first argument of dynamicCall() from the list generateDocumentation()'s given me.
5) If I insert into dynamicCall() any method which isn't presented in the documentation generated the output is different. So I suppose that methods in documentation generated really exist.
6) If I use #import directive and try calling directly avoiding QAxObject usage I see "mg17motor.tlh" file but none of interfaces described there contain any methods. So I can't use it directly as well. Is it normal?
I would be very much obliged for any advice.
You can find the ActiveX object using the OLE viewer. Then search for something like
APT.. or MG.. under all objects. Then find the parameter ProgID=MGMOTOR.MGMotorCtrl.1.
Now in Qt don't use QAxObject but QAxWidget. Then you get something like:
QAxWidget* aptMotor;
QVariant chanID = QVariant(0);
aptMotor = new QAxWidget();
aptMotor->setControl("MGMOTOR.MGMotorCtrl.1");
//Nice html documentation on available functions
QFile file("out.html");
file.open(QIODevice::WriteOnly | QIODevice::Text);
QTextStream out(&file);
out << aptMotor->generateDocumentation();
file.close();
aptMotor->setProperty("HWSerialNum",QVariant(83853493));
aptMotor->dynamicCall("StartCtrl");
aptMotor->dynamicCall("EnableHWChannel(QVariant)",chanID);
QThread::sleep(1); // Give it time to enable the channel
double pos(0);
aptMotor->dynamicCall("SetAbsMovePos(QVariant,QVariant)",chanID,QVariant(pos));
aptMotor->dynamicCall("MoveAbsolute(QVariant,QVariant,QVariant)",chanID,0);
aptMotor->dynamicCall("StopCtrl");
I currently am writing some unittests for OpenCL kernels and need to create a context.
As I am not after performance it does not matter to me which device is running the kernel.
So I want to create the context with as little restrictions as possible and thought of this code:
#define __CL_ENABLE_EXCEPTIONS
#include <CL/cl.hpp>
#include <iostream>
int main() {
try {
cl::Context context(CL_DEVICE_TYPE_ALL);
}catch(const cl::Error &err) {
std::cerr << "Caught cl::Error (" << err.what() << "): " << err.err() << "\n";
}
}
Which returns
Caught cl::Error (clCreateContextFromType): -32
-32 is CL_INVALID_PLATFORM and the documentation of clCreateContextFromType says:
CL_INVALID_PLATFORM if properties is NULL and no platform could be selected or if platform value specified in properties is not a valid platform.
As I have not provided any properties they are of course NULL.
Why can't any platform be selected?
I also have tried CL_DEVICE_TYPE_DEFAULT with the same result.
Here is a list of my platform and device that were detected:
NVIDIA CUDA
(GPU) GeForce GTX 560
As a side node: Specifying the platform in the properties works as intented.
I tried your code, using CL_DEVICE_TYPE_ALL and it worked on my setup. I'm not sure why it's not working on yours...
As a workaround, maybe you could do something like this:
// Get all available platforms
std::vector<cl::Platform> platforms;
cl::Platform::get(&platforms);
// Pick the first and get all available devices
std::vector<cl::Device> devices;
platforms[0].getDevices(CL_DEVICE_TYPE_ALL, &devices);
// Create a context on the first device, whatever it is
cl::Context context(devices[0]);
cl::Context context(cl_device_type) is calling the complete constructor with default parameters:
cl::Context::Context(cl_device_type type,
cl_context_properties * properties = NULL,
void(CL_CALLBACK *notifyFptr)(const char *,const void *,::size_t,void *) = NULL,
void * data = NULL,
cl_int * err = NULL
)
Witch is only a wrapper of C++ to the underlying clCreateContextFromType().
This function allows that a NULL pointer is passed as a property, but then, the platform selection is implementation dependent. And it looks like in your case it does not default to nVIDIA platform.
You will have to pass some info to the constructor I'm afraid....
have C sources that must compile in 32bit and 64bit for multiple platforms.
structure that takes the address of a buffer - need to fit address in a 32bit value.
obviously where possible these structures will use natural sized void * or char * pointers.
however for some parts an api specifies the size of these pointers as 32bit.
on x86_64 linux with -m64 -mcmodel=small tboth static data and malloc()'d data fit within the 2Gb range. data on the stack, however, still starts in high memory.
so given a small utility _to_32() such as:
int _to_32( long l ) {
int i = l & 0xffffffff;
assert( i == l );
return i;
}
then:
char *cp = malloc( 100 );
int a = _to_32( cp );
will work reliably, as would:
static char buff[ 100 ];
int a = _to_32( buff );
but:
char buff[ 100 ];
int a = _to_32( buff );
will fail the assert().
anyone have a solution for this without writing custom linker scripts?
or any ideas how to arrange the linker section for stack data, would appear it is being put in this section in the linker script:
.lbss :
{
*(.dynlbss)
*(.lbss .lbss.* .gnu.linkonce.lb.*)
*(LARGE_COMMON)
}
thanks!
The stack location is most likely specified by the operating system and has nothing to do with the linker.
I can't imagine why you are trying to force a pointer on a 64 bit machine into 32 bits. The memory layout of structures is mainly important when you are sharing the data with something which may run on another architecture and saving to a file or sending across a network, but there are almost no valid reasons that you would send a pointer from one computer to another. Debugging is the only valid reason that comes to mind.
Even storing a pointer to be used later by another run of your program on the same machine would almost certainly be wrong since where your program is loaded can differ. Making any use of such a pointer would be undefined abd unpredictable.
the short answer appears to be there is no easy answer. at least no easy way to reassign range/location of the stack pointer.
the loader 'ld-linux.so' at a very early stage in process activation gets the address in the hurd loader - in the glibc sources, elf/ and sysdeps/x86_64/ search out elf_machine_load_address() and elf_machine_runtime_setup().
this happens in the preamble of calling your _start() entry and related setup to call your main(), is not for the faint hearted, even i couldn't convince myself this was a safe route.
as it happens - the resolution presents itself in some other old school tricks... pointer deflations/inflation...
with -mcmodel=small then automatic variables, alloca() addresses, and things like argv[], and envp are assigned from high memory from where the stack will grow down. those addresses are verified in this example code:
#include <stdlib.h>
#include <stdio.h>
#include <alloca.h>
extern char etext, edata, end;
char global_buffer[128];
int main( int argc, const char *argv[], const char *envp )
{
char stack_buffer[128];
static char static_buffer[128];
char *cp = malloc( 128 );
char *ap = alloca( 128 );
char *xp = "STRING CONSTANT";
printf("argv[0] %p\n",argv[0]);
printf("envp %p\n",envp);
printf("stack %p\n",stack_buffer);
printf("global %p\n",global_buffer);
printf("static %p\n",static_buffer);
printf("malloc %p\n",cp);
printf("alloca %p\n",ap);
printf("const %p\n",xp);
printf("printf %p\n",printf);
printf("First address past:\n");
printf(" program text (etext) %p\n", &etext);
printf(" initialized data (edata) %p\n", &edata);
printf(" uninitialized data (end) %p\n", &end);
}
produces this output:
argv[0] 0x7fff1e5e7d99
envp 0x7fff1e5e6c18
stack 0x7fff1e5e6a80
global 0x6010e0
static 0x601060
malloc 0x602010
alloca 0x7fff1e5e69d0
const 0x400850
printf 0x4004b0
First address past:
program text (etext) 0x400846
initialized data (edata) 0x601030
uninitialized data (end) 0x601160
all access to/from the 32bit parts of structures must be wrapped with inflate() and deflate() routines, e.g.:
void *inflate( unsigned long );
unsigned int deflate( void *);
deflate() tests for bits set in the range 0x7fff00000000 and marks the pointer so that inflate() will recognize how to reconstitute the actual pointer.
hope that helps if anyone similarly must support structures with 32bit storage for 64bit pointers.