I just watched this excellent presentation, in which the second speaker repeatedly sings the praises of PVRTC 2bpp in particular. I use that whenever possible, but let’s be realistic; that’s not very often, if you want your content to look good. The alpha channel in particular tends to be quite horrid (though still impressive for the size!). PVRTC 4bpp generally looks far more than “twice as good”, for only a doubling, but we could still use better fidelity (again, especially in the alpha channel).
I’m just wondering about the subject line; I bet PowerVR could do wonders with 8 or even 16 bits - certainly better than 16-bit RGB or RGBA uncompressed can offer.Jessy2011-10-28 00:04:26
Hi Jessy,
Thanks for your suggestion! This is something that could be quite useful for developers, I will pass your feedback on to the engineers who work on it to see if that’s something we can do. In the meantime, we’ve updated the compressor in our SDK, and the 4bpp compression is much improved from before, so you may be able to get something quite good out of it. The alpha channel in particular is now often preserved better than in previous versions.
Thanks,
Tobias
Jessy,
An 8bpp format is an interesting idea - by that do you mean something like, say, DXT5 which effectively consists of a pair of 4bpp textures (one for Alpha and the other RGB) or do you just want better RGB in an 8bpp budget? If the former, do you use premultiplied or non-premultiplied textures.
FWIW, we generally only have requests for higher levels of compression so that more complex 3D environments can be rendered in the limited memory footprint on mobile devices.
SimonF2011-10-28 14:56:33
SimonF wrote:
An 8bpp format is an interesting idea - by that do you mean something like, say, DXT5 which effectively consists of a pair of 4bpp textures (one for Alpha and the other RGB) or do you just want better RGB in an 8bpp budget?
I do not design compression algorithms, so this is a case where I, as a customer, might just be telling your company to "make a faster horse". ;-) However, for RGBA images, I'd bet that the DXT5 approach is not ideal; I'd wager that compressing the alpha channel as a delta from the green channel, or the saturated sum of the other channels, would produce the best results, for most uses of that channel (i.e. when the alpha is an opacity mask). For other common uses of the alpha channel, such as normal or gloss maps, that scheme wouldn't likely produce nearly as good of results, of course. In terms of memory, I see no benefit to the DXT approach, either. Currently, I can use two PVRTC images, with one being greyscale, and move one of its channels into the alpha result, in the fragment shader. That involves two texture lookups, and swizzling a low precision vector, so there's a performance hit, but your GPUs are fast; I can deal with that. I don't see a copy of DXT5 as a priority.
And yes, I also want to be able to get even higher quality for RGB images, as we can now, with PVRTC 2bpp or 4bpp, though I'd take an exclusive 4-channel format first. The RGB portion of PVRTC 4bpp RGBA looks better than a PVRTC 2bpp RGB image, so I'm sure it would be an improvement even with a useless channel.
SimonF wrote:
If the former, do you use premultiplied or non-premultiplied textures.
I rarely use premulitplied alpha blending for several reasons:
* Unlike with uncompressed textures, premultiplied alpha blending does not yield identical results to standard alpha blending; noise in value (the V in HSV) occurs.
* My profiling has shown no performance benefit to premulitplied alpha.
* Fog doesn't work with it; for some terrible reason, fog doesn't modulate the alpha result. There is no RGB value to fade to that will yield appropriate results.
* Although premulitplied blending allows for more control (i.e. an effective mix of additive and traditional alpha blending), I don't find this necessary for the vast majority of effects. It's more unwiedly to animate.
SimonF wrote:
FWIW, we generally only have requests for higher levels of compression so that more complex 3D environments can be rendered in the limited memory footprint on mobile devices.
The developers using PVRTC want to be paid, today. And right now, that still means developing with iPhone 3GS/iPod touch 3G (except the 8 GB w/MBXLite, which is obsolete), and later iPod touches in mind. All of these only have 256 MB of shared RAM. Looking at reviews for Shadowgun, for example, you see a lot of crashes on these devices; they're being pushed to their limits. There's not just a framerate drop when virtual memory is accessed, because there is no virtual memory; the game dies, negative reviews come in, and the PVRTC users get paid less.
For mobile devices, planned obsolescence comes in 2-3 years. We'll be on to 1-2 GB of RAM shortly; some Android devices (not that PVRTC users make money on them) already have 1 GB. A couple things that are not going to change are 1. desire for ever- increasing graphical fidelity, and 2. the small amount a customer will pay for a "mobile app". Because of the latter, the development time for games, on devices using PowerVR-designed GPUs, is going to stay small. Teams are also going to stay small. Large worlds - the kind of content that necessitates many textures - are not practical to build in the available time.
With more memory available, what PVRTC users are going to need, is not a slightly better- looking low-footprint format, but rather, much higher fidelity for the smaller number of textures they have time to create. Increasing resolution helps, but in my experience, the increase in color fidelity of PVRTC 4bpp does more for image quality than upping the resolution using 2bpp, by any factor, in most cases. (There are textures for which PVRTC 2bpp is a fantastic choice, such as noisy effects that last only a moment, or textures that are actually designed to be very murky or blurry, but that doesn't describe most of what we use.) I think you'd find that, with an 8 bpp format, you'd actually have lower memory use, in products where formats are well-selected, per texture. Our only realistic current option, for increasing fidelity for high-contrast images in particular, is to increase resolution, when in actuality, better color fidelity for a bicubicly-filtered lower resolution version of an image will generally trump that alternative, even with the smaller resultant data size. (If that weren't true, all internet and broadcast video would have been at 1080p, with extreme compression, for the past half-decade or longer.)
I don't see the PVRTC 2bpp or 4bpp formats becoming obsolete for some time. Although it is easier to just use the best-looking format available, even if we somehow get a memory boost that allows us to use RGBA 32 bpp on everything, that's still going to drain battery faster than lower bit depth formats, and batteries haven't kept up the pace of increase/improvement that we've seen in other relevant hardware. So please keep working on those highly-compressed formats, if you have the resources. But what we need most from PowerVR is the visual equivalent of 256 kbps AAC/MP3; something that is significantly smaller than uncompressed data, but an effective replacement for it, for the vast majority of humans, using the consumer hardware of the time. That's not going to happen with 4 bpp.
Your company had an unbelievable ability to predict the future; look at how well it's paying off, now that phones and tablets have become the norm for the bulk of your average consumer's computer use - at this point, nobody can touch your performance/power ratio. Please don't get so caught up in 2011, where your old tech is paying the bills for developers, that you fail to continue to push the industry forward.
