PDA

View Full Version : question for those beta testing v9..



zogthedoomed
02-07-2006, 09:38 AM
I'm just curious .. will there be an AMD optimised version on the disc (seeing as I've heard that the Intel compiler they use does not naturally behave favourably towards non Intel chips .. so I'm told). The current Intel compiled version of 8 runs considerably slower on AMD than Intel. Obviously subjective to a degree but when a very hi specced AMD machine feels sluggish and renders F9 and Fprime renders substantially slower than a lesser specced Intel next to it theres something wrong and i'm not the only person to of noticed this.

Also is Ambient occlusion going to be built into the renderer in the same way as it appears to be in say XSI? The current implementation of having to have multiple object versions and scenes with different hand-changed textures is slow, accident prone and is pushing us away from using LW. It really should be accessed in the same way as a buffer export. A scene wide effect. Click a button and at render time it spits out an AO pass at the same time.

CHeers.

Lewis
02-07-2006, 10:03 AM
I think nobody who is really testing LW9 can't asnwer you to this (NDA) so maybe would be best to send this question to NewTek.

Earl
02-07-2006, 10:05 AM
LW 8.5 runs a lot faster on my Athlon than my Pentium 4. Both are about the same frequency. Not sure there is much merit to this claim.

NanoGator
02-07-2006, 10:26 AM
I think nobody who is really testing LW9 can't asnwer you to this (NDA) so maybe would be best to send this question to NewTek.

You're absolutely correct.

mattclary
02-07-2006, 10:29 AM
LW 8.5 runs a lot faster on my Athlon than my Pentium 4. Both are about the same frequency. Not sure there is much merit to this claim.

At the same frequency, AMD chips will always smoke an Intel chip, but AMD chips "should" be smoking Intel chips at a much lower frequency.

I would love an answer from Newtek as to which compiler they are using, as I have heard about this several places and am growing concerned that AMD chips may be running the code slower than they should.

Earl
02-07-2006, 10:38 AM
At the same frequency, AMD chips will always smoke an Intel chip, but AMD chips "should" be smoking Intel chips at a much lower frequency.
True. However I should have been more specific. My Athlon64 3000+ (2.0 GHz) runs about twice as fast as my Pentium 4 2.6 GHz. Of course, if NewTek found a way to compile it even better for an AMD chip, I would be more than happy. :D

I would expect a 3000+ rated Athlon64 to outperform a P4 2.6, but to be twice as fast...

zogthedoomed
02-07-2006, 11:49 AM
Well the two computers in question where not identical but as close as. A P4 2.8 with an FX 5600 and 1Gb DDR on a nasty Abit MB against a 3200 AMD 64 with 2Gb of good Corsair DDR, a 6600GT 256Mb on an Asus A8N MB.

I made the big assumption that while the clock speed of the AMD was lower, the extra RAM, better MB and more powerful graphics would more than make up the deficit. However it performs noticably worse than the Intel when it comes to F9 and Fprime rendering. I can't give you figures off the top of my head but its enough to get frustrated at the sluggishness.

You may not think theres any merit in this claim but .. well what can I say. An Intel compiler has no obligation to optimise for AMD. So why do Newtek (AFAIK) just compile for Intel? Maybe they don't anymore. I maybe totally wrong, after all thier blurb for LW 8 says they recomend Opterons. Rowsby for one would probably disagree with them. These links are from a dude on WOrleys group.

http://www.swallowtail.org/naughty-intel.html

http://www.theregister.co.uk/2005/07/12/amd_vs_intel_code/

http://devforums.amd.com/index.php?showtopic=34

http://www.betanews.com/article/Suit_Intel_Sabotaged_Compiler_for_AMD/1121274628

mattclary
02-07-2006, 11:53 AM
By all rights the AMD 64 should have mopped the floor with the 2.8 Intel machine. :stumped:

mattclary
02-07-2006, 01:04 PM
I created a new thread. Hopefully NewTek will take notice and answer us.


http://www.newtek.com/forums/showthread.php?t=45429

