From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on atuin.qyliss.net X-Spam-Level: X-Spam-Status: No, score=-6.4 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, SPF_HELO_NONE autolearn=unavailable autolearn_force=no version=3.4.6 Received: by atuin.qyliss.net (Postfix, from userid 496) id 386C492838; Thu, 28 Oct 2021 03:45:39 +0000 (UTC) Received: from atuin.qyliss.net (localhost [IPv6:::1]) by atuin.qyliss.net (Postfix) with ESMTP id AB83592882; Thu, 28 Oct 2021 03:45:14 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 496) id 622EA927D7; Thu, 28 Oct 2021 03:45:12 +0000 (UTC) Received: from bee.birch.relay.mailchannels.net (bee.birch.relay.mailchannels.net [23.83.209.14]) by atuin.qyliss.net (Postfix) with ESMTPS id 037D8927D4 for ; Thu, 28 Oct 2021 03:45:07 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|ncm@cantrip.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 96E0D208B1 for ; Thu, 28 Oct 2021 03:45:04 +0000 (UTC) Received: from pdx1-sub0-mail-a55.g.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 132832078C for ; Thu, 28 Oct 2021 03:45:04 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|ncm@cantrip.org Received: from pdx1-sub0-mail-a55.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384) by 100.114.196.211 (trex/6.4.3); Thu, 28 Oct 2021 03:45:04 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|ncm@cantrip.org X-MailChannels-Auth-Id: dreamhost X-Spicy-Ruddy: 45863aba46bef856_1635392704474_2845192953 X-MC-Loop-Signature: 1635392704474:235391539 X-MC-Ingress-Time: 1635392704474 Received: from pdx1-sub0-mail-a55.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a55.g.dreamhost.com (Postfix) with ESMTP id B87B9870F3 for ; Wed, 27 Oct 2021 20:45:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cantrip.org; h=to :references:subject:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s= cantrip.org; bh=FduPBLD/oTM8a3YVu2xdRhCBZ9w=; b=X3EHAy3v/kbZpWn/ r2AdSt9IVQ5GQi3V07ZMewgbA0ux7YSSURKs6XkJfxm9W1kMdBPWALYwu9PZwyT9 uYfuXvVcLlmMAYcooDKDLqtTiC7M95mppn+C+EXYE7FydZBRnRt080Hd57GNOB44 5ScuDor8qX/a/b5QL1hCpzdAKX4= Received: from [10.137.0.10] (pool-74-108-117-154.nycmny.fios.verizon.net [74.108.117.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ncm@cantrip.org) by pdx1-sub0-mail-a55.g.dreamhost.com (Postfix) with ESMTPSA id 7A6A486427 for ; Wed, 27 Oct 2021 20:45:02 -0700 (PDT) To: discuss@spectrum-os.org References: <20211026200434.w6yzfnl6duhqjgig@x220.qyliss.net> Subject: Re: GPU virtualization in Spectrum X-DH-BACKEND: pdx1-sub0-mail-a55 From: Nathan Myers Message-ID: Date: Wed, 27 Oct 2021 23:44:59 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <20211026200434.w6yzfnl6duhqjgig@x220.qyliss.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Message-ID-Hash: YDXJTAUXZZGV7URLGYP5NAPIIG6KAOEJ X-Message-ID-Hash: YDXJTAUXZZGV7URLGYP5NAPIIG6KAOEJ X-MailFrom: ncm@cantrip.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-config-1; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.4 Precedence: list List-Id: General high-level discussion about Spectrum Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: This is a very welcome update. I wonder: is Vulkan itself practical as a virtualized interface? I can imagine that shaders running on behalf of different VMs would need to be guarded against seeing memory meant for other VMs. Might this mean swapping in a different memory map when running on behalf of each VM, one at a time? Overhead from swapping memory maps might be better than no access at all. The use case I am concerned for is exercising Vulkan as a general compute acceleration engine, as in Kompute (http://kompute.cc), running alongside ordinary graphics rendering chores, and in place of proprietary CUDA. It would be tragic for security details to make 90+% of the computational power of our machines available only for sterile graphical rendering. If Vulkan could use a virtio-gpu backend, I guess this might come out to much the same thing. But would it lack access to GPU-specific optimizations implemented in e.g. an AMD driver and made available via higher-level Vulkan APIs not visible via virtio-gpu?