VMD-L Mailing List

From: John Stone (johns_at_ks.uiuc.edu)
Date: Sun Oct 02 2011 - 23:02:20 CDT

Hi,

On Sun, Oct 02, 2011 at 03:34:39PM -0400, Axel Kohlmeyer wrote:
> On Sat, Oct 1, 2011 at 10:20 PM, John Stone <johns_at_ks.uiuc.edu> wrote:
[...]
> > On Sat, Oct 01, 2011 at 08:58:19AM -0400, Axel Kohlmeyer wrote:
> > [...]
> >> drivers). high-performance quadro cards are very expensive,
> >> but most of the features that they offer over geforce
> >> cards are not exploited by VMD. so you are probably best
> >> off with a GeForce GTX 580 card.
> >
> > This statement is somewhat inaccurate.  VMD benefits directly
> > from the larger memory capacity of the Quadro cards,
> > support for stereoscopic display, improved line antialiasing,
> > ECC memory, dual DMA copy engines, and other features of the
> > Quadro cards.  What Quadro features are you thinking of that
> > VMD does not exploit?  For systems with 20 million atoms,
>
> i guess my wording was very sloppy. what i wanted to express
> is, that in typical use cases, the performance of a high-end
> quadro card is equivalent to a high-end geforce when
> using VMD. stereo is a separate issue.

Absolutely correct, all things being equal.

There are a number cases where a Quadro is faster, but I agree
that within VMD, these would be considered special cases by most
everyday users of VMD. The main ones that arise more broadly are
things like speed of antialiased points, lines, use of multiple
user-defined clipping planes, and running a multiple OpenGL apps
conccurently.

> quadro cards are often presented as if they can make
> magically stuff faster, but if you are looking at a multi-million
> atom system, there is no magic that can give you _that_
> much more performance, say with a VDW rep.

They certainly aren't going to run shaders any faster than a GeForce card
will, so things like the ray-traced sphere representation in VMD
will run no faster on a Quadro than on a GeForce.

> > having the larger memory of the Quadro cards is going to be
> > a big deal.  The new GPU-accelerated surface representations
> > I'm working on will need memory, and this is an area where
> > the Quadro has a huge advantage compared with the GeForce cards.
>
> i'm not talking about features that don't exist yet.
> and i'd like to note that only the highest-end quadro
> cards have a lot more memory than high-end geforce
> cards. a quadro 4000 with 256 GPU cores and 2GB RAM
> is still significantly more expensive ($750) than a geforce
> GTX 580 with 512 cores and 3GB RAM ($550).
>
> however, for a system this large, i'd rather go for
> having a dedicated display GPU and then add an
> additional dedicated "compute GPU" if possible.
> perhaps adding a used Tesla C1060 from somebody
> who upgraded to a newer hardware might be a good
> deal for that purpose.

This makes good sense for the general case. Things are going
to get interesting with the GPU-accelerated representations
in the near future that will change things a bit however.
For pure computing purposes, having additional compute-specific
GPUs works well. For the upcoming graphical representations,
things are a bit tricky, as we will get the best performance
when the computing and display are done on the same GPU, as
we can avoid (at least) two unnecessary host-GPU memory transfers
by having CUDA/OpenCL write their results directly to an OpenGL
input buffer bypassing the host entirely. This is something new
and is mainly of concern for GPU-accelerated graphical representations
like the surface rep we're working on.

> the largest issue that i would dmitry expect to run into
> is neither GPU or CPU bound but rather a software problem.
> he mentioned that he wants to do a cartoon representation
> of his huge systems, i fear that this will not go well with
> the current STRIDE code. i guess we should add the
> necessity of an internal replacement for it to the agenda
> for our next meeting.

He can still use the NewRibbons representation and such, but clearly
STRIDE and DSSP (and probably any other code I've heard of)
won't be able to handle a structure this large. He may need
to run STRIDE on pieces of his structure to get it to work for him.
Replacing STRIDE with our own code is on the TODO list. We can definitely
chat about this in greater depth when you visit.

Cheers,
  John

>
> cheers,
> axel.
>
>
> > Cheers,
> >  John Stone
> >  johns_at_ks.uiuc.edu
> >
> >> cheers,
> >>     axel.
> >>
> >> > Thanks in advance and best regards,
> >> > Dmitry Osolodkin
> >>
> >
> > --
> > NIH Resource for Macromolecular Modeling and Bioinformatics
> > Beckman Institute for Advanced Science and Technology
> > University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801
> > http://www.ks.uiuc.edu/~johns/           Phone: 217-244-3349
> > http://www.ks.uiuc.edu/Research/vmd/       Fax: 217-244-6078
> >
>
>
>
> --
> Dr. Axel Kohlmeyer
> akohlmey_at_gmail.com  http://goo.gl/1wk0
>
> Institute for Computational Molecular Science
> Temple University, Philadelphia PA, USA. 

-- 
NIH Resource for Macromolecular Modeling and Bioinformatics
Beckman Institute for Advanced Science and Technology
University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801
http://www.ks.uiuc.edu/~johns/           Phone: 217-244-3349
http://www.ks.uiuc.edu/Research/vmd/       Fax: 217-244-6078