date:20111109

[Spice-devel] 0.10 release - what's pending?

2011-11-09 Thread Alon Levy

Hi,

 It's been a long time with no major news of problems in 0.9 land. This
 could mean zero users, but in that case I go to my secondary reason,
 which is that spice-server.syms is already claiming to have 0.10
 symbols, and that's just ugly.

 Any patches anyone is expecting to send to fix any bugs? any objections
 to cutting a release this week?

Alon
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] OpenGL passthrough

2011-11-09 Thread Mosebach Kai

Hi guys,

Just a though : 

In a scenario where a kvm-host system has a openGL capable display
adapter, wouldn't it be possible (and relatively simple compared to a full
VGA passthrough) to just
pass the OpenGL interface/access into the VMs QXL Adapter making this one
(HW accelerated) OpenGL aware?

Thanks for enlightenment,

Kai

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] OpenGL passthrough

2011-11-09 Thread Alon Levy

On Wed, Nov 09, 2011 at 01:52:12PM +, Mosebach  Kai wrote:
 Hi guys,
 
 Just a though : 
 
 In a scenario where a kvm-host system has a openGL capable display
 adapter, wouldn't it be possible (and relatively simple compared to a full
 VGA passthrough) to just
 pass the OpenGL interface/access into the VMs QXL Adapter making this one
 (HW accelerated) OpenGL aware?

There are threads in qemu-devel about using pci passthrough for using
the host GPU from the guest. If you actually want to view the results
then yes, it's relatively simple in theory. Maybe also in practice, but
I've been struggling with a slightly larger problem, doing OpenGL and
Direct3D passthrough, for almost a year now, with no results to show :/

I do have patches on my harddrive somewhere by Izik Eidos that do a
proof of concept for GL passthrough from a windows guest to a
windows/linux client, I could ask him if it's ok to post them if you'd
like. (and if I can find them).

Basically it adds qxl messages for all the GL commands, adds a surface
type, tracks all commands from the last SwapBuffers (I guess
wglSwapBuffers - the equivalent of glXSwapBuffers) per surface, and
passes all of those to the client. Rendering on the server, that is the
host, will be a little simpler.

 
 Thanks for enlightenment,
 
 Kai
 
 ___
 Spice-devel mailing list
 Spice-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/spice-devel
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [PATCH] support _ASYNC io calls and interrupt handling (busy wait)

2011-11-09 Thread Alon Levy

rebased.

From: Gerd Hofmann kra...@redhat.com
---
This is Gerd's patch from the original async io in qemu series, rebased and
tested by me.

 src/qxl.h |8 ++
 src/qxl_driver.c  |   66 +---
 src/qxl_surface.c |4 +-
 3 files changed, 72 insertions(+), 6 deletions(-)

diff --git a/src/qxl.h b/src/qxl.h
index 23ed2dc..62c3086 100644
--- a/src/qxl.h
+++ b/src/qxl.h
@@ -410,6 +410,14 @@ void *qxl_allocnf  (qxl_screen_t   
*qxl,
unsigned long   size);
 int   qxl_garbage_collect (qxl_screen_t *qxl);
 
+/*
+ * I/O port commands
+ */
+void qxl_update_area(qxl_screen_t *qxl);
+void qxl_memslot_add(qxl_screen_t *qxl, uint8_t id);
+void qxl_create_primary(qxl_screen_t *qxl);
+void qxl_notify_oom(qxl_screen_t *qxl);
+
 #ifdef XSPICE
 /* device to spice-server, now xspice to spice-server */
 void ioport_write(qxl_screen_t *qxl, uint32_t io_port, uint32_t val);
diff --git a/src/qxl_driver.c b/src/qxl_driver.c
index 428735a..ada0943 100644
--- a/src/qxl_driver.c
+++ b/src/qxl_driver.c
@@ -102,6 +102,64 @@ const OptionInfoRec DefaultOptions[] = {
 { -1, NULL, OPTV_NONE, {0}, FALSE }
 };
 
