Unreal Engine 4 on OpenPOWER | Hacker News Reader

Unreal Engine 4 on OpenPOWER

raptorengineering.com

93 pointsamock40 comments

Nice. There was an Anandech article here not too long ago showing pretty nice improvement over Intel in some cases:

---

All in all, the maximum throughput of one POWER8 core is about 43% faster than a similar Broadwell-based Xeon E5 v4. Considering that using more cores hardly ever results in perfect scaling, a POWER8 CPU should be able to keep up with a Xeon with 40 to 60% more cores.

---

http://www.anandtech.com/show/10435/assessing-ibms-power8-pa...

Big thing to also take from that article is that the POWER8 uses over 2 times as much power as the Xeon E5 v4. Depending on the use case this can be very important.

If single-threaded performance or memory bandwidth is more important to your use case then POWER8 would steamroll a Xeon E5 v4 even factoring in the power usage, I'm actually looking at trying to get a S812LC at work to eval moving one of our very heavy transactional PostgreSQL databases to for this very reason (having to run a seq scan over a 80GB table would benefit heavily from the increased memory bandwidth).

As per article linked by the OP, the single threaded performance of the POWER8 is 87% of the Intel CPU at the same clock [1].

The per-core performance is higher thanks to the 8 thread SMT capability of POWER8 (although the sweet spot is normally 4) and its massive 8-way execution. So POWER8 is excellent for heavily threaded applications, but for pure single thread speed, Intel is still king.

[1] IIRC POWER8 and Intel CPUs peak at around the same clock speed.

Back when I worked on a UE3 title we actually used machines not too far off(basically more RAM) from final specs so that we wouldn't build things that could never be run on a reasonable PC/X360/etc. Giving a developer a machine close to an end users definitely incentivises a focus on fast, performant code.

However having faster asset cooking is always a good thing.

Faster build machines should always available to devs. Machines to test on should be the average of the end users.

Yup, we'd use IncrediBuild to keep build times down to something reasonable.

Unless you're working on something very console specific most of your day to day testing happens on PC. Even titles that don't have a PC port will have a PC version of the game since iteration time is so much quicker. Having something close in specs there means you'll see perf issues right up-front as opposed to when QA gets around to testing it the next day.

I recently worked on a AAA port where we had roughly 220Ghz worth of processing power hooked on IncrediBuild; a full rebuild still took about 15 minutes!

We had to make the engine sit on the PSVita and for that reason did all the development, debugging and testing on that platform. We even debugged a release build most of the time because the debug one wouldn't go above 5fps!

Most of the time, you end up running the editor and the game so for many things a faster machine is helpful.

>OpenPOWER systems allow you to keep your valuable assets and proprietary engine code safe and secure through full owner control

What does it mean? It's some form of DRM pitch?

Yes. It's about not having anything like Intel's ME running code you can't audit or control that has full access to your hardware. It's basically the same pitch as for Libreboot https://libreboot.org/.

I.e. it's DRM-free pitch? That's the opposite of what I first took it for.

Yes, it's a DRM-free pitch. I suppose “Keep your … proprietary code safe” could seem DRM-related but “full owner control” is an FSF-y anti-DRM catchphrase.

It's a very odd mix, pitching user freedom with "proprietary engine code" as the example of data that is protected.

There's a blurb at the bottom of the Talos machine's page (same page, hit the link on the bottom left) about how they can't divulge certain details of the PCIe system.

Plenty of room for backdoors and other shenanigans in there. Which kind of undermines the entire claim...

OpenPOWER is really open, including the chip's firmware (https://github.com/open-power), and there's no embedded management chip as found in Intel or AMD CPUs.

People may be overselling this; all the current Power8 machines are servers that have BMCs.

Parent posts are likely referring to on-CPU management features (on the IC itself), not on-board ones like BMCs.

The BMC's firmware is also open: https://github.com/open-power/hostboot

Here's a blog post with some details: https://blog.jms.id.au/2015/07/openpower-firmware-stack/

Hostboot (and skiboot) is loaded from the BMC, but it's not the BMC firmware - hostboot and skiboot run entirely on the host.

The BMC firmware we're currently working on at IBM (based off some work by Facebook) is at https://github.com/openbmc/openbmc.

[Disclosure: IBM Power Systems. Opinions my own.]

The problem with DRM like Intel's is that you have to trust Intel. And the DRM is meant to protect other people's code running on consumer machines. The pitch here is that you can run your own custom DRM, that only you control.

To use CAs as an analogy. Intel, and most chip manufactures, when they describe DRM, they mean generalized consumer DRM, so basically how your browser or OS comes with a list of CAs pre-installed. The DRM pitch here is the ability to write your own DRM, e.g. like having your own internal CA.

This has a use case. DRM can be useful for things like governments and companies. While dangerous from a civil liberty perspective on consumer hardware, it's perfectly reasonable for an organization to want a DRM solution that they control entirely. As an example such a solution could prevent the IT guy (re: Snowden) from stealing your files.

In this case I'd call it InfoSec features, not DRM. They can be conflated because both can rely on encryption, but they have different purposes, or I'd say premises.

