Explain PowerPC/Porting to me....

Discussion in 'Wii U - Console, Accessories and Hardware' started by EnigmaXtreme, May 24, 2013.

  1. EnigmaXtreme
    OP

    EnigmaXtreme GBAtemp Maniac

    Member
    1,343
    24
    Jan 1, 2009
    Tasmania, Australia
    This may a stupid question, if I asked it on NeoGaf I'd probably get abnned

    Lately we have been seeing all these games coming out for the PS360 and even some that are also confirmed for PS4/X1 but barely anything for Wii U.

    This confuses me cause don't Wii U, 360 and PS3 all use the same PowerPC architecture, can someone explain to me how porting to x86 is easier then bringing these games to Wii U.

    Or am I missing something obvious here....
     
  2. Disorarara

    Disorarara GBAtemp Fan

    Member
    309
    41
    Sep 12, 2012
    They are PowerPC based, but that has almost nothing to do with anything really. The easiness of porting between platforms usually has to do with libraries, similarities in GPU architectures or competence of the SDK provided.
     
  3. FAST6191

    FAST6191 Techromancer

    pip Reporter
    23,173
    8,911
    Nov 21, 2005
    It might not be so much difficulty in porting but not worth the effort for the sales the games will get (this need not be profit but the dev time could be spent somewhere else to get a bigger profit somewhere else).

    To answer the question though powerpc is about as broad as saying Intel or even ARM -- they might share some of the same companies and design philosophies but their actual implementations can be radically different. Indeed the 360 is a fairly standard powerpc but the PS3 is a cell which has these things called SPEs (synergistic processing elements if memory serves) which change the game quite a bit.

    Beyond that architecture of the CPU tends not to matter half as much as it did in years past where you might be squeezing every drop out of them and that meant both knowing the processing and coding to it (something most coders are no longer taught let alone code for, if they are even allowed to code for it). Broader architecture choices can still matter but that can be covered later.

    I am not sure quite how to tackle this more fully without going into a general assembly programming, modern graphics programming and computer architecture discussion.
    I can at least go in for a partial glossary sort of thing consisting of terms I have seen floating around the last few weeks/months

    Floating point operations
    Computers tend to work best if you use whole numbers, the dominant way of doing decimal point numbers is called floating point (the DS uses a slightly different method called fixed point, others use BCD, others use log tables and the is also the work around it and "do not put it into the calculator until you have to" method). Depending upon the maths you are doing it is actually pretty poor so you get single precision, double precision, quad precision and further varying grades which allow for bigger numbers to be represented more accurately. Higher precisions may or may not be supported or as fast but they are needed for better graphics, movement, physics.....
    The speed is measured in FLOPS aka floating point operations per second and that is why people like that number in specs lists.

    SIMD -- mainly as the Wii U SIMD operations were trashed by Marcan and co. I do not know if you are familiar with arrays but they are a core component of computing these days ( http://mathworld.wolfram.com/Array.html has some but nicer to read stuff exists elsewhere). Without getting into the boring stuff they look as follows

    (1 1 7)
    (87 88 44)
    (14 487 98)

    If you wanted to multiply that by 4 you multiply each of those numbers, a traditional processor might have had to do this one at a time and that would take ages. SIMD allows you to do it on a the lot at once. This is why video started being a thing around the introduction of MMX way back when. At times I would probably place these ahead of floating point in the list of things a games/multimedia machine has to be able to do. The above is somewhat simplified and for an array like that it is not so bad but start mashing multiple arrays together and doing proper array maths (especially if the array holds floating point numbers) and it gets ugly. SIMD = single instruction, multiple data.

    Multicore -- If I have one processor screaming along at 3 GHz I can double my speed if I have two... actually no but it can get pretty close though the performance rapidly drops off when adding more and more general use processors to the point where it eventually becomes unproductive (see Amdahl's law). This leads to things like the SPE mentioned for cell and the GPGPU stuff I will cover next. Also coding for multicore, especially in an arbitrary/unpredictable environment like games, is a right pain as you do not know what is going on in the other core that easily, you might have to wait or face not having a number to work with (see race conditions) and generally you have to wait for things to happen before you calculate them. The Wii U stuff is considered pretty poor by all accounts where the others do better, it is not fatal but not ideal.

    GPGPU -- 3d graphics like floating point numbers, no way around it really. As general purpose CPUs were not getting good enough at a fast enough pace we got graphics cards (GPU) that did it for us. Several years later people realised that graphics cards were powerful little things in their own right and it might be nice to code for them. Graphics card makers opened up accordingly (it was not the first but you might have heard of CUDA) and even added a few options for things graphics cards tended not to have to do (some general purpose instructions, hence GP-GPU). The added a few options thing was nice as there is a serious performance hit associated with piping data between general memory and the CPU, general memory and the graphics card and the CPU and the graphics card. However much like normal multicore (graphics cards can have hundreds of cores) it is a right pain to do well which is why few ever have really (however many years on this is and I still do not have a graphics card H264 encoder I can trust to make quality video). That performance hit between the CPU and memory is known as a cache miss (too much data to hold in the CPU so it has to go looking in memory) and is why some are talking about the cache on various systems being larger.
    The SPE stuff is kind of odd and is like a cut down processor in the CPU itself which dodges issues with having to fire data around and dodges many issues with having to manage large amounts of processors -- it was pretty radical at the time and did offer a massive performance boost if you could use it, again most programmers are not too capable of this and Sony fluffed the SDK so not many could truly take advantage of it.
    Graphics can also be quite different in what they expect in, what they will do and how they work (shaders are things in the graphics processor but shader languages are programming languages almost unto themselves).

    out of order execution. I would largely accuse it of being a buzzword but I will cover it anyway. Processors basically do one instruction after the other until there are no more numbers that need crunching. Though as mentioned above you do have to wait for things to happen but after that might be some simple numbers that need crunching, here the processor will hopefully do the stuff it is waiting on/will help something else and go back to doing whatever it sidelined. Related to this is pipelining and branch prediction. This is also a reason why few people do assembly level/architecture influenced coding any more as this stuff is really hard to do in your head but the compiler can do OK at it.


    That over for all that I said about it not mattering, coders not coding to the hardware an such it kind of still matters and if your processor does not handle certain types of operations so well and your game engine uses a lot of them (you use a lot of double precision floats but the performance with them is not so hot...) and you get to tweak a lot of things. If you have different types and philosophies when it comes to memory (most consoles do not have the most, even if you consider they do not have to run a whole OS underneath it all) in terms of splits between general memory, graphics memory and whatever else and you designed your game to work better on systems with general memory then even if you are on the same type of processor you are in trouble. Given general computers now far outperform consoles and you can just say "just get a better computer" to any customer it becomes far easier to go to x86.
     
    JPnintendo and Rydian like this.
  4. Deltaechoe

    Deltaechoe The Dopefish

    Member
    511
    132
    May 3, 2012
    United States
    Actually the reason that there are less ports on the Wii U has less to do about the actual technical difficulty of the port and more to do with the profitability of the software sales and the less than optimal support that nintendo gives to their 3rd parties (this has been going on for a long time, since gamecube days at latest). So with hardware sales projections being low, this cripples the profitability of software sales because if a lot of people don't own the console then no one is going to buy software from it, and this doesn't take into account the large cut that nintendo takes too (assuming my information is correct on this). Anyway, that combined with the lack of 3rd party support on Nintendo's behalf is probably the reason why you don't see a lot of third party love for their systems and in some publisher's cases, animosity for it.

    As far as porting things to x86, everyone and their mother has a pc, there are very well established and easy distribution routes (ie steam) and a higher prospective profit margin.
     
  5. Rydian

    Rydian Resident Furvertâ„¢

    Member
    27,883
    8,107
    Feb 4, 2010
    United States
    Cave Entrance, Watching Cyan Write Letters
    Also PC development is hella' easy. The tools and engines for the PC have been in development forever, they don't start over and stop every few years.
     
  6. Deltaechoe

    Deltaechoe The Dopefish

    Member
    511
    132
    May 3, 2012
    United States
    I don't know if I would say it was easy, with pc you get a specific problem that you won't get with console coding and that's making it compatible with all kinds of different hardware.
     
  7. Rydian

    Rydian Resident Furvertâ„¢

    Member
    27,883
    8,107
    Feb 4, 2010
    United States
    Cave Entrance, Watching Cyan Write Letters
    I should say I guess that development ON the PC is easy.