How many developers are using all 3 cores for X360?

I know Itakagi of DOA 4 said the screenshots you have been seeing is running on 1 core, so im wondering how many games are there which are using all 3 cores for Xbox 360. Unlike PS3 where you have to use some if not all the SPEs instead of only the Core PPC, Xbox 360 games can be made on one core only , so which ones are using all 3 of them.
 
onetimeposter said:
Unlike PS3 where you have to use some if not all the SPEs instead of only the Core PPC

You could use the PPE for a game alone, you don't HAVE to use SPUs, but it'd obviously be a monumental waste of potential.

onetimeposter said:
Xbox 360 games can be made on one core only , so which ones are using all 3 of them.

Not sure if we can know about all games, but to get the ball rolling, a new engine from Inis called nFactor2 is using all 3 cores. Carmack also discussed a little about how he would be using the second and third cores.

I think it's a safe bet that any game using physics middleware (or other types perhaps also), for example, will be using more than one core.
 
Last edited by a moderator:
onetimeposter said:
When developing for starting at one core, do they have to code for the 2 threads or can developers use 1 thread per core.

They could use 1 thread per core, nothing saying you have to use 2. Again though, to get best performance it probably would make sense in most instances to consider what you could spin off into its own thread to at least use a second thread on that one core.
 
probably none, I'm sure most first gen games will really on one core with a few threads touching the other 2 here and there. I"M not convinced that this whol e IO multi-threaded thing si were the future is, gonna be an interesting generation for gamers and next 5 years for developes in general.
 
onetimeposter said:
so does that explain why there seems to be monumental difference in frameratein some games compared to others?

The reasons for any framerate problems would be very specific to from game-to-game. There isn't one common explanation. For some devs, it's perfectly normal for a game to operate at a low framerate for a very long time (i.e. a "get it working first, optimise later" approach). For others, something like CPU usage could be an explanation as noted above (although there are any number of other technical reasons why that might be).
 
Titanio said:
They could use 1 thread per core, nothing saying you have to use 2. Again though, to get best performance it probably would make sense in most instances to consider what you could spin off into its own thread to at least use a second thread on that one core.

I wonder...since a core in the X360 CPU seems so similar to the PPE in Cell would a core behave in a very similar manner.

I'm thinking of Deano Cleaver's comments as to not thinking of the PPE as a single 3.2GHz core but two 1.6GHz cores. If you would only use thread on the PPE you would be effectively using a 1.6GHz CPU.

Would doing the same thing with a core on the X360 be much the same thing? If so it seems that not utilizing that second logical thread/core is awful waste of potential. If I'm wrong then using one thread with what would be still essentially be a 3.2GHz CPU then seems much more palletable.
 
scificube said:
I wonder...since a core in the X360 CPU seems so similar to the PPE in Cell would a core behave in a very similar manner.

I'm thinking of Deano Cleaver's comments as to not thinking of the PPE as a single 3.2GHz core but two 1.6GHz cores. If you would only use thread on the PPE you would be effectively using a 1.6GHz CPU.

Would doing the same thing with a core on the X360 be much the same thing? If so it seems that not utilizing that second logical thread/core is awful waste of potential. If I'm wrong then using one thread with what would be still essentially be a 3.2GHz CPU then seems much more palletable.

I don't know for sure, but I'd wager that not using the second thread would be to ignore greater potential performance. I'm not sure how much your first thread would gain by having the core to itself. Perhaps someone with a more intimate knowledge of that can answer better.
 
considering cell is the only processor that will dynamically assign threads, spawning additional threads will still only use one core on xenon; however, the gpu does require cache, and possibly cores, to be locked for graphics processing. So I would say your typical elemetry program will definitely only use one core, but most likely, additional cores will be put to use by gpu locking. In other words, using multiple cores in x360 probably has less to do with multithreading, as it may with cell programming, because of assigning.
 
I do not agree that frequency split. There is no add on. Each thread, each core runs on same freq. The problem is how each thread utilizes floating point and integer units. Is each unit divided (one part for one thread, second for second) or it works at some fragment of time for one thread and than for other (like unified shaders for ATIgpu).
 
lip2lip said:
considering cell is the only processor that will dynamically assign threads, spawning additional threads will still only use one core on xenon;

Not neccessarily true. There's more than one way to handle threads, it doesn't even have to be at the hardware level. What would prevent MS from changing the threading-library / mini-kernel or even the kernel scheduler to dynamicly assign threads to available cores upon creation if a core is not specified? Now I'm not saying this is currently available, but why couldn't it be possible?
 
Lysander said:
I do not agree that frequency split. There is no add on. Each thread, each core runs on same freq. The problem is how each thread utilizes floating point and integer units. Is each unit divided (one part for one thread, second for second) or it works at some fragment of time for one thread and than for other (like unified shaders for ATIgpu).

