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.
 
Sabastian said:
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? ;)

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. :)
 
demalion said:
OK, 125 million transistors...dropping displacement mapping....those feature tradeoffs as outlined in the R300 versus NV30 article are where those ~15 million transistors went?!

This caught my eye: (from the B3D interview)

We have native support for 32-bit integer, which is how we get the performance on the older apps. If we were to run them as FP16 then they wouldn't run as fast. So we have dedicated hardware with native support for 32-bit per pixel integer, 64-bit per pixel floating and 128-bit per pixel floating.

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?
 
Just let everyone know that I updated my previous post. ;)

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

[joke mode] Are you sure that I am NOT also them?[/joke mode] ;) :D
 
Nappe1 said:
Just let everyone know that I updated my previous post. ;)

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

[joke mode] Are you sure that I am NOT also them?[/joke mode] ;) :D

[action]shaking head[/action] Your right .... I could be speaking with the infamous Bit Boys all in one.... :eek: :LOL:
 
Nappe1 said:
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. :)

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.
 
I'd actually be surprised if Displacement Mapping caught on significantly

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. :LOL:

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


dmap_main_alien.jpg
 
I ask some more questions to NVIDIA, answers will follw....

In their docs they say:

HOS (gf4/gffx)
continuous tessellation (gf4/gffx)
vertex dm (gffx)
geometry dm (gffx)

The HOS part was disabled on the gf4, at least in the drivers!
Hope the marketing guys know what they do, the lack of screenshots or words about DM could also be a bad sigen. ATI's DM isn't available in the drivers yet, but they had at least some screen shots.

Regards,
Thomas
 
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:
One more curious peculiarity of the GeForce FX is realization of displacement maps. Actually the chip doesn't have a separate hardware unit controlling tessellation of N-Patches and displacement maps - there is just a possibility (which is beyond the vertex shaders 2.0) not only to use in the shader data selected from a texture but also record computational results of a vertex shader into a certain memory place which can be interpreted as a texture or a vertex buffer. This won't be open for developers and will be meant only for internal use, in particular, for realization of DM without a separate hardware unit. But in future DX versions it will be possible to record calculated data from a vertex shader into accelerator's memory, up to generation of an arbitrary number of new vertices necessary for support of arbitrary HOS on the shader level.

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.
 
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 :-? ).
 
DaveBaumann said:
Testiculus Giganticus said:
Characters are not the best thing to to do DM on, DT :LOL:

Talk to Matrox.
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.
 
Testiculus Giganticus said:
DaveBaumann said:
Testiculus Giganticus said:
Characters are not the best thing to to do DM on, DT :LOL:

Talk to Matrox.
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?
 
Back
Top