[pve-devel] [PATCH qemu-server/pve-manager v1 0/2] add virtio-vga-gl Vulkan (venus) support

[pve-devel] [PATCH qemu-server/pve-manager v1 0/2] add virtio-vga-gl Vulkan (venus) support

[Markus Frank]

This option is represented by an enum in qemu-server and a comboBox in
pve-manager, 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.

As I am not sure what the hostmem and blob properties actually do, I
asked on the qemu-discuss mailing list:
https://mail-archive.com/qemu-discuss@nongnu.org/msg09011.html

QEMU documentation:
www.qemu.org/docs/master/system/devices/virtio/virtio-gpu.html#virtio-gpu-virglrenderer


To get an overview of the performance, see the benchmark below.

supertuxkart (1.5) benchmark (default settings, vulkan, 1024x768):

Host result (Granite Ridge integrated GPU):
* Total frame count: 8488
* Total profiling time (ms): 38139
* Steady FPS: 92
* Mostly stable FPS: 137
* Typical FPS: 194

VM (host, 4 core, 8GiB) with venus (hostmem=8192M) result:
* Total frame count: 3321
* Total profiling time (ms): 38130
* Steady FPS: 58
* Mostly stable FPS: 75
* Typical FPS: 86

This benchmark showed no significant differences in performance between
the various memory window sizes for venus.



qemu-server:

Markus Frank (1):
  virtio-vga-gl: add Vulkan (venus) support

 src/PVE/QemuServer.pm | 20 +++++++++++++++++++-
 1 file changed, 19 insertions(+), 1 deletion(-)


pve-manager:

Markus Frank (1):
  ui: qemu: add Vulkan option in DisplayEdit

 www/manager6/qemu/DisplayEdit.js | 42 +++++++++++++++++++++++++++++++-
 1 file changed, 41 insertions(+), 1 deletion(-)

-- 
2.47.3



_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

[pve-devel] [PATCH qemu-server v1 1/2] virtio-vga-gl: add Vulkan (venus) support

[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.

Signed-off-by: Markus Frank <m.frank@proxmox.com>
---
 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/;
+    }
+
     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 {
-- 
2.47.3



_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

Re: [pve-devel] [PATCH qemu-server v1 1/2] virtio-vga-gl: add Vulkan (venus) support

[Thomas Lamprecht]

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?
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?

Mostly asking this key questions to better judge the design/approach you
chose.

> 
> Signed-off-by: Markus Frank <m.frank@proxmox.com>
> ---
>  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/;
> +    }
> +
>      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

Re: [pve-devel] [PATCH qemu-server v1 1/2] virtio-vga-gl: add Vulkan (venus) support

[Markus Frank]

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 <m.frank@proxmox.com>
>> ---
>>   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

[pve-devel] [PATCH pve-manager v1 2/2] ui: qemu: add Vulkan option in DisplayEdit

[Markus Frank]

The 'isVirgl' formula deactivates the Vulkan option if the type is not
'virtio-gl'. However, it does not reset the option to its default.
Therefore, also add a listener function to reset the Vulkan option.

Signed-off-by: Markus Frank <m.frank@proxmox.com>
---
 www/manager6/qemu/DisplayEdit.js | 42 +++++++++++++++++++++++++++++++-
 1 file changed, 41 insertions(+), 1 deletion(-)

