On 10/28/2010 03:52 PM, Ian Molton wrote:
> On 28/10/10 15:24, Avi Kivity wrote:
>>> The caller is intended to block as the host must perform GL rendering
>>> before allowing the guests process to continue.
>>
>> Why is that? Can't we pipeline the process?
>
> No, not really. the guest may call for the scene to be rendered at any
> time and we have to wait for that to happen before we can return the
> data to it.
Waiting for a response is fine, but can't the guest issue a second batch
while waiting for the first?
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
On 11/01/2010 05:42 AM, Avi Kivity wrote:
> On 10/28/2010 03:52 PM, Ian Molton wrote:
>> On 28/10/10 15:24, Avi Kivity wrote:
>>>> The caller is intended to block as the host must perform GL rendering
>>>> before allowing the guests process to continue.
>>>
>>> Why is that? Can't we pipeline the process?
>>
>> No, not really. the guest may call for the scene to be rendered at
>> any time and we have to wait for that to happen before we can return
>> the data to it.
>
> Waiting for a response is fine, but can't the guest issue a second
> batch while waiting for the first?
In a threaded application I think you mean but all RPCs are dispatched
holding a global lock so even within a threaded application, only a
single GL call will be executed at a time.
The other scenario would be multiple applications trying to use GL but
AFAICT, this is not supported in the current model.
Regards,
Anthony Liguori
On 01/11/10 13:21, Anthony Liguori wrote:
> On 11/01/2010 05:42 AM, Avi Kivity wrote:
>> On 10/28/2010 03:52 PM, Ian Molton wrote:
>>> On 28/10/10 15:24, Avi Kivity wrote:
>> Waiting for a response is fine, but can't the guest issue a second
>> batch while waiting for the first?
> The other scenario would be multiple applications trying to use GL but
> AFAICT, this is not supported in the current model.
It very much is. It supports fully visually integrated rendering (no
overlay windows) and even compositing GL window managers work fine, even
if running 3D apps under them.
-Ian
On 01/11/10 10:42, Avi Kivity wrote:
>> No, not really. the guest may call for the scene to be rendered at
>> any time and we have to wait for that to happen before we can
>> return the data to it.
>
> Waiting for a response is fine, but can't the guest issue a second
> batch while waiting for the first?
No. Userspace doesnt do or expect that.
Multiple applications work fine, however.
-Ian
On 11/01/2010 10:49 AM, Ian Molton wrote:
> On 01/11/10 13:21, Anthony Liguori wrote:
>> On 11/01/2010 05:42 AM, Avi Kivity wrote:
>>> On 10/28/2010 03:52 PM, Ian Molton wrote:
>>>> On 28/10/10 15:24, Avi Kivity wrote:
>
>>> Waiting for a response is fine, but can't the guest issue a second
>>> batch while waiting for the first?
>
>> The other scenario would be multiple applications trying to use GL but
>> AFAICT, this is not supported in the current model.
>
> It very much is. It supports fully visually integrated rendering (no
> overlay windows) and even compositing GL window managers work fine,
> even if running 3D apps under them.
Does the kernel track userspace pid and pass that information to qemu?
Regards,
Anthony Liguori
> -Ian
On 01/11/10 15:57, Anthony Liguori wrote:
>> It very much is. It supports fully visually integrated rendering (no
>> overlay windows) and even compositing GL window managers work fine,
>> even if running 3D apps under them.
>
> Does the kernel track userspace pid and pass that information to qemu?
Yes. And the qemu code tracks the PIDs and keeps multiple queues (one
per pid).
-Ian