Shader Model 3.0 Done Right? X1000 lacks "Vertex Texture Fetching."

ftp://download.nvidia.com/developer/...x_Textures.pdf

La La La

Pages 11 and 12.

Notice, it says the 6800, doesn't mention the ultra, just the 6800. The 6800 had less vertex power than the ultra, so by only mentioning the 6800 we're left to think that the ultra is capable of more. After all, the ultra had 1 more vertex unit than the nu.

Next, you'll want to notice that performance of VTF is *dramatically improved* when you use dynamic branching in the pixel and vertex shaders when using displacement mapping....Since, with unoptimized code, you're generally displacing vertices that won't show it/won't be used anyway.

It's not the method that's slow, it's the CODE that's the culprit. ATi are just smearing NVidia like they always do. I really wish it'd stop, as this ISN'T a presidential campaign, it's videocards. THAT'S IT!

Now note that the 7800 has THREE more AND a second pipe for them. Speed of this has dramatically improved due to this fact.

So, how is this to slow for use?

even the subsurface scattering code was largely unoptimized in the msdn post, if developers just copy and paste sample code then of course it would suck. And if you use unoptimized coding on BOTH ATI AND NVIDIA, you should still get better results from nvidia provided you use the same generic crap sample code. BTW the code from msdn is NOT FULL RADIOSITY, it is just Precomputed Radiance Transfer, which is not AS GOOD as REAL radiosity, but gives similar effects.

I really wish ATI had put this feature into its hardware.
Not that i think it is useful in any way.

*EDIT =)*

Quote:

---

Originally Posted by Ubermann

I really wish ATI had put this feature into its hardware.
Not that i think it is useful in any way.
But that would make the Nvidia FANBOYS stfu.
"Hey ATI cant play UE3 LOL" <-- Do you really think so ?
Do you really think they would develop a game useless for all those people that has ATI ?

---

Rebuttal of fanboy remark removed.
I actually like the R500, just not the r520. The r500 is completely amazing in every aspect, the design of it is so much more efficient then anything out there. However the r520 is piece of trash, expensive piece of trash, in comparison to the r500. Hell even the 7800gtx is a piece of trash compared to the r500.
About the Unreal 3 thing, uhhh look at farcry, hdr still doesnt work right on the x1800 series. So is farcry not running at all on ati hardware? NO, just the hdr feature will not work. Same with Unreal 3, virtual displacement mapping will just be replaced with lower quality normal maps or parallax maps.

Dont take it personal.

In fact, it might be better to flat out ignore it and look at the benchmarks in reviews and prices on the street....this thread's gotten out of control already :slapass:

Quote:

---

Originally Posted by Ubermann

Dont take it personal.

---

I hope you didnt skip the last part about farcry and etc.

Quote:

---

Originally Posted by P_1

I actually like the R500, just not the r520. The r500 is completely amazing in every aspect, the design of it is so much more efficient then anything out there. However the r520 is piece of trash, expensive piece of trash, in comparison to the r500. Hell even the 7800gtx is a piece of trash compared to the r500.

---

AMEN... I firmly agree that the R500(now R600 for us pc owners) is an AMAZING piece of hardware! Infact, I place my bets upon it devouring whatever NVidia have to throw at it by the time release is upon us. ATi has been working on that chip for longer than probably any other chip ever released, so by the time it hits it WILL be a work of art. The G80 will be NVidia's unified part, but considering ATi had the R600 ready while NVidia was still saying unified pipes/shaders were useless, I'm POSITIVE ATi will likely own that round. Especially considering ATi's done nothing but add to it for the past 2-3 years.

Next gen(not the refresh, but actual generation) will belong to ATi, I can promise you all that one! Grayskull, if you can, please tell us The R600 will still be seen next year!

Now, on with the show, NOWHERE did any of us say that the r520 cannot run UE3.0, we simply stated that the R520 will not do virtual displacement mapping if epic doesn't code the work around, unless the workaround can be forced via drivers(if it has to be done via the developer, there could be a problem). That is what this arguement is about guys, now can we please stay to that point?

This thread has been closed once before, lets please not get it closed again. P_1, please edit your post, as I promise you perkam is going to in about 15 - 20 minutes, and it won't be in a nice manner. Same to you Ubermann. This is a very interesting discussion, which has lead to alot of newfound knowledge of BOTH architectures/methods, and I'd honestly like to see it stay around, as I'd rather learn about the cards than merely bash them.

:::edit::
thank you P_1, ubermann, I'd advise you do the same. This isn't a flame war thread, it's an intelligent debate.

Quote:

---

Originally Posted by Shadowmage

Gimme PDF.

Anyways, everyone who does ANY sort of REAL game design (NOT JUST ATI) knows that NVIDIA's solution is half-assed. It's common knowledge. The only way I can prove this is by quoting graphics pros who say it's not very powerful. Therefore, you can either believe Diltech, or you can believe a graphics pro.

I could ask my NVIDIA contact, but like all PR managers, he'll talk about how much VTF rocks and how NVIDIA > ATI, so kinda pointless (unless someone can help me word it to actually get a decent answer)

BTW, Radiosity is debunked! This link is for a tutorial in PRT (aka real-time Radiosity, or what looks like Radiosity) for DirectX, August 2005 update. Therefore, we can assume that it can be run on ALL cards.

http://msdn.microsoft.com/library/de...ormableprt.asp

---

Shadow, that's PRT, not this... Just because the reality engine calls it "real time radiosity", doesn't mean it IS radiosity. Also, note that the the 7800gtx showed radiosity BEFORE the august update. Explain that one. :D
http://www.gamedev.net/reference/pro...s/rtradiosity/
That's NOT prt. This is what NVidia use for real time radiosity.

Now shadow, notice everyone at beyond 3d are completely baffled as to how the 7800 is pulling it off... it's NOT prt, PRT only does the edges. This does the ENTIRE thing.

Of course, this thread ISN'T your grounds to continue that discussion, we have a thread in the general hardware section for that... so please keep on subject.

Also, shadow, as for "believe a graphics pro", don't forget who I work for....

Quote:

---

Originally Posted by DilTech

[/b]

Shadow, that's PRT, not this... Just because the reality engine calls it "real time radiosity", doesn't mean it IS radiosity. Also, note that the the 7800gtx showed radiosity BEFORE the august update. Explain that one. :D
http://www.gamedev.net/reference/pro...s/rtradiosity/
That's NOT prt. This is what NVidia use for real time radiosity.

Now shadow, notice everyone at beyond 3d are completely baffled as to how the 7800 is pulling it off... it's NOT prt, PRT only does the edges. This does the ENTIRE thing.

---

Exactly, he states that all the developers are bashing the 7800gtx. He is also implying that he knows something about game development. As you can see the Game developers ARE NOT talking about how slow NV hardware is Shadow, instead they are praising it. Actually now that I take a look at the thing you linked, he also mentions that its not full radiosity either, but its close enough to fool the human eye, so thats a bit of a disappointment.

P_1 > You're positive that makes for more efficient runtime code? It makes for smaller and more "elegant" code, yes, however, usually when you start using for and loops you add extra instructions which the cpu/gpu/whatever will have to interpret. That original code you quoted, has all the instructions needed, nothing else. You have added lots of extra instructions, that will have to be either compiled into (1) the above or (2) what you written. In (1) the performance will be the same. In (2) there will have to be several extra evaluations done by the processing unit, just to come up with the same lines as in the original (with lots of extra of no need). Or, am I totally off here?

Shadowmage > Please, stop flaming Dil. Dil doesn't hate ATI he's just a very good buffer in these historically slightly ATI friendly forums. Dil is a very reputable member always contributing to the discussions in a positive way, and also one of the better XS News posters, I wonder, why don't you start posting news (please, differentiate between news and news, stress any speculations and assumptions as such) instead, providing us with all these credible sources you seem awfully tight with but we've never heard of? Shadow, I strongly advice you to take a serious look at yourself before making such accusations again.
Perkam, please don't PM me for this... it was not inteded as flaming.

Quote:

---

Originally Posted by slider99

P_1 > You're positive that makes for more efficient runtime code? It makes for smaller and more "elegant" code, yes, however, usually when you start using for and loops you add extra instructions which the cpu/gpu/whatever will have to interpret. That original code you quoted, has all the instructions needed, nothing else. You have added lots of extra instructions, that will have to be either compiled into (1) the above or (2) what you written. In (1) the performance will be the same. In (2) there will have to be several extra evaluations done by the processing unit, just to come up with the same lines as in the original (with lots of extra of no need). Or, am I totally off here?

