{"id":9565,"date":"2021-01-28T03:39:18","date_gmt":"2021-01-28T08:39:18","guid":{"rendered":"http:\/\/local.brightwhiz\/?p=9565"},"modified":"2021-01-28T03:39:18","modified_gmt":"2021-01-28T08:39:18","slug":"vulkan-1-2-168-release-available","status":"publish","type":"post","link":"http:\/\/local.brightwhiz\/vulkan-1-2-168-release-available\/","title":{"rendered":"Vulkan 1.2.168 Release With Two New Extensions Available"},"content":{"rendered":"\n
Vulkan 1.2.168 release specification introduces two new KHR extensions namely VK_KHR_workgroup_memory_explicit_layout<\/strong> and VK_KHR_zero_initialize_workgroup_memory<\/strong>.<\/p>\n\n\n\n VK_KHR_workgroup_memory_explicit_layout<\/strong>: This is a SPIR-V extension, which allows shaders to explicitly define the layout of code: Workgroup storage class memory and creates aliases between variables from that storage class in a compute shader.<\/p>\n\n\n\n The aliasing feature allows different “views” on the same data, so the shader can bulk copy data from another storage class using one type (e.g. an array of large vectors), and then use the data with a more specific type. It also enables reducing the amount of workgroup memory consumed by allowing the shader to alias data whose lifetimes don’t overlap.<\/p>\n\n\n\n The explicit layout support and some form of aliasing is also required for VK_KHR_zero_initialize_workgroup_memory<\/strong>: This extension allows the use of a null constant initializer on shader Workgroup memory variables, allowing implementations to expose any special hardware or instructions they may have. Zero initialization is commonly used by applications running untrusted content (e.g. web browsers) as a way of defeating memory-scraping attacks.<\/p>\n\n\n\n
layering OpenCL<\/a> on top of Vulkan<\/a>.<\/p>\n\n\n\n