Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualNik02

Posted 01 November 2012 - 03:17 AM

If you use GPU tessellation here, are you absolutely sure that the edge tessellation factors (as computed by the hull shader's constant evaluation function) are consistent with regard to their actual position as related to their adjacent geometry? And that the tessellation algorithm (as specified by the corresponding attribute of the hull shader function) is one that produces consistent results (as in integer factors)?

Load time can be improved by using smaller vertex buffers.

Drawing performance is dependent on many other things as well. Each drawn primitive takes a certain amount of overhead (like vertex shaders and tessellator) regardless of whether or not they end up covering any pixels on the render target; in addition, each pixel (or fragment of pixel) drawn takes time, and the more complex logic is specified in the shaders to draw those, the longer it takes. There are also the matters of register pressure, resource waiting, bus bandwith...

Do profile your application with a GPU profiler (search for these) to gain understanding where your bottleneck is; after you've done this, it becomes possible to try to fix it.

Finally, FPS is a very poor measurement of relative performance. You should instead measure milliseconds per frame, it linearly corresponds to the time taken by all the ops for a given frame. FPS is a reciprocal of that.

#1Nik02

Posted 01 November 2012 - 03:15 AM

If you use GPU tessellation here, are you absolutely sure that the edge tessellation factors (as computed by the hull shader's constant evaluation function) are consistent with regard to their actual position as related to their adjacent geometry? And that the tessellation algorithm (as specified by the corresponding attribute of the hull shader function) is one that produces consistent results (as in integer factors)?

Load time can be improved by using smaller vertex buffers.

Drawing performance is dependent on many other things as well. Each drawn primitive takes a certain amount of overhead; in addition, each pixel (or fragment of pixel) drawn takes time, and the more complex logic is specified in the shaders to draw those, the longer it takes. There are also the matters of register pressure, resource waiting, bus bandwith...

Do profile your application with a GPU profiler (search for these) to gain understanding where your bottleneck is; after you've done this, it becomes possible to try to fix it.

Finally, FPS is a very poor measurement of relative performance. You should instead measure milliseconds per frame, it linearly corresponds to the time taken by all the ops for a given frame. FPS is a reciprocal of that.

PARTNERS