XBox One Backwards Compatibility and Xbox One X Enhancements for X360 and OG (XO XOX BC)

You have to wonder what seemingly unrelated changes fed from this, we got a rather unexpected half cpu core recently, if we assume each jag core is being mapped to a xenos thread then having a seperate discrete management core would be very helpful....

Also the delay with implementing screen shots, could it have been access to the emulated frame buffer that caused the delay as they knew it had to support BC if that was now in proof positive stage and getting ready for more dev time?

I dont think they would upset the apple cart too much but conspiracy theories are fun

 

For the CPU, there are multiple options besides step-by-step emulation of the native code of a different ISA.
That would require significantly higher straightline speed, since each "step" as seen in native code would be multiple potentially expensive operations in the emulator.
However, translating the code to the native code of the emulating processor can be done, as several code-morphing processors and dynamic translators have done in the past. Since this happens at an instruction level, it isn't necessary to have the source code or recompile. If the legal gray area of copyright is satisfied by getting publisher permission, the translated code can be put in a RAM cache or even cached to disk.
That strips out a big chunk of the CPU code overhead, most of the time.
If we then count on the usually terrible IPC of Xenon, and whatever other kinds of "slack" there is between CPU-bound execution stretches (synchronization, FP-INT conversions that somehow were still allowed in 360 code, store-to-load forwarding, better branch prediction, better caching, etc), you can get a lot closer, particularly for games that did not push the 360 that hard. That this might not be entirely perfect still may be evidenced by the still-rough results for some of the heavier games out there.

I'm assuming the GPU side has some kind of internal mapping for the graphics commands, with the necessary tweaks being less intractible since the two GPUs have a continuity of sorts in terms of API support and IP provider.

It may be possible that other elements of the system can improve on bottlenecks besides code. There is a gargantuan increase in RAM capacity and a standard hard drive, for example. That might explain some of the pop-in improvements for games that might have been stuck streaming from optical. More RAM might also let more become cached in memory versus physical drives, and could have room for a translated code cache. A lot of problems last-gen came from other bottlenecks besides code, so improving them could buy margin for emulation.

 

I'm wondering if streaming assets (textures) might be stored on the hard disk uncompressed as well - this would save a whole thread on a number of titles.

Cyan - are your size comparisons download sizes are installed sizes?

 

I would really doubt that, as it would require a massive reengineering of the rendering/streaming subsystem on a game by game basis.

 

Perhaps keeping the data compressed makes it easier to keep the assets in RAM? If the whole package is small enough, some titles and their OS could stay there. If not, a read cache of virtual HDD sectors could keep hot data in physical memory.

 

Was Mass Effect on the XBox 360 comparison video running off of the DVD? That's all you'd need to explain the performance difference, HDD access is a lot faster than DVD access.

 

The bolded part is something that was nagging at me when I first read Digital Foundry's article. Why should games improve the pop-in issue and load times? Don't original X360 games always count on 512MB and nothing more, so it shouldn't make a difference if you have 8GB of available memory now? Why should the X360 executable look for more memory and if it is a yes, use it? Could it be due to development kits?

Yes, installed sizes, I got the numbers first when I noticed the download size of Hexic HD, although before that I already had a hunch the download sizes were larger than I was used to, especially from games like Super Meat Boy and Hexic HD or Perfect Dark.

But once downloaded I had to check and confirm the installed sizes in "My games and apps" section 'cos I couldn't see the download size again using the Preview Program - Quests. That's the actual space those games take, but Hexic HD was also a 623.1MB download, too.

 

The emulated game wouldn't see extra memory, the disk caching would happen transparently by the emulator. All it would see is disk accesses that are a lot faster than usual.

 

So if I understand it correctly, the emulator is transforming the original Xbox 360 disk cache into physical memory and tricks the original XEX file into believing it is disk cache being used? That's what I get from your words

 

We can't know for sure, but putting the HD cache (that games like Halo 3 used) into memory rather than a HDD partition might be a good idea.

If you stored that in memory, you might be able to 'accellerate' the entire emulator if you weren't processing limited, so it thought longer had passed that actually had. That way you might be able to accelerate loading without the game knowing this had happened.

 

Phil Spencer has talked about the classic Xbox 360 games you won't be playing on the Xbox One. Plus he also mentions they are working on a solution for multi-disc games, like Blue Dragon (talking of which, I might get Blue Dragon since I never played the original game, bring more jRPGs to the X1, Phil..)

http://www.express.co.uk/entertainm...ne-backwards-compatibility-Kinect-Mass-Effect

 

"The 360 games think they're running on the 360 OS, which they are. And the 360 OS thinks its running on the hardware, which it's not, it's running on an emulated VM. On the other side, the Xbox One thinks it's a game. That's why things like streaming, game DVR, and screenshots all work, because it thinks there's just one big game called 360."