I didn't think the clock-rate scaled linearly or anything but that if I understand you correctly...core clock frequecny is not magically halved by using only one thread per core but effecitively not leveraged because the pool of execution elements is not 1:1 for two threads. So maybe I'm looking at this the wrong way. If the execution elements are not being used by another thread I don't understand why they can't be leveraged. This would mean that the analogy Deano C used was more in line with having limited resources when using two threads. If using only one thread the core could leverage all the resources available at full clock speed so there may actually be advantages to doing this given the task at hand.

Am I on the right track now?
 
Actually, i dont think you only use 1 core ever. I think you have both 3 cores working on something at the sametime allways. But...i could be wrong....i just dont see it as 3 Seperate 3 cpus, its 3 cores but 1 CPU, so you use that CPU wich will use the 3 cores for whatever you are doing. OF course it will depend on the Developer to actually make full use of the 3 cores, but i doubt the other 2 cores sit in idle waiting for the Engine to assign a thread to them.
 
If your code is only single threaded the other cores will sit idle. If you don't fork/pthread_create/whatever into another core I don't think MS's scheduler will automatically place the thread on another idle core from what I understand.

I think MS intended for fewer bigger threads to be sitting out there on the ready list and that giving devs controll over where there go would be a plus. MS also may not want the overhead of a more robust scheduler consuming the fewer resources they have with their chip. I not qualified to say for sure but barring some missing HW functionality they could still beef up the scheduler if they wanted to.

In Sony's case I think they're going with a bunch more smaller threads sitting out there and that trying to deal with them all would have been a hassle. You still can have explicit control I think though. The PPE in Cell was meant to be busy doing this kind of work I feel where alot of the "real" work takes place elsewhere on the SPE's concurently.

I only guessing of course, but it makes sense to me given what we know.
 
As I said, the theory that freq splits as resources of execution core are allocated between different threads is, for me, wrong. If we except that theory than we could come to absurd fact that X2cpu works at 9.6ghz (3x3.2ghz).
My understandment is that both threads of one core have same basic execution units, and that effect of those units go to both threads somehow (do not know how for sure), but both threads are autonomous: "logical cpu-s". Sounds a bit contradictory.
Each X2cpu thread can be delegated by game maker with "system data" function or "basic geometry" function. There is no strict hierarchy between cores as in cell, where main core (ppe) cares for spes as a boss.
 
BRiT said:
Not neccessarily true. There's more than one way to handle threads, it doesn't even have to be at the hardware level. What would prevent MS from changing the threading-library / mini-kernel or even the kernel scheduler to dynamicly assign threads to available cores upon creation if a core is not specified? Now I'm not saying this is currently available, but why couldn't it be possible?

like hd-dvd, it is a possibility, until you consider how much ms makes selling kernel scheduling, i believe there is a reason you have not seen it yet, and will not.
 
I'm not understanding the logical core issue as well as I thought I did.

If you can dual issue do you:

A. Effectively have two CPU's operating at full clock-rate? Effective as in being able to do the same amount of work as two CPUs at the frequency the chip operates ignoring the obvious inefficiencies and overhead. This would imply there are enough execution elements for both threads to run at full clock rate without fighting for resources.

B. Effectively you have 2 threads fighting for the same execution units somewhere in the core so that the net result is both threads run about half as fast?

C. This is something more related to how the architecture logical threads?

A is a good argument for logical threads.

B is a bad argument for logical threads. Effectively using 2 threads you still can only do the work 1 thread would have allowed for. You can still have very unrelated tasks going on and hide latencies etc but in the overall the argument for logical cores seems pretty weak especially considering the inherent losses to performance due to overhead etc.

I have to think A is closer to the truth.

If so I have some concerns about MS's CPU. There is only one VMX unit per core IIRC so there could be a case where this resource is being consumed by one thread and the other has to wait for it to free up thus cutting into the benefit of having 2 threads on one core. Is this in actuality a problem or could the VMX unit handle the requests of both threads simultaneously somehow?

If I understand correctly the DD2 version of Cell has two VMX units in the PPE. Could this revision to the design be driven by the need to correct the afore mentioned possible problem? If so and this particular problem is no more...what would have Deano C look at the PPE as two 1.6GHz CPUs vs. two 3.2GHz CPUs? If the PPE really is to be looked at in this manner then the value of it being dual issue seems greatly diminished to me.

Anyone more qualified than me wish to spare a few moments to comment on this?
 
lip2lip said:
like hd-dvd, it is a possibility, until you consider how much ms makes selling kernel scheduling, i believe there is a reason you have not seen it yet, and will not.

It's not that difficult to have the kernel scheduler do this for you. It may even already be built into it. And actually, anyone who's had at least one comp.sci course in Operating Systems should be capable of completing such a task. Also, it's in MS's best interest to make their console be the best it can be by providing the best toolsets they can to the devs. From this they indirectly gain monetary compensation in license fees as a portion of every title sold as well as mindshare.
 
Lysander said:
There is no strict hierarchy between cores as in cell, where main core (ppe) cares for spes as a boss.

This is not a strict arrangement in Cell either, or would not appear to be.
 
Back
Top