Home Forums Programming Multi-threading on the 360

Viewing 6 reply threads
  • Author
    Posts
    • #7528
      Anonymous
      Inactive

      I’ve been doing some research on multi-threading techniques on current-gen platforms and I seem to have hit a wall with regards those used on the 360. I’ve seen mentions of high-level APIs such as OpenMP being used, as well as various tidbits appearing on XNA related articles on MSDN and mentions of the XMCore addition to the XDK however I haven’t found anything concrete yet.

      As such, I’m just wondering if those of you with more experience in this area would be willing to shed some light on the situation or if you know of any important resources I may have missed along the way. :)

    • #44959
      Anonymous
      Inactive

      The Xbox operating system is a bit like Windows (without the actual windows):

      http://blogs.msdn.com/xboxteam/archive/2006/02/17/534421.aspx

      Threading is done through the normal Win32 API (or at least, an API that is functionally similar to the Win32 API in that regard). Like the linked article says- CreateThread, WaitForSingleObject etc. are the same on both platforms.

    • #44963
      Anonymous
      Inactive

      the 360 sdk is usually locked behind NDA’s, so the next best thing (IMO) is to check what the hardware manufactures release.

      the Xenon is a PowerPC at its core (pun intended – of course), so IBM’s site should be worth a visit.

      EDIT: check this out, http://www.ibm.com/developerworks/power/library/pa-fpfxbox/index.html?ca=drs-#figure1

      B.

    • #44964
      Anonymous
      Inactive

      Well i’ve got a good bit of experience on all 3 platforms. It is true that 360 and pc are similar and use reasonably similar methods. Ps3 is obviously quite different. For ps3 there’s a very good spu book on amazon, I’ve used it a bit. Great insight. As for open mp I can’t imagine many ppl use It in the industry in reality. It’s great for gamaustra articles as it’s all open source and the general reader can download and experiment. Of ya got more specific questions shoot me a pm

    • #44967
      Anonymous
      Inactive

      Thanks for the info guys, much appreciated! :)

      What I’m trying to do is examine the circumstances that surrounded the shift from the first generation of single threaded 360 games (bar the exceptions like Kameo) to the more modern titles such as Bionic Commando, which not only have a multi-threaded engine but also a threaded renderer. Specifically looking at whether this was due to increased familiarisation with the hardware or whether new techniques were adopted (such as those mentioned in my OP). Of course, attempting to explain this without knowing what’s going on behind the scenes has been the challenging part. ;)

      I dropped you a PM the other day Peter but I just assumed you’d be busy as hell around this time of year. I’ll pop a new one off with some more specific questions now though, ta!

    • #44966
      Anonymous
      Inactive

      The GDC presentation on the Saints Row scheduler sounds like it might be helpful if you haven’t seen it already:

      http://www.volition-inc.com/gdc07/GDC2007_Turner_Randall_Scheduler.ppt

      Broadly speaking, the "circumstances that surrounded the shift" were that the first generation of titles started development on alpha kits that were quite different to the shipping hardware (see the linked powerpoint)- and also, that there wasn’t much precedent (or incentive) for architecting a game engine to distribute over many cores up to that point.

      There hasn’t, to my knowledge, been any "new techniques" that weren’t already known at launch (though maybe not codified in shipping APIs), it just takes time to rework all of that code to be parallelizable and AAA game development doesn’t turn on a dime.

    • #44968
      Anonymous
      Inactive

      The shift as you call it is the ability to adapt to the new hardware. Launch title games typically tend to be just a port from what you know (i.e. the last iteration of the platform with some nice new shaders blah, but architectural often very similar, its lower risk!). You dont really decide to make a launch title and do everything in one giant leap, cause the risk is high and you often dont know what your making anyway. Then as you iterate through the console lifecycle you take what you have a build on it. Classic example is last gen, the games got better and better as the cycle went on. Code base existed, was optimized extend. Its the natural order.
      As for Bionic Commando they threaded everything and I suspect that might be a reason why it was delayed so long, especially if they had to revamp old system to make them threaded or even write from scratch. Vey high risk indeed!

      As for the techniques they dont really differ much from what you’d expect. You typically have a job manager thread which fetches from a queue which then spawns a thread ( or puts the job on the worker thread), then waits till its done or spawns off another if you got multiple worker threads using semaphore etcs to control access to the worker context. How you decide on what jobs to choose comes down to priorities or a scheduler. Its you classical computer science actually. How the job is executed then depends on hardware. i.e on PS3 you have to dma the work to the spu before you can execute, then dma back the results. 360 is easier you generally memcopy to the local storage of the thread.

Viewing 6 reply threads
  • The forum ‘Programming’ is closed to new topics and replies.