diff --git a/www/manager6/qemu/DisplayEdit.js b/www/manager6/qemu/DisplayEdit.js
index a2c28ba7..c9a404c4 100644
--- a/www/manager6/qemu/DisplayEdit.js
+++ b/www/manager6/qemu/DisplayEdit.js
@@ -11,12 +11,30 @@ Ext.define('PVE.qemu.DisplayInputPanel', {
         return { vga: ret };
     },
 
+    controller: {
+        xclass: 'Ext.app.ViewController',
+
+        onTypeChange: function (type) {
+            let me = this;
+            let vm = me.getViewModel();
+
+            if (type.getValue() !== 'virtio-gl') {
+                vm.set('vulkan', '__default__');
+                vm.notify();
+            }
+        },
+    },
+
     viewModel: {
         data: {
             type: '__default__',
             clipboard: '__default__',
+            vulkan: '__default__',
         },
         formulas: {
+            isVirgl: function (get) {
+                return get('type') === 'virtio-gl';
+            },
             matchNonGUIOption: function (get) {
                 return get('type').match(/^(serial\d|none)$/);
             },
@@ -58,10 +76,32 @@ Ext.define('PVE.qemu.DisplayInputPanel', {
                 }
                 return true;
             },
+            listeners: { change: 'onTypeChange' },
             bind: {
                 value: '{type}',
             },
         },
+        {
+            xtype: 'proxmoxKVComboBox',
+            name: 'vulkan',
+            deleteEmpty: false,
+            fieldLabel: gettext('Vulkan'),
+            comboItems: [
+                [
+                    '__default__',
+                    Proxmox.Utils.defaultText + ' (' + Proxmox.Utils.disabledText + ')',
+                ],
+                ['venus-512', 'Venus (512 MiB memory window)'],
+                ['venus-1024', 'Venus (1024 MiB memory window)'],
+                ['venus-2048', 'Venus (2048 MiB memory window)'],
+                ['venus-4096', 'Venus (4096 MiB memory window)'],
+                ['venus-8192', 'Venus (8192 MiB memory window)'],
+            ],
+            bind: {
+                value: '{vulkan}',
+                disabled: '{!isVirgl}',
+            },
+        },
         {
             xtype: 'proxmoxintegerfield',
             emptyText: Proxmox.Utils.defaultText,
@@ -139,7 +179,7 @@ Ext.define('PVE.qemu.DisplayEdit', {
     vmconfig: undefined,
 
     subject: gettext('Display'),
-    width: 350,
+    width: 370,
 
     items: [
         {
-- 
2.47.3



_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

Re: [pve-devel] [PATCH pve-manager v1 2/2] ui: qemu: add Vulkan option in DisplayEdit

[Thomas Lamprecht]

Am 10.11.25 um 12:40 schrieb Markus Frank:
> The 'isVirgl' formula deactivates the Vulkan option if the type is not
> 'virtio-gl'. However, it does not reset the option to its default.
> Therefore, also add a listener function to reset the Vulkan option.
> 
> Signed-off-by: Markus Frank <m.frank@proxmox.com>
> ---
>  www/manager6/qemu/DisplayEdit.js | 42 +++++++++++++++++++++++++++++++-
>  1 file changed, 41 insertions(+), 1 deletion(-)
> 
> diff --git a/www/manager6/qemu/DisplayEdit.js b/www/manager6/qemu/DisplayEdit.js
> index a2c28ba7..c9a404c4 100644
> --- a/www/manager6/qemu/DisplayEdit.js
> +++ b/www/manager6/qemu/DisplayEdit.js
> @@ -11,12 +11,30 @@ Ext.define('PVE.qemu.DisplayInputPanel', {
>          return { vga: ret };
>      },
>  
> +    controller: {
> +        xclass: 'Ext.app.ViewController',
> +
> +        onTypeChange: function (type) {
> +            let me = this;
> +            let vm = me.getViewModel();
> +
> +            if (type.getValue() !== 'virtio-gl') {
> +                vm.set('vulkan', '__default__');
> +                vm.notify();
> +            }
> +        },
> +    },
> +
>      viewModel: {
>          data: {
>              type: '__default__',
>              clipboard: '__default__',
> +            vulkan: '__default__',
>          },
>          formulas: {
> +            isVirgl: function (get) {
> +                return get('type') === 'virtio-gl';
> +            },
>              matchNonGUIOption: function (get) {
>                  return get('type').match(/^(serial\d|none)$/);
>              },
> @@ -58,10 +76,32 @@ Ext.define('PVE.qemu.DisplayInputPanel', {
>                  }
>                  return true;
>              },
> +            listeners: { change: 'onTypeChange' },
>              bind: {
>                  value: '{type}',
>              },
>          },
> +        {
> +            xtype: 'proxmoxKVComboBox',
> +            name: 'vulkan',
> +            deleteEmpty: false,
> +            fieldLabel: gettext('Vulkan'),
> +            comboItems: [
> +                [
> +                    '__default__',
> +                    Proxmox.Utils.defaultText + ' (' + Proxmox.Utils.disabledText + ')',
> +                ],
> +                ['venus-512', 'Venus (512 MiB memory window)'],
> +                ['venus-1024', 'Venus (1024 MiB memory window)'],
> +                ['venus-2048', 'Venus (2048 MiB memory window)'],
> +                ['venus-4096', 'Venus (4096 MiB memory window)'],
> +                ['venus-8192', 'Venus (8192 MiB memory window)'],
> +            ],


might be nicer to virtually split the option into two here, i.e. a checkbox
for vulkan/venus and a dedicated combobox for the memory window size (or
just leave that out for now if it doesn't make a measurable difference anyway.

> +            bind: {
> +                value: '{vulkan}',
> +                disabled: '{!isVirgl}',
> +            },
> +        },
>          {
>              xtype: 'proxmoxintegerfield',
>              emptyText: Proxmox.Utils.defaultText,
> @@ -139,7 +179,7 @@ Ext.define('PVE.qemu.DisplayEdit', {
>      vmconfig: undefined,
>  
>      subject: gettext('Display'),
> -    width: 350,
> +    width: 370,
>  
>      items: [
>          {


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

Re: [pve-devel] [PATCH qemu-server/pve-manager v1 0/2] add virtio-vga-gl Vulkan (venus) support

[Thomas Lamprecht]

Am 10.11.25 um 12:40 schrieb Markus Frank:
> To get an overview of the performance, see the benchmark below.
> 
> supertuxkart (1.5) benchmark (default settings, vulkan, 1024x768):
> 
> Host result (Granite Ridge integrated GPU):
> * Total frame count: 8488
> * Total profiling time (ms): 38139
> * Steady FPS: 92
> * Mostly stable FPS: 137
> * Typical FPS: 194
> 
> VM (host, 4 core, 8GiB) with venus (hostmem=8192M) result:
> * Total frame count: 3321
> * Total profiling time (ms): 38130
> * Steady FPS: 58
> * Mostly stable FPS: 75
> * Typical FPS: 86
> 

Comparing with a benchmark in the VM with other displays would be also nice.
Most interesting would be the default (vga IIRC) and qxl (SPICE).

> This benchmark showed no significant differences in performance between
> the various memory window sizes for venus.

I probably would not expose them then for now.


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

Re: [pve-devel] [PATCH qemu-server/pve-manager v1 0/2] add virtio-vga-gl Vulkan (venus) support

[Markus Frank]

On 2025-11-10 14:54, Thomas Lamprecht wrote:
> Am 10.11.25 um 12:40 schrieb Markus Frank:
>> To get an overview of the performance, see the benchmark below.
>>
>> supertuxkart (1.5) benchmark (default settings, vulkan, 1024x768):
>>
>> Host result (Granite Ridge integrated GPU):
>> * Total frame count: 8488
>> * Total profiling time (ms): 38139
>> * Steady FPS: 92
>> * Mostly stable FPS: 137
>> * Typical FPS: 194
>>
>> VM (host, 4 core, 8GiB) with venus (hostmem=8192M) result:
>> * Total frame count: 3321
>> * Total profiling time (ms): 38130
>> * Steady FPS: 58
>> * Mostly stable FPS: 75
>> * Typical FPS: 86
>>
> 
> Comparing with a benchmark in the VM with other displays would be also nice.
> Most interesting would be the default (vga IIRC) and qxl (SPICE).

I did, but I do not think the results are really comparable because all current display types use vulkan software rendering, which performs really badly.
See below:

VM virtio-gl (Vulkan, without venus, llvmpipe software rendering):
* Total frame count: 762
* Total profiling time (ms): 260786
* Steady FPS: 1
* Mostly stable FPS: 2
* Typical FPS: 2


To make a more meaningful comparison, it would be better to use OpenGL with virtio-gl.

This is the result I got in the same VM with virtio-gl and a similar supertuxkart benchmark using OpenGL instead of Vulkan:
VM virtio-gl (OpenGL, virgl):
* Total frame count: 2940
* Total profiling time (ms): 38128
* Steady FPS: 35
* Mostly stable FPS: 54
* Typical FPS: 77


OpenGL also requires software rendering with VGA and QXL.

vga (OpenGL, software rendering):
* Total frame count: 762
* Total profiling time (ms): 73867
* Steady FPS: 7
* Mostly stable FPS: 8
* Typical FPS: 10

qxl (OpenGL, software rendering):
* Total frame count: 762
* Total profiling time (ms): 75797
* Steady FPS: 7
* Mostly stable FPS: 8
* Typical FPS: 9

> 
>> This benchmark showed no significant differences in performance between
>> the various memory window sizes for venus.
> 
> I probably would not expose them then for now.



_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

Re: [pve-devel] [PATCH qemu-server/pve-manager v1 0/2] add virtio-vga-gl Vulkan (venus) support

[Dominik Csapak]

to add some of my high level tests & thoughts:

tried with an NVIDIA card, but could not get it to work. The guest
would start but could not initialize the vulkan driver -> the
virgl-server process on the host crashed. When trying again
afterwards (e.g. with vkcube) the guest also crashed (probably
worth looking into if I have more time?)

Also tried with an AMD RX560, which worked fine.

I tested a vulkan memtest tool[0] (thanks @thomas for finding this)
but the various memory window settings did not make a difference,
it would always result in ~5.4 GB memory transfer speeds.

I also tested the Tomb Raider (2013) benchmark with proton (9.0-5) with
dxvk (directx -> vulkan translation layer) and got

the following results:

virtio-gl hostmem size  avg fps  host rss of the kvm process
512M                    62.6     ~8GiB
8192M                   61.3     ~8GiB

so the hostmem size did not make any difference.

My suggestion would be to reduce the option to a single boolean for now 
(e.g. vulkan=on/off) and use 512M hostmem size by default.
We can still expose some memory setting later too if we need it.

0: https://github.com/GpuZelenograd/memtest_vulkan

On 11/10/25 12:40 PM, Markus Frank wrote:
> This option is represented by an enum in qemu-server and a comboBox in
> pve-manager, 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.
> 
> As I am not sure what the hostmem and blob properties actually do, I
> asked on the qemu-discuss mailing list:
> https://mail-archive.com/qemu-discuss@nongnu.org/msg09011.html
> 
> QEMU documentation:
> www.qemu.org/docs/master/system/devices/virtio/virtio-gpu.html#virtio-gpu-virglrenderer
> 
> 
> To get an overview of the performance, see the benchmark below.
> 
> supertuxkart (1.5) benchmark (default settings, vulkan, 1024x768):
> 
> Host result (Granite Ridge integrated GPU):
> * Total frame count: 8488
> * Total profiling time (ms): 38139
> * Steady FPS: 92
> * Mostly stable FPS: 137
> * Typical FPS: 194
> 
> VM (host, 4 core, 8GiB) with venus (hostmem=8192M) result:
> * Total frame count: 3321
> * Total profiling time (ms): 38130
> * Steady FPS: 58
> * Mostly stable FPS: 75
> * Typical FPS: 86
> 
> This benchmark showed no significant differences in performance between
> the various memory window sizes for venus.
> 
> 
> 
> qemu-server:
> 
> Markus Frank (1):
>    virtio-vga-gl: add Vulkan (venus) support
> 
>   src/PVE/QemuServer.pm | 20 +++++++++++++++++++-
>   1 file changed, 19 insertions(+), 1 deletion(-)
> 
> 
> pve-manager:
> 
> Markus Frank (1):
>    ui: qemu: add Vulkan option in DisplayEdit
> 
>   www/manager6/qemu/DisplayEdit.js | 42 +++++++++++++++++++++++++++++++-
>   1 file changed, 41 insertions(+), 1 deletion(-)
> 



_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

Re: [pve-devel] [PATCH qemu-server/pve-manager v1 0/2] add virtio-vga-gl Vulkan (venus) support

[Thomas Lamprecht]

Am 13.11.25 um 16:13 schrieb Dominik Csapak:
> My suggestion would be to reduce the option to a single boolean for now
> (e.g. vulkan=on/off) and use 512M hostmem size by default.
> We can still expose some memory setting later too if we need it.

Sounds good to me. As, like you say, when needed we can add properties
like "vulcan-protocol" (defaulting to venus) or "venus-memory-window"
(or s/venus/vulkan/ if it applies for all available protocols).



_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel