I'd say that's a reasonable view. Sorry, Simon!
Next-Gen iPhone & iPhone Nano Speculation
- Thread starter Arun
- Start date
I (speaking personally etc, etc) find it odd given PVRTC2 has been in the HW for quite some time but simply not exposed.
I suppose if we'd been allowed that amount of silicon we might have done something else.
Further the quality difference is sometimes relatively small. For example, this is a section of one of the test images that I think was used in the ASTC paper. (Src image, ASTC @ 4.27bpp and PVRTC @ 4bpp)
I don't think there's a lot in it. They just have different artefacts. <shrug>
Attachments
It is odd.
I have to say that when it comes to drivers/API, your relationship with Apple is a bit opaque from the outside.
arjan de lumens
Veteran
It seems to me that it's possible to push the ASTC bitrate really quite far down before you cross over from "they just have different artifacts" to "one is clearly worse than the other".
Here are your three images, except that I cut the bitrate for the ASTC image in half: I have replaced the ASTC @ 4.27 bpp image in the middle of your lineup with an ASTC @ 2.13 bpp image, while keeping the original and the PVRTC2 @ 4bpp images unchanged.
Attachments
Yeah, but that's part of it. I'm not knocking the algorithm, it does really well for the given constraints. But those constraints weren't necessarily the right choice. ASTC simply covers more of what I need as a game developer.
I'm assuming that is because they didn't want to imply long term support for it by exposing it, whilst wanting to ultimately progress to ASTC.
I understand that there are multiple facets to this, and the implication of what you are saying is that a die area design constraint was high priority, but given that series 6XT now supports ASTC, one might think that that die area judgement was wrong (whoever made it), as 6XT now has redundant PVRTC2 die area in it AND ASTC die area.
Hindsight is a wonderful thing, but committing somewhat more die area to an improved PRVTC might have resulted in it being exposed and supported in favour of an open standard option.
(I have a gut feeling that PVRTC being a proprietary standard has served IMG very well in keeping IOS tied exclusively to PowerVr thus far).
You don't find the weird colour blocks a bit, well, weird? I suspect it's due to using a "maximise the PSNR" in the compressor (which admittedly is a problem with PVRTC compressor as well, just with different resulting artefacts).
It might actually be a bit opaque from the inside too
arjan de lumens
Veteran
Well, yes; they admittedly get rather visible when flipping back and forth at 8x magnification. Cutting bitrate in half was probably a bit overoptimistic of me for this kind of comparison; pushing bitrate that hard forces the compressor to make some rather hard choices between preservation-of-detail and color-fidelity, in ways that probably have room for improvement still.
As for compressor settings, I actually didn't optimize for pure PSNR, instead using the settings that the ASTC commandline codec recommends for improving subjective quality (" -b 1.8 -v 2 1 1 0 25 0.1"; the -b switch is to suppress block artifacts; the -v switch computes a per-pixel weighting for the codec to use based on the amount of detail in a small neighborhood around the pixel)
These settings tend to help subjective quality a bit at the cost of making PSNR a bit worse, although the difference is usually not very large for RGB textures. Below, I have attached your image again, now with two ASTC 2.13 bpp enocdes: the subjective-quality encode in the middle and a pure PSNR-optimized 2.13 bpp encode to the right (and original to the left).
It would probably be possible to get visually-better results still by optimizing for a more proper psycho-visual metric like x264's SSD/SATD, although this is probably just as true for PVRTC as it is for ASTC.
Attachments
What weird blocks? The images are almost identical. Almost. There's a bit more compression artefact fuzz in the middle one, but not so much that it's eye-poppingly obvious. The diagonal line at the bottom of the image is also less well defined, but again - would anyone actually notice this, especially in motion?
Half the storage size for not a very large difference in quality, well... The choice is pretty obvious isn't it, if memory/storage actually is a concern, that is.
heres a post of mine from 2 years ago
http://beyond3d.com/showpost.php?p=1662163&postcount=16
I havent look at IOS for a year or so, but its still not supported!
FFS whats up, I assume what tangey saiz is correct they dont want to support it cause it will be phased out
TMSC has started making SOCs for Apple:
http://arstechnica.com/apple/2014/0...its-first-apple-processors-replacing-samsung/
http://arstechnica.com/apple/2014/0...its-first-apple-processors-replacing-samsung/
Shipping, actually. They started manufacturing in Q1.
Apple never wanted to increase their dependence on an outside IP supplier in the first place when they adopted PVRTC. The gain in quality and usability was simply worth the consequences of dependence. When an industry standard TC was offered of sufficient quality, they of course jumped at adopting it.
That's only an indication of ASTC's own quality/usability, not its quality relative to PVRTC2.
That's only an indication of ASTC's own quality/usability, not its quality relative to PVRTC2.
There are a couple of insiders upthread who have expressed that ASTC is a better TC solution, with the caveat that it has a die area penalty.
Well, yes and no. I agree it's "all in the eye of the beholder" and probably is only noticeable when the image is zoomed, but you will encounter devs/artists who insist their images must be (nearly) pixel perfect. It's a "can't please everyone all of the time" situation. <shrug>
FWIW I've again attached pre-zoomed images showing Src, 2bpp ASTC and 2bpp PVRTC versions. They just seem to have different artefacts.
Attachments
PVR-TC was originally developed to replace the prior PVR vector quantization scheme specifically because of PVR-VQ's high hardware implementation cost for indirect data accesses, so avoiding the expense of more die area in a TC solution was already shown to be a priority of the hardware team.
It's not the HW cost but the memory latency that's the issue... unless you are implying that you'd need very large caches to hide it?
Having said that, some people are manually doing their own "VQ" in the fragment shaders. IIRC Colt McAnlis ( https://twitter.com/duhroach ) of Google seems to be doing this. See https://www.youtube.com/watch?v=jHXzzHElFPk&index=14&list=PLOU2XLYxmsII5O-vSGx2S3dN-hSVc3Cs_ around 20:40.
I seem to recall that anandtech discovered that apple silently changed the soc in the current ipad of the time, from 32nm to 28nm, which was seen as them testing in a limited form. There was no way to tell which ipad had what soc, except the newer one ran for longer and cooler.
It's possible therefore that some A7 devices selling now might have a 20nm chip in them.