[Ailuros]

Originally Posted by tangey

ummmm...shake it ?

That's not what I understand under overflow; nice try though nonetheless.

[Npl]

Originally Posted by Ailuros

How do you get a bucket to overflow when you always empty it in time?

you cant, but thats an analogy for immediate renderers I guess.
With a TBDR you cant render a pixel until you know theres no further triangle that "hits" it - which means you cant empty your bucket until you poured all the water in (finished the scene). Thats assuming the TBDR requires to operate a single pass, if not then it needs to create a incomplete picture (and some information about ZValues) and then it can empty the bucket before accepting more water.

[Ailuros]

Originally Posted by Npl

you cant, but thats an analogy for immediate renderers I guess.
With a TBDR you cant render a pixel until you know theres no further triangle that "hits" it - which means you cant empty your bucket until you poured all the water in (finished the scene). Thats assuming the TBDR requires to operate a single pass, if not then it needs to create a incomplete picture (and some information about ZValues) and then it can empty the bucket before accepting more water.

The 4 cores operate quite in a complicated fashion when it comes to macro- and micro-tiling.

http://worldwide.espacenet.com/publi...068895A1&KC=A1

http://worldwide.espacenet.com/publi...068895A1&KC=A1

Or display list related patents like that one: http://worldwide.espacenet.com/publi...115778A1&KC=A1

[Npl]

Originally Posted by Ailuros

The 4 cores operate quite in a complicated fashion when it comes to macro- and micro-tiling.

http://worldwide.espacenet.com/publi...068895A1&KC=A1

http://worldwide.espacenet.com/publi...068895A1&KC=A1

Or display list related patents like that one: http://worldwide.espacenet.com/publi...115778A1&KC=A1

and how is multicore related to the problems of overflowing buffers?
the problem is that you cant start (fragment-)processing a single tile unless you know there is nothing, like say a translucent triangle above the ones you have in your displaylist, that affects the outcome.
you are limited in the amount of information you can store before you begin rendering, so either you decide to drop something and hope none notices or you render what-you-have and then accept new data (the extreme example beeing immediate renderers, or some "hybrid" renderer that only defers aslong there is space).

[Ailuros]

Originally Posted by Npl

and how is multicore related to the problems of overflowing buffers?

How is it unrelated in this particular thread in the first place? You've got 4 GPU cores in the NGP, so what how and why would overflow? Do you have same sized or dynamically sized macro tiles for all of the 4 cores and one or multiple display lists? I can only imagine they use multi-level display lists (or buffers or whatever one wants to call them), compress the hell out of it and store only the absolutely necessary.

the problem is that you cant start (fragment-)processing a single tile unless you know there is nothing, like say a translucent triangle above the ones you have in your displaylist, that affects the outcome.
you are limited in the amount of information you can store before you begin rendering, so either you decide to drop something and hope none notices or you render what-you-have and then accept new data (the extreme example beeing immediate renderers, or some "hybrid" renderer that only defers aslong there is space).

Don't you think engineers have taken any of those considerations into account? Heck IMG has more than a few patents that affect display list control, compression etc etc. I can't imagine the display list(-s) are that small that they can be overflown that easily and doubt even more that if you manage to overflow that one you wouldn't get an IMR or hybrid whatever into the exact same theoretical trouble.

[Exophase]

IMG's GPUs do have support for multi-pass rendering, they don't have a problem loading a framebuffer from memory (and storing one to memory) if necessary. I'm almost certain that they'll stop binning and render what they have if they run out of space (including the space for the depth/stencil buffer they now need..)

[Npl]

Originally Posted by Ailuros

How is it unrelated in this particular thread in the first place? You've got 4 GPU cores in the NGP, so what how and why would overflow? Do you have same sized or dynamically sized macro tiles for all of the 4 cores and one or multiple display lists? I can only imagine they use multi-level display lists (or buffers or whatever one wants to call them), compress the hell out of it and store only the absolutely necessary.