+static void qxl_wait_for_io_command(qxl_screen_t *qxl)
+{
+struct QXLRam *ram_header = (void *)(
+(unsigned long)qxl-ram + qxl-rom-ram_header_offset);
+
+while (!(ram_header-int_pending  QXL_INTERRUPT_IO_CMD)) {
+usleep(1);
+}
+ram_header-int_pending = ~QXL_INTERRUPT_IO_CMD;
+}
+
+void qxl_update_area(qxl_screen_t *qxl)
+{
+#ifndef XSPICE
+if (qxl-pci-revision = 3) {
+ioport_write(qxl, QXL_IO_UPDATE_AREA_ASYNC, 0);
+qxl_wait_for_io_command(qxl);
+} else {
+ioport_write(qxl, QXL_IO_UPDATE_AREA, 0);
+}
+#else
+ioport_write(qxl, QXL_IO_UPDATE_AREA, 0);
+#endif
+}
+
+void qxl_memslot_add(qxl_screen_t *qxl, uint8_t id)
+{
+#ifndef XSPICE
+if (qxl-pci-revision = 3) {
+ioport_write(qxl, QXL_IO_MEMSLOT_ADD_ASYNC, id);
+qxl_wait_for_io_command(qxl);
+} else {
+ioport_write(qxl, QXL_IO_MEMSLOT_ADD, id);
+}
+#else
+ioport_write(qxl, QXL_IO_MEMSLOT_ADD, id);
+#endif
+}
+
+void qxl_create_primary(qxl_screen_t *qxl)
+{
+#ifndef XSPICE
+if (qxl-pci-revision = 3) {
+ioport_write(qxl, QXL_IO_CREATE_PRIMARY_ASYNC, 0);
+qxl_wait_for_io_command(qxl);
+} else {
+ioport_write(qxl, QXL_IO_CREATE_PRIMARY, 0);
+}
+#else
+ioport_write(qxl, QXL_IO_CREATE_PRIMARY, 0);
+#endif
+}
+
+void qxl_notify_oom(qxl_screen_t *qxl)
+{
+ioport_write(qxl, QXL_IO_NOTIFY_OOM, 0);
+}
+
 int
 qxl_garbage_collect (qxl_screen_t *qxl)
 {
@@ -190,8 +248,8 @@ qxl_usleep (int useconds)
 int
 qxl_handle_oom (qxl_screen_t *qxl)
 {
-ioport_write(qxl, QXL_IO_NOTIFY_OOM, 0);
-
+qxl_notify_oom(qxl);
+
 #if 0
 ErrorF (.);
 qxl_usleep (1);
@@ -228,7 +286,7 @@ qxl_allocnf (qxl_screen_t *qxl, unsigned long size)
ram_header-update_area.right = qxl-virtual_x;
ram_header-update_surface = 0; /* Only primary for now */

-   ioport_write(qxl, QXL_IO_UPDATE_AREA, 0);
+qxl_update_area(qxl);

 #if 0
ErrorF (eliminated memory (%d)\n, nth_oom++);
@@ -471,7 +529,7 @@ setup_slot(qxl_screen_t *qxl, uint8_t slot_index_offset,
 ram_header-mem_slot.mem_start = slot-start_phys_addr;
 ram_header-mem_slot.mem_end = slot-end_phys_addr;
 
-ioport_write(qxl, QXL_IO_MEMSLOT_ADD, slot_index);
+qxl_memslot_add(qxl, slot_index);
 
 slot-generation = qxl-rom-slot_generation;
 
diff --git a/src/qxl_surface.c b/src/qxl_surface.c
index 047b35a..5a26ba6 100644
--- a/src/qxl_surface.c
+++ b/src/qxl_surface.c
@@ -378,7 +378,7 @@ qxl_surface_cache_create_primary (surface_cache_t   *cache,
 create-type = QXL_SURF_TYPE_PRIMARY;
 create-mem = physical_address (cache-qxl, cache-qxl-ram, 
cache-qxl-main_mem_slot);
 
-ioport_write(qxl, QXL_IO_CREATE_PRIMARY, 0);
+qxl_create_primary(qxl);
 
 dev_addr = (uint8_t *)qxl-ram + mode-stride * (mode-y_res - 1);
 
@@ -920,7 +920,7 @@ download_box (qxl_surface_t *surface, int x1, int y1, int 
x2, int y2)
 ErrorF (Issuing update command for %d\n, surface-id);
 #endif
 
-ioport_write(surface-cache-qxl, QXL_IO_UPDATE_AREA, 0);
+qxl_update_area(surface-cache-qxl);
 
 pixman_image_composite (PIXMAN_OP_SRC,
surface-dev_image,
-- 
1.7.7.1

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] About spice-xpi firefox version Compatiblity

2011-11-09 Thread Antonio Perez-Aranda

Hi all,

I'm tring to running spice-xpi on Firefox 7.0 but it say me that
plugin is incompatible.

I modify the install.rdf to allow install until firefox 10.0 and I'm
disable the compatibility check on install. But when I try to load
test.html from git it say me that the plugins are required.

Do you plan support recent Firefox versions?

Thanks

-- 
Antonio Pérez-Aranda Alcaide
aperezara...@yaco.es

Yaco Sistemas S.L.
http://www.yaco.es/
C/ Rioja 5, 41001 Sevilla
Teléfono +34 954 50 00 57
Fax      +34 954 50 09 29
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH] support _ASYNC io calls and interrupt handling (busy wait)

2011-11-09 Thread Alon Levy

On Wed, Nov 09, 2011 at 05:30:28PM +0200, Alon Levy wrote:
 rebased.
 
 From: Gerd Hofmann kra...@redhat.com

I'll correct Gerd's last name before committing if it's acked. Sorry
Gerd!

 ---
 This is Gerd's patch from the original async io in qemu series, rebased and
 tested by me.
 
  src/qxl.h |8 ++
  src/qxl_driver.c  |   66 +---
  src/qxl_surface.c |4 +-
  3 files changed, 72 insertions(+), 6 deletions(-)
 
 diff --git a/src/qxl.h b/src/qxl.h
 index 23ed2dc..62c3086 100644
 --- a/src/qxl.h
 +++ b/src/qxl.h
 @@ -410,6 +410,14 @@ void *qxl_allocnf  (qxl_screen_t 
   *qxl,
   unsigned long   size);
  int qxl_garbage_collect (qxl_screen_t *qxl);
  
 +/*
 + * I/O port commands
 + */
 +void qxl_update_area(qxl_screen_t *qxl);
 +void qxl_memslot_add(qxl_screen_t *qxl, uint8_t id);
 +void qxl_create_primary(qxl_screen_t *qxl);
 +void qxl_notify_oom(qxl_screen_t *qxl);
 +
  #ifdef XSPICE
  /* device to spice-server, now xspice to spice-server */
  void ioport_write(qxl_screen_t *qxl, uint32_t io_port, uint32_t val);
 diff --git a/src/qxl_driver.c b/src/qxl_driver.c
 index 428735a..ada0943 100644
 --- a/src/qxl_driver.c
 +++ b/src/qxl_driver.c
 @@ -102,6 +102,64 @@ const OptionInfoRec DefaultOptions[] = {
  { -1, NULL, OPTV_NONE, {0}, FALSE }
  };
  
 +static void qxl_wait_for_io_command(qxl_screen_t *qxl)
 +{
 +struct QXLRam *ram_header = (void *)(
 +(unsigned long)qxl-ram + qxl-rom-ram_header_offset);
 +
 +while (!(ram_header-int_pending  QXL_INTERRUPT_IO_CMD)) {
 +usleep(1);
 +}
 +ram_header-int_pending = ~QXL_INTERRUPT_IO_CMD;
 +}
 +
 +void qxl_update_area(qxl_screen_t *qxl)
 +{
 +#ifndef XSPICE
 +if (qxl-pci-revision = 3) {
 +ioport_write(qxl, QXL_IO_UPDATE_AREA_ASYNC, 0);
 +qxl_wait_for_io_command(qxl);
 +} else {
 +ioport_write(qxl, QXL_IO_UPDATE_AREA, 0);
 +}
 +#else
 +ioport_write(qxl, QXL_IO_UPDATE_AREA, 0);
 +#endif
 +}
 +
 +void qxl_memslot_add(qxl_screen_t *qxl, uint8_t id)
 +{
 +#ifndef XSPICE
 +if (qxl-pci-revision = 3) {
 +ioport_write(qxl, QXL_IO_MEMSLOT_ADD_ASYNC, id);
 +qxl_wait_for_io_command(qxl);
 +} else {
 +ioport_write(qxl, QXL_IO_MEMSLOT_ADD, id);
 +}
 +#else
 +ioport_write(qxl, QXL_IO_MEMSLOT_ADD, id);
 +#endif
 +}
 +
 +void qxl_create_primary(qxl_screen_t *qxl)
 +{
 +#ifndef XSPICE
 +if (qxl-pci-revision = 3) {
 +ioport_write(qxl, QXL_IO_CREATE_PRIMARY_ASYNC, 0);
 +qxl_wait_for_io_command(qxl);
 +} else {
 +ioport_write(qxl, QXL_IO_CREATE_PRIMARY, 0);
 +}
 +#else
 +ioport_write(qxl, QXL_IO_CREATE_PRIMARY, 0);
 +#endif
 +}
 +
 +void qxl_notify_oom(qxl_screen_t *qxl)
 +{
 +ioport_write(qxl, QXL_IO_NOTIFY_OOM, 0);
 +}
 +
  int
  qxl_garbage_collect (qxl_screen_t *qxl)
  {
 @@ -190,8 +248,8 @@ qxl_usleep (int useconds)
  int
  qxl_handle_oom (qxl_screen_t *qxl)
  {
 -ioport_write(qxl, QXL_IO_NOTIFY_OOM, 0);
 -
 +qxl_notify_oom(qxl);
 +
  #if 0
  ErrorF (.);
  qxl_usleep (1);
 @@ -228,7 +286,7 @@ qxl_allocnf (qxl_screen_t *qxl, unsigned long size)
   ram_header-update_area.right = qxl-virtual_x;
   ram_header-update_surface = 0; /* Only primary for now */
   
 - ioport_write(qxl, QXL_IO_UPDATE_AREA, 0);
 +qxl_update_area(qxl);
   
  #if 0
   ErrorF (eliminated memory (%d)\n, nth_oom++);
 @@ -471,7 +529,7 @@ setup_slot(qxl_screen_t *qxl, uint8_t slot_index_offset,
  ram_header-mem_slot.mem_start = slot-start_phys_addr;
  ram_header-mem_slot.mem_end = slot-end_phys_addr;
  
 -ioport_write(qxl, QXL_IO_MEMSLOT_ADD, slot_index);
 +qxl_memslot_add(qxl, slot_index);
  
  slot-generation = qxl-rom-slot_generation;
  
 diff --git a/src/qxl_surface.c b/src/qxl_surface.c
 index 047b35a..5a26ba6 100644
 --- a/src/qxl_surface.c
 +++ b/src/qxl_surface.c
 @@ -378,7 +378,7 @@ qxl_surface_cache_create_primary (surface_cache_t *cache,
  create-type = QXL_SURF_TYPE_PRIMARY;
  create-mem = physical_address (cache-qxl, cache-qxl-ram, 
 cache-qxl-main_mem_slot);
  
 -ioport_write(qxl, QXL_IO_CREATE_PRIMARY, 0);
 +qxl_create_primary(qxl);
  
  dev_addr = (uint8_t *)qxl-ram + mode-stride * (mode-y_res - 1);
  
 @@ -920,7 +920,7 @@ download_box (qxl_surface_t *surface, int x1, int y1, int 
 x2, int y2)
  ErrorF (Issuing update command for %d\n, surface-id);
  #endif
  
 -ioport_write(surface-cache-qxl, QXL_IO_UPDATE_AREA, 0);
 +qxl_update_area(surface-cache-qxl);
  
  pixman_image_composite (PIXMAN_OP_SRC,
   surface-dev_image,
 -- 
 1.7.7.1
 
 ___
 Spice-devel mailing list
 Spice-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] OpenGL passthrough

2011-11-09 Thread Mosebach Kai

On 11/9/11 3:51 PM, Alon Levy al...@redhat.com wrote:


On Wed, Nov 09, 2011 at 01:52:12PM +, Mosebach  Kai wrote:
 Hi guys,
 
 Just a though : 
 
 In a scenario where a kvm-host system has a openGL capable display
 adapter, wouldn't it be possible (and relatively simple compared to a
full
 VGA passthrough) to just
 pass the OpenGL interface/access into the VMs QXL Adapter making this
one
 (HW accelerated) OpenGL aware?

There are threads in qemu-devel about using pci passthrough for using

I tried for long time now to pass through PCIe Hardware into the guest
with all kind of PCIe cards w/o too much off success. So that¹s not what I
want ;-)

the host GPU from the guest. If you actually want to view the results
then yes, it's relatively simple in theory. Maybe also in practice, but
I've been struggling with a slightly larger problem, doing OpenGL and
Direct3D passthrough, for almost a year now, with no results to show :/

I do have patches on my harddrive somewhere by Izik Eidos that do a
proof of concept for GL passthrough from a windows guest to a
windows/linux client, I could ask him if it's ok to post them if you'd
like. (and if I can find them).

Basically it adds qxl messages for all the GL commands, adds a surface
type, tracks all commands from the last SwapBuffers (I guess
wglSwapBuffers - the equivalent of glXSwapBuffers) per surface, and
passes all of those to the client. Rendering on the server, that is the
host, will be a little simpler.

So (if I got you right and you got me right) we talk about the QXL device
on the KVM guest receiving OpenGL commands and passing them (thru
qemu-kvm) downwards to the OpenGL capable hardware on the KVM Host
(server). The client (spicec or similar) should not be involved at all. Is
there any work in progress (for rendering on the server) - similar to the
RemoteFX project of HyperV?


Cheers Kai


 
 Thanks for enlightenment,
 
 Kai
 
 ___
 Spice-devel mailing list
 Spice-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/spice-devel

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] OpenGL passthrough

2011-11-09 Thread Alon Levy

On Wed, Nov 09, 2011 at 03:57:30PM +, Mosebach  Kai wrote:
 On 11/9/11 3:51 PM, Alon Levy al...@redhat.com wrote:
 
 
 On Wed, Nov 09, 2011 at 01:52:12PM +, Mosebach  Kai wrote:
  Hi guys,
  
  Just a though : 
  
  In a scenario where a kvm-host system has a openGL capable display
  adapter, wouldn't it be possible (and relatively simple compared to a
 full
  VGA passthrough) to just
  pass the OpenGL interface/access into the VMs QXL Adapter making this
 one
  (HW accelerated) OpenGL aware?
 
 There are threads in qemu-devel about using pci passthrough for using
 
 I tried for long time now to pass through PCIe Hardware into the guest
 with all kind of PCIe cards w/o too much off success. So that¹s not what I
 want ;-)
 
 the host GPU from the guest. If you actually want to view the results
 then yes, it's relatively simple in theory. Maybe also in practice, but
 I've been struggling with a slightly larger problem, doing OpenGL and
 Direct3D passthrough, for almost a year now, with no results to show :/
 
 I do have patches on my harddrive somewhere by Izik Eidos that do a
 proof of concept for GL passthrough from a windows guest to a
 windows/linux client, I could ask him if it's ok to post them if you'd
 like. (and if I can find them).
 
 Basically it adds qxl messages for all the GL commands, adds a surface
 type, tracks all commands from the last SwapBuffers (I guess
 wglSwapBuffers - the equivalent of glXSwapBuffers) per surface, and
 passes all of those to the client. Rendering on the server, that is the
 host, will be a little simpler.
 
 So (if I got you right and you got me right) we talk about the QXL device
 on the KVM guest receiving OpenGL commands and passing them (thru
 qemu-kvm) downwards to the OpenGL capable hardware on the KVM Host
 (server). The client (spicec or similar) should not be involved at all. Is
 there any work in progress (for rendering on the server) - similar to the
 RemoteFX project of HyperV?
 

I know I'm working on enabling both server side and client side
rendering, not aware of anyone else.

 
 Cheers Kai
 
 
  
  Thanks for enlightenment,
  
  Kai
  
  ___
  Spice-devel mailing list
  Spice-devel@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/spice-devel
 
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] OpenGL passthrough

2011-11-09 Thread Mosebach Kai

Both would be very helpful :-) And important from a market/competitive
point of view.