InfoSec is the goal, and DRM is the process by which the goal is reached. DRM refers to digital data that some people can't copy, or view, etc. often at a hardware level. That's a tool in doing InfoSec.

"What does it mean? It's some form of DRM pitch?"

It's a BS claim. IBM has only developed one CPU for high-assurance security:

https://domino.research.ibm.com/library/cyberdig.nsf/papers/...

POWER is an insecure processor like the rest. The software on it will likewise have the same problems as the rest. The difference they're advertising is that there's more open code. This reduces the unknowns for users, gives them more control over their own boxes, and improves security a bit. There's still black boxes in there including one I didn't know about per one commenter in this thread. You can trust the hardware and any firmware left about as much as you can trust IBM's management in that division. Yeah, it gave me pause too.

So, let's change it to "less DRM" and "more open than x86." If you want an open ISA, looked at RISC-V or SPARC (esp Leon3 or OpenSPARC T2). If you want a more secure ISA, look at crash-safe.org, Cambridge's CHERI processor (also open), System/38 (still exists), or even old Burroughs B5000 from 1961. In such light, "Open"POWER is neither truly open nor secure even if better than x86.

I think its important to consider the context, which is clearly stated on the frontpage of Talos: "POWER is the only open, owner-controllable architecture that is competitive in performance".

There are other architectures that could be candidates for an owner-controllable system (see https://www.raptorengineering.com/TALOS/op_twbx86.php for a review of some other alternatives), but POWER8 is currently the one that can be competitive with x86-64 and could realistically build today.

It's called a "Talos Secure Workstation" "designed for security-conscious users." Then they mention the ownership and openness differentiators but nothing else. Other "secure" workstations were CMW's, separation kernels, hypervisor schemes, and so on that protect the system from attack.

So, I think it's a misleading label. "Secure" workstation has a meaning that goes way back. In isolation, it has an established meaning. They should just say open and/or DRM-free as that's intended meaning.

If you're interested in it - support this pull request: https://github.com/EpicGames/UnrealEngine/pull/2585

If you're getting a 404, it's not because of an error in the URL.

You need to sign up here: https://github.com/EpicGames/Signup

I'm not going to sign up because their marketing pitch for making the engine "free[sic]" doesn't specify if they mean it is actually free software or just gratis + some proprietary source code you get a copy of.

Do you know which is the case? My hunch is it's probably the latter because they ask for royalties.

It's free as in beer, and you get to look at the source code. It's not libre software.

sigh Figured as much.

? you expect them to GPL a triple A game engine?

Yes. Why not?

Because they've spent tons of money on it and now want to earn something

>implying nobody can make money while respecting user freedom

This has been debunked so many times I'm not going to bother.

Let me rephrase - why would they lose part of their money - much money? I can't see what would be their profit on releasing UE under open source license. Moreover, what would be profit of others except the right of copying their code?

> I can't see what would be their profit on releasing UE under open source license.

They have already forgone a lot of potential revenue by allowing anyone to get the source code for the engine (under a proprietary license) without paying anything. The only thing left is to design a non-royalty revenue model that can work with a free software license. This has already been solved.

> Moreover, what would be profit of others except the right of copying their code?

Being able to release free software games using UE. Creating a community around UE that allows for innovation by that community. Porting to new platforms by that community. A show of good will to the free software community. There are many good reasons, but they all come about from giving people software freedom.

> They have already forgone a lot of potential revenue by allowing anyone to get the source code for the engine (under a proprietary license) without paying anything.

They're making to pay only those who has profits from using their engine. Those who has no profits (i.e. less than $3000) wouldn't buy it anyway.

> Being able to release free software games using UE.

You can do that now.

> Creating a community around UE that allows for innovation by that community.

There is a community.

> Porting to new platforms by that community.

You can do that now.

> There are many good reasons, but they all come about from giving people software freedom.

I am for free software, but I don't like ideology in name of ideology.

I'm happy to see usable non x86 hardware ! But we still have to solve emulation. I wonder if there is a way to decompile and recompile binaries. In theory it SHOULD be possible to convert what the CPU is asked to do, back to what the program does, and then convert it to another CPU.

An implementation like this would have a huge impact on new platform giving them a fighting change, allow competition without vendor lock-in.

Machine code translation is exactly how Intel Atom Android phones support apps containing native ARM code. Intel has a translator from ARM to x86 or x86_64 called Houdini. (I never managed to find any detailed information about it, it's propriety). Even if you're developing an app for Android using the NDK you may not realise that your phone doesn't have an ARM processor. Few people bother to ship x86 binaries, and the fact that works so well is why they still don't even as x86 devices become more common (they're mostly tablets). Compatibility is around 80% of apps [0], and the performance hit is somewhat substantial (e.g. 2x) but doesn't matter for most apps.

[0] https://regmedia.co.uk/2014/04/30/watt_compatibility_large.j... [1] https://commonsware.com/blog/2013/11/21/libhoudini-what-it-m...

Reply on news.ycombinator.com