Jump to content
  • Advertisement
Sign in to follow this  
irreversible

OpenGL Texture size on GPU on modern hardware

This topic is 2690 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I skipped doing anything in OpenGL for a few years a while back and when I got back into it, it seemed that the API no longer required even an extension to be invoked to use non-power-of two textures directly (I can only assume this change in behavior doesn't relate to only OpenGL, but also to Direct3D). ATM I'm targeting GF200+ series cards and wondering if the lack of limitation is only apparent and the diver actually does the conversion internally or has GPU architecture changed enough since the GF4 era that the textures are sampled directly regardless of what resolution they are loaded into VRAM. Can anyone clarify on this?

Bottom line is: should I worry about scaling my textures to power of two resolution for shipping in the future or can I just focus on minimizing used storage?

Share this post


Link to post
Share on other sites
Advertisement

I skipped doing anything in OpenGL for a few years a while back and when I got back into it, it seemed that the API no longer required even an extension to be invoked to use non-power-of two textures directly (I can only assume this change in behavior doesn't relate to only OpenGL, but also to Direct3D). ATM I'm targeting GF200+ series cards and wondering if the lack of limitation is only apparent and the diver actually does the conversion internally or has GPU architecture changed enough since the GF4 era that the textures are sampled directly regardless of what resolution they are loaded into VRAM. Can anyone clarify on this?

Bottom line is: should I worry about scaling my textures to power of two resolution for shipping in the future or can I just focus on minimizing used storage?


I think right after the GF4 native support for non-power-of-2 textures started, it's natively working on GF200+

Share this post


Link to post
Share on other sites
GL2 (or maybe it's 2.1) specifies that the NPOT extension must be supported.
FWIW There are some old ATI cards that (wrongly) report GL2.1 support but still don't support NPOT textures though...

However, keep in mind that sampling from a POT texture is still slightly faster than sampling from a NPOT texture, so it's still preferable to use them where convenient.

Share this post


Link to post
Share on other sites
Thanks for the replies, guys!
Hodgman, you might recall my asking about texture atlas packing a while back - I have that up and running now and I've implemented an adaptive baker that creates the minimum required size baked map for requested quality X. I've noticed that oftentimes, especially when the model has long narrow faces, it is difficult to create a texture that has both the minimum possible size and satisfies the POT requirement: in fact, most of the time the texture can be expected to be 40-70% empty for many types of models, which is a huge waste of storage. By adaptively iterating through various texture sizes of NPOT dimensions, it's easier to come up with a solution that saves almost the same amount of storage at the expense of giving up the POT requirement.

I am trying all common forms of POT layout prior to reverting to a NPOT solution first, though.


I think I'm quite okay with giving up some performance, especially since I'm targeting GL2.1+ anyway if I can save that much on VRAM storage and possibly on HDD storage (although I'm using PNG to store my textures, which does a very good job at compressing dead space).

Share this post


Link to post
Share on other sites
Some (all?) GeForce FX cards are troublesome too; the driver does report support for NPO2 but will drop you back to software emulation if you try to use them (in OpenGL at least; I haven't tested one with D3D). Hello < 1 FPS!

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!