More ATI Missing Vertex Texture Fetch Info

[pxc]

Thanks. There you have it. Discussion over. Case closed.

Actually MS frowns on falsely enabling hardware caps bits. But it is case closed for all but the "ATI true believers"... ATI doesn't support a feature that's part of the VS3.0 spec. Even ATI doesn't deny that, they just tried to downplay it and offer a work-around.

It's laughable that the few believe it's optional even though MS's spec doesn't call it optional.

 

[eno-on]

I really want to know. If a certain part of an API, certain instructions, can be done by a 'generic' unit, i.e. one that can be programmed to do anything, then does that part meet API specs, if said instruction is made to be done in drivers on the hardware?

 

[John Reynolds]

For those who don't know what I'm referring to when I say caps, read more here: http://msdn.microsoft.com/library/d...irectx/directxsdk/Tools/System/capsviewer.asp

 

[OldBoy]

At least you realize that asking MS and ATI is not childish. We can disagree on the questions.

Continue your spamathon.

Nice try.

 

[OldBoy]

Actually MS frowns on falsely enabling hardware caps bits. But it is case closed for all but the "ATI true believers"... ATI doesn't support a feature that's part of the VS3.0 spec. Even ATI doesn't deny that, they just tried to downplay it and offer a work-around.

It's laughable that the few believe it's optional even though MS's spec doesn't call it optional.

It's laughable when you try to tell the people who have written the spec what their spec actually entails

 

[pxc]

It's laughable when you try to tell the people who have written the spec what their spec actually entails

I'm siding with MS. I don't know where the apologists are getting their interpretations from. MS didn't include what you and the other apologists claim.

Point out anywhere in the VS 3.0 spec that says vertex texture fetch is optional. I've been waiting since yesterday. Even ATI's GDC presentation (page 4) linked in the first post of this thread supports MS's documentation.

 

[tranCendenZ]

I don't know where the apologists are getting their interpretations from. MS didn't include what you and the other apologists claim.

Humus (an ATI employee) stated it is "optional" on the R3D and B3D forums. That is where they are getting the interpretation from specifically.

 

[OldBoy]

I'm siding with MS. I don't know where the apologists are getting their interpretations from. MS didn't include what you and the other apologists claim.

Point out anywhere in the VS 3.0 spec that says vertex texture fetch is optional. I've been waiting since yesterday. Even ATI's GDC presentation (page 4) linked in the first post of this thread supports MS's documentation.

Nice try again. You trying to label people who don't agree with you apologists is pretty weak. Either way, MS says it meets specs (as was pointed out above.) You say it doesn't. It's not really a hard choice on who to go with.

If you feel that you actually know more than MS, then head on over to Beyond3D.com and share your opinion. I'm sure the people on those forums can clarify things.

Ultimately, this whole discussion is a waste of time if this feature is never used on any games or only on a handful of games. Similarly, even if it is used in games, if ATI's methods yield identical or superior results to nvidia's implementation then the whole discussion was pointless from the beginning.

 

[pxc]

Humus (an ATI employee) stated it is "optional" on the R3D and B3D forums. That is where they are getting the interpretation from specifically.

Yeah, i figured as much.

It seems so simple. There are parts of SM2 that are optional and MS clearly states that in the DX9 documentation. If VTF is optional, then why can't anyone point it out in the VS3.0 documentation? I can't even find anything in my Microsoft Press and Apress DX9 books, or in the 9.0c SDK docs that states VTF is optional.

 

[pxc]

Either way, MS says it meets specs (as was pointed out above.) You say it doesn't. It's not really a hard choice on who to go with.

You don't seem to understand how a driver reports caps from that statement.

 

[OldBoy]

Yeah, i figured as much.

It seems so simple. There are parts of SM2 that are optional and MS clearly states that in the DX9 documentation. If VTF is optional, then why can't anyone point it out in the VS3.0 documentation? I can't even find anything in my Microsoft Press and Apress DX9 books, or in the 9.0c SDK docs that states VTF is optional.

Well, if it isn't optional then how come MS's own software states that the X1800 fully meets SM3.0 spec?

 

[OldBoy]

You don't seem to understand how a driver reports caps from that statement.

I don't even proclaim to understand this whole area. I'm simply going by what MS's software says. If it says pass it's a pass. Just because you don't like how it passed doesn't mean it didn't pass.

 

[kcthebrewer]

Yay, we are back to the pluses after standards!

Everyone remember SM2.0+ that the FX series released, and then ATI's 9x00 SM2.0++?
Yay for more consumer confusion!

Also, Oldboy, provide links/C&Ps for your statements. You are coming across as you acting like you are the person that wrote the SM3.0 specs and it isn't very becoming.

 

[tornadotsunamilife]

Yay, we are back to the pluses after standards!

Everyone remember SM2.0+ that the FX series released, and then ATI's 9x00 SM2.0++?
Yay for more consumer confusion!

Average run of the mill consumer don't gove a damn, show them how much vram a cards got and they're sold

 

[kcthebrewer]

Average run of the mill consumer don't gove a damn, show them how much vram a cards got and they're sold

What do you mean my 512MB Geforce 6200 isn't the shiznit?

(no I don't own one)

 

[pxc]

Well, if it isn't optional then how come MS's own software states that the X1800 fully meets SM3.0 spec?

Because ATI's drivers are reporting a feature/capability that the hardware doesn't support. An actual query to IDirect3D9::CheckDeviceFormat with the D3DUSAGE_QUERY_VERTEXTEXTURE mask (see this) returns nada according to dave b in the x1800 review.

Remember, ATI admits that the R520 does not support VTF. But they are reporting it in caps. Why would they do that if it were "optional"?

 

[poley]

Firstly let me say this, I've had both Ati and Nvidia hardware in my computer over the years, the last two have been an ti300 and a 6800gt. I'm just interested in how industry is developing because in a year or so I'm going to upgrade and its useful to keep track, plus its a great laugh reading the flame wars..

I currently side with no one company but I'm starting to feel Ati is getting a real hammering over this feature and there isn't really any justification for it (the hammering that is). This especially seems to be the case at [H] when comparing to other sites.

As for my background in all this....well I normally stay clear of the graphics forum because of threads like this, I'm quite happy to lurk in the watercooling section, however, I'm doing my postgrad in Physics currently right now (in London) and I've spent a lot of time reading technical design reports and the like, hence I've spent some time at beyond3d reading up on all this, but this in no way makes me an expert.

I'll just link to this post at b3D, if you follow the links and read up it should clear up a few things.

http://www.beyond3d.com/forum/showpost.php?p=589394&postcount=2

here's the important quotes

When ATI sat down and started looking at SM3.0 several years back and looked at what would be required to make Vertex Texturing perform well and decided the costs weren't worth it (we're not talking about a broken implementation here, but a design decision) - NVIDIA appear to have implement it in a basic "meet the spec" fashion, the net result is that few, if any, developers have taken up on it because its slow, which is what ATI has decided when they designed it.

this from this article

However, one element of Vertex Shader 3.0 compliance is the capability for vertex texturing, yet there appears to be an absence of any texture lookup capabilities from ATI's diagrams above; a curious loophole of the VS3.0 specification is that although the capability bit for Vertex Texture capabilities must be enabled for compliance, there are no actual texture formats dictated for support, so if the capability bit is enabled but no texture formats exposed VS3.0 compliance can still be met - indeed this is the case with R520 as it has no direct vertex texturing capabilities. ATI's statement is to engineer Vertex Texturing in a non-unified architecture to a point were it is actually usable and beneficial would require so much die for extra texture caching and other associated elements to reduce the texture latency costs, it would be very costly for the frequency that it is likely to be used, and that cost would have inevitably come at the detriment to something else; instead ATI are looking to leverage the pixel pipeline more for such vertex operations.

Admittedly Ati seem to have used this loophole to save them some cash, however I feel it is justified when considering that there exists only one game that currently uses it and judging from the responses from dev's at b3D (in various threads) with regard to this issue this is unlikely to change a great deal and even if it does, the developers that will use it will be the type who will have the resources and time to ensure the effects also work on the x1000 series.

R2VB or Render to Vertex Buffer, is Ati's way of enabling the feature (so that dev's can simulate VTF ), its technically speaking a hack and is unlikely to be supported by MS as a certified feature of SM3.0 until DX10 by which time there may not even be a need for such things as Ati and Nvidia are both moving towards unified architecture's which will have their capabilities controlled more through software than hardware, partly seen in the R500...

also something that may interest some people in relation to the delays and why they happened...

the issue was eventually traced it had occurred not in any of ATI's logic cells, but instead in a piece of "off-the-shelf" third party IP whose 90nm library was not correct. One the issue was actually traced, after nearly 6 months of attacking numerous points where they felt the problems could have occurred, it took them less than an hour to resolve in the design, requiring only a contact and metal change, and once back from the fab with the fix in place stable, yield-able clock speeds jumped in the order of 160MHz.

aside from all that techno mumbo-jumbo it looks like a good fight between ati and nvidia this round, ati seemingly having the better spec's and performance (in most games) along with better AF and AA but nvidia having a good headstart, better form-factor and SLI up and working from the start.

 

[Attean]

ATi's next architecture should take a unified approach so I don't think you'll ever see a vertex texture fetch in any of their cards - but that's not a bad thing. I don't even think nVidia will have it if G80 is unified. I don't even know why people like you are harping on this issue when it's not a big deal. Besides PF, no game on the market utilizes displacement mapping so why make a big deal about it?

Valve is supposedly working on displacement mapping. They have the guy who pretty much invented it working on implementing it in real time.

 

[OldBoy]

Because ATI's drivers are reporting a feature/capability that the hardware doesn't support. An actual query to IDirect3D9::CheckDeviceFormat with the D3DUSAGE_QUERY_VERTEXTEXTURE mask (see this) returns nada according to dave b in the x1800 review.

Remember, ATI admits that the R520 does not support VTF. But they are reporting it in caps. Why would they do that if it were "optional"?

Couldn't tell you. I think only MS can answer this one. Somebody obviously needs to ask is the following:

Per your own program ATI's X1800 GPU is SM3.0 fully compliant. However, the GPU doesn't feature VTF. Is the software reporting full compliance incorrectly?

 

[OldBoy]

Firstly let me say this, I've had both Ati and Nvidia hardware in my computer over the years, the last two have been an ti300 and a 6800gt. I'm just interested in how industry is developing because in a year or so I'm going to upgrade and its useful to keep track, plus its a great laugh reading the flame wars..

I currently side with no one company but I'm starting to feel Ati is getting a real hammering over this feature and there isn't really any justification for it (the hammering that is). This especially seems to be the case at [H] when comparing to other sites.

As for my background in all this....well I normally stay clear of the graphics forum because of threads like this, I'm quite happy to lurk in the watercooling section, however, I'm doing my postgrad in Physics currently right now (in London) and I've spent a lot of time reading technical design reports and the like, hence I've spent some time at beyond3d reading up on all this, but this in no way makes me an expert.

I'll just link to this post at b3D, if you follow the links and read up it should clear up a few things.

http://www.beyond3d.com/forum/showpost.php?p=589394&postcount=2

here's the important quotes



this from this article



Admittedly Ati seem to have used this loophole to save them some cash, however I feel it is justified when considering that there exists only one game that currently uses it and judging from the responses from dev's at b3D (in various threads) with regard to this issue this is unlikely to change a great deal and even if it does, the developers that will use it will be the type who will have the resources and time to ensure the effects also work on the x1000 series.

R2VB or Render to Vertex Buffer, is Ati's way of enabling the feature (so that dev's can simulate VTF ), its technically speaking a hack and is unlikely to be supported by MS as a certified feature of SM3.0 until DX10 by which time there may not even be a need for such things as Ati and Nvidia are both moving towards unified architecture's which will have their capabilities controlled more through software than hardware, partly seen in the R500...

also something that may interest some people in relation to the delays and why they happened...



aside from all that techno mumbo-jumbo it looks like a good fight between ati and nvidia this round, ati seemingly having the better spec's and performance (in most games) along with better AF and AA but nvidia having a good headstart, better form-factor and SLI up and working from the start.

Nice. I actually understood all that

 

[5150Joker]

Simple answer is this: Does MS object to ATi not having a VTF and being compliant through R2VB? If the answer is yes, then arguing about whether or not its optional is pointless and just leads to circular arguments from both sides. As long as MS allows it, then it's fine.

 

[tranCendenZ]

Couldn't tell you. I think only MS can answer this one. Somebody obviously needs to ask is the following:

Per your own program ATI's X1800 GPU is SM3.0 fully compliant. However, the GPU doesn't feature VTF. Is the software reporting full compliance incorrectly?

Demirug (of 3dcenter.de fame, home of the optimization-finders ) has an interesting point:

If you look at the caps that a R520 reports you will see that it tell you it can use a point filter for vertex fetch. Nice. It don’t have a useable format but it supports filter. This looks unreasonably but there is a good reason why the driver do this. The DDK says that if your driver say that it support VS 3.0 it have to report at least point filter for vertex texture. IF it was ever planned to make vertex fetch an optional feature it makes no sense to add this demand to the DDK. It would be more easy to say: “If you don’t support vertex fetch report no filter for vertex texture.” In this case a developer can check the filter caps and don’t need to check every texture format to find that none of them supports vertex fetch.

He basically concludes that though ATI is "technically" in spec, it is only a "backdoor," not something that was intended based on the rest of the document. He also refers to ATI's workaround as a "hack." In other words, ATI was able to pull a fast one due to poor wording. In this case Demirug points out, ATI is reporting it can use a point filter for vertex fetch, but it can't actually do vertex fetch in the first place - yet ATI needs to report this in order to be "technically" in spec.

 

[OldBoy]

Demirug (of 3dcenter.de fame, home of the optimization-finders ) has an interesting point:



He basically concludes that though ATI is "technically" in spec, it is only a "backdoor," not something that was intended based on the rest of the document. He also refers to ATI's workaround as a "hack." In other words, ATI was able to pull a fast one due to poor wording. In this case Demirug points out, ATI is reporting it can use a point filter for vertex fetch, but it can't actually do vertex fetch in the first place - yet ATI needs to report this in order to be "technically" in spec.

lol, very nice.

 

[BBA]

Link Here is Nv support. Also not so perfect, I guess.

Thats a pdf describing Opengl 2.0 support in nv4 video cards.

Can you elaborate on what exactly you are talking about please? Give specifics or quotes.

 

[pxc]

Simple answer is this: Does MS object to ATi not having a VTF and being compliant through R2VB? If the answer is yes, then arguing about whether or not its optional is pointless and just leads to circular arguments from both sides. As long as MS allows it, then it's fine.

Yep, there's no point to arguing it. I'm sure the hoopla will generate a MS response soon to put this to rest.

It would be unfortunate if MS caves to pressure from ATI, but who can really know how or why MS will decided either way.

 

[tranCendenZ]

Yep, there's no point to arguing it. I'm sure the hoopla will generate a MS response soon to put this to rest.

It would be unfortunate if MS caves to pressure from ATI, but who can really know how or why MS will decided either way.

One thing I learned is that MS never seems to cave. That being said, their spec really isn't as clear cut as it should be, so maybe they should cut ATI some slack. On the other hand, ATI clearly knew that they weren't following what the spec intended when they didn't include vertex texture fetch, so who knows.

 

[Rollo]

So, since you're so knowledgeable why aren't you heading over to the Beyond3D.com forums and pitching in your 2 cents? Wanting to discuss it on a forum where hardly anyone (if anyone) understands the issues present seems like a recipe for something else altogether

What are you? The forum police?



In my thread you say I'm not welcome here, in this thread you tell Prime1 to go to B3d?

Who gets to stay in your little dictatorship, and why do you get to call the shots here? I see no "Mod" designation under your name?

 

[computerpro3]

What are you? The forum police?

No, I'm the forum police!

 

[Jima13]

Thats a pdf describing Opengl 2.0 support in nv4 video cards.

Can you elaborate on what exactly you are talking about please? Give specifics or quotes.

To summarize: the hardware supports only one-channel and four-channel FP32 textures. It does not support FP16 textures. It does not support any "traditional" integer texture formats. You may only use 2D and 1D textures. No cube maps, no 3D maps.

There's no filtering ... but you can have point sampled mipmapping. For that you need to compute explicit lod bias to sample beyond mip level 0 as there's no concept of texture minification and magnification on vertices.

This, folks, is the feature set of the "legit" vertex texturing implementation on NV40 and G70. Good luck finding a reasonable use case for this. And much better luck finding a reasonable use case that is also not more elegantly handled with render-to-vertex-buffer (not using R2VB as I don't wish to refer to ATI's whatever-it-is specifically).





http://www.beyond3d.com/forum/showpost.php?p=590773&postcount=90

 

[John Reynolds]

I'm just wondering when we'll see a front-page news blurb from Brent stating how neither company really supports this "major SM3.0 feature" very well. And hopefully this one would actually be written entirely by Brent.

 

[R1ckCa1n]

I'm just wondering when we'll see a front-page news blurb from Brent stating how neither company really supports this "major SM3.0 feature" very well. And hopefully this one would actually be written entirely by Brent.

That would be like admitting the X1800XL is available @ retail right now and isn't a paper launch. I started to hold my breath and almost passed out.

Missing feature or not, the X1800 displays wonderful 3d.

 

[Digital Viper-X-]

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.

nobody read this? it seems it is faster doing it with R2VB

 

[Sly]

Point out anywhere in the VS 3.0 spec that says vertex texture fetch is optional.

Has anybody answered to this yet?

 

[Apple740]

Has anybody answered to this yet?

Quote from Demirug on Nvnews;

"ATI don't suport Vertex Texturing but they can still claim 100% SM3. Unfortunately there is a little hole in the DX spec that make this possible.

As long as Microsoft don't close it no one can stop ATI to tell everbody that they have SM3 hardware. As microsoft already working hard on the next Direct3D version I don't believe that we will see this spec change. But even if this change will happen in the future ATI can still use an workaround in the driver to get vertex texture run in a way that is conform.

Anyway the worst thing that can happen ist that new games will not run on X1x000 Hardware out of the box. But this should be discovered at least in a test before it go gold. Developers than need to go back and fix it. No harm for the gamers."



As you can read on Beyond3d, Ati does a workaround with r2vb, and considering that 7800 cards are slow in vtf and not supporting the whole thing either, this whole thing looks like a non-issue.

 

[PRIME1]

Quote from Demirug on Nvnews;
As you can read on Beyond3d, Ati does a workaround with r2vb, and considering that 7800 cards are slow in vtf and not supporting the whole thing either, this whole thing looks like a non-issue.

I have not seen any benchmark that shows the 7800 slow using VTF. That's pure FUD. Nor has there been any OFFICIAL statement made regarding ATI not including part of the SM3.0 spec. So until an official statement is made, it's more a matter of opinion whether they "fully" support the spec or not. Considering a lot of people at Beyond3D are calling ATI's implementation a "hack", I'm not so sure they will get official support.

 

[SnakEyez187]

I have not seen any benchmark that shows the 7800 slow using VTF. That's pure FUD. Nor has there been any OFFICIAL statement made regarding ATI not including part of the SM3.0 spec. So until an official statement is made, it's more a matter of opinion whether they "fully" support the spec or not. Considering a lot of people at Beyond3D are calling ATI's implementation a "hack", I'm not so sure they will get official support.

So essentially it's a non-issue? Cool.

 

[PRIME1]

So essentially it's a non-issue? Cool.

Well, if the next gen SM3.0 games use VTF, the ATI cards will take a performance hit.

 

[tornadotsunamilife]

Well, if the next gen SM3.0 games use VTF, the ATI cards will take a performance hit.

You know this how? You're presuming...

 

[pxc]

Well, if the next gen SM3.0 games use VTF, the ATI cards will take a performance hit.

Not necessarily a performance hit. Most likely it will just not show the effects linked to VTF. No one is going to code the workaound into a game if the x1800 refresh (R580?) includes VTF.

 

[tornadotsunamilife]

No one is going to code the workaound into a game if the x1800 refresh (R580?) includes VTF.

I don't see why not, from what I see unified architectures doesn't need VTF anyway and that's the direction that ati is moving in (if not nvidia also)