From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id 8033D1FF17A for ; Tue, 11 Nov 2025 12:06:29 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 03857704F; Tue, 11 Nov 2025 12:07:14 +0100 (CET) Message-ID: Date: Tue, 11 Nov 2025 12:06:40 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Markus Frank To: Thomas Lamprecht , Proxmox VE development discussion References: <20251110114032.125526-1-m.frank@proxmox.com> <20251110114032.125526-2-m.frank@proxmox.com> <848ad76f-dca6-4944-a309-2e18c77553c3@proxmox.com> Content-Language: en-US In-Reply-To: <848ad76f-dca6-4944-a309-2e18c77553c3@proxmox.com> X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1762859178023 X-SPAM-LEVEL: Spam detection results: 0 AWL -0.001 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [qemu.org, qemuserver.pm] Subject: Re: [pve-devel] [PATCH qemu-server v1 1/2] virtio-vga-gl: add Vulkan (venus) support X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Proxmox VE development discussion Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" On 2025-11-10 15:27, Thomas Lamprecht wrote: > Am 10.11.25 um 12:40 schrieb Markus Frank: >> The venus protocol facilitates the translation of Vulkan API calls via >> the virglrenderer. To use it, the virgl-server package must be installed >> on the host. >> >> The Vulkan option is represented by an enum with values such as >> 'venus-512' and 'venus-1024'. This is to allow for the potential >> addition of another Vulkan implementation in the future. The number >> indicates the memory window in MiB for Venus. > > Meh, if it provides no obvious benefit I'm not sure if this makes sense > to add now already. > > I'd also mention more prominently that this only works for the virtio-gl > type, at least in the commit message and probably also in the description > of the vulkan "flag". > Is this strongly limited to that display type? And are there errors > generated with others combination that block the start? Yes, it is limited to virtio-gl. I will update the description. It should also mention that 'virgl-server' needs to be installed on the host. And yes, there is an error. See inline below. > Asking mostly to see if it would be an option to just generate a log_warn > about a useless combination of display and venus that then shows up in the > start task in such a case. > > And is it likely that there might be another protocol that relays vulkan? A different protocol already exists for Vulkan: virtio-gpu rutabaga [1]. However, I do not think this one is really suitable for PVE. I would not rule out the possibility of another implementation in the future. [1] https://www.qemu.org/docs/master/system/devices/virtio/virtio-gpu.html#virtio-gpu-rutabaga > > Mostly asking this key questions to better judge the design/approach you > chose. > >> >> Signed-off-by: Markus Frank >> --- >> src/PVE/QemuServer.pm | 20 +++++++++++++++++++- >> 1 file changed, 19 insertions(+), 1 deletion(-) >> >> diff --git a/src/PVE/QemuServer.pm b/src/PVE/QemuServer.pm >> index cf195ccc..2b358e9f 100644 >> --- a/src/PVE/QemuServer.pm >> +++ b/src/PVE/QemuServer.pm >> @@ -160,6 +160,12 @@ my $vga_fmt = { >> qw(cirrus qxl qxl2 qxl3 qxl4 none serial0 serial1 serial2 serial3 std virtio virtio-gl vmware) >> ], >> }, >> + vulkan => { >> + description => 'Enable vulkan by using the venus protocol.', >> + type => 'string', >> + enum => ['venus-512', 'venus-1024', 'venus-2048', 'venus-4096', 'venus-8192'], >> + optional => 1, >> + }, >> memory => { >> description => "Sets the VGA memory (in MiB). Has no effect with serial display.", >> type => 'integer', >> @@ -1499,6 +1505,15 @@ sub print_vga_device { >> $pciaddr = print_pci_addr($vgaid, $bridges, $arch); >> } >> >> + my $venus = ""; >> + if ($vga->{vulkan} && $vga->{vulkan} =~ /^venus-(\d+)/) { >> + my $virgl_memory_window = $1; >> + $venus = ",hostmem=${virgl_memory_window}M,venus=on,blob=on"; >> + >> + die "You need to use virtio-gl to enable vulkan (venus) support!\n" >> + if $vga->{type} !~ /^virtio-gl/; >> + } Here is a die to prevent starting without virtio-gl. >> + >> if ($vga->{type} eq 'virtio-gl') { >> my $base = '/usr/lib/x86_64-linux-gnu/lib'; >> die "missing libraries for '$vga->{type}' detected! Please install 'libgl1' and 'libegl1'\n" >> @@ -1507,9 +1522,12 @@ sub print_vga_device { >> die >> "no DRM render node detected (/dev/dri/renderD*), no GPU? - needed for '$vga->{type}' display\n" >> if !PVE::Tools::dir_glob_regex('/dev/dri/', "renderD.*"); >> + >> + die "missing virgl render server for vulkan (venus)! Please install 'virgl-server'.\n" >> + if $vga->{vulkan} && !-e "/usr/libexec/virgl_render_server"; >> } >> >> - return "$type,id=${vgaid}${memory}${max_outputs}${pciaddr}${edidoff}"; >> + return "$type,id=${vgaid}${memory}${max_outputs}${pciaddr}${edidoff}${venus}"; >> } >> >> sub vm_is_volid_owner { > _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel