search for: virtgpu_cmd_resource_create_2d

...file mode 100644 index 0000000..461f452 --- /dev/null +++ b/include/hw/virtio/virtgpu_hw.h @@ -0,0 +1,158 @@ +#ifndef VIRTGPU_HW_H +#define VIRTGPU_HW_H + +enum virtgpu_ctrl_type { + VIRTGPU_UNDEFINED = 0, + + /* 2d commands */ + VIRTGPU_CMD_GET_DISPLAY_INFO = 0x0100, + VIRTGPU_CMD_RESOURCE_CREATE_2D, + VIRTGPU_CMD_RESOURCE_UNREF, + VIRTGPU_CMD_SET_SCANOUT, + VIRTGPU_CMD_RESOURCE_FLUSH, + VIRTGPU_CMD_TRANSFER_TO_HOST_2D, + VIRTGPU_CMD_RESOURCE_ATTACH_BACKING, + VIRTGPU_CMD_RESOURCE_INVAL_BACKING, + + /* cursor commands */ + VIRTGPU_CMD_UPD...

Hi folks, Lets kick off the virtio-gpu review process, starting with the virtio protocol. This is a tiny patch series for qemu. Patch #1 carries the header file describing the virtual hardware: config space, command structs being sent over the rings, defines etc. Patch #2 adds a text file describing virtio-gpu to docs/specs/. It covers 2D support only for now. For anybody who wants to dig a

Hi folks, Lets kick off the virtio-gpu review process, starting with the virtio protocol. This is a tiny patch series for qemu. Patch #1 carries the header file describing the virtual hardware: config space, command structs being sent over the rings, defines etc. Patch #2 adds a text file describing virtio-gpu to docs/specs/. It covers 2D support only for now. For anybody who wants to dig a

...sources are initially simple 2D resources, consisting of a width, +height and format along with an identifier. The guest must then attach +backing store to the resources in order for DMA transfers to +work. This is like a GART in a real GPU. + +A typical guest user would create a 2D resource using +VIRTGPU_CMD_RESOURCE_CREATE_2D, attach backing store using +VIRTGPU_CMD_RESOURCE_ATTACH_BACKING, then attach the resource to a +scanout using VIRTGPU_CMD_SET_SCANOUT, then use +VIRTGPU_CMD_TRANSFER_SEND_2D to send updates to the resource, and +finally VIRTGPU_CMD_RESOURCE_FLUSH to flush the scanout buffers to +screen. + + +contr...

...the concept of resources private to the > +host, the guest must DMA transfer into these resources. This is a > +design requirement in order to interface with future 3D rendering. In > +the unaccelerated there is no support for DMA transfers from "the unaccelerated case"? > +VIRTGPU_CMD_RESOURCE_CREATE_2D: > + Command: struct virtgpu_resource_create_2d > + > + Create a 2D resource on the host. > + > + This creates a 2D resource on the host with the specified width, > + height and format. Only a small subset of formats are support. The > + resource ids are generated by the g...

...the concept of resources private to the > +host, the guest must DMA transfer into these resources. This is a > +design requirement in order to interface with future 3D rendering. In > +the unaccelerated there is no support for DMA transfers from "the unaccelerated case"? > +VIRTGPU_CMD_RESOURCE_CREATE_2D: > + Command: struct virtgpu_resource_create_2d > + > + Create a 2D resource on the host. > + > + This creates a 2D resource on the host with the specified width, > + height and format. Only a small subset of formats are support. The > + resource ids are generated by the g...

...eone else > could write a compatible implementation. Ok. The short-term goal for this text is to help reviewing the code by documenting how the device is supposed to work. Being good enough for an independent implementation is the next level. I'll keep it on the radar though. > > +VIRTGPU_CMD_RESOURCE_CREATE_2D: > > + Command: struct virtgpu_resource_create_2d > > + > > + Create a 2D resource on the host. > > + > > + This creates a 2D resource on the host with the specified width, > > + height and format. Only a small subset of formats are support. The > > +...