Wreckage
Banned
- Jul 1, 2005
- 5,529
- 0
- 0
rbV5
Lifer
- Dec 10, 2000
- 12,632
- 0
- 0
Are we just picking on ATI? or ignoring the fact that accordng to my October 2005 DirectX card capabilities chart from Microsoft, there are no parts that support 100% of DX9 including NV 7800x, far from it in fact.
Looks to me like compromises have been made from every GPU manufacturer, and there is alot of DX API unsupported in hardware in even the newest cards.
Looks to me like compromises have been made from every GPU manufacturer, and there is alot of DX API unsupported in hardware in even the newest cards.
Wreckage
Banned
- Jul 1, 2005
- 5,529
- 0
- 0
I looked at that chart. the 6800 and 7800 met or exceeded all SM3.0 functions for DirectX9. The X1xxx series from ATI was not even listed.
The 6xxx and 7xxxx series cards using 7x.xx series drivers and up are DirecX 9.0c compliant. No available ATI cards are.
Todd33
Diamond Member
- Oct 16, 2003
- 7,842
- 2
- 81
I'm not sure why some guy with no experience in GPUs, other than benchmarks would need to draw any conclusions. It makes no difference how something is done in hardware, as long as the calls from the API result in the same answer. So unless he knows something about the r520 hardware that would result in "performance penalty" or knows about writing drivers, he should not say "require special consideration from developers".
People on the Internet love to speak out of their a$$.
rbV5
Lifer
- Dec 10, 2000
- 12,632
- 0
- 0
You'll also notice that many of DirectX capabilities are unsupported, for instance vertex texture filtering, with 7800 only 3 of 12 capabilities are exposed with drivers.....Why do you suppose that is? Could it be that Nvidia felt that only 3 of them were needed for now, and that fully supporting all of DX9's vertex filtering capabilities would waste critical die space on functionality that would go unused? Thats my guess, and thats my guess as to why ATI decided that vertex texture fetch was too expensive for the benefit.
I guess we'll see going forward, but clearly there have always been compromises for hardware API support. My guess is that new ATI cards get listed, they will show the same SM3.0 support moniker as the nvidia cards despite differences in API support.
crazydingo, actually I was wrong. Apparently Pacific Fighters makes use of vertex textures. I found this out from an older thread at B3D that was recently linked, but that nVidia page that Wreckage linked proves it.
dnavarro, again, virtual is not the same thing as displacement mapping. The former is a pixel shader effect (read: an optical illusion of depth on a flat surface, just like the excellent parallax occlusion mapping in ATI's R520's Toy Shop demo), while real displacement mapping creates geometry (read: real bumps).
malG, the bottom line is actually what Humus said (and ATI confirmed that MS is OK with): R520 is technically in SM3 spec. And they can do the equivalent of vertex texturing using their R2VB fourcc implementation.
Tod33, the special consideration is that vertex texturing on R520 is currently expected to be supported with a workaround, so devs will indeed need to pay special attention to see if the GPU uses either the expected SM3 bit or ATI's R2VB fourcc workaround. ATI did the same with geometry instancing and their SM2 series, AFAIK.
dnavarro, again, virtual is not the same thing as displacement mapping. The former is a pixel shader effect (read: an optical illusion of depth on a flat surface, just like the excellent parallax occlusion mapping in ATI's R520's Toy Shop demo), while real displacement mapping creates geometry (read: real bumps).
malG, the bottom line is actually what Humus said (and ATI confirmed that MS is OK with): R520 is technically in SM3 spec. And they can do the equivalent of vertex texturing using their R2VB fourcc implementation.
Tod33, the special consideration is that vertex texturing on R520 is currently expected to be supported with a workaround, so devs will indeed need to pay special attention to see if the GPU uses either the expected SM3 bit or ATI's R2VB fourcc workaround. ATI did the same with geometry instancing and their SM2 series, AFAIK.
And ATi did GI with far less of a performance hit with their workaround. So maybe it might be this way with the vertex fetch workaround too?
Already known sometime now
From my post b4 5/10 in this thread..
But ATI has other problems which will make game developer life a pain in the a$$
1.ATI lacks severely in ALU throughput.(you see 24 against 16 ... )
2. ATI doesn't support FP16 filtering.
3. ATI doesn't support vertex texturing into the vertex shaders.(They will have to make tricks to do it dumping it into a pixel buffer and let then the fragment shader do the texturing)
Those three points as I said will make their lives a pain in the a$$, since they will have to write different paths for ATI to implement them...
From my post b4 5/10 in this thread..
But ATI has other problems which will make game developer life a pain in the a$$
1.ATI lacks severely in ALU throughput.(you see 24 against 16 ... )
2. ATI doesn't support FP16 filtering.
3. ATI doesn't support vertex texturing into the vertex shaders.(They will have to make tricks to do it dumping it into a pixel buffer and let then the fragment shader do the texturing)
Those three points as I said will make their lives a pain in the a$$, since they will have to write different paths for ATI to implement them...
jim, I don't understand your first point at all. They have 16 pipes, but they're obviously clocked much higher, and apparently they're more efficient. (And there are actually two ALUs per pipe in the G70, and "1.5" in the R520, so it's more like 48 vs. 24--ignoring clock speeds and efficiency.)
Devs would probably be more handicapped by the huge amount of less-than-amazing hardware on teh market, like X300s and 6200s. And in fact the X1600XT looks to be amazing in its segment, what with 12 pixel "pipes" running at 590MHz. That is, if ALUs were all that mattered, which X1600XT vs. 6600GT/6800 benchmarks indicate is not the case with most current games....
Devs would probably be more handicapped by the huge amount of less-than-amazing hardware on teh market, like X300s and 6200s. And in fact the X1600XT looks to be amazing in its segment, what with 12 pixel "pipes" running at 590MHz. That is, if ALUs were all that mattered, which X1600XT vs. 6600GT/6800 benchmarks indicate is not the case with most current games....
Pete I didn't say that this will affect the overall performance, or that XT is not efficient, I just stated the fact..
In the most gpu limited resolution 2048x1536 though XT and GTX have almost identical performance
Doesn't that say anything?Yes, but your fact is, on its face, incorrect in one of two ways. R520 is either not "severely" lacking considering clocks, or you forgot that clockrate is half of the throughput equation. I guess you meant to say per-clock rather than throughput, in which case, yes, it's lacking in that one, almost completely context-less detail. So I don't see how that fact would make developer's lives a PITA any more than G70 doubling the number of MADDs per pipe compared to NV40 or R420.
As for 20x15 numbers, I'm reading the TrustedReviews article now. The peformance isn't identical per game, but I see it's roughly even overall. Not sure what that's supposed to say, though, as they have a rather limited benchmark set, and there's something odd about their Far Cry numbers (severe CPU limitation, despite their FX55).
As for 20x15 numbers, I'm reading the TrustedReviews article now. The peformance isn't identical per game, but I see it's roughly even overall. Not sure what that's supposed to say, though, as they have a rather limited benchmark set, and there's something odd about their Far Cry numbers (severe CPU limitation, despite their FX55).
Originally posted by: jim1976
Pete I didn't say that this will affect the overall performance, or that XT is not efficient, I just stated the fact..
In the most gpu limited resolution 2048x1536 though XT and GTX have almost identical performance
Yea 16 pipes going up against 24, and is gettting identical number. Whats the 24 or 32 piped ones gonna be like!
Also from what Xbit have just posted up on their website on the benchmarks, they say the X1800XT and downwards have "the most efficient Shader Model 3.0 implementation on the PC to date"
I dont know where your gettin ghte 1.5 ALUs for the R520 and 2 for the 7800GTX. Because if im correct and researched everything right the X1800 has 2 ALUs with 2 Vector ALUs in 1 and 2 Scalar units in the other. These are fully featured ALUs. While the 7800GTX the 2 ALUs that they use are not fully featured. While The X1800 has a MADD and MULL unit inside each ALU the 7800GTX only has 1 MADD unit in 1 ALU while the other contains a MULL unit. But with the 7800GTX they have hadded 1 more of each i think now.
And here is a bit from B3D on whats happening with their Vertex Texture.
"Part of the point of vertex texturing is to be able to expose pixel format data to the vertex shader, and as somewhat of an alternative to Vertex Texturing ATI will be promoting the use of a new extension to DirectX known as Render to Vertex Buffer. As the name implies Render to Vertex Buffer (R2VB) allows all of the operations within the pixel shader to be utilised, but rather than rendering to a displayable surface or texture the results are rendered to a buffer in memory that can be directly read as an input to the vertex shader. The upshot of this process is that an application can have access to the capabilities of the Pixel Shader which can then be fed back into the geometry processing pipeline, which should result in a superset of capabilities of vertex texturing and should actually perform better than current vertex texturing schemes because the pixel pipelines are inherently built to cope with, and hide texture latencies."
IT seems that this way is much better for this gens cards as it will be a faster than the current stuff that the vertex texturing has to use. And ATi said they will have implemented this feature in the unified architecture in their R600.
Yes but I dont see your point either; making a mountain out of a mole hill. :roll:
R520 passed SM3 spec.
It may be optional, but if the developer chooses to implement it, ie. Unreal3, then doesnt that make R520 suckers up sh1t creek without a paddle?
Well Unreal3 also makes heavy use of dynamic branching where the R520 is 60-70% better than G70.
CrystalBay
Platinum Member
- Apr 2, 2002
- 2,175
- 1
- 0
First of all, not all cards on the market are VS3 to begin with. Secondly, do you think Epic will spend time making a feature integral to its game knowing that half the market won't support it? Thirdly, apparently ATI can support it, and can do so in a way that the dev wouldn't know that they're not using vertex hardware for the texturing. So this may indeed be making a mountain of a molehill. I guess it depends on ATI stepping up to the plate.
But I don't recall competing architectures from ATI or nV having equal featuresets for quite some time, so I don't think this will be anything new to developers.
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 Discussion Threads
- Started by Tigerick
- Replies: 21K
-
Discussion Intel current and future Lakes & Rapids thread- Started by TheF34RChannel
- Replies: 23K
-
-
Facebook
Twitter