| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <4CCEBEE2.8010404@codemonkey.ws> Date: Mon, 01 Nov 2010 08:21:38 -0500 From: Anthony Liguori <anthony@...emonkey.ws> To: Avi Kivity <avi@...hat.com> CC: Ian Molton <ian.molton@...labora.co.uk>, virtualization@...ts.osdl.org, linux-kernel@...r.kernel.org, QEMU Developers <qemu-devel@...gnu.org> Subject: Re: [Qemu-devel] Re: [PATCH] Implement a virtio GPU transport 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists