[5715] in Release_7.7_team
Re: Athena machine graphics drivers
daemon@ATHENA.MIT.EDU (William Cattey)
Tue Feb 13 13:08:31 2007
In-Reply-To: <E92612DA-60D6-48C0-8159-DCB4E83449D0@mit.edu>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <C8E17167-3000-482D-86D2-114A4C4A7ADB@mit.edu>
Cc: Ivica Ceraj <ceraj@mit.edu>, Justin Riley <Riley000@MissouriState.edu>,
owls@mit.edu, release-team@mit.edu
Content-Transfer-Encoding: 7bit
From: William Cattey <wdc@MIT.EDU>
Date: Tue, 13 Feb 2007 13:08:04 -0500
To: Charles Shubert <cshubert@mit.edu>
X-Spam-Flag: NO
X-Spam-Score: 0.00
Hi Chuck,
I'm actually no longer in the Athena reporting chain, so my answer is
definitely NOT definitive. I've added the owls (Athena strategy) and
the release-team (Athena implementation) team lists to the CC list here.
Summary: The Athena Release is the victim of 20 years of evolution
to be very low-cost, and very generic. To try and take it in the
direction of offering a non-generic high performance graphic aspect
to all or most of the systems served by the Release is extremely
difficult, effectively impossible.
Probably the best way to proceed is with a designated small group of
systems where some person takes on the responsibility of making
tweaking performance on those systems.
Detail:
What you propose is extremely problematic logistically from a number
of standpoints:
1. The Athena Release is in a period of rampdown where the IS&T
decision has been made to put progressively less energy into evolving
it over time.
2. The Athena Release, to minimize the maintenance effort, has been
HEAVILY focused on using components as generic as possible, and to
MINIMIZE, effectively to zero, the number of special purpose drivers
we fetch off the net and hand install to match particular hardware.
3. The distribution model for the Athena Release is basically,
"anyone who knows how can run the installer and get it without
accepting any special licenses". This means that graphics drivers,
most of which come with "click through" licenses applicable to
individuals are a PARTICULAR no-no for inclusion in Athena.
4. The diverse equipment base of Athena and the generic OS setup of
Athena means that we'd be talking about fetching, testing,
integrating, and maintaining, not one or two, but more like 8 or 10
special purpose graphics drivers, most of which we really would not
be supposed to be redistributing.
Instead what you would need to do is override the generic OS installs
on specific machines. Athena offers the ability to install special
RPMs and even to prevent OS updates from displacing them. This sort
of hand-tooling is done by the system owners. For systems owned by
MIT, the way we did this in the past was to have designated special
purpose clusters or groups of systems. But there again, the work was
not done by Athena developers, and not part of the mainline release.
Someone affiliated with a department or with the Faculty Liaisons was
the designated person to make sure the hand tooling was done and kept
up to date.
The future vision for Athena is that it gets out of the business of
offering the operating system, and instead offers services on top of
a pre-installed OS. By sacrificing generic-ness, and middle-of-the-
road-ness, it will be easier in the future to expect systems in the
field to already have the highest performance graphics drivers
installed. But we're still in the "explore the Vision" stage.
Sorry to be unable to give the solution you hope for. Perhaps
someone on owls or release-team sees something I have missed, but I
think that by giving you the answer, "we've always given in the
past", that you'll get an early version of what the "real answer is
right now."
Sorry,
-Bill
----
William Cattey
Linux Platform Coordinator
MIT Information Services & Technology
W92-176, 617-253-0140, wdc@mit.edu
http://web.mit.edu/wdc/www/
On Feb 13, 2007, at 9:12 AM, Charles Shubert wrote:
> Hi Bill,
>
> I'm not sure if you are the person to answer this question, but
> I've had 3 people point the finger at you. So ...
>
>
> Problem:
>
> We have a protein visualization program that is built on top of
> Java3D (http://web.mit.edu/star/biochem/). It is pretty demanding
> on graphics drivers. The graphics drivers drivers on the Athena
> cluster machines in the clusters seem to us the generic driver.
> This creates a performance problem for us for rotation of molecules
> with the atoms showing.
>
> We get reasonable performance when we replace the generic driver
> with the the native driver for a particular graphics card.
>
> This particular performance problem becomes a real big problem as
> the size of the molecule gets bigger. With the current performance
> students are limited to looking at fairly small molecules. Our
> program is setup to retrieve any of the molecules in the Protein
> Data Bank. Last year there were about 30,000 proteins in the
> Protein Data Bank. This year there are about 40,000 and the
> crystallographers are submitting larger and larger molecules. So,
> poor rendering performance is a problem.
>
>
> Solution:
>
> To address the performance problem I'm rewriting the way our
> program renders molecules, but it would be helpful if we could
> improve the performance by taking advantage of fast graphics drivers.
>
>
> Timeframe:
>
> I'd like to have my new version of the software and fast graphics
> drivers for Athena cluster machines in place for Fall, 2007.
>
>
> How can we make this happen?
>
> Thanks,
>
> --Chuck
>
