alexvoica

I know, we've shipped about 800 million MIPS CPUs in the last year alone.

But for that time in history, a million processors was a big milestone. You also have to remember that in 1988 MIPS was a three-year old company battling established vendors.

I'm not talking about buying, I'm talking about engineering expertise.

You're right, it is a typo. It's actually http://ark.intel.com/products/80817/Intel-Core-i5-4460-Proce...

I'll update the chart, thanks for noticing.

Oh, that must have happened recently. Thanks for letting me know!

I agree on the out-of-/in-order commentary. But to paraphrase, with great performance comes great power consumption. http://www.anandtech.com/show/9330/exynos-7420-deep-dive/5

I perceive the situation on binary translation in a slightly different way. I think the aim here is to perhaps ensure that some legacy code written for x86/ARM also runs alongside the apps written for MIPS. So they are not trying to compete, but ensure they have a broad(er) ecosystem.

I don't know if people are aware of this but Richard Stallman (rms) uses a Loongson-based laptop from Lemote.

I think a lot of people forget that 64-bit MIPS has been around for more than two decades - much longer than Intel, AMD or ARM.

For example, the Nintendo N64 game console had a MIPS64 CPU.

I think I address some of your points in the article. I specify that overall peak power consumption for the chip is 30W - this is for an octa-core configuration. This means one CPU roughly consumes 3.5W (if you take out the coherency manager and fabric). Then I also referenced the SPEC CPU2000 performance number at 1GHz. From that you can easily calculate performance per W. If you want more technical details about the architecture, they do have an user manual here http://www.loongson.cn/uploadfile/cpumanual/Loongson3B1500_p...

I also state that a new processor will be released next year and it will run at above 2GHz which should solve the difference in frequency.

I'll see what I can do in terms of sending a few boards. Will ping you an email shortly.

You can always try to use QEMU for OS development when a dev board is not available. The latest version implements Release 6 for 32- and 64-bit MIPS CPUs.

When it comes to development boards, we are working to expand the Creator family to include more options at the high- and low-end.

For those asking if MIPS is dead, my sincere answer is a loud no. We've had a record quarter in shipments, registered over 800m devices last year using the architecture (which represents a 10% increase YoY, by the way).

Regards, Alex.

Ah, I see what you mean. I was thinking more in terms of market-driven motives for adoption rather than technical facts. Unfortunately, Vulkan is currently still under development and under strict NDA so I can't disclose any of the inner workings at this moment in time (beyond what we have posted on the blog). However, when the spec is final and public, we will talk a lot about the technical implications in more detail, offering code snippets and tutorials so developers can understand how to use Vulkan.

When it comes to Vulkan development, it is a pretty much a joint effort. We (the GPU providers) design the graphics processors and write the drivers/compilers to support Khronos. Then the application developers (the middleware guys) adopt their engines and libraries for Vulkan too in cooperation with us and other members of Khronos. Finally, the high-level application developers (e.g. games developers) port their software too. In addition, third parties might also create Vulkan open source drivers and compilers for the GPUs so it's a combination of in-house and third-party work.

Cool, thanks for the clarification. What I was trying to suggest is that we will encourage all of our partners to adopt Vulkan alongside OpenGL ES on Android, Linux or any other operating system that supports Khronos APIs. However, for some manufacturers, updating might not be an option due to factors like costs, development time, etc. So there is no absolute guarantee that every single device having a PowerVR Rogue GPU will have Vulkan. We can only promote it and hope that it happens since it is a really good API.

When I say developers, I mean graphics people like Unity, Epic, Gameloft, Steam etc. who want to have more control over performance optimization. When OpenGL was first designed, GPUs were fixed-function hardware that performed only a fraction of the tasks they handle now. Vulkan has been designed to be aware of tile-based renderers so that these developers can use them more efficiently. Driver and compiler development is a different topic although it is true that some parts of the driver will be more easier to write and manage.