Please let me have a look at the patches if possible,

Thanks Kai

On 11/9/11 5:54 PM, Alon Levy al...@redhat.com wrote:

On Wed, Nov 09, 2011 at 03:57:30PM +, Mosebach  Kai wrote:
 On 11/9/11 3:51 PM, Alon Levy al...@redhat.com wrote:
 
 
 On Wed, Nov 09, 2011 at 01:52:12PM +, Mosebach  Kai wrote:
  Hi guys,
  
  Just a though :
  
  In a scenario where a kvm-host system has a openGL capable display
  adapter, wouldn't it be possible (and relatively simple compared to a
 full
  VGA passthrough) to just
  pass the OpenGL interface/access into the VMs QXL Adapter making this
 one
  (HW accelerated) OpenGL aware?
 
 There are threads in qemu-devel about using pci passthrough for using
 
 I tried for long time now to pass through PCIe Hardware into the guest
 with all kind of PCIe cards w/o too much off success. So that¹s not
what I
 want ;-)
 
 the host GPU from the guest. If you actually want to view the results
 then yes, it's relatively simple in theory. Maybe also in practice, but
 I've been struggling with a slightly larger problem, doing OpenGL and
 Direct3D passthrough, for almost a year now, with no results to show :/
 
 I do have patches on my harddrive somewhere by Izik Eidos that do a
 proof of concept for GL passthrough from a windows guest to a
 windows/linux client, I could ask him if it's ok to post them if you'd
 like. (and if I can find them).
 
 Basically it adds qxl messages for all the GL commands, adds a surface
 type, tracks all commands from the last SwapBuffers (I guess
 wglSwapBuffers - the equivalent of glXSwapBuffers) per surface, and
 passes all of those to the client. Rendering on the server, that is the
 host, will be a little simpler.
 
 So (if I got you right and you got me right) we talk about the QXL
