* [Qemu-devel] virtio-gpu: cursor update not in sync with resource update
@ 2015-09-14 12:40 Marc-André Lureau
2015-09-14 14:06 ` Gerd Hoffmann
0 siblings, 1 reply; 7+ messages in thread
From: Marc-André Lureau @ 2015-09-14 12:40 UTC (permalink / raw)
To: QEMU, Gerd Hoffmann; +Cc: Dave Airlie
Hi
Afaik, the goal of the seperate cursor queue is to update cursor
quickly (probably to give good input responsiveness). However, the
VIRTIO_GPU_CMD_UPDATE_CURSOR references a surface that is uploaded via
the ctrl queue. The same resource id may be reused for cursor update.
But there is no synchronization between the two queues. So often, the
cursor set results in last update being shown. Should the kernel wait
for the update to finish? But then why having 2 different queues?
Should the update be done on the cursor queue instead? or should the
different cursor be cached (with different id) and qemu to do the
synchronization?
--
Marc-André Lureau
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Qemu-devel] virtio-gpu: cursor update not in sync with resource update
2015-09-14 12:40 [Qemu-devel] virtio-gpu: cursor update not in sync with resource update Marc-André Lureau
@ 2015-09-14 14:06 ` Gerd Hoffmann
2015-09-14 15:17 ` Marc-André Lureau
0 siblings, 1 reply; 7+ messages in thread
From: Gerd Hoffmann @ 2015-09-14 14:06 UTC (permalink / raw)
To: Marc-André Lureau; +Cc: Dave Airlie, QEMU
Hi,
> Afaik, the goal of the seperate cursor queue is to update cursor
> quickly (probably to give good input responsiveness). However, the
> VIRTIO_GPU_CMD_UPDATE_CURSOR references a surface that is uploaded via
> the ctrl queue. The same resource id may be reused for cursor update.
> But there is no synchronization between the two queues. So often, the
> cursor set results in last update being shown. Should the kernel wait
> for the update to finish?
Yes (for new cursors).
> But then why having 2 different queues?
> Should the update be done on the cursor queue instead? or should the
> different cursor be cached (with different id) and qemu to do the
> synchronization?
The guest can upload different cursors and then switch between them
without re-uploading and therefore without ctrl queue updates. Thats
why they have an id in the first place ...
cheers,
Gerd
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Qemu-devel] virtio-gpu: cursor update not in sync with resource update
2015-09-14 14:06 ` Gerd Hoffmann
@ 2015-09-14 15:17 ` Marc-André Lureau
2015-09-14 21:08 ` Dave Airlie
0 siblings, 1 reply; 7+ messages in thread
From: Marc-André Lureau @ 2015-09-14 15:17 UTC (permalink / raw)
To: Gerd Hoffmann; +Cc: Dave Airlie, QEMU
Hi
On Mon, Sep 14, 2015 at 4:06 PM, Gerd Hoffmann <kraxel@redhat.com> wrote:
> The guest can upload different cursors and then switch between them
> without re-uploading and therefore without ctrl queue updates. Thats
> why they have an id in the first place ...
Ok, but the cursor id is reused most of the time. So there are at
least two things to fix: use different cursor ids for different cursor
data (with some cache management probably), fix kernel to only upload
new resource id and wait for data to be transfered. Is that correct?
--
Marc-André Lureau
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Qemu-devel] virtio-gpu: cursor update not in sync with resource update
2015-09-14 15:17 ` Marc-André Lureau
@ 2015-09-14 21:08 ` Dave Airlie
2015-09-14 21:14 ` Marc-André Lureau
0 siblings, 1 reply; 7+ messages in thread
From: Dave Airlie @ 2015-09-14 21:08 UTC (permalink / raw)
To: Marc-André Lureau; +Cc: Gerd Hoffmann, QEMU
On 15 September 2015 at 01:17, Marc-André Lureau
<marcandre.lureau@gmail.com> wrote:
> Hi
>
> On Mon, Sep 14, 2015 at 4:06 PM, Gerd Hoffmann <kraxel@redhat.com> wrote:
>> The guest can upload different cursors and then switch between them
>> without re-uploading and therefore without ctrl queue updates. Thats
>> why they have an id in the first place ...
>
> Ok, but the cursor id is reused most of the time. So there are at
> least two things to fix: use different cursor ids for different cursor
> data (with some cache management probably), fix kernel to only upload
> new resource id and wait for data to be transfered. Is that correct?
Currently the kernel driver does this:
ret = virtio_gpu_cmd_transfer_to_host_2d(vgdev, qobj->hw_res_handle, 0,
cpu_to_le32(64),
cpu_to_le32(64),
0, 0, &fence);
if (!ret) {
reservation_object_add_excl_fence(qobj->tbo.resv,
&fence->f);
virtio_gpu_object_wait(qobj, false);
}
before moving the cursor, shouldn't that suffice?
Do we fail the transfer sometimes?
Dave.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Qemu-devel] virtio-gpu: cursor update not in sync with resource update
2015-09-14 21:08 ` Dave Airlie
@ 2015-09-14 21:14 ` Marc-André Lureau
2015-09-14 21:18 ` Dave Airlie
0 siblings, 1 reply; 7+ messages in thread
From: Marc-André Lureau @ 2015-09-14 21:14 UTC (permalink / raw)
To: Dave Airlie; +Cc: Gerd Hoffmann, QEMU
Hi
On Mon, Sep 14, 2015 at 11:08 PM, Dave Airlie <airlied@gmail.com> wrote:
> Currently the kernel driver does this:
>
> ret = virtio_gpu_cmd_transfer_to_host_2d(vgdev, qobj->hw_res_handle, 0,
> cpu_to_le32(64),
> cpu_to_le32(64),
> 0, 0, &fence);
> if (!ret) {
> reservation_object_add_excl_fence(qobj->tbo.resv,
> &fence->f);
> virtio_gpu_object_wait(qobj, false);
> }
>
> before moving the cursor, shouldn't that suffice?
>
> Do we fail the transfer sometimes?
That's apparently not in Gerd tree.
--
Marc-André Lureau
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Qemu-devel] virtio-gpu: cursor update not in sync with resource update
2015-09-14 21:14 ` Marc-André Lureau
@ 2015-09-14 21:18 ` Dave Airlie
2015-09-15 6:20 ` Gerd Hoffmann
0 siblings, 1 reply; 7+ messages in thread
From: Dave Airlie @ 2015-09-14 21:18 UTC (permalink / raw)
To: Marc-André Lureau; +Cc: Gerd Hoffmann, QEMU
On 15 September 2015 at 07:14, Marc-André Lureau
<marcandre.lureau@gmail.com> wrote:
> Hi
>
> On Mon, Sep 14, 2015 at 11:08 PM, Dave Airlie <airlied@gmail.com> wrote:
>> Currently the kernel driver does this:
>>
>> ret = virtio_gpu_cmd_transfer_to_host_2d(vgdev, qobj->hw_res_handle, 0,
>> cpu_to_le32(64),
>> cpu_to_le32(64),
>> 0, 0, &fence);
>> if (!ret) {
>> reservation_object_add_excl_fence(qobj->tbo.resv,
>> &fence->f);
>> virtio_gpu_object_wait(qobj, false);
>> }
>>
>> before moving the cursor, shouldn't that suffice?
>>
>> Do we fail the transfer sometimes?
>
>
> That's apparently not in Gerd tree.
Interesting, I'm not sure where this got lost,
I had it in my clone of Gerd's tree from a while back.
Dave.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Qemu-devel] virtio-gpu: cursor update not in sync with resource update
2015-09-14 21:18 ` Dave Airlie
@ 2015-09-15 6:20 ` Gerd Hoffmann
0 siblings, 0 replies; 7+ messages in thread
From: Gerd Hoffmann @ 2015-09-15 6:20 UTC (permalink / raw)
To: Dave Airlie; +Cc: Marc-André Lureau, QEMU
Hi,
> >> if (!ret) {
> >> reservation_object_add_excl_fence(qobj->tbo.resv,
> >> &fence->f);
> >> virtio_gpu_object_wait(qobj, false);
> >> }
> >>
> >> before moving the cursor, shouldn't that suffice?
> >>
> >> Do we fail the transfer sometimes?
> >
> >
> > That's apparently not in Gerd tree.
>
> Interesting, I'm not sure where this got lost,
Probably fallen through the cracks with the recent fence fixups.
I've added it back.
cheers,
Gerd
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2015-09-15 6:20 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-09-14 12:40 [Qemu-devel] virtio-gpu: cursor update not in sync with resource update Marc-André Lureau
2015-09-14 14:06 ` Gerd Hoffmann
2015-09-14 15:17 ` Marc-André Lureau
2015-09-14 21:08 ` Dave Airlie
2015-09-14 21:14 ` Marc-André Lureau
2015-09-14 21:18 ` Dave Airlie
2015-09-15 6:20 ` Gerd Hoffmann
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.