Xbox 360 streaming is faster if you install the game on USB stick (same is true for Trials Evolution and Fusion). Haven't tested SSDs on next gen consoles.
ROPs don't matter that much anymore in modern graphics rendering. On any modern GPU, you should use compute shaders for anything else than triangle rasterization. Compute shaders write directly to memory (instead of using ROPs). I would estimate that a future engine would use at least 2/3 of the GPU time running compute shaders (for graphics rendering). Of course that remaining 1/3 of the frame might be partially ROP bound. However AMD GCN is quite good in g-buffer rendering, as it has full rate 64 bit ROP output. This allows you to bit pack two 32 bit g-buffers to a single 64 bit g-buffer and practically double your ROP rate (compared to other architectures). Bit packing instructions are also very fast (shift + and/or in a single cycle). HDR particle rendering hasn't been ROP bound on any modern GPU (HDR particle rendering is always bandwidth bound, even on 290X and Titan). That leaves us with shadow maps... Yes, shadow maps are often ROP bound and/or geometry bound, depending on your content and shadow map resolution. However in our case (Trials Fusion) we already use exactly the same shadow map resolution on both Xbox One and PS4. So we can definitely manage that pretty well.
I'm very interested in the results. I dropped a 1Tb 7200rpm HDD in mine on day one so I'm keen to se the disk I/O performance deltas between standard 5400rpm, 7200rpm, hybrid and SSD drives.
All our levels are created inside the game using exactly the same in-game level editor as the users are using (to create user created content). The level files are usually around 50 KB in size, and contain all the game logic info (triggers/events) + object/camera placement + animation. We load the 50 KB file in one go, build data structures based on that, and then we start to simulate. We keep the loading screen on as long as all our streaming subsystems tell us that they are finished. We stream textures, meshes, objects, terrain heigthmap, etc all on fly. Starting a new level is not much different than warping the camera to a new location in the world. Except that during level load we ensure that everything is streamed at full quality before we start, while a camera jump might show some blurry textures or lower LOD objects occasionally.
Hardware PRT only implements sampling from a sparse texture, it doesn't offer you a complete virtual texturing system. You still need to analyze the scene (texture pages needed), copy the page list back to CPU (and remove duplicates), update the GPU data, load from the HDD, manage the HDD data (optimize access patterns), etc yourself (basically all the hard parts). With hardware PRT, you save around 4 ALU instructions (compared to the optimal shader based indirection+sampling implementation). This is only a minor gain in performance, and in our case we weren't ALU bound in our g-buffer rendering stage, so there wasn't a gain at all. The biggest thing with hardware PRT is that you don't need to add borders (for filtering) to your virtual texture pages. This simplifies many things considerably (and even saves HDD space), but it also means that hardware PRT needs a completely separate data set from software virtual texturing. This is not good for content production, since PC DirectX doesn't support hardware PRT (DX 11.2 does, but it requires Windows 8). We didn't want to double our virtual texture export times, just to support a feature that didn't bring any noticeable performance gains for us.
Players have created FPS games, racing games, etc already in Trials Evolution (the older Xbox 360 Trials game).
Avalanche studio seems to agree with this, in GDC they basically said the only way not to be ROP bound is to use long shaders. for short shaders they suggested the use of compute shaders to bypass ROBs completely and write straight through UAVs.
http://www.humus.name/Articles/Perss...timization.pdf
