Broadcom BCM2763 or Videocore IV

[codedivine]

Anyone have any details of BCM2763 using VideoCore IV? These are likely the GPUs being used in the new Nokia 701/700/600 phones. Yes I know I know, nobody here seems to care about Symbian but will still be interesting to know purely from a technical perspective.

Nokia employees have stated the following so far:
1. 128MB of graphics memory
2. 1 Gigapixel fillrate compared to 200Mpixel on N8
3. No one has confirmed that they are using BCM2763 but thats the assumption
4. Higher clock speed than earlier but thats a given

It is likely a 40nm part correct? Any info about the architecture? Broadcom site has almost zero info about this.

 

[codedivine]

Found a press release: http://www.broadcom.com/press/release.php?id=s430181
BCM2763 is made on 40nm and includes 128MB LPDDR2 on-package. Broadcom quote upto "4x to 6x" performance increase over VideoCore III.

 

[Rys]

It's also the SoC used in the Raspberry Pi. I don't think any early GPU performance analysis exists at this point, and from following the Raspberry Pi dev blog it seems they have some driver issues to work out on the 3D side before that becomes useful (although I'm only going on their Q3 perf).

 

[Exophase]

The SoC in Raspberry Pi is BCM2835. Not sure how it differs but I doubt it has on-package DRAM. Liz (I believe an R-Pi contributor and Broadcom employee) made the following comment on the forums:

"The multimedia performs really, really well (part of our mobile phone chip dividend; you're basically looking at something that outperforms a Tegra 3 and doesn't get hot)."

This is supposed to be in regard to the GPU. Of course I'm pretty skeptical.

I'm not sure if it has driver issues or if there are issues in something else userspace linked with Quake 3, but whatever it is the video alludes to performance impact being CPU-side and not in how the GPU is utilized.

Apparently the Roku 2 also uses this SoC.

 

[codedivine]

That Raspberry Pi project is extremely interesting, thanks for the mention! As Exophase said, the graphics core there does not seem to have packaged memory.

The mentioned Nokia phones are using 1GHz ARM11, 512MB of system RAM and (likely) VideoCore IV with its own 128MB LPDDR2 as mentioned so its a different SoC but the same graphics core. On the N8, the graphics chip has its own coprocessor for things like compiling the shaders (which I found quite interesting) etc., so I am assuming its a similar arrangement in the new phones too. Not sure whats done in the BCM2835 of the R-Pi.

Do other graphics cores (eg any of the SGX cores or adreno) also use coprocessors for handling things like shader compiles or are they done on the main CPU of the system?

 

[Rys]

Ah yes, it's not the BCM2763 in the Pi, my mistake there.

 

[I.S.T.]

The SoC in Raspberry Pi is BCM2835. Not sure how it differs but I doubt it has on-package DRAM. Liz (I believe an R-Pi contributor and Broadcom employee) made the following comment on the forums:

"The multimedia performs really, really well (part of our mobile phone chip dividend; you're basically looking at something that outperforms a Tegra 3 and doesn't get hot)."

This is supposed to be in regard to the GPU. Of course I'm pretty skeptical.

I'm not sure if it has driver issues or if there are issues in something else userspace linked with Quake 3, but whatever it is the video alludes to performance impact being CPU-side and not in how the GPU is utilized.

Apparently the Roku 2 also uses this SoC.

Outperforming a GPU not out yet? Impressive.

 

[Deleted member 13524]

From the official Nokia Blog:

Behind the screen is a brand new graphics co-processor, with a faster clock and four times the graphics memory of previous Symbian smartphones.

a) There's dedicated graphics memory
b) It's 128MB


I can't think of anything other than BCM2763 going into Nokia 701.
However, only this model boasts about the better graphics hardware. I wonder if the 600 and 700 still carry the old (and cheaper?) BCM2727.


