Any plans for texture compression, or not?

[lulzfish]

I see PowerVR has provided some tools as part of their SDK for compressing textures to a native SGX format. Are people planning to use this, or will there be any attempt to use GLSL or something to implement a different algorithm, or are most people planning to ignore it, since the Pandora has ridiculous amounts of RAM and enough bandwidth to not worry about it?

 

[JayFoxRox]

I thought this was just a feature of the chip which is independend from the rendering pipeline. So if you start your app you decompress your textures using the pvr lib and then you keep it in memory for later use.
But doesn't really matter to me at all. I'm generating more than 75% of all my textures at startup or at runtime which gives full picture quality at whatever dimension I like while keeping the files REALLY small. We have enough RAM for the average homebrew game / application and probably enough bandwidth to not think about this kind of stuff.
Only future will tell I guess.
//Edit: Move to pandora dev. ?

 

[Adventus]

Texture Compression greatly improves texture cache efficency and overall memory bandwidth. The PVRTC textures are decompressed in hardware after the texture cache, so you obtain the full benefit (unlike PSP). No one is likely to implement a more efficent algorithm in GLSL.

The problem is that IMGtec do not provide the source for there PVRTC texture compressor, so we can't use Pandora to produce PVRTC textures at start up (would be slow anyway).... in this situation 16 bit textures would probably be the best compromise. Beyond the previous situation and aliasing I can't see any reason to not use PVRTC.

 

[warmi]

I thought this was just a feature of the chip which is independend from the rendering pipeline. So if you start your app you decompress your textures using the pvr lib and then you keep it in memory for later use.
But doesn't really matter to me at all. I'm generating more than 75% of all my textures at startup or at runtime which gives full picture quality at whatever dimension I like while keeping the files REALLY small. We have enough RAM for the average homebrew game / application and probably enough bandwidth to not think about this kind of stuff.
Only future will tell I guess.
//Edit: Move to pandora dev. ?

It is not about ram .. PVRT speeds up rendering noticeably.

 

[JayFoxRox]

I still don't get it.. I just checked my SDK and the only thing I can find is PVRTexLib and PVRTexTool. However, the lib can - from what I see - only used to decompress textures before passing them to OpenGL ES and the tool and the lib can be used to compress the textures for that. Ofcourse decompression is done on the SGX then, but I don't see how it would speed up rendering or so.
The only usefull sample I could find (which is actually doing what I thought first) is in the PVRTexLib manual, section 3.1

 

[Exophase]

Compressed textures improve rendering by:
- Decreasing pressure on the system bus, because less is fetched for a texture.
- Increasing texture cache utilization because more active texture portions can fit in it.

All of the texture compression schemes I've seen are solely color space conversions (eg, making a pixel 2bpp within a block that mostly uses the same 4 colors, it's basically sub-palletization/quantization). They don't need information from adjacent data elements to be decoded, they only need the given pixel and some block context information. This means that they can be kept in their compressed form until the very final texture fetch stages.

This may not hold true for PSP's texture compression, which would explain why it has to be decompressed into texture cache (and is therefore all but useless since the 32bpp results are overkill)

 

[lulzfish]

I don't know as much about the CPU / GPU relation as I thought I did, but I thought for some reason that you could compress the textures somehow [either with a custom texture format or by saving the compressed pixels in a lossless format such as BMP or PNG], then upload them compressed and decompress in the pixel shader.

Would this have any effect, or would it just complicate everything more?

 

[dflemstr]

I don't know as much about the CPU / GPU relation as I thought I did, but I thought for some reason that you could compress the textures somehow [either with a custom texture format or by saving the compressed pixels in a lossless format such as BMP or PNG], then upload them compressed and decompress in the pixel shader.

Would this have any effect, or would it just complicate everything more?

How would you go about doing that? How do you want to upload the raw PNG to the shader? It would prove to be very difficult and inefficient, since (as was stated in the SGX performance thread on the other board) the SGX only accepts a limited amount of data per shader. If you were to provide a shader with a PNG, you'd need to have a huge int array, while you can use a simple sampler2D (aka decompressed ordinary texture) if you decompress the texture on the CPU. And you'll lose performance if you either 1. have to decompress the PNG on-the-fly every frame, or 2. decompress it and cache it, thus making the whole operation unnecessary since you can do the same on the CPU much more cheaply.

 

[lulzfish]

No, you're not sending the PNG. you would actually probably store it in some sort of binary format.
It would be uploaded as a texture, but the pixel shader would decompress it into a more detailed / larger texture than the compressed version you sent.

From what I've seen of block-compressed textures, this is theoretically possible, maybe not practical.
Like I said, I don't really know much about texture compression.

 

[dflemstr]

No, you're not sending the PNG. you would actually probably store it in some sort of binary format.
It would be uploaded as a texture, but the pixel shader would decompress it into a more detailed / larger texture than the compressed version you sent.

From what I've seen of block-compressed textures, this is theoretically possible, maybe not practical.
Like I said, I don't really know much about texture compression.

You can of course use scaling algorithms like 2xSaI or normal texture magnification filters. But that's not really using compressed textures
The thing is that the sampler2D structure is kinda optimized, so you really shouldn't be using something else, thus making it nearly impossible to use a non-standard binary format that you want to send to the shader. If you can get a format that 'fits' in a sampler2D and gains quality in the shader (like 2xSaI etc) you can play with that, of course. Not really worth it in the long run, though.