4 cores only means 4 times the buffer size, doesnt change a thing for me. fixed size is fixed size and dynamic workload can exceed it.

Originally Posted by Ailuros

Don't you think engineers have taken any of those considerations into account? Heck IMG has more than a few patents that affect display list control, compression etc etc. I can't imagine the display list(-s) are that small that they can be overflown that easily and doubt even more that if you manage to overflow that one you wouldn't get an IMR or hybrid whatever into the exact same theoretical trouble.

Im pretty sure IMG has chosen a way to deal with this, however unlikely a problem it might be. Certainly devs on a closed platform will be vary of any limits (which likely are high enough so you dont reach them in realtime graphics) but a generic OpenGL driver surely has to take such things into account. And I just asked which way they deal with the problem (as Im curious of the implications)

@Exophase: Thanks. I guess this could be a reason recent PowerVR GPUs cant guarantee order-independent transparency, the output might dependent on where the rendering is halted and stored possibly truncated (less accurate then one-pass rendering)

[Aeoniss]

Well then..

[Ailuros]

Originally Posted by Npl

4 cores only means 4 times the buffer size, doesnt change a thing for me. fixed size is fixed size and dynamic workload can exceed it.

Not necessarily 4x times the buffer size; unfortunately details are quite sparse and it takes a lot of guesswork what they're exactly doing. However assuming that you have under an instance all 4 cores completely available, if the scene gets split up into 4 viewports/macro tiles why would you need 4x times the buffer size? It's an honest question. Note that the relevant patent for MPs doesn't specify whether one or multiple display lists will be used; it's an either/or option.

Im pretty sure IMG has chosen a way to deal with this, however unlikely a problem it might be. Certainly devs on a closed platform will be vary of any limits (which likely are high enough so you dont reach them in realtime graphics) but a generic OpenGL driver surely has to take such things into account. And I just asked which way they deal with the problem (as Im curious of the implications).

I'd be interested too in an as simple as possible explanation (in order to understand it myself) but I suspect they keep it under wraps as some sort of secret sauce.

In any case if there should be any cases where for whatever reason a DR would be forced to operate as an IMR (always in a highly relative sense) one of its advantages it would lose IMO would be effective fill-rate amongst others. But since in the embedded space GPUs in general don't have excessive fill-rates I don't see it as problem. If the NGP GPU is clocked at 200MHz as rumors want it, then it has 400MTexels and 3.2 GPixels z/stencil raw fill-rates per core.

Besides as Arun already noted, senior Simon's 2bpp & 4bpp PVRTC are a blessing aside other things.

[Rys]

Originally Posted by Ailuros

I'd be interested too in an as simple as possible explanation (in order to understand it myself) but I suspect they keep it under wraps as some sort of secret sauce.

It's not necessarily secret sauce as such, but you're right that we haven't talked about it much in public yet. I'll see about changing that, so there's a bit more information about how MP works at the work distribution and memory costs level.

[JohnH]

Actually I think we can be specific in saying that there is no significant change in memory cost associated with multi-core, I'm not sure why anyone would think there was.

Pretty certain there's been a public talk given on Multi-core by Tony King Smith that explained it's operation pretty well.

John.

[ToTTenTranz]

Originally Posted by ToTTenTranz

Doesn't the GPU-dedicated RAM need to increase in bandwidth as you increase the number of cores? Not theoretically of course, but practically.

You couldn't get a "high-end" version of your GPUs to "infinitely" scale linearly with increasing the number of cores without increasing memory bandwidth, right?

Originally Posted by Rys

Right, but the bandwidth requirement for extra cores is low.

Originally Posted by JohnH

Actually I think we can be specific in saying that there is no significant change in memory cost associated with multi-core, I'm not sure why anyone would think there was.

I'm not trying to start a flamewar between comrades or anything.. but where are we standing exactly?

Is it "so low" that you consider it "non significant"?
What ratios are we talking about? For each 100% increase in cores, you'll need 10% increase in memory bandwidth? More? Less? Not allowed to specify?

[Ailuros]

Series5XT scales up to 16 cores and not more. Ditto though for Series6/Rogue.

In any case if they claim officially themselves that past 16 it doesn't make any sense anymore, then obviously it wouldn't be worth bothering for something over 16 in pure theory for such a hypothetical case.

As for where you're standing, uhmm trust the more experienced one out of the two

[ToTTenTranz]

There's a core amount cap for series 6?

[Rys]

Originally Posted by ToTTenTranz

I'm not trying to start a flamewar between comrades or anything.. but where are we standing exactly?

We said the same thing, just in different words.

Is it "so low" that you consider it "non significant"?
What ratios are we talking about? For each 100% increase in cores, you'll need 10% increase in memory bandwidth? More? Less? Not allowed to specify?

No MP config I know of has considered adjusting memory config to increase bandwidth to help performance, versus single core. We obviously don't want to give away figures (sadly, I'd love to walk you through a profiled frame or frames and discuss the consumers).

[Rys]

Originally Posted by Ailuros

As for where you're standing, uhmm trust the more experienced one out of the two

Where did we say different things?

[JohnH]

Originally Posted by ToTTenTranz

I'm not trying to start a flamewar between comrades or anything.. but where are we standing exactly?

Is it "so low" that you consider it "non significant"?
What ratios are we talking about? For each 100% increase in cores, you'll need 10% increase in memory bandwidth? More? Less? Not allowed to specify?

Hmm, here I'll say it again for you,

Actually I think we can be specific in saying that there is no significant change in memory cost associated with multi-core, I'm not sure why anyone would think there was

[Entropy]

Originally Posted by ToTTenTranz

I'm not trying to start a flamewar between comrades or anything.. but where are we standing exactly?

Is it "so low" that you consider it "non significant"?
What ratios are we talking about? For each 100% increase in cores, you'll need 10% increase in memory bandwidth? More? Less? Not allowed to specify?

This is getting strange - the amount of bandwidth needed per core will depend on what you're trying to do with it. And what the guys from IMG are saying is that if for example Apple wanted to quadruple the number of pixels on the iPad3 and therefore (hypothetically) utilized a 543MP8 configuration or four times the number of cores, those cores would use four times the bandwidth to do the same job, they wouldn't incur any extra penalty.

The real difficulty lies in predicting what types of codes your customer wants to run, what resources will be spent on memory paths, and design for maximum efficiency in terms of gates/power/cost. If you over engineer, then your design will be bloated with baggage that goes largely unused, and you leave an open window for your competitors to do more with less. On the other hand, obviously you want to provide the capabilities that the customer may want, as well as provide juicy new IP to license. So IMG offers both cores with different levels of complexity, and also the possibility to widen many of these to fit perceived need.

What I would like to see is bandwidth usage data for different but typical tasks, for, say, IMG, Mali, and Tegra respectively.

[Shifty Geezer]

Originally Posted by Entropy

This is getting strange - the amount of bandwidth needed per core will depend on what you're trying to do with it. And what the guys from IMG are saying is that if for example Apple wanted to quadruple the number of pixels on the iPad3 and therefore (hypothetically) utilized a 543MP8 configuration or four times the number of cores, those cores would use four times the bandwidth to do the same job, they wouldn't incur any extra penalty.

Yes. And I think some were suggesting that as you introduce more cores, there's an overhead, so instead of being a linear use it's exponential. eg. A linear memory would have 1 core using 5 GB/s, say; 2 cores 10 gb/s; 4 cores 20 GB/s. Whereas the suggestion is with overhead, that where 1 core consumes 5 GB/s, a second would push the total up to 12 GB/s, and quad-core would go to 28 GB/s.

Both Rys and JohnH are telling us that memory usage is linear, based on workload. You'll clearly need X times as much memory to drive X number of cores as they all consume data, but there's no additional penalty.

