On Fri, Mar 25, 2011 at 6:34 AM, Yigit Turgut wrote: > Yes it is possible, depending on your algorithm you can attach > process-pixel/thread like schemes and number of cores you have will > determine how many threads you can run simultaneously. > There is a CUDA library for java as well but don't think Java is the > best option here - stick with the C API. With a GTX460 you will have > around 300 cores available for your execution space. If images are > around 200MB then you have 343597383680000 bits for each file and > since each color is represented with an 8-digit hexadecimal > assuming > pictures are squares you have 3276800x3276800 pixel approximately > > 10737418240000 in total. GTX460 has 37.8 billion/sec texture rate thus > it will take about 284 seconds to complete processing each pixel of > one picture ; assuming ideal operating/conversion condition. For a > real world implementation I say it will be around 400~ seconds. With > an SLI setup it can reduce to 210-220 seconds. > > Hi. Thanks for the reply. Yeah, for sure I'm going to be using C++ to program this at the very least. Also, if not CUDA, then I will be using FPGAs. Java was chosen by a friend who was more comfortable with it and when speed was not an issue. Our lab i= s now processing many of these images and speed is now a requirement. 200MB =3D 200E6 B 200E6B/4B per pixel =3D 50E6 pixels 50E6 pixels/37.8E9 pixels/s =3D 0.00132s note that pixels are 4B RGBA colour scheme I'm not understanding your calculations. Are my calculations above wrong? --=20 http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .