Well, I mentioned Anand because the presentation was better (and it was more striking for being such an improvement over previous articles). Brent's article was more insightful. All that is lacking given the goal of the article, IMO, is presentation. I think Brent should ask Ratchet for help in that department...if he was willing he could do an awesome job in changing that. Depends on how wedded they are to their traditional style.
4x AA performance comparisons invalid?
- Thread starter Fuz
- Start date
Those two screen shots were taken in different places so it is really irrelevant what they look like. The only way I think that they can do a good job is to use the start of a race for example when each time you load will look the same, or the spawn point. It is so silly when people get really in depth about these sorts of things and do not really regulate where the picture is and what they see.
Really you would think that reviewers would either do a better job or get off their high horse.
I realize it may be too difficult to do for them, but I think that many of these tests really are subjective and often depend on where a reviewer chooses to take pics from, certain areas will look better with different modes on different cards. It certainly seems to me that ATI's implementation is more robust, but I still do not 100% trust a few pictures, I would rather (pie in the sky) we all had super fast connections and could see a movie of what they saw.
Really you would think that reviewers would either do a better job or get off their high horse.
I realize it may be too difficult to do for them, but I think that many of these tests really are subjective and often depend on where a reviewer chooses to take pics from, certain areas will look better with different modes on different cards. It certainly seems to me that ATI's implementation is more robust, but I still do not 100% trust a few pictures, I would rather (pie in the sky) we all had super fast connections and could see a movie of what they saw.
Bigus Dickus
Regular
I'm no .html wizzard or anything, so this is just a question out of curiosity...OpenGL guy said:
Is it possible to prevent downloading of an image posted on a website? I would think that should be possible. I know I've seen streamed .mov or .avi files that I couldn't "download" the file at all, couldn't save target, nothing. I only got the .html link, not the actual file. Maybe by looking at the source code it would have been possible to locate the actual url for the file and download it?
Anyway, if it is possible to prevent downloading, then a nice javascript like the one MikeC/Ratchet did for image comparisons would make a really nice blind A/B test, essentially forcing everyone to judge at their desktop resolution (or the lowest desktop resolution for those that just had to have a closer look).
Just curious. Any web wizzards?
Doomtrooper
Veteran
Pr0n
The only way I could think to do it sort of reasonably would be to write an application that uses an undocumented file format, that displays images using a Overlay.
The overlay will prevent you from being able to use Print-Screen or Alt-Print-Screen.
But of course programs like Hypersnap can be used to grab the image from the overlay surface....
Really, there isn't a way of stopping someone from grabbing the image.
The overlay will prevent you from being able to use Print-Screen or Alt-Print-Screen.
But of course programs like Hypersnap can be used to grab the image from the overlay surface....
Really, there isn't a way of stopping someone from grabbing the image.
I wan't to point out an error everyone tends to have.
Antialisaing should not be compared in still screenshots.
The most important point in anti-aliasing is to (surprise) remove aliasing that you get when the geometry is moving on screen.
For example 2xAA on R300 will beat 4xAA on GF4/FX on still screenshots, while it will lose to it (due to less samples), in movement.
The problem of web reviews is that how can aliasing presented?
It could only be done with test programs - but it has to be sw rendering otherwise you cannot really do comparsions.
It also need to have high framerates - the higher the framerate the more obvious the aliasing.
And it obviously has to be high-polygon.
Antialisaing should not be compared in still screenshots.
The most important point in anti-aliasing is to (surprise) remove aliasing that you get when the geometry is moving on screen.
For example 2xAA on R300 will beat 4xAA on GF4/FX on still screenshots, while it will lose to it (due to less samples), in movement.
The problem of web reviews is that how can aliasing presented?
It could only be done with test programs - but it has to be sw rendering otherwise you cannot really do comparsions.
It also need to have high framerates - the higher the framerate the more obvious the aliasing.
And it obviously has to be high-polygon.
Actually, it's the opposite. With a magnifier (i.e. still shots), you can tell that the 9700 only has two colors per edge (2xAA), while the other has 4 (4xAA).
But when animating, a spinning pinwheel for example, the gamma corrected AA on the 9700 at 2xAA looks much better than the 4xAA of the GF4. Side by side comparisons really show it, esp at > 2 feet of distance. There's a "Beating" phenonema from the varying intensity of the animated GF4 AA, which causes weird moire patterns and strange artifacts. The 9700 looks great and has a constant intensity. Of course the edge crawling on the 9700 at 2xAA is worst than that of a 4xAA, but from 2 feet away or further, with animation, the gamma correction of the 9700 really steals the show.
My (I admit to be subjective) opinion.
But when animating, a spinning pinwheel for example, the gamma corrected AA on the 9700 at 2xAA looks much better than the 4xAA of the GF4. Side by side comparisons really show it, esp at > 2 feet of distance. There's a "Beating" phenonema from the varying intensity of the animated GF4 AA, which causes weird moire patterns and strange artifacts. The 9700 looks great and has a constant intensity. Of course the edge crawling on the 9700 at 2xAA is worst than that of a 4xAA, but from 2 feet away or further, with animation, the gamma correction of the 9700 really steals the show.
My (I admit to be subjective) opinion.
THe_KELRaTH
Regular
How much of a performance cost is there between having Gamma correction and no gamma correction?
ie. enough in 3Dmarks, (500 points), so that the NV30 can claim being the fastest.
Nvidia mentioned that they support the option of gamma correction in shaders. Is that a usable option or a marketing ploy so that the NV30 can quote that it has Gamma correction on the box.
ie. enough in 3Dmarks, (500 points), so that the NV30 can claim being the fastest.
Nvidia mentioned that they support the option of gamma correction in shaders. Is that a usable option or a marketing ploy so that the NV30 can quote that it has Gamma correction on the box.
OpenGL guy
Veteran
There doesn't have to be a performance penalty at all.THe_KELRaTH said:
Anyone can do gamma correction in the shaders... This won't help MSAA however.
THe_KELRaTH
Regular
You guys, (ATI Team), must be really pleased with the comparative results - I'm certainly impressed.
The R300 scores more than double in the PS2.0 shadermark test, do you think thats a realistic figure or just an Nv30 driver error as the margin is so huge.
The R300 scores more than double in the PS2.0 shadermark test, do you think thats a realistic figure or just an Nv30 driver error as the margin is so huge.
OpenGL guy
Veteran
Yes, the R300 has proven to be a good part.THe_KELRaTH said:
It's still too early to say. Not enough real facts are known about the GFFX's shaders and their performance.
Yes, as OpenGL Guy writes, anyone can do gamma correction in the shader. The R300 has dedicated HW to perform degamma from textures into the shader, and on shader output, without using any shader instructions.
However, in the AA case when you "combine" your fragments into the final pixel color, you need to read in fragments that are gamma corrected, degamma them, merge them, and then gamma correct them before sending them out to the display buffer. This is called "resolving" the multi-sample buffer. Without gamma correction in the resolve pass, the merged fragments have the wrong color. Also, if you don't gamma correct at all into and out of the frame buffer, you lose LSBs in the color (gamma correction is a form of color compression, which lines up with the displayed color). Basically, you need to do it this way to get maximum output quality.
Without it, you either lose out some color LSBs, or you get AA that has weird intensity patterns.
However, in the AA case when you "combine" your fragments into the final pixel color, you need to read in fragments that are gamma corrected, degamma them, merge them, and then gamma correct them before sending them out to the display buffer. This is called "resolving" the multi-sample buffer. Without gamma correction in the resolve pass, the merged fragments have the wrong color. Also, if you don't gamma correct at all into and out of the frame buffer, you lose LSBs in the color (gamma correction is a form of color compression, which lines up with the displayed color). Basically, you need to do it this way to get maximum output quality.
Without it, you either lose out some color LSBs, or you get AA that has weird intensity patterns.
OpenGL guy said:
Yes, not enough yet. I would hazard a guess that in the PS2.0 test, they are running in 32b mode, which runs, apparently, at 1/2 our speed. I'm sure they will optimize this case to run in 16b mode, where they will match our speed (PS2 compliance might be an issue). Of course, they will have to give up significant quality to get a speed match.
My opinion, based only on observed results.
Joe DeFuria
Legend
Sounds reasonable.
Which puts nVidia in an interesting dilemma if your speculation turns out to be correct. nVidia likes to tout their "industry's only 128 bit support" in their marketing materials. If they do drop to 64 bit mode for PS/VS 2.0 shaders in general and claim, "visual quality difference is negligible...." that seems to downplay the significance of 128 bit support in the first place....
OpenGL guy
Veteran
I would have said this myself, except that I have to make certain assumptions. For one, how many 16 bit float operations can the GFFX do per cycle? How many 32 bit? If the GFFX can do eight 16 bit float operations per cycle (as it appears), then it should be about 54% faster than a 9700 Pro at shading when using such floats. If each 32 bit float takes two cycles, then it should be 23% slower using these. Neither one matches the observed results so I didn't say anything...sireric said:
Isn't the uncertainty regarding relative pixel shader performance due to the interaction between fragment and vertex processing? In other words, I think the nv30 vertex processing architecture scalability offers an advantage in simple processing, but suffers with a more complex workload (in comparison to the R300).
It might turn out that the GFFX can have yet unknown bottlenecks when executiong shaders.
I read it somewhere that shader performance depends on the number of temporary registers used
If it's true it might be a hint for an unconvetional architecture...
I can only guess though unfortunately.
I read it somewhere that shader performance depends on the number of temporary registers used
If it's true it might be a hint for an unconvetional architecture...
I can only guess though unfortunately.
THe_KELRaTH
Regular
In fact, and I expect there's no relevance here, is that the shadermark scores are have a very similar ralation to the 200m / 350m triangles per sec rates in terms of percentage difference.