Samsung Exynos 5250 - production starting in Q2 2012

[Nebuchadnezzar]

I thought I mentioned the CPU thing too.

I think that's not cheating per se; this is to solve the fundamental problem of badly written benchmarks that don't take into account DVFS. As a default going from idle to full frequency takes 400ms. Benchmarks like quadrant where the tests are only a few seconds are really inconsistent because of this. Benchmarks should ideally "warm up" for 1-2 seconds before doing their actual tests, which nobody does.

The boost_mode thing which he mentioned is a cheat, it raises the thermal limits by 10°C and avoids falling back to A7s.

 

[Gitaroo]

lol, shamesung, reminds me of the Geforce FX days.

 

[french toast]

K

I thought I mentioned the CPU thing too.

I think that's not cheating per se; this is to solve the fundamental problem of badly written benchmarks that don't take into account DVFS. As a default going from idle to full frequency takes 400ms. Benchmarks like quadrant where the tests are only a few seconds are really inconsistent because of this. Benchmarks should ideally "warm up" for 1-2 seconds before doing their actual tests, which nobody does.

The boost_mode thing which he mentioned is a cheat, it raises the thermal limits by 10°C and avoids falling back to A7s.

Nebu you are now famous.
http://m.bbc.co.uk/news/technology-23512887

nice to see some proper reporting and the correct origin of this info.

 

[Deleted member 13524]

K

Nebu you are now famous.
http://m.bbc.co.uk/news/technology-23512887

nice to see some proper reporting and the correct origin of this info.

LOL

The issue was first raised by a contributor to the Beyond3D forum on Saturday.

They think Nebuchadnezzar posted that last Saturday! They probably saw it was written on the 27th and assumed it was July.
Go BBC!

 

[Turbotab]

LOL



They think Nebuchadnezzar posted that last Saturday! They probably saw it was written on the 27th and assumed it was July.
Go BBC!

Typically well researched BBC Technology article, and I quote "The Exynos 5 Octa uses GPU technology licensed from British firm ARM" Poor old Imagination Technology

 

[french toast]

Lol the finer details I had noticed were cocked up, I was focussing more on the proper source however, something I was quite surprised about, usually the bbc would miss such things.

 

[lanek]

Edit: not see you have allready posted the samung response.

But anyway, other source.
http://www.androidpolice.com/2013/0...ively-changing-gpu-frequency-in-certain-apps/

 

[mczak]

Typically well researched BBC Technology article, and I quote "The Exynos 5 Octa uses GPU technology licensed from British firm ARM" Poor old Imagination Technology

Well the sentence is technically correct. There's two Exynos 5 Octa (5410 and 5420) and one of them indeed uses GPU technology licensed from ARM. They did not claim directly this was the part used for the benchmarks .

 

[Alexko]

K

Nebu you are now famous.
http://m.bbc.co.uk/news/technology-23512887

nice to see some proper reporting and the correct origin of this info.

Wow, I did not expect this to make it into mainstream news. It's nice that they credited Nebuchadnezzar, even if they did get a few details wrong.

 

[wishiknew]

Edit: not see you have allready posted the samung response.

But anyway, other source.
http://www.androidpolice.com/2013/0...ively-changing-gpu-frequency-in-certain-apps/

That's a very interesting response in its own way.

 

[tangey]

Moving the discussion sideways, I see the further follow-up by anandtech suggests one of the very few 1st party apps that does run the gpu @ 532mhz is the camera app, and they say it does so when applying filters.

This could be an indicator that samsung are using SGX GPGPU compute to do the filtering. IMG were demoing this a good 18 months ago on a TI chip, showing both a power saving and a performance increase.

http://www.youtube.com/watch?v=sDrz-w1jzEU&list=TLeG3apr1Ma8A

And featured it in a slightly different way a few months back, in their blog.
http://withimagination.imgtec.com/i...compute-on-powervr-with-androids-filterscript

Update.
I see IMG have done a piece on a new 3rd party development board with the 5410 on it (cites the SGX543MP3 running "around 600Mhz")
Interestingly they are supplying android renderscript drivers for it. You can be sure they didn't develop these drivers solely for the development board, so likely they are being implemented by Samsung. The IMG article does reference the renderscript capabilities.

http://withimagination.imgtec.com/i...evelopment-board-with-a-powervr-sgx544mp3-gpu

 

[gribble]

Mali T62x, i.e. Exynos 5420 with T524MP6, and T678 onwards include Forward Pixel Kill, ARM's answer to overdraw:

"In an FPK-enabled GPU, the threads that colour the pixels are not irrevocably committed to complete once they are launched. Calculations already in flight can be terminated at any time if we spot that a later thread will write opaque data to the same pixel location. Since each thread takes a finite time to complete, we have a window in time which we can exploit to kill pixels already in the pipeline. In effect, we exploit the depth of the pipeline to emulate the "psychic" seeing-into-the-future effect that I alluded to earlier.

In fact, it’s possible to do even better than this. By adding a simple FIFO buffer to the start of the pipeline, we can extend the forward pixel kill zone, making it more likely to spot overdraw, and at the same time giving the pipeline the chance to kill threads before they are even started."

http://blogs.arm.com/multimedia/1048-killing-pixels-a-new-optimization-for-shading-on-arm-mali-gpus/

Sounds like real competition to the Powervr TBDR techniques; looking forward to seeing some good comparitive analysis of the 5420 Vs A7.

 

[mboeller]

"In an FPK-enabled GPU, the threads that colour the pixels are not irrevocably committed to complete once they are launched. Calculations already in flight can be terminated at any time if we spot that a later thread will write opaque data to the same pixel location. Since each thread takes a finite time to complete, we have a window in time which we can exploit to kill pixels already in the pipeline. In effect, we exploit the depth of the pipeline to emulate the "psychic" seeing-into-the-future effect that I alluded to earlier.

Delay-streams...lightweight version. :smile:

It seems old ideas never die: https://mediatech.aalto.fi/~timo/ (Presentation from Siggraph 2003)

 

[Ailuros]

Delay-streams...lightweight version. :smile:

It seems old ideas never die: https://mediatech.aalto.fi/~timo/ (Presentation from Siggraph 2003)

Ewwww a blast from the past Does anyone know what the "boys" do these days?

 

[arjan de lumens]

Ewwww a blast from the past Does anyone know what the "boys" do these days?

Let's see. Petri Nordlund has become a development director at Unity Technologies. The Tuomi brothers, on the other hand, have formed a startup "Siru Innovations Oy", which according to their website http://siru.fi/ is a "leading Finnish graphics IP vendor", with very little information beyond that. According to http://www.tomshardware.com/reviews/medfield-krait-smartphone-mobile-soc,3117-9.html, Siru seems to consist mostly of ex-Bitboys people. Blast from the past, indeed.

 

[Exophase]

The ARM blog rather conspicuously leaves out IMG's TBDR method of hidden surface removal, or at least their descriptions don't seem to cover it when they all say the sorting must be done by the application.

Still, nice to see some new sounding techniques (someone let me know if this really was implemented somewhere else first). At first I thought this sounded ridiculous since pixels that overlap are normally drawn pretty far apart, but then I remembered that Mali uses small tiles so you don't need a very big FIFO at all.

 

[tangey]

This would appear to be another difference between T604 and the rest, as T604 doesn't get a mention. T604 also doesn't have their new texture compression.

 

[Ailuros]

Let's see. Petri Nordlund has become a development director at Unity Technologies. The Tuomi brothers, on the other hand, have formed a startup "Siru Innovations Oy", which according to their website http://siru.fi/ is a "leading Finnish graphics IP vendor", with very little information beyond that. According to http://www.tomshardware.com/reviews/medfield-krait-smartphone-mobile-soc,3117-9.html, Siru seems to consist mostly of ex-Bitboys people. Blast from the past, indeed.

Thanks arjan; on a sidenote we don't see much of your input these days around here either, while it defintely would be welcome about general technical matters.

 

[Ailuros]

The ARM blog rather conspicuously leaves out IMG's TBDR method of hidden surface removal, or at least their descriptions don't seem to cover it when they all say the sorting must be done by the application.

Still, nice to see some new sounding techniques (someone let me know if this really was implemented somewhere else first). At first I thought this sounded ridiculous since pixels that overlap are normally drawn pretty far apart, but then I remembered that Mali uses small tiles so you don't need a very big FIFO at all.

I'd like to stand corrected but if a game engine isn't "intelligent" enough to keep from processing unnecessary data then even the best hw HSR is not going to help you for anything. I recall some developers in the past calling hw HSR "low level HSR" and if the former reflects reality in rough lines I can understand why.

Don't get me wrong I don't mean that any of it is useless but I think in the light of what each engine does or should do in terms of data rejection, it's more of an additional feature IMHO to further increase efficiency.

What I'd like to hear and maybe arjan will have the time to give a quick answer: as tiling in mobile GPUs is highly popular I hear from various sides over and over again that (irrelevant whether tile based DR or IMR) tilers spend quite a bit of time buffering when it comes to geometry data. Now it's my understanding this far that there's probably unfortunately no way of "assisting" the whole thing better through APIs. Can someone with some experience in the field correct my possible misconceptions or if I'm close enough to fill in the blanks?

It's a generic question and therefore obviously not contentrated on just one architecture out there.

 

[Nebuchadnezzar]

Interesting tidbit on a newer commit: https://gerrit.chromium.org/gerrit/...it;h=0d644a84db4d0ddf236e4e4ddb321bb40beca198

Seems that the 5420 has some kind of SRAM for the memory interface and GPU that warrants it being run by two additional PMIC regulator rails on their own voltage plane.