[Rys]

For the same number of pixels, bandwidth goes up almost negligably when you add cores to work on them. So it's not linear at all (for us anyway) when doing MP.

[Exophase]

Originally Posted by Shifty Geezer

Yes. And I think some were suggesting that as you introduce more cores, there's an overhead, so instead of being a linear use it's exponential. eg. A linear memory would have 1 core using 5 GB/s, say; 2 cores 10 gb/s; 4 cores 20 GB/s. Whereas the suggestion is with overhead, that where 1 core consumes 5 GB/s, a second would push the total up to 12 GB/s, and quad-core would go to 28 GB/s.

Both Rys and JohnH are telling us that memory usage is linear, based on workload. You'll clearly need X times as much memory to drive X number of cores as they all consume data, but there's no additional penalty.

Why would you need X times as much memory for X cores, assuming that their job is to render a scene X times faster than a single core would? The amount of data assets wouldn't increase; same framebuffer size, same textures, and as far as binning is concerned I expect that to be the same too - you'd just be distributing the bins between different cores.

As far as bandwidth goes, there'd be no increase in outgoing to render targets since this is subdivided between cores with no overlap. There may be some instances where the same data needs to be loaded into separate cores where it would have been retained in the cache of a single core, but in that case it'll either stay in the cache of all the cores that loaded it or it wouldn't have stayed in the cache of the single core. In fact, the multiple cores will texture cache better because they'll have smaller working sets but the same amount of cache each (presumably). And if they have a shared L2 cache that's even better; I'd fully expect bandwidth requirements to go down after this, not up. Maybe someone can tell me if Series5XT MP has anything like this (like Mali-400MP does)

(then again, someone please tell me if there's some glaring flaw in my reasoning)

[Ailuros]

Originally Posted by Rys

For the same number of pixels, bandwidth goes up almost negligably when you add cores to work on them. So it's not linear at all (for us anyway) when doing MP.

Yes but if workload increases for a config with N amount more cores, then naturally the bandwidth requirements should increase too. I know it's obviously a dumb clarification since it's self explanatory, but some of us need unfortunately a KISS approach to comprehend it easier.

Else for workload X irrelevant in theory if you have N pipelines from a hypothetical single core vs. the same amount of N pipelines spread over Y cores the bandwidth requirements are fairly similar, yes?

[Shifty Geezer]

Originally Posted by Exophase

Why would you need X times as much memory for X cores,

I missed a 'bandwidth' there.

Originally Posted by Ailuros

Yes but if workload increases for a config with N amount more cores, then naturally the bandwidth requirements should increase too.

Yeah, that's what I was getting at. If you are targeting a more powerful GPU, you'll feed it more data needing more BW. If you have the same graphics workload and start adding more cores, it won't change the bandwidth usage as it's the same amount of data, just being processed faster. Clearly the choice to go with a four or eight core SGX in a device would have to be coupled with a choice to increase RAM BW accordingly to feed them, but not with any overhead that means more cores = less memory efficiency.

[RudeCurve]

Isn't the main benefit of TBDRs is that you don't need to go off-chip as IMRs meaning you need less bandwidth for a given workload?

[ToTTenTranz]

Originally Posted by Shifty Geezer

Clearly the choice to go with a four or eight core SGX in a device would have to be coupled with a choice to increase RAM BW accordingly to feed them, but not with any overhead that means more cores = less memory efficiency.

That was exactly the info I was looking for.

By increasing the number of cores, one assumes the purpose is to also increase the number of rendered pixels, increased geometry, post-processing effects, higher-resolution textures, etc.
And by doing so, the SGX5 architecture would naturally need to also increase the memory bandwidth available for the whole GPU (and not memory bandwidth per-core), or the graphics subsystem would face a bottleneck eventually.


Maybe for not using the right terms, the answers I was getting were not for the question I made, hence all the confusion.