GeForceFX and displacement mapping?

I find that bit of info interesting re:gf3-being fully DX6 compliant, didn't know that. BTW when are the Bit Boys going to have a DX9 compliant card? Surely they could cough one up for Christmas?

EDIT:don't answer that.

 

They do not have any plans for PC-market.
chip codenamed Hammer was the last thing for PC-market they had on R&D, but it got scrapped on last spring. It was planned to come out about right now, but it really doesn't matter anymore.

SVG core based PDA / Cellular products should be _possible_ on Q1/2003. I have no information about mysterious customer that is mentioned on their pages.

and btw, 1997 designed Pyramid3D (model TR25203) didn't fall behind much to be DX8 compliant. (some parts were much more programmable than DX8 allows, but on amount of registers at PS, P3D falls a bit behind of specs. their fixed point programmable HW T&L had unlimited program lenght and it supportted jumps, branches and sub routines. whole pipelline worked always in 32 bits and then dithered result to 24 bit or 16 bit. memory controller had 2 working modes; One and two channel mode. it also supported some sort of simple HSR done in PS. ) If someone doesn't believe, I can post a link to Hardware Reference Guide. it's a nice book for night reading: over 250 pages.

 

This caught my eye: (from the B3D interview)

That reads to me "we used more transistors to make dedicated hardware for each type to optimize performance for 32-bit integer and FP16."

Does anyone else read it that way?

 

[joke mode]Man.... you know more about the Bit Boys then .... anyone. Even them..[/joke mode] hehe.

 

Just let everyone know that I updated my previous post.

[joke mode] Are you sure that I am NOT also them?[/joke mode]

 

[action]shaking head[/action] Your right .... I could be speaking with the infamous Bit Boys all in one....

 

Not that I don't believe you or anything of the sort man but if posting that link is not much trouble I would take a peek.

 

Isn't the NV30 supposedly using register combiners. This along with the good old tmu would mean legacy support for the current software. I am pretty sure they do not have an extra hardwired pipeline, that would be a waste.

 

Well, it does indeed look like nVidia is fully supporting Displacement Mapping. The information is at a number of websites.

Regardless, I'd actually be surprised if Displacement Mapping caught on significantly. I'm still expecting implementations more similar to Bezier patches to catch on more (Though it seems apparent now that Bezier patches themselves won't catch on...). That is, HOS information is encoded into the data sent to the GPU when sending the vertices, not in a texture.

 

Chalnoth you crack me up...I mean seriously do you sacrifice some kind of small critter for this company too.
Back Pedal....you stated on this forum and Nvnews prior tp the 9700 launch was the NV30 will be far more advanced than a 9700..so far it doesn't look that way.

I stated back then bold words and I stand by that statement, Displacement mapping not worthwhile..

 

Characters are not the best thing to to do DM on, DT

 

Talk to Matrox.

 

All of this talk criticizing Nvidia's support for DM presupposes that ATI actually supports a bug-free, high quality, high performance (read: not emulated by CPU or HAL) implementation.

However, we don't have any facts in this case.

#1 ATI isn't pushing it, or promoting this feature in their PR or development events. At Mojo day, only Microsoft's presenter even discusssed it.

#2 ATI's beta drivers from a month ago said it wasn't implemented (yet?)

#3 We have no DX9 samples in the DX9 SDK to even test DM. In fact, there's not even one for REFRAST!

#4 ATI's registered developer site doesn't have any either, but has plenty of other demos for specific ATI features

#5 ATI's DX9 driver reports in driver caps that it doesn't support any of the DM modes EXCEPT pre-sampled displacement maps, which means no adaptive tesselation, and this doesn't accomplish anything that can't be done by a VS2.0 vertex shader.

So, right now, we have no real evidence that full DX9 DM is supported in HW on the R300. In fact, we don't even have any evidence if it can do Parhelia level DM.

I say, talk about DM should wait until #1 their driver reports that they support DX9 DM fully and #2 there are demos that demonstrate speedy, bug-free, HQ artifact free, usage of this feature.

Otherwise, it's one of those OEM checkboxes that don't mean anything in the real world.

If it's merely done by the CPU, than this isn't really any different than what can be done today with software vertex processing.

In other words: It's premature for f*nb*ys to start condemning NVidia for not supporting a feature that neither Microsoft nor ATI have demonstrated working support for yet.

 

@DemoCoder,

agreed. AFAIK, only the Parhelia has implemented DM to the full, adaptive extend.

@all,

DigitLife had to say the following regarding DM on NV30:

So--seems to support adaptive DM, depending on how NV will implement DM using their VS2+ hardware . . .

ta,
-Sascha.rb

ta,
-Sascha.rb

 

I believe only parhelia and P10 (?) do displacement mapping in HW. R300 and NV30 do not. Those specs are just DX9 specs, with software fallbacks. Features like continuous tessellation in HW are definitely not in any chip other than Parhelia. Yet, everyone claims to do it, even though they handle it with the DX9 SW path.

 

I'm sure the 9700 supports N-patches or Truform II so hardware tesselation is there (been there in some form since the 8500) and they state displacement mapping clearly on their site.

TRUFORMâ„¢ 2.0
2nd generation N-Patch higher order surface support
Discrete and continuous tessellation levels per polygon
Displacement mapping

http://www.ati.com/products/pc/radeon9700pro/specs.html

 

DemoCoder,

Among the R300 launch presentations at their site was a very specific graphical demonstration of atleast adaptive tesselation. Of course your comments about an actual demonstration of it working in hardware stands, but they have already quite clearly stated atleast that functionality. As for displacement mapping, I don't have a specific and very clear image in mind from the presentation (and can't find them at ATI's site) so I won't comment. EDIT2: Here they are,and displacement mapping is listed very specifically. Of course this is not an actual real demonstration, but it is an ATI presentation stating that the R300 supports the feature. See my comments below on this not being exposed in DX 9 yet.

I don't think getting a response from nVidia stating the nv30 does not support displacement mapping (!!) and then being surprised and concerned warrants a label of "ATI fanboi" at all, and your doing so strikes me as a bit more than silly.

This isn't to say the rest of your points about the lack of a demonstration from ATI are not justified, but your comments in this regard seem to point directly at this being a matter of DX 9 simply not being ready to expose the feature. I presume that Matrox has DX 9 beta drivers exposing this for you to make this contrast? While it is pretty clear the Parhelia without question can do displacement mapping, I don't think any card not exposing it in DX 9 right now is a reasonable metric of whether it can as well, and certainly not comparable to the apprently direct statement from nVidia concerning this.

That said, a simple response from some ATI person familiar with the issues at hand would clear that part up pretty easily (hint hint), unless they can't speak on it for some reason.

Your entire reasoning seems flawed...if ATI can't do displacement mapping in hardware, that would mean ATI should be looked on equally badly and with as much surprise as nVidia is for this comment, not that nVidia should not. I am still amazed when reasoning like this crops up, but I do have to admit it is just my own opinion...

One thing that could be causing confusion IMO is if something about the DX 9 spec is expected to change...like changing it (EDIT: displacement mapping) to something that requires PS/VS 3.0 functionality. Does that make sense at all to anyone? (I'm still having trouble thinking things are as simple as "nv30 has no displacement mapping functionality", so forgive me if it is a hare-brained theory ).

 

If they told you that DM is all that usefull for characters, they lied.I think that you have seen their DM demos, and the characters that are DMed lack in many aspects, especially in refined detail.

 

Compared to what? My only view on displacement mapping on characters is superiority in silhouette to bump mapping. You are going further and seem to be implying it is inferior for detailing than bump mapping...do I read you correctly?