[Mesa-dev] [PATCH] winsys/svga: use new ioctl for logging

2020-01-21 Thread VMware
From: Roland Scheidegger 

Use the new ioctl for logging (rather than duplicating what the kernel
is doing). This way it's also independent from the actual guest/host
mechanism to do the logging.

Signed-off-by: Roland Scheidegger 
Reviewed-by: Thomas Hellstrom 
---
 src/gallium/winsys/svga/drm/vmw_msg.c | 22 ---
 src/gallium/winsys/svga/drm/vmw_screen.h  |  2 ++
 .../winsys/svga/drm/vmw_screen_ioctl.c|  7 +++---
 src/gallium/winsys/svga/drm/vmwgfx_drm.h  | 17 ++
 4 files changed, 42 insertions(+), 6 deletions(-)

diff --git a/src/gallium/winsys/svga/drm/vmw_msg.c 
b/src/gallium/winsys/svga/drm/vmw_msg.c
index 2a2d6a61297..e664769c279 100644
--- a/src/gallium/winsys/svga/drm/vmw_msg.c
+++ b/src/gallium/winsys/svga/drm/vmw_msg.c
@@ -31,6 +31,9 @@
 #include "pipe/p_defines.h"
 #include "svga_winsys.h"
 #include "vmw_msg.h"
+#include "vmwgfx_drm.h"
+#include "vmw_screen.h"
+#include "xf86drm.h"
 
 
 #define MESSAGE_STATUS_SUCCESS  0x0001
