[PATCH 2/4] winevulkan: Replace temp heap_allocs with alloca

[Liam Middlebrook]

On 3/5/20 12:25 PM, Andrew Wesie wrote:
> On Thu, Mar 5, 2020 at 11:03 AM Joshua Ashton <joshua at froggi.es> wrote:
>>
>> This allocates these structs and arrays of structures on the stack instead of the heap (which is expensive and takes time!)
>>
>> These structures and arrays of structures are small, and this is all super duper hot path code.
>>
> 
> Would it make sense to keep the heap allocation as a slow-path if the
> assumption about the allocation size is wrong? For example, if count
> is less than 32 use alloca(), otherwise use the heap to avoid a stack
> overflow.
> 

Agreed, I think this is a case where it would be good to get some performance 
numbers to help tune our expectations for what the high-mark for would be for normal 
size/usage.

For the wine_vkCmdExecuteCommands() implementation I'm not too concerned with any 
limit over 64-bytes (which I would consider small for some of the other structures 
I'll list below), since according to pahole(1) VkCommandBuffer_T takes up 20-bytes, 
and off-memory I've never seen a single call to vkCmdExecuteCommands supply a count 
of more than three command buffers.


Here's a list of the different _host conversion structs and their respective sizes:

> VkMemoryHeap_host                                     12
> VkBufferDeviceAddressInfoKHR_host                     16
> VkBufferMemoryRequirementsInfo2_host                  16
> VkCommandBufferBeginInfo_host                         16
> VkDeviceMemoryOpaqueCaptureAddressInfoKHR_host        16
> VkImageMemoryRequirementsInfo2_host                   16
> VkImageSparseMemoryRequirementsInfo2_host             16
> VkPerformanceMarkerInfoINTEL_host                     16
> VkPipelineInfoKHR_host                                16
> VkSparseBufferMemoryBindInfo_host                     16
> VkSparseImageMemoryBindInfo_host                      16
> VkSparseImageOpaqueMemoryBindInfo_host                16
> VkAccelerationStructureMemoryRequirementsInfoNV_host  20
> VkAcquireProfilingLockInfoKHR_host                    20
> VkDescriptorImageInfo_host                            20
> VkMemoryAllocateInfo_host                             20
> VkMemoryRequirements_host                             20
> VkPipelineExecutableInfoKHR_host                      20
> VkBufferCopy_host                                     24
> VkCommandBufferAllocateInfo_host                      24
> VkDescriptorBufferInfo_host                           24
> VkDescriptorSetAllocateInfo_host                      24
> VkPerformanceOverrideInfoINTEL_host                   24
> VkSemaphoreSignalInfoKHR_host                         24
> VkAccelerationStructureInfoNV_host                    28
> VkConditionalRenderingBeginInfoEXT_host               28
> VkMemoryRequirements2_host                            28
> VkMemoryRequirements2KHR_host                         28
> VkBindBufferMemoryInfo_host                           32
> VkBindImageMemoryInfo_host                            32
> VkGeometryAABBNV_host                                 32
> VkImageFormatProperties_host                          32
> VkMappedMemoryRange_host                              32
> VkPipelineShaderStageCreateInfo_host                  32
> VkBufferCreateInfo_host                               36
> VkSparseMemoryBind_host                               36
> VkBindAccelerationStructureMemoryInfoNV_host          40
> VkBufferViewCreateInfo_host                           40
> VkCommandBufferInheritanceInfo_host                   40
> VkFramebufferCreateInfo_host                          40
> VkImageFormatProperties2_host                         40
> VkSubresourceLayout_host                              40
> VkAccelerationStructureCreateInfoNV_host              44
> VkAcquireNextImageInfoKHR_host                        44
> VkCopyDescriptorSet_host                              44
> VkWriteDescriptorSet_host                             44
> VkBindSparseInfo_host                                 48
> VkBufferMemoryBarrier_host                            48
> VkDescriptorUpdateTemplateCreateInfo_host             48
> VkRenderPassBeginInfo_host                            48
> VkRayTracingPipelineCreateInfoNV_host                 52
> VkBufferImageCopy_host                                56
> VkSparseImageMemoryBind_host                          56
> VkImageMemoryBarrier_host                             60
> VkComputePipelineCreateInfo_host                      64
> VkImageViewCreateInfo_host                            64
> VkGeometryTrianglesNV_host                            80
> VkSwapchainCreateInfoKHR_host                         84
> VkGraphicsPipelineCreateInfo_host                     88
> VkGeometryDataNV_host                                 112
> VkGeometryNV_host                                     128
> VkPhysicalDeviceMemoryProperties_host                 456
> VkPhysicalDeviceMemoryProperties2_host                464
> VkPhysicalDeviceLimits_host                           488
> VkPhysicalDeviceProperties_host                       800
> VkPhysicalDeviceProperties2_host                      808

My only concern here would be with the VkPhysicalDevice* structures, namely 
VkPhysicalDeviceMemoryProperties2_host since it's usage in VK_EXT_memory_budget 
gives it the potential to be used in a hot-path (or at the very least lukewarm-path) 
for an application.

How about setting the threshold that Andrew is suggesting to 4k bytes and seeing if 
that strikes the right balance of perf/safety?


Thanks,

Liam Middlebrook

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------