Skip to main content
Up and Coming
March 20, 2019

wglDXRegisterObjectNV returns 0 but no error ( NV_DX_interop2 )

Has anyone successfully added NV_DX_interop2 functionality to a PC Win10 OVR SDK app with NVIDIA GTX 1080 GPU?  Just to be clear, my goal is to be able to execute arbitrary GL code and have it
write to the DX eye render targets, with the proper wglDXLockObjectsNV()
and wglDXUnlockObjectsNV() surrounds.


The problem I am having is that when I call

gl_handles[0] = wglDXRegisterObjectNV(gl_handleD3D, dxColorbuffer,  gl_names[0], GL_RENDERBUFFER,  WGL_ACCESS_READ_WRITE_NV);

the handle is set to 0, but there is no error detected by GetLastError();  So, I have 2 renderbuffer objects, color and depth, that are derived from the OVR eye render targets/buffers.  The dxColorbuffer object appears correct, as does the dxDepthbuffer object.  The call succeeds on the dxDepthbuffer object and sets the handle to a non-null value.

I think I am doing all the required steps correctly, including:

gl_handleD3D = wglDXOpenDeviceNVFunc((void *)((OVR::Render::D3D11::RenderDevice*)pRender)->Device); 
glGenFramebuffers(2, gl_fbonames);
glGenRenderbuffers(2, gl_names);
gl_handles[0] = wglDXRegisterObjectNV(gl_handleD3D, dxColorbuffer, gl_names[0],   GL_RENDERBUFFER,      WGL_ACCESS_READ_WRITE_NV);

... subsequent calls such as glBindFramebuffer(), etc. are present but not shown.

Thanks.












    57 replies

    knchaffinAuthor
    Up and Coming
    April 19, 2019
    @thewhiteambit

    Copying to the CurRenderTarget also makes sense, just no RTV's.
    Inspiring
    April 19, 2019
    Can't tell, I haven't seen your whole project. I would hardly suggest to drop the Swapchains and Backbuffers (as long as you don't just mean the way you use them). Haven't used them since years, there is absolutely no need for IDXGISwapChain or alike - except you are running in a framework-environment were you can't change this. You can gain access to the (texture/surface-)resouces of the RTV.

    I just had a look, I have several DX-Devices with massive DXGI- and GL-interop etc. but not a single (IDXGI)SwapChain in my project, and it is huge!

    I would start fresh, and try to copy from a simple cleared Red texture to a cleared Blue texture with no other use in the project, just to see what's wrong with that CopyResource.
    Inspiring
    April 19, 2019
    Also you should have a look at the Misc-Flags of OVR textures created. I feel with you, have been in the OVR undocumentation hell for to long also. Only thing that helped me was days and weeks and weeks of trying just to find out some undocumented OVR oddity has been the problem all the time.
    Inspiring
    April 19, 2019
    Also you should flush you DX device context to be sure the commands have been processed
    knchaffinAuthor
    Up and Coming
    April 19, 2019
    @thewhiteambit

    Yeah, I'm sitting right at 2 months into the interop thing.  I did mess around with the MiscFlags this morning and don't think this is the source of the problem.  I set my DX texture to the same MiscFlags=2 that OVR uses, to no avail.
    I feel like I have missed the big picture.  In your interop code you created a DX color render texture (or perhaps one per eye) to register with the interop and GL, right?  After GL finished rendering to that texture, what did you do with it?  What was the destination texture in your CopySubresourceRegion() call?  Did you copy to device level texture such as BackBuffer or CurRenderTexture, or did you copy it to a higher level destination texture, such as perhaps associated with the eye rendertargets?

    Thanks, I appreciate the time you have given me on this.
    Inspiring
    April 19, 2019
    @knchaffin

    I have a GL texture with the desired picture.

    So I create a texture in DX and register for interop

    Then I copy the GL texture to the interop texture in GL (glBlitFramebuffer)

    Then I copy from the interop texture to the OVR texture in DX (CopySubresourceRegion).

    Technically no BackBuffer or SwapChain involved, except the intention of the OVR texture is the same as a SwapChain or BackBuffer.
    knchaffinAuthor
    Up and Coming
    April 19, 2019
    @thewhiteambit You said "Then I copy from the interop texture to the OVR texture in DX (CopySubresourceRegion).".  I'm sorry to be a pain, but this is at the heart of my confusion.  Which "OVR texture"?  I suspect it may be an OVR eye render texture, but I'm probably still confused.  If it is the eye render texture, that will be simple to test, once I modify my DX texture dimensions to match the eye render texture(s).  I'll be quite for a while then....  I promise!


    Inspiring
    April 19, 2019
    @knchaffin

    Yes it's the (or in my case one) Eye-Texture. For testing you might use any other layer-texture as well. I am not 100% sure, but CopySubresourceRegion should be capable of copying between textures of different sizes as long as you don't copy larger BOXes than source or destination texture.

    Feel free to ask further questions. I know this can be pain.
    knchaffinAuthor
    Up and Coming
    April 20, 2019
    @thewhiteambit

    Thanks for pointing me in the right direction, further up the render chain.  I'm sure this is the reason for my CopyResource() problems.  I need to change up my application significantly in order to do this correctly in a layer manner at the eyetexture level.  That will take me a little while, so I just wanted to say thanks now.
    knchaffinAuthor
    Up and Coming
    April 24, 2019
    @thewhiteambit

    Okay, progress!  I finally am able to use copyresource to the eye render textures and get a black eye:)  The problem was that my DX texture I created has desc.SampleDesc.Count = 1 whereas the eye render texture has desc.SampleDesc.Count = 4 due to MSAA being enabled.  After fixing this, the CreateTexture() failed since I was initializing from data for the checkerboard and MSAA textures cannot be initialized from data.  I set the data arg to NULL and the CreateTexture() succeeds, but thus I now have a black texture.

    Since  I expect there to be MSAA complications on the interop GL side render to the DX texture, I plan to turn off MSAA in the application.  Do you know how seriously that will impact render quality?  Or do you know if MSAA can be handled on the GL side?

    After days of CopyResource() seemingly doing nothing, having it produce a black eye image is progress!