Will the NV30 even have a HOS processor?

Discussion in 'Architecture and Products' started by Luminescent, Oct 9, 2002.

  1. Luminescent

    Veteran

    Joined:
    Aug 4, 2002
    Messages:
    1,036
    Likes Received:
    0
    Location:
    Miami, Fl
    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?
     
  2. KimB

    Legend

    Joined:
    May 28, 2002
    Messages:
    12,921
    Likes Received:
    221
    Location:
    Seattle, WA
    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).
     
  3. Dave Baumann

    Dave Baumann Gamerscore Wh...
    Moderator Legend

    Joined:
    Jan 29, 2002
    Messages:
    14,079
    Likes Received:
    648
    Location:
    O Canada!
     
  4. Luminescent

    Veteran

    Joined:
    Aug 4, 2002
    Messages:
    1,036
    Likes Received:
    0
    Location:
    Miami, Fl
    That is the process I was referring to Dave, thankyou. Any comments on this?
     
  5. Randell

    Randell Senior Daddy
    Veteran

    Joined:
    Feb 14, 2002
    Messages:
    1,869
    Likes Received:
    3
    Location:
    London
    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?
     
  6. Humus

    Humus Crazy coder
    Veteran

    Joined:
    Feb 6, 2002
    Messages:
    3,217
    Likes Received:
    77
    Location:
    Stockholm, Sweden
    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).
     
  7. Luminescent

    Veteran

    Joined:
    Aug 4, 2002
    Messages:
    1,036
    Likes Received:
    0
    Location:
    Miami, Fl
    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?
     
  8. moichi

    Newcomer

    Joined:
    Jul 22, 2002
    Messages:
    36
    Likes Received:
    0
    Location:
    Japan
    If we can use framebuffer as vertex buffer,
    we will do displacement mapping by pixel shader.
     
  9. Luminescent

    Veteran

    Joined:
    Aug 4, 2002
    Messages:
    1,036
    Likes Received:
    0
    Location:
    Miami, Fl
    Can the framebuffer be used as the vertex buffer? Is this a sure thing, or a tentative solution?
     
  10. OpenGL guy

    Veteran

    Joined:
    Feb 6, 2002
    Messages:
    2,357
    Likes Received:
    28
    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...
     
  11. Luminescent

    Veteran

    Joined:
    Aug 4, 2002
    Messages:
    1,036
    Likes Received:
    0
    Location:
    Miami, Fl
    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?
     
Loading...

Share This Page

  • About Us

    Beyond3D has been around for over a decade and prides itself on being the best place on the web for in-depth, technically-driven discussion and analysis of 3D graphics hardware. If you love pixels and transistors, you've come to the right place!

    Beyond3D is proudly published by GPU Tools Ltd.
Loading...