MIPS Series5 Now Official

Discussion in 'Mobile Graphics Architectures and IP' started by iwod, Jun 26, 2013.

Tags:
  1. iwod

    Newcomer

    Joined:
    Jun 3, 2004
    Messages:
    179
    Likes Received:
    1
  2. wco81

    Legend

    Joined:
    Mar 20, 2004
    Messages:
    6,131
    Likes Received:
    238
    Location:
    West Coast
    If mobile device makers used this CPU or Atom, wouldn't those devices be at a disadvantage running all the mobile apps. which were compiled for ARM?

    In the desktop space, competitors to X86 never got any traction because of the software deficit, either not enough native software or poor emulation performance.

    So isn't it too late for alternate CPU architectures in the mobile space?
     
  3. Rys

    Rys AMD RTG
    Moderator Veteran Alpha

    Joined:
    Oct 9, 2003
    Messages:
    4,138
    Likes Received:
    1,337
    Location:
    Beyond3D HQ
    For Android, MIPS is healthy. You get MIPS system images by default now, plus toolchain support in the NDK, and if you build for all NDK architectures you get MIPS binaries in the resulting .apk. Obviously for non-native code it's also fine.

    I can't comment on other OSes, but we obviously work on them all where we can.
     
  4. Npl

    Npl
    Veteran

    Joined:
    Dec 19, 2004
    Messages:
    1,905
    Likes Received:
    6
    android has the advantage that most apps are java and dont care for the architecture. But thats only half the thruth I guess, support for mips still is lackin in llvm and other important tools which are at least as important as software.
     
  5. Laurent06

    Regular

    Joined:
    Dec 14, 2007
    Messages:
    707
    Likes Received:
    31
    Yes, that's half the truth :) For Android, you have to ensure Dalvik (Java) and v8 (Javscript) generate good code and this can take a large amount of time. On v8 there's been public activity for months, and I guess it's the same for Dalvik.
     
  6. Exophase

    Veteran

    Joined:
    Mar 25, 2010
    Messages:
    2,406
    Likes Received:
    428
    Location:
    Cleveland, OH
    NDK use may be more common than you think.. for starters, anyone that wants reasonable portability with iOS. And that's really only part of it. I don't know what the total percentage of apps use, but that can be a misleading comfort since what really matters is the number of apps weighted by their popularity and surely a lot of the most popular ones use NDK.

    Sure, most apps built using the NDK after a certain date will already have MIPS support. From what I can tell that date is a little over a year ago. For apps before that you're out of luck unless the original developer updates - if the original developers are even active anymore. I can't see this as being a totally unimportant issue. It was at least critical enough that Intel decided to employ binary translation, and they had support longer (by about another year). They also have more money to throw around to try to get devs to update, although I really can't say how invested MIPS will or won't be in doing the same thing.
     
  7. wco81

    Legend

    Joined:
    Mar 20, 2004
    Messages:
    6,131
    Likes Received:
    238
    Location:
    West Coast
    But does the Google Play store distribute fat or MIPS binaries of those apps?

    I guess they could if MIPS or Atom gains significant installed bases.
     
  8. Exophase

    Veteran

    Joined:
    Mar 25, 2010
    Messages:
    2,406
    Likes Received:
    428
    Location:
    Cleveland, OH
    It's part of the NDK, it's in the APK (as a fat binary) if the developer enables it (I have no idea if it is or isn't by default). The store really doesn't have anything to do with it.
     
  9. tmavr

    Newcomer

    Joined:
    Sep 2, 2010
    Messages:
    10
    Likes Received:
    0
    There are many STBs with MIPS cores around,
    For example Linux Satellite Receivers
    Some of them very popular

    STBs are a natural fit, not so much power constrained as phones/tablets, and always price sensitive to components.

    So I guess there is a consumer market - There is a market - it might not be so large, but it is nice to have a modern MIPS core around.

    Also don’t forget that the Chinese have used a MIPS derivative for HPC. So there is some demand for know-how and integration services
     
  10. Rys

    Rys AMD RTG
    Moderator Veteran Alpha

    Joined:
    Oct 9, 2003
    Messages:
    4,138
    Likes Received:
    1,337
    Location:
    Beyond3D HQ
    You're right, and we've made pretty good inroads into getting developers to add MIPS support to NDK apps, especially games, from what I can tell (haven't been involved directly with that), but we necessarily won't be able to catch them all.

    As for binary translation, I'm curious myself; I'll check when I'm back at work next week.
     
  11. rpg.314

    Veteran

    Joined:
    Jul 21, 2008
    Messages:
    4,298
    Likes Received:
    0
    Location:
    /
    I am curious about how this works. Does the code get compiled for all architectures by default. What if somebody uses ARM intrinsics? Are they translated to equivalent intrinsics for other architectures? How come a date's cutoff is relevant here?
     
  12. Rys

    Rys AMD RTG
    Moderator Veteran Alpha

    Joined:
    Oct 9, 2003
    Messages:
    4,138
    Likes Received:
    1,337
    Location:
    Beyond3D HQ
    You set APP_ABI in Application.mk. 'all' builds for all, not sure what happens if you use architecture intrinsics but I imagine it'd be a compile failure.

    The date cutoff is relevant because non-ARM ABI support has been phased in over time. Actually it's a bit more complicated than that for ARM too, but MIPS and x86 certainly weren't there in the first NDK.
     
  13. tangey

    Veteran

    Joined:
    Jul 28, 2006
    Messages:
    1,406
    Likes Received:
    149
    Location:
    0x5FF6BC
    MIPS 64-bit IP launched for phones/tablets

    In retrospect the title needs editing, poor choice as it is clearly designed for many other applications than phone/tablet

    PR
    http://www.imgtec.com/news/detail.asp?ID=923

    Blog posting
    http://blog.imgtec.com/mips-processors/meet-mips-i6400-warrior-cpu-for-64-bit-computing-revolution

    Highlights from the PR.

    4 Threads per core
    Up to 6 cores can be clustered, cores can work on separate clocks/voltages
    Design permits up to 64 clusters.
    30-50% perf improvement per core over ARM (err "competitor 64-bit") on similar die area
    Unspecified licensees secured across multiple markets.
     
  14. ToTTenTranz

    Legend Veteran Subscriber

    Joined:
    Jul 7, 2008
    Messages:
    9,407
    Likes Received:
    4,057

    Not to mention the fact that this will find no space in the smartphone/tablet market.
    Look at how troublesome it was for Intel.. and they're a bottomless pit of money, talent and alien technology.

    Servers, render farms, routers and maybe consoles is the most likely scenario
     
  15. sebbbi

    Veteran

    Joined:
    Nov 14, 2007
    Messages:
    2,924
    Likes Received:
    5,287
    Location:
    Helsinki, Finland
    If MIPS becomes popular in the future, we might need to add MIPS SIMD (http://www.imgtec.com/mips/architectures/simd.asp) support in our vector library at some point. Currently it only generates x64 (SSE4/AVX) and ARM (NEON) intrinsics. Hopefully the instruction set is good :)
     
  16. Nebuchadnezzar

    Legend

    Joined:
    Feb 10, 2002
    Messages:
    949
    Likes Received:
    98
    Location:
    Luxembourg
  17. Gubbi

    Veteran

    Joined:
    Feb 8, 2002
    Messages:
    3,470
    Likes Received:
    743
    Are there plans for fatter cores? Dual issue in-order seems a little unambitious even for mobile or low power server segments.

    Cheers
     
  18. Entropy

    Veteran

    Joined:
    Feb 8, 2002
    Messages:
    2,912
    Likes Received:
    774
    Well, there is the multithreading to improve utilization of ALU resources. The blend of cost/efficiency/performance on offer is too much of an unknown to judge the appeal at the moment.
     
  19. AlexV

    AlexV Heteroscedasticitate
    Moderator Veteran

    Joined:
    Mar 15, 2005
    Messages:
    2,528
    Likes Received:
    107
    That would probably be the unannounced Rys SKU:razz:
     
  20. Exophase

    Veteran

    Joined:
    Mar 25, 2010
    Messages:
    2,406
    Likes Received:
    428
    Location:
    Cleveland, OH
    So it looks like the MIPS r6 removes and changes some things. Here's what I could find:

    - Packed single float operations
    - Trapping arithmetic
    - LWC2/STWC2 encodings
    - FP (COP1) and COP2 conditional branches (BC*{T/F})
    - All "likely" form of branch instructions
    - Conditional branch and link instructions (BGEZAL, BLTZAL)
    - All mul/div using HI/LO regs (and the move to/from those regs)
    - FP reg + reg address load/store
    - Unaligned partial load/store (LL/LR, etc)
    - FP chained MADDs (replaced with FMA instructions)
    - Conditional moves ("replaced" with conditional select zero)
    - Prefetch with register + register address
    - FP round to integer

    And a bunch of instructions have had their encodings moved around.

    Most of this is cruft, but not necessarily cruft no one used. I know I used conditional branch/link and conditional moves in code years ago. I guess the plan is to handle compatibility with a mix of load time translation (maybe for the stuff with 1:1 mappings?) and trapped emulation, which I'm sure is not going to be fast. So I guess we can expect yet another NDK target in Android.

    According to the AT article, "Additional instructions were also added specifically targeting today’s applications like web browsers." I have no idea what these instructions are supposed to be.
     
Loading...

Share This Page

  • About Us

    Beyond3D has been around for over a decade and prides itself on being the best place on the web for in-depth, technically-driven discussion and analysis of 3D graphics hardware. If you love pixels and transistors, you've come to the right place!

    Beyond3D is proudly published by GPU Tools Ltd.
Loading...