Octocontrabass wrote:
QEMU must be allocating its host buffers in the same format as the guest buffers.
The format only refers to the pixel format, not dimensions AFAICT (emphasis mine):
Virtual I/O Device (VIRTIO) Version 1.2 (Working Draft) wrote:
VIRTIO_GPU_CMD_RESOURCE_CREATE_2D ...
Code:
enum virtio_gpu_formats {
VIRTIO_GPU_FORMAT_B8G8R8A8_UNORM = 1,
VIRTIO_GPU_FORMAT_B8G8R8X8_UNORM = 2,
...
This creates a 2D resource on the host with the
specified width, height and format. ...
Octocontrabass wrote:
Since this command copies between two buffers of the same dimensions
I also thought the backing store had to have the same dimensions but the specification does not actually say this (emphasis mine):
Virtual I/O Device (VIRTIO) Version 1.2 (Working Draft) wrote:
5.7.6.1
Device Operation: Create a framebuffer and configure scanout
• Create a host resource using VIRTIO_GPU_CMD_RESOURCE_CREATE_2D.
• Allocate a framebuffer from guest ram, and attach it as backing storage to the resource just created, us-
ing VIRTIO_GPU_CMD_RESOURCE_ATTACH_BACKING. Scatter lists are supported, so the frame-
buffer doesn’t need to be contignous in guest physical memory.
• Use VIRTIO_GPU_CMD_SET_SCANOUT to link the framebuffer to a display scanout.
This does give the impression the backing store needs to match the dimensions of the host resource. However, it does not actually explicitly say that.
Also, if the dimensions are indeed expected to match I'd expect to find `src_offset = dst_offset;` instead of `src_offset = t2d.offset + stride * h`, since the latter means I always need to start drawing in the backing store from the top-left corner (0,0) instead of whatever X,Y coordinates the rectangle specifies. You also wouldn't need `t2d.offset` if the former was used.
In short, I do not see any reason to use a separate `src_offset` if the backing store's size is expected to match the host's resource size
(In hindsight, I could calculate the t2d.offset such that I can start drawing in the backing store from X,Y instead of 0,0, though that seems rather pointless to me compared to the device doing just that from the get-go).
Virtual I/O Device (VIRTIO) Version 1.2 (Working Draft) wrote:
VIRTIO_GPU_CMD_RESOURCE_ATTACH_BACKING
...
This assign an array of guest pages as the backing store for a resource. These pages are then used
for the transfer operations for that resource from that point on.
This does not explicitly mention the backing store needs to match the size of the host's resource either.
Virtual I/O Device (VIRTIO) Version 1.2 (Working Draft) wrote:
VIRTIO_GPU_CMD_TRANSFER_TO_HOST_2D
...
This takes a resource id along with an destination offset into the resource, and a box to transfer to the
host backing for the resource.
I interpret the last part as "the size of the backing store matches the area of the box (= rectangle, presumably)", given that an offset also needs to be specified explictly.
Virtual I/O Device (VIRTIO) Version 1.2 (Working Draft) wrote:
VIRTIO_GPU_CMD_SET_SCANOUT ...
This sets the scanout parameters for a single scanout. The resource_id is the resource to be scanned
out from, along with a rectangle.
Scanout rectangles must be completely covered by the underlying resource. ...
While this essentially says that the resource's size must be equal or larger than the size of the scanout it does not mention the backing store at all.