Accelerating MO Rendering

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 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.)

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.

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.

-Geoff

On Wed, Jul 14, 2010 at 8:49 PM, 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 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.)

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.

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.

Yes, I did some experimenting with OpenCL before my desktop broke and
remember float vs double performance to make a significant difference.
The cheaper graphics cards still on the market also don’t support
double precision.

OpenCL would be optional I guess? There are some other areas that
might benefit from using OpenCL. The vdw cube could be done in OpenCL.
A more interesting project would be an OpenCL implementation to map
various properties (i.e. electrostatic, lipophilic, …) to surfaces.
We currently have an electrostatic color method for vdw surfaces but
this is really slow.

-Geoff

This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/firsthttp://p.sf.net/sfu/sprint-com-first


Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
avogadro-devel List Signup and Options

On Jul 14, 2010, at 3:10 PM, Tim Vandermeersch wrote:

OpenCL would be optional I guess?

Yes, I believe there’s already a CMake module for detecting it, in which case we should enable its use by default.

There are some other areas that might benefit from using OpenCL.

Yes, exactly. I think if available, OpenCL should be used for most surface rendering. I suspect we’d get large speedups on machines with OpenCL for not much work.

-Geoff

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

On Thursday 15 July 2010 02:01:40 Marcus D. Hanwell wrote:

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.

Quoting what looks like the relevant section of the VMD license,

2. Licensee may, at its own expense, create and freely distribute complimentary works that interoperate with the Software, directing others to the TCBG server to license and obtain the Software itself. Licensee may, at its own expense, modify the Software to make derivative works. Except as explicitly provided below, this License shall apply to any derivative work as it does to the original Software distributed by Illinois. Any derivative work should be clearly marked and renamed to notify users that it is a modified version and not the original Software distributed by Illinois. Licensee agrees to reproduce the copyright notice and other proprietary markings on any derivative work and to include in the documentation of such work the acknowledgement:

“This software includes code developed by the Theoretical and Computational
Biophysics Group in the Beckman Institute for Advanced Science and
Technology at the University of Illinois at Urbana-Champaign.”

Licensee may redistribute without restriction works with up to 1/2 of their
non-comment source code derived from at most 1/10 of the non-comment source
code developed by Illinois and contained in the Software, provided that the
above directions for notice and acknowledgement are observed. Any other
distribution of the Software or any derivative work requires a separate
license with Illinois. Licensee may contact Illinois (vmd@ks.uiuc.edu) to
negotiate an appropriate license for such distribution.

That looks a lot like an advertising clause, which made the original BSD
license incompatible with the GPLv2. What was merged does not look like it
complies with “provided that the above directions for notice and
acknowledgement are observed”, but it is not clear to me which above
directions need to be followed either. Copyright and other proprietary
markings?

Before we go merging this into Avogadro I would like to get advice from the
FSF or similar. How do we track the percentage of code, or it “very little” a
reasonable approximation of less than 10%? Do we need to mark the sections off
in our code, assuming their license is GPL compatible, as 0.5% of VMD -
warning, do not exceed 10% total.

I have changed the subject to reflect this is off topic to the original post,
but I think it deserves consideration and some research before merging in code
from VMD.

Thanks,

Marcus

On Jul 15, 2010, at 2:17 PM, Marcus D. Hanwell wrote:

Before we go merging this into Avogadro I would like to get advice from the
FSF or similar. How do we track the percentage of code, or it “very little” a
reasonable approximation of less than 10%? Do we need to mark the sections off
in our code, assuming their license is GPL compatible, as 0.5% of VMD -
warning, do not exceed 10% total.

How about we just ask John Stone and the VMD developers for a clarification. They’re the original copyright holders, so if we say “can we included X, Y and Z source in Avogadro and it’s GPL” and they say “yes,” I don’t see a need for advice from the FSF – VMD has allowed their code to be included.

I did ask John about the approximate exp() function and he said yes. I’d be happy to clarify further.

For what it’s worth, VMD is many thousands of lines of code, and I suspect we’d only be interested in a few hundred. Moreover, we’d probably need to rewrite and refractor their “more interesting” code (e.g. Open CL surfaces and MOs) to work with Avogadro.

I’m traveling right now, but I’d be happy to ask John for further clarification.

-Geoff

On Thursday 15 July 2010 17:36:06 Geoffrey Hutchison wrote:

On Jul 15, 2010, at 2:17 PM, Marcus D. Hanwell wrote:

Before we go merging this into Avogadro I would like to get advice from
the FSF or similar. How do we track the percentage of code, or it “very
little” a reasonable approximation of less than 10%? Do we need to mark
the sections off in our code, assuming their license is GPL compatible,
as 0.5% of VMD - warning, do not exceed 10% total.

How about we just ask John Stone and the VMD developers for a
clarification. They’re the original copyright holders, so if we say “can
we included X, Y and Z source in Avogadro and it’s GPL” and they say
“yes,” I don’t see a need for advice from the FSF – VMD has allowed their
code to be included.

I did ask John about the approximate exp() function and he said yes. I’d
be happy to clarify further.

Ah, if he owns the copyright, and has said we can include it in a GPLv2
project under the GPLv2 (or later ideally), then there is no problem. It
wasn’t clear to me whether he owned the copyright, and the wording of their
license is unclear to me. I am not a lawyer, but I have never had cause to
worry about a license with terms like that.

For what it’s worth, VMD is many thousands of lines of code, and I suspect
we’d only be interested in a few hundred. Moreover, we’d probably need to
rewrite and refractor their “more interesting” code (e.g. Open CL surfaces
and MOs) to work with Avogadro.

I just don’t want us to have any legal/licensing issues. If John can grant us
use of the code, and it is under a license compatible with GPLv2 then that is
fine. Although it would be nice to know, and label, what license that code is
under.

I’m traveling right now, but I’d be happy to ask John for further
clarification.

That would make me feel a lot better, knowing exactly what license the code is
under, labeling it as such, etc would be good. Also, if I were to split this
code out, could I license it BSD three clause, LGPL, GPL? Or, should I avoid
using it altogether?

I am not trying to be difficult, I would like it to be explicitly clear what
license the code is under, and how/what I can use that code for. Otherwise it
becomes code I effectively cannot use as the terms are too vague. It can wait
until you are done traveling, but it would be good to have some definite
answers.

Thanks,

Marcus