David Kirk on HDR+AA

Status
Not open for further replies.
geo said:
trinibwoy said:
Still sticking up for the 128-bit crowd pretty well - even with AA

http://www.xbitlabs.com/articles/video/display/2004-27gpu2_8.html

And what Bob said too.... :oops:

And what was the primary improvement of the rushed-forward 5900 over the cancelled-as-quickly-as-possible 5800? I can't believe we're even talking about this like it isn't a settled issue.
you should know that when it comes to NV3x, nothing is EVER settled. it's just going to be rehashed until the end of time!

(and I might say that the move away from FX12 ALUs is more important than the 256-bit bus, but I'd be an idiot, wouldn't I? :p )
 
geo said:
Well, sure, and his touching defense that R520 is really worse than NV30 as a company failure warmed the cockles of my heart (well, something got warm anyway).

I really don't see him saying that at all in his replies to the initial set of questions. What part of his responses are you getting that from?
 
And what was the primary improvement of the rushed-forward 5900 over the cancelled-as-quickly-as-possible 5800?
More floating-point units? DDR RAM instead of DDR-2? Improved color compression? Depth bounds test?

Really, there are plenty of things wrong with NV30. The 128-bit memory bus just wasn't one of them(*). NV43 is only marginally bigger (probably smaller if you remove SM3.0 support) and performs a lot better.


(*) Of course, a 256-bit bus did help, mostly due to the memory inefficiencies elsewhere in the pipeline. But a 256-bit bus isn't all that made NV35 run significantly faster.
 
A is important for speed, B does nothing for speed, C is kinda meh, D is definitely meh.

Also, christ, I was an asshole for even making a joke about NV3x, but now people are seriously debating how NV3x wasn't that bad or something like that? GAAAAAAH.
 
B does nothing for speed,
Assuming you're talking about DDR vs DDR-2, DDR has a much lower latency than DDR-2. This means that the latency absorbing FIFOs become much more effective (or: you can run more threads without stalling for memory). This can significantly improve your speed.
 
geo said:
And what was the primary improvement of the rushed-forward 5900 over the cancelled-as-quickly-as-possible 5800? I can't believe we're even talking about this like it isn't a settled issue.

The 6600GT/9800P comparison was to show that a wider bus is not critical to performance superiority. If you compare the same architecture with different bus widths, of course the wider one will be faster.
 
Bob said:
B does nothing for speed,
Assuming you're talking about DDR vs DDR-2, DDR has a much lower latency than DDR-2. This means that the latency absorbing FIFOs become much more effective (or: you can run more threads without stalling for memory). This can significantly improve your speed.
It was also clocked 75Mhz lower than NV30. I don't think the latency would make up for that if NV35 had an identical memory bus.

Okay, FUCK. Why am I arguing about NV3x again? It was in 2002! I'm leaving this thread forever.
 
It was also clocked 75Mhz lower than NV30. I don't think the latency would make up for that if NV35 had an identical memory bus.
The CAS latency for DDR-2 was ~2x (in clocks) that of DDR. To make up for the latency alone, you'd need NV30 have its memory run at 850 MHz instead of 500 MHz.

Recent DDR-2 memories have had their latency cut dramatically such that they're only ~40% higher than DDR (at the same clock), and about on par when measured in seconds.
 
The Baron said:
Why am I arguing about NV3x again? It was in 2002! I'm leaving this thread forever.

Well, I'm not leaving it forever, but I am declaring a moratorium on talking about you-know-what for awhile. :p I blame bit-tech for rolling out a piece of bait that the loyalist Kirk couldn't just walk away from as quickly as possible.
 
geo said:
What I got out of that is that [from his pov], at least FX set the stage for future success, while ATI (even with R520) hasn't completed the transition that NV has, and thus doesn't have that "investment" excuse. On fab process, once again, it isn't investment and it isn't all process [which he implies is the sum of FX's issues], therefore the balance is ATI incompetence. So, overall message --"Yes, ATI screwed up R520, but people really misunderstand when they think we screwed up NV30".

I didn't really get that. I read it as something like "FX was shit and made us work harder. Without that kick in the ass, NV40 could have been like R420 is: just an evolution part. You might not have got SM3.0 or something!".

With "I don't think ATI can attribute all their recent problems to process, although I'm sure they'd like to." All I can do is nod my head. I don't think his 'investment' statement earlier applies again, and process isn't the entire reason R520 is late. He speaks the truth there, as long as you don't assume his answer requires you to apply what he's said previously, or read it as an implication that the opposite applies to NVIDIA's products. Is he really commenting on his own company with the answer? I don't think he is.

Overall message: NV30 was crap, it made us make NV40 a real step forward, which ATI is yet to make with R520 yet. ATI are having issues with the process, but that's not all.

Ho hum :p
 
I thought the main benefit of NV35 was reduced register pressure.

Edit: Cripes, that was meant to follow Bob's first post on this page. Must have had this window open for a while. I'll just follow the crowd and say forget I ever said anything about NV30 ever. Onward and upward!
 
The key word was "underestimate", Rys. But I'm not talking about this anymore. Really.
 
geo said:
The key word was "underestimate", Rys. But I'm not talking about this anymore. Really.

I blame his usage of the word on bit-tech's completely shite question :LOL: I'm done too now :D
 
Zengar said:
Kirk is right

If you want HDR with AA, then just render a bigger buffer and downsample it to the screens resolution - sould work fine. Or you can apply some edge smoothing filters to the scene. The problem is - as he said - that there are no displayable floating-point buffers in curent hardware. That means, one must tonemap it manually and write the output to the visible screen. That's why the hardware antialiasing on the floating-pint buffer doesn't make much sence(commonly spoken).
It still makes much more sense to use sparse grid multisampling on a float buffer, downsample it and do tonemapping to output it to a displayable buffer than using ordered grid supersampling instead.
Displayable FP buffers or not, antialiasing is necessary. And if you can do it with a smaller performance hit, why not?


JF_Aidan_Pryde said:
Xmas said:
"But with HDR, you render individual components from a scene and then composite them into a final buffer. It's more like the way films work, where objects on the screen are rendered separately and then composited together. Because they're rendered separately, it's hard to apply FSAA (note the full-screen prefix, not composited-image AA! -Ed) So traditional AA doesn't make sense here."
Sometimes I get this feeling that Mr Kirk completely switched to the PR department. That, or he really doesn't know what he's talking about.

Would you care to give a more accurate explaination? :)
Generally, HDR. Or in short, HDR rendering is rendering with a high dynamic range and performing tone mapping to get a displayable image. I don't know why he's talking about compositing, rendering objects separately, etc. That isn't related to HDR at all.
 
_xxx_ said:
Jawed said:
Well, one thing's for sure, Digi and WaltC are both gonna have fun today.

Which means that we're gonna have fun reading that, so that's nice :)

Although I'll be @ Napalm Death concert today, so I guess I'll have even more fun... :D

Napalm Death, that is a name I havent heard in years. ;)
 
trinibwoy said:
Did anyone else find Kirk's comments very ominous with respect to us seeing HDR+AA on Nvidia hardware anytime soon. The obstacles he described aren't going away anytime soon. He'll look pretty silly if ATi manages to give us usable HDR+AA soon though.

What I got out of his remarks was their arch isnt suited to perform this function and looking forward it doesnt make sense to make it suited since developers should be taking care of this within their engine.

Or did I miss something?
 
Yeahh sounded like he meant that by the time all titles use HDR the AA will be gone from the hardware and done inengine/shaders instead.
That surely must be a while no?

I dont see it as a big problem yet but many that want top notch will i guess.

Why cant you just take the finalrender and then apply AA?
 
overclocked said:
Why cant you just take the finalrender and then apply AA?

You mean render at a higher resolution and downsample right? I don't think you can do AA after the image is rendered to the backbuffer.

I also don't understand Kirk's comments about rendering the image in bits and stiching it back together. I thought HDR on NV40 was done by rendering to a single FP16 back-buffer. Why is it necessary to use render targets (just) for HDR?
 
Status
Not open for further replies.
Back
Top