@@ -424,6 +427,7 @@ void
 vmw_svga_winsys_host_log(struct svga_winsys_screen *sws, const char *log)
 {
struct rpc_channel channel;
+   struct vmw_winsys_screen *vws = vmw_winsys_screen(sws);
char *msg;
int msg_len;
int ret;
@@ -444,9 +448,21 @@ vmw_svga_winsys_host_log(struct svga_winsys_screen *sws, 
const char *log)
 
sprintf(msg, "log %s", log);
 
-   if (!(ret = vmw_open_channel(&channel, RPCI_PROTOCOL_NUM))) {
-  ret = vmw_send_msg(&channel, msg);
-  vmw_close_channel(&channel);
+   if (vws->ioctl.have_drm_2_17) {
+  struct drm_vmw_msg_arg msg_arg;
+
+  memset(&msg_arg, 0, sizeof(msg_arg));
+  msg_arg.send = (uint64_t) (unsigned long) (msg);
+  msg_arg.send_only = 1;
+
+  ret = drmCommandWriteRead(vws->ioctl.drm_fd, DRM_VMW_MSG,
+&msg_arg, sizeof(msg_arg));
+
+   } else {
+  if (!(ret = vmw_open_channel(&channel, RPCI_PROTOCOL_NUM))) {
+ ret = vmw_send_msg(&channel, msg);
+ vmw_close_channel(&channel);
+  }
}
 
if (ret)
diff --git a/src/gallium/winsys/svga/drm/vmw_screen.h 
b/src/gallium/winsys/svga/drm/vmw_screen.h
index e0b1bb33bc4..c55de4a2b6f 100644
--- a/src/gallium/winsys/svga/drm/vmw_screen.h
+++ b/src/gallium/winsys/svga/drm/vmw_screen.h
@@ -78,6 +78,8 @@ struct vmw_winsys_screen
   boolean have_drm_2_9;
   uint32_t drm_execbuf_version;
   boolean have_drm_2_15;
+  boolean have_drm_2_16;
+  boolean have_drm_2_17;
} ioctl;
 
struct {
diff --git a/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c 
b/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c
index 2e84c811e82..4ce953fee8d 100644
--- a/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c
+++ b/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c
@@ -973,7 +973,6 @@ vmw_ioctl_init(struct vmw_winsys_screen *vws)
drmVersionPtr version;
boolean drm_gb_capable;
boolean have_drm_2_5;
-   boolean have_drm_2_16;
const char *getenv_val;
 
VMW_FUNC;
@@ -990,8 +989,10 @@ vmw_ioctl_init(struct vmw_winsys_screen *vws)
   (version->version_major == 2 && version->version_minor > 8);
vws->ioctl.have_drm_2_15 = version->version_major > 2 ||
   (version->version_major == 2 && version->version_minor > 14);
-   have_drm_2_16 = version->version_major > 2 ||
+   vws->ioctl.have_drm_2_16 = version->version_major > 2 ||
   (version->version_major == 2 && version->version_minor > 15);
+   vws->ioctl.have_drm_2_17 = version->version_major > 2 ||
+  (version->version_major == 2 && version->version_minor > 16);
 
vws->ioctl.drm_execbuf_version = vws->ioctl.have_drm_2_9 ? 2 : 1;
 
@@ -1116,7 +1117,7 @@ vmw_ioctl_init(struct vmw_winsys_screen *vws)
   else
  vws->ioctl.num_cap_3d = SVGA3D_DEVCAP_MAX;
 
-  if (have_drm_2_16) {
+  if (vws->ioctl.have_drm_2_16) {
  vws->base.have_coherent = TRUE;
  getenv_val = getenv("SVGA_FORCE_COHERENT");
  if (getenv_val && strcmp(getenv_val, "0") != 0)
diff --git a/src/gallium/winsys/svga/drm/vmwgfx_drm.h 
b/src/gallium/winsys/svga/drm/vmwgfx_drm.h
index 02cab33f2f2..fcb741e3068 100644
--- a/src/gallium/winsys/svga/drm/vmwgfx_drm.h
+++ b/src/gallium/winsys/svga/drm/vmwgfx_drm.h
@@ -71,6 +71,7 @@ extern "C" {
 #define DRM_VMW_CREATE_EXTENDED_CONTEXT 26
 #define DRM_VMW_GB_SURFACE_CREATE_EXT   27
 #define DRM_VMW_GB_SURFACE_REF_EXT  28
+#define DRM_VMW_MSG 29
 
 /*/
 /**
@@ -1213,6 +1214,22 @@ union drm_vmw_gb_surface_reference_ext_arg {
struct drm_vmw_surface_arg req;
 };
 
+/**
+ * struct drm_vmw_msg_arg
+ *
+ * @send: Pointer to user-space msg string (null terminated).
+ * @receive: Pointer to user-space receive buffer.
+ * @send_only: Boolean whether this is only sending or receiving too.
+ *
+ * Argument to the DRM_VMW_MSG ioctl.
+ */
+struct drm_vmw_msg_arg {
+   __u64 send;
+   __u64 receive;
+   __s32 send_only;
+   __u32 

Re: [Mesa-dev] -fno-common build failures (default from upcoming gcc release 10)

2020-01-21 Thread Bas Nieuwenhuizen
I think this ended up spawning a bunch of work in
https://gitlab.freedesktop.org/mesa/mesa/issues/2385

On Mon, Jan 20, 2020 at 3:41 PM Stefan Dirsch  wrote:
>
> Hi
>
> Starting from the upcoming GCC release 10, the default of -fcommon option will
> change to -fno-common. Due to this we're going to see a lot of build failures
> in Mesa drivers like
>
> multiple definition of `syncobj_handle'; 
> src/amd/vulkan/9198681@@vulkan_radeon@sha/meson-generated_.._radv_entrypoints.c.o
>  (symbol from plugin):(.text+0x0): first defined here
> [  213s]
> /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld:
> src/amd/vulkan/9198681@@vulkan_radeon@sha/radv_wsi_wayland.c.o (symbol from
> plugin): in function `radv_GetPhysicalDeviceWaylandPresentationSupportKHR':
>
> I'm wondering if there is already anybody working on fixing these issues or is
> it recommended to workaround it by setting -fcommon manually somehow? How can
> the latter be done when using meson/ninja as build tool?
>
> Thanks,
> Stefan
>
> Public Key available
> --
> Stefan Dirsch (Res. & Dev.)   SUSE Software Solutions Germany GmbH
> Tel: 0911-740 53 0Maxfeldstraße 5
> FAX: 0911-740 53 479  D-90409 Nürnberg
> http://www.suse.deGermany
> 
> (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] -fno-common build failures (default from upcoming gcc release 10)

2020-01-21 Thread Ian Romanick
On 1/20/20 6:41 AM, Stefan Dirsch wrote:
> Hi
> 
> Starting from the upcoming GCC release 10, the default of -fcommon option will
> change to -fno-common. Due to this we're going to see a lot of build failures

It seems like many of the places where this would occur in Mesa are
likely to be fine... but it would be easy enough to fix by sprinkling
'extern' around (if my understanding of the GCC docs is correct).  It
also seems unlikely that GCC will be able to apply any hypothetical
optimizations to the uses in Mesa.  I think most places where a global
is intended to be isolated, we already decorate it with static.

See also
https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#index-fcommon

We definitely should decide which behavior we want, and we should start
enforcing it sooner rather than later.

> in Mesa drivers like
> 
> multiple definition of `syncobj_handle'; 
> src/amd/vulkan/9198681@@vulkan_radeon@sha/meson-generated_.._radv_entrypoints.c.o
>  (symbol from plugin):(.text+0x0): first defined here
> [  213s]
> /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld:
> src/amd/vulkan/9198681@@vulkan_radeon@sha/radv_wsi_wayland.c.o (symbol from
> plugin): in function `radv_GetPhysicalDeviceWaylandPresentationSupportKHR':
> 
> I'm wondering if there is already anybody working on fixing these issues or is
> it recommended to workaround it by setting -fcommon manually somehow? How can
> the latter be done when using meson/ninja as build tool?

I know you can do it with buildtype=plain, but that may be overkill for
anything other than testing.

> Thanks,
> Stefan
> 
> Public Key available
> --
> Stefan Dirsch (Res. & Dev.)   SUSE Software Solutions Germany GmbH
> Tel: 0911-740 53 0Maxfeldstraße 5
> FAX: 0911-740 53 479  D-90409 Nürnberg
> http://www.suse.deGermany 
> 
> (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev