in old days of regular opengl, easy determine if texture upload successful - after calling glteximage2d use glgettexlevelparameteriv gl_texture_width , gl_texture_height parameters. gles, however, doesn't seem allow this, , far can tell has no mechanism determine whether texture has been provided card (for example, glgeterror set things will not succeed, opposed things did not succeed).
the application i'm working on straddling barrier between having enough vram available , not (and there's lot of dynamically-allocated fbos , flying around, complicating matters further), , if important texture upload fails need know if need purge unimportant texture , retry.
i fear not possible @ moment. entire opengl state contained texture size removed (according gles 2.0.25 specs). correctly stated, there no error generated on texture upload going wrong (that sadly design). proxy textures removed, , reported people not supported/broken on pc-class gpus. now?
you try , read texture contents via framebuffer object (maybe not whole texture, corner points / every 32nd pixel / ...). not fast, should work. maybe use framebuffer completeness test texture attached (but seems limited image internal format, may or may not set in case texture upload fails because of low memory - have test that).
you can (in theory) determine amount of available memory creating renderbuffer object, spec states glrenderbufferstorage() fail gl_out_of_memory, should quite reliable.
it pretty easy test free space before allocating texture, deleting renderbuffer (if successful) , allocating texture itself. keep in mind mipmaps texture take little more 1.33x storage base level.
even better determine available memory @ application startup (maybe after compiling shaders , allocating other objects not easy estimate memory footprint) , keep track of object allocations see how memory left. seems complicated, if opengl objects wrapped in classes, should pretty easy.
Comments
Post a Comment