Nvidia Release NV40 effects videos

[SsP45]

I find it interesting that in many of those movies they keep talking about how much better FP16 is compared to INT16, yet they never mention FP32.
________
Medical Marijuana Dispensary

 

[Razor04]

The demo only had the teapot rotating along that one axis at a fixed speed, and the blur still showed up even when the rotation was paused. When the demonstrator rotated the teapot on a vertical axis at the very end, there was of course no motion blur that fit that direction of rotation.

I noticed that too...very odd that when you pause something the blur is still there. Maybe they were trying to freeze it in time as in a snapshot so that it was a little easier to see the result of the effect...but if that isn't what they were aiming for then the blur should have turned off at that point in time. DemoCoder...I don't see how you could have missed the choppiness in the other vids...especially in the HDR video. That one seemed to be the worst FPS-wise out of all of them. I did appreciate that the vids actually showed useful things instead of a slutty fairy dancing around trying to attract gamers that need to get out more. Unfortunately I don't expect any of thes features to be very useable in the NV40.

 

[DemoCoder]

The HDR demo is extremely simple, with no background geometry, and just a statue model with a single HDR cube map texture plus a glow effect, so I find it nearly impossible to believe any choppiness is the result of GPU HW limitation, since this demo can be done on old INT16 hardware today without choppiness, the only difference being banding. Indeed, it could be run on a GF3 with DX8 shaders. This demo would run at 100+fps on old HW.

You're reading way too much into a vidcapture. The real demo may or may not be choppy, but I highly doubt it's because it's shader, texture, or geometry limited. A single cube map band limiting or texture limiting? A single geometry model? The glow affect? Come on. The only thing left would be to suggest that FP16 filtering is the problem, but I highly doubt it.

The only plausible explanation for me is bad drivers, or the vid-cap software causing the problem.

 

[991060]

The only plausible explanation for me is bad drivers, or the vid-cap software causing the problem.

Judging from other vids, I think they used a camera for capturing instead of a vid-cap software.

 

[DemoCoder]

The only plausible explanation for me is bad drivers, or the vid-cap software causing the problem.

Judging from other vids, I think they used a camera for capturing instead of a vid-cap software.

You can still get dropped frames. I get stutter motion all the time if I convert from a MiniDV video to low bitrate video (25mbs to 150kps). Quicktime trailers look good because the studios put a lot of effort into massaging the source and tuning the codec when they make it. If you produce your own video with WMV or Quicktime, it is way choppier even at equivalent bit rates if you simply "Save As" the compressed video without much thought.

 

[demalion]

I found the video of exceedingly poor quality (would have been a good time for something more like the HL 2 video bink encoding, but perhaps it is intentional at this point in time, with higher quality demonstration intended closer to launch)...I don't think you can take away anything definitively indicative of hardware from them.

This evaluation includes noticing a marked choppiness, noticing the "banding" illustration for the HDR more as a change in the blotchiness rather than actually seeing banding appear/disappear, and personally not being able to make out nuances in the motion blur video with confidence.

The multiple light, 3d paint, and displacement videos were the only ones that clearly illustrated unique hardware capabilities to me along with their commentary. The rest strike me as a really fuzzy preview of full functionality of a fleshed out PS 2.0 featureset (that's already clearly specified) and would require only improved performance of it to at least the level of R300 IPC judging by similar existing demos, as DC mentioned. I don't think failing to meet this is a likelihood, so encoding or transient issues (drivers, system, done on early hardware a while ago, etc) seem far more likely than a drastic lack of performance, especially as such low quality video could have been done at a low resolution or hidden in other ways if performance was a problem.

Maybe a look at some SDK 7.0 samples, if they have advanced shaders included, and analyzing some shader lengths might be more indicative of performance.

 

[Megadrive1988]

very interesting, but not incredibly impressive. the 2D paint stuff was interesting. the 3D stuff was pretty choppy.

I was much more impressed by ATI's realtime Animusic demo at R300's launch in 2002.

 

[991060]

OT: demalion, I found your post among the hardest-to-read ones in B3D.

 

[nelg]

Part of the paint demo reminded me of using Hsoft’s Sqizz in PhotoPaint and when done on images of screen resolution it is almost as fast.

 

[DemoCoder]

NVidia's videos were compressed with generic MPEG-4 @ 155kbps. The HDR video is 13mb, 1:30 length, 29fps, NTSC resolution. For comparison, MS's XNA butter-smooth demo video (with the car) is 1:30 long, came out to 30mb in size, similar resolution, but used 2.8Mbps WMV9 encoder. So Microsoft's equal length, similar resolution video contains 20 times the bitrate, but is only 2x the filesize.

Clearly NVidia fubar'ed up the video compression, since the datarate claimed in the AVI header doesn't match the size. (155kbps * 90 = 1.7mb. The audio rate is claimed in AVI file as 350kbps. Audio bitrate > video bitrate? WTF)

Something weird is going on.

Anyway, I doubt these demos are supposed to be compared to Animusic. These are individual feature demonstrations. Animusic was a GPU-wide demo, more like Dawn, Nvidia's dancing Gorilla, Toy Story, et all. NVidia probably has some new version of Dawn ready to go. We've had Dawn, we've had Dusk. What's next? Hangover?

 

[KimB]

I find it interesting that in many of those movies they keep talking about how much better FP16 is compared to INT16, yet they never mention FP32.

Because they're not talking about shader calculations, but rather texture filtering and framebuffer blending. FP16 precision in either of these cases is completely new, and very exciting.

 

[Heathen]

Well I watched the 3d paint vid and for all of the capabilities he was espousing I was thinking 'Well I certainly hope so'. Nice to see the extra speed but otherwise unimpressive.

The others were nice but nothing so far which makes me want to run out and buy an NV40.

 

[DemoCoder]

These demos were primarily written for the SDK and developers, not consumers.

Anyway, load up the teapot multilight example and watch the red light moving in an ellipse when only a single light is switched on. It's still choppy. You're telling me that the NV40 can't render smoothly a single friggin teapot with a single light? Puh-lease. And look at the horrible block compression artifacts.

 

[KimB]

Finally got all the demos downloaded.

Perhaps the most interesting thing that I found was in the HDR video. The person doing the demo was able to dynamically switch between 16-bit floating-point and 16-bit integer. This would make it appear that the NV40 also supports 16-bit integer blending and filtering.

As for the performance, guys, it's compression artifacts from the video. Get over it.

 

[Guden Oden]

This would make it appear that the NV40 also supports 16-bit integer blending and filtering.

Um, wee-eelll, the guy actually says as much on the audio-track, but whatever.

As for the performance, guys, it's compression artifacts from the video. Get over it.

Yeah, it's a bit silly seeing all these people harping on the framerate when they should KNOW a video capture doesn't represent the true framerate of the source material. Just read the page with the videos, it's all there. Even info on how the capture was done.

Of course it'll look choppy, the video runs at 29fps and the source video framerate is not synched to the capture rate. Naturally there will be dropped frames.

The multiple lights demo looks very impressive to me. That's a buttload of lights being shown! A multipassing multiple shader incarnation using PS2.0 might not actually be any faster considering how many passes would be required to draw just one frame, even when considering possible branch penalties etc on NV40.

I think this chip will rock, at least in 16-bit fp (I fully expect people to whine and bitch a lot if 32-bit performance is somewhat lacking, but it'll be pure knee-jerk responses of course.)

 

[flick556]

Is it me or does the HDR demo look strangely familiar to the Unreal engine 3 stuff, don't focus on the girl but the background it would appear to be full 3d and quite high quality . The blur or whatever it is seems intentional to not allow us to fully see it.

I only seen one unreal shot and it was pulled almost a week ago but it looks almost identical if you allow yourself to see past the blur. Also all the other vids after being uncompressed run smooth as silk but this one has a little trouble but still smooth, maybe the signs of a engine years away from release.

 

[Padman]

flick556, that's just a high dynamic range cubemap being used. You can see the same image being used in most HDR demos. Rhtribl (spelling?) uses this texture as well.

so, unfortunately, no secret super 3D engine in the background

 

[KimB]

Well I watched the 3d paint vid and for all of the capabilities he was espousing I was thinking 'Well I certainly hope so'. Nice to see the extra speed but otherwise unimpressive.

Were you thinking in terms of that program not being impressive for a photo editing program? Of course not: it was a tech demo. I found it impressive simply that they were able to do all of those effects on the graphics card. The high dynamic range blur stuff I thought was particularly neat.

 

[Guden Oden]

I liked the fact it did all rendering to a back buffer, so that the front buffer could be zoomed in and out etc, realtime effects added like the deformation stuff or the brightness changes etc; they didn't affect the original, but were instantly applied only to the front buffer. And, it was FAST! That was almost what impressed me most I think, it seemed to react to mouse movements as soon as they happened. That's awesome.

That's how a paint program should be, there's no lag when using pens or brushes in the real world, so there shouldn't be in a computer either.

For a tech demo this paint program was really advanced, though it would need a better UI etc if it was to be a real product.

 

[Lezmaka]

NVidia's videos were compressed with generic MPEG-4 @ 155kbps. The HDR video is 13mb, 1:30 length, 29fps, NTSC resolution. For comparison, MS's XNA butter-smooth demo video (with the car) is 1:30 long, came out to 30mb in size, similar resolution, but used 2.8Mbps WMV9 encoder. So Microsoft's equal length, similar resolution video contains 20 times the bitrate, but is only 2x the filesize.

Clearly NVidia fubar'ed up the video compression, since the datarate claimed in the AVI header doesn't match the size. (155kbps * 90 = 1.7mb. The audio rate is claimed in AVI file as 350kbps. Audio bitrate > video bitrate? WTF)

Something weird is going on.

I opened up the HDR video in virtualdub and it said the video data rate was 916kbps and the audio was 353kbps.

The video was also running at 29.970 fps. If the demo's were running slower than that, say, 20-25 fps, wouldn't that cause the multiple identical frames like I see when I go frame-by-frame? If you're capturing ~30 fps and the frame being rendered hasn't changed, wouldn't you get two identical frames in a row and that would cause some chopiness.