Create Vulkan Image Class

[Zomon333]

This is a larger issue as it requires a lot of in depth information which can be relevant to shaders and 3D graphics, which we're not implementing yet. Consequently it has a lot of bloat that we can't really ignore, but we're not able to properly address either. We will definitely need to revisit and refactor the Image class numerous times during the development cycle.

Image Creation

• [ ] Figure out how to store layout and format information
  • [x] This will likely be stored in the VkImageCreateInfo struct as a VkFormat or a VkImageType.
• [ ] Create an image with
  • [ ] Requires image creation info VkImageCreateInfo
  • [x] sType = VK_STRUCTURE_TYPE_IMAGE_CREATE_INFO
  • [x] Flags need to be from VkImageCreateFlagBits and mostly determine if the image is a sparse image
  • [ ] Mutable format bit controls the ability to create views. Required later.
  • [x] imageType is the dimensionality of the image, for 1D, 2D, or 3D
  • [x] Format refers to how texel data gets stored in memory. There are many formats-- check the documentation.
  • [x] Extent: Image size in texels as a VkExtent3D struct containing width, height, depth.
    • [x] Vulkan uses explicit array size, instead of aliasing the next-higher dimension as an array count. This is set in arrayLayers.
  • [ ] Max image size is device dependent. This can be queried with vkGetPhysicalDeviceFeatures() for maxImageDimension{1/2/3}D fields in VkPhysicalDeviceLimits.
  • [ ] If the image is a cube map, then the maximum side length is in maxImageDimensionCube
  • [ ] 1D, 2D, and Cubes are guaranteed to have a maximum of at least 4096 texels.
  • [ ] maxImageArrayLayers is guaranteed to have at least 256 texels.
  • [ ] We'll also need to know the number of mipmap levels, in mipLevels.
  • [ ] Mipmapping is the process of using a set of prefiltered images of successively lower resolution in order to improve image quality when undersampling the image. (Mipmaps are smaller and prefiltered, allowing for different Levels of Detail for rendering depending on parameters like distance.)
  • [ ] The base texture is level 0 of the mipmap. Every subsequent level is half the resolution of the prior level. This can continue until the image is a 1x1 texel.
  • [ ] We'll also need to know the number of samples in an image; this must be a member of the VkSampleCoutnFlagBits enum.
  • [ ] We'll need to know the image's use cases;
  • [ ] Tiling modes, from the tiling field, need to be a VkImageTiling enum. Will be either...
    • [ ] Linear tiling where image data is laid out left to right top to bottom, or...
    • [ ] Optimal tiling, which is an opaque representation which greatly improves efficiency but is not (easily) mappable.
  • [ ] We'll also need usage bits from the VkImageUsageFlags enum
  • [ ] We'll need the sharing mode, which will either be EXCLUSIVE or CONCURRENT.
  • [ ] We'll need the queue family index count and queue family indices for when the sharing mode is concurrent.
  • [ ] We'll also need layout from the VkImageLayout enum. These can be changed during execution, and must be created as either undefined or preinitialized.
  • [ ] Changing layout requires use of a pipeline barrier, which is used in rendering pipelines to synchronize access across different rendering stages. They're discussed later in Chapter 4.

Memory Binding & Allocation

• [x] Allocation should be the same as with buffers.
  • [x] vkGetImageMemoryRequirements
  • [x] Takes a VkMemoryRequirements field which is already parsed by buffers. Reference this!
• [x] Binding occurs with vkBindImageMemory
• We'll eventually want to create sparse images. This will likely become a SparseImage class of it's own, but we're documenting the need for it here for later.

Image Destruction

• [x] An image can be destroyed with vkDestroyImage

Extra Details

Linear Images #35

Nonlinear Encoding #36

Compressed Image Formats #37

[Zomon333]

Additional reading

VkImageUsageFlags:

• VK_IMAGE_USAGE_TRANSFER_SRC_BIT: Image will be the source of transfer commands (C4: Moving Data)
• VK_IMAGE_USAGE_TRANSFER_DST_BIT: Image will be the destination of transfer commands (C4: Moving Data)
• VK_IMAGE_USAGE_SAMPLED_BIT: Image can be sampled from in a shader
• VK_IMAGE_USAGE_STORAGE_BIT: Image can be used for general purpose storage, like from a shader
• VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT: Image can be bound as a color attachment and drawn into, like for a frame buffer (C7: Graphics Pipelines)
• VK_IMAGE_USAGE_DEPTH_STENCIL_ATTACHMENT_BIT: Image can be bound as a depth / stencil and used for testing (C10: Fragment Processing)
• VK_IMAGE_USAGE_TRANSIENT_ATTACHMENT_BIT: Image can be used to store immediate results of a graphics operation (C13: Multipass Rendering)
• VK_IMAGE_USAGE_INPUT_ATTACHMENT_BIT: Image can be used as a special input during graphics rendering, but can only be read from fragment shaders at their own pixel location (C13: Multipass Rendering)

VkImageLayout:

• VK_IMAGE_LAYOUT_UNDEFINED: Image state is undefined and must be set to another state before it can be used
• VK_IMAGE_LAYOUT_GENERAL: The most vague use case for an image, can be used almost anywhere but isn't optimized
• VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL: Image is going to be rendered into from the graphics pipeline
• VK_IMAGE_LAYOUT_DEPTH_STENCIL_ATTACHMENT_OPTIMAL: Image is going to be used as a depth or stencil buffer
• VK_IMAGE_LAYOUT_DEPTH_STENCIL_READ_ONLY_OPTIMAL: Image is going to be used for depth testing but will not be written to. Can be read from shaders.
• VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL: Image will be bound for reading by shaders, but not writing. Used for textures.
• VK_IMAGE_LAYOUT_TRANSFER_SRC_OPTIMAL: Image is source of copy operations
• VK_IMAGE_LAYOUT_TRANSFER_DST_OPTIMAL: Image is destination of copy operations
• VK_IMAGE_LAYOUT_PREINITIALIZED: Image contains data placed there from an external actor, like from mapping
• VK_IMAGE_LAYOUT_PRESENT_SRC_KHR: Image is used as a source for presentation