Will the NV30 even have a HOS processor?

[Luminescent]

If we refer back to this thread, at the bottom of the first page: http://www.beyond3d.com/forum/viewtopic.php?t=2655&start=0, along with the commencement of the second page, humus and democoder were discussing possible displacement mapping implementations on the NV30. If we read closely, neither of them included procedures for a dedicated HOS unit, but used the pixel and vertex shaders in conjunction. Taking this piece information, along with the fact that the programmable pre-primitive processor was supposedly removed from the final design of the NV30 processsor, is it possible that the NV30 does not have an HOS processor in any form?

Nvidia might not have wanted any major hardwired logic in it's processor. It would seem to be a step in the right direction, in terms of programmability, but how about for performance, wouldn't the NV30 suffer a performance loss when implementing HOS? Would it be feasible to include methods for computing HOS without HOS specific hardware and have them be just as efficient or effective as a dedicated solution?

 

[KimB]

Displacement mapping requires vertexes to be added. Vertexes cannot be created or destroyed in the pixel/vertex shaders through any instructions we have today.

So, quite simply, displacement mapping support requires special hardware, though it may still be possible to leverage the PS/VS processing power in some way to save transistor space (and, in turn, hurt HOS performance).

 

[Dave Baumann]

3Dlabs[/url]]The displacement lookup (and optionally the tessellation) is done by the texture subsystem and the results left in memory where they can be read just like a regular vertex buffer. On the second pass the vertex shader will pick up the displaced vertices, light them and then they get processed as normal.

 

[Luminescent]

That is the process I was referring to Dave, thankyou. Any comments on this?

 

[Randell]

well if I've interpreted this correctly, the R300 doesnt have a hardwired TRUFORM engine (I think) like the 8500, so takes a bigger performance % hit using TRUFORM, but relatively it doesnt matter as much as its a much more powerful peice of hardware so the final performance numbers are still higher.

Is displacement mapping to DX9 going to be like cube maps to DX7, ie, first gerenation hardware can do it, but you'd only really want to try it on second generation hardware coupled with more powerful CPU's/memory sunsystems?

 

[Humus]

Displacement mapping and truform requires special hardware to generate the vertices. You may implement displacement mapping with render to vertex array, the 3dlabs method above sounds very similar, but it will not work as good as Matrox style displacement mapping, you don't get any LOD, you must take care of topology yourself (create an appropriate index buffer for the generated vertices).

 

[Luminescent]

So, if I understand Humus correctly, a programmable vpu such as the p10 or NV30 could displacement map without hardwired logic albeit n-patches, unless the implementation is emulated on a cpu for vertex generation. In a situation such as this, with no n-patch emulation, woudln't cpu have to send a more-than-usual amount of vertices to the vpu for this type of implementation to take place? With no hardware vertex generation, let's say there is no n-patch support or emulation, the displaced verteces, whose information came from the pixel pipeline, are going to create a choppy mess unless extra polygons are added or some type of curve is specified.

This makes me wonder whether or not the NV30 will support hardware n-pathes. It is great to play truformed games on the 9700, with the minimal performance loss of a hardware execution (at least in the coming driver updates). Wouldn't it be a great disadvantage if the NV30 was lacking this backwards compatible IQ feature and had to emulate it?

 

[moichi]

If we can use framebuffer as vertex buffer,
we will do displacement mapping by pixel shader.

 

[Luminescent]

Can the framebuffer be used as the vertex buffer? Is this a sure thing, or a tentative solution?

 

[OpenGL guy]

Can the framebuffer be used as the vertex buffer?

If you can support vertex buffers in local video memory, then any chunk of local memory can be a vertex buffer, right? Calling a chunk of memory a vertex buffer isn't the difficult part...

 

[Luminescent]

So one would store the "displacement" pixel calculations in vertex buffer, retrieve the mesh, and send data to the vertex registers to be executed via vertex processor? Would this method be as quick as the conventional matrox algorithm?