device
 on the KVM guest receiving OpenGL commands and passing them (thru
 qemu-kvm) downwards to the OpenGL capable hardware on the KVM Host
 (server). The client (spicec or similar) should not be involved at all.
Is
 there any work in progress (for rendering on the server) - similar to
the
 RemoteFX project of HyperV?
 

I know I'm working on enabling both server side and client side
rendering, not aware of anyone else.

 
 Cheers Kai
 
 
  
  Thanks for enlightenment,
  
  Kai
  
  ___
  Spice-devel mailing list
  Spice-devel@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/spice-devel
 

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] OpenGL passthrough

2011-11-09 Thread Alon Levy

On Wed, Nov 09, 2011 at 04:57:23PM +, Mosebach  Kai wrote:
 Both would be very helpful :-) And important from a market/competitive
 point of view.
 
 Please let me have a look at the patches if possible,
 

I'm so far from that the mere mention of it here was just a result of
asking. It is a thought of a thought.

 Thanks Kai
 
 On 11/9/11 5:54 PM, Alon Levy al...@redhat.com wrote:
 
 On Wed, Nov 09, 2011 at 03:57:30PM +, Mosebach  Kai wrote:
  On 11/9/11 3:51 PM, Alon Levy al...@redhat.com wrote:
  
  
  On Wed, Nov 09, 2011 at 01:52:12PM +, Mosebach  Kai wrote:
   Hi guys,
   
   Just a though :
   
   In a scenario where a kvm-host system has a openGL capable display
   adapter, wouldn't it be possible (and relatively simple compared to a
  full
   VGA passthrough) to just
   pass the OpenGL interface/access into the VMs QXL Adapter making this
  one
   (HW accelerated) OpenGL aware?
  
  There are threads in qemu-devel about using pci passthrough for using
  
  I tried for long time now to pass through PCIe Hardware into the guest
  with all kind of PCIe cards w/o too much off success. So that¹s not
 what I
  want ;-)
  
  the host GPU from the guest. If you actually want to view the results
  then yes, it's relatively simple in theory. Maybe also in practice, but
  I've been struggling with a slightly larger problem, doing OpenGL and
  Direct3D passthrough, for almost a year now, with no results to show :/
  
  I do have patches on my harddrive somewhere by Izik Eidos that do a
  proof of concept for GL passthrough from a windows guest to a
  windows/linux client, I could ask him if it's ok to post them if you'd
  like. (and if I can find them).
  
  Basically it adds qxl messages for all the GL commands, adds a surface
  type, tracks all commands from the last SwapBuffers (I guess
  wglSwapBuffers - the equivalent of glXSwapBuffers) per surface, and
  passes all of those to the client. Rendering on the server, that is the
  host, will be a little simpler.
  
  So (if I got you right and you got me right) we talk about the QXL
 device
  on the KVM guest receiving OpenGL commands and passing them (thru
  qemu-kvm) downwards to the OpenGL capable hardware on the KVM Host
  (server). The client (spicec or similar) should not be involved at all.
 Is
  there any work in progress (for rendering on the server) - similar to
 the
  RemoteFX project of HyperV?
  
 
 I know I'm working on enabling both server side and client side
 rendering, not aware of anyone else.
 
  
  Cheers Kai
  
  
   
   Thanks for enlightenment,
   
   Kai
   
   ___
   Spice-devel mailing list
   Spice-devel@lists.freedesktop.org
   http://lists.freedesktop.org/mailman/listinfo/spice-devel
  
 
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] How do I install vioser in virt-manager?

