I see that Arm mali supports 4K textures & i have verified this using below calls
GLint maxGPUTextureSize;
glGetIntegerv(GL_MAX_TEXTURE_SIZE, &maxGPUTextureSize);
My question is : In my GL application ,I have an textures which are of size more than 4K & it does get uploaded without any warnings or errors from driver.
What could be the suspected performance impact here, I have an mip-mapping enabled in my code.
Could the performance impact be only be at startup Or it could also impact run-time performance too.
Hi.
It's impossible to give you an answer about the performance impact; it depends on the sampling pattern and LOD level selection. If you never pick from LOD zero the performance impact may be nothing more than the additional memory footprint (the large texture may never be accessed), if you start sparsely sampling from the additional large LOD 0 level then you may thrash the texture cache and the performance loss may be extreme.
In addition note that at some point large textures will have a quality loss; there are only a finite number of bits of precision in the sample coordinates; for every additional 2^N of width you add you need one extra bit of sample coordinate (which you can't add) to maintain the sample accuracy of sub-pixel sample addressing. At some point that will start to cause problems, but it depends on texture size and the number of UV wrap multiples you expect to have (every wrap multiple of 2^N pixels effectively steals bits from the normalized zero-to-one range addressing accuracy).
HTH, Pete
Hi, Pete
Does that mean if I enlarge a texture image from 16*16 pixel to 32*32 pixel, it will need one more bit of sample coordinate? But why? Could you explain how this work and maintain the sample accuracy? Thanks a lot.
Peter Harris said:for every additional 2^N of width you add you need one extra bit of sample coordinate (which you can't add) to maintain the sample accuracy of sub-pixel sample addressing.
Regards,
Luc
Hi Luc,
At resolutions that low you won't have a problem; the problems come when you are at the upper range of what an FP16 variable can store when using "mediump" texture coordinates. FP16 can store 10 fractional bits, so gives you sampling accuracy in the 0-1 UV range of 1 part in 1024. If you have a texture that is e.g. 2048 texels wide you'll lack enough precision to address it accurately. This problem gets worse if you start UV wrapping - e.g. if you repeat a texture twice then you would run out of bits for any size over 512, if you wrap it 16 times then you would run out of bits for any size over 128.In general you want to use "mediump" texture coordinates as much as possible (bandwidth is expensive), but you need to be aware at what point you need to switch up to "highp".HTH, Pete