Soldato
- Joined
- 25 Sep 2008
- Posts
- 6,767
- Location
- Orsett, Essex
Vincent Voelz, who is certainly very active these days, has put into production a new series of projects for the nVidia GPU2 client: projects 5781 to 5786.
These projects simulate several proteins that have similar amino acid sequences. Curiously, although these sequences differ by only a few residues, their folding is rather different (see "this article" for details). We are interested here in the nature of these sequence dependencies in protein folding, and we try to answer the following questions: in nature, are the folding disruptions local or not? Moreover, are the current simulations using implicit solvent sufficiently accurate to detect this sequence dependency? If so, this will be an interesting starting point for developing tools that will lead us to the computer design of both the structure and dynamics of proteins.
These projects will inaugurate the first GPU server using the v5 server code; the IP address is 171.67.108.21. Each project has 922 atoms, and can therefore still be considered small proteins. The WUs should preferably be returned within 15 days, and no later than 25 days, although most current nVidia GPUs will be able to return units within 24 hours. Each unit is worth 783 points.
Source
These work unit's are really fast some people are getting 9K with a GTX275

Some more details on the GPU3 core
Here is an update and some more details on the third generation GPU core. As I stated before, this core is built on OpenMM, which brings the science further along and allows us to make easier updates. OpenMM supports OpenCL in beta form in its 1.0 release (scheduled for late January 2010), but it is important to stress that the OpenCL support is very early and so we will not be relying on OpenCL in the first releases of the GPU3 core.
This means that the core will only roll out for NVIDIA first. ATI has depreciated Brook, but does not have a fully-functioning OpenCL implementation, so we are stuck in between support on the ATI side. Once the OpenCL implementation matures (on both ATI and NVIDIA), we will be able to finish and optimize our OpenCL code (we can't reliably optimize code until the implementations are more finalized), and then the OpenCL portions will go into QA.
So, if you are interested in OpenCL (especially in terms of ATI support), this will not be in the initial release, but once the environment has matured, we will push forward. By the way, once OpenCL support for multi-core boxes has matured, we will also see about porting the GPU3 code as a new SMP2 style core as well (i.e. threads-based SMP support). If the performance is strong, it's appealing to think that we can go back to having a single dominant code base for much of FAH's calculations.
Source
Bit more i missed
Just an update on my blog post. I want to make it clear that we're seeing problems in both of our ATI and NVIDIA GPU OpenCL implementations for OpenMM. Maybe it's on our side (I'm bet some bugs are on our side), but we suspect there could possibly be some issues with both the NVIDIA and ATI OpenCL implementations (and maybe even Apple's). We are working with everyone closely to either fix our bugs or get our code compliant with the OpenCL implementations.
Also, it looks like I should have been more careful in my wording of my previous post. I was referring to the issues above when talking about whether the ATI implementation was "fully functional" and some groups have gotten this out of my intended context. As far as I understand, the ATI OpenCL implementation is fully functional.
Finally, it is important to note that our Brook code is still supported, just not actively developed so Folding@Home/OpenMM is concentrating on shifting to OpenCL, so no more active development using Brook.
Looks like ATI will be left out of the show again at least for now

Last edited: