But wouldn't the same CUs that are used for time warping, the same ROPs that are used for rendering at high refresh rates etc, just be standard GPU fare that can also be used to render more conventional graphics at higher resolutions and lower refresh rates?
The front end above those elements deals with different scenarios and could optimize more for one than the other.
Facilitating some kind of time warp is generally compromising overall efficiency. More can get done in the absence of it, and it primarily exists because of how unforgiving VR is in terms of latency and how janky the GPU pipeline is in terms of timing.
Accepting some jankiness and not letting compute partially obstruct the primary rendering process allows for more to get done, or possibly accomplishing as much more efficiently. Queues can be deeper without being negated by a hard frame rate floor, and the GPU can run ahead more to fill in occupancy slots rather than having to worry about what might need to be kicked out or blocked by a screen shift.
VR needs to prioritize response time, which has implications in terms of hurting utilization and from that the effective resource budget.
By way of weak analogy, it's like having two processors that can be designed however they want, but one must run at 6 GHz and it is allowed to provide output that is periodically nonsensical in the context of the other.
AMD don't seem to be designing different architectures for VR and standard displays.
In numerical terms, VR as a niche is almost nonexistent. The market that existing GPUs is barely profitable for AMD as-is.
AMD's best-case solution for VR currently is a dual-card system, which isn't the most efficient way.
That method does minimize disruption for a standard synchronization model that also does better with inter-frame synchronization and dependences, whereas VR has opportunities for intra-frame data sharing or scheduling since it's two view of the same time step that can have a lot of common work.
While the same approaches to software might not transfer across, wouldn't faster GCN 1.3 based kit give both a huge boost?
If it's better generally, it should help both. The more specialized optimizations can be non-transferrable, and we haven't reached a point where we have an embarrassment of riches in terms of performance that we can discount them.