next »

[Glaiel-Gamer]

I tend to get a huge speed hit when switching frame buffers for render to texture, and as far as I know the only way to do post process filters is to render the scene on a texture first.

Anyway all the sites out there tell me how to do render to texture but don't give you any tips on how to make it fast. Any suggestions?

[Ivan]

One thing you can do is not generate a depth FBO if you're not using the zbuffer in your shader. That should speed it up a bit. But really, it shouldn't be too slow. Where exactly are you getting a slowdown? On glBindFramebufferEXT()?

I use like 6-7 FBO stages in some of my screen shaders and its runs fine.

[Glaiel-Gamer]

i was just using the color buffer cause I'm doing 2D

Maybe it's not that slow, I don't have a FPS counter and it probably just seems slower than without it by 50% which still might be 200 fps

[Ivan]

I mean, it's going to be slower no matter what. Also, you don't need your FBOs to be the size of the screen for alot of things. Like for bloom and stuff you can get away with REALLY small textures for the blur.

[Glaiel-Gamer]

my 4-pass 1024x768 blur filter runs about 100 FPS. Is this good or bad? I know I don't need a 4 pass blur filter, 2 is plenty, but this was some sort of stress test

[Hajo]

my 4-pass 1024x768 blur filter runs about 100 FPS. Is this good or bad? I know I don't need a 4 pass blur filter, 2 is plenty, but this was some sort of stress test

Seems good enough. Everything that is better than what you need is good enough for your needs. Don't waste time worrying about problems that aren't problems. There will be enough real problems to keep you busy

[Lynx]

I don't think humans can really perceive more than 60-70 fps, and 30fps is usually pretty acceptable if it's smooth.

[Glaiel-Gamer]

I don't think humans can really perceive more than 60-70 fps, and 30fps is usually pretty acceptable if it's smooth.

Right but my test was on about 40 basic sprites and nothing else, and I'm trying to make sure I can make the game more complicated and still hit 60 fps. I probably got to do some profiling.

[Hajo]

... 30fps is usually pretty acceptable if it's smooth.

Jitter is more annoying than a (overall) mediocre frame rate.

[Ivan]

If you're using a texture for blur, you don't need it to be that high res, since it's going to be blurry anyway. You can easily get away with something like 128x128 texture for a blur pass. In fact, that's alot better since the blur shader will run alot faster.

[Will Vale]

Right but my test was on about 40 basic sprites and nothing else, and I'm trying to make sure I can make the game more complicated and still hit 60 fps. I probably got to do some profiling.

Your performance is probably fine - the 1024x768 four-pass blur has added a fixed GPU cost to your frame, but this won't change with the number of sprites and you should be able to draw a lot more only increasing your frame time slightly. A relatively modern card should eat up 4x1024x768 so I'm guessing yours is a mobile part or a little older?

Toastie makes a good point about low frequency effects, and the smaller texture will lower your fixed blur cost without changing your cost per sprite.

There's some good advice on the NVidia and AMD sites about GPU profiling, but mainly:

* Turn off vsync so your time isn't rounded up.
* Measure time per frame in milliseconds, not fps, so you can see what your changes really mean.

Cheers,

Will

[nihilocrat]

... 30fps is usually pretty acceptable if it's smooth.

Jitter is more annoying than a (overall) mediocre frame rate.

This is the truth. I have heard anecdotal evidence (and you can probably notice if you play them) that pro console games take this approach if the game eats up too many frames to be consistently smooth at 60fps.

[Glaiel-Gamer]

right ya but the final filter isn't gonna be blur, it's gonna be (for closure)

threshold (the lighting effect) + add (1 pass)
vblur + add (1 pass)
hblur + add (1 pass)

so 3 passes in the end, full res. Plus a render to texture for the lights (1 high res pass for rendering, and one lo res pass for collision)

So 10 frame buffer swaps in the end (I could optimize to 5 or 6 if I wanted)

Is it the swapping that causes the lag or is the actual rendering?

[Ivan]

they don't all have to be fullres. Render the scene to a fullres texture and then highpass it into a smaller one then do your blurs on that and then combine it in the end with the fullres one.

[Kaelan]

Is it the swapping that causes the lag or is the actual rendering?

if memory serves, swapping won't cause lag, but it will cause a state change and possibly a pipeline flush/stall. both are expensive, especially the latter, so you want to minimize them - but if you're rendering to multiple buffers, you can't exactly avoid those costs. Minimizing the number of swaps is probably worth it if it doesn't otherwise complicate your code enough to make it a net loss.

Depending on how the lights work you might want to do the collision in software, since the framebuffer switch for rendering and the occlusion test(s) will all induce stalls, IIRC.

The cost of all these operations will vary based on OS, video card, and driver version, though. Framebuffer swaps might not hurt at all on certain top-end cards but on lower end cards, if they're supported at all you may discover they cost a lot more.

It may help to try and visualize the way your graphics operations are going to be pipelined and executed by the graphics card - draw a horizontal timeline of your commands, and then mark the points on that timeline where you try and use the results of those commands. For example, if you render to a framebuffer object, as soon as you attempt to bind that framebuffer as a texture, you're forcing the graphics card to finish all those rendering operations, so you get a stall. Etc.

If you can minimize the number of those stalling points, you have a better chance of not running into any real performance issues.

[Glaiel-Gamer]

Is it the swapping that causes the lag or is the actual rendering?

if memory serves, swapping won't cause lag, but it will cause a state change and possibly a pipeline flush/stall. both are expensive, especially the latter, so you want to minimize them - but if you're rendering to multiple buffers, you can't exactly avoid those costs. Minimizing the number of swaps is probably worth it if it doesn't otherwise complicate your code enough to make it a net loss.

Ya but I could easily optimize it by not switching back to the screen buffer just to immediately switch to a different frame buffer if it makes a difference.

Depending on how the lights work you might want to do the collision in software, since the framebuffer switch for rendering and the occlusion test(s) will all induce stalls, IIRC.

I need the light layer to know what's walkable, I might be ably to reduce it to some circle math but that fails when I add raycasting.

[Zaknafein]

I've had some success with early-stencil/early-z for fullscreen effects and deferred rendering, if you can isolate parts of the screen that you are really using on the framebuffer object.
The idea is to flag pixels in the stencil/depth buffer before doing the costly per-pixel operations and then only process the flagged pixels in the 2nd step. This works best if your scene geometry is pretty light, or if you have low-poly versions that you can use for the flagging pass.

I wrote about it here, not the right language or engine and it's DirectX based, but may give you an idea...