Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 3171E200C81 for ; Fri, 12 May 2017 03:03:40 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 30305160BCA; Fri, 12 May 2017 01:03:40 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 7642D160BC7 for ; Fri, 12 May 2017 03:03:39 +0200 (CEST) Received: (qmail 71370 invoked by uid 500); 12 May 2017 01:03:38 -0000 Mailing-List: contact user-help@guacamole.incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@guacamole.incubator.apache.org Delivered-To: mailing list user@guacamole.incubator.apache.org Received: (qmail 71360 invoked by uid 99); 12 May 2017 01:03:38 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 12 May 2017 01:03:38 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 46ABFC03A8 for ; Fri, 12 May 2017 01:03:38 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 0.299 X-Spam-Level: X-Spam-Status: No, score=0.299 tagged_above=-999 required=6.31 tests=[KAM_LAZY_DOMAIN_SECURITY=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id NC2M-6Xbmmz7 for ; Fri, 12 May 2017 01:03:36 +0000 (UTC) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.24]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id CCE7B5FB62 for ; Fri, 12 May 2017 01:03:35 +0000 (UTC) Received: from [93.208.97.200] (helo=[192.168.1.101]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1d8yzR-0007kZ-Kw; Fri, 12 May 2017 03:03:29 +0200 Subject: Re: GPU intensive applications in guacamole To: user@guacamole.incubator.apache.org References: <1494507883083-955.post@n4.nabble.com> Cc: jodonya@gmail.com From: Steffen Moser X-Enigmail-Draft-Status: N1110 Message-ID: Date: Fri, 12 May 2017 03:03:27 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <1494507883083-955.post@n4.nabble.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Df-Sender: bGlzdHNAc3RlZmZlbi1tb3Nlci5kZQ== archived-at: Fri, 12 May 2017 01:03:40 -0000 Hi, On 05/11/2017 03:04 PM, odonya wrote: > We have a gpu intensive application that we are trying to test if we can use > it with guacamole. This is not a gaming application. > My question is which machine is supposed to have enhanced GPUs , is it the > client machine which is connecting to guacamole or the remote machine or > actually both machines. The remote machine which runs both, the terminal service and your application should have the GPU power your application needs. It is in my opinion quite useless to have the power it in the client which executes just the browser. Whether it actually works, cannot be said without knowing more about the concrete application you would like to run. If your application uses the GPU for general-purpose calculation acceleration (e.g. CUDA or OpenCL code), i.e. non-frame-rendering calculations, then there should be no problem introduced by the remote access (besides the fact that aspects like GPU resource allocation and scheduling might require further attention in order to allow several user access your remote application simultaneously). If your application uses the GPU's power for accelerating the graphic frame rendering, I am not sure if the acceleration is available in remote/terminal services at all. I suppose that in a terminal server mode there won't be any GPU-based 3D acceleration at all neither in Unix/Linux (X11VNC, XRDP) nor in Windows (Windows Terminal Server). Best regards, Steffen