OpenGL & Vulkan

[jherico]

I've been trying to work with a piece of example code that demonstrates Vulkan / OpenGL interoperability using `GL_EXT_external_objects` on the OpenGL side and VK_KHR_external_memory_win32 on the Vulkan side.  This works on my GeForce 1070, but testing it on my RX 580 it failed to produce the desired results.  After some experimentation, debugging and closer examination of the spec I realized that I was glossing over some key elements, like checking the supported tiling modes on the OpenGL side.

However, when I tried to do this I discovered that even though the RX 580 advertises GL_EXT_memory_object and GL_EXT_semaphore, it actually fails to fully implement them.  For instance, the GetUnsignedBytevEXT function isn't found by my GL loader.  Additionally, the following code generates errors on both calls to glGetIntervalformativ, reporting an invalid enum (presumably the tiling type enums added by the extension).

GLint numTilingTypes;

glGetInternalformativ(GL_TEXTURE_2D, GL_RGBA8, GL_NUM_TILING_TYPES_EXT, 1, &numTilingTypes);

std::vector<GLint> tilingTypes;

tilingTypes.resize(numTilingTypes);

glGetInternalformativ(GL_TEXTURE_2D, GL_RGBA8, GL_TILING_TYPES_EXT, numTilingTypes, tilingTypes.data());

Is the extension supposed to be considered functional?  If so, where are the missing functions and why don't these calls work?  If not, why is it advertised in the extensions list?

OS: Windows 10 64 bit

Driver: Radeon 18.9.1

[xhuang]

Hello,

Yeah, the implementation for EXT_external_objects has been done recently, and will be included in the coming release soon. I can help to run on my box if you can provide your application and let you know the result immediately. Thank you for your reporting and apologize for the inconsistency of the support for new extension.

[jherico]

The file is here:   Vulkan/glinterop.cpp at gl_test2 · jherico/Vulkan · GitHub

https://github.com/jherico/Vulkan/blob/gl_test2/examples/glinterop/glinterop.cpp

[xhuang]

Hello,

The glinterop build fails as below. It'll be efficient if you can update the *.cpp.

[jherico]

It successfully compiles on Visual Studio 15.8.3, using the Vulkan 1.1.82.1 SDK and with the project set to C++14 compatibility.  However, I've made a change to the C++ file that may resolve the ambiguity that seems to be preventing you from compiling.

My CMake build is configured as cmake -G "Visual Studio 15 Win64"

[xhuang]

Yes, it's working now after i upgrade my SDK to the latest version. I was using 1.1.70.1. I got something as follows, the following calls are still have problems. I've pinged the engineer who develops this feature, and he is going to fix it soon. Will get you back. Thanks.

• glGetInternalformativ(GL_TEXTURE_2D, GL_RGBA8, GL_NUM_TILING_TYPES_EXT, 1, &numTilingTypes);
• glGetInternalformativ(GL_TEXTURE_2D, GL_RGBA8, GL_TILING_TYPES_EXT, numTilingTypes, tilingTypes.data());

[jherico]

I'm also able to get it to work, sometimes, if I force a linear texture.  However, there's some additional code that I haven't been able to add and test.  In theory I should be able to fetch UUIDs out of the GL context using glGet with GL_NUM_DEVICE_UUIDS_EXT and then glGetUnsignedBytevEXT/glGetUnsignedByteiEXT along with GL_DEVICE_UUID_EXT and GL_DRIVER_UUID_EXT.  Unfortunately the loader returns null for glGetUnsignedBytevEXT and glGetUnsignedByteiEXT, so I can't test this. 

[xhuang]

Current driver does not contains the implementation for glGetUnsignedBytevEXT/glGetUnsignedByteiEXT, definitely it will be in the next driver release. The only thing i'm not 100% is the last fix for glGetInternalformativ along with GL_DEVICE_UUID_EXT and GL_DRIVER_UUID_EXT will be in the next release, as there's quite long testing cycle for us to validate a driver release. Will keep you update. Apologies again.

[jherico]

I also wanted to mention I'm seeing artifacts on the rendered image, even when everything else is working properly.  Specifically, usually only the first couple lines of the texture make it back to Vulkan... so I see a mostly black image in the texture with just the first two lines showing the animated pattern.  The number of lines varies depending on the dimensions of the texture... so if I change it to 256x256 I see more lines.  That's with the current code in the repo and the hardware as mentioned above. 

If I initially populate the texture with a color, like red, the color does show up in the output wherever the GL code has failed to write.  Additionally, if I modify the code on the GL side to use the imported texture as the FBO attachment and set the GL window as visible, I see the same pattern on the GL window as I do in the Vulkan one, i.e. only the first few lines are properly rendered.  I'll post a screenshot when I have access to the machine again, which likely won't be till tomorrow afternoon or Friday. 

[jherico]

This is an example of what I'm seeing on my AMD system when I run it locally.

The 2 GL errors are from the calls to

        glTextureParameteri(texture, GL_TEXTURE_TILING_EXT, glTiling);

and

        glGetInternalformativ(GL_TEXTURE_2D, GL_RGBA8, GL_NUM_TILING_TYPES_EXT, 1, &numTilingTypes);

This was produced from the code with commit ID e837cc0c

Note that the current implementation is rendering to a pure GL FBO, then use glCopyImageSubData to copy to the shared image, then blit from the FBO color attachment to the default framebuffer.  Hence the GL window on the left is correct.

If I change the code so that the shared image is directly used as the FBO color target, the GL window on the left matches whats in the Vulkan window... only the first few lines are rendered.  Also note, this effect does not happen every time...  sometimes when I start the application the Vulkan texture looks fine, but usually I see an effect like this.