I can't speak for all GPU vendors, but Imagination is actively developing a Vulkan driver for PowerVR Rogue GPUs (this is what the demo is running on). Beyond driver availability, I can't guarantee that OEMs and/or chip makers will license that driver and build new firmware with it.

Developers have been asking for Vulkan for years. Essentially Vulkan and OpenGL ES provide two fundamental choices: going low level for highly tuned, architecture-specific optimizations (i.e. game engines) or high level, respectively, for quick and easy code writing that can run across multiple platforms (i.e. a simple UI or a 2D game).

Not quite although I get your point. Vulkan is designed for developers that want to get close to the metal (e.g. game engine guys). OpenGL ES will still live for high-level rendering.

This is how an software update works in mobile: the GPU vendor writes the driver using a spec (e.g. Vulkan), then submits the driver for conformance testing with Khronos. Once the driver achieves conformance, the driver is made available to chip makers and OEMs. They take the driver and build an Android BSP; the new ROM is then pushed to consumers through an OTA. The GPU vendor has little control or influence over the update process beyond the point of providing the driver.

For anyone still reading this, I'm interviewing the JAXA engineering team this week. If you have any specific questions you'd like me to ask, reply to this comment.

Yes but process node characteristics such as the gate length and/or the silicon film thickness should be relatively similar.

Maximum TDP for HR5000 is 4-6W (fact) whereas the Mongoose-V might be in the sub 1W range (speculation).

I have a feeling Mongoose-V (32-bit MIPS) is manufactured in a 0.18um process node. I'm not 100% sure but it would coincide with the time of the release. HR5000 (64-bit MIPS) might be manufactured in a more recent SOI process node.

Here is a quote from the product spec about the radiation hardening technology that HIREC developed:

Space radiation environments present severe problems in semiconductor devices for space use. Conventional space-use devices are fabricated with special radiation-hardened processes. However, it was not feasible to continue this method because it was difficult to maintain and manage the manufacturing processes. In addition, it will be necessary to utilize state-of-the-art commercial processes to improve the performance of integrated circuits for space use. HIREC established the Customer-Owned Tooling (COT) procedure for developing advanced LSI circuits for space use. Hardening techniques utilizing the hardness-by-design (HBD) approach are utilized to ameliorate Single-Event Effects SEE).* Moreover, a radiation-hardened ceramic package is utilized to reduce the influence of Total Ionization Dose (TID).

We've posted a follow-up article where we analyze further optimizations and compare memory traffic and rendering speed for ray traced shadows vs. cascaded shadow maps: http://blog.imgtec.com/multimedia/ray-traced-shadows-vs-casc...

The PowerVR Wizard architecture scales from mobile to desktop/console. We will be bringing out dev kits in the near future that will deliver very (very) high performance.

Yes, we've integrated Caustic's ray tracing tech into the PowerVR architecture.

You can also run the code I've given above on a very fast CPU; however, the PowerVR Wizard GPU has built-in structures designed to accelerate ray tracing functionality in addition to the traditional rasterized architecture, giving you real-time ray tracing + rasterzied graphics + compute in a single GPU.

This article on AnandTech presents the architecture in more detail: http://www.anandtech.com/show/7870/imagination-announces-pow...

You essentially implement ray tracing capabilities inside the G buffer. Have a look at this presentation from GDC for more details and let me know if you have further questions. http://www.gdcvault.com/play/1020688/Practical-Techniques-fo...

Yes, we are using ray tracing extensions implemented for OpenGL.

You can find the sample code here http://cdn.imgtec.com/OpenRLSDK/OpenRL-Hybrid-Example.zip

Thank you for the feedback. There will be an article tomorrow analyzing more screenshots and presenting performance data too (memory traffic and rendering speed)

For people interested in the difference between taking an architectural license vs. using standard, off-the-shelf IP, have a look at this article too: http://www.alexvoica.com/when-soc-met-ip/