It depends on what else you're doing. There is absolutely no problem dropping the performance of your program way below 60 fps with only a screen-aligned quad which consists of only two triangles.

However, given your hardware setup and your obviously trivial shader code and very low resolution 60k seems ridiculously low. Are you sure you are above 60 fps at any time and not capped by vsync the entire time?

08-23-2013, 04:09 AM

red1939

The problem is that I am not doing anything at all: no application logic, empty (trivial) shaders, no multisampling, etc.

It's not capped at 60 fps (I believe), as when I decrease the number of triangles, the fps goes higher.

I am using statically linked glfw v.3.0 and glew 1.1.0, together - of course - with opengl32.lib.

The only hint I could get from GPU Perf is that the almost all of the GPU time is taken by so called "Interpolator". Sure, the triangles are huge as a whole window, but it doesn't explain such low performance.

08-23-2013, 05:01 AM

thokra

Actually, the visible area covered by primitives does matter a great deal. The more fragments are generated, the more interpolation has to take place. With a growing number of exports (i.e. the stuff you pass out of one stage into another, e.g. vertex shader -> fragment shader) this overhead increases - not to mention, there are values that are always interpolated, such as the depth value. Plus, the more fragments, the more fragment shader invocations. (Probably not a problem in your case though).

Just as a comparison: If I'm not mistaken, a few years back I was able to yank around 3M vertices through a GeForce 8600M GS at approx. 30fps - which, even at the time, was pretty crappy hardware. Also with very simple shaders. Can post some code? Shaders, state inits, rendering loop? Do you actually have the depth test disabled?

Have you tried some OpenGL based game to see if you get bad performance there?

08-23-2013, 02:52 PM

red1939

I've tried with the depth test disable/enabled, but I don't see any real difference in terms of performance impact, also I didn't seem to have too much problems with OpenGL titles.

08-23-2013, 02:58 PM

red1939

As the lovely anti-link prevention system blocks me from sending urls, you will have to do manually create pastebin links from these:
pastebin.com/rUHYYmBd main.cpp
pastebin.com/yzZJ19xx Context.hpp
pastebin.com/XA37QF8v Context.cpp
pastebin.com/FqG6etR9 Shaders

08-24-2013, 03:42 AM

GClements

Quote:

Originally Posted by red1939

Sure, the triangles are huge as a whole window, but it doesn't explain such low performance.

Oh, it does. 640x480 x 500 quads x 60 fps = 9.2e9 pixels/second.

That's 28 Gbyte/sec at 3 bytes/pixel or 37 Gbyte/sec at 4 bytes/pixel; depending upon the width of the memory bus and the clock rate that could realistically be saturating the memory bandwidth. That could explain why the "GPU utilization" says "low". Early-depth optimisation won't help in this case, as you'd just be replacing writes to the colour buffer with reads from the depth buffer.

If you're comparing the triangle counts against a game, games aren't drawing a thousand 640x480 triangles per frame.

08-25-2013, 10:39 PM

red1939

I see, so in other words, a more realistic scenario would be to draw these triangles in some distance, or at least smaller?

08-25-2013, 11:13 PM

Alfonse Reinheart

Well, the bigger question is why you're drawing so many triangles, all of which are overlapping, that close to the screen? Or more to the point: what are you drawing?

08-26-2013, 03:13 AM

GClements

Quote:

Originally Posted by red1939

I see, so in other words, a more realistic scenario would be to draw these triangles in some distance, or at least smaller?

Yes. A more realistic test would keep the overdraw (the average number of times any given pixel is drawn) in single figures.

Real programs make some effort to ignore parts which can't be seen, so the total fill rate is limited to some low multiple of the number of screen pixels.