如果函數調用的參數與OpenGL允許的參數集不匹配，或者與上下文中已經設置的狀態沒有合理交互，則會導致OpenGL錯誤 。 錯誤顯示爲錯誤代碼。
對於大多數OpenGL錯誤和大多數OpenGL函數，發出錯誤的函數將不起作用。 沒有OpenGL狀態將被改變，不會啓動渲染。 這就好像該功能尚未被調用。 有一些情況並非如此。
| 這篇文章是一個存根 。 你可以通過擴展來幫助OpenGL Wiki。 |
捕捉錯誤（困難的方式）
OpenGL錯誤存儲在隊列中，直到實際處理錯誤。 因此，如果您不定期測試錯誤，則不會知道哪個函數調用會引發特定的錯誤。 因此，如果您需要知道錯誤來自何處，應定期進行錯誤測試。
要獲取隊列中的下一個錯誤（並將其從隊列中移除），請調用此函數：
如果錯誤隊列爲空，它將返回GL_NO_ERROR 。 否則，它將返回下面的錯誤枚舉器之一，並從隊列中刪除該錯誤。 因此，要獲取當前隊列中的所有錯誤，您需要循環。
一個簡單的循環來提取當前的OpenGL錯誤：
格林厄爾 錯誤 ;
while （（ err = glGetError （）） ！= GL_NO_ERROR ）
{
//處理/記錄錯誤。
}
錯誤的含義
glGetError函數返回以下錯誤代碼之一，如果沒有（更多）錯誤可用，則返回GL_NO_ERROR 。 每個錯誤代碼表示一類用戶錯誤。
- GL_INVALID_ENUM ，0x0500
- 給定一個枚舉參數不是該函數的合法枚舉。 這只是爲了解決當地的問題。 如果規範允許枚舉某些情況下，其他參數或狀態決定這些情況，那麼GL_INVALID_OPERATION就是結果。
- GL_INVALID_VALUE ，0x0501
- 在給定值參數不是該函數的合法值時。 這隻適用於當地的問題; 如果規範允許某些情況下的值，其他參數或狀態指定這些情況，則GL_INVALID_OPERATION是結果。
- GL_INVALID_OPERATION ，0x0502
- 給定一個命令的狀態集合對於給定該命令的參數不合法。 它也給出了參數組合定義什麼是合法參數的命令。
- GL_STACK_OVERFLOW ，0x0503
- 鑑於堆棧推送操作無法完成，因爲它會溢出堆棧大小的限制。
- GL_STACK_UNDERFLOW ，0x0504
- 給定堆棧彈出操作無法完成時，因爲堆棧已經處於最低點。
- GL_OUT_OF_MEMORY ，0x0505
- 在執行可以分配內存的操作時給出，並且不能分配內存。 返回這個錯誤的OpenGL函數的結果是未定義的; 部分操作可以發生。
- GL_INVALID_FRAMEBUFFER_OPERATION ，0x0506
- 在做任何嘗試從不完整的幀緩衝區讀取或寫入/渲染的任何情況下。
- GL_CONTEXT_LOST ，0x0507（使用OpenGL 4.5 或 ARB_KHR_robustness ）
- 鑑於如果OpenGL上下文已經丟失，由於顯卡重置。
- GL_TABLE_TOO_LARGE 1，0x8031
- ARB_imaging擴展的一部分。
1 ：這些錯誤代碼在3.0中被棄用 ，並在3.1 核心及以上版本中被刪除。
在OpenGL參考文檔中，大多數錯誤都被明確列出。 但是，幾乎所有的OpenGL函數都可以生成GL_OUT_OF_MEMORY和GL_CONTEXT_LOST 。 並且可以根據與該特定函數調用不直接關聯的原因生成它們。
捕捉錯誤（簡單的方法）
調試輸出功能爲您的應用程序提供了一種簡單的方法，以便在驅動程序中發生OpenGL錯誤（或其他有趣的事件）時通過應用程序定義的消息回調函數進行通知。 只需啓用調試輸出，註冊回調，然後等待用DEBUG_TYPE_ERROR消息調用它。
此方法避免了在應用程序周圍花費昂貴且代碼混淆的glGetError（）調用來捕獲和本地化OpenGL錯誤的原因（並且需要將它們有條件地編譯爲調試版本以避免優化版本中的性能問題）。 該功能甚至可以確保消息回調函數在觸發GL錯誤（或性能警告）的GL調用的相同線程和調用堆棧中被調用。
顯示如何利用調試消息回調（例如，用於檢測OpenGL錯誤）的簡單示例：
void MessageCallback （ GLenum source ，
GLenum 類型 ，
GLuint ID ，
格林尼姆 嚴重性 ，
GLsizei 長度 ，
const GLchar * 消息 ，
const void * userParam ）
{
fprintf （ stderr ， “GL CALLBACK：％s type = 0x％x，severity = 0x％x，message =％s \ n ” ，
（ 鍵入 == GL_DEBUG_TYPE_ERROR ？ “** GL ERROR **” ： “” ），
類型 ， 嚴重性 ， 消息 ）;
}
//在init期間，啓用調試輸出
glEnable （ GL_DEBUG_OUTPUT ）;
glDebugMessageCallback （ （ GLDEBUGPROC ） MessageCallback ， 0 ）;
副作用
在大多數情況下，生成錯誤的函數將會退出，而不會更改任何OpenGL狀態或啓動任何OpenGL操作。 它們不會修改用戶傳遞給這些函數的任何客戶端內存（即：指針參數）。 在這樣的錯誤下，返回值爲零或者同樣無害。 但是，在某些情況下會發生錯誤，並修改OpenGL狀態。
每當生成GL_OUT_OF_MEMORY錯誤時，OpenGL上下文和/或對象的狀態都是未定義的 。
在OpenGL上下文丟失後，任何命令都會生成GL_CONTEXT_LOST錯誤（要求OpenGL 4.5 或 ARB_KHR_robustness ）。 這些命令沒有副作用，對於可能阻塞CPU的函數，有一些特殊情況例外。
多重綁定函數函數具有不同尋常的錯誤屬性。 由於它們聚合了一次綁定多個對象的能力，如果一個對象的綁定失敗並出現錯誤，則其他對象將按正常綁定。 只有錯誤的物體纔會失敗。 請注意，沒有辦法檢測哪些對象無法綁定（除了查詢每個綁定點的上下文）。
沒有錯誤上下文
| 核心版本 | 4.6 | |
|---|---|---|
| 核心版本 | 4.6 | |
| ARB擴展 | KHR_no_error | |
可以創建不報告OpenGL錯誤的OpenGL上下文 。 如果上下文位GL_CONTEXT_FLAG_NO_ERROR_BIT設置爲true，那麼上下文不會報告大多數錯誤。 在適當的情況下，它仍會報告GL_OUT_OF_MEMORY_ERROR ，但這可能會延遲到實際發生錯誤的時間點。 沒有其他錯誤會被報告。
這也意味着實現也不會檢查錯誤。 所以如果你給一個會引發錯誤的函數提供不正確的參數，你會得到未定義的行爲。這包括應用程序終止的可能性。
上下文不能有無錯誤位和健壯性或調試位。
以下是原文：
If the parameters of a function call do not match the set of parameters allowed by OpenGL, or do not interact reasonably with state that is already set in the context, then an OpenGL Error will result. The errors are presented as an error code.
For most OpenGL errors, and for most OpenGL functions, a function that emits an error will have no effect. No OpenGL state will be changed, no rendering will be initiated. It will be as if the function had not been called. There are a few cases where this is not the case.
| This article is a stub. You can help the OpenGL Wiki by expanding it. |
Contents
[hide]Catching errors (the hard way)
OpenGL errors are stored in a queue until the error is actually handled. Therefore, if you do not regularly test for errors, you will not know necessarily which function call elicited a particular error. As such, error testing should be done regularly if you need to know where an error came from.
To fetch the next error in the queue (and to remove it from the queue), call this function:
If the error queue is empty, it will return GL_NO_ERROR. Otherwise, it will return one of the error enumerators below and remove that error from the queue. So to fetch all of the errors currently in the queue, you would need to loop.
A simple loop to extract the current OpenGL errors:
GLenum err;
while((err = glGetError()) != GL_NO_ERROR)
{
// Process/log the error.
}
Meaning of errors
The glGetError function returns one of the following error codes, or GL_NO_ERROR if no (more) errors are available. Each error code represents a category of user error.
- GL_INVALID_ENUM, 0x0500
- Given when an enumeration parameter is not a legal enumeration for that function. This is given only for local problems; if the spec allows the enumeration in certain circumstances, where other parameters or state dictate those circumstances, then GL_INVALID_OPERATION is the result instead.
- GL_INVALID_VALUE, 0x0501
- Given when a value parameter is not a legal value for that function. This is only given for local problems; if the spec allows the value in certain circumstances, where other parameters or state dictate those circumstances, then GL_INVALID_OPERATION is the result instead.
- GL_INVALID_OPERATION, 0x0502
- Given when the set of state for a command is not legal for the parameters given to that command. It is also given for commands where combinations of parameters define what the legal parameters are.
- GL_STACK_OVERFLOW, 0x0503
- Given when a stack pushing operation cannot be done because it would overflow the limit of that stack's size.
- GL_STACK_UNDERFLOW, 0x0504
- Given when a stack popping operation cannot be done because the stack is already at its lowest point.
- GL_OUT_OF_MEMORY, 0x0505
- Given when performing an operation that can allocate memory, and the memory cannot be allocated. The results of OpenGL functions that return this error are undefined; it is allowable for partial operations to happen.
- GL_INVALID_FRAMEBUFFER_OPERATION, 0x0506
- Given when doing anything that would attempt to read from or write/render to a framebuffer that is not complete.
- GL_CONTEXT_LOST, 0x0507 (with OpenGL 4.5 or ARB_KHR_robustness)
- Given if the OpenGL context has been lost, due to a graphics card reset.
- GL_TABLE_TOO_LARGE1, 0x8031
- Part of the ARB_imaging extension.
1: These error codes are deprecated in 3.0 and removed in 3.1 core and above.
In the OpenGL Reference documentation, most errors are listed explicitly. However, GL_OUT_OF_MEMORY and GL_CONTEXT_LOST could be generated by virtually any OpenGL function. And they can be generated for reasons not directly associated with that particular function call.
Catching errors (the easy way)
The debug output feature provides a simple method for your application to be notified via an application-defined message callback function when an OpenGL error (or other interesting event) occurs within the driver. Simply enable debug output, register a callback, and wait for it to be called with a DEBUG_TYPE_ERROR message.
This method avoids the need to sprinkle expensive and code-obfuscating glGetError() calls around your application to catch and localize the causes of OpenGL errors (and the need to conditionally compile them into debug builds to avoid the performance hit in optimized builds). The feature can even ensure that message callback functions are invoked on the same thread and within the very same call stack as the GL call that triggered the GL error (or performance warning).
A simple example showing how to utilize debug message callbacks (e.g. for detecting OpenGL errors):
void MessageCallback( GLenum source,
GLenum type,
GLuint id,
GLenum severity,
GLsizei length,
const GLchar* message,
const void* userParam )
{
fprintf( stderr, "GL CALLBACK: %s type = 0x%x, severity = 0x%x, message = %s\n",
( type == GL_DEBUG_TYPE_ERROR ? "** GL ERROR **" : "" ),
type, severity, message );
}
// During init, enable debug output
glEnable ( GL_DEBUG_OUTPUT );
glDebugMessageCallback( (GLDEBUGPROC) MessageCallback, 0 );
Side effects
Under most circumstances, a function that generates an error will exit without changing any OpenGL state or initiating any OpenGL operations. They will not modify any client memory passed into those functions by the user (ie: pointer arguments). Under such errors, return values are zero or something equally innocuous. However, there are certain circumstances were an error happens and OpenGL state is modified.
Whenever the GL_OUT_OF_MEMORY error is generated, the state of the OpenGL context and/or objects is undefined.
The GL_CONTEXT_LOST error is generated (which requires OpenGL 4.5 or ARB_KHR_robustness) by any commands after the OpenGL context was lost. Those commands have no side effects, with a few special-case exceptions for functions that can block the CPU.
The multi-bind functions functions have unusual error properties. Because they aggregate the ability to bind multiple objects at once, if the binding of one object fails with an error, the others will be bound as normal. Only the erronous objects will fail to bind. Note that there is no way to detect which objects failed to bind (other than querying the context for each binding point).
No error contexts
| Core in version | 4.6 | |
|---|---|---|
| Core since version | 4.6 | |
| ARB extension | KHR_no_error | |
An OpenGL Context can be created which does not report OpenGL Errors. If the context bit GL_CONTEXT_FLAG_NO_ERROR_BIT is set to true, then the context will not report most errors. It will still report GL_OUT_OF_MEMORY_ERROR where appropriate, but this can be delayed from the point where the error actually happens. No other errors will be reported.
This also means that the implementation will not check for errors either. So if you provide incorrect parameters to a function that would have provoked an error, you will get undefined behavior instead. This includes the possibility of application termination.
Contexts cannot have the no error bit and the robustsness or debug bits.