Shadowmage > Please, stop flaming Dil. Dil doesn't hate ATI he's just a very good buffer in these historically slightly ATI friendly forums. Dil is a very reputable member always contributing to the discussions in a positive way, and also one of the better XS News posters, I wonder, why don't you start posting news (please, differentiate between news and news, stress any speculations and assumptions as such) instead, providing us with all these credible sources you seem awfully tight with but we've never heard of? Shadow, I strongly advice you to take a serious look at yourself before making such accusations again.
Perkam, please don't PM me for this... it was not inteded as flaming.

---

I'm pretty sure as I've written similar code to this before in which I wrote out tons of statements instead of dynamically calling them. When I dynamically called the stuff I got a smaller program size 132k compared to 104k, and the runtimes were faster as well. This also allows it to scale much better in terms of when you have many more arrays like vExitRadiance[4], vExitRadiance[5],.... With my method all you would have to do is change a few numbers in the for loops and the pointers and it would do it.
Feel free to take the code and compile something similar if you would like to compare it. (the full source is in the direct x sdk, so you can go ahead, and make a copy of it, and then replace it with the code I made, and then compile, and compare both executables from the sdk)

Code:

---

Source: (SDK root)\Samples\C++\Direct3D\LocalDeformablePRT
Executable: (SDK root)\Samples\C++\Direct3D\Bin\x86 or x64\LocalDeformablePRT.exe

---

P_1 > You are perfectly right about scaling and program size (as well as in memory allocation), however, the original code, I'm quite confident, has less instructions (basically your 'optimized' code will result in running the exact same code as the original, plus some extra such as incrementing a variable (counter)). This would seem logical at least. Basically, what I'm saying, is that the original code should result in fewer instructions needed to be evaluated by the processing unit than your optimized. Still I can be wrong of course.

Does this have anything to do with vertex texture fetching or is it about radiosity ?
I did read thread from start before i made that stupid post earlier but now i have no idea whats on topic.
Radiosity is a part of SM3.0 ?

Quote:

---

Originally Posted by slider99

P_1 > You are perfectly right about scaling and program size (as well as in memory allocation), however, the original code, I'm quite confident, has less instructions (basically your 'optimized' code will result in running the exact same code as the original, plus some extra such as incrementing a variable (counter)). This would seem logical at least. Basically, what I'm saying, is that the original code should result in fewer instructions needed to be evaluated by the processing unit than your optimized. Still I can be wrong of course.

---

Just test it out, I havent tried it on a small scale. Also I'm pretty limited here by university bandwidth so I'm not gonna be dling the sdk just to test it.

Quote:

---

Originally Posted by Ubermann

Does this have anything to do with vertex texture fetching or is it about radiosity ?
I did read thread from start before i made that stupid post earlier but now i have no idea whats on topic.
Radiosity is a part of SM3.0 ?

---

No radiosity is not part of sm3.0, however since shadow brought it up, that the r520 could also do it, we got into a discussion about it. The main point of it however is that developers are amazed at how the 7800gtx can pull it off in realtime. The argument was over about if developers hated the 7800gtx like shadow says or not.

Quote:

---

P_1, please edit your post, as I promise you perkam is going to in about 15 - 20 minutes, and it won't be in a nice manner.

---

Quote:

---

Perkam, please don't PM me for this... it was not inteded as flaming.

---

Relax gentlemen. As long as you're aware of what is and what isn't proper forum behaviour (as you've shown by editing your posts) I have no intention of disrupting this very interesting discussion.

Pls continue, but with one thing in mind: once you're willing to make a statement about what a company has and what it doesnt, be prepared to back it up, but do not judge the company based on it even if you do...leave the readers to come to a conclusion ;) There will be no mention of radiosity here though, as there is a seperate thread on this.

I just wish someone could show us a graphical (whether its fps or image quality) difference with vs without VTF (not necessarily ATI vs Nvidia).

P.S. ShadowMage is the reason this thread has re-opened, so lets keep everyone's positive intentions in mind here.

Perkam

Can someone running a 7800GTX try Pacific fighter at 1600x1200 and turn it on and off and see what happens with FPS ?
As i understand its the only game that use this feature.