amcelroy / openclv Goto Github PK

OpenCLV Demo and Documents\Event Example\Register and Use Events.vi

and

Program Manipulation\Register Kernel Event.vi

must. know. secret.

Update the functions for read / writing memory to include the device buffer size and host buffer size.

creating new ticket to capture all unwired errors

OpenCLV Demo and Documents\Anisotropic Filter\SRAD Filter Example.vi

Non-User VIs\Unload OpenCLV DLL.vi

can you wire up an empty constant instead of relying on the default value in the main shifter?

is the LV code optimized? is it REALLY optimized? you dont want some myopic LV jerk coming behind you and saying "i optimized your LV comparison and your 80,000x claim is only like 2000x.

that would make you look very bad.

I am not saying your LV version is or isnt optimized. only saying you might want to be damn sure that is teh best LV can do before selling your tools ability next to what you can get out of LV nativley.

have you used the inplace element structure? i am not an expert with that structure. personally i dont waste time optimizing code unless there is a reall business need and I just havnt hit one yet. 12GB of ram costs $90.

you should find someone who loves to optomize code and get him to eek every little biut out of that native LV code you have there.

many of them link to the wrong dll

Non-User VIs\Functions\Laplacian*

hanging ref in delete 64/32/16

no need to branch clusters in compute 64/32/16
non need to branch the cluster, just pull from the unbundle thats already there

Would you please expand it to include Windows 8.1 please?
Currently it does not allow me to install it.
Thanks.

If data is accessed outside of memory on an Intel processor, this causes Labview to crash. Try / Catch doesn't handle the overflow, as the error is occurring on memory in Labview. Doesn't seem to be an issue for NVIDIA and ATI OpenCL devices.

These two outputs are in the case structure. Better if they are outside the main case and you return completely bogus data if there is an error. That way down stream code kicks and screams and does not erroniously use the default values of tese two controls. Can go into detail over the phone. This is a code smell

not a huge issue but you get performance increases by doing things like this outside of the loop. noting here so you can do this as you move forward, not worth changing existing code.

just realized that you may be exposing your developer/customers to a huge API headache.

I could be wrong but...

It seems like the error handler always pops up a prompt if the dlls throw errors. This is very bad. In production code you want to minimize the points of user interaction. If your customers (developers) cannot control when their customer (users) get popups that puts a lot of pain and burden on your customer. there are ways to get past this. lets talk on the phone.

easy/ugly: put logic in the error handler and a global variable somewhere or use an API cfg file your customers can use to set the error reporting behavior: enum {popup, log to file, send txt msg, ... whatever}

I strongly recommend your default model be log to file and pass error back out of the VI.

it is your customer's responsibility and HIS decision how he wants to handle that error event.

this could be an easy fix but I want to make sure we get this one right before shipping

Change Unsigned 64-bit Integer to Unsigned Pointer-Sized Integer

or try to do this

the frame does not do anything. the seq structure does what you are trying to do.

see issues 28 and 29 regarding forking and refs

these are better but the BD could use some tidying up

I am getting inconsistent results and sometimes LabVIEW crashes when using the ReadMemory VIs with a user defined "Dimensions" argument.
I think the problem is in clLabviewDevice.cpp in all the various ReadMemory_xx functions.

In the call to the OpenCL function
clEnqueueReadBufferRect(d->GetQueue(), DeviceMem, true, Origin, HostOrigin, Region, HostRowPitch, HostSlicePitch, DevRowPitch, DevSlicePitch, Data, NULL, NULL, d->GetEvent());

HostRowPitch and HostSlicePitch should be switched with DevRowPitch and DevSlicePitch, respectively.

That is, the arguments given to clEnqueueReadBufferRect in the body of ReadMemory_xx should be equal (with the same order) to the ones given to clEnqueueWriteBufferRect in the WriteMemory_xx functions (which are working correctly).

See in OpenCL API:
clEnqueueWriteBufferRect
clEnqueueReadBufferRect

that both functions have exactly the same parameters.

thanks,
Enrico

grad control is dead code

also same comments as issue regarding the laplacian vis

note LV creates a copy of memory at wire branches

this is not bad but it caught me as different from the way you did it everywhere else.

-vs-

say this one

please let me review your final copy. please do edit it yourself and ask me for 2 more review before you go life with it. strive for concise, easy to read, and "OPENCLV is amazing, no I meant really amazing" take a tip from NI and use your documentation to market for benefits to your customers

When computing an FFT repeatedly in certain situations, memory usage shoots up at a very fast rate until an FFT_FAILED message pops up. This only happens to me with 2D Complex_to_Complex or 2D Hermitian_to_Real (size is single prec 100 by 81 by 90 by the way). Exact same LabView code but with 3D instead of 2D produces no memory usage increase.

Looking in "clAmdFft.cpp" under "ComputeFFT()":
The issue appears to be with the temporary buffer used in the enqueueTransform function. The buffer is allocated every time the FFT is computed, but it is never deallocated.

Simplest solution is just to never allocate it and let the enqueueTransform allocate its own memory by passing a NULL instead of an allocated buffer. Otherwise it should be allocated only once during FFT plan creation, and it should be deallocated when destroying the plan.

broken error wire in Get Preferred Vector Size.vi will result in lost warnings

not worth fixing now but worth refactoring in next rev. put in error input terminal on the Generate Error.vi and always wire into him. This preserves any warnings on the error line and you can even all logic to the error generator to always give precedence to the incoming error.

again not worth fixing now. I do see that you tend to call the error logic inside an error case structure so your code is safe and you only risk losing warnings not incoming errors (in most cases.)

Very professional API. Good icons are THE MOST important documentation you can give an API in LV and you have done a great job.

good job. let me know what the next steps are.

ver: raptorview_openclv-1.0.1.65

DLL not found when "Create Device GUI.vi" is dropped

Get the popup 5 or so times in a row.

a few things:

use a shifter to hold the Device Out and the Program Handel and just make sure there is valid data there at all times. i see the "use default if unwired" and it makes me nervious

Not sure what the intent is. You know better than me. However I see potential for overflow issues in "Program Manipulation\Global Thread and Offset Quick.vi"

could you provide example pics for each example/demo folder in the prj?

OpenCLV_x64_1.0\Device Manipulation\Create Device GUI.vi

The BD is very big. Strive to fit it on one page - this is a hard and fast rule if your code is visible to customers. I can deal with it. But for every VI you touch/commit to SVN going forward please refactor the BD to fit on a page. Goal is for reader (includes you) to be able to see at a glance with code is doing with out scrolling.

Also I see some error wires that do not go through. If this is intended I recommend explicitly calling this guy.

It tells everybody what your intent is. And it makes LV happy with dependencies, etc.

You can use VI analyzer toi find all instances of unwired error wires. takes some tweaking on the vi analyzer cfg but you can get it to tell you.

Unwired errors are a code smell. A few of them and you wont kill anyone. Lots and lots of them and bugs are inevitable.

good as is but will be more scalable if managed inside a file and parsed dynamically upon first call then stored in an FGV (this is lazy loading in LV).