zvookin
commented
8 years ago I'd like to avoid extending Halide's buffer_t API for this as I feel all the extra information is fairly specific to the backend GPU API/language being used. There are some concepts which could be abstracted and shared between the different GPU realms, but it seems more productive for developers to access the features specific to one GPU API using the names and concepts of that API. Thus for access outside of Halide, I'd prefer people to use the wrap/unwrap mechanism and to make allocations and access the texture information using the (e.g.) OpenCL API to do so.
For textures managed entirely internally by Halide, the allocation can be done using a direct call into the GPU API specific runtime. This is entirely between the Halide CodeGenDev* backend for that GPU API and its runtime code so we do not need to agree on a specific way to pass the extra information.
The one place Halide will need to surface such things is in storage scheduling directives. We will also of course need a way to carry the information internally in the IR. I'd like to drive the providing of scheduling directives for this from use cases as opposed to proactively designing for covering many possibilities. It feels like there is a fair bit of potential to add a lot of complexity and I'd only want to do that if there is a lot of performance to be gained. (Some of the more interesting possibilities are things like computing to and from vertex buffers and such, rather than just managing texture layouts.)
On Mon, Mar 7, 2016 at 10:43 AM, Brian Leibig notifications@github.com wrote:
Right now, the OpenCL + Textures runtime (in the gpu_texture_api_variants branch) uses potentially inaccurate values for image formats and image descriptors when allocating images on the CL device. For instance, for the channel type it uses the respective unsigned int type for the elem_size. This can improve with the better type information in the new halide_buffer_t, but it still won’t be enough information to specify the full range of OpenCL channel types. Specifically, when we have sampling (
1021 https://github.com/halide/Halide/issues/1021), we will want to
use the CL_SNORM_x/CL_UNORM_x channel types for the images when doing linear filtering.
The runtime is also using CL_R as the channel order, which means read_image and write_image calls will only load and store one pixel at a time. If the image is in packed RGBA format with the color dimension vectorized, the runtime should be able to set the channel order to CL_RGBA with the code generator utilizing read_image/write_image calls that read and store 4 values at a time. But the runtime does not have enough information to know if it’s safe to create an image with CL_RGBA channel order instead of a CL_R. Theoretically other channel orders like CL_RG and CL_RGB could be supported for channel dimension extents of 2 or 3.
The general issue is that the compiler needs to somehow communicate with the runtime this extra info on how to create images in halide_opencl_textures_device_malloc. Possible solutions could be to have this data be part of the new halide_buffer_t, or passed in as an extra parameter to halide_device_malloc.
This issue has broader implications than just the OpenCL runtime in that it can probably help other GPU runtimes such as OpenGL as well (see #118 https://github.com/halide/Halide/issues/118, #371 https://github.com/halide/Halide/issues/371, #801 https://github.com/halide/Halide/issues/801).
— Reply to this email directly or view it on GitHub https://github.com/halide/Halide/issues/1059.
bleibig
Right now, the OpenCL + Textures runtime (in the gpu_texture_api_variants branch) uses potentially inaccurate values for image formats and image descriptors when allocating images on the CL device. For instance, for the channel type it uses the respective unsigned int type for the elem_size. This can improve with the better type information in the new halide_buffer_t, but it still won’t be enough information to specify the full range of OpenCL channel types. Specifically, when we have sampling (#1021), we will want to use the CL_SNORM_x/CL_UNORM_x channel types for the images when doing linear filtering.
The runtime is also using CL_R as the channel order, which means read_image and write_image calls will only load and store one pixel at a time. If the image is in packed RGBA format with the color dimension vectorized, the runtime should be able to set the channel order to CL_RGBA with the code generator utilizing read_image/write_image calls that read and store 4 values at a time. But the runtime does not have enough information to know if it’s safe to create an image with CL_RGBA channel order instead of a CL_R. Theoretically other channel orders like CL_RG and CL_RGB could be supported for channel dimension extents of 2 or 3.
The general issue is that the compiler needs to somehow communicate with the runtime this extra info on how to create images in halide_opencl_textures_device_malloc. Possible solutions could be to have this data be part of the new halide_buffer_t, or passed in as an extra parameter to halide_device_malloc.
This issue has broader implications than just the OpenCL runtime in that it can probably help other GPU runtimes such as OpenGL as well (see #118, #371, #801).