On Wed, 14 Jul 2010 14:49:49 -0400, Geoffrey Hutchison geoff.hutchison@gmail.com
wrote:
A few weeks ago, the University of Pittsburgh hosted a GPU computing
workshop, and John Stone (the lead developer of VMD) presented. He’s
written some incredibly fast optimizations for rendering orbitals,
including an implementation in OpenCL / CUDA which is close to real-time
for C60 on a fast nVidia card.
I read the paper they published on this with great interest, would have
loved to have attended the workshop.
I talked to him about his code – we can treat the VMD code essentially
like BSD license. (They don’t actually tag the code, but as long as we
use
less than 10% of the codebase, it’s free for unrestricted use.)
This is what really worries me. What does “essentially like BSD license”
actually mean? Is this written down and defined anywhere? Is this
compatible with the GPLv2, you cannot place further restrictions on the use
of GPL code, and this license sounds like it does.
What if two projects used some of their code, and linked, producing an
executable with 10% or more? Would they be willing to relicense the
portions we want to use under a standard license such as GPL, BSD, or
similar? If not, then I would like to verify we can even link to it from
our GPLv2 library/application.
I tried out his optimized approximate exp() function for our GTO code.
First, I got a ~9% speedup from a public domain exp() I found on the
web. I
got ~19% speedup from the VMD approx. exp(). I’m now getting ~11
orbitals
per second for benzene.fchk. That’s a savings of ~2 seconds, but on
something larger that’s a good minute.
It sounds like a great speed up, but I would take the 9% if we can’t clear
up the licensing issue.
I think we can get much larger speedups if we switch to floats for the
orbitals. Certainly we don’t need double precision for rendering, which
is
the main point of John’s talk. If the orbital isosurface is off by
~0.1%,
no one will notice.
Yeah, I never got time to really optimize that code, beyond parallelizing
it. I was thinking at the time of templating all of the relevant classes. I
also wanted to use floats for all rendering, as it would speed up our
rendering in general. There were some concerns about whether we should
store all coordinates as floats though, and risk losing precision.
I think with most visualization a few % is often OK, a tenth of one
percent is no problem. That said, I would love to keep the most accurate
version and the optimized one for both comparison and for when we might be
performing further calculations on the output.
This does sound very promising, and it would be great to optimize this
code. I do think using floats and OpenCL is likely to yield the best
performance, and going forward this will be available on more and more
systems.
Thanks,
Marcus