1.5 - 200% increase in OpenGL Rendering ?
by Scott Wilson-Billing · in iTorque 2D · 09/30/2011 (12:22 pm) · 11 replies
Loving the fact 1.5 is out but my first rule is never upgrade midway through development, so I'll be staying with 1.4.1. until release.
I will upgrade thought and have a question about the 200% performance improvement...
Is it just the alpha blending fix (which I have already applied) or is there some other notable stuff?
I will upgrade thought and have a question about the 200% performance improvement...
Is it just the alpha blending fix (which I have already applied) or is there some other notable stuff?
#2
09/30/2011 (1:14 pm)
Thanks Michael, thought it was. 
#3
I did a small test, tho and set two objects to alpha (in blending to 97) alpha testing remained at -1. I know there was a thread on this, but what essentially is happening? How is this (alpha testing) saving memory?
Quote from www.garagegames.com/community/forums/viewthread/7484/1#comment-47464
After reading this, I am thinking all objects (requiring rendering) are tested via the Alpha Test, if they pass they are passed, if not they fail, and are rejected..?
a. What determines the pass?
b. what determines the fail?
c. and again, with the current system, how is this improving performance?
Sorry if this is long winded I just want to better understand the engine.
Thanks.
09/30/2011 (1:51 pm)
That brings up a good question I have... so with alpha testing set a default -1, assuming on all objects, this prevents and alpha adjustments (transparency) thus saving stress on the engine?I did a small test, tho and set two objects to alpha (in blending to 97) alpha testing remained at -1. I know there was a thread on this, but what essentially is happening? How is this (alpha testing) saving memory?
Quote from www.garagegames.com/community/forums/viewthread/7484/1#comment-47464
Quote:
Alpha test is one operation in the Per-fragment Operations stage (See Fragment
Processing Overview diagram on Page 2) of the OpenGL pipeline that allows any further
processing of the fragment to be aborted based on the value of its alpha component. The
fragment's alpha component is compared with an application-specified reference value
using an application-specified comparison function. If the fragment passes the test, it will
be processed by the subsequent fragment operation, otherwise it will be discarded. Alpha
test does not incur any extra overhead even if all the fragments pass the test. Unlike
stencil testing, depth testing, texturing, and blending, alpha testing do not involve
fetching data from memories external to the GPU. Alpha Test is only available in RGBA
mode.
After reading this, I am thinking all objects (requiring rendering) are tested via the Alpha Test, if they pass they are passed, if not they fail, and are rejected..?
a. What determines the pass?
b. what determines the fail?
c. and again, with the current system, how is this improving performance?
Sorry if this is long winded I just want to better understand the engine.
Thanks.
#4
10/01/2011 (9:31 am)
Pixels only go through alpha tests if the src or dest in the blend operation is an alpha one. Otherwise they are opaque and will only do a z test for pixel occlusion on SGX hardware as used on all iOS devices since day 1
#5
10/01/2011 (10:08 am)
But how does this, new feature, the alpha test change the process? 
#6
10/01/2011 (10:52 am)
@rennie - The simplest way I can put it is that we had both blending and alpha testing turned on, which killing performance. In general, you never want the two enabled. Once we turned of alpha testing all together, our FPS skyrocketed. Since there are people who use alpha testing in their projects, we exposed it as a new property for t2dSceneObjects. Use one or the other, never both.
#7
10/01/2011 (11:25 am)
oh ok, so essentially, i can use blending, if I want a bit of transparency, colors changes etc, and me being me, should just level alpha testing at -1?
#8
To explain that a bit in case you are interested, its important to know that Imagination Technology has significantly optimized the hardware to do the 'most common' stuff on high performance.
For this reason opaque pixels totally oclude pixels behind them so they are not even drawn (this test happens before anything is performed on the pixel, unlike the pc where the pixel is fully calculated with all shaders and then tested!)
The consequence of this is the following:
On iOS, the worst thing you can do is Alpha testing. This is often used for masking which is about the worst thing you can do performance wise on iOS. This is bad because not only does it disable the pixel occlusion, it additionally requires a lock of the pixel for the testing lookup.
The less bad thing, but still significantly faster than the alpha testing, is alpha blending without testing.
The best thing is not having transparency at all for above reason, unless you need it.
The mobile hardware is capable at handling a 100 polygon object that surounds the real visible stuff relatively easy and super performant if its opaque, but if you have a single quad on 2 triangles and use alpha or worse alpha testing that will hit a the performance quite a bit, the same object now needs over a magnitude more processing power pretty easily.
I still have the hope that iT2D at some point gets capabilities to stop drawing quad sprites but approximates the outline at least to reduce the overdraw, fillrate hit and pixel ops above, that would push the performance seriously.
A trivial first step would be if we could use the collision polygon as new mesh for the sprite in question, that should also be quite easy to pull off
10/01/2011 (12:42 pm)
Correct! Use -1 if you don't need the blending, that will double to quadrupple the performance of that specific sprites where you disabled it.To explain that a bit in case you are interested, its important to know that Imagination Technology has significantly optimized the hardware to do the 'most common' stuff on high performance.
For this reason opaque pixels totally oclude pixels behind them so they are not even drawn (this test happens before anything is performed on the pixel, unlike the pc where the pixel is fully calculated with all shaders and then tested!)
The consequence of this is the following:
On iOS, the worst thing you can do is Alpha testing. This is often used for masking which is about the worst thing you can do performance wise on iOS. This is bad because not only does it disable the pixel occlusion, it additionally requires a lock of the pixel for the testing lookup.
The less bad thing, but still significantly faster than the alpha testing, is alpha blending without testing.
The best thing is not having transparency at all for above reason, unless you need it.
The mobile hardware is capable at handling a 100 polygon object that surounds the real visible stuff relatively easy and super performant if its opaque, but if you have a single quad on 2 triangles and use alpha or worse alpha testing that will hit a the performance quite a bit, the same object now needs over a magnitude more processing power pretty easily.
I still have the hope that iT2D at some point gets capabilities to stop drawing quad sprites but approximates the outline at least to reduce the overdraw, fillrate hit and pixel ops above, that would push the performance seriously.
A trivial first step would be if we could use the collision polygon as new mesh for the sprite in question, that should also be quite easy to pull off
#10
docs.garagegames.com/it2d/official/content/documentation/Game%20Builder/Sceneobj...
It's a very quick and simple transparency technique. With alpha test set to 128, any pixels with an alpha value less than 128 are not drawn at all, and any pixels with over 128 are drawn fully opaque. So you get a hard or non-filtered outline with no semi-transparent pixels. Fine for pixel art or anything with a hard border, but if you need smooth edges on your sprites then you use regular blending and set the alpha test to -1.
10/01/2011 (10:52 pm)
Rennie - if you take a look at the cloud screenshots here you'll see what alpha testing actually looks like:docs.garagegames.com/it2d/official/content/documentation/Game%20Builder/Sceneobj...
It's a very quick and simple transparency technique. With alpha test set to 128, any pixels with an alpha value less than 128 are not drawn at all, and any pixels with over 128 are drawn fully opaque. So you get a hard or non-filtered outline with no semi-transparent pixels. Fine for pixel art or anything with a hard border, but if you need smooth edges on your sprites then you use regular blending and set the alpha test to -1.
#11
there are only a handfull of cases where alpha test is really required, namely depth sorting related if you didn't properly split them over layers or if you use compression where the sharp border can become a victim of the compression technology leading to feathering / semy smooth fading which breaks 8bit looks for example
10/03/2011 (4:49 pm)
even if you need hard edges, normally make them use alpha 0 on that pixels and set it to -1there are only a handfull of cases where alpha test is really required, namely depth sorting related if you didn't properly split them over layers or if you use compression where the sharp border can become a victim of the compression technology leading to feathering / semy smooth fading which breaks 8bit looks for example
Employee Michael Perry
ZombieShortbus