low fps

low fps

• Aun

  160 fps sounds pretty good to me! That's twice as fast as any monitor is capable of displaying in any case...
  
  It really isn't worth reading too much into performance measurements for applications that are not doing very much work, and are running at ridiculously high framerates. The actual cost of your drawing code usually ends up being so low that performance is totally dominated by system overhead, so you end up accidentally measuring uninteresting things like how long Present takes or how fast Windows is at dispatching input messages.
  
  Before doing any kind of serious performance investigation, you need to make sure you are doing enough work that your framerate falls below the monitor refresh rate. Try drawing hundreds of thousands, or even millions, of triangles, and then you'll get results that can really tell you something interesting.
  
  
  

• sigme

  My terrain engine, for a 1024x1024 heightmap, using 2 shaders, one for hi detail (6 alpha blended textures, base layer and lightmap) and one for low detail (1 texture stretched the entire terrain), I blend from hi detail shader and switch to low detail based on a certain distance, rather like the fog factor formula.

  I use quadtree culling plus LOD switching algorithm.

  My near and far planes are set to 1, 1000 respectively, so I see quite a lot of the terrain at one time unless I am looking at more of a downward angle.

  I get average 100-150 FPS in windowed mode, I get 300-500 FPS (depending on how much visible terrain) in fullscreen mode.

  If I move away from the terrain whilst still looking at it, where the LOD would be most coarse, I get 600+ FPS.

  If I look at nothing, so everything is culled, I get 1000+ FPS.

  I suck at artwork, and my engine is in its 'messy needs optimising and refactoring stage' but here is a screenshot I took of a 512x512 heightmap terrain http://geekswithblogs.net/images/geekswithblogs_net/fluxtah/6133/o_terra.jpg

  I am not sure why you are getting such low FPS, but I do not think your test is giving accurate results.

  Also GFX cards are optimised to render large batches of geometry with as less draw calls rather than small batches with many draw calls, I doubt this is the problem though.

  
  

• Marc Jones

  ok thanks :)

  ill fill func draw with other calls and then will come back here again :)

  
  
  

• Softwhere

  2Shawn:

  160 fps for void 200 triangles... there will be more than 200 + models + physics + game logic...

  2dzraptor:

  ofc i will then move out of draw func anything possible. but for now i think it won't gimme +200 fps :)

   

  btw, when i draw loaded textured *.x model that consist of 1800 triangles fps is ~470! still confused why...

  edit: i'm using texture non power of 2 dimensions. can it be the reason

  
  
  

• XNA Rockstar

  Graphics drivers are optimised for programs that do lots of rendering work. The goal is to make things run at the monitor refresh rate, typically somewhere in the region of 60 to 90 fps. Nobody cares whether programs can go faster than this, so nobody bothers optimising for programs that do so little drawing work. Who knows what crazy paths the driver may be going down when you run a trivial app like this - it's probably spending most of its time waking up the graphics card to submit a batch of drawing calls, then shutting it down again when it immediately runs out of things to draw, and I doubt operations like "force an early flush of the command buffer because the app called Present before writing enough data to reach the normal kick-off threshold" are going to be at all well optimised by the driver authors or hardware designers! (because the only apps that ever hit this case are ones that are already running plenty fast enough).
  
  
  

• R.K.S.

  Fenghus wrote:

  A "constant fixed system overhead" of 6 milliseconds per frame That doesn't sound correct...

  No, that sounds about right. For example, I just ran my game, and I was getting 120 FPS on average, which means about 8 milliseconds per frame. However, I also useda Stopwatch to measure my update and draw frames, and it turns out, those add up to about 4 milliseconds. That means I have another 4 milliseconds as overhead, and 6 milliseconds doesn't seem like that much of a stretch.

  
  
  

• Zero_

  No, i mean, that sounds too much. If the program is completely error-free and there really is a constant system overhead of 4-6 milliseconds, no application will ever run faster than 160-250 fps. It seems more likely the overhead is generated by some fault in the application.
  

• jackinthegreen

  hi again!

  i told i'll come back ;)

  at the moment i have same 200 triangles rendered with only 25-35 fps. im using 3d texture and my own effect. this fps are definitly less that i expect to see :)

  texture3d size is 128x64x128 Color format (i.e. not very big - only 4 mb) and created this way:

  vlTexture = new Texture3D(graphics.GraphicsDevice, lx, ly, lz, 1, ResourceUsage.None, SurfaceFormat.Color);

  i dont change anything, just draw triangles.

  here is the part of my shader:

  struct VS_OUTPUT3

  {

  float4 position : POSITION;

  float3 texCoord : TEXCOORD0;

  };

  VS_OUTPUT3 Main_VS3(

  float4 pos : POSITION,

  float3 texCoord : TEXCOORD0)

  {

  VS_OUTPUT3 Out = (VS_OUTPUT3)0;

  Out.position = mul(pos, worldViewProj);

  Out.texCoord = texCoord;

  return Out;

  }

  float4 Main_PS3(

  float3 texCoord : TEXCOORD0) : COLOR

  {

  return tex3D(textureSampler, texCoord);

  }

  
  
  

• Grahame Edwards

  Well, there's no way to say for sure if we can't see any code. The reason that you get a faster FPS when you zoom out is that there are less pixels to send to the pixel shader, and generally just less to draw.
  
  

• Morten Dahl

  Well, I don't know if it's good or bad, but i just ran an empty project that only contains one draw call to clear my screen to CornflowerBlue and was only achieving 270 FPS, which translates to 3.7 milliseconds of overhead. I don't think this is really a correct measurement though, because on a faster computer/graphics card, I can get higher FPS, but the overhead shouldn't really change should it I'm getting a bit confused over this though.
  
  

• DBLearner

  NeTBaPb wrote:

  160 fps for void 200 triangles... there will be more than 200 + models + physics + game logic...

  
  
  Sure. But my point is, this 160 fps figure is totally meaningless. You can't generalize from drawing just a few things to what kind of performance you will get when you later come to draw lots of things. There just isn't any meaningful relationship between the numbers, because at the moment you are not measuring what you think you are measuring: almost all of that 160 fps figure will be dominated by constant (and very unpredictable) fixed overhead costs.
  
  The only meaningful way to look at framerate figures is to draw what you actually want to draw in your final game, and then see how fast that runs. Drawing less and then trying to apply a linear projection based on whatever figures you get just isn't a valid logic and won't tell you anything useful at all.
  
  
  

• scribework

  here is my draw func

  protected override void Draw(GameTime gameTime)

  {

  VertexPositionColor[] axes = new VertexPositionColor;

  axes[1] = new VertexPositionColor(new Vector3(100, 0, 0), Color.Red);

  axes[3] = new VertexPositionColor(new Vector3(0, 100, 0), Color.Green);

  axes[5] = new VertexPositionColor(new Vector3(0, 0, 100), Color.BlueViolet);

  basicEffect.View = mainCamera.ViewMatrix;

  basicEffect.Texture = tz[0];

  basicEffect.Begin();

  foreach (EffectPass pass in basicEffect.CurrentTechnique.Passes)

  {

  pass.Begin();

  graphics.GraphicsDevice.VertexDeclaration = decl1;

  graphics.GraphicsDevice.DrawUserPrimitives<VertexPositionColor>(PrimitiveType.LineList, axes, 0, 3);

  graphics.GraphicsDevice.VertexDeclaration = decl;

  graphics.GraphicsDevice.Vertices[0].SetSource(vb, 0, VertexPositionTexture.SizeInBytes);

  graphics.GraphicsDevice.Indices = ib;

  graphics.GraphicsDevice.DrawIndexedPrimitives(PrimitiveType.TriangleList, 0, 0, lz * 4, 0, lz * 2);

  pass.End();

  }

  basicEffect.End();

  base.Draw(gameTime);

  DrawFps();

  }

  where lz is 100

  vb = new VertexBuffer(graphics.GraphicsDevice, VertexPositionTexture.SizeInBytes * lz * 4, ResourceUsage.None);

  vb.SetData<VertexPositionTexture>(pz);

  ib = new IndexBuffer(graphics.GraphicsDevice, sizeof(int) * lz * 6, ResourceUsage.None, IndexElementSize.ThirtyTwoBits);

  ib.SetData<int>(idz);

  setuped earlier in loadgraphicscontent

  
  
  

• Penicillin

  Even though it's running pretty fast right now, I would suggest moving your VertexPositionColor declarations outside of your Draw code. Each time you call Draw, you're rebuilding the exact same thing; you only need to do it once. Try putting it inside LoadGraphicsContent() or something similar. This type of thinking will help you avoid the real pitfalls later on, such as recreating a model inside each Draw call.
  
  

• Imran_Akram

  A "constant fixed system overhead" of 6 milliseconds per frame That doesn't sound correct...

  
  
• low fps