ARM Community: Multicore or Multi-pipe GPUs: Easy steps to becoming multi-frag-gasmic - ARM Community

The ARM Mali-400 MP was the world’s first embedded multicore graphics processor (GPU) when it was launched, back in 2008, and Mali-T604 continues that trend. Since then, there have been a number of new GPUs claiming to be multicore and people have asked me lots of questions seeking to quantify what is a “core” versus a “pipeline” and about scalability, so I thought I’d share the answers with a wider audience. My colleague Jem Davies has noted before in his blog that the beginning of wisdom is to call things by their correct names. Graphics can sometimes be a very confusing area for jargon, so this is another in a series of blogs in our quest to explain graphics terminology.

Core vs. pipeline: definitions and examples
The difference between a “core” and a “pipeline” is that a “core” is a self-contained entity which has its own self-contained resources such that it can operate independently of other elements. An instruction pipeline in this context shares all or parts of the resource within a “core” between itself and other pipelines. Pipes also only have a very limited capacity to run independent tasks. This definition is common and well established across CPU, GPU, DSP and pretty much any compute element you can name.

Mali-400 MP is a multicore GPU: it contains a vertex processor and up to four fragment processors. The vertex processor is a core and the fragment processors are also cores: they run independently on separate tasks and contain their own critical resources. Within each Mali-400 fragment processor there is one pipeline, however it has a very complex pipeline which has several sub-pipelines to handle different tasks.

Mali-T604 is a multicore GPU, which can contain up to four cores, with each core being able to operate independently and again containing its own critical resources. The tri-pipe architecture in the Mali-T604 means that each core contains three different types of pipelines (four in total): 1x load/store, 1x texture, 2x ALU. Again, the individual pipelines are complex, containing sub-pipes.

Scaling by core gives deterministic performance
Mali-T604 scales by numbers of cores – that is you can build SoCs with different numbers of cores. (You can also scale dynamically by powering cores up and down.) Some other GPUs choose to scale by pipeline – putting more pipelines within a core. With such a design, the GPU is exposed to the potential of compute limitation due to resource contention. In an environment where you have many pipelines all competing for register, cache and texture fetch resources then you either have to grow the resource to compensate (more registers, bigger cache) or potentially have a core with non-deterministic performance. This phenomenon can be seen in some superscalar CPUs: the addition of a second pipeline, although increasing the compute potential, does not increase the performance by 2x, but some considerably smaller factor due to the contention for resource.

Unlike scaling by pipeline, scaling by core is more deterministic as each core yields the given performance level since each core is independent. Adding additional cores increases the potential performance linearly (or very close to linearly). It does not suffer from fundamental resource constraints, as each core has self-contained resource to sustain that performance per core. All this makes scaling by core count much more attractive. By balancing the complexity of the pipeline with “right sized” resources both Mali-400 MP and Mali-T604 have a very compact core size for the performance/feature set they offer. An illustration of this is that Mali-400 MP is half the silicon area of competitor GPUs, but with greater performance.

I hope this clarifies matters. Do you have any further questions?

Ed Plowman, Technical Marketing Manager - Media Processing Division, ARM, Ed has recently returned to ARM Ltd after a stint at Intel where he worked as a games industry evangelist. During his time at ARM Ed guided the graphics processing strategy for a number of years. Ed was also a founding member of Khronos and a significant force in the creation of the OpenGL ES working group. Ed has continued his work within Khronos occupying a seat on the Khronos board of promoters for many years and more recently has taken up the post of Khronos treasurer. Ed started his career as one of the founding members of Argonaut technologies which later became ARC cores, an off shoot of Argonaut Software, working on CPU based 3D graphics technology and later helping create the ARC processor core.