Hi,
On 03/27/2013 12:04 PM, Søren Sandmann wrote:
Hans de Goede <hdegoede@xxxxxxxxxx> writes:
Hmm, I assume with host-memory you mean guest memory here, right? iow surfaces
will be moved by the driver from video-memory to X-server allocated memory (which
in a vm is guest memory). I'm assuming this is what you mean in the rest of
my reply.
Right, "host" here means the host of the video device.
** IN_VIDEO => IN_HOST
- update_area is issued for the surface in question
- data is copied to pixman image
- state is set to IN_HOST
- destroy command is issued for the ID
I assume the main use-case for this is freeing up video memory,
unfortunately due to glz compression and the drawing command tree
kept in the spice-server, it is possible that the server itself
still holds a reference to the surface, and sending the destroy
will not end up freeing any memory (atleast not directly), this
is esp. going to be a problem when doing these kind of evictions
with the intention of freeing up a larger block of memory
for a new surface.
Indeed, this is a problem. The way I intend to deal with this was
described later in the mail:
After issuing a destroy, need to wait for the command ring to go
idle, then garbage collect. Hopefully this will trigger a recycle
call, which will then free the associated memory.
But if that fails, it will simply kick out another surface and try
again.
Given how spice-server works, I'm worried this may nor work all to well.
But we'll just have to wait and see. I just want it to be clear, that
making changes to the virtual hardware to make life easier for the
driver is an option too.
Regards,
Hans
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel