[linux-audio-dev] DRI + Jack conflict?

[David Olofson]

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

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:

	http://www.zalman.co.kr/english/product/ZM80C-HP.htm


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