Skip to content

Instantly share code, notes, and snippets.

@OneSadCookie
Created July 18, 2011 16:36
Show Gist options
  • Save OneSadCookie/1090015 to your computer and use it in GitHub Desktop.
Save OneSadCookie/1090015 to your computer and use it in GitHub Desktop.
KatieHuber> it's not particularly hard to get OpenGL into a state where it requires more VRAM *at once* than is available (eg. an 8192x8192 FP32 texture is already 1GB), try drawing one of those to an 8192x8192 FP32 framebuffer and undefined behavior will result)
<Oddity007> Who in their right mind would allocate a texture that big?
<KatieHuber> but if your total VRAM required for one draw call is less than the total VRAM available on the card, that draw call should succeed
<Oddity007> MUST HAVE MOAR PIXELZZZZ
<KatieHuber> Oddity007: well, that was an example :P
<KatieHuber> people hit it on low VRAM cards with regular old 32-bit 4096x4096 textures (64M each) reasonably regularly
<KatieHuber> I think most cards have 512 now so hitting it with 4096 textures is pretty hard these days
<TheBunny> " in their right mind "
<TheBunny> Oh you assume so much about the average coder there...
<Oddity007> lol
<KatieHuber> skyhawk2891: but the important point is, just having lots of large textures is not inherently problematic
<KatieHuber> you could have thousands of 1024x1024 32-bit textures using GB of RAM without OpenGL having any issues beyond performance :P <KatieHuber> skyhawk2891: so what exactly are you seeing?
<TheBunny> you could render a movie!
<TheBunny> was the res on a movie screen these days?
<KatieHuber> I think they're still only doing 4k by 2k <KatieHuber> even if they're doing double that, any recent card will handle 8k by 4k as a single texture/framebuffer
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment