From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 13:31:58 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C768C106566C; Mon, 29 Aug 2011 13:31:58 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 7DC508FC13; Mon, 29 Aug 2011 13:31:58 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1Qy1wT-0006Mo-FD>; Mon, 29 Aug 2011 15:31:57 +0200 Received: from e178014041.adsl.alicedsl.de ([85.178.14.41] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1Qy1wT-0001kz-C2>; Mon, 29 Aug 2011 15:31:57 +0200 Message-ID: <4E5B94CC.3010207@zedat.fu-berlin.de> Date: Mon, 29 Aug 2011 15:31:56 +0200 From: "Hartmann, O." User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0) Gecko/20110825 Thunderbird/6.0 MIME-Version: 1.0 To: "freebsd-performance@freebsd.org" References: <4E5B663F.5080304@zedat.fu-berlin.de> <20110829143127.4300c80b.lists@yamagi.org> In-Reply-To: <20110829143127.4300c80b.lists@yamagi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.14.41 Cc: Adrian Chadd , freebsd-current@freebsd.org, Yamagi Burmeister Subject: Re: PHORONIX: OpenCL, GLSL Back-End For LLVM May Soon Open Up X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 13:31:58 -0000 On 08/29/11 14:31, Yamagi Burmeister wrote: > On Mon, 29 Aug 2011 20:12:54 +0800 > Adrian Chadd wrote: > >> Hi, >> >> http://forums.nvidia.com/index.php?showtopic=38242 Post 18 >> >> This indicates the driver supports CUDA somehow. What's missing is a >> FreeBSD runtime. >> >> Can someone please do some legwork with this and see if it's possible >> to bring the Linux CUDA SDK up in the linuxulator? > Yes that's possible. jhb@ wrote a little tutorial some time ago: > http://blogs.freebsdish.org/jhb/2010/07/20/using-cuda-with-the-native-freebsdamd64-nvidia-driver/ > With beginnig of 2011 I tried everything possible to make CUDA SDK running on FreeBSD 9-CUR/amd64. For those interested in this subject, the mentioned forae entries and that mentioned tutorial are a bit outdated. I tried the tutorial mentioned by Yamagi, but I had never real success installing SDK 3.2/32bit. For serious scientific usage 32bit isn't a great deal, my model code highly depends on 64 bit in the portions were the model is calculated on the cpu, not the GPU. Anyway, having CUDA working in the Linuxulator would be great. But having something OpenCL-ish natively would be a real quantum leap ... And 64bit. My lectures in "building compilers" I liestend to is quite a time ago, so as far as I know, nVidias driver BLOB is executing some binary code that is only applicable for the GPU. Further, the OpenCL code or even CUDA code of a C/C++ software is runtime compiled when accessed and transfered to the GPU/driver, so the nvcc compiler is a "sine conditio qua non" in this game, so far. My thinking: eliminating the need of the nvcc producing PTX code/binary code via LLVM could be a solution. But at this point I do not know whether PTX has to translated again in binary code via nvcc to make the GPU understand what I want. By the beginning of this year Pathscale introduced a kind of compiler capable of HMPP, a very smart model like OpenMP. This compiler seems not to be ready by now and I never got access to a beta version to test whether it was capable of compiling CUDA ready code. As far as I know, HMPP is also an "open" standard. Well, conclusively, there seems no real solution to be present for FreeBSD by now (as I mentioned, the Linuxulator is no real alternative due to its 32bit limitations). oh