2011-11-09 Thread Todd And Margo Chester


Hi All,

Scientific Linux 6.2 x64
host: kvm
guest: XP-Pro x32
spice 0.8.x

I give up.  I have Googl'ed my fingers off on this one.  How
do I install the virtio serial device in my guest with virt-manager?

I see serial devices to add, but what type and what is the
path to the device?  Am I even looking at the right serial devices?

Very frustrated and confused,
-T
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] How do I install vioser in virt-manager?

2011-11-09 Thread Alon Levy

On Wed, Nov 09, 2011 at 11:07:57AM -0800, Todd And Margo Chester wrote:
 Hi All,
 
 Scientific Linux 6.2 x64
 host: kvm
 guest: XP-Pro x32
 spice 0.8.x
 
 I give up.  I have Googl'ed my fingers off on this one.  How
 do I install the virtio serial device in my guest with virt-manager?
 
 I see serial devices to add, but what type and what is the
 path to the device?  Am I even looking at the right serial devices?

The serial device should appear in other devices (along with the cpus)
in device manager. There is a link for a driver on the dowload page of
spice:

 http://spice-space.org/download.html

 under Windows binaries:, current link is
 http://spice-space.org/download/binaries/virtio-serial_20110725.zip
 which looks relatively recent.

 I don't remember the upstream location for the drivers, I'll try to
 find it and update, but I think those should be good, let me know if
 they aren't.

Note that this is not the serial device you should also have in the vm,
i.e. COM1, but a different device.

Alon

 
 Very frustrated and confused,
 -T
 ___
 Spice-devel mailing list
 Spice-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/spice-devel
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] OpenGL passthrough

2011-11-09 Thread Yonit Halperin


On 11/09/2011 07:06 PM, Alon Levy wrote:

On Wed, Nov 09, 2011 at 04:57:23PM +, Mosebach  Kai wrote:

Both would be very helpful :-) And important from a market/competitive
point of view.

Please let me have a look at the patches if possible,

Afaik, there is an experimental code for OpenGL hardware acceleration on 
the server side and on the client side as well. Look for #ifdefs 
USE_OPENGL. I think that there were problems with the hw acceleration on 
the server side since the rendering results were different than the ones 
expected for the windows guest.


Yonit.


I'm so far from that the mere mention of it here was just a result of
asking. It is a thought of a thought.


Thanks Kai

On 11/9/11 5:54 PM, Alon Levyal...@redhat.com  wrote:


On Wed, Nov 09, 2011 at 03:57:30PM +, Mosebach  Kai wrote:

On 11/9/11 3:51 PM, Alon Levyal...@redhat.com  wrote:



On Wed, Nov 09, 2011 at 01:52:12PM +, Mosebach  Kai wrote:

