Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Results 1 to 3 of 3

Thread: Multiple GPU Nvidia QuadroPlex

  1. #1
    Newbie Newbie
    Join Date
    May 2013
    Posts
    2

    Multiple GPU Nvidia QuadroPlex

    Hi All,

    I found that doc. which desrcibes how to create an off-screen renderContext.

    I use OGRE and I put example2 (from the below doc.) to the source of OGRE.

    My question is how to link the affinityRenderingContext and the already defined windowRenderingContext?
    Put it the other way around, how to create an on-screen renderContext from the affintiyContext!

    Any response would be appreciated! Thanks

    Code :
    Doc:
    Name
     
          WGL_NV_gpu_affinity
     
    Name Strings
     
     
          WGL_NV_gpu_affinity
     
    Contact
     
     
          Barthold Lichtenbelt, NVIDIA (blichtenbelt 'at' nvidia.com)
     
    Notice
     
     
          Copyright  NVIDIA Corporation, 2005-2006.
     
    Status
     
     
          Completed.
     
    IP Status
     
     
          NVIDIA proprietary.
     
    Version
     
     
          Last Modified Date: 10/08/2006
          Author revision: 10
     
    Number
     
     
          ???
     
    Dependencies
     
     
          WGL_ARB_extensions_string is required.
     
          This extension interacts with WGL_ARB_make_current_read.
     
          This extension interacts with WGL_ARB_pbuffer.
     
          This extension interacts with GL_EXT_framebuffer_object
     
    Overview
     
     
          On systems with more than one GPU it is desirable to be able to
          select which GPU(s) in the system become the target for OpenGL
          rendering commands. This extension introduces the concept of a GPU
          affinity mask. OpenGL rendering commands are directed to the
          GPU(s) specified by the affinity mask. GPU affinity is immutable.
          Once set, it cannot be changed.
     
          This extension also introduces the concept called affinity-DC. An
          affinity-DC is a device context with a GPU affinity mask embedded
          in it. This restricts the device context to only allow OpenGL
          commands to be sent to the GPU(s) in the affinity mask.
     
          Handles for the GPUs present in a system are enumerated with the
          command wglEnumGpusNV. An affinity-DC is created by calling
          wglCreateAffinityDCNV. This function takes a list of GPU handles,
          which make up the affinity mask. An affinity-DC can also
          indirectly be created by obtaining a DC from a pBuffer handle, by
          calling wglGetPbufferDC, which in turn was created from an
          affinity-DC by calling wglCreatePbuffer.
     
          A context created from an affinity DC will inherit the GPU
          affinity mask from the DC. Once inherited, it cannot be changed.
          Such a context is called an affinity-context. This restricts the
          affinity-context to only allow OpenGL commands to be sent to those
          GPU(s) in its affinity mask. Once created, this context can be
          used in two ways:
     
            1. Make the affinity-context current to an affinity-DC. This
               will only succeed if the context's affinity mask is the same
               as the affinity mask in the DC. There is no window
               associated with an affinity DC, therefore this is a way to
               achieve off-screen rendering to an OpenGL context. This can
               either be rendering to a pBuffer, or an application created
               framebuffer object. In the former case, the affinity-mask of
               the pBuffer DC, which is obtained from a pBuffer handle,
               will be the same affinity-mask as the DC used to created the
               pBuffer handle.  In the latter case, the default framebuffer
               object will be incomplete because there is no window-system
               created framebuffer. Therefore, the application will have to
               create and bind a framebuffer object as the target for
               rendering.
            2. Make the affinity-context current to a DC obtained from a
               window. Rendering only happens to the sub rectangles(s) of
               the window that overlap the parts of the desktop that are
               displayed by the GPU(s) in the affinity mask of the context.
     
          Sharing OpenGL objects between affinity-contexts, by calling
          wglShareLists, will only succeed if the contexts have identical
          affinity masks.
     
          It is not possible to make a regular context (one without an
          affinity mask) current to an affinity-DC. This would mean a way
          for a context to inherit affinity information, which makes the
          context affinity mutable, which is counter to the premise of this
          extension.
     
    New Procedures, Functions and Structures:
     
     
          DECLARE_HANDLE(HGPUNV);
     
          typedef struct _GPU_DEVICE {
            DWORD  cb;
            CHAR   DeviceName[32];
            CHAR   DeviceString[128];
            DWORD  Flags;
            RECT   rcVirtualScreen;
          } GPU_DEVICE, *PGPU_DEVICE;
     
          BOOL wglEnumGpusNV(UINT iGpuIndex,
                            HGPUNV *phGpu);
     
          BOOL wglEnumGpuDevicesNV(HGPUNV hGpu,
                                 UINT iDeviceIndex,
                                 PGPU_DEVICE lpGpuDevice);
     
          HDC wglCreateAffinityDCNV(const HGPUNV *phGpuList);
     
          BOOL wglEnumGpusFromAffinityDCNV(HDC hAffinityDC,
                                         UINT iGpuIndex,
                                         HGPUNV *hGpu);
     
          BOOL wglDeleteDCNV(HDC hdc);
     
    New Tokens
     
     
          New error codes set by wglShareLists, wglMakeCurrent and
          wglMakeContextCurrentARB:
     
          ERROR_INCOMPATIBLE_AFFINITY_MASKS_NV    0x20D0
     
          New error codes set by wglMakeCurrent and
          wglMakeContextCurrentARB:
     
          ERROR_MISSING_AFFINITY_MASK_NV          0x20D1
     
    Additions to the WGL Specification
     
     
          GPU Affinity
     
          To query handles for all GPUs in a system call:
     
               BOOL wglEnumGpusNV(UINT iGpuIndex, HGPUNV *phGPU);
     
          <iGpuIndex> is an index value that specifies a GPU.
     
          <phGPU> upon return will contain a handle for GPU number
          <iGpuIndex>. The first GPU will be index 0.
     
          By looping over wglEnumGpusNV and incrementing <iGpuIndex>,
          starting at index 0, all GPU handles can be queried. If the
          function succeeds, the return value is TRUE. If the function
          fails, the return value is FALSE and <phGPU> will be unmodified.
          The function fails if <iGpuIndex> is greater or equal than the
          number of GPUs supported by the system.
     
          To retrieve information about the display devices supported by a
          GPU call:
     
               BOOL wglEnumGpuDevicesNV(HGPUNV hGpu,
                                       UINT iDeviceIndex,
                                       PGPU_DEVICE lpGpuDevice);
     
          <hGpu> is a handle to the GPU to query.
     
          <iDeviceIndex> is an index value that specifies a display device,
          supported by <hGpu>, to query. The first display device will be
          index 0.
     
          <lpGpuDevice> pointer to a GPU_DEVICE structure which will receive
          information about the display device at index <iDeviceIndex>.
     
          By looping over the function wglEnumGpuDevicesNV and incrementing
          <iDeviceIndex>, starting at index 0, all display devices can be
          queried. If the function succeeds, the return value is TRUE. If
          the function fails, the return value is FALSE and <lpGpuDevice>
          will be unmodified. The function fails if <iDeviceIndex> is
          greater or equal than the number of display devices supported by
          <hGpu>.
     
          The GPU_DEVICE structure has the following members:
     
               typedef struct _GPU_DEVICE {
                 DWORD  cb;
                 CHAR   DeviceName[32];
                 CHAR   DeviceString[128];
                 DWORD  Flags;
                 RECT   rcVirtualScreen;
               } GPU_DEVICE, *PGPU_DEVICE;
     
          <cb> is the size of the GPU_DEVICE structure. Before calling
          wglEnumGpuDevicesNV, set <cb> to the size, in bytes, of
          GPU_DEVICE.
     
          <DeviceName> is a string identifying the display device name. This
          will be the same string as stored in the <DeviceName> field of the
          DISPLAY_DEVICE structure, which is filled in by
          EnumDisplayDevices.
     
          <DeviceString> is a string describing the GPU for this display
          device. It is the same string as stored in the <DeviceString>
          field in the DISPLAY_DEVICE structure that is filled in by
          EnumDisplayDevices when it describes a display adapter (and not a
          monitor).
     
          <Flags> Indicates the state of the display device. It can be a
          combination of any of the following:
     
          DISPLAY_DEVICE_ATTACHED_TO_DESKTOP      If set, the device is part
          of the desktop.
     
          DISPLAY_DEVICE_PRIMARY_DEVICE           If set, the primary
          desktop is on this device. Only one device in the system can have
          this set.
     
          <rcVirtualScreen> specifies the display device rectangle, in
          virtual screen coordinates. The value of <rcVirtualScreen> is
          undefined if the device is not part of the desktop, i.e.
          DISPLAY_DEVICE_ATTACHED_TO_DESKTOP is not set in the <Flags>
          field.
     
          The function wglEnumGpuDevicesNV can fail for a variety of
          reasons. Call GetLastError to get extended error information.
          Possible errors are as follows:
     
          ERROR_INVALID_HANDLE   <hGpu> is not a valid GPU handle.
     
          A new type of DC, called an affinity-DC, can be used to direct
          OpenGL commands to a specific GPU or set of GPUs. An affinity-DC
          is a device context with a GPU affinity mask embedded in it. This
          restricts the device context to only allow OpenGL commands to be
          sent to the GPU(s) in the affinity mask. An affinity-DC can be
          created directly, using the new function wglCreateAffinityDCNV and
          also indirectly by calling wglCreatePbufferARB followed by
          wglGetPbufferDCARB. To create an affinity-DC directly call:
     
               HDC wglCreateAffinityDCNV(const HGPUNV *phGpuList);
     
          <phGpuList> is a NULL-terminated array of GPU handles to which the
          affinity-DC will be restricted. If an element in the list is not a
          GPU handle, as returned by wglEnumGpusNV, it is silently ignored.
     
          If successful, the function returns an affinity-DC. If it fails,
          NULL will be returned.
     
          To create an affinity-DC indirectly, first call
          wglCreatePbufferARB passing it an affinity-DC. Next, pass the
          handle returned by the call to wglCreatePbufferARB to
          wglGetPbufferDCARB to create an affinity-DC for the pBuffer. The
          DC returned by wglGetPbufferDCARB will have the same affinity mask
          as the DC used to create the pBuffer handle by calling
          wglCreatePbufferARB.
     
          An affinity-DC has no window associated with it, and therefore it
          has no default window-system-provided framebuffer. (Note: This is
          terminology borrowed from EXT_framebuffer_object). A context made
          current to an affinity-DC will only be able to render into an
          application-created framebuffer object, or a pBuffer. The default
          window-system-framebuffer object, when bound, will be incomplete.
          The EXT_framebuffer_object specification defines what 'incomplete'
          means exactly.
     
          A context created from an affinity-DC, by calling wglCreateContext
          and passing it an affinity-DC, is called an affinity-context. This
          context will inherit the affinity mask from the DC. This affinity-
          mask cannot be changed. The affinity mask restricts the affinity-
          context to only allow OpenGL commands to be sent to those GPU(s)
          in its affinity mask.
     
          The function wglCreateAffinityDCNV can fail for a variety of
          reasons. Call GetLastError to get extended error information.
          Possible errors are as follows:
     
          ERROR_NO_SYSTEM_RESOURCES    Insufficient resources exist to
          create the affinity-DC.
     
          ERROR_INVALID_DATA           <phGpuList> is empty or contains no
          valid GPU handles
     
          An affinity-context can only be made current to an affinity-DC
          with the same affinity-mask, otherwise wglMakeCurrent and
          wglMakeContextCurrentARB will fail and return FALSE. In the case
          of wglMakeContextCurrentARB, the affinity masks of both the "read"
          and "draw" DCs need to match the affinity-mask of the context.
     
          If a context that has no affinity mask is made current to an
          affinity-DC, wglMakeCurrent and wglMakeContextCurrentARB will fail
          and return FALSE. In the case of wglMakeContextCurrentARB it will
          fail if either the "read" or "draw" DC is an affinity-DC.
     
          If an affinity-context is made current to a DC obtained from a
          window, by calling GetDC, then rendering will only happen to the
          subrectangle(s) of the window that overlap the parts of the
          desktop that are displayed by the GPU(s) in the affinity-mask of
          the context. Note that a DC obtained from a window does not have
          an affinity mask set.
     
          The following error codes are added to the description of
          wglMakeCurrent and wglMakeContextCurrentARB:
     
          ERROR_INCOMPATIBLE_AFFINITY_MASKS_NV    The device context(s) and
          rendering context have non-matching affinity masks.
     
          ERROR_MISSING_AFFINITY_MASK_NV          The rendering context does
          not have an affinity mask set.
     
          Sharing OpenGL objects between affinity-contexts, by calling
          wglShareLists, will only succeed if the contexts have identical
          affinity masks. The following error codes are added to the
          description of wglShareLists:
     
          ERROR_INCOMPATIBLE_AFFINITY_MASKS_NV    The contexts have non-
          matching affinity masks.
     
          To delete an affinity-DC call:
     
               BOOL wglDeleteDCNV(HDC hdc)
     
          <hdc> Is a handle of an affinity-DC to delete.
     
          If the function succeeds, TRUE is returned. If the function fails,
          FALSE is returned. Call GetLastError to get extended error
          information. Possible errors are as follows:
     
          ERROR_INVALID_HANDLE   <hdc> is not a handle of an affinity-DC.
     
          To retrieve a list of GPU handles that make up the affinity-mask
          of an affinity-DC, call:
     
               BOOL wglEnumGpusFromAffinityDCNV(HDC hAffinityDC,
                                               UINT iGpuIndex,
                                               HGPUNV *phGpu);
     
          <hAffinityDC> is a handle of the affinity-DC to query.
     
          <iGpuIndex> is an index value of the GPU handle in the affinity
          mask of <hAffinityDC> to query.
     
          <phGpu> upon return will contain a handle for GPU number
          <iGpuIndex>. The first GPU will be at index 0.
     
          By looping over wglEnumGpusFromAffinityDCNV and incrementing
          <iGpuIndex>, starting at index 0, all GPU handles associated with
          the DC can be queried. If the function succeeds, the return value
          is TRUE. If the function fails, the return value is FALSE and
          <phGPU> will be unmodified. The function fails if <iGpuIndex> is
          greater or equal than the number of GPUs associated with
          <hAffinityDC>.
     
          Call GetLastError to get extended error information. Possible
          errors are as follows:
     
          ERROR_INVALID_HANDLE   <hAffinityDC> is not a handle of an
          affinity-DC.
     
    Interactions with WGL_ARB_make_current_read
     
     
          If the make current read extension is not supported, all language
          referring to wglMakeContextCurrentARB is deleted.
     
    Interactions with WGL_ARB_pbuffer
     
     
          If the pbuffer extension is not supported, all language referring
          to puffers, wglGetPbuferDC and wglCreatePbuffer are deleted.
     
    Interactions with GL_EXT_framebuffer_object
     
     
          If the framebuffer object extension is not supported, all language
          referring to framebuffer objects is deleted.
     
    Usage examples
     
     
          // Example 1 - Normal window creation, DC setup and
          // context creation.
     
          PIXELFORMATDESCRIPTOR pfd;
          int   pf;
          HDC   hDC;
          HGLRC hRC;
          HWND  hWnd;
     
          hWnd = CreateWindow(...);
          hDC = GetDC(hWnd);
     
          memset(&pfd, 0, sizeof(pfd));
          pfd.nSize        = sizeof(pfd);
          pfd.nVersion     = 1;
          pfd.dwFlags      = PFD_DRAW_TO_WINDOW | PFD_SUPPORT_OPENGL;
          pfd.iPixelType   = PFD_TYPE_RGBA;
          pfd.cColorBits   = 32;
     
          // Note, for ease of code reading no error checking is done.
          pf = ChoosePixelFormat(hDC, &pfd);
          SetPixelFormat(hDC, pf, &pfd);
          DescribePixelFormat(hDC, pf, sizeof(PIXELFORMATDESCRIPTOR),
                              &pfd);
     
          hRC = wglCreateContext(hDC);
          wglMakeCurrent(hDC, hRC);
     
     
          // Example 2 - Offscreen rendering to one GPU using a FBO
          // It is assumed that a context already has been created (and
          // possibly destroyed) and was used to query the proc addresses
          // of the WGL affinity related entrypoints.
     
          #define MAX_GPU 4
     
          PIXELFORMATDESCRIPTOR pfd;
          int    pf, gpuIndex = 0;
          HGPUNV hGPU[MAX_GPU];
          HGPUNV GpuMask[MAX_GPU];
          HDC    affDC;
          HGLRC  affRC;
     
          // Get a list of the first MAX_GPU GPUs in the system
          while ((gpuIndex < MAX_GPU) && wglEnumGpusNV(gpuIndex,
          &hGPU[gpuIndex])) {
                gpuIndex++;
          }
     
          // Create an affinity-DC associated with the first GPU
          GpuMask[0] = hGPU[0];
          GpuMask[1] = NULL;
     
          affDC = wglCreateAffinityDCNV(GpuMask);
     
          // Set a pixelformat on the affinity-DC
          pf = ChoosePixelFormat(affDC, &pfd);
          SetPixelFormat(affDC, pf, &pfd);
          DescribePixelFormat(affDC, pf, sizeof(PIXELFORMATDESCRIPTOR),
          &pfd);
     
          affRC = wglCreateContext(affDC);
          wglMakeCurrent(affDC, affRC);
     
          // Make a previously created FBO current so we have something
          // to render into. Since there's no window, the default system
          // created FBO is incomplete.
          glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fb);
     
           <Now draw>
     
     
          // Example 3 - Offscreen rendering to one GPU using a pBuffer
          // It is assumed that a context already has been created (and
          // possibly destroyed) and was used to query the proc addresses
          // of the WGL affinity and pbuffer related entrypoints.
     
          #define MAX_GPU 4
     
          int    gpuIndex = 0;
          HGPUNV hGPU[MAX_GPU];
          HGPUNV GpuMask[MAX_GPU];
          HDC    affDC, pBufferAffDC;
          HGLRC  affRC;
     
          // Get a list of the first MAX_GPU GPUs in the system
          while ((gpuIndex < MAX_GPU) && wglEnumGpusNV(gpuIndex,
          &hGPU[gpuIndex])) {
                gpuIndex++;
          }
     
          // Create an affinity-DC associated with the first GPU
          GpuMask[0] = hGPU[0];
          GpuMask[1] = NULL;
     
          affDC = wglCreateAffinityDCNV(GpuMask);
     
          // Setup desired pixelformat attributes for the pbuffer
          // including WGL_DRAW_TO_PBUFFER_ARB.
          HPBUFFERARB  handle;
          int          width = 512, height = 512, format = 0;
          unsigned int nformats;
     
          int attribList[] =
          {
              WGL_RED_BITS_ARB,               8,
              WGL_GREEN_BITS_ARB,             8,
              WGL_BLUE_BITS_ARB,              8,
              WGL_ALPHA_BITS_ARB,             8,
              WGL_STENCIL_BITS_ARB,           0,
              WGL_DEPTH_BITS_ARB,             0,
              WGL_DRAW_TO_PBUFFER_ARB,        true,
              0,
          };
     
          wglChoosePixelFormatARB(affDC, attribList, NULL, 1,
                                  &format, &nformats);
     
          handle = wglCreatePbufferARB(affDC, format, width, height, NULL);
     
          // pbufferAffDC will have the same affinity-mask as affDC.
          pBufferAffDC = wglGetPbufferDCARB(handle);
     
          // affRC will inherit the affinity-mask from pBufferAffDC.
          affRC = wglCreateContext(pBufferAffDC);
          wglMakeCurrent(pBufferAffDC, affRC);
     
          <Now draw into the pBuffer>
     
     
    Issues
     
     
          1) Do we really need an affinity-DC, or can we do with just an
          affinity context?
     
          DISCUSSION: If affinity is not part of a DC, a new function will
          need to be defined to create an affinity-context or set an
          affinity-mask for an existing context. Passing NULL as a HDC to
          wglMakeCurrent will then be one way to create an off-screen
          rendering context, where rendering will have to go to a FBO. If
          the HDC passed to wglMakeCurrent is one for a pBuffer, the
          affinity-mask in the affinity-context dictates where rendering is
          direct to. This might mean pBuffer resources will have to move, or
          alternatively, duplicated across all GPUs in a system. That is
          counter to the whole idea of this extension. Thus an affinity-DC
          is definitely needed for a pBuffer.
     
          Thus the question reduces to, do we need an affinity-DC in order
          to facilitate off-screen rendering to a FBO? Having an affinity-DC
          has the following advantages:
     
          a)  It is consistent with making current to a pBuffer or window,
          that does need a DC.
          b) passing NULL as a HDC to wglMakeCurrent might be filtered out
          by the MS layer on future OSes.
          c) The driver implementation might benefit from knowing at DC
          creation time what the affinity-mask is, rather than at
          wglMakeCurrent time.
     
          RESOLUTION: Yes.
     
          2) Should the GPU affinity concept also apply to D3D and/or GDI
          commands?
     
          DISCUSSION:  It could be especially desirable to apply the
          affinity concept to D3D. However, D3D is sufficiently different
          that this extension doesn't directly apply.
     
          RESOLUTION: That falls outside this extension.
     
          3) Should setting a pixelformat on an affinity-DC be required?
     
          DISCUSSION: Setting a pixelformat on an affinity-DC is not
          strictly necessary if the application does off-screen rendering to
          a FBO. However, the Microsoft layer of wglMakeCurrent requires
          that the pixelformats of the DC and RC passed to it match. This
          becomes an issue when making an affinity-context current to a DC
          obtained from a window. The DC has a pixelformat set by the
          application, and therefore the affinity-context needs to have the
          same pixelformat. This means the affinity-DC, that the affinity-
          context is created from, needs to have the same pixelformat set.
     
          RESOLUTION: YES. Setting a pixelformat on an affinity-DC is
          required.
     
          4) Is it allowed to make an affinity-context current to an
          affinity-DC where the mask of the context spans more GPUs than the
          mask in the DC?
     
          5) Is it allowed to make an affinity-context current to an
          affinity-DC where the mask of the context spans less GPUs than the
          mask in the DC?
     
          DISCUSSION: Issues 4 and 5 are lumped together in this discussion.
          For example, is this scenario something we want to support: An
          application wants to share objects across two contexts and have
          these two contexts each render to a different GPU. It can do this
          by creating two affinity-DCs. One has an affinity mask for the
          first GPU, the other for the second GPU. It also creates two
          affinity-contexts that both have an affinity-mask that spans both
          GPUs. Making one context current to the first affinity-DC will
          lock the context to the GPU in the mask of that affinity-DC. Make
          another context current to the second affinity-DC will lock that
          context to the second GPU. This is effectively what issue 4) is
          asking. . The simplest solution is to disallow these cases, and
          that is how the spec is currently written.
     
          RESOLUTION: NO, we will not allow this to keep the spec simple. If
          necessary, these restrictions can always be lifted later.
     
          6) What should an application do if the enum functions that return
          BOOL fail for another reason than they are done? For example, if
          they fail because they run out of memory?
     
          RESOLUTION: An application will have to call GetLastError to find
          out the reason of failure.
     
          7) The "Enum" API commands in this extension assume that the list
          of things being enumerated does not change dynamically. Is that
          reasonable?
     
          DISCUSSION: Display devices, and possibly GPUs in the future, can
          be changed dynamically and/or hotplugged. Thus yes, this is a
          potential issue. Existing OS functionality like EnumDisplayDevices
          and even wglMakeCurrent will suffer from this too. In the latter
          case, the application could make a context current to a device
          that was removed from the system. A possible solution would be
          some sort of notification mechanism to the application. Possibly
          combined with being able to snapshot state first, then enumerate
          that snapshot. That snapshot of state might immediately become
          invalid, but at least the enumeration will walk a consistent list.
     
          RESOLUTION: This is a wider issue than just this specification,
          and not currently addressed.
     
          8) How do I transfer data efficiently between two affinity-
          contexts?
     
          DISCUSSION: It is desired for an application to render in one
          context, and transfer the result of that rendering to another
          context. These two contexts can be on different GPUs. If they are,
          how does the application efficiently transfer this data? Currently
          OpenGL provides two mechanisms, neither of which are ideal:
     
          1) The application can do a ReadPixels followed by a DrawPixels /
          TexImage call. This involves transfer through host memory, which
          can be slow.
     
          2) The application can share objects among the two contexts using
          wglShareLists(). This will work, but is counter to the premise of
          this extension where each GPU has its own set of resources, not
          shared with another GPU.
     
          RESOLUTION: This is a hole which needs to be addressed separately.
     
     
    Revision history
     
     
          4/6/2006 version 9 - first public release
          10/8/2006 version 10 - Changed WCHAR fields into GPU_DEVICE
          structure to CHAR fields. The implementation has always treated
          them as CHAR.
    Last edited by Dark Photon; 05-29-2013 at 04:26 AM.

  2. #2
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    You do not need to quote an entire extension specification to us. Even though you can't post a link yet, we do know how to use Google to find stuff.

    As to the substance of your question:

    I use OGRE and I put example2 (from the below doc.) to the source of OGRE.

    My question is how to link the affinityRenderingContext and the already defined windowRenderingContext?
    You don't. The whole point of creating rendering contexts that are GPU-specific is to not have to have inter-GPU communication. That you can have two independent GPUs operating, both doing their own stuff, without having to talk to one another directly. So one GPU does physics computations or whatever, and the other GPU does drawing. Or whatever division of labor you like.

    Affinity RCs can't directly talk to non-affinity RCs or affinity RCs for different GPUs.

    If you just want to render with one GPU to the screen, that's easy; don't create another RC to begin with. A little known fact about rendering contexts: you can use them with any device context (with one caveat), not just the one you created for that rendering context. The aforementioned caveat is that the new device context must use the same pixel format as the one the RC was created with.

    So do that. You create your affinity HDC. Assign it a pixel format. Then you create a rendering context from that. After that, you create your visible window and get it's HDC. Assign that HDC the same pixel format you use for your affinity HDC.

    And you're done.

    But you can't use an arbitrarily created RC with an affinity RC. Not without a CPU round-trip.

  3. #3
    Newbie Newbie
    Join Date
    May 2013
    Posts
    2
    Dear Alfonse,

    Thank you for your guide, now it works.

    Best Regards,
    Peter Kovacs

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •