Emulate exportable VkDeviceMemory for QnxScreenBuffer memory with server-side allocation#110
Conversation
|
@jmacnak any ideas on the failing end2end test compilation (missing |
It does look like a valid finding. I do not understand why it is only triggered in this PR though since it seems to be a pre-existing issue and this PR does not touch that file... If you can, just add a gfxstream/tests/end2end/BUILD.bazel Line 77 in 3b4da72 |
|
@jmacnak thank you1 That fixed it. Looking for reviews now 🙂 |
…rver-side allocation + import during ColorBuffer creation. ... And add platform_helper_qnx implementation; implements some helpers in the gfxstream::qnx namespace, etc.. This change allows QNX to defer the allocation to the gfxtream backend, and makes the externalMemory management more uniform across platforms, in terms of the way it is managed by the ColorBufferVk object lifetime.
generic memoryMode interface
ecd8cce to
033e1f5
Compare
|
@jmacnak will this merge automatically? I don't quite know what the |
|
Internal CI thingy. I think a googler has to trigger it so just spam "@jmacnak" whenever you need it. |
Is this fine? |


Note: There will be a subsequent change to remove ALL "creation with handle import" code. This effectively negates the requirement for that functionality, as QNX was previously doing the the "server" (QNX Screen) side allocation in the virtio-gpu frontend, and then creating the resource by importing the external handle. However, that was just leaving the vdev to guess when to create a resource this way. This should basically all be internal details of the backend renderer. This makes the frontend implementation AND the backend implementation much easier to understand, and keeps things most similar to other platforms (even ones that are doing typical export-from-Vulkan after allocation).