3D Grid based defered rendering

Discussion in 'General 3D Technology' started by K.I.L.E.R, Apr 30, 2003.

  1. K.I.L.E.R

    K.I.L.E.R Retarded moron
    Veteran

    Joined:
    Jun 17, 2002
    Messages:
    2,952
    Likes Received:
    50
    Location:
    Australia, Melbourne
    I thought doing TBR in 3d would actually be able to save geometry calcs.

    If I am dreaming, wake me up.
    Then tell me what other ways can you save geometry calcs on a TBDR chip.

    Thanks
     
  2. Jodi

    Newcomer

    Joined:
    Jan 7, 2003
    Messages:
    45
    Likes Received:
    0
    Location:
    Auckland, New Zealand
    TBR only saves in fillrate.

    There is no way to know to cull a vertex until you have transformed it (or in VS cases, written out its position to clip space). So unless TBR people have come up with some special tricks the answer to your question is:

    No.
     
  3. Nick

    Veteran

    Joined:
    Jan 7, 2003
    Messages:
    1,881
    Likes Received:
    17
    Location:
    Montreal, Quebec
    Nowadays geometry calculations are not the bottleneck. Both the vertex and pixel pipeline use floating-point arithmetic, but there are thousands of more pixels to process. Also, clipping and such is a hard-wired operation which is perfectly pipelined so it hardly matters if you clip or not. Reducing overdraw for the pixel shader is where the real benefit of Tile Based Rendering lies.
     
  4. micron

    micron Diamond Viper 550
    Veteran

    Joined:
    Feb 23, 2003
    Messages:
    1,189
    Likes Received:
    12
    Location:
    U.S.
    Please dont kill me for asking this but, could a Kyro or other type of TBR chip have onboard pixel and vertex shaders?
     
  5. Arun

    Arun Unknown.
    Moderator Legend Veteran

    Joined:
    Aug 28, 2002
    Messages:
    5,023
    Likes Received:
    299
    Location:
    UK
    What you've got to realize is that the VS actually does more than transform positions. It also calculates other things, which are then interpolated during Rasterization and used in the PS.

    While it is impossible to save transform work, you *could* save that type of work.

    Another way to look at it is always doing non-transform work in the PS. While this might *significantly* increase PS workload, it would be very efficient in a TBDR, since no useless calculations at all would be done.
    This would also mean you could reduce your Vertex Shading power to save transistors, and at the same time you also get higher quality because per-pixel is always more precise than per-vertex.


    Uttar


    EDIT: I'd also like to add that it IS possible to cull a triangle *before* doing rasterization or Triangle Setup. All you need to do is create a bounding box.
    What you could do, instead of doing per-pixel in all cases, is actually only do the per-vertex non-transform related work when you got a triangle that wasn't culled.
    It would be quite compatible with the traditional TBDR system I think ( might be wrong though ) - but one big problem is how much cache you might need for this... I'd be surprised if it was worth it.
     
  6. PC-Engine

    Banned

    Joined:
    Feb 7, 2002
    Messages:
    6,799
    Likes Received:
    12
    eDRAM is pretty cheap nowadays to be used as cache.
     
  7. darkblu

    Veteran

    Joined:
    Feb 7, 2002
    Messages:
    2,642
    Likes Received:
    22
    so what you're describing is a scheme where

    (1) object-eye transformations are carried out strictly before any other work (call it VS')
    (2) view volume clipping is carried out
    (3) rest of VS (call it VS") and setup are carried out
    (4) PS is carried out,

    and eventually save (compared to the status quo) the VS" work?

    one issue i see with the above is that it prevents you from using the post-perspective-transform coordinates (i.e. right before W-division ) for volume clipping, and you have to do homogeneous-space volume clipping no matter what. from a perfomance POV it's nothing to worry about (IMHO), but from a spatial precision POV, by moving your view volume clipping to an 'earliear' space you introduce a bit of error in the clipping scheme (which could eventually snap a vertex 1 unit off the mark).

    another issue is with V shaders which do not do any eye-space lighting whatsoever - they would go for an object-perspective transform in one step, and you'd have to handle those differently.
     
  8. demalion

    Veteran

    Joined:
    Feb 7, 2002
    Messages:
    2,024
    Likes Received:
    1
    Location:
    CT
  9. Panajev2001a

    Veteran

    Joined:
    Mar 31, 2002
    Messages:
    3,187
    Likes Received:
    8
    what about using HOS...

    Transform with the host CPU the control points ( simple transform ), check for visibility ( choose the algorithm you prefer ), tesselate only the patches that are visible and then process those triangles...
     
  10. SA

    SA
    Newcomer

    Joined:
    Feb 9, 2002
    Messages:
    100
    Likes Received:
    2
    The primary method for reducing vertex processing of hidden geometry is via bounding volumes or a bounding hierarchy. In either case, the visibility of a volume containing geometry is determined and if the volume is hidden, then all the enclosed geometry is discarded.

    One way to support this is via a z culling query. In this case, a set of bounding volumes are sent to the card and the card reports back to the application which volumes are visible. Visible volumes either process their contained geometry or are subdivided if they are part of a bounding volume hiearchy. This method (which is supported by some current immediate mode renderers) does not work as well with traditional TBRs since TBRs typcially do not process the the hidden surface information immediately but defer the processing until after the scene is fully specified.

    Another way for this to be done is to pass bounding volumes to the card along with the geometry via the API. I prefer this approach since it can reduce the latency associated with the method above. It also works well with TBRs since the bounding volume information is explicitly associated with the enclosed geometry. The card queues and processes bounding volumes before processing the associated enclosed geometry. It then processes the associated geometry for visible volumes. Visibility information and associations can be cached locally on the chip.

    A third alternative is to pass the entire scene graph (bounding volume hiearchy) to the card. This has the advantage that the card is able to perform any optimizations it choses without involving any changes to the application. It also works well for both immediate mode as well as TBR based renderers. The problem with the approach is that it reduces the amount of direct control the developer has of the scene processing. This approach was proposed in the Fahrenheit project which was subsequently abandoned.
     
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...