Also, the BCM2763 is capable of 1080p video recording and 1080p H.264 high-profile decoding.
Lack of HDMI output could be explained by cost and space decisions (it's a shame if they never release a HDMI-equipped phone with this hardware though), but I wonder why Nokia isn't enabling 1080p recording off-the-shelf.
A limitation imposed by the sensor itself?

 

[Deleted member 13524]

Some Nokia 701 GLBenchmark 1.1 results are in, device specs confirm it's a Videocore IV, a BCM2763.

Comparably to the BCM2727, it goes from more than 2x its performance all the way to ~5x in a couple of tests (except for the CPU scores, where it's using the same ARM11 CPU at 50% higher clocks).
Fill-rate tests show about 2x the performance of Tegra 2 (tablet version) and 1/3rd the performance of the SGX543MP2 in iPad2.

It tops almost all the synthetic tests in GLBench 1.1, most probably due to the gpu performance/screen resolution ratio of the device.

Here's hoping the GLBenchmark team will provide support for Symbian Anne/Belle in the future for the 2.1 and 2.5 benchmarks.

 

[Ailuros]

I simply love it when people again and again are forgetting the differences in resolutions amongst other things. 640*360 compared to 1024*768 and 1280*752 and even fill-rate comparisons on top of that? The iPad2 screen has 3.4x times more pixels and the Transformer 4.2x.

 

[Deleted member 13524]

I simply love it when people again and again are forgetting the differences in resolutions amongst other things. 640*360 compared to 1024*768 and 1280*752 and even fill-rate comparisons on top of that? The iPad2 screen has 3.4x times more pixels and the Transformer 4.2x.

Someone woke up with a severe case of trigger-happyness today..


The fillrate results in the glbenchmark are resolution-dependant (it appears the total number of pixels is multiplied by the frames per second or something similar), wich is why the iphone 4 and ipad 1 have the same results, as well as smartphones and tablets with Tegra 2., or why the ZTE Blade (MSM7227 + 800*480) gets the same fillrate results as the Xperia X10 Mini (MSM7227 + 320*240).


The rest of the tests in Nokia 701 show very high results most probably because of the low resolution, just as I stated before.


Nonetheless, there's no need to get all sarcastic..

 

[JohnH]

I'd be more concerned about comparison of vsync locked devices to a non vsync locked device, looking at both ipad2 and transformer it's prety clear thathe majority of the tests are tied to vsync rate...

Basically need GLB2.1 for any meaningful comparison.

 

[Lazy8s]

The Pro test, having been implemented with the same assets in both GL ES 1.1 and 2.0, makes for an interesting point of comparison.

Under GL ES 1.1, the Nokia 701 achieves 25 fps and the iPad 2 scores 37 fps. Under 2.0 with the vsync limit off, iPad 2 moves it to 150 frames per second.

 

[Deleted member 13524]

I'd be more concerned about comparison of vsync locked devices to a non vsync locked device, looking at both ipad2 and transformer it's prety clear that the majority of the tests are tied to vsync rate...

Most of them, yes. But not the fillrate ones. The test also shows the frames per second on that score and the iPad2 gets between 19 and 34fps. Asus Transformer gets ~4 fps. That test is definitely not being limited by vsync.

Basically need GLB2.1 for any meaningful comparison.

Of course. The offscreen test in 2.1 is probably the best multiplatform apples-to-apples test available right now. It's a shame that the glbenchmark team haven't made the benchmark available to Symbian^3 devices, as it would cover several million handsets.

The Pro test, having been implemented with the same assets in both GL ES 1.1 and 2.0, makes for an interesting point of comparison.

Under GL ES 1.1, the Nokia 701 achieves 25 fps and the iPad 2 scores 37 fps.

That's with "CPU skinning". On "GPU skinning" the Nokia 701 actually gets faster.

 

[Ailuros]

Someone woke up with a severe case of trigger-happyness today.

Irrelevant content ignored.

The fillrate results in the glbenchmark are resolution-dependant (it appears the total number of pixels is multiplied by the frames per second or something similar), wich is why the iphone 4 and ipad 1 have the same results, as well as smartphones and tablets with Tegra 2., or why the ZTE Blade (MSM7227 + 800*480) gets the same fillrate results as the Xperia X10 Mini (MSM7227 + 320*240).

Of course are they resolution dependent; however accepting that results are actually resolution dependent I'll leave it to you to define the accuracy of your following sentence:

Fill-rate tests show about 2x the performance of Tegra 2 (tablet version) and 1/3rd the performance of the SGX543MP2 in iPad2.

As long as all 3 devices do not run at the same resolution and there's a different multiplier in the equasion, the comparison is useless. Further to that I don't know how many TMUs the Videocore4 contains but I severely doubt it has 4.

For the TBDR the effective fill-rate is amount of TMUs * frequency * depth complexity at all times and for the rest TMUs * frequency * depth complexity if and whenever something like early Z rejects data.

The SGX543MP2 is most likely clocked at 250MHz which gives it a peak fill-rate without depth complexity of 1.0 GTexels/s. In 2.1 warm up fill test it slightly exceeds that rate. The Mali400MP4 with 4 TMUs clocked at 267MHz has a peak fill-rate of 1.068 GTexels/s, yet the Hardkernel Odroid A at 1360*768 yields 528 MTexels/s in the warm up fill test.

What we actually need is 2.5 running at 1080p or higher (preferably off screen), since bandwidth will take in such high resolutions even a bigger hit.

The rest of the tests in Nokia 701 show very high results most probably because of the low resolution, just as I stated before.

No one questioned that obviously. The only thing I'm marking for the moment specifically for the fill-rate is that it has effectively tripled in 1.1 compared to the N8. If now Broadcom or whoever else rates the fill-rate a N times higher rate than the actual nearly 400 MTexels/s it yields, the food for thought is above.

Nonetheless, there's no need to get all sarcastic..

Irrelevant content ignored.

 

[darkblu]

That's with "CPU skinning". On "GPU skinning" the Nokia 701 actually gets faster.

That GPU skinning raises some questions, given GL_OES_matrix_palette is not among the cited extensions on the 701st.

 

[Deleted member 13524]

Irrelevant content ignored.

Maybe if you hold of a bit on the flamey sarcasm next time, we'll both avoid this "irrelevant content"?

Of course are they resolution dependent; however accepting that results are actually resolution dependent I'll leave it to you to define the accuracy of your following sentence: (...)

I think I didn't write what I meant, hence the confusion.

The formula to attain the fillrate score has the number of rendered pixels as a variable, so that the score itself presents as the GPU capabilities and doesn't vary with the device's resolution.


You can re-check that by looking at the Marvell Armada 1080p tablet and 480*320 phone, using the exact same SoC, RAM, etc and achieving the exact same fillrate score -> Using GLBenchmark 1.1.

 

[darkblu]

I think I didn't write what I meant, hence the confusion.

The formula to attain the fillrate score has the number of rendered pixels as a variable, so that the score itself presents as the GPU capabilities and doesn't vary with the device's resolution

All results given in {pixels | texels}/s should be resolution-independent, vsync non-withstanding.

 

[Deleted member 13524]

All results given in {pixels | texels}/s should be resolution-independent, vsync non-withstanding.

I'm no expert but I thought as much.. Which is why I don't really understand Ailuro's criticism to the fillrate comparison I made between Nokia 701, an iPad2 and a Tegra 2 device, given that the 701 isn't vsynced (there are scores with 275fps) and the other devices show a framerate well below the 60fps vsync threshold.

 

[darkblu]

I'm no expert but I thought as much.. Which is why I don't really understand Ailuro's criticism to the fillrate comparison I made between Nokia 701, an iPad2 and a Tegra 2 device, given that the 701 isn't vsynced (there are scores with 275fps) and the other devices show a framerate well below the 60fps vsync threshold.

Yes, I read your argument with Ailuros. Unfortunately the presence of vsync cannot be easily discarded even for results that are not capped by vsync. Of course, the lower the result, the less it will be affected by vsync, but even for something like 25fps (40ms frame duration), you can have up to 16ms of vsync waits, based on sheer bad luck of having your frames posted shortly after the previous vsync cycle. As you can see, 16/40 is not a negligible 'ballast' to speak of. Those 25fps could actually be anything between 25 (your frames were lucky to always come at a vsync) and 41fps (your frames always took a full 1/60th of a sec hit) once you turn vsync off. Even if we assumed luck to be impartial, say 50/50, you'd still be looking at (25 + 41) / 2 = 33fps of potential performance at vsync off, for the same '25@vsync-on' case - that's a 32% gain from vsync off.