[french toast]

Its good to have this comparison. .although I would have expected 640m LE to be substantially more powerfull than that?.

Ipad 4 doesn't look all that bad too be honest, cant wait to compare the next generation

[Jubei]

Originally Posted by dagamer

Thing is, it actually wasn't that short a time when you compare how quickly the S4 was replaced by the S4 Pro (April to October). And the Snapdragon 600 shipping in March will probably be replaced in September with the 800 (another 6 months). This cadence is pretty unprecedented, especially considering its all on 28nm, though even Samsung is doing a release (Galaxy S) and clock uptweak (Galaxy Note) twice a year too. Even nvidia had multiple Tegra 3 SKUs.

Makes me wonder how sustainable this is.

We are talking about two different things here. S600 is not going to be replaced by S800, it will continue to exist as the mainstream chip whereas S800 will be the high end chip

APQ8064 however has been completely replaced by APQ8064T

[Jubei]

Originally Posted by french toast

Its good to have this comparison. .although I would have expected 640m LE to be substantially more powerfull than that?.

In actual games it is

[Helmore]

Originally Posted by Jubei

In actual games it is

That makes you question the use of this benchmark.

EDIT: Forget I said anything, see ams' post below this one as to why.

[ams]

Originally Posted by ltcommander.data

http://www.anandtech.com/show/6872/t...dxbenchmark-27

Anandtech has done a bunch of GL/DXBenchmark 2.7 tests. They confirm that T-Rex HD is shader heavy with a 165% increase in shader complexity compared to Egypt HD whereas geometry, depth, and memory bandwidth has only gone up ~50%. The HD4000 ends up being 2-3x faster than the iPad 4's SGX554MP4 in Egypt and T-Rex, while the nVidia GT 640M LE (which might give a hint at how a Keplar Tegra 5 would perform) is 20-30% faster than the HD4000.

Apparently Anand had erroneous data on the GT 640M LE-equipped Razer Edge. He has updated the article with corrected data, and now GT 640M LE is ~ 100% faster than HD 4000:

http://images.anandtech.com/graphs/graph6872/53938.png

http://images.anandtech.com/graphs/graph6872/53944.png

The differences may be even more pronounced with games (depending on the game and the detail settings).

On a side note, the Fill Rate data on GT 640M LE and HD 4000 still looks strange. How is it possible that GT 640M LE and HD 4000 gain ~ 50% and 100% texel fillrate, respectively, when moving from Onscreen to Offscreen (1080p)?

[Ailuros]

Originally Posted by ltcommander.data

The GT 640M LE is 20W compared to 17W for the whole Ivy Bridge so it doesn't look that efficient when it only achieves a 20-30% performance difference. It might be something DXBenchmark specific though. And as you say 20W is quite a ways from being Tegra compatible of course, so there's going to be differences, although the GT 640M LE may be what's in Kayla.

In terms of arithmetic throughput yes, but it's obviously not the entire story for GPU performance.

[ams]

Originally Posted by ltcommander.data

And as you say 20W is quite a ways from being Tegra compatible of course, so there's going to be differences, although the GT 640M LE may be what's in Kayla.

Technically Kayla is a not-yet-released GPU that supports OpenGL 4.3 (while GT 640M LE supports OpenGL 4.1). So Kayla is probably a modified lower power version of the newly announced GT 735M.

[Ailuros]

Originally Posted by ams

Technically Kayla is a not-yet-released GPU that supports OpenGL 4.3 (while GT 640M LE supports OpenGL 4.1). So Kayla is probably a modified lower power version of the newly announced GT 735M.

Probably yes; however either way it's hard to believe that it'll be a 1:1 performance mirror for all GPU aspects for the future Logan SoC GPU block. 32 TMUs would be insane in terms of die area and a 8x times increase compared to Wayne in terms of unit amount only, since DX11 TMUs are quite a bit more expensive than DX9L1 TMUs in Wayne.

[ams]

Yes, the Tegra 5 "Logan" GPU will likely be significantly reworked compared to any current Kepler GPU variant (including Kayla).

[Rys]

Originally Posted by Arun

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.

We fixed it

[Turbotab]

Originally Posted by Arun

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

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?

[Ailuros]

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?

[Simon F]

Originally Posted by Turbotab

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.

[Turbotab]

Originally Posted by Simon F

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?

[Rys]

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).