Hi david

have you looked at F-script, it has a APL way of dealing with 
collections of objects. I'm sure
that this is not what you where referring to but this is interesting.
Epscially because the author of F-script told that contrary to what I 
was thinking he can do some
good optimization.

Stef
On vendredi, décembre 6, 2002, at 10:32  pm, David A. Smith wrote:

> Actually, the graphics chip manufacturers are moving in the direction 
> of general purpose massively parallel hardware. One of the goals of 
> our project is to tap into that kind of potential to go beyond 
> graphics computation. The VPU access is a start, but to be honest, the 
> real win will come later on. Our matrix extension is intended to add 
> similar general purpose capabilities to those available in APL, with 
> real performance. This kind of capability is not just needed for 3D 
> graphics, but for any kind of serious scientific simulation.
>
> Regards,
>
> David
>
>
> At 12:03 PM 12/6/2002 +0100, you wrote:
>> On Fri, 6 Dec 2002, Joshua D Boyd wrote:
>>
>> > On Thu, Dec 05, 2002 at 03:03:08AM -0500, Joshua 'Schwa' Gargus 
>> wrote:
>> >
>> > > Tell me more!  Arbitrary n-D matrix operations will be hardware
>> > > accelerated, yet accessed through a nice (extended) Smalltalk
>> > > interface?  Cool!
>>
>> Actually I think David was referring to Vector Processing Units. This 
>> is
>> AltiVec on PowerPC, MMX/SSE on Intel, 3DNow! on AMD, etc (?). So the
>> discussion goes a little bit in the wrong direction, but it's 
>> interesting
>> still ;-)
>>
>> > > I understand that consumer graphics cards generally have bad
>> > > performance when it comes to reading data back from the card (ie:
>> > > glReadPixels).  Has/will this changed with the latest hardware 
>> (Radeon
>> > > 9700 and NV30)?
>>
>> Not fundamentally, I think.
>>
>> > >  Could you give a general idea of the bandwidth
>> > > available?  The reason I ask is that I can imagine speeding up 
>> things
>> > > like genetic algorithms.  Ideally, the objective function could be
>> > > compiled to run on the graphics hardware, but realistically it 
>> would
>> > > probably often require the CPU (please tell me I'm wrong).  In 
>> this
>> > > case, bandwidth from the VPU to the CPU becomes important.
>>
>> As I said, VPU means the on-processor vector units. Generally the 
>> graphics
>> processor is referred to as "GPU". Only recently some companies 
>> (3Dlabs,
>> ATI) have begun to name their boards "Visual Processing Units", 
>> probably
>> to distinguish them from NVIDIA, and causing confusion with this.
>>
>> > I've had good luck with reading vertexs and matrices back from 
>> Geforce3
>> > and Quadro4 cards.  Never tried using glReadPixels.
>>
>> Graphics boards are optimized for getting data _to_ the screen, not 
>> back.
>> In fact, there are "pure" modes where your application promises the
>> graphics subsystem to never ever read back any state, which allows the
>> driver to much more aggressively optimize its internal processing.
>>
>> OTOH, newer drivers have considerably sped up read-back rate for 
>> recent
>> NVIDIA boards. It's just that hardware vendors put much more effort 
>> into
>> optimizing the common pathes first. If you really need fast read-back
>> capabilities you have to look in the professional market - one (if 
>> not the
>> only) selling point of SGI machines today is _bandwidth_.
>>
>> > It used to be that the trick of getting good graphics out of a 
>> Indigo2
>> > Impact was to push as much work onto the graphics subsystem, and
>> > surprisingly, cache some of the state of the graphics subsystem to
>> > minimize the number of glEnables and glDisables called.  I can't say
>> > that this is really the best thing to do these days.
>>
>> It still is.
>>
>> -- Bert
>
>
>
Dr. Stéphane DUCASSE (ducasse at iam.unibe.ch) 
http://www.iam.unibe.ch/~ducasse/
  "if you knew today was your last day on earth, what would you do
  different? ... especially if, by doing something different, today
  might not be your last day on earth" Calvin&Hobbes