iPad Pro NPOT framebuffer size?

Question

Created Mar ’16

Replies 2

Boosts 0

Views 1k

Participants 2

Hi there,

I have an application that currently uses OpenGLES 2 and does some framebuffer fetching to handle "mouse" picking on an extra framebuffer it creates.

Up until the appearance of the iPad Pro I was using a POT that was whatever the next POT would cover the maximum width/height of the device where it ran.

Given that the resolution of the iPad Pro is 2732x2048 that is currently forcing me to use a 4096x4096 framebuffer which seems excessive and a bit of a waste of resources.

I'd like to know if creating a 2732x2732 framebuffer would have a performance cost on the iPad Pro knowing that this picking framebuffer, depending on application context, can be potentially rerendered on a per frame basis and it's picking needs to be instant.

Is there any cost? Anything I should enable that would make it ok? anything I should know about this?

A confirmation on its cost would be very much appreciated.

Cheers,

-Javier.

Boost

Answer 1

tapnik OP

Mar ’16

You don't have to use a square texture, a 4096x2048 is a power-of-two texture that work the same and save you half the space.

As for NPOT textures:

https://www.khronos.org/registry/gles/extensions/APPLE/APPLE_texture_2D_limited_npot.txt

Which basically says that yes, NPOT textures should work as long as you're not mipmapping and the repeat mode is GL_CLAMP_TO_EDGE, which is the case with your picking test. I don't think theres any special API call you need to enable this, it should just work.

0

Answer 2

Javier Edo OP

Apr ’16

Apologies for the late reply,

Thanks for your reply, perhaps I didn't explain myself correctly. I am fully aware that NPOT textures work, I can see it working in my testing device.

What I am interested in knowing is if by using NPOT I will be paying the cost of using them, getting slower FBO drawing speed, I know this can all be tested and it seems to be ok but I want to know if I have to expect slower drawing or if it's meant to be just as fast.

I would like to get some sort of confirmation from Apple and not just make an assumption based on the few tests I can (and have) run. I want a futureproof solution not just "this works now so I assume it must be the case"... that kind of thing.

I'm saying this because there is literally no info about OpenGL|ES 2.0 FBO texture sizes, whereas for ES3.0 there is the following affirmation in the HW Guidelines, under Best Practises for ES3.0 I have found:

When possible, your renderbuffer’s height and width should be a multiple of 32 pixels.

(found here: https://developer.apple.com/library/ios/documentation/DeviceInformation/Reference/iOSDeviceCompatibility/OpenGLESPlatforms/OpenGLESPlatforms.html)

Which would mean that for a GL|ES 3.0 I would need to use an FBO with either width or height 2752 (32x86) as it's the next acceptable value for a 2732 screen resolution size, but then again I can't find any affirmation on the GL|ES 2.0 front.

Any confirmation on whether I should expect that this rule would apply to ES2.0 would be great. I can see why this would sort of apply to devices that can run ES3.0 as it kind of suggests me that this is part of the tiled rasterizing going on in these ES3.0 GPUs but it may be a different case for older GPUs that can't run ES3.0.

I may move my app to GL|ES 3.0 but don't want to do it just because there is something that's not well documented enough...

Any ideas?

0