Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Stefano Stabellini <stefano.stabellini@eu.citrix.com>]

Jamie Lokier wrote:

> Paul Brook wrote:
>> On Sunday 07 September 2008, Samuel Thibault wrote:
>>> Jamie Lokier, le Sun 07 Sep 2008 00:27:23 +0100, a écrit :
>>>> Samuel Thibault wrote:
>>>>> Jamie Lokier, le Fri 05 Sep 2008 13:02:15 +0100, a écrit :
>>>>>> Another way to map guest framebuffer to video memory is the XF86DGA
>>>>>> extension, which is great when you can use it.
>>>>> It is being deprecated and probably never works nowadays anyway :)
>>>> That's a shame as the alternatives are all slower on old video cards.
>>> Yes, and because alternatives don't provide so much performance.
>>> Ideally, once switched to fullscreen you could just let the guest
>>> directly write to the actual video memory (particularly interesting for
>>> Xen and KVM).
>> You really don't want to have the guest writing directly to host video ram. 
>> Video ram tends to be high-latency, so you want to write to regular memory, 
>> then use a wide block transfer or DMA to copy to video ram.
> 
> Latency applies mainly when reading.
> 
> A good quality guest _expects_ that reading its video RAM will be
> slow, and only writes to its video RAM, and possible by preparing images
> off-screen then wide block transfers. :-)

That is a really good point.
Usually the safe way to handle the video ram VS main memory problem is
to write to main memory then copy the whole buffer to video ram every so
often.
But in our case the guest thinks that he is writing to video ram
already, so in theory he is already using all precautions needed to
handle the latency problem.
It is actually probable that the guest is handling another buffer in his
own memory and syncing that one with what he thinks to be the video ram.