[PD] Gem for a dual G5

[chris clepper]

The right inlet of the cube object scales the X,Y and Z proportionally. 
  It sounds like the cube isn't the bottleneck and doing this won't 
affect CPU load at all.  The cuboid Geo allows scaling of X Y Z 
separately so that might be an option.

I am at a loss as to why your 5200 is performing the way it does.  Can 
you post a patch for others to test with different GPUs on OSX.  Maybe 
there is a bug somewhere in the drivers?

cgc

On Oct 16, 2004, at 8:32 AM, Amos Elmaliah wrote:

> Hi,
> Chris, I think i found one cause for cpu drops.
> while rgba texturing of cubes (many), having lighting enabled, I 
> noticed that changing scaleXYZ ratios so the cubes are not cubes is 
> very demanding for the GPU,(geforce 5200) and my frame rate drops from 
> ~200 to ~10. is there a way to do this without the high cost ?
> Is there a difference in implementation between re-scaling a  geo [ 
> cube ] or changing the size of a geo doing something like
>
> 	[scale]
> 	|
> 	[cube ]
> ?
> thanks, amos.
>
>
> On Oct 6, 2004, at 7:07 PM, chris clepper wrote:
>
>> On Oct 6, 2004, at 7:37 AM, Amos Elmaliah wrote:
>>
>>> hi Chris, list;
>>>
>>> I am trying to figure out ways to improve gem setup on my machine.
>>> It seems like the bottle neck is the graphic card (the Geforce fx 
>>> 5200) as the frame rate drops when I texture many goes but cpu's 
>>> staying stable.  Is there a way to have cpu/ddr share these things 
>>> in gem? Should I just try to upgrade to a better ATI card or are 
>>> there any other options?
>>
>> Without more specific info on what you are trying to do it is a 
>> little difficult to make a suggestion.  In general, the 5200 is not a 
>> very fast GPU these days and I have run tests where the G5 ran 
>> Altivec code several times faster than the 5200's shader unit could 
>> process the same work.  Most of my testing for the G5 was on a dual 
>> 2.0 with a 9600 and I never saw the GPU affect performance 
>> dramatically even when texturing hundreds of geos with 1920x1080 
>> textures.  If you can afford the 9800 then go ahead and get it - 
>> there will probably be some work on GEM to take advantage of more 
>> advanced GPU features.  At the very least you can crank up the frame 
>> rate, FSAA, and texture size without problem with the current 
>> version.
>>
>>> Just out of curiosity, what the specific difficulties of coding pd 
>>> and gem for 64 bit machines?
>>
>> 64 bits hasn't even factored into GEM coding at this point - we don't 
>> use 64 bit ints and only two objects might possibly require more than 
>> 4GB of RAM and even that's a stretch.  My work has mainly focused on 
>> making GEM fast on G4s, and fortunately that same code runs well on a 
>> G5 with only minor modifications.  GEM basically has a HD capable 
>> real-time system by accident, which was a pretty pleasant surprise 
>> for me.
>>
>> cgc
>>
>>> Thanks
>>>
>>> _______________________________________________
>>> PD-list at iem.at mailing list
>>> UNSUBSCRIBE and account-management -> 
>>> http://iem.at/cgi-bin/mailman/listinfo/pd-list
>>
>>
> ---------------------------------------
> http://www.koncon.nl/~aelmalia/
> ------------------------------- -------
> http://www.tangiercluj.tk
> ------------------------------- -------
>
>
> _______________________________________________
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://iem.at/cgi-bin/mailman/listinfo/pd-list
>
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> MailScanner thanks transtec Computers for their support.
>