Make setting a stride of the ImageView data possible #150
Conversation
There was a problem hiding this comment.
I'm glad to see you getting acquainted with the inner workings of LLGL :-) I started with a concept for rowStride and layerStride in this struct earlier of last year but never took the time to start on the implementation because I had no need for this feature so far.
I'm happy to help with the Metal backend, but we can add this a bit later. It would make sense to also add this field to MutableImageView at some point, but that's maybe something for another time.
| { | ||
| const FormatAttributes& formatAttribs = GetFormatAttribs(format); | ||
| if (formatAttribs.blockWidth > 0 && formatAttribs.blockHeight > 0) | ||
| { | ||
| outLayout.rowStride = (extent.width * formatAttribs.bitSize) / formatAttribs.blockWidth / 8; | ||
| outLayout.rowStride = ((srcDataStride > 0 ? srcDataStride : extent.width) * formatAttribs.bitSize) / formatAttribs.blockWidth / 8; |
There was a problem hiding this comment.
How should LLGL behave when the row stride is smaller than the width of the source image? Should this be undefined behavior or be defined as an invalid argument? Either way, it should be documented in the ImageView struct for this field. If we consider it an invalid argument we should probably also add max(srcDataStride, extent.width) here to clamp it to the largest value or add an assertion LLGL_ASSERT(srcDataStride == 0 || srcDataStride >= extent.width).
There was a problem hiding this comment.
I'm not sure why it is an issue. Isn't the extent there describes the size of the destination subresource? If so then it doesn't matter if the row stride is bigger or smaller than extent.width. Correct me if I'm wrong, please.
| @@ -477,7 +477,7 @@ void VKRenderSystem::WriteTexture(Texture& texture, const TextureRegion& texture | |||
| VK_BUFFER_USAGE_TRANSFER_SRC_BIT // <-- TODO: support read/write mapping //GetStagingVkBufferUsageFlags(bufferDesc.cpuAccessFlags) | |||
| ); | |||
|
|
|||
| VKDeviceBuffer stagingBuffer = CreateStagingBufferAndInitialize(stagingCreateInfo, imageData, imageDataSize); | |||
| VKDeviceBuffer stagingBuffer = CreateTextureStagingBufferAndInitialize(stagingCreateInfo, srcImageView, extent); | |||
There was a problem hiding this comment.
It looks like this change ignores imageData. This function must not use the input parameter directly in case the image format and data type had to be converted (see intermediateData). That's what all the code above is for. Oh, and the convert functions such as ConvertImageBuffer() will also have to handle the new stride. Yeah, this features goes wide I'm afraid 😬
There was a problem hiding this comment.
I fixed the ignoring of imageData, but I'm not sure about ConvertImageBuffer because I can't figure out how to take the stride into account in ConvertImageBufferFormatWorker
There was a problem hiding this comment.
I'll see to also update the image conversion functions over the weekend. The work distribution likely needs to be adjusted.
|
It was a quick and a low effort solution just to get it working, and also I was sleepy 😅. I just wanted to get your feedback on the idea and implementation.
Yeah, now I understand it a little better :). I wish I had more knowledge of graphics programming to help you with the bigger problems.
Yes, please help me if you have the time, I'm scared of Objective-C. If you don't have time I can try to do it myself. |
|
I'll take another look over the weekend since this is a bit more involved and I'll come up with a unit test for this feature. |
I was implementing the chunked lightmap rendering in my project.
The idea is that instead of one huge lightmap texture, I create multiple smaller ones and render them only if they are visible.
But I ran into a problem when I needed to update the lightmap on the intersection of multiple chunks.
Because I had to calculate proper offsets and size for each chunk's texture.
As the size of the texture of a chunk and the size of the lightmap buffer on CPU are different, I had to do the following:
It was quite slow to do all of that. I could have only the third step if there was an option to set custom stride for the source data of the image view.
But then I noticed that ID3D11DeviceContext::UpdateSubresource function has a parameter just for what I need, so I made this PR to expose that parameter in the public interface.