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@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
http://www.koncon.nl/~aelmalia/
PD-list@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.