Kishonti GFXbench

AFAIK there have been very significant changes since I left IMG, so it's likely different and doesn't have a single huge bottleneck anymore, but in an early version, I tried disabling the foliage (many alpha tested layers with an ALU-heavy pixel shader) by modifying the vertex shader to output a dummy position. The overall performance of the entire benchmark increased by about 3x on all handheld architectures.

Also somewhat annoying that the Exynos Galaxy S4 (and maybe other Android SGX devices?) fails to compile all the GLB2.7 shaders so it's impossible to benchmark. James, this is a disgrace, how dare you prioritise compiler optimisation over bugfixing! Oh wait, oops ;) :D

So is Alpha blending a weakness of the Series 5 PowerVR GPUs, compared to the Adreno 320, and would it account for the drop in relative performance in 2.7 vs 2.5.1 for Power VR equipped devices?
 
I'm not sure about alpha blending, but since Arun said alpha tests and there are suggested workarounds in their developer recommendations for SGX and alpha tests I'd bet on the latter.

I'd say it's time we see some Rogue performance in GLB2.7 and then we can move on to GLB3.0 later for another session of single digit framerates glory ;)

By the way I'd love to know why the Adreno330/S800 results have been removed from the GLB2.7 database. Was there something wrong with the score? Apple protested for losing the top spot and Kishonti felt sorry for them what? :LOL:
 
So is Alpha blending a weakness of the Series 5 PowerVR GPUs,
Err? If you are saying that 1000 layers of transparent triangles renders slower than 1000 layers of opaque triangles, then, in that sense, alpha blending is "weaker" than not alpha blending, but that's nothing to do with the shader hardware.

If you mean alpha testing, that's a different beast entirely, because it enforces an interaction between the texturing unit and the HSR/visibility test.
 
Err? If you are saying that 1000 layers of transparent triangles renders slower than 1000 layers of opaque triangles, then, in that sense, alpha blending is "weaker" than not alpha blending, but that's nothing to do with the shader hardware.

If you mean alpha testing, that's a different beast entirely, because it enforces an interaction between the texturing unit and the HSR/visibility test.

Having done more reading on the subject, I should have said 'alpha testing' / discard, which I now understand is something that Imgtec strongly recommends not to use, because of its effect on their HSR routine, am I right?

Kishonti informatics tweeted that alpha testing is used on the foliage elements of GLBenchamrk 2.7, I suppose this is why even the mighty SGX 554 MP4 is struggling to fend off its rivals vs 2.5.1.

As alpha test / discard is standard part of OpenGL 2.0, I cannot see any reason why the GLBenchmark team should not have used it in 2.7. A more open question, if an Android game developer wanted to use alpha test, they would be forced to rewrite parts of their code for PowerVR platforms to achieve optimal FPS, is that a valid statement?
 
I think it's most correct to say that we don't mind use of discard where it makes sense. Yes it causes some extra work for the hardware but it should have considered use by the developer. It doesn't help any GPU that does pre-pixel shading optimisations based on early Z reject, so it's not just our architecture where performance can suffer if you don't use it only where needed.

So no rewrite required, just considered usage.

2.7 makes heavy use of it in some frames but they don't really have much choice given the types of scene they're rendering, and they use it optimally (we helped them out with that in recent times).
 
I didn't want to open a new thread for it. Kishonti has released GFXbench4.0. Car chase looks beautiful and quite well done IMHO for which the X1 GPU delivers an impressive 30fps average in 1080p offscreen, which doesn't come much as a surprise considering how powerful the GPU is. There's also a low level Tessellation test for all the DX11 ULP mobile GPUs. Adreno4xx GPUs seem to do quite well in both forementioned tests.

I'm curious to see if ARM Malis are able to run the Car chase and Tessellation tests and at which framerate. Other than that nothing much has changed compared to GFXbench3.1.
 
Last edited:
You don't need to have a DX11-capable GPU to run the tessellation test. The extension for OpenGL ES is present in the Android Extension Pack and 3.2, and neither of those specs require a GPU that is also DX11 compliant. I mention it because lots of our GPUs fit into that category.
 
I didn't want to open a new thread for it. Kishonti has released GFXbench4.0. Car chase looks beautiful and quite well done IMHO for which the X1 GPU delivers an impressive 30fps average in 1080p offscreen, which doesn't come much as a surprise considering how powerful the GPU is. There's also a low level Tessellation test for all the DX11 ULP mobile GPUs. Adreno4xx GPUs seem to do quite well in both forementioned tests.

I'm curious to see if ARM Malis are able to run the Car chase and Tessellation tests and at which framerate. Other than that nothing much has changed compared to GFXbench3.1.

Result for Mediatek's MT6755, using a Mali-T860, apparently an MP2: 2.5 fps for the Car Chase, 8.1 fps for the tessellation test (both offscreen).

Like all previous Malis, Mali-T860 does not have any tessellation HW; it's all compute shaders.
 
That doesn't sound all too bad for a solution that runs tessellation through compute shaders.
 
Back
Top