-
We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
HUGE 3dfx interview w/Gary Tarolli
Page 10 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.
AlabamaMan
Junior Member
but them, let's not leave out:
"going"
"will"
and "being"
neither of which has any "probablys" or "bettings" before them.
i don?t usually flame people. go back, re-read some of your more colorful posts and them tell me that you did nothing to deserve it.
"going"
"will"
and "being"
neither of which has any "probablys" or "bettings" before them.
i don?t usually flame people. go back, re-read some of your more colorful posts and them tell me that you did nothing to deserve it.
AlabamaMan
Junior Member
which demos in particular are unrealistic and why?
BenSkywalker
Diamond Member
Dave-
"High resolution provides more detail, while anti-aliasing provides more accuracy. I'm not sure where you got the idea that either reduces accuracy and that RGSS does it more than OGSS. This is simply not the case. There is no way to lose accuracy when dealing with 4x the original data. (unless you do something screwy)"
Sampling proximity(same thing that gives RGSS an edge in eliminating aliasing artifacts creates more noticeable FSAA artifacts ie, haloing and blurring). Perhaps I should have used detail instead of accuracy, it may be better expressed that way.
"Actually, on B3D there wasn't ever really a conclusion on this"
Near the end of the thread it seemed to be agreed upon that on a mathematical basis at least, higher res could be proven to be superior(though I don't recall who was still left in the discussion, it had dwindled by that point).
"In CAD apps, it blows things away. If you note benchmarks, you'll note that there is like a 10x performance increase with GF boards over software T&L. But also take note that the 10x performance increase is not present in games."
They are still CPU limited. Using MDK2 or TD6 as examples(covers both major APIs) while my FPS are quite a bit better with hardware T&L, I am completely CPU bound by game code. I have tested extensively and the edge that my GF1 provides increases on a percentage basis when I overclock the CPU, though they don't budge when I OC or UC the core. Both games, particularly TD6, are composed nearly entirely of static vertices, so that of course does have an impact. With TD6, I'm seeing nearly a 400% increase using hardware T&L over software, and I have an Athlon550. Upping it to 600MHZ using FSB(I don't have a GF) it increases to over 400%. The GF T&L unit is still scaling.
For MDK2, if you run hardware mode on a GF compared to a V5 at low res(just to leave it strictly T&L and eliminate fillrate), the GF/GF2 is quite a bit faster then the V5, in the order of ~250% using Rev's numbers with older drivers. That's a ~850MHZ CPU, although the comparison unfortunately relies on the OpenGL drivers of each board, both of which have improved significantly in the past four months since those numbers were run.
ICyourNipple-
"honestly, with no bias whatsoever, what CPU is a GeForce 2 T&L engine equivalent to in a real game situation assuming the game is heavily optimized for the T&L engine?"
By my benching I would say at least a 2.4GHZ Athlon for games looking at the GF1, though with that high of geometry complexity you may well be fill limited before you are able to have the T&L unit stretch its' legs. DMZG is an example of this, with the amount of overdraw raw fillrate limits you before the T&L unit will become a bottleneck. Unfortunately we don't have enough games to get a better idea of exactly what level of performance is possible.
"High resolution provides more detail, while anti-aliasing provides more accuracy. I'm not sure where you got the idea that either reduces accuracy and that RGSS does it more than OGSS. This is simply not the case. There is no way to lose accuracy when dealing with 4x the original data. (unless you do something screwy)"
Sampling proximity(same thing that gives RGSS an edge in eliminating aliasing artifacts creates more noticeable FSAA artifacts ie, haloing and blurring). Perhaps I should have used detail instead of accuracy, it may be better expressed that way.
"Actually, on B3D there wasn't ever really a conclusion on this"
Near the end of the thread it seemed to be agreed upon that on a mathematical basis at least, higher res could be proven to be superior(though I don't recall who was still left in the discussion, it had dwindled by that point).
"In CAD apps, it blows things away. If you note benchmarks, you'll note that there is like a 10x performance increase with GF boards over software T&L. But also take note that the 10x performance increase is not present in games."
They are still CPU limited. Using MDK2 or TD6 as examples(covers both major APIs) while my FPS are quite a bit better with hardware T&L, I am completely CPU bound by game code. I have tested extensively and the edge that my GF1 provides increases on a percentage basis when I overclock the CPU, though they don't budge when I OC or UC the core. Both games, particularly TD6, are composed nearly entirely of static vertices, so that of course does have an impact. With TD6, I'm seeing nearly a 400% increase using hardware T&L over software, and I have an Athlon550. Upping it to 600MHZ using FSB(I don't have a GF) it increases to over 400%. The GF T&L unit is still scaling.
For MDK2, if you run hardware mode on a GF compared to a V5 at low res(just to leave it strictly T&L and eliminate fillrate), the GF/GF2 is quite a bit faster then the V5, in the order of ~250% using Rev's numbers with older drivers. That's a ~850MHZ CPU, although the comparison unfortunately relies on the OpenGL drivers of each board, both of which have improved significantly in the past four months since those numbers were run.
ICyourNipple-
"honestly, with no bias whatsoever, what CPU is a GeForce 2 T&L engine equivalent to in a real game situation assuming the game is heavily optimized for the T&L engine?"
By my benching I would say at least a 2.4GHZ Athlon for games looking at the GF1, though with that high of geometry complexity you may well be fill limited before you are able to have the T&L unit stretch its' legs. DMZG is an example of this, with the amount of overdraw raw fillrate limits you before the T&L unit will become a bottleneck. Unfortunately we don't have enough games to get a better idea of exactly what level of performance is possible.
You are taking what I've said out of context.. and assuming I know what you are saying I should be flamed about, I would agree with you except you are taking those posts out of context. The one about the whitepaper is a prime example. I clearly explain in a post that the way that post was phrased did not carry out the intended meaning very well and so I explained.
That aside, anyone who would stoops so low as to attempt to threaten someone (and just so you know, I've done nothing illegal at all.. I'm very careful about that and I know what I can and cannot do) is pretty sad. You've proven your age (no offense, but you have).
That aside, anyone who would stoops so low as to attempt to threaten someone (and just so you know, I've done nothing illegal at all.. I'm very careful about that and I know what I can and cannot do) is pretty sad. You've proven your age (no offense, but you have).
AlabamaMan
Junior Member
dave, the wallpaper comment is just one of many. "ingorant fool"; "no one cares what you think" (in reply to "in my opinion"😉... nothing to be proud of.
as for sec, i wrote it in the moment of anger. i am sure you would know better then break the rules.
You've proven your age
really? want to take a stab at it? and does your comment has any but offesive intend?
as for sec, i wrote it in the moment of anger. i am sure you would know better then break the rules.
You've proven your age
really? want to take a stab at it? and does your comment has any but offesive intend?
BenSkywalker
Diamond Member
That screwed me up...
I read Dave's reply posted at 12:13 and was scratching my head as to what I said???
Than I realized that he posted his at the exact same time as mine so he wasn't talking to me.....
I read Dave's reply posted at 12:13 and was scratching my head as to what I said???
Than I realized that he posted his at the exact same time as mine so he wasn't talking to me.....
Ok, demos.
They optimize the geometry mostly. I don't feel like going into specifics.
Sampling proximity(same thing that gives RGSS an edge in eliminating aliasing artifacts creates more noticeable FSAA artifacts ie, haloing and blurring). Perhaps I should have used detail instead of accuracy, it may be better expressed that way.
There is no reason this would be true.
The only thing that is different by changing sampling positions is where your maximum color varitions go. Which angle.
Near the end of the thread it seemed to be agreed upon that on a mathematical basis at least, higher res could be proven to be superior(though I don't recall who was still left in the discussion, it had dwindled by that point).
No, I pretty clearly recall that the conclusion was that an anti-aliased image was more accurate, while high resolution provided more detail.
They are still CPU limited. Using MDK2 or TD6 as examples(covers both major APIs) while my FPS are quite a bit better with hardware T&L, I am completely CPU bound by game code. I have tested extensively and the edge that my GF1 provides increases on a percentage basis when I overclock the CPU, though they don't budge when I OC or UC the core. Both games, particularly TD6, are composed nearly entirely of static vertices, so that of course does have an impact. With TD6, I'm seeing nearly a 400% increase using hardware T&L over software, and I have an Athlon550. Upping it to 600MHZ using FSB(I don't have a GF) it increases to over 400%. The GF T&L unit is still scaling.[b/]
That is interesting. I'm a bit perplexed though. Not that I doubt you, but recall how a big deal was made before because in TD6 a CPU was faster than T&L. Now that aside, I do find your results interesting. There must be a very small fill-rate requirement in that game for that to be happening. One thing that does bother me about the whole thing though is that scaling of T&L with CPU. I mean why is the T&L engine so dependant on the CPU? The idea of a T&L is to offload the CPU, and really there is no technical reason that should be happening. The situation is really fishy (not that I doubt you, but the app)
For MDK2, if you run hardware mode on a GF compared to a V5 at low res(just to leave it strictly T&L and eliminate fillrate), the GF/GF2 is quite a bit faster then the V5, in the order of ~250% using Rev's numbers with older drivers. That's a ~850MHZ CPU, although the comparison unfortunately relies on the OpenGL drivers of each board, both of which have improved significantly in the past four months since those numbers were run.
Yeah, it is the old drivers thing. 3dfx (trying to keep myself seperate here 🙂) made a lot of optimization to it. Also, you can try the WickedGL and you might get further performance over the latest V5 drivers.
Ben, you present one of the big issues with T&L and future games, which is something I'm pointed at though not enough. When it comes to future games, there are going to be a lot more texture passes and depth complexity. Because of this you'll be hitting an early fill-rate limit and so T&L here won't get you any benifit. Again though, I reference our old articles at B3D on the subject is they go deap into this.
They optimize the geometry mostly. I don't feel like going into specifics.
Sampling proximity(same thing that gives RGSS an edge in eliminating aliasing artifacts creates more noticeable FSAA artifacts ie, haloing and blurring). Perhaps I should have used detail instead of accuracy, it may be better expressed that way.
There is no reason this would be true.
The only thing that is different by changing sampling positions is where your maximum color varitions go. Which angle.
Near the end of the thread it seemed to be agreed upon that on a mathematical basis at least, higher res could be proven to be superior(though I don't recall who was still left in the discussion, it had dwindled by that point).
No, I pretty clearly recall that the conclusion was that an anti-aliased image was more accurate, while high resolution provided more detail.
They are still CPU limited. Using MDK2 or TD6 as examples(covers both major APIs) while my FPS are quite a bit better with hardware T&L, I am completely CPU bound by game code. I have tested extensively and the edge that my GF1 provides increases on a percentage basis when I overclock the CPU, though they don't budge when I OC or UC the core. Both games, particularly TD6, are composed nearly entirely of static vertices, so that of course does have an impact. With TD6, I'm seeing nearly a 400% increase using hardware T&L over software, and I have an Athlon550. Upping it to 600MHZ using FSB(I don't have a GF) it increases to over 400%. The GF T&L unit is still scaling.[b/]
That is interesting. I'm a bit perplexed though. Not that I doubt you, but recall how a big deal was made before because in TD6 a CPU was faster than T&L. Now that aside, I do find your results interesting. There must be a very small fill-rate requirement in that game for that to be happening. One thing that does bother me about the whole thing though is that scaling of T&L with CPU. I mean why is the T&L engine so dependant on the CPU? The idea of a T&L is to offload the CPU, and really there is no technical reason that should be happening. The situation is really fishy (not that I doubt you, but the app)
For MDK2, if you run hardware mode on a GF compared to a V5 at low res(just to leave it strictly T&L and eliminate fillrate), the GF/GF2 is quite a bit faster then the V5, in the order of ~250% using Rev's numbers with older drivers. That's a ~850MHZ CPU, although the comparison unfortunately relies on the OpenGL drivers of each board, both of which have improved significantly in the past four months since those numbers were run.
Yeah, it is the old drivers thing. 3dfx (trying to keep myself seperate here 🙂) made a lot of optimization to it. Also, you can try the WickedGL and you might get further performance over the latest V5 drivers.
Ben, you present one of the big issues with T&L and future games, which is something I'm pointed at though not enough. When it comes to future games, there are going to be a lot more texture passes and depth complexity. Because of this you'll be hitting an early fill-rate limit and so T&L here won't get you any benifit. Again though, I reference our old articles at B3D on the subject is they go deap into this.
Well, let me clear up the ignorant fool thing yet again.
It goes like this. There are technical facts that there is no getting around. A person can express their opinion about a fact, but because there is a set "fact" opinions mean nothing. Facts are facts. With that said, this guy was saying as his opinion something that goes against a set fact. I tried to explain this and point him to something to read. He refused and said he didn't need to. That is ignornace and hence my point. I certain give, I was way to harsh in that post (I'm sure you understand.. as you said with the SEC thing.. it is just a case where we are wrong and we hope that people won't hold it against us) but I still maintain that should a perspective on things is ignornace.
As for the age thing, I'm just gonna drop that whole thing because I really don't want to fight.
It goes like this. There are technical facts that there is no getting around. A person can express their opinion about a fact, but because there is a set "fact" opinions mean nothing. Facts are facts. With that said, this guy was saying as his opinion something that goes against a set fact. I tried to explain this and point him to something to read. He refused and said he didn't need to. That is ignornace and hence my point. I certain give, I was way to harsh in that post (I'm sure you understand.. as you said with the SEC thing.. it is just a case where we are wrong and we hope that people won't hold it against us) but I still maintain that should a perspective on things is ignornace.
As for the age thing, I'm just gonna drop that whole thing because I really don't want to fight.
AlabamaMan
Junior Member
ok, i see what you are getting at. fair enough.
Dave,
I don't know squat about the technical side of this discussion, although I am learning something (Chinese I think!). It seems to me, a general consumer who goes by benchmarks, reviews, and this message board that 3DFX is not up there performance wise with Nvidia. I'm not a Nvidia mark infact I wish I could purchase 3DFX everytime - the Voodoo 2 was my first board and I only got rid of it a few months back after buying a GF2MX. Why doesn't 3DFX just produce a board that is way ahead of the competition?
If I was going to build a board I would want it to steal the thunder from the leading competitor and make people notice that I was around and a force to be reckoned with. Like I said, if I was more technically knowledgable I could explain what I mean. I suppose you are gonna have to use your imagination on this one. 😱 😀:
I don't know squat about the technical side of this discussion, although I am learning something (Chinese I think!). It seems to me, a general consumer who goes by benchmarks, reviews, and this message board that 3DFX is not up there performance wise with Nvidia. I'm not a Nvidia mark infact I wish I could purchase 3DFX everytime - the Voodoo 2 was my first board and I only got rid of it a few months back after buying a GF2MX. Why doesn't 3DFX just produce a board that is way ahead of the competition?
If I was going to build a board I would want it to steal the thunder from the leading competitor and make people notice that I was around and a force to be reckoned with. Like I said, if I was more technically knowledgable I could explain what I mean. I suppose you are gonna have to use your imagination on this one. 😱 😀:
AlabamaMan
Junior Member
i have realized how easy it is to make the same mistake you did 🙂
no, no hard feelings.
no, no hard feelings.
BenSkywalker
Diamond Member
Dave-
"I mean why is the T&L engine so dependant on the CPU? The idea of a T&L is to offload the CPU, and really there is no technical reason that should be happening. The situation is really fishy (not that I doubt you, but the app)"
I can say that the T&L code was heavily optimized for SSE, but I have an Athlon. A like clocked PIII produces restults nearly twice as fast as my Athlon, but I don't have a PIII😉
For the prior benches that Kyle had up, two things. One is that he was running at 1024x768 with detail set to high for everything, he fill limited the bench even though he was using 16bit color. This game starts dropping FPS moving from 320x240 to 640x480, it has some serious issued with overdraw considering the type of game it is(it has the option to view overdraw that looks a lot like the Quake3 shots using the Intel utility that Kristoff posted some time ago).
The other issue with the bench was vertex caching. I'm sure you know all about the changes to the Det3s in that area, and it made a huge difference in this game, over 50% in many cases comparing the Det2 5.32s to the Det3 6.18s.
For this particular title, hardware T&L makes it fly while software(at just over 30FPS avereage) is unplayable. I wouldn't want to spend too much time playing that game, and it likely has some fairly horrible code, but in this case hardware T&L is the difference for me between playable and not.
"There is no reason this would be true.
The only thing that is different by changing sampling positions is where your maximum color varitions go. Which angle."
If all sampling positions were taken from the same relative proximity I would agree, but they aren't. With RGSS you create a situation in which you weight certain areas more heavily in the final ouput. Looking at the White Paper(calling it your white paper in this case sounds confrontational which I am not trying to be) you can see that entire pixel sized areas have no samples taken at all while ceratin areas close to the edges of the pixel are heavily sampled from. With OGSS you always have sampling that is evenly weighted in terms of proximity, which is a disadvantage in terms of eliminating aliiasing artifacts but does produce a more accurate representation of the textures.
To bring up an example that someone else used over at B3d, if you have a mountain in the distance that is textured with white and black stripes, RGSS will turn it grey sooner then OGSS(ignoring mip mapping and sticking with just FSAA), while higher res will leave it white and black and could create a situation where the entire mountain swaps back and forth between white and black depending on how you turn. Which is more accurate? None of the situations are ideal, but the mountain doesn't contain *any* grey. The FSAA method may produce superior visual results, but it is less accurate and RGSS is less accurate then OGSS. RGSS may look better in that situation, but it is less accurate when compared to the native image.
"I mean why is the T&L engine so dependant on the CPU? The idea of a T&L is to offload the CPU, and really there is no technical reason that should be happening. The situation is really fishy (not that I doubt you, but the app)"
I can say that the T&L code was heavily optimized for SSE, but I have an Athlon. A like clocked PIII produces restults nearly twice as fast as my Athlon, but I don't have a PIII😉
For the prior benches that Kyle had up, two things. One is that he was running at 1024x768 with detail set to high for everything, he fill limited the bench even though he was using 16bit color. This game starts dropping FPS moving from 320x240 to 640x480, it has some serious issued with overdraw considering the type of game it is(it has the option to view overdraw that looks a lot like the Quake3 shots using the Intel utility that Kristoff posted some time ago).
The other issue with the bench was vertex caching. I'm sure you know all about the changes to the Det3s in that area, and it made a huge difference in this game, over 50% in many cases comparing the Det2 5.32s to the Det3 6.18s.
For this particular title, hardware T&L makes it fly while software(at just over 30FPS avereage) is unplayable. I wouldn't want to spend too much time playing that game, and it likely has some fairly horrible code, but in this case hardware T&L is the difference for me between playable and not.
"There is no reason this would be true.
The only thing that is different by changing sampling positions is where your maximum color varitions go. Which angle."
If all sampling positions were taken from the same relative proximity I would agree, but they aren't. With RGSS you create a situation in which you weight certain areas more heavily in the final ouput. Looking at the White Paper(calling it your white paper in this case sounds confrontational which I am not trying to be) you can see that entire pixel sized areas have no samples taken at all while ceratin areas close to the edges of the pixel are heavily sampled from. With OGSS you always have sampling that is evenly weighted in terms of proximity, which is a disadvantage in terms of eliminating aliiasing artifacts but does produce a more accurate representation of the textures.
To bring up an example that someone else used over at B3d, if you have a mountain in the distance that is textured with white and black stripes, RGSS will turn it grey sooner then OGSS(ignoring mip mapping and sticking with just FSAA), while higher res will leave it white and black and could create a situation where the entire mountain swaps back and forth between white and black depending on how you turn. Which is more accurate? None of the situations are ideal, but the mountain doesn't contain *any* grey. The FSAA method may produce superior visual results, but it is less accurate and RGSS is less accurate then OGSS. RGSS may look better in that situation, but it is less accurate when compared to the native image.
I can say that the T&L code was heavily optimized for SSE, but I have an Athlon. A like clocked PIII produces restults nearly twice as fast as my Athlon, but I don't have a PIII
Yeah.. the thing is I don?t understand why. The T&L engine should be independent.
For the prior benches that Kyle had up, two things. One is that he was running at 1024x768 with detail set to high for everything, he fill limited the bench even though he was using 16bit color. This game starts dropping FPS moving from 320x240 to 640x480, it has some serious issued with overdraw considering the type of game it is(it has the option to view overdraw that looks a lot like the Quake3 shots using the Intel utility that Kristoff posted some time ago).
Kristof?. Not Kristoff damnit. He?ll kill you if you do that. 🙂
For this particular title, hardware T&L makes it fly while software(at just over 30FPS avereage) is unplayable. I wouldn't want to spend too much time playing that game, and it likely has some fairly horrible code, but in this case hardware T&L is the difference for me between playable and not.
I have to assume they haven?t done much SSE/3Dnow! Optimization. For that game to be slow in software, something is really wrong.
If all sampling positions were taken from the same relative proximity I would agree, but they aren't. With RGSS you create a situation in which you weight certain areas more heavily in the final ouput. Looking at the White Paper(calling it your white paper in this case sounds confrontational which I am not trying to be) you can see that entire pixel sized areas have no samples taken at all while ceratin areas close to the edges of the pixel are heavily sampled from. With OGSS you always have sampling that is evenly weighted in terms of proximity, which is a disadvantage in terms of eliminating aliiasing artifacts but does produce a more accurate representation of the textures.
I?m not sure I see how you figure you have a weight certain areas more. A physical example. Take four samples \||/ If you average that, you are going to come up with a perfectly straight line. You aren?t averaging one area more than the another.
To bring up an example that someone else used over at B3d, if you have a mountain in the distance that is textured with white and black stripes, RGSS will turn it grey sooner then OGSS(ignoring mip mapping and sticking with just FSAA), while higher res will leave it white and black and could create a situation where the entire mountain swaps back and forth between white and black depending on how you turn. Which is more accurate? None of the situations are ideal, but the mountain doesn't contain *any* grey. The FSAA method may produce superior visual results, but it is less accurate and RGSS is less accurate then OGSS. RGSS may look better in that situation, but it is less accurate when compared to the native image.
This really isn?t true though. I mean if the border was at 45 degrees, OGSS would be the first to get the grey line.
Yeah.. the thing is I don?t understand why. The T&L engine should be independent.
For the prior benches that Kyle had up, two things. One is that he was running at 1024x768 with detail set to high for everything, he fill limited the bench even though he was using 16bit color. This game starts dropping FPS moving from 320x240 to 640x480, it has some serious issued with overdraw considering the type of game it is(it has the option to view overdraw that looks a lot like the Quake3 shots using the Intel utility that Kristoff posted some time ago).
Kristof?. Not Kristoff damnit. He?ll kill you if you do that. 🙂
For this particular title, hardware T&L makes it fly while software(at just over 30FPS avereage) is unplayable. I wouldn't want to spend too much time playing that game, and it likely has some fairly horrible code, but in this case hardware T&L is the difference for me between playable and not.
I have to assume they haven?t done much SSE/3Dnow! Optimization. For that game to be slow in software, something is really wrong.
If all sampling positions were taken from the same relative proximity I would agree, but they aren't. With RGSS you create a situation in which you weight certain areas more heavily in the final ouput. Looking at the White Paper(calling it your white paper in this case sounds confrontational which I am not trying to be) you can see that entire pixel sized areas have no samples taken at all while ceratin areas close to the edges of the pixel are heavily sampled from. With OGSS you always have sampling that is evenly weighted in terms of proximity, which is a disadvantage in terms of eliminating aliiasing artifacts but does produce a more accurate representation of the textures.
I?m not sure I see how you figure you have a weight certain areas more. A physical example. Take four samples \||/ If you average that, you are going to come up with a perfectly straight line. You aren?t averaging one area more than the another.
To bring up an example that someone else used over at B3d, if you have a mountain in the distance that is textured with white and black stripes, RGSS will turn it grey sooner then OGSS(ignoring mip mapping and sticking with just FSAA), while higher res will leave it white and black and could create a situation where the entire mountain swaps back and forth between white and black depending on how you turn. Which is more accurate? None of the situations are ideal, but the mountain doesn't contain *any* grey. The FSAA method may produce superior visual results, but it is less accurate and RGSS is less accurate then OGSS. RGSS may look better in that situation, but it is less accurate when compared to the native image.
This really isn?t true though. I mean if the border was at 45 degrees, OGSS would be the first to get the grey line.
Dear Forum Reader,
You are here, and one of three things have happened...
1) You've read through every single post and are intrigued and enligtend by the lively (and informative) debate. Congrats, you are a 3d tech weenie.
2) You went to the last page first to see who was flaming who and read backwards to get all the good stuff. Congrats, you have probably been seen as a guest on The Springer Show.
3) You just smoked a really big bag of weed just randomly typed forums.anandtech.com/reply.cfm?catid=27&threadid=264912&messid=1888884 into your address window. Congrats, as stoned as you are you will probably understand this discussion better than many.
On a more serious note, excellent discussions fellas. Quite informative. Please continue as I re-lurk.
You are here, and one of three things have happened...
1) You've read through every single post and are intrigued and enligtend by the lively (and informative) debate. Congrats, you are a 3d tech weenie.
2) You went to the last page first to see who was flaming who and read backwards to get all the good stuff. Congrats, you have probably been seen as a guest on The Springer Show.
3) You just smoked a really big bag of weed just randomly typed forums.anandtech.com/reply.cfm?catid=27&threadid=264912&messid=1888884 into your address window. Congrats, as stoned as you are you will probably understand this discussion better than many.
On a more serious note, excellent discussions fellas. Quite informative. Please continue as I re-lurk.
BenSkywalker
Diamond Member
Dave-
"Kristof?. Not Kristoff damnit. He?ll kill you if you do that."
Doh!😱 I do that all the time too...
"I have to assume they haven?t done much SSE/3Dnow! Optimization. For that game to be slow in software, something is really wrong."
But it is twice as fast using SSE as it is using no SIMD at all. The complexity of the models for the cars seems to be rather high, and they are only using a single infinite light source, best case for hardware T&L. I don't think they did anything too spectacular as far as optimizations, but it does offer a ~100% boost running SSE.
"I?m not sure I see how you figure you have a weight certain areas more. A physical example. Take four samples \||/ If you average that, you are going to come up with a perfectly straight line. You aren?t averaging one area more than the another."
With RGSS you are weighting the edges of the pixel more then the center. Both methods do this, but moreso with RGSS then OGSS. For close proximity objects it isn't a real issue, but when you are looking at an object in the distance with a 256x256 texture map that is being viewed at 25x25 size then you are more then likely going to be sampling completely different points. Which ties in with...
"This really isn?t true though. I mean if the border was at 45 degrees, OGSS would be the first to get the grey line."
Very true, but you did do a great job explaining optimal angles and how they relate to noticeable aliasing🙂. Haloing, which the "mountain" example is, is more noticeable along certain angles just as jaggies are. The haloing created by RGSS is more noticeable then that of OGSS. I still would take higher res and deal with the "natural" artifacts then the ones introduced by FSAA, but they may be because I spend a great deal of time looking at the flaws it creates.
"Kristof?. Not Kristoff damnit. He?ll kill you if you do that."
Doh!😱 I do that all the time too...
"I have to assume they haven?t done much SSE/3Dnow! Optimization. For that game to be slow in software, something is really wrong."
But it is twice as fast using SSE as it is using no SIMD at all. The complexity of the models for the cars seems to be rather high, and they are only using a single infinite light source, best case for hardware T&L. I don't think they did anything too spectacular as far as optimizations, but it does offer a ~100% boost running SSE.
"I?m not sure I see how you figure you have a weight certain areas more. A physical example. Take four samples \||/ If you average that, you are going to come up with a perfectly straight line. You aren?t averaging one area more than the another."
With RGSS you are weighting the edges of the pixel more then the center. Both methods do this, but moreso with RGSS then OGSS. For close proximity objects it isn't a real issue, but when you are looking at an object in the distance with a 256x256 texture map that is being viewed at 25x25 size then you are more then likely going to be sampling completely different points. Which ties in with...
"This really isn?t true though. I mean if the border was at 45 degrees, OGSS would be the first to get the grey line."
Very true, but you did do a great job explaining optimal angles and how they relate to noticeable aliasing🙂. Haloing, which the "mountain" example is, is more noticeable along certain angles just as jaggies are. The haloing created by RGSS is more noticeable then that of OGSS. I still would take higher res and deal with the "natural" artifacts then the ones introduced by FSAA, but they may be because I spend a great deal of time looking at the flaws it creates.
With RGSS you are weighting the edges of the pixel more then the center. Both methods do this, but moreso with RGSS then OGSS. For close proximity objects it isn't a real issue, but when you are looking at an object in the distance with a 256x256 texture map that is being viewed at 25x25 size then you are more then likely going to be sampling completely different points. Which ties in with...
Yeah, I see what you are saying. Really though, it is a trade off. I mean overally RGSS is going to give you better quality on average.
Very true, but you did do a great job explaining optimal angles and how they relate to noticeable aliasing. Haloing, which the "mountain" example is, is more noticeable along certain angles just as jaggies are. The haloing created by RGSS is more noticeable then that of OGSS. I still would take higher res and deal with the "natural" artifacts then the ones introduced by FSAA, but they may be because I spend a great deal of time looking at the flaws it creates.
damn.. turning it around on me. 🙂 Really though, if you consider the artifact level is pretty small. The higher resolution you get, the less likely you'll be to see any. And when it comes down to it, anti-aliasing handles artifacts better than high-resolution. However, do consider that we are still in the early days of anti-aliasing. There are plenty of different forms of it, which are much more advanced. But when it comes to what we currently have, on an overal image RGSS is going to give a best overall result .
Now my question. How did this whole conversation get started? 🙂
BenSkywalker
Diamond Member
Dave-
"Yeah, I see what you are saying. Really though, it is a trade off. I mean overally RGSS is going to give you better quality on average."
I would say it depends. I think that RGSS does a better job at eliminating aliasing artifacts, but it also introduces more noticeable ones. I think that 3dfx's FSAA is better then nVidia's or ATi's in image quality, but I have seen them all done in software with much greater precission. I'm not talking about which is better out of what we have now, I'm talking about the methods themselves outside of current implementations. Besides, I think almost everyone is in agreement that JGSS would be the best for gaming, although I haven't heard anything about hardware support on the next couple of generations.
"damn.. turning it around on me. Really though, if you consider the artifact level is pretty small. The higher resolution you get, the less likely you'll be to see any. And when it comes down to it, anti-aliasing handles artifacts better than high-resolution. However, do consider that we are still in the early days of anti-aliasing. There are plenty of different forms of it, which are much more advanced. But when it comes to what we currently have, on an overal image RGSS is going to give a best overall result ."
In hardware we are in the early stages, it has been around for many years on the software side🙂 There is a great deal of progress that needs to be made looking at current hardware to catch comparable software implementations, and even they have the problems that I'm bringing up(in reality they are what I base nearly all my comments on).
I agree absolutely that higher res reduces the significance greatly, but it also reduces the "need" for FSAA. At like res I'll take FSAA over non without hesitation as long as performance is tollerable, but right now we are at the point where we can chose 4x FSAA or double the res which will remain my choice for 90%+ of the games I play.
"Now my question. How did this whole conversation get started?"
Hmmm, I don't know, you were in this thread on the first page, I just jumped in🙂
BTW- Did you ever get your watch fixed?
"Yeah, I see what you are saying. Really though, it is a trade off. I mean overally RGSS is going to give you better quality on average."
I would say it depends. I think that RGSS does a better job at eliminating aliasing artifacts, but it also introduces more noticeable ones. I think that 3dfx's FSAA is better then nVidia's or ATi's in image quality, but I have seen them all done in software with much greater precission. I'm not talking about which is better out of what we have now, I'm talking about the methods themselves outside of current implementations. Besides, I think almost everyone is in agreement that JGSS would be the best for gaming, although I haven't heard anything about hardware support on the next couple of generations.
"damn.. turning it around on me. Really though, if you consider the artifact level is pretty small. The higher resolution you get, the less likely you'll be to see any. And when it comes down to it, anti-aliasing handles artifacts better than high-resolution. However, do consider that we are still in the early days of anti-aliasing. There are plenty of different forms of it, which are much more advanced. But when it comes to what we currently have, on an overal image RGSS is going to give a best overall result ."
In hardware we are in the early stages, it has been around for many years on the software side🙂 There is a great deal of progress that needs to be made looking at current hardware to catch comparable software implementations, and even they have the problems that I'm bringing up(in reality they are what I base nearly all my comments on).
I agree absolutely that higher res reduces the significance greatly, but it also reduces the "need" for FSAA. At like res I'll take FSAA over non without hesitation as long as performance is tollerable, but right now we are at the point where we can chose 4x FSAA or double the res which will remain my choice for 90%+ of the games I play.
"Now my question. How did this whole conversation get started?"
Hmmm, I don't know, you were in this thread on the first page, I just jumped in🙂
BTW- Did you ever get your watch fixed?
BenSkywalker
Diamond Member
"If you do this in real life, won't the mountain look grey from a distance anyway, assuming the stripes are thin enough?"
Good point, I'll explain this a bit more.
In real life the point at which the mountain would appear grey is based on your eyes. I may see it sooner or later then you, but yes it would happen. This same thing can be reproduced on a monitor with high enough resolution, it will be up to your eyes to distinguish when you see it as grey and when you see it as black and white.
The big difference is the "jump" from one to another. The only way around this is significantly higher resolutions, higher then what any monitor I have seen can do. FSAA will have the "jump" problem while high enough resolution would be more represenative of a real life situation. If done at high enough res, you will gradualy see the mountain changing to more pronounced color variations from grey to being able to see white and black, it won't "jerk".
Good point, I'll explain this a bit more.
In real life the point at which the mountain would appear grey is based on your eyes. I may see it sooner or later then you, but yes it would happen. This same thing can be reproduced on a monitor with high enough resolution, it will be up to your eyes to distinguish when you see it as grey and when you see it as black and white.
The big difference is the "jump" from one to another. The only way around this is significantly higher resolutions, higher then what any monitor I have seen can do. FSAA will have the "jump" problem while high enough resolution would be more represenative of a real life situation. If done at high enough res, you will gradualy see the mountain changing to more pronounced color variations from grey to being able to see white and black, it won't "jerk".
TRENDING THREADS
-
Discussion Zen 5 Speculation (EPYC Turin and Strix Point/Granite Ridge - Ryzen 9000)- Started by DisEnchantment
- Replies: 25K
-
Discussion Intel Meteor, Arrow, Lunar & Panther Lakes + WCL Discussion Threads
- Started by Tigerick
- Replies: 25K
-
-
-
