Feature Request HDRP for mobile

Thanks for your request. HDRP heavily relies on GPU compute. Its use of compute is designed from high end devices and would run very poorly on mobile GPUs, even if they support compute.

 

Hi @DevDunk

Indeed supporting HDRP on mobile would be great, even experimental, but it would be a lot of work, add maintenance cost to HDRP, might pull HDRP features and systems down in order to maintain the compatibility.

However, to give more details, we think that in the current state of the mobile market, devices, drivers and GPUs, and based on our experience with URP, VFX Graph, and consoles this effort would very probably lead to something very instable and not usable for most productions.

First, a lesson learned with VFX Graph, is that support for compute on mobile is very unpredictable, unequal and fragmented. The more compute one uses, the more one hits a multitude of driver issues on many devices, even pretty high end and recent ones.

But it is not just about Compute, but as well the fact that HDRP relies on many passes which also affect CPU consumption. Based on the previous generation of consoles hardware and prototypes to run on portable consoles, it can already be challenging if you want to run HDRP's specific features (somehow Steam Deck is actually running pretty fine with HDRP but is more a portable PC than a mobile device). While some phones from the past years could be compared to this generation of hardware, the required power consumption even on the CPU would very probably make it impracticable for commercial titles.

URP is optimized for mobile in many ways (FP16 shaders, renderer optimized for tile based GPUs,...), and we currently see more opportunities to keep this split in terms of platform reach per pipeline, and use our time to better align the pipelines authoring and core feature while making features with scalability settings and architectures specifically designed for mobile on one side (targeting performance) or for PC/Consoles on the other side (targeting visual fideliity) rather than trying to squeeze features architected for PC and consoles into mobile hardware.

 

Hi @kripto289 ,

I understand your point, and looking at it straight, having a single pipeline would be much easier for everyone.

It was not an easy one, but we took the decision to open our rendering pipeline and offer 2 specialized ones based on tens of thousands of games built with Unity, and between 10 to 20 years providing technologies to millions of creators.

If 10 years ago, most users could create competitive content in terms of visual fidelity and performance building on top of a simple but powerful graphics engine, the market has evolved, both in terms of available technologies, hardware capabilities, competitive offerings and users expectations. It was not an opinion, but became just a production fact that more and more users needed to extend and modify the Built-in render pipeline more and more heavily, and in opposite directions whether they were doing mobile or PC/Consoles games; Many wanted to strip out some code which was preventing the pipeline to be performant on mobile, some wanted to write their own pipeline (eg: the Ori series), while others were spending years re-implementing features and implementing new features in order to compete visually with AAA (eg: Escape from Tarkov), or even implemented their own 2 dedicated render pipelines for mobile and PC/Consoles like Genshin Impact.

So the conclusion was that one cannot rule all platforms, all users, all genre, all industries with a single rendering architecture. Unreal also has a dedicated renderer for mobile. Most AAA games shipping on mobile use a totally different rendering architecture. Here are the buffers used by each pipeline. As you can see, the more features you want to offer, the more complex becomes the pipeline, and the less cross platform it is.



Now, proposing 2 different rendering architectures does not mean that they should be totally incompatible, and that is probably a mistake that we did at the time.

We have been working in the past years to realign the 2 pipelines so that they share more and feel less like 2 products: Shader Graph to target multiple render pipelines, possibility to associate different pipelines to different quality tiers, shared rendering debugger, shared volume system, shared rendering layers, unification of the camera component, and now Render Graph...

We have also improved feature parity in both ways (terrain details support for HDRP, URP dynamic resolution and FSR support, URP HDR output,...) and developed new features for both pipelines (SRP lens flares and screen space lens flares, Adaptive Probe Volumes). More and more game graphics features and effects can be made for both pipeline with Shader Graph (eg: shaders, full screen master node, custom render textures,...) and VFX Graph. There are still some feature differences but that will evolve (and as you said, that is ok - they have different requirements, cover different needs and different hardware range with different priorities-).

But, while making sure to not diverge and keep the 2 pipelines converging, our first priority has been to make sure that URP and HDRP are the right solutions to replace and improve the Built-in render pipeline, so that as soon as possible we have 2 pipelines and not 3. This has taken longer than expected, but today we hear mostly great feedback from productions using them, and almost no new production starts on Built-in. New pipelines mean that there will always be things that people regret from the previous generation, but we do our best to make sure that this stays marginal.

So, the future of the graphics engine is hopefully what you expect: a more unified authoring experience with scalable features running on a choice of 2 rendering architecture optimized for their platform tiers themselves running on a core cross platform and modern graphics foundation, all more customizable, more optimized and with more features than built-in. We are not there yet, but I hope that you can appreciate the steps already done.