通常のOpenGLの古き良き時代には、テクスチャのアップロードが成功したかどうかを判断するのはかなり簡単でした。glTexImage2Dを呼び出した後、GL_TEXTURE_WIDTHとGL_TEXTURE_HEIGHTをパラメータとしてglGetTexLevelParameterivを使用できました。ただし、GLESはこれを許可していないようであり、私が知る限り、テクスチャが実際にカードに正常に提供されたかどうかを判断するメカニズムはありません（たとえば、glGetErrorは、成功しないものに対してのみ設定されます。成功しなかったものとは対照的に）。
私が取り組んでいるアプリケーションは、十分なVRAMを使用できるかどうかの障壁を常に越えています（動的に割り当てられたFBOなどが飛び交うことが多く、問題がさらに複雑になります）。重要なテクスチャのアップロードが失敗した場合は、重要でないテクスチャを削除して再試行する必要があるかどうかを確認します。
現時点ではこれが不可能だと思います。テクスチャサイズを含むOpenGL状態全体が削除されました（GLES 2.0.25仕様に準拠）。あなたが正しく述べたように、テクスチャのアップロードがうまくいかなくてもエラーは発生しません（それは悲しいことに設計によるものです）。プロキシテクスチャは削除され、PCクラスのGPUではサポートされていない/壊れていることが多いとの報告がありました。ならどうしよう？
フレームバッファオブジェクトを介してテクスチャの内容を読み戻すことができます（テクスチャ全体ではなく、コーナーポイントのみ/32ピクセルごと/...）。それほど速くはありませんが、動作するはずです。テクスチャを添付してフレームバッファの完全性テストを使用することもできます（ただし、画像の内部形式に限定されているようです。メモリが少ないためにテクスチャのアップロードが失敗した場合に設定される場合とされない場合があります。テストする必要があります）。 。
（理論的には）renderbufferオブジェクトを作成することで使用可能なメモリの量を決定できます。仕様では、glRenderbufferStorage（）はGL_OUT_OF_MEMORYで失敗するため、非常に信頼できるはずです。
テクスチャを割り当てる前に空き領域をテストし、次にレンダーバッファを削除して（成功した場合）、テクスチャ自体を割り当てるのは非常に簡単です。ミップマップを使用すると、テクスチャは基本レベルで1.33倍を少し超えるストレージを必要とすることに注意してください。
さらに良いのは、アプリケーションの起動時に使用可能なメモリを決定し（おそらく、シェーダーをコンパイルし、メモリフットプリントを見積もるのが難しい他のオブジェクトを割り当てた後）、オブジェクトの割り当てを追跡して、残りのメモリ量を確認することです。複雑に思えますが、OpenGLオブジェクトがクラスにラップされている場合は、かなり簡単なはずです。