I am a beginner in OpenCL programming. My PC has windows 8.1 with both intel graphics and AMD Radeon 7670. When I searched to download an OpenCL SDK and sample helloworld programs, I found that there are separate SDKs and programs in entirely different formats available. I have to use C not C++. Can anyone suggest which SDK I should install? Please help.
At the lowest level, the various OpenCL SDKs are the same; they all include cl.h from the Khronos website. Once you've included that header you can write to the OpenCL API, and then you need to link to OpenCL.lib, which is also supplied in the SDK. At runtime, your application will load the OpenCL.dll that your GPU vendor has installed in /Windows/System32.
Alternatively, you can include cl.hpp and use the C++ wrapper, but since you said you're a C programmer, and because most of the books use the C API, stick with cl.h. I think this might account for the "programs in entirely different formats" observation you made which is why I bring it up here.
The benefit of one SDK over another typically is for profiling and debugging. The AMD SDK, for example, includes APP Profiler (or now CodeXL) which will help you figure out how to make your kernels faster. NVIDIA supplies Parallel Nsight for the same purpose, and Intel also has performance tools.
So you might choose your SDK based on the hardware in your machine, but understand that once you've coded to the OpenCL API, your application can run on other GPUs from other vendors -- that is the benefit of OpenCL. You should even be able to get samples from one vendor to execute on hardware from another.
One thing to be careful of is versions: If you code to an OpenCL 1.2 SDK you might not run on OpenCL 1.1 hardware.
For me the best thing with OpenCL is that you do not need an SDK at all because it abstracts different Vendor implementations behind a common Interface (see Answer in this Thread: Do I really need an OpenCL SDK?).
Related
I'd like to start playing with ARM TrustZone, so I'd like to setup a development environment, unfortunatelly I have the feeling I'm still missing something, I don't know how to put everything together.
This is my current picture:
A SoC with a Cortex-A processor is required
is it possible to develop without a board? i.e. emulators?
TrustZone is a Hardware & Software technology
If I get a SoC board, is the hardware part already covered?
The software (OS/Kernel) part may be solved with GlobalPlatform, OpenTEE, etc.
TrustedApplications development
Which IDE's are there?
How are they deployed to the board?
I know this is a quite extensive question, I'll be happy to get links to online material.
Edit:
Some parts of my question were partially answered, but the most important thing hasn't been answered yet: is the picture I detailed correct and complete? Yes/no, why?
And no, this is not a duplicate of Which ARM based development boards should I use?
For emulator, you can use ARM Fast Model (https://developer.arm.com/products/system-design/fast-models) if you have the budget.
QEmu might have some Trustzone support but I am not sure how reliable is the Trustzone implementation (What works on QEmu might not work on real hardware). joakim-bech (one of the lead engineer working on an Open-Source implementation of Trusted OS) said in his stackoverflow response it should work; And he has still confirmed it in the blog post TEE Development With No Hardware - Is That Possible?...
I would recommand you to have a look at the list of platforms supported by Optee - Open Portable Trusted Execution Environment: https://github.com/OP-TEE/optee_os#3-platforms-supported
The answers to your other questions would really depend of the platform you use, your budget, your development environment, etc
For less than $150:
If you want to stick to Windows you might have to build qEmu yourself (qEmu seems to support Windows but I am not sure if the Windows already-built binaries support Trustzone). In term of HW board, I use the Hikey board (currently at $119) for my Trustzone development.
Using Linux for the development will probably save you some time as for this budget you will probably have to use Open-Source solutions that generally primarily support Linux.
To start developing a Trusted App for OP-TEE:
I used this presentation: https://www.slideshare.net/linaroorg/lcu14103-how-to-create-and-run-trusted-applications-on-optee
I updated/improved the original example code, my changes could be found here: https://github.com/oliviermartin/lcu14_optee_hello_world
I have an application, written in C, which runs on multiple platforms: Windows and various flavors of Unix. The two most important are Linux, then Windows.
One of the core algorithms could benefit from CUDA acceleration. However, everything must run normally if the system isn't CUDA-capable, (or the user doesn't specifically ask for GPGPU acceleration).
So, I need to make sure the application tries to load the CUDA libraries only under the right circumstances.
On Windows, the delay-load mechanism makes this fairly easy.
Is there a similarly easy mechanism to do this on Linux? Or do I have to go through the contortions involved with dlopen()?
You have two choices, both perfectly valid:
As you note in your question, use dlopen to load dynamic libraries at runtime
Statically link the CUDA toolkit libraries into your application. NVIDIA have been shipping static versions of the toolkit libraries for linux for several major release cycles, and static linking is fully supported. The downside of this approach is application size.
I'd like to develop a network based application for the Arduino platform. The examples shipped with a Wi-Fi Shield library are all multifile sketches with a network part implemented in C. I'd like to figure out how to implement the network portion in a way regular C/C++ development is conducted (with a decent IDE and step-by-step debugger).
I noticed WiShield is build on top of the uIP library ((an open source full TCP/IP stack implementation for resource-constrained embedded devices)) and greatly influenced by it. Smart folks implemented DHCP and zero configuration implementations on top of it. How do people execute projects of such complexity and what tools are being used?
Are you looking for some Arduino emulator? I think these two should get you started.
Emulino
Simavr
Use the simple programming software that can easily work with arduino chips but don't make your project in complex situation putting some complex programs.
Next term, I'll need to write a basic operating system for Motorola 68K processor as part of a course lab material.
Is there a Linux emulator of a basic hardware setup with that processor? So my partners and I can debug quicker on our computers instead of physically restarting the board and stuff.
Is it possible to apply test-driven development technique to OS development? Code will be mostly assembly and C. What will be the main difficulties with trying to test-drive this? Any advice on how to do it?
I would recommend developing an operating system for the classic Amiga computers, which had different versions of the 68000 processor. Since the Amiga computer is a complete computer and is extremely well documented, I thought this would be a good exercise.
There is an emulator for it called UAE (and Win-UAE) which is very exact and
can be configured with different kinds of processors (68000 - 68060) and other capabilities. Normally, you would also need to acquire ROMs for it, but since you are developing an operating system yourself, this is not necessary.
Tools you will need is either Cygwin (for developing under Windows) or a Linux computer. Then you will need cross compilers. This includes both a C compiler and an assembler. Here is a template for creating a simple ROM which changes screen color and flicks the power LED. It will create a file 'kick.rom' which UAE then searches for in the current directory.
Reference on the 68000 instruction set can be found at the links below. Be aware that different assembler programs may use slightly different syntax and instruction set.
If you need to demo the operating system on real hardware, there are modern Amiga clones sold on Ebay and other places. Search for "Minimig".
Update:
Nowadays AROS also runs on UAE as well as physical Amigas.
Refs:
[UAE]
[WinUAE]
[Cygwin]
[Cross Compilers]
[68000 reference]
I would suggest QEMU for m68k emulation.
(The system emulator you want in QEMU is "Coldfire" - that's what Freescale calls the successor to the m68k architecture).
You certainly can tdd this project. First off decouple all accesses to the hardware with simple routine calls, e.g. getch() and printf, then you can provide simple mocks that provide test input and check output. You can then write well over 90% of the project on a PC using gcc, msdev or xcode. Once you have got some confidence in the decoupling routines you will need very little access to the hardware, and only then to occasionally check that your mocks are acting as you expect.
Keep to C until you find a particular bottle neck, and only then resort to assembler.
There are a few new projects that use hardware simulated 68000 cpus, the C-One project, the Minimig (Mini Amiga) project and the Natami (Native Amiga) project - they are new 68k compatible Amiga systems.
C One, reconfigurable computer, Minimig, in development, prototypes done: FPGA Arcade and Natami.
The Easy68k http://www.easy68k.com simulator might help you.
The uClinux project started on a m68k board. They may have the tools you need...
What things should be kept most in mind when writing cross-platform applications in C? Targeted platforms: 32-bit Intel based PC, Mac, and Linux. I'm especially looking for the type of versatility that Jungle Disk has in their USB desktop edition ( http://www.jungledisk.com/desktop/download.aspx )
What are tips and "gotchas" for this type of development?
I maintained for a number of years an ANSI C networking library that was ported to close to 30 different OS's and compilers. The library didn't have any GUI components, which made it easier. We ended up abstracting out into dedicated source files any routine that was not consistent across platforms, and used #defines where appropriate in those source files. This kept the code that was adjusted per platform isolated away from the main business logic of the library. We also made extensive use of typedefs and our own dedicated types so that we could easily change them per platform if needed. This made the port to 64-bit platforms fairly easy.
If you are looking to have GUI components, I would suggest looking at GUI toolkits such as WxWindows or Qt (which are both C++ libraries).
Try to avoid platform-dependent #ifdefs, as they tend to grow exponentially when you add new platforms. Instead, try to organize your source files as a tree with platform-independent code at the root, and platform-dependent code on the "leaves". There is a nice book on the subject, Multi-Platform Code Management. Sample code in it may look obsolete, but ideas described in the book are still brilliantly vital.
Further to Kyle's answer, I would strongly recommend against trying to use the Posix subsystem in Windows. It's implemented to an absolute bare minimum level such that Microsoft can claim "Posix support" on a feature sheet tick box. Perhaps somebody out there actually uses it, but I've never encountered it in real life.
One can certainly write cross-platform C code, you just have to be aware of the differences between platforms, and test, test, test. Unit tests and a CI (continuous integration) solution will go a long way toward making sure your program works across all your target platforms.
A good approach is to isolate the system-dependent stuff in one or a few modules at most. Provide a system-independent interface from that module. Then build everything else on top of that module, so it doesn't depend on the system you're compiling for.
XVT have a cross platform GUI C API which is mature 15+ years and sits on top of the native windowing toollkits. See WWW.XVT.COM.
They support at least LINUX, Windows, and MAC.
Try to write as much as you can with POSIX. Mac and Linux support POSIX natively and Windows has a system that can run it (as far as I know - I've never actually used it). If your app is graphical, both Mac and Linux support X11 libraries (Linux natively, Mac through X11.app) and there are numerous ways of getting X11 apps to run on Windows.
However, if you're looking for true multi-platform deployment, you should probably switch to a language like Java or Python that's capable of running the same program on multiple systems with little or no change.
Edit: I just downloaded the application and looked at the files. It does appear to have binaries for all 3 platforms in one directory. If your concern is in how to write apps that can be moved from machine to machine without losing settings, you should probably write all your configuration to a file in the same directory as the executable and not touch the Windows registry or create any dot directories in the home folder of the user that's running the program on Linux or Mac. And as far as creating a cross-distribution Linux binary, 32-bit POSIX/X11 would probably be the safest bet. I'm not sure what JungleDisk uses as I'm currently on a Mac.
There do exist quite few portable libraries just examples I've worked within the past
1) glib and gtk+
2) libcurl
3) libapr
Those cover nearly every platform and so they are extremly useful tool.
Posix is fine on Unices but well I doubt it's that great on windows, besides we do not have any stuff for portable GUIs there.
I also second the recommendation to separate code for different platforms into different modules/trees instead of ifdefs.
Also I recommend to check beforehand what are the differences in you platforms and how you could abstract them. E.g. this is some OS related stuff (e.g. the annoying CR,CRLF,LF in text files), or hardware stuff. E.g. the previous mentioned posix compability doesnt stop you from
int c;
fread(&c, sizeof(int), 1, file);
But on different hardware platforms the internal memory layout can be complete different (endianess), forcing you to use conversion functions on some of the target platforms.
You can use NAppGUI for both console and desktop apps. The SDK uses ANSI-C and your code will work on Windows/macOS/Linux.
https://www.nappgui.com
It's free and OpenSource.