search

KhronosGroup / OpenGL-Registry

OpenGL, OpenGL ES, and OpenGL ES-SC API and Extension Registry
678 stars 274 forks source link

Clarification at EXT_external_objects_win32 #575

Closed pabloko closed 1 year ago

pabloko commented 1 year ago

Hello, while implementing EXT_external_objects_win32 had a lot of confusion while using ImportMemoryWin32HandleEXT or ImportMemoryWin32NameEXT with <type> HANDLE_TYPE_D3D11_IMAGE_EXT or HANDLE_TYPE_D3D11_IMAGE_KMT_EXT about the <size> field.

Since no api exists to query D3D11 resource physical size and it varies from vendor and version of the implementation, I think the spec should be more clear about <size> and state more clearly if this value should be 0 for D3D11 resources, since this option seems to work. Also it could state that sizes bigger than physical size, even if accepted by the implementation, can cause undefined behaviour.

I published a gist with more detailed insight of my findings Regards

pdaniell-nv commented 1 year ago

Thanks for bringing up this issue. We are discussing internally and will respond soon.

pdaniell-nv commented 1 year ago

I think we need to update the GL_EXT_external_objects_win32 to have language similar to Vulkan for these handle types:

If the parameters define an import operation and the external handle type is VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D11_TEXTURE_BIT, VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D11_TEXTURE_KMT_BIT, or VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D12_RESOURCE_BIT, allocationSize is ignored. The implementation must query the size of these allocations from the OS.

Then I think implementations need to update their driver to ignore the \<size> parameter for these handle types and not require the application to use zero. I think you can use zero as a workaround in the meantime.

pabloko commented 1 year ago

Thanks for your reply, yes, something like this would solve the confusion.

In the meantime, I tested the workaround on different test machines with nvidia, amd and intel graphics cards and seems to work as intended.

Ignoring the value at driver level would be positive since in my tests exceeding the physical size lead to system wide texture corruption. Its an easy mistake to make since the only question in stackoverflow about this extension is answered to just overallocate so the call succeed.