From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MClrs-00082N-4X for qemu-devel@nongnu.org; Fri, 05 Jun 2009 22:42:48 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MClrn-0007wc-I8 for qemu-devel@nongnu.org; Fri, 05 Jun 2009 22:42:47 -0400 Received: from [199.232.76.173] (port=53100 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MClrn-0007wZ-DB for qemu-devel@nongnu.org; Fri, 05 Jun 2009 22:42:43 -0400 Received: from mx20.gnu.org ([199.232.41.8]:5296) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MClrn-0008Vk-4Q for qemu-devel@nongnu.org; Fri, 05 Jun 2009 22:42:43 -0400 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MClrl-0008Tw-1i for qemu-devel@nongnu.org; Fri, 05 Jun 2009 22:42:41 -0400 From: Paul Brook Subject: Re: [Qemu-devel] Qemu + CUDA: a new possible way? Date: Sat, 6 Jun 2009 03:42:33 +0100 References: <4A297B77.8080008@autistici.org> In-Reply-To: <4A297B77.8080008@autistici.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906060342.33783.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: OneSoul > Recently, reading some technical articles over internet, I have > discoverd the big potentialities of the CUDA framework in relation to > the scientific and graphic computing that takes strong advantage from > the most recent GPUs. Someone has used it for password recovery, > realtime rendering, etc, with great results. Most of these problems are what's known as embarrassingly parallel. It's trivial to split them up into many small independent pieces. A GPU contains hundreds or thousands of small, loosely coupled, low power processing units so is a good fit for this kind of problem. Most of the work that qemu does is completely the opposite. Every step is highly dependent on the preceding steps, so you have to execute them in series. If you really think you have figured our some magic way around this then your first step should be to make qemu work over a small number (say 8 or 16) of tightly coupled CPU cores. If you can't do that then you haven't got a hope in hell of making it work over a vast number of remote GPU cores. Paul