Comparing performance of textures vs procedural shaders on mobile gpu

Hi, I'm making a mobile game in which I would like to use as much procedural shader effects as possible. It's a 3D space combat game, and at the moment, I've written custom shaders for various things such as the skybox, energy shields, and some weapon effects.

Until now, these shaders control fairly 'high-level' stuff - for example the skybox shader right now just generates a soft fade from horizon to sky, and some stars. But I'm experimenting in generating some more complex detail, such as nebula etc, which would be generated from preset values each frame. Another example would be hyperspace effects, especially animated effects which have the potential to significantly reduce the need for textures, and reduce fill rate by removing the need for particle systems (or at least greatly reducing the number of particles).

The problem is that I don't really know what I can/can't do efficiently with mobile GPUs. So my main question is, how do I compare the performance of texture lookup to something like procedurally generating perlin noise each frame? Also, what are the main things to look out for on mobile GPUs when using them for procedural generation type stuff, and what other things can I give up to get the most improvement in performance when doing procedural stuff?

In terms of testing, I haven't decided on the minimum spec yet, and I would be willing to push it up a bit to get better performance for a GPU-heavy game, so before I go buying stuff it would be great to learn as much as possible about any fairly generalizable rules of thumb on this sort of thing.

Thanks,
Billy

 

Well... this may sound obvious but: Test on a device. Get something that you consider being the lowest acceptable. Then do both solutions and compare results.

It depends A LOT on what your minimum specs are. For example a lot of devices used to be fillrate bound, now it's not that much of an issue.

 

Also this might be useful :

https://community.imgtec.com/developers/powervr/tools/pvrshadereditor/

You can paste your compiled vertex / frag shaders in it and it will give an estimation of cycles (although it's specific to powervr gpus, obviously). Don't rely too much on it, but it's good for ballpark stuff.

 

Yeah for sure! But as I mentioned I'm willing to push this minimum spec up depending on what a GPU can give me, and I won't be able to get a bunch of different devices just to test this. Also I don't have a mac or iphone, and I hear they have specific issues especially fill rate. My own phone is very bad and I'm going to buy a minimum spec device soon, but I don't want to get something too low and then have to get a newer/more expensive one.

I'd like to target something from around 5 years ago, but I could go for a newer device if I knew that it would give me very significant improvements on stuff like realtime noise generation. For example I'd like to do several layers of blended noise for stuff like shield hits, but I have no idea if this is a reasonable idea.

That's the sort of thing I'd like to get a grip on, GPUs seem to be advancing pretty fast, I mean on desktop vertices tend to not really be a problem anymore etc. I'd like to know if this is the case for mobile (and any other useful stuff) but even partially generalizable information is hard to find. And then there's Apple device quirks as well.

Thanks for that, I need to find a way to create a metric of some kind that isn't necessarily comprehensive but gives me a good chance of nailing decent performance across devices.

PS do you happen to know much about vertices performance on mobile GPUs? I hear at least on desktop textures are becoming far more costly by comparison, and regularly hear of smooth tests with tens of millions of polygons. I'd like to create models for my game (ships etc) with no baked maps, but I'd need to offset it with more modelled geometry, so what are mobile GPUs like for let's say, 200-300k polygons? I've seen some comments to the effect that this is quite possible, but looking around the net brings up a lot of random advice, that seems to be very outdated, such as keeping it around 30k-50k polygons - but that was the rule half a decade ago, and I can't imagine stuff hasn't gotten wildly better since then.

Thanks for your advice!

 

I think 200-300k is fine. I mean we've been doing ~70k on an iPhone 3GS and I can't imagine you'd want to support something that old.

But then again, that may depend on what kind of shaders you're running on those verts. In mobile we generally try to do most stuff in vertex shaders and then pass them to pixel shaders, so that cost rises with higher vert counts. Assuming simple shaders you can get polycounts up to a million easily and still be running at 60fps.

 

That's good to hear. On the parts where I'm adding the most vertices, the fragment shader stuff will mainly consist of applying a few small tiling textures (I've already got plans to create some efficient shader/map setups), and on the parts that do the most fragment work (e.g. noise generation), the geo will be very simple (mostly planes). So I think I should be OK there.

I think the main question then is how far I can push what is essentially realtime texture generation using noise functions, some of it I imagine would get pretty heavy when the player is up close and there are a lot of pixels being worked on.

 

As a general rule a texture will always be cheaper on mobile.

It's not always true, like for example if you want to do a gradient across a mesh and only need to calculate the color per vertex (and the calculation is very simple, like maybe a lerp against a dot product or the mesh UVs) then a shader only approach can be faster. It is also highly dependent on the size / compression of the texture being used, so if you're just using a small 2x1 pixel texture vs a lerp between two color values, this might be a toss up (and the texture might still win, but probably not). However if your texture is some 4096x4096 uncompressed RGBA thing, you'll probably start having problems with memory bandwidth. However something as complex as a perlin noise might still be slower than that 4096x4096 texture if you're doing it per pixel or if your mesh is too dense!

It's also a question of if you're targeting OpenGL ES 2.0 or ES 3.0 / Metal devices. If it's ES 2.0 then a texture sample using fixed mesh UVs is kind of the way to go, as just about any per-pixel (or even per vertex) calculation is close to guaranteed to be slower.

 

I'm definitely targeting ES 2 ... so I'm thinking probably it's going to be best to leave off the noise generation and maybe just try to work off some small textures tiled/combined. I can't really find any examples of anyone doing noise generation on mobile, and the more I look at it the more it seems like uncharted territory that I don't need to deal with right now. Besides, it probably takes quite a few noise layers to rival even just average custom textures for something like nebula, so if one is worse than a texture, 2 or 3 won't be very good.

Thanks a lot for the advices.

 

Done a lot of optimised mobile shaders, and texture is the way to go for pretty much everything. Do as little as you can in fragment and use the right type ie fixed where possible...

Noise on mobile GPU is a no go IMHO, it has a hard enough time doing all the other jobs being asked of it.

 

Also consider generating TO a target texture at run time if you want to keep the exe small, It also allow for variation on demand if the same algo can be used for many case. So you get the benefit of both.

 

Thanks for the advice, yeah I think I'd rather save the GPU for something that would save me a lot in development time, such as unbaked models with higher geo. And looking at it I would need several layers of noise each with a couple of layers of frequency to make anything decent, so I don't think it's going to be feasible.

That's something I've thought about, but it's not what I need to focus on right now. I thought that by using realtime noise generation in the shader I could have a lot more flexibility with the output dynamically, which would be a huge advantage in creating a more interesting and reactive environment.

Anyway I think it's worth keeping in mind for future games. The latest mobile GPUs are pretty powerful and may be driven by AR/VR to become even better.

 

Also depend at each rate those dynamic change happen ... but you can do a lot of tricks with just texture anyway, if you don't think straightforward mapping.

 

Yeah, I'll see how it goes. I just have to focus on getting the whole game finished to a good standard, and then I can fiddle around.

 

Me too!
Thanks for asking this question Billy. Is helpful to others as much as yourself.

 

You might find this useful:

I wrote a ton of procedural shaders for Star Trek Timelines, and got everything ported down to an iPad2 level of device. Took a lot of tricks

 

Incredibly useful stuff there, thanks! Almost everything mentioned is relevant to my situation. It's making me think about generating textures at runtime again (on load). Not only would it reduce the file size and all that, but being able to generate environments semi-procedurally during development would be very helpful for workflow and iterating widespread changes. All of the environment generation stuff you mentioned is very interesting.

One question, what do you think of minimum spec these days, would you still target an ipad 2 (or a device with 512 mb ram)? I'm not necessarily interested in getting the widest possible audience - my game will be paid so I imagine most people buying it would be non-casual gamers and probably have a good device. But I wouldn't want to lock out too many players.

PS that's a great looking game too, I had a few screenshots in my inspiration folder

 

We've dropped iPad2 support for our latest game. While it was a significant source of revenue for us on STT, the percent of the market is dropping over time (you can see these on the Unity hardware stats pages). Moving up to devices with 1gb of ram, you have significantly more breathing room.

 

what kind of tricks for example ?