Hi guys,

Just a though :

In a scenario where a kvm-host system has a openGL capable display
adapter, wouldn't it be possible (and relatively simple compared to a
full
VGA passthrough) to just
pass the OpenGL interface/access into the VMs QXL Adapter making this
one
(HW accelerated) OpenGL aware?


There are threads in qemu-devel about using pci passthrough for using


I tried for long time now to pass through PCIe Hardware into the guest
with all kind of PCIe cards w/o too much off success. So that¹s not
what I
want ;-)


the host GPU from the guest. If you actually want to view the results
then yes, it's relatively simple in theory. Maybe also in practice, but
I've been struggling with a slightly larger problem, doing OpenGL and
Direct3D passthrough, for almost a year now, with no results to show :/

I do have patches on my harddrive somewhere by Izik Eidos that do a
proof of concept for GL passthrough from a windows guest to a
windows/linux client, I could ask him if it's ok to post them if you'd
like. (and if I can find them).

Basically it adds qxl messages for all the GL commands, adds a surface
type, tracks all commands from the last SwapBuffers (I guess
wglSwapBuffers - the equivalent of glXSwapBuffers) per surface, and
passes all of those to the client. Rendering on the server, that is the
host, will be a little simpler.


So (if I got you right and you got me right) we talk about the QXL
device
on the KVM guest receiving OpenGL commands and passing them (thru
qemu-kvm) downwards to the OpenGL capable hardware on the KVM Host
(server). The client (spicec or similar) should not be involved at all.
Is
there any work in progress (for rendering on the server) - similar to
the
RemoteFX project of HyperV?



I know I'm working on enabling both server side and client side
rendering, not aware of anyone else.



Cheers Kai





Thanks for enlightenment,

Kai

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel





___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel


___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] 0.10 release - what's pending?

[Spice-devel] OpenGL passthrough

Re: [Spice-devel] OpenGL passthrough

[Spice-devel] [PATCH] support _ASYNC io calls and interrupt handling (busy wait)

[Spice-devel] About spice-xpi firefox version Compatiblity

Re: [Spice-devel] [PATCH] support _ASYNC io calls and interrupt handling (busy wait)

Re: [Spice-devel] OpenGL passthrough

Re: [Spice-devel] OpenGL passthrough

Re: [Spice-devel] OpenGL passthrough

Re: [Spice-devel] OpenGL passthrough

[Spice-devel] How do I install vioser in virt-manager?

Re: [Spice-devel] How do I install vioser in virt-manager?

Re: [Spice-devel] OpenGL passthrough

13 matches

Site Navigation

Mail list logo

Footer information