| Name |
| |
| AMD_gpu_association |
| |
| Name Strings |
| |
| WGL_AMD_gpu_association |
| |
| Contact |
| |
| Nick Haemel, AMD (nick.haemel 'at' amd.com) |
| |
| Status |
| |
| Complete |
| |
| Version |
| |
| Last Modified Date: March 03, 2009 |
| Author Revision: 1.0 |
| |
| Based on: WGL_ARB_make_current_read specification |
| Date: 3/15/2000 Version: 1.1 |
| |
| EXT_framebuffer_object specification |
| Date: 2/13/2007 Revision #119 |
| |
| Number |
| |
| 361 |
| |
| Dependencies |
| |
| OpenGL 1.5 is required. |
| |
| WGL_ARB_extensions_string is required. |
| |
| GL_EXT_framebuffer_object is required. |
| |
| This extension interacts with WGL_ARB_make_current_read. |
| |
| This extension interacts with GL_EXT_framebuffer_blit. |
| |
| This extension interacts with WGL_ARB_create_context. |
| |
| |
| Overview |
| |
| |
| There currently is no way for applications to efficiently use GPU |
| resources in systems that contain more than one GPU. Vendors have |
| provided methods that attempt to split the workload for an |
| application among the available GPU resources. This has proven to be |
| very inefficient because most applications were never written with |
| these sorts of optimizations in mind. |
| |
| This extension provides a mechanism for applications to explicitly |
| use the GPU resources on a given system individually. By providing |
| this functionality, a driver allows applications to make appropriate |
| decisions regarding where and when to distribute rendering tasks. |
| |
| The set of GPUs available on a system can be queried by calling |
| wglGetGPUIDsAMD(). The current GPU assigned to a specific context |
| can be determined by calling wglGetContextGPUIDAMD. Each GPU in a |
| system may have different performance characteristics in addition |
| to supporting a different version of OpenGL. The specifics of each |
| GPU can be obtained by calling wglGetGPUInfo. This will allow |
| applications to pick the most appropriate GPU for each rendering |
| task. |
| |
| Once all necessary GPU information has been obtained, a context tied |
| to a specific GPU can be created with wglCreateAssociatedContextAMD. |
| These associated contexts can be made current with |
| wglMakeAssociatedContextCurrentAMD and deleted with |
| wglDeleteAssociatedContextAMD. Only one GPU associated or |
| non-associated context can be current at one time per thread. |
| |
| To provide an accelerated path for blitting data from one context |
| to another, the new blit function BlitContextFramebufferAMD has |
| been added. |
| |
| |
| |
| |
| New Procedures and Functions |
| |
| UINT wglGetGPUIDsAMD(UINT maxCount, UINT *ids); |
| |
| INT wglGetGPUInfoAMD(UINT id, INT property, GLenum dataType, |
| UINT size, void *data) |
| |
| UINT wglGetContextGPUIDAMD(HGLRC hglrc); |
| |
| HGLRC wglCreateAssociatedContextAMD(UINT id); |
| |
| HGLRC wglCreateAssociatedContextAttribsAMD(UINT id, HGLRC hShareContext, |
| const int *attribList); |
| |
| BOOL wglDeleteAssociatedContextAMD(HGLRC hglrc); |
| |
| BOOL wglMakeAssociatedContextCurrentAMD(HGLRC hglrc); |
| |
| HGLRC wglGetCurrentAssociatedContextAMD(void); |
| |
| VOID wglBlitContextFramebufferAMD(HGLRC dstCtx, GLint srcX0, GLint srcY0, |
| GLint srcX1, GLint srcY1, GLint dstX0, |
| GLint dstY0, GLint dstX1, GLint dstY1, |
| GLbitfield mask, GLenum filter); |
| |
| New Tokens |
| |
| Accepted by the <property> parameter of wglGetGPUInfo: |
| |
| WGL_GPU_VENDOR_AMD 0x1F00 |
| WGL_GPU_RENDERER_STRING_AMD 0x1F01 |
| WGL_GPU_OPENGL_VERSION_STRING_AMD 0x1F02 |
| WGL_GPU_FASTEST_TARGET_GPUS_AMD 0x21A2 |
| WGL_GPU_RAM_AMD 0x21A3 |
| WGL_GPU_CLOCK_AMD 0x21A4 |
| WGL_GPU_NUM_PIPES_AMD 0x21A5 |
| WGL_GPU_NUM_SIMD_AMD 0x21A6 |
| WGL_GPU_NUM_RB_AMD 0x21A7 |
| WGL_GPU_NUM_SPI_AMD 0x21A8 |
| |
| Accepted by the <dataType> argument of wglGetGPUInfoAMD: |
| |
| GL_UNSIGNED_BYTE |
| GL_UNSIGNED_INT |
| GL_INT |
| GL_FLOAT |
| |
| Accepted by the <mask> argument of wglBlitContextFramebufferAMD: |
| |
| GL_COLOR_BUFFER_BIT |
| GL_DEPTH_BUFFER_BIT |
| GL_STENCIL_BUFFER_BIT |
| |
| |
| Additions to the GLX Specification |
| |
| This specification is written for WGL. |
| |
| |
| GLX Protocol |
| |
| This specification is written for WGL. |
| |
| |
| Additions to the WGL Specification |
| |
| GPU Associated Contexts |
| |
| When multiple GPUs are present, a context can be created for |
| off-screen rendering that is associated with a specific GPU. |
| This will allow applications to achieve an app-specific |
| distributed GPU utilization. |
| |
| The IDs for available GPUs can be queried with the command: |
| |
| UINT wglGetGPUIDsAMD(UINT maxCount, UINT *ids); |
| |
| where <maxCount> is the max number of IDs that can be returned and |
| <ids> is the array of returned IDs. If the function succeeds, |
| the return value is the number of total GPUs available. The |
| value 0 is returned if no GPUs are available or if the call has |
| failed. The array pointer <ids> passed into the function will be |
| populated by the smaller of maxCount or the total GPU count |
| available. The ID 0 is reserved and will not be retuned as a |
| valid GPU ID. If the array <ids> is NULL, the function will |
| only return the total number of GPUs. <ids> will be tightly packed |
| with no 0 values between valid ids. |
| |
| Calling wglGetGPUIDsAMD once with <maxCount> set to zero returns |
| the total available GPU count which can be used to allocate an |
| appropriately sized id array before calling wglGetGPUIDsAMD |
| again to query the full set of supported GPUs. |
| |
| Each GPU in a system may have different properties, performance |
| characteristics and different supported OpenGL versions. To |
| determine which GPU is best suited for a specific task the |
| following functions may be used: |
| |
| INT wglGetGPUInfoAMD(UINT id, INT property, GLenum dataType, |
| UINT size, void *data); |
| |
| <id> is a GPU id obtained from calling wglGetGPUIDsAMD. The GPU ID |
| must be a valid GPU ID. The function will fail if <id> is an invalid |
| GPU ID and -1 will be returned. <property> is the information being |
| queried. <dataType> may be GL_UNSIGNED_INT, GL_INT, GL_FLOAT, or |
| GL_UNSIGNED_BYTE and signals what data type is to be returned. <size> |
| signals the size of the data buffer passed into wglGetGPUInfoAMD. |
| This is the count of the array of type <dataType>. <data> is the |
| buffer which will be filled with the requested information. For a |
| string, <size> will be the number of characters allocated and will |
| include NULL termination. For arrays of type GL_UNSIGNED_INT, GL_INT, |
| and GL_FLOAT <size> will be the array depth. If the function |
| succeeds, the number of values written will be returned. If the number |
| of values written is equal to <size>, the query should be repeated with |
| a larger <data> buffer. Strings should be queried using the |
| GL_UNSIGNED_BYTE type, are UTF-8 encoded and will be NULL terminated. |
| If the function fails, -1 will be returned. |
| |
| <property> defines the GPU property to be queried, and may be one of |
| WGL_GPU_OPENGL_VERSION_STRING_AMD, WGL_GPU_RENDERER_STRING_AMD, |
| WGL_GPU_FASTEST_TARGET_GPUS_AMD, WGL_GPU_RAM_AMD, WGL_GPU_CLOCK_AMD, |
| WGL_GPU_NUM_PIPES_AMD, WGL_GPU_NUM_SIMD_AMD, WGL_GPU_NUM_RB_AMD, or |
| WGL_GPU_NUM_SPI_AMD. |
| |
| If <size> is not sufficient to hold the entire value for a particular |
| property, the number of values returned will equal <size>. If |
| <dataType> is inappropriate for <property>, for instance INT for a |
| property which is a string, the function will fail and -1 will be |
| returned. |
| |
| Querying WGL_GPU_OPENGL_VERSION_STRING_AMD returns the highest supported |
| OpenGL version string and WGL_GPU_RENDERER_STRING_AMD returns name |
| of the GPU. <dataType> must be GL_UNSIGNED_BYTE with the previous |
| properties. Querying WGL_GPU_FASTEST_TARGET_GPUS_AMD returns an array |
| of the IDs of GPUs with the fastest data blit rates when using |
| wglBlitContextFramebufferAMD. This list is ordered fastest |
| first. This provides a performance hint about which contexts and GPUS |
| are capable of transfering data between each other the quickest. Querying |
| WGL_GPU_RAM_AMD returns the amount of RAM available to GPU in MB. Querying |
| WGL_GPU_CLOCK_AMD returns the GPU clock speed in MHz. Querying |
| WGL_GPU_NUM_PIPES_AMD returns the nubmer of 3D pipes. Querying |
| WGL_GPU_NUM_SIMD_AMD returns the number of SIMD ALU units in each |
| shader pipe. Querying WGL_GPU_NUM_RB_AMD returns the number of render |
| backends. Querying WGL_GPU_NUM_SPI_AMD returns the number of shader |
| parameter interpolaters. If the <parameter> being queried is not |
| applicable for the GPU specified by <id>, the value 0 will be returned. |
| |
| Unassociated contexts are created by calling wglCreateContext. |
| Although these contexts are unassociated, their use will still be |
| tied to a single GPU in most cases. For this reason it is advantageous |
| to be able to query the GPU an existing unassociated context resides |
| on. If multiple GPUs are available, it would be undesirable |
| to use one for rendering to visible surfaces and then chose the |
| same one for off-screen rendering. Use the following command to |
| determine which GPU a context is attached to: |
| |
| UINT wglGetContextGPUIDAMD(HGLRC hglrc); |
| |
| <hglrc> is the context for which the GPU id will be returned. If the |
| context is invalid or if an error has occurred, wglGetContextGPUIDAMD |
| will return 0. |
| |
| To create an associated context, use: |
| |
| HGLRC wglCreateAssociatedContextAMD(UINT id); |
| |
| <id> must be a valid GPU id and cannot be 0. If a context was |
| successfully created the handle will be returned by |
| wglCreateAssociatedContextAMD. If a context could not be created, NULL |
| will be returned. If a context could not be created, error information |
| can be obtained by calling GetLastError. Upon successful creation, |
| no pixel format is tied to an associated context. |
| |
| To create an associated context and request a specific GL version, use: |
| |
| HGLRC wglCreateAssociatedContextAttribsAMD(UINT id, |
| HGLRC hShareContext, const int *attribList) |
| |
| All capabilities and limitations of wglCreateContextAttribsARB apply |
| to wglCreateAssociatedContextAttribsAMD. Additionally, <id> must be |
| a valid GPU ID and cannot be 0. If a context was successfully created |
| the handle will be returned by wglCreateAssociatedContextAttribsAMD. |
| If a context could not be created, NULL will be returned. In this |
| case, error information can be obtained by calling GetLastError. Upon |
| successful creation, no pixel format is tied to an associated context. |
| |
| <hShareContext> must either be NULL or that of an associated context |
| created with the the same GPU ID as <id>. If <hShareContext> was |
| created using a different ID, wglCreateAssociatedContextAttribsAMD |
| will fail and return NULL. |
| |
| |
| A context must be deleted once it is no longer needed. Use the |
| following call to delete an associated context: |
| |
| BOOL wglDeleteAssociatedContextAMD(HGLRC hglrc); |
| |
| If the function succeeds, TRUE will be returned, otherwise FALSE is |
| returned. <hglrc> must be a valid associated context created by |
| calling wglCreateAssociatedContextAMD. If an unassociated context, |
| created by calling wglCreateContext, is passed into <hglrc>, the |
| function will fail. An associated context cannot be deleted by calling |
| wglDeleteContext. If an associated context is passed into |
| wglDeleteContext, the result is undefiend. |
| |
| To render using an associated context, it must be made the current |
| context for a thread: |
| |
| BOOL wglMakeAssociatedContextCurrentAMD(HGLRC hglrc); |
| |
| <hglrc> is a context handle created by calling |
| wglCreateAssociatedContextAMD. If <hglrc> was created using |
| wglCreateContext, the call will fail and FALSE will be returned. If |
| <hglrc> is not a valid context and not NULL, the call will fail and |
| FALSE will be returned. If the call succeeds, TRUE will be returned. |
| To detach the current associated context, pass NULL as <hglrc>. |
| |
| Only one type of context can be current to a thread at a time. If an |
| unassociated context is current to a hdc when |
| wglMakeAssociatedContextCurrentAMD is called with a valid <hglrc>, it |
| is as if wglMakeCurrent is called first with an hglrc of NULL. If an |
| associated context is current and wglMakeCurrent is called with a |
| valid context, it is as if wglMakeAssociatedContextCurrentAMD is |
| called with an hglrc of NULL. |
| |
| The current associated context can be queried by calling: |
| |
| HGLRC wglGetCurrentAssociatedContextAMD(void); |
| |
| The current associated context is returned on a successful call to |
| this function. If no associated context is current, NULL is returned. |
| If an unassociated context is current, NULL will be returned. |
| |
| Associated contexts can be shared just as unassociated contexts can by |
| calling wglShareLists. Associated contexts can only be shared with |
| other contexts that were created with the same GPU id. Associated |
| contexts cannot be shared with non-associated contexts. FALSE will be |
| returned if either context is not valid or not an associated context |
| associated with the same GPU. |
| |
| An associated context can not be passed in as a parameter into |
| wglCopyContext. If an associated context is passed into wglCopyContext, |
| the result is undefiend. |
| |
| The addresses returned from wglGetProcAddress are only valid for the |
| current context. It may be invalid to use proc addresses obtained from |
| a traditional context with an associated context. Furthermore, the |
| OpenGL version and extensions supported on an associated context may |
| differ. Each context should be treated seperately, proc addressses |
| should be queried for each after context creation. |
| |
| Calls to wglSwapBuffers and wglSwapLayerBuffers when an associated |
| context is current will return FALSE and will have no effect. |
| |
| There is no way to use pBuffers with associated contexts. |
| |
| Overlays and underlays are not supported with associated contexts. |
| |
| The same associated context is used for both write and read operations. |
| |
| To facilitate high performance data communication between multiple |
| contexts, a new function is necessary to blit data from one context |
| to another. |
| |
| VOID wglBlitContextFramebufferAMD(HGLRC dstCtx, GLint srcX0, GLint srcY0, |
| GLint srcX1, GLint srcY1, GLint dstX0, |
| GLint dstY0, GLint dstX1, GLint dstY1, |
| GLbitfield mask, GLenum filter); |
| |
| <dstCtx> is the context handle for the write context. <mask> is the |
| bitwise OR of a number of values indicating which buffers are to be |
| copied. The values are GL_COLOR_BUFFER_BIT, GL_DEPTH_BUFFER_BIT, and |
| GL_STENCIL_BUFFER_BIT, which are described in section 4.2.3. The |
| pixels corresponding to these buffers are copied from the source |
| rectangle, bound by the locations (srcX0, srcY0) and (srcX1, srcY1), |
| to the destination rectangle, bound by the locations (dstX0, dstY0) |
| and (dstX1, dstY1). The lower bounds of the rectangle are inclusive, |
| while the upper bounds are exclusive. |
| |
| The source context is the current GL context. Specifying the current |
| GL context as the <dstCtx> will result in the error |
| GL_INVALID_OPERATION being generated. If <dstCtx> is invalid, the |
| error GL_INVALID_OPERATION will be generated. If no context is |
| current at the time of this call, the error GL_INVALID_OPERATION |
| will be generated. These errors may be queried by calling glGetError. |
| The target framebuffer will be the framebuffer bound to |
| GL_DRAW_FRAMEBUFFER_EXT in the context <dstCtx>. The source framebuffer |
| will be the framebuffer bound to GL_READ_FRAMEBUFFER_EXT in the |
| currently bound context. |
| |
| The restrictions that apply to the source and destination rectangles |
| specified with <srcX0>, <srcY0>, <srcX1>, <srcY1>, <dstX0>, <dstY0> |
| <dstX0>, and <dstY0> are the same as those that apply for |
| glBlitFramebufferEXT. The same error conditions exist as for |
| glBlitFramebufferEXT. |
| |
| When called, this function will execute immediately in the currently |
| bound context. It is up to the caller to maintain appropriate |
| synchronization between the current context and <dstCtx> to ensure |
| rendering to the appropriate surfaces has completed on the current |
| and <dstCtx> contexts. |
| |
| Additions to Chapter 4 of the OpenGL 1.5 Specification (Per-Fragment |
| Operations and the Frame Buffer) |
| Modify the beginning of section 4.4.1 as follows: |
| |
| When an assoicated context is bound, the default state for an associated |
| context is invalid for rendering. Because there is no attached window, |
| there is no default framebuffer surface to render to. An app created |
| framebuffer object must be bound for rendering to be valid. If the |
| object bound to GL_FRAMEBUFFER_BINDING_EXT is 0, it is as if the |
| framebuffer is incomplete, and an |
| GL_INVALID_FRAMEBUFFER_OPERATION_EXT error will be generated |
| where rendering is attempted. |
| |
| |
| New State |
| |
| None |
| |
| |
| Interactions with GL_EXT_framebuffer_blit |
| |
| If the framebuffer blit extension is not supported, all language |
| referring to glBlitFramebufferEXT and wglBlitContextFramebufferAMD |
| is removed. |
| |
| Interactions with GL_EXT_framebuffer_object |
| |
| If WGL_AMD_gpu_association is supported, and context created with it |
| will also support EXT_framebuffer_object. |
| |
| |
| Interactions with WGL_ARB_make_current_read |
| |
| If the make current read extension is supported, it is invalid to pass |
| an associated context handle as a parameter to |
| wglMakeContextCurrentARB. If an associated context is passed into |
| wglMakeContextCurrentARB, the result is undefiend. |
| |
| Interactions with WGL_ARB_create_context |
| If wglCreateContextAttribsARB is not supported, all language |
| referring to wglCreateAssociatedContextAttribsAMD is removed. |
| |
| |
| Issues |
| |
| 1. Is a different DC necessary in addition to an associated context? |
| |
| - Resolved. It seems unnecessary. An associated DC would be a virtual |
| DC with no real meaning. Using an associated DC would require apps to |
| create windows and set pixelformats that are meaningless. |
| |
| 2. Should the list of IDs returned by wglGetGPUIDs be ordered in some |
| way? By fastest GPU? |
| |
| - Resolved. There is no need to create a restriction. The GPU info can |
| be queried. |
| |
| 3. What happens when the GPUs support different versions of OpenGL? |
| Do we allow this? Do we need the |
| |
| - Resolved. It is the applications responsibility to use each GPU |
| appropriately based on the supported version of OpenGL. |
| |
| 4. What should the relation between wglMakeAssociatedContextCurrentAMD and |
| wglMakeCurrent be? Should it be legal to have an associated context and a |
| normal context current to the same thread? |
| |
| - Resolved. It seems feasible to have an associated context and a normal |
| one both current, but for simplicity, only one of any type will be allowed |
| per thead. |
| |
| 5. Will a call to wglShareLists with contexts that were not created through |
| wglCreateContext make it through to the driver? If not, will a new |
| shareLists call be necessary? |
| |
| -Resolved. This is not an issue. |
| |
| 6. Is GPUClock a good parameter for the GPUInfo structure? How should |
| relative GPU performance be presented? |
| |
| - Resolved. This is sufficent. One alternative would be to test execution of |
| some amount of geometry rendering. But applications are better positioned |
| to perform this based on their rendering needs. |
| |
| 7. Is BlitContextFramebufferEXT the best way to transfer data from one |
| context to another? Or would it be better to create a read and write |
| context bind point? |
| |
| - Resolved. Both methods would work well. Adding a new function prevents |
| the additional state that would have to be tracked for a global read and |
| write bind point. In addition, using global (wgl) bind points may |
| introduce mutability issues when multiple threads are being used. |
| Only one thread could use the interface at a time. |
| |
| 8. Should the GPU ID be part of the pixel format? That would allow |
| apps to search for a format that worked on different GPUs. |
| |
| - Resolved. Using the pixel format would provide a non-intrusive solution, |
| but would require the app to use a DC that is not available through |
| current interfaces. In addition, the app would have to create a |
| dummy window. |
| |
| 9. Are there any problems calling wglShareLists with contexts not created |
| by Windows? |
| |
| - Resolved. This is not an issue. |
| |
| 10. What should happen in an associated context when the default FBO is |
| bound? The 2 options seem to be 1. Throw an error and do not render, |
| 2. Discard all rendering as failing the pixel ownership test. |
| |
| - The first option seems more logical. |
| |
| |
| Revision History |
| 03/03/2009 - Initial version written. Written by nickh |
