S3TC will be used in PSP

[Simon F]

S3TC and vector quantization texture compression (Simon's method) are different although the underlying concept is similiar.

It's my understanding that PVR-TC =! VQ.

Correct. They are completely different.

FWIW, the translucent glass texture in this picture has been done with 2bpp PVR-TC. (The background has also been done with PVR-TC but I don't know if it was the 4bpp or 2bpp version).

 

[ysoya]

The double access is inconvenient but it can be avoided by using this amazing technology called a cache. It's not free, of course, but then even Nvidia were using two levels of caching to implement S3TC.

Because S3TC uses small, local (4x4) codebook, it might be more cache friendly and easy to implement in hardware (just a guess).

The DC codebook could be up to 2kB in size. The max sized DC-VQ texture for a 256x256 image would thus be 18kB. The equivalent S3TC opaque only texture would be 32kB. Please explain how the VQ texture is not smaller.

Oops, I must have said 'not always smaller'. You are right except for smaller textures. BTW, PSP is a mobile, low-res device.

Technically I do feel that BTC variants (eg S3TC) are probably more convenient systems then VQ-based solutions but I think there are better solutions than S3TC.

S3TC is simple, effective and, even widespreaded. Though there are a number of TC methods that have better aspects, I think S3TC might be the better choice for PSP.

-ysoya[/quote]

 

[Squeak]

Because S3TC uses small, local (4x4) codebook, it might be more cache friendly and easy to implement in hardware (just a guess).

Cache friendly I doubt.The whole 4x4 texelblock needs to be loaded every time the hardware has to access a single texel. That means that with bilinear it needs to access more than four texels on average, this gets even worse when mip maps are dynamically created.

S3TC is simple, effective and, even widespreaded. Though there are a number of TC methods that have better aspects, I think S3TC might be the better choice for PSP.

In the case of TC formats, being a standard isn’t really as big an advantage, as it is with other data formats. TC is to a large extent only used by “professionalsâ€￾, to whom converting from one format to another is not a problem if it is advantageous.

S3TC doesn’t work well with noisy textures like for example a flowerbed or a Persian rug, and alpha costs 4bits extra. So overall I’ll say that the format is showing its age.

 

[Natoma]

Why not FXT1? Isn't that superior to S3TC, and open source as well?

 

[London Geezer]

Why not FXT1? Isn't that superior to S3TC, and open source as well?

What r u doing in here!?!? It's BAD for u!!! j/k...

 

[Simon F]

Why not FXT1? Isn't that superior to S3TC, and open source as well?

Open source means B'all if the basic algorithm infringes on the S3TC patent.

 

[Fafalada]

Paging Texture is one of the worst bottleneck in PS2 rendering pipeline.

But the rendering pipeline is not one of the worst PS2 bottlenecks

Anyway, I don't know about other apps, but the rendering speed I get when using texture transfers is within 10-15% of performance with them disabled.
And that's for simple geometry transforms, the difference gets smaller with more complex shaders.

But speaking of... PSP is not PS2, so I am not sure what PS2 bottlenecks have to do with Panajev's discussion of PSP memory

Technically I do feel that BTC variants (eg S3TC) are probably more convenient systems then VQ-based solutions but I think there are better solutions than S3TC.

Given the size of screens on portable hw I hardly thing compression quality is much of an issue, I'd be perfectly happy with error rate of 2x2VQ. It'd be handy to have size that could go down to 2bits/texel though.

 

[Fox5]

Why not FXT1? Isn't that superior to S3TC, and open source as well?

Yeah, I always wondered what happened to FXT1 too! Though in the compression programs available for it, it always produced very crap looking textures.