What's the current status of "real-time Pixar graphics&
- Thread starter Daliden
- Start date
Sure, API's are great. But why only optimize for the 'bad' videocards?
It seems a bit unfair, that the developers go down to-the-metal for some videocards to get them to preform a bit, while they don't for others that could really amaze us and do it sooo much better...
I know that they want to sell that game to the owners of the 'bad' chips as well, but it's not fair to the owners of the 'good' ones. And I understand that some companies have enough money to make sure the 'bad' ones look just as good as the 'good' ones, but the other companies have money, too!
But the owners of the 'bad' ones are a force to be reckoned with. We probably don't want them angry.
As the developers make different paths in their code to make it preform reasonably well on older hardware, why not make one to really let it shine on new hardware as well?
Anyway, what's the difference? We want to see what can be done, right?
It seems a bit unfair, that the developers go down to-the-metal for some videocards to get them to preform a bit, while they don't for others that could really amaze us and do it sooo much better...
I know that they want to sell that game to the owners of the 'bad' chips as well, but it's not fair to the owners of the 'good' ones. And I understand that some companies have enough money to make sure the 'bad' ones look just as good as the 'good' ones, but the other companies have money, too!
But the owners of the 'bad' ones are a force to be reckoned with. We probably don't want them angry.
As the developers make different paths in their code to make it preform reasonably well on older hardware, why not make one to really let it shine on new hardware as well?
Anyway, what's the difference? We want to see what can be done, right?
Are you talking specifically about the R3xx vs. NV3x architecture?DiGuru said:
If so, I think you're rather off-base.
The R3xx architecture is very...forgiving on what the assembly is. Optimizing pixel shaders for the R3xx doesn't yield a huge performance increase.
However, the NV3x is very challenging to program for. It has a lot of quirks and not-so-obvious performance penalties. This alone doesn't necessarily mean it's bad, it just means that it is extremely hard to program for at a low level.
It shouldn't be any mystery, then, why nVidia produced Cg. They knew that OpenGL's HLSL (GLSlang, I think it's been called?) wouldn't be ready at the launch of the NV30, and they didn't think, earlier on, that Microsoft's HLSL would be ready yet either (the NV30 was delayed). But nVidia needed to make it relatively easy to program for the NV30, and still get decent performance.
I say that developers should code solely in one of the various available HLSL's (no tweaking of the assembly), and leave it up to the IHV's to fix any performance issues by either producing better compilers, or, say, urging Microsoft to do so (as is apparently happening). The only thing that developers should need to do to optimize for the NV3x architecture is to select lower precision rendering when it is possible to do so without a noticeable change in the output color. There are many other quirks of the NV3x architecture that developers shouldn't need to pay any attention to.
OpenGL guy
Veteran
As are your comments below.Chalnoth said:
How would you know? Did it occur to you that the it appears forgiving because there is a driver between the application and the hardware? I will agree that the R300's shaders are a lot more flexible than the NV3x's.
All of this should be resolved by the driver with the exception of partial precision as you mention below.
Yet Cg appears to produce results no better than HLSL.
I suspect that a lot of that may be due to an effective assembler/compiler-optimiser buried in the driver but there's a (practical) limit to how much re-arrangement can be done. Recoding the original source may still make a big difference.Chalnoth said:
Of course. It's simply easier to optimize for the R300's architecture. This is why developers shouldn't program in assembly: they would need to write completely different shaders for the two architectures, and will either take too long to write optimized assembly, or won't be able to discover where the performance problems are occuring.OpenGL guy said:
Which has no bearing on what my statement was. Cg was released prior to HLSL. Also, I'm not so sure that HLSL allows for the possibility of a 'write once, run anywhere' shader. Cg is designed for that sort of thing.
Simon F said:
Porting a big asm project would be considered 'fun' by a few people I know. There are some absolute ASM geniuses out there, who are actually more productive in ASM than most people are in high languges.
Some slightly odd things I've heard about
1) Designing an ARM like machine architecture, writting assembler, emulator and tools for it and then writing the entire games AI system in it. And no they weren't porting, they simply decided the best language to write a modern AI system in was ARM-like asm...
2) Writing a major portion of a large game on/in a complete different architectures asm language, then writing an emulator on the actual platform. Again not for porting reasons.
3) Similar to 2, I know of 1 company that hated the PC so much, the developed a game on a console and then 1 month before they had to ship on PC they ported it. Nothing too weird except they never had a contract (nor AFAIK an intention) to release the console version.
4) Writing game logic on a sound CPU because they liked that processors ASM (this is a bit older going back to megadrive/genesis)
5) Writing a particle system on the disk drive CPU (thats really old, C64 and that was good reason, A whole extra 2 Mhz being wasted
).Even I have to admit being involved in slightly dubious practise once (just the once you understand
). We had the choice of writing the game logic and AI on a PC or PS1 (we had to do both versions), given the PS1 was the more limited we wrote it on PS1. We used the GTE on the PS1 (the fixed point coprossor), then wrote a GTE emulator on PC. In our defense we did it mostly in C on the PS1 (via intrinsics), though there was a few bits of R3000 asm...Dio said:
Talking of that...
www.chrissawyer.com
I'd say the most impressive part, though, is that the game is absolutely amazing gameplay-wise and got very acceptable graphics/sounds IMO, considering what Chris' goals must have been.
And for a 99% assembly code game, it didn't sell that bad, either...
Chris Sawyer always does everything nearly 100% by himself, only using a few other guys for images and sounds. I wonder how much money he did with all this... Oh wait, no matter, I can't count that far!
Uttar
Chalnoth said:
I wouldnt mind seeing this extended to all programming, only problem is that programmers dislike to expose their source-code ... I personally like virtual ISAs as a halfway compromise. Typed SSA virtual assembly languages can be pretty much just as usefull as the original code for the compiler (it is a real shame politics is preventing LLVM from becoming the next gen GCC by the way).
This could finally get us off the threadmill of legacy support, at least as far as the ISA is concerned, and make competition in the processor business much more interesting.
VFX_Veteran
Regular
Since when has this thread started talking about assembly language? It's getting rapidly off-topic.
-M
-M
Mr. Blue said:
Nah, it's really fully on topic. You guys use assembly language for your films, right? Right?
Okay, so trying to get back on topic...
We know FP64 would be sufficent for everything the film industry does, and FP32 for 99.5% of it. But...
How good would FP24 and FP48 be? What I mean there is FP24 in 1 clock or FP48 in 2 or more clocks. Could that be sufficent for the film industry?
Not that I'm aware of any GPU being a FP24/FP48 combo. But just thought it'd be an interesting thing, probably very balanced for the game industry too ( FP24 for 95% of cases, and FP48 in 3-4 cycles in 5% of cases would take a lot less transistors than FP32 from top to bottom, and result in higher performance and IQ for a similar transistor count - if thd developer's know what he's doing... )
So?
Uttar
Happens in all non branching forums, it is just a poor design for discussion (of course HTML forces us into it).
The main programmer for the PDI renderer used for Antz/Shrek has a site BTW (and works for NVIDIA now). It doesnt tell much about the rendering engine, but he has posted some tidbits on usenet on occasion.
He used a tiled A-buffer renderer with deferred shading ... the shading parameters in the A-buffer could also be used for subsequent raytracing I believe.
The main programmer for the PDI renderer used for Antz/Shrek has a site BTW (and works for NVIDIA now). It doesnt tell much about the rendering engine, but he has posted some tidbits on usenet on occasion.
He used a tiled A-buffer renderer with deferred shading ... the shading parameters in the A-buffer could also be used for subsequent raytracing I believe.
Quote from the site:
This quote is the answer to the original question. Since the average frame time of both offline (30 minutes) and real-time rendering (1/60 sec) is constant, there is not going to happen any converge any time soon.
Actually, this is not a new observation. It was observed years ago by Jim Blinn.
If we fix the target to Toy Story quality (the real thing, not cheap imitations) then it’s just a matter of time.
If the hardware companies abandon the brute force algorithms and adopt more elegant ones then it will happen sooner (probably in the next ten years).
If they continue patching the SGI’s pipeline, designed for gouraud shaded scenes with a few hundreds of polygons, then it will happen later.
But unless hardware starts to support more robust algorithms, I don’t see how we can abandon our software renderers.
This quote is the answer to the original question. Since the average frame time of both offline (30 minutes) and real-time rendering (1/60 sec) is constant, there is not going to happen any converge any time soon.
Actually, this is not a new observation. It was observed years ago by Jim Blinn.
If we fix the target to Toy Story quality (the real thing, not cheap imitations) then it’s just a matter of time.
If the hardware companies abandon the brute force algorithms and adopt more elegant ones then it will happen sooner (probably in the next ten years).
If they continue patching the SGI’s pipeline, designed for gouraud shaded scenes with a few hundreds of polygons, then it will happen later.
But unless hardware starts to support more robust algorithms, I don’t see how we can abandon our software renderers.
I take "convergence" to mean something entirely different.Pavlos said:
For one thing, there are just too many advancements to be made to make computer graphics truly believable. The additional money (and computing power) thrown at film products will, for the forseeable future, allow for better visuals.
But convergence, to me, means something different. It means something closer to the "real time" Final Fantasy vs. the movie we saw some time ago. Computer games will never be able to render at the same resolution, with as complex shaders, with the same anti-aliasing, etc. But, there is now a convergence that is happening in the way graphics for games are designed, compared to how they're designed for movies. That convergence is not complete, but it is happening. The next step is a convergence in hardware. Soon, the hardware used for high-end rendering will be very similar to that used in game machines. Movie makers will still use renderfarms, and they will still take much longer to render a single frame, but the advantages of using the same technology to power products both in the consumer space and in high-end rendering are too much to ignore.
I think that very soon, renderfarms for making movies will use chips from ATI and/or nVidia for most of the processing.
To my somewhat untrained eyes, LLVM would be a bear to implement either in silicon or in an emulated virtual machine.MfA said:
The idea that a low level instruction for malloc/free (and/or garbage collection) is a good idea is boggling to me.
