On Friday 13 February 2004 13.53, Tim Goetze wrote:
> >Hear hear. I think that GL accelration is a (potentially)
> > important optimisation for audio apps - it saves a lot of cache
> > and memory bandwidth that can be better used number-crunching
> > audio.
> i'm a bit skeptical about this GL + audio business. over the years,
> these splendid 3D accelerator cards have 'improved' to the point of
> being one of the noisiest parts in a system, and consuming serious
Yes... That's a really rather annoying side effect. However, there are
actually quite powerfull cards with large, fan-less heatsinks. It
doesn't get more silent than that! ;-)
And there's always the option of replacing the original heatsink + fan
assembly with a water cooling block (provided you have a water cooled
machine) or a big fan-less heatsink, like this one:
I've mounted these on two ATI FireGL 8800 cards without (major)
problems. The heatsinks are supposed to support bigger/hotter cards
as well, but you should definitely use the optional fan for those.
(I'm using the fan anyway, as there isn't much self circulation with
horizontal heatsinks. Very silent but quite sufficient at 5 V.)
> true open-source support for these chips verges on non-existence.
> wasn't the point of linux to have an all-open-source system? i for
> one won't run binary GL drivers.
Well, as annoying as it it, it seems like we'll just have to accept
that the drivers are part of the package. You buy a video card, and
you get drivers one way or another; drivers that are pretty close to
firmware, except that it runs on the host CPU. And you don't have the
source of the firmware in your printer, modems and other devices, do
you? Doesn't really matter as long as they work, and speak some
comprehensible standard protocol.
Still, I'd really prefer if I could debug these bl**dy ATI drivers
myself, rather than wasting time posting bug reports to ATI. And
having the source of my laser printer's firmware could be fun...
> and if you design your application around it, a system that does
> GL in software will suffer big time from the cache, memory
> bandwidth *and* CPU cycle hit. i've seen some simple GL-enabled
> applications freeze software GL systems to a virtual standstill
> because it never dawned on the author that this has to be taken
> into account.
Actually, many OpenGL developers do sort of take s/w OpenGL in
account: They explicitly do not support it, as it's dog slow pretty
much by definition, and there isn't much to do about that. OpenGL
doesn't lend itself well to s/w implementation.
> i do agree that GL is a potentially important optimization. i don't
> expect the potential to manifest itself within the next cople of
> years though. :)
Well, M$ and Apple desktop environments seem to be moving towards
using 3D acceleration for all rendering, but 3D acceleration probably
isn't cheap and widely available enough for this approach to
completely replace s/w rendering and 2D acceleration just yet.
Embedded PC hardware still generally comes without 3D acceleration,
and it'll probably stay that way until GPU power consumption has been
reduced by at least an order of magnitude. I'd assume your average
laptop user would really rather not waste power on eyecandy either.
So, I guess the 2D acceleration and s/w rendering APIs will be
relevant for several more years to come - and applications should
preferably support *both* 2D and 3D APIs when appropriate. (Could be
done through 2D-over-3D wrappers or backends.)
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
--- http://olofson.net --- http://www.reologica.se ---