On Thu, Mar 26, 2009 at 2:56 PM, Joel Falcou <joel.falcou@u-psud.fr> wrote:
Felipe Magno de Almeida a écrit :
Could the library's interface match a GPGPU implementation? Creating operations result in shader compilations, so there would have to be a way to save these operations. Like boost::function<vec(vec, vec)>for the performance to be worth. Do you see a way to do this with your library? (This is using a OpenGL implementation).
Well, i have a similar system planned in the matrix library that Boost.SIMD is extarcted from (http://nt2.sourceforge.net). I think it's slightly out of scope for a strictly SIMD library.
Implementationwise, it is doable I think as the core library is already split up upon extension detection. Adding another level is easy. But I fear the performance won't be that great as we'll run lots of small scale operation when GPGPU prefer large amounts of data (hence this being more a model for a matrix library).
FWIW, ACML also offers a GPU library that offloads operations to the GPU when "it makes sense". I do agree with Joel - a GPGPU implementation can be added later. It would probably be better to let OpenCL mature as well, before heading into this area. Joel, how does the extension detection mechanism work? Is there a small runtime penalty for each function as it detects which path would be optimal, or can you define at compile-time what extensions are available (e.g. if you are compiling for a fixed hardware platform, like a console). --Michael Fawcett