Request for feedback: front-to-back renderer performance

Gosh, this isn't sounding very good at all. Either our implementation isn't fast enough (and I'm not sure what we could do to improve it), or front-to-back rendering just doesn't work very well with real-world games.

Does anyone have any positive feedback at all?

There's a huge performance improvement, but only with PCs, or laptops and tablets with ATI or nvidia graphics like nvidia 635m, and only if the device's screen is full hd or quad hd or more. From my own tests there's no real difference or even regression in performance if you are playing on a screen with resolution lower than 1080p (not in all cases), any intel mobile gpu like hd 4400 or even iris 5100-6100, i didn't test weaker or desktop intels, only an old crappybook with intel GMA gpu and the game just can't start, dunno why, though it works without ftb.

There's also a performance improvement on some phones and tablets but not on many, no difference or regression because of a higher cpu utilization on others.

Its a little niche. Might be good with mode 7.

Next Penelope perhaps.

Ashley I think too much objects are simply discarded because of blending, effect, transparency,.. , this is interesting read about blending optimizations and front to back render with UNDER Blending, might help..

https://developer.nvidia.com/content/transparency-or-translucency-rendering

All hi,

Ashley hi,

i don't know if this happen because of rendering front back enabled

but i'm using crosswalk on android and since i use r208 and enable back front render i see that theere is better performance than before (r206)

i'm not sure ... but it's like that

before my game was very laggy on s2 i9100 and now it work perfectly (with ads ... not admob but with other networks)

Sisyphus & matrixreal - I'm looking for specific performance numbers with real-world games, not our artificial test that just creates piles of sprites. Can you report on any specific FPS numbers?

Sisyphus & matrixreal - I'm looking for specific performance numbers with real-world games, not our artificial test that just creates piles of sprites. Can you report on any specific FPS numbers?

Oh, i'm not talking about the test now and in previous post, it's about the game i'm working on. Here's some fps numbers.

Better performance with:

Desktop with 660ti and 2560x1080 screen - 55-60 fps without ftb, and stable 60 with ftb.

Laptop with nvidia 635m and 1920x1080 - 40fps without, 55-60 with ftb.

Old pc with nvidia 9600gt 2560x1080 - 40fps without, 50-60 fps with ftb.

No changes or performance regression with:

Any macbook i try (late 2013, early 2015) with intel gpu and 2560x1600 screen 35-40fps without, 30-40fps with ftb.

Laptop with intel hd4400 and 1920x1080 - 30fps always with or without ftb.

Netbook Intel GMA and hd screen - 10-30 without ftb, Crash with ftb.

I'm looking for specific performance numbers with real-world games, not our artificial test that just creates piles of sprites. Can you report on any specific FPS numbers?

Umbra demo - run through the same section of part of my alpha test (with javascript tools running in chrome):

Back to front: 51 fps:

Front to back: 44 fps:

Edit:

With javascript tools off, so just the game running:

Back to front: 60 fps / 40% cpu / delta dt: 0.1 ms

Back to front: 60 fps (occasional drops to 59 fps) / 44% cpu / delta dt 0.8 ms

So, little discernible difference real-time.

Ashley

black screen on ipad 2 / retina / air / iphone 5 iOS 8.3

work fine on iphone 4s 7.1.2

My knowledge of rendering is near non-existent, but why is FTB consistently slower? Surely in most cases the added benefit of graphic occlusion should be saving draw calls and improving performance?

Elliott - look at the numbers in this thread, it's not consistently slower. But it's not always faster either. It adds extra CPU and GPU overhead in order to eliminate overdraw, and if there's not much overdraw then it will be slower.

So there's not much good news here. I'm particularly concerned that it crashes some devices or introduces display glitches. It's not much use if it's slightly faster on some devices, but crashes on others. So I don't think it's worth shipping this in a stable release. I think we will retract this feature and go back to back-to-front rendering only. Any objections?

i think thats probably best, its not stable and not really great improvements so its best not to use, not even as an option, too bad, well.. only a step closer to something that does work i still think reducing textureswapping might improve the renderer, just a sidenote..

I agree - I applaud giving this a try and it's a pity that it didn't bear fruit.