loki74
02-07-2006, 08:49 PM
Also is Ambient occlusion going to be built into the renderer in the same way as it appears to be in say XSI? The current implementation of having to have multiple object versions and scenes with different hand-changed textures is slow, accident prone and is pushing us away from using LW. It really should be accessed in the same way as a buffer export. A scene wide effect. Click a button and at render time it spits out an AO pass at the same time.


You're texturing objects special to get ambient occlusion?? First, correct me if im wrong doesnt ambient occlusion happen naturally if youre using radiosity? Also, there is a plugin, SG_AmbOcc that I use... totally kicks @ss, and it has a minimal effect on my rendertimes. It works as a shader, so you have to add it on a surface-by surface basis... that can be tedious, i know, but it also makes it much more flexible.

I must say though, you must be one VERY patient person to be doing ambient occlusion with textures!

And I agree it would be nice if there was a separate AO pass so that we could composite w/ more flexibility in post...

Verlon
02-08-2006, 12:44 AM
On the compiler thing....
It works something like this when compiled by an intel compiler (which is generally regarded as the fastest out there....)

A compiled program running executes a few steps like this
1) The program checks to see if CPU is SSE capable *(1,2,3,whatever)
2) The program checks to see if the CPU is a Genuine Intel CPU
3) If 1 AND 2 are true, enable SSE (1,2,3, whatever) optimizations. If 1 is true, but 2 is not (as well as all other cases, but this is the only one that matters), do NOT use SSE optimizations.

So the SSE stuff on the AMD CPUs doesn't get used. In areas where SSE is better, it hurts AMD performance. Sometimes it matters, but other times the Athlon's heavy duty FPU can make up the difference.

zogthedoomed
02-08-2006, 06:07 AM
Loki, we weren't using radiosity. We were using AO to fudge it for speed although AO proved to be the big bottleneck in the end. Yes we used SG_AmbOcc which was cool but inconsistant. Too many frames of flicker that had to be checked and then rerendered. While we could bake it into environments we couldn't with characters and I lost count of the hundreds and hundreds of frames that had to be rerendered because of flickering AO. We won't be using it again. Oh and when I said texturing objects I meant applying the shader, not painting a texture. That would be faintly rediculous!

Stooch
02-08-2006, 08:24 AM
You're absolutely correct.

i hope that was sarcasm because his statement was a double negative.

Stooch
02-08-2006, 08:27 AM
True. However I should have been more specific. My Athlon64 3000+ (2.0 GHz) runs about twice as fast as my Pentium 4 2.6 GHz. Of course, if NewTek found a way to compile it even better for an AMD chip, I would be more than happy. :D

I would expect a 3000+ rated Athlon64 to outperform a P4 2.6, but to be twice as fast...

something is wrong with your p4 then. shouldnt be THAT much faster. amd starts to spank intel on the very high end spectrum of cpus. however at that spectrum, xeons are a FAR better deal and deliver more bang for the $. I know because i just finished putting in an order for a boxx renderfarm and have been sweating benchmarks for a couple of weeks. great reversal of you ask me.

LMUSIC
02-08-2006, 09:16 AM
zogthedoomed - I have been using the IFW2 shaders for AO (replaced SG_AmbOcc) and am not getting any flickering frame to frame. Plus it works in LW64.

loki74
02-08-2006, 07:36 PM
Loki, we weren't using radiosity. We were using AO to fudge it for speed although AO proved to be the big bottleneck in the end. Yes we used SG_AmbOcc which was cool but inconsistant. Too many frames of flicker that had to be checked and then rerendered. While we could bake it into environments we couldn't with characters and I lost count of the hundreds and hundreds of frames that had to be rerendered because of flickering AO. We won't be using it again. Oh and when I said texturing objects I meant applying the shader, not painting a texture. That would be faintly rediculous!

ah! well that explains it--I've mainly been using SG_AmbOcc for stills! :D

yea i got the feeling u werent using radiosity; I guess what I meant to say is that if you really wanted AO, isnt radiosity an option? But I suppose the massive increase in rendering time would not be worth it...

And in any case your point still stands; native AO would kick @ss. But dont get me wrong, Im not complaining or anything. i mean, heck im still pretty psyched that were getting native sss. (it will be native right?)