You are here

Home » Neural Network Forums » Encog Project » Encog Developer Contributor (Java and C#)

More notes on OpenCL

jeffheaton's picture
published by jeffheaton on Sun, 10/10/2010 - 19:21

Some other interesting facts I am finding on OpenCL. When I do build some sort of multi-highend GPU based computer, I would really rather locate it at a colo that I use. Probably built rack-mount style. I hope the EVGA motherboard and very long nVidia Tesla cards will actually fit properly.

But a few other logistical problems I've noticed. I can't use OpenCL from a Windows service. It bombs out with no graphics adapter found. Much like if I tried to kick off OpenGL or DirectX from a service. Also, if I use "terminal services" and login to a machine that has an OpenCL GPU on it, it bombs if I try to kick off a program that uses OpenCL. OpenCL is very much like a video game, you run it at the console. Not sure how Linux is.

One side-product that we will be releasing at some point. Probably in either 2.7 or 3.0(there may not be a 2.7) is something called Encog-Node. Meant to run somewhat headless. You can run it as a service/daemon if you are not using OpenCL. But if you ARE using OpenCL you run it console, probably as a startup app, and it will launch and run very similar to a full-screen video game. Where I will go full-screen using OpenGL and then I can drop the GPU down to just a black 320x200 (minimal memory) screen just saying "Encog Node - 01 - Press space to exit", or something like that. Kind of a very boring video game! It will take all of its commands via TCP/IP and can function using the scheduler on another machine (part of a grid). By the way, keyboard is totally responsive while running heavy GPU. Mose is kind of dicey because you are rarely getting video-screen updates. So the only way to stop it would be a TCP/IP command or a keyboard command.

Jeff

Neural Network Forums: 
Encog Developer Contributor (Java and C#)
jmvaret's picture

Submitted by jmvaret on Wed, 10/13/2010 - 12:14.

Dear Jeff,

I'm about to download 2.5b1 and start giving it a try on my multi-GPU system. I'll post some performance numbers on the forum, of course, for you to take a look at, etc.

First, I'd like to check with your "TuneEncongOpenCL" application, that both cards get properly detected and the CL code is not crashing my system anymore (like it happened with the old 1.0 tuneOpenCL utility).
But thing is, I've not been able to find any 1.x or 2.x version for tuneEncogOpenCL in your download area, neither in your openCL area. Only the ol' good version 1.0 is available for download.

Is such an updated encog openCL tuning application available, which included encog's new openCL code?

thanks for your time,

jeffheaton's picture

Submitted by jeffheaton on Wed, 10/13/2010 - 19:42.

TuneEncongOpenCL is a C# application. And because Encog 2.5 for C# really does not exist yet, I have not be able to produce a new version of TuneEncongOpenCL. The tune application will be quite a bit different, reflecting changes in Encog. I may also port it to Java.

jmvaret's picture

Submitted by jmvaret on Wed, 10/20/2010 - 13:59.

Hi jeff,

I've just started porting one of our applications to encog 2.5beta. Not a great deal here, since 2.5 pretty is pretty much working right out of the box in place of the good 'old 2.4, but anyway or own code requires some big changes due to the fact that, from now onwards, we will be able to train more than one network at once, spanning them across our GPUs.

I've been reviewing the new javadoc for your new CL objects/classes. They look like great, by the way. Thing is, I wonder whether you are publishing some kind of CL java example source code, in order to show developers how to take advantage of encog 2.5's new CL subsystem. A couple of advanced topics (like CL enqueuing and CL kernel construction/usage) could use a good java example or two !

thanks for your time,

jeffheaton's picture

Submitted by jeffheaton on Wed, 10/20/2010 - 20:57.

I actually just did a video tonight that features the new Encog OpenCL Benchmark.

http://www.youtube.com/watch?v=e2sGq_vI41s

I have not yet placed it for download. But I did rewrite the tuning article to focus on the new features. I expect that it will be released this week.

Glad to hear Encog 2.5 is working well. So far the only bug reports have been in the workbench. There are quite a few unit tests guarding Encog from getting too messed up in these major releases. But there is always a chance to miss something, hence the beta period.

Yes there will be scheduler examples.

I also think the new OpenCL database will be pretty cool, especially if lots of people submit profiles on their GPU's. This can be done through the soon to be released Encog OpenCL Benchmark. You can see my two OpenCL devices already in there.

http://www.heatonresearch.com/opencl

3dmashup's picture

Submitted by 3dmashup on Sat, 03/26/2011 - 20:49.

"But a few other logistical problems I've noticed. I can't use OpenCL from a Windows service. It bombs out with no graphics adapter found".

This not specifically an OpenCL problem. It's a feature of Windows security architecture that was introduced in Vista & Windows 2003. It's there to prevent any service, that could be a Trojan, from accessing the UI and tricking users into elevating the services privileges. So it will also bomb on any graphics card/UI access, from a Windows service, and that includes CUDA. I think there should be a way to override this and give a Windows Service GPU access privileges, but I won't hold my breath for that from MSFT.

There are some alternatives that do work

1) Start a background process at start-up and connect to it via RPC or TC/IP. It's lots of code and messy plumbing ...
2) Embed the OpenCL code in a database like PostgreSQL see http://www.scribd.com/doc/51484335/PostgreSQL-OpenCL-Procedural-Language....

Approach 2) gives the all the benefits of a database for OpenCL persistence access to the PostgreSQL Eco-sphere for developing client/server or Web applications.

jeffheaton's picture

Submitted by jeffheaton on Tue, 03/29/2011 - 07:20.

I've also found I can run OpenCL as a service on Linux just fine. Seems to be a more developed platform for hard core number crunching with OpenCL.

The Postgre option is interesting. I don't want to introduce PostgreSQL as an Encog dependency. Namely you would have to have Postgre installed to use Encog. This is where the plugin architecture will be useful.

For next pass of it, I plan to just directly access OpenCL from Java/C# like I did before. I noticed Postgre takes exactly the same OpenCL kernel code, so porting in this direction later should not be too hard.

The real "double edged sword" with GPU is that the GPU is very fast. But ONLY on the math code. It is far more complex to program GPU and traditional multicore. It is hard enough to break a job into pieces for multicore. But for GPU you have to break it into piceces for the CPU cores, then into smaller pieces that the GPU might be good at. Then you just have to hope that you do not incur too much overhead getting the GPU its pieces, or you might as well have just done the whole thing with the CPU. And if you offload to the GPU in too large of chuncks, then the OS shuts down your kernel. All a VERY delicate balancing act. But I do think I have a way to accomplish.

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer