octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GPU computing for octave


From: Xavier Delacour
Subject: Re: GPU computing for octave
Date: Fri, 14 Mar 2008 11:57:47 -0400

A more interesting (and more ambitious) approach might be to generate
bindings for cuda/brook/sh frameworks themselves, such that users
could compile/prepare and then invoke a cg routine from within Octave.

eg,
mkcudafile("cuda_fft.cu");
cuda_fft(...);

There is definitely value in parallelizing common routines like FFT,
GEMM, etc. But quite a bit of research depends on custom cg coding.
Lowering the complexity barrier to integrate that custom work into
Octave would be useful I think.

Xavier

On Fri, Mar 14, 2008 at 9:55 AM, David Bateman
<address@hidden> wrote:
> Ronny Lindner wrote:
>  > hello,
>  >
>  > I recently started my diploma thesis on GPU computing and I want to
>  > develop plugins for some octave functions so that they run on the
>  > graphics card. It might be possible to achieve a speedup of up to 20!
>  >
>  > I know there is a CUDA (GPU computing) plugin for matlab, but it only
>  > works on nvidia cards and my aim is to develop an octave plugin for
>  > amd+nvidia, windows+linux.
>  > Has anyone tried something similar before?
>
>  However, wouldn't trying to use the CUDA interface with Octave already
>  be a good start.. Octave can use matlab mex file in source code form and
>  CUDA mex files are supplied with their source.. Also it seems that the
>  NVIDIA GPU works on C99 complex values rather than their real and
>  imaginary parts as matlab doe, so there will be speed improvements if
>  these files were converted directly to oct-files
>
> >
>  > Do you know any functions that are good candidates for parallelization?
>  What do you mean? I'd probably wouldn't base an answer on what is most
>  easily parallelized, but rather what function being parallelized will
>  give the most benefit to my (or rather your) programs.. I'd probably
>  target a xGEMM blas replacement and an FFT as the first targets as the
>  most useful code to have running fast.
>
>  D.
>
>  --
>  David Bateman                                address@hidden
>  Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph)
>  Parc Les Algorithmes, Commune de St Aubin    +33 6 72 01 06 33 (Mob)
>  91193 Gif-Sur-Yvette FRANCE                  +33 1 69 35 77 01 (Fax)
>
>  The information contained in this communication has been classified as:
>
>  [x] General Business Information
>  [ ] Motorola Internal Use Only
>  [ ] Motorola Confidential Proprietary
>
>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]