Constantine Shablia
07c6459cd8
Add buffer copy/fill/update helpers using compute shaders. The driver can select the optimal per-workgroup copy/fill/update size by specifying a non-zero vk_meta_device::buffer_access::optimal_size_per_wg size. If zero, the core will assume a 64-byte size (the usual cache-line size). Buffer accesses will be done through SSBOs unless vk_meta_device::buffer_access::use_global_address is true, in which case the core will the buffer address using GetBufferDeviceAddress() and pass that address as a push constant to the compute shader. Image to buffer copies are always done through a compute shader. The optimal workgroup size will be chosen based on vk_meta_copy_image_properties::tile_size: the copy logic picks a workgroup size matching the tile size, and aligns accesses on a tile. The view format is selected by the driver. To optimize things on the shader side, pick UINT formats (usually less work to do to pack data). Buffer to image copies can be done done through the graphics pipeline if needed (use_gfx_pipeline passed to vk_meta_copy_buffer_to_image()), which is useful for vendor-specific compressed formats that can't be written outside of the graphics pipeline. Drivers should normally prefer compute-based copies when that's an option. Just like for image to buffer copies, the workgroup size of compute shaders is picked based on the image tile size, and the view format must be selected by the driver. Image to image copies is just a mix of the above, with the driver being able to select the pipeline type, as well as define the tile size and view format to use. When using a compute pipeline, the workgroup size will be MAX2(src_tile_sz, dst_tile_sz), and accesses will be aligned on the selected reference image. For compressed formats, the caller should pick an RGBA format matching the compressed block size. Co-developed-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29333>
`Mesa <https://mesa3d.org>`_ - The 3D Graphics Library ====================================================== Source ------ This repository lives at https://gitlab.freedesktop.org/mesa/mesa. Other repositories are likely forks, and code found there is not supported. Build & install --------------- You can find more information in our documentation (`docs/install.rst <https://docs.mesa3d.org/install.html>`_), but the recommended way is to use Meson (`docs/meson.rst <https://docs.mesa3d.org/meson.html>`_): .. code-block:: sh $ meson setup build $ ninja -C build/ $ sudo ninja -C build/ install Support ------- Many Mesa devs hang on IRC; if you're not sure which channel is appropriate, you should ask your question on `OFTC's #dri-devel <irc://irc.oftc.net/dri-devel>`_, someone will redirect you if necessary. Remember that not everyone is in the same timezone as you, so it might take a while before someone qualified sees your question. To figure out who you're talking to, or which nick to ping for your question, check out `Who's Who on IRC <https://dri.freedesktop.org/wiki/WhosWho/>`_. The next best option is to ask your question in an email to the mailing lists: `mesa-dev\@lists.freedesktop.org <https://lists.freedesktop.org/mailman/listinfo/mesa-dev>`_ Bug reports ----------- If you think something isn't working properly, please file a bug report (`docs/bugs.rst <https://docs.mesa3d.org/bugs.html>`_). Contributing ------------ Contributions are welcome, and step-by-step instructions can be found in our documentation (`docs/submittingpatches.rst <https://docs.mesa3d.org/submittingpatches.html>`_). Note that Mesa uses gitlab for patches submission, review and discussions.