Tony Tamasi Interview
- Thread starter Ardrid
- Start date
Sorry, just being silly...I should have used a winky.PaulS said:I'm fine, no need for the rolling eyes
I found it a uniquely informative interview for an nVidia representative (given the past year or so), partly because of BS filters for certain key "PS 3.0" related marketspeak, and partly because of the willingness of the interviewee to tackle some important pointed questions posed by TR that clarified some things. Marked improvement.
Tamasi said:
Just plain wrong.
If the frame buffer has sufficient precision and conversion process can implement the gamma curve on a per component basis, no additional shader pass is required at all.
This is so fundamentally wrong you really have to question whether Tamasi knows anything at all about graphics and displays or whether he is just a marketing parrot.
Hey Tony? Want a cracker?
OpenGL guy
Veteran
Given that the GeForce HW has built-in MSAA downsampling in the RAMDAC, you'd have to do the gamma correction before then if the hardwired circuitry didn't do it for you. When combining the results of the subsamples, you want to degamma them first, do the averaging, then regamma them. How else could this be done without a shader pass, assuming it's possible at all? How is your idea of "and conversion process can implement the gamma curve on a per component basis" (I assume you meant "any" not "and") any different? A shader pass just means that you need to touch every pixel.Scarlet said:
Off topic to the FSAA discussion going on, but still relevent to the thread imo... Having the 6800 family all out by July 4th implies to me the 6800 Ultra and 6800 first (May-June) followed by the PCIe version later (June-July). Because he said 6800 family and not NV4x family this implies to me that the entire family NV4x family will not be out by then... only the higher end cards. Anything slower than the 6800 NU will probably be named 6200 or 6700 like last generation and be released in the fall.
Well in fairness, you do seem a bit prejudiced against foolishness.Althornin said:lol, YOU are calling me a bigot.radar1200gs said:
I read this as being in the context of SM2.0 vs. 3.0, not (just) FP24 vs. FP32. Tony was saying that 3.0 "looks better" due to its higher full-precision format (a debatable point, given that no games show FP32 looking better than FP24) and "runs faster" due to 3.0's various efficiencies (again, I'll believe it when I see it, but it definitely seems possible). I don't think he was being tricky in that answer at all, in the context of his full reply.
The gamma correction/adjustment issue was brought up by H@ at Ars a while ago, but, again, pictures speak louder than words, and I don't think we've seen GC/GA from NV40 yet.
Very misleading. Is there a single visual effect SM3 gives that cannot be achieved in SM2? Anyone? Later on in the article you can actually figure out this is the case when he starts talkng about writing shader code in HLSL, but if you aren't awake, you might be mislead by his first claim. He then tries to recover with some hand-waving (of a "quick example" of "possible effects") about "sophisticated shadowing and lighting" and "hundreds of instructions" and "true branching" (as opposed to "false" branching?).Tamasi said:
I do agree with the assertion branching makes things easier for developers to code, but I don't see that as a benefit to me if it hits performance. The "be careful" when you use branching admonition really means that developers are still going to have to do all the things Tamasi claims SM3 obviates. Why? Because if they don't, SM3 performance will be a pig.
This is clever FUD no matter how you look at it. The issue isn't whether or not you have a standard but rather whether or not you consistently handle precision in a way that is logically coherent and reasonably representative of infinite precision within a limited number of bits. Anyone who has ever designed floating point ALUs knows there is more than one way to design them, and generally speaking they are all good. What we have as an IEEE standard is what was convenient for Intel to do way back when.Tamasi said:
I won't belabor how Tamasi used one arguement just one month ago for FP16 and uses a completely different arguement today (it seems like several others have already done that). Folks should take that into account every time Tamasi opens his mouth.
P.S. With respect to the virtues of SM3 vs. SM2, I'd prefer you just label me as a skeptic. I am skeptical of SM3 benefits versus the costs of getting it. But that's OK. I don't think XP is better than 98SE either (wishes I'd never formatted my disks for NTFS).
In the context of what nV HW will do,I don't doubt his accuracy. However it is the way Tamasi states it as an absolute implying there is no other solution, that I take issue with. If he had said, "On nV hardware, blah-blah-blah" I would have had no objection.DemoCoder said:
What I have noticed over time is that TT makes these inaccurate and incomplete statements which have the cumulative effect of being very misleading. You watch - if nV implements another shader pass to do gamma correction because of the way nV hardware operates, they will market it as a feature. Invariably a crowd of technoneophytes will demand additional shader passes on everyone else's HW to implement the same result regardless of whether or not the problem was solved differently.
There is so much history of this behavior that I am hyper-sensitive to it, and no longer believe it is incidental and accidental.
Scarlet, your 3 ports it looks like you are trying to pick a fight with TT at any point, even if it means quoting thins out of context.
I thought we've been over this plenty of times. His claim Is perfectly accurate. Are there things that you can do in SM 3.0 that you could not in SM 2.0? Yes, Vertex texture fetch would one of them. If you bothered to quote the preceding sentence, it would have been obvious to anyone that he was talking about the VS 3.0 features in this whole paragraph. If anything is "very misealding" here, that would be quoting this out of context and then adding qualifiers such as "visual effect" that had nothing to do with the original proposition.
Scarlet said:
I thought we've been over this plenty of times. His claim Is perfectly accurate. Are there things that you can do in SM 3.0 that you could not in SM 2.0? Yes, Vertex texture fetch would one of them. If you bothered to quote the preceding sentence, it would have been obvious to anyone that he was talking about the VS 3.0 features in this whole paragraph. If anything is "very misealding" here, that would be quoting this out of context and then adding qualifiers such as "visual effect" that had nothing to do with the original proposition.
Geeforcer, your response is a perfect illustration of my main point, that his verbal sleight-of-hand is quite good.
Read the entire interview and get an "impression" of what he is saying, then go dissect what he actually said. The two don't add up, and for that skill, TT is admirable. TT if anything would love everyone to believe SM3 allows for visual effects and performance that are unattainable on a clock-per-clock basis with anything that precedes it, no? His entire interview is meant to create and bolster that impression, no?
He does it by citing just the pieces of the story he wants you to have and is a clever apologist for the pieces he doesn't want you to have.
If there is a beef with my being so skeptical about what TT says, then perhaps TT should not have been such a prominent part of the "lies, damn lies, and benchmarks" regime at nV.
P.S. And yeah, XP does suxor compared to 98SE. I spent the last two days trying to break XP out of an install loop when it decided it didn't like something. I finally had to wipe the partition and all the data stored therein. 98SE never did that to me.
Read the entire interview and get an "impression" of what he is saying, then go dissect what he actually said. The two don't add up, and for that skill, TT is admirable. TT if anything would love everyone to believe SM3 allows for visual effects and performance that are unattainable on a clock-per-clock basis with anything that precedes it, no? His entire interview is meant to create and bolster that impression, no?
He does it by citing just the pieces of the story he wants you to have and is a clever apologist for the pieces he doesn't want you to have.
If there is a beef with my being so skeptical about what TT says, then perhaps TT should not have been such a prominent part of the "lies, damn lies, and benchmarks" regime at nV.
P.S. And yeah, XP does suxor compared to 98SE. I spent the last two days trying to break XP out of an install loop when it decided it didn't like something. I finally had to wipe the partition and all the data stored therein. 98SE never did that to me.
what about the physics stuff?
I was wondering if it is REQUIRED to have PS 3 to do 'physics' type of things, like the particle systems example?
1) Is that feasible to be done fast enough with what the PS are already required to do?
2) would there be some fallback for PS 2? or would the game run without those 'physics' entirely? what about other physics (like gravity)?
I was wondering if it is REQUIRED to have PS 3 to do 'physics' type of things, like the particle systems example?
1) Is that feasible to be done fast enough with what the PS are already required to do?
2) would there be some fallback for PS 2? or would the game run without those 'physics' entirely? what about other physics (like gravity)?
I love the whole partial precision bit in the talk. Doesn't he understand that for ATI there is no such thing as "partial precision." R3xx cards run everything at FP24 because it's a single precision architecture. You hand it a shader (with or without a PP hint) and it runs it at FP24. I don't think he understands what single-precision means.
Similar threads
- Locked