"You download a kind of manifest of wrapper for the 360 game, so we can say 'hey, this is actually Banjo, or this is Mass Effect. The emulator runs exactly the same for all the games.

Revealed: How Xbox One Can Play 360 Games via Backward Compatibility

 

I really don't understand why they can't just have the Xbox One connect to the original Kinect hardware.

 

We don't really have a good idea of how performance in the emulator stacks up against the original hardware yet.

The games that show occasional worse-than-the-original frame rates are ones where heavy screen tearing was present on the 360 (VP, ME, Keflings). Vsync is engaged permanently on the emulator at the moment. It could be that the emulator is out-performing the 360 already, we just can't tell yet.

Hopefully Vsync will be an toggle option on the emulator in a future update. Then we can make more meaningful performance comparisons.

I'm fine with a little bit of tearing if it allows smoother framerates and more importantly, less control latency.

 

I don't think installing the game and running from the HDD on 360 had a Massive Effect (see what I did there?) on pop-in. It did reduce pop-in in a lot of cases, but not significantly. Pretty much all UE games still had it even after installing.

I wonder whether it could have anything to do with decompression. We know the X1 has decompression hardware, and as far as I know the 360 did not. Could this account for the difference?

 

Microsoft says they aren’t modifying the code at all. If a game was decompressing assets in software on 360, presumably it still is on 360. Any enhancements are likely simply down to a much faster i/o subsystem and possible ramdisk caching.

 

True, but the game code itself is only one part of the picture.

(this is all assumption coming from general development experience - if anyone with actual 360 game dev experience wants to chip in that would be super.)

I would have thought the game code would be issuing standard decompression library calls (would anyone want to roll their own decompression libraries these days?). Where those libraries reside would dictate how easy it is to route the calls to more efficient routines.

For example, if the libs are packed with the game then you have a somewhat closed environment and it would take some kind of call signature recognition and interception by the Virtual OS or the VM to route decompression to hardware-based libraries. Possible, but very inefficient.

However, if the game calls libraries resident on the OS (is there a GAC-esque assembly repository on 360??) then those would be easily replaceable in the Virtual OS with calls to hardware decompression.

I'm constantly improving the performance of legacy applications without touching the application code itself, by upgrading the referenced libraries sitting resident on the server.

Of course what applies to decompression also applies to many other software functions that may be hardware-resident now, or simply have greatly improved software libraries for.

 

if a game has strict, pre-allocated budgets, then it probably will always allocate the same amount of memory.
But even on consoles it might make sense nowadays to allocate bigger memory chunks from the OS, as the OS can re-combine memory pages into one block of virtual memory space (that's what an OS does, right? )
So if a game wants to stream in a texture or a new sound file, it could try to allocate some memory from the OS, on X360 this might fail as it reaches the memory limit and the Game would free some old resources and try again. On XBOne the allocation might succeed and then a game might as well use 2GB of space. This might be risky at times, as some internal structures might run with assumptions e.g. "we cannot fit more than 1024 textures into memory anyway", that's where MS has probably to hand tune the VM for every game, but beyond this, the increased memory budget might really help with streaming even on engine side.

And as 3dilettante said, it's rather straight forward to translate opcodes from one ISA to another. It's what emulators do on runtime, but instead of executing the instruction, you'd store the emulation code. I've written my tiny C++ to MIPS to C# to .Net converted that way. The idea is based on http://nestedvm.ibex.org/ and it actually shows how simple the idea is.

non optimized code will probably run faster on x86 than on the XBox CPU. When the PS3 came out (which is similar on CPU core side), there were benchmarks with PPU vs X86 and most of the time vanilla c++ code run on PPU as fast as it would run on an 700MHz - 1300MHz x86 core2 (you might still find those results in google). Modern Jaguar cores @ 1.86GHz might be a good match for vanilla PowerPC code. On top the X360 run two thread per core, which effectivelly means 1.6GHz and that's even less raw MHz power, eh?

yet Altivec code was always famous to wipe the floor with the SSE code, not only does it support multiply-add, but also tons of registers and operates non destructive on more registers per op. If you give your code some altivec love, you can really gain a lot performance.

I think, if developers optimized for altivec, they've optimized the parts that were really time critical (e.g. some physics or AI raycast). Hence those hard to emulate altivec ops will be issued when it's most critical (e.g. combat) and that would hurt emulation twice.

Yet I'm really impressed with what MS has pulled out of the box.

 

Microsoft filed some kind of forward compatibility patent in ~2006, it has anything to do with this?

 

If it's the one I half remember being thrown around a few years ago then no, it was much more describing a method in general terms than describing a detailed implemented system. Nothing MS have described thus far seems like patentable technology and given the applicability of PPC emu to data centre tasks if it was I'd imagine there would be a lot more noise about it Iacknowledging that something like Power7 is a different beast by an order of magnitude than Xenos).