Track pixels drawn per frame/second?

So I might've asked about this before, but I'm wondering if there's a way to get a concrete number on a game's fillrate per frame? It's very hard to optimize performance when you don't know exactly what assets that are heavy on the render.

Thanks

All the frame is redraw every time, so 1920*1080*60 draws per second, other than that, drawing is super-optimised, don't even try to, so I would assume the bottleneck is in the CPU and thus less sprites processed, the more performance, also, smaller re-usable assets are good too.

Whiteclaws - it's not as simple as that. With C2's back to front renderer, if two objects overlap, those pixels are drawn twice.

newt That's bitrate, pixel fill rate is the number of pixels a gpu can draw per second.

Tinimations - I'm not sure how much knowing the exact number of pixels drawn each frame would help. There's such a wide variety of hardware out there any number that's fine for one device will be too much for another, unless you're targeting the Xbox one?

There's also the issue that not all pixels require the same amount of work to draw. Even ignoring webGL effects which obviously add a varying amount of work, a transparent pixel requires more work from the gpu than a fully opaque one. Fully transparent ones still require work from the gpu as well, though only if an object is visible. So if you have an image with a lot of completely transparent pixels, that's work the gpu is doing for no effect. Rotated objects require more work, too.

For any recent gpu though, those aren't really something to be concerned about as graphics cards are getting ridiculously powerful. Ashley tested his new 1070, and if I recall correctly from his tweet he was able to render a quarter million sprites at 30 fps, though I don't know how large they were.

However, on a device like the iphone 4s, having UI panels be opaque instead of transparent makes a considerable difference. On some of those older devices the total pixel fill rate is only about three times the resolution of the screen - so if you have a single background image the size of the screen, that's a third of the pixel budget right there.

I suppose you could calculate the size of the bounding boxes and crop them to the screen to determine a vague estimate of the number of pixels they contain, but again pixels alone aren't the only benchmark for performance because of various things like how it's more work for the gpu to use a larger texture than a smaller one and how it takes extra work to switch from one texture to another (so if you have a hundred of the same image to draw, sticking them all on the same layer can help).

There are more performance tips in the manual, in case you haven't seen them already: https://www.scirra.com/manual/134/performance-tips

Arima This was helpful. Getting the feeling occational slowdowns I experience on laptops can be blamed on how I use a big background image with a transparent dark tile above it, essentialy rendering the full background twice. I turned off big fog sprites, and that greatly improved it.

newt That's bitrate, pixel fill rate is the number of pixels a gpu can draw per second.

Yes, but it's a good indicator of what you should be looking for for bottlenecks.

check this out now:

1920*1080*60 *32 bit per pixel /8 bits for byte / 1024 to Kbytes = 486000KB = ~ 500MB per second.

can you phone do that ? probably not. therefore lower the res for your games. PC can handle this

saiyadjin

Yes, and it does, a modern mobile GPU can push out 60 to 120 draw calls per second, also, that is misleading cause RAM is cleared between draws and the number of pixels drawn has nothing to do with the total RAM used per frame to draw screen

Arima, well I assumed C2 draws everything in one draw call.

But OP, most likely the bottleneck is CPU-wise for most modern systems

what are you talking about? if your whole scene changes then it does. also on bad engines it does.

it's around 9MB/frame of processing.

but usally engines render only moved pixels and what not to optimize nicely so that's pretty solid. and the other thing is - if you got blending, effects there are more passes through GPU then one, and it slow the whole process down, so really forget your 60FPS on mobile.

No they don't, they use OpenGL and OpenGL most likely clears screen buffer and rasterizes vectors and adds fragments every draw call, you are confusing the memory used to store those Images for quick access and the memory used to handle fragment shaders and vertex shaders, there's definitely multiple passes with effects and that can slow down things especially on devices that do not support OpenGL effects

Tinimations - Glad it helped!

newt - Bitrate and pixel fill rates really don't have anything to do with each other though. Bitrate is all about compressed video and the resulting accuracy of the compressed image in comparison to the original, and game engines don't compress their rendered frames when they're sent to the screen. Even having thousands of small sprites like the snow or confetti he showed might slam the draw calls, but the resulting number of pixels drawn would still probably be quite small compared to what the gpu can manage because of the empty space between them. With that many sprites on screen it's probably going to be a cpu bottleneck calculating their positions or telling the gpu to draw them instead of the actual process of drawing them, which is what we're talking about here. If you meant developers should avoid tons of objects to optimize though, that's correct but for different reasons than the pixel fill rate alone.

Whiteclaws - A draw call is made for each on screen object, not once for the entire screen, so if you have 100 instances that's a hundred draw calls each frame, or 6000 per second.

That's not exactly right about RAM/VRAM being cleared each frame - it would be a huge bottleneck to do so, as the process is so slow most games have to show you a loading screen. I suspect you meant the framebuffer is cleared (the RAM/VRAM allocated to the drawn image). Even if that is what you meant I thought I should clarify for anyone else reading. If you have 'clear background' set to yes it clears the framebuffer (which also takes more work, so disabling it can help performance if the background is covered anyway), but you can turn that off and watch objects smear around.

As mentioned, the framebuffer is stored in memory, so the higher the resolution the more memory it uses.

saiyadjin - At that resolution with no overdraw it's 124,416,000 drawn pixels per second. The Tegra 3 - which is an older chip - could draw 1.04 billion pixels per second, the Tegra 4 can draw 2.68 billion, and there are two generations of chips that have come out since then that are even faster. Mobile gpus have had the power to draw the entire screen multiple times per frame for quite a while.

Also, C2 does not only draw moved pixels. I've never heard of the technique used anywhere except compressed video and even then it's not exactly the same thing as it's encoding the movement of pixels rather than just drawing the moved pixels, as far as I know. If anyone's using it for rendering it's unusual (aside from frame warping in VR to coverup missed frames, but that doesn't work properly for rendering new material). If there's any difference between the current frame and the previous one, C2 redraws everything (with the exception of any pixels that are not covered by an object if you tell it not to with the clear background setting). If everything is the same, it skips drawing completely.

Arima - that is correct - but Tegra 3 is a pretty hardcore chip, while mobile chips are usually way weaker. example - mali 400 (which was a high end chip at one point) - Pixel rate scalable from 275 Mpix/s to 1.1 Gpix/ which would usually mean it can render ~ 10x more fps per second ~ 530 frames. but the problem is that draw calls are deeper then it is supposed to be -> graphics usually takes more then one "pass" to render the final pixel. and that takes time and slows down process. on a fullHD picture if you use 5 effects on different parts - > 6 passes, default render + 1 for each effect + maybe some other -> huge drop in fps. it's not all in pixel rendering, and that data that providers give you is - still image pixel rendering with 0 effects which is just to show bruteforce power of the chip.

didn't say about C2, i think that's more of a 3D engines idea, or i might have misread that somewhere something, not so sure anymore