[Mesa-dev] [PATCH 1/2] st/va: implement VaDeriveImage

2015-10-29 Thread Julien Isorce
And apply relatives change to:
vlVaBufferSetNumElements
vlVaCreateBuffer
vlVaMapBuffer
vlVaUnmapBuffer
vlVaDestroyBuffer
vlVaPutImage

It is unfortunate that there is no proper va buffer type and struct
for this. Only possible to use VAImageBufferType which is normally
used for normal user data array.
On of the consequences is that it is only possible VaDeriveImage
is only useful on surfaces backed with contiguous planes.
Implementation inspired from cgit.freedesktop.org/vaapi/intel-driver

Signed-off-by: Julien Isorce 
---
 src/gallium/state_trackers/va/buffer.c | 47 +--
 src/gallium/state_trackers/va/image.c  | 92 +-
 src/gallium/state_trackers/va/va_private.h |  5 ++
 3 files changed, 138 insertions(+), 6 deletions(-)

diff --git a/src/gallium/state_trackers/va/buffer.c 
b/src/gallium/state_trackers/va/buffer.c
index 8f9ba44..b619d0b 100644
--- a/src/gallium/state_trackers/va/buffer.c
+++ b/src/gallium/state_trackers/va/buffer.c
@@ -26,8 +26,11 @@
  *
  **/
 
+#include "pipe/p_screen.h"
 #include "util/u_memory.h"
 #include "util/u_handle_table.h"
+#include "util/u_transfer.h"
+#include "vl/vl_winsys.h"
 
 #include "va_private.h"
 
@@ -73,6 +76,10 @@ vlVaBufferSetNumElements(VADriverContextP ctx, VABufferID 
buf_id,
   return VA_STATUS_ERROR_INVALID_CONTEXT;
 
buf = handle_table_get(VL_VA_DRIVER(ctx)->htab, buf_id);
+
+   if (!buf || buf->derived_surface.resource)
+  return VA_STATUS_ERROR_INVALID_BUFFER;
+
buf->data = REALLOC(buf->data, buf->size * buf->num_elements,
buf->size * num_elements);
buf->num_elements = num_elements;
@@ -86,16 +93,32 @@ vlVaBufferSetNumElements(VADriverContextP ctx, VABufferID 
buf_id,
 VAStatus
 vlVaMapBuffer(VADriverContextP ctx, VABufferID buf_id, void **pbuff)
 {
+   vlVaDriver *drv;
vlVaBuffer *buf;
 
if (!ctx)
   return VA_STATUS_ERROR_INVALID_CONTEXT;
 
-   buf = handle_table_get(VL_VA_DRIVER(ctx)->htab, buf_id);
+   if (!pbuff)
+  return VA_STATUS_ERROR_INVALID_BUFFER;
+
+   drv = VL_VA_DRIVER(ctx);
+
+   buf = handle_table_get(drv->htab, buf_id);
if (!buf)
   return VA_STATUS_ERROR_INVALID_BUFFER;
 
-   *pbuff = buf->data;
+   if (buf->derived_surface.resource) {
+  *pbuff = pipe_buffer_map(drv->pipe, buf->derived_surface.resource,
+   PIPE_TRANSFER_WRITE,
+   >derived_surface.transfer);
+
+  if (!buf->derived_surface.transfer || !*pbuff)
+ return VA_STATUS_ERROR_INVALID_BUFFER;
+
+   } else {
+  *pbuff = buf->data;
+   }
 
return VA_STATUS_SUCCESS;
 }
@@ -103,16 +126,25 @@ vlVaMapBuffer(VADriverContextP ctx, VABufferID buf_id, 
void **pbuff)
 VAStatus
 vlVaUnmapBuffer(VADriverContextP ctx, VABufferID buf_id)
 {
+   vlVaDriver *drv;
vlVaBuffer *buf;
 
if (!ctx)
   return VA_STATUS_ERROR_INVALID_CONTEXT;
 
-   buf = handle_table_get(VL_VA_DRIVER(ctx)->htab, buf_id);
+   drv = VL_VA_DRIVER(ctx);
+
+   buf = handle_table_get(drv->htab, buf_id);
if (!buf)
   return VA_STATUS_ERROR_INVALID_BUFFER;
 
-   /* Nothing to do here */
+   if (buf->derived_surface.resource) {
+ if (!buf->derived_surface.transfer)
+return VA_STATUS_ERROR_INVALID_BUFFER;
+
+ pipe_buffer_unmap(drv->pipe, buf->derived_surface.transfer);
+ buf->derived_surface.transfer = NULL;
+   }
 
return VA_STATUS_SUCCESS;
 }
@@ -129,7 +161,12 @@ vlVaDestroyBuffer(VADriverContextP ctx, VABufferID buf_id)
if (!buf)
   return VA_STATUS_ERROR_INVALID_BUFFER;
 
-   FREE(buf->data);
+   if (buf->data)
+ FREE(buf->data);
+
+   if (buf->derived_surface.resource)
+ pipe_resource_reference(>derived_surface.resource, NULL);
+
FREE(buf);
handle_table_remove(VL_VA_DRIVER(ctx)->htab, buf_id);
 
diff --git a/src/gallium/state_trackers/va/image.c 
b/src/gallium/state_trackers/va/image.c
index 8e64673..f266ce8 100644
--- a/src/gallium/state_trackers/va/image.c
+++ b/src/gallium/state_trackers/va/image.c
@@ -184,10 +184,95 @@ vlVaCreateImage(VADriverContextP ctx, VAImageFormat 
*format, int width, int heig
 VAStatus
 vlVaDeriveImage(VADriverContextP ctx, VASurfaceID surface, VAImage *image)
 {
+   vlVaDriver *drv;
+   vlVaSurface *surf;
+   vlVaBuffer *img_buf;
+   VAImage *img;
+   struct pipe_surface **surfaces;
+   int w;
+   int h;
+   int i;
+
if (!ctx)
   return VA_STATUS_ERROR_INVALID_CONTEXT;
 
-   return VA_STATUS_ERROR_UNIMPLEMENTED;
+   drv = VL_VA_DRIVER(ctx);
+
+   if (!drv)
+  return VA_STATUS_ERROR_INVALID_CONTEXT;
+
+   surf = handle_table_get(drv->htab, surface);
+
+   if (!surf || !surf->buffer || surf->buffer->interlaced)
+  return VA_STATUS_ERROR_INVALID_SURFACE;
+
+   surfaces = surf->buffer->get_surfaces(surf->buffer);
+   if (!surfaces || !surfaces[0]->texture)
+  return VA_STATUS_ERROR_ALLOCATION_FAILED;
+
+   img = CALLOC(1, 

[Mesa-dev] [PATCH 2/2] st/va: add support to export a surface as dmabuf

2015-10-29 Thread Julien Isorce
I.e. implements:
VaAcquireBufferHandle
VaReleaseBufferHandle
for memory of type VA_SURFACE_ATTRIB_MEM_TYPE_DRM_PRIME

And apply relatives change to:
vlVaMapBuffer
vlVaUnMapBuffer
vlVaDestroyBuffer

Implementation inspired from cgit.freedesktop.org/vaapi/intel-driver

Tested with gstreamer-vaapi with nouveau driver.

Signed-off-by: Julien Isorce 
---
 src/gallium/state_trackers/va/buffer.c | 136 -
 src/gallium/state_trackers/va/context.c|   4 +-
 src/gallium/state_trackers/va/va_private.h |   6 ++
 3 files changed, 144 insertions(+), 2 deletions(-)

diff --git a/src/gallium/state_trackers/va/buffer.c 
b/src/gallium/state_trackers/va/buffer.c
index b619d0b..4ad20d2 100644
--- a/src/gallium/state_trackers/va/buffer.c
+++ b/src/gallium/state_trackers/va/buffer.c
@@ -27,6 +27,7 @@
  **/
 
 #include "pipe/p_screen.h"
+#include "state_tracker/drm_driver.h"
 #include "util/u_memory.h"
 #include "util/u_handle_table.h"
 #include "util/u_transfer.h"
@@ -108,6 +109,9 @@ vlVaMapBuffer(VADriverContextP ctx, VABufferID buf_id, void 
**pbuff)
if (!buf)
   return VA_STATUS_ERROR_INVALID_BUFFER;
 
+   if (buf->export_refcount > 0)
+  return VA_STATUS_ERROR_INVALID_BUFFER;
+
if (buf->derived_surface.resource) {
   *pbuff = pipe_buffer_map(drv->pipe, buf->derived_surface.resource,
PIPE_TRANSFER_WRITE,
@@ -138,6 +142,9 @@ vlVaUnmapBuffer(VADriverContextP ctx, VABufferID buf_id)
if (!buf)
   return VA_STATUS_ERROR_INVALID_BUFFER;
 
+   if (buf->export_refcount > 0)
+  return VA_STATUS_ERROR_INVALID_BUFFER;
+
if (buf->derived_surface.resource) {
  if (!buf->derived_surface.transfer)
 return VA_STATUS_ERROR_INVALID_BUFFER;
@@ -164,8 +171,12 @@ vlVaDestroyBuffer(VADriverContextP ctx, VABufferID buf_id)
if (buf->data)
  FREE(buf->data);
 
-   if (buf->derived_surface.resource)
+   if (buf->derived_surface.resource) {
+ if (buf->export_refcount > 0)
+   return VA_STATUS_ERROR_INVALID_BUFFER;
+
  pipe_resource_reference(>derived_surface.resource, NULL);
+   }
 
FREE(buf);
handle_table_remove(VL_VA_DRIVER(ctx)->htab, buf_id);
@@ -192,3 +203,126 @@ vlVaBufferInfo(VADriverContextP ctx, VABufferID buf_id, 
VABufferType *type,
 
return VA_STATUS_SUCCESS;
 }
+
+VAStatus
+vlVaAcquireBufferHandle(VADriverContextP ctx, VABufferID buf_id,
+VABufferInfo *out_buf_info)
+{
+   uint32_t i;
+   uint32_t mem_type;
+   vlVaBuffer *buf ;
+   struct pipe_screen *screen;
+
+   /* List of supported memory types, in preferred order. */
+   static const uint32_t mem_types[] = {
+  VA_SURFACE_ATTRIB_MEM_TYPE_DRM_PRIME,
+  0
+   };
+
+   if (!ctx)
+  return VA_STATUS_ERROR_INVALID_CONTEXT;
+
+   buf = handle_table_get(VL_VA_DRIVER(ctx)->htab, buf_id);
+
+   if (!buf)
+  return VA_STATUS_ERROR_INVALID_BUFFER;
+
+   /* Only VA surface|image like buffers are supported for now .*/
+   if (buf->type != VAImageBufferType)
+  return VA_STATUS_ERROR_UNSUPPORTED_BUFFERTYPE;
+
+   if (!out_buf_info)
+  return VA_STATUS_ERROR_INVALID_PARAMETER;
+
+   if (!out_buf_info->mem_type)
+  mem_type = mem_types[0];
+   else {
+  mem_type = 0;
+  for (i = 0; mem_types[i] != 0; i++) {
+ if (out_buf_info->mem_type & mem_types[i]) {
+mem_type = out_buf_info->mem_type;
+break;
+ }
+  }
+  if (!mem_type)
+ return VA_STATUS_ERROR_UNSUPPORTED_MEMORY_TYPE;
+   }
+
+   if (!buf->derived_surface.resource)
+  return VA_STATUS_ERROR_INVALID_BUFFER;
+
+   screen = VL_VA_PSCREEN(ctx);
+
+   if (buf->derived_surface.fence) {
+  screen->fence_finish(screen, buf->derived_surface.fence, 
PIPE_TIMEOUT_INFINITE);
+  screen->fence_reference(screen, >derived_surface.fence, NULL);
+   }
+
+   if (buf->export_refcount > 0) {
+  if (buf->export_state.mem_type != mem_type)
+ return VA_STATUS_ERROR_INVALID_PARAMETER;
+   } else {
+  VABufferInfo * const buf_info = >export_state;
+
+  switch (mem_type) {
+  case VA_SURFACE_ATTRIB_MEM_TYPE_DRM_PRIME: {
+ struct winsys_handle whandle;
+
+ memset(, 0, sizeof(whandle));
+ whandle.type = DRM_API_HANDLE_TYPE_FD;
+
+ if (!screen->resource_get_handle(screen, 
buf->derived_surface.resource, ))
+return VA_STATUS_ERROR_INVALID_BUFFER;
+
+ buf_info->handle = (intptr_t)whandle.handle;
+ break;
+  default:
+ return VA_STATUS_ERROR_UNSUPPORTED_MEMORY_TYPE;
+  }
+   }
+
+   buf_info->type = buf->type;
+   buf_info->mem_type = mem_type;
+   buf_info->mem_size = buf->num_elements * buf->size;
+
+   }
+
+   buf->export_refcount++;
+
+   *out_buf_info = buf->export_state;
+
+   return VA_STATUS_SUCCESS;
+}
+
+VAStatus
+vlVaReleaseBufferHandle(VADriverContextP ctx, VABufferID buf_id)
+{
+   vlVaBuffer *buf;
+
+   

[Mesa-dev] [PATCH 0/2] vaapi: add support for dmabuf export

2015-10-29 Thread Julien Isorce
This 2 patches allow to derive a va surface as a va image.
Which one can be exported as dmabuf by calling VaAcquireBufferHandle.

I have tested these patches with gstreamer-vaapi and nouveau driver.
The pipeline looks like:

gstvaapidecode:(vasurface, NV12) -> gstvaapipostproc:(dmabuf, RGBA) -> 
glimagesink(EGL_EXT_image_dma_buf_import) 

I even went further by doing export and import in separate processes,
i.e. exporting the surface in a process A, and importing in an EGLImage in a 
process B.

The concrete use case is the GStreamer backend for the Chromium browser:
https://github.com/Samsung/ChromiumGStreamerBackend

The VA surface is exported as dmabuf in the new Media Process.
Then this dmabuf is imported into an EGLImage in the GPU Process. 

Julien Isorce (2):
  st/va: implement VaDeriveImage
  st/va: add support to export a surface as dmabuf

 src/gallium/state_trackers/va/buffer.c | 181 -
 src/gallium/state_trackers/va/context.c|   4 +-
 src/gallium/state_trackers/va/image.c  |  92 ++-
 src/gallium/state_trackers/va/va_private.h |  11 ++
 4 files changed, 281 insertions(+), 7 deletions(-)

-- 
1.9.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v2 07/13] st/va: add headless support, i.e. VA_DISPLAY_DRM

2015-10-29 Thread Christian König



+  drm_info = (struct drm_state *) ctx->drm_state;
+  if (!drm_info) {
+ FREE(drv);
+ return VA_STATUS_ERROR_INVALID_PARAMETER;
+  }
+
+#if GALLIUM_STATIC_TARGETS
+  drm_fd = drm_info->fd;
+#else
+  drm_fd = dup(drm_info->fd);
+#endif
+
+  if (drm_fd < 0) {
+ FREE(drv);
+ return VA_STATUS_ERROR_INVALID_PARAMETER;
+  }
+
+  drv->vscreen = CALLOC_STRUCT(vl_screen);
+  if (!drv->vscreen)
+ goto error_screen;
+
+#if GALLIUM_STATIC_TARGETS
+  drv->vscreen->pscreen = dd_create_screen(drm_fd);
+#else
+  if (pipe_loader_drm_probe_fd(>dev, drm_fd))
+ drv->vscreen->pscreen = pipe_loader_create_screen(drv->dev, 
PIPE_SEARCH_DIR);
+#endif
+
+  if (!drv->vscreen->pscreen)
+ goto error_pipe;
+
+  }


It would be nice to have this snip-set in something like a 
vl_winsys_drm.c if possible, but that's not a hard requirement and can 
happen when we actually need this elsewhere as well.


Emil any further comments? Did you static target cleanup already land? I 
would like to get at least quite a bunch of the patches upstream sooner 
than later.


Regards,
Christian.

On 28.10.2015 15:22, Julien Isorce wrote:

This patch allows to use gallium vaapi without requiring
a X server running for your second graphic card.

Signed-off-by: Julien Isorce 
---
  src/gallium/state_trackers/va/Makefile.am |  9 
  src/gallium/state_trackers/va/context.c   | 70 ---
  2 files changed, 73 insertions(+), 6 deletions(-)

diff --git a/src/gallium/state_trackers/va/Makefile.am 
b/src/gallium/state_trackers/va/Makefile.am
index 2a93a90..348cfe1 100644
--- a/src/gallium/state_trackers/va/Makefile.am
+++ b/src/gallium/state_trackers/va/Makefile.am
@@ -30,6 +30,15 @@ AM_CFLAGS = \
$(VA_CFLAGS) \
-DVA_DRIVER_INIT_FUNC="__vaDriverInit_$(VA_MAJOR)_$(VA_MINOR)"
  
+AM_CFLAGS += \

+   $(GALLIUM_PIPE_LOADER_DEFINES) \
+   -DPIPE_SEARCH_DIR=\"$(libdir)/gallium-pipe\"
+
+if HAVE_GALLIUM_STATIC_TARGETS
+AM_CFLAGS += \
+   -DGALLIUM_STATIC_TARGETS=1
+endif
+
  AM_CPPFLAGS = \
-I$(top_srcdir)/include
  
diff --git a/src/gallium/state_trackers/va/context.c b/src/gallium/state_trackers/va/context.c

index 7ff5dcd..c70120e 100644
--- a/src/gallium/state_trackers/va/context.c
+++ b/src/gallium/state_trackers/va/context.c
@@ -28,7 +28,8 @@
  
  #include "pipe/p_screen.h"

  #include "pipe/p_video_codec.h"
-
+#include "pipe-loader/pipe_loader.h"
+#include "state_tracker/drm_driver.h"
  #include "util/u_memory.h"
  #include "util/u_handle_table.h"
  #include "util/u_video.h"
@@ -36,6 +37,8 @@
  
  #include "va_private.h"
  
+#include 

+
  static struct VADriverVTable vtable =
  {
 ,
@@ -99,6 +102,8 @@ PUBLIC VAStatus
  VA_DRIVER_INIT_FUNC(VADriverContextP ctx)
  {
 vlVaDriver *drv;
+   int drm_fd;
+   struct drm_state *drm_info;
  
 if (!ctx)

return VA_STATUS_ERROR_INVALID_CONTEXT;
@@ -107,9 +112,56 @@ VA_DRIVER_INIT_FUNC(VADriverContextP ctx)
 if (!drv)
return VA_STATUS_ERROR_ALLOCATION_FAILED;
  
-   drv->vscreen = vl_screen_create(ctx->native_dpy, ctx->x11_screen);

-   if (!drv->vscreen)
-  goto error_screen;
+   switch (ctx->display_type) {
+   case VA_DISPLAY_ANDROID:
+   case VA_DISPLAY_WAYLAND:
+  FREE(drv);
+  return VA_STATUS_ERROR_UNIMPLEMENTED;
+   case VA_DISPLAY_GLX:
+   case VA_DISPLAY_X11:
+  drv->vscreen = vl_screen_create(ctx->native_dpy, ctx->x11_screen);
+  if (!drv->vscreen)
+ goto error_screen;
+  break;
+   case VA_DISPLAY_DRM:
+   case VA_DISPLAY_DRM_RENDERNODES: {
+  drm_info = (struct drm_state *) ctx->drm_state;
+  if (!drm_info) {
+ FREE(drv);
+ return VA_STATUS_ERROR_INVALID_PARAMETER;
+  }
+
+#if GALLIUM_STATIC_TARGETS
+  drm_fd = drm_info->fd;
+#else
+  drm_fd = dup(drm_info->fd);
+#endif
+
+  if (drm_fd < 0) {
+ FREE(drv);
+ return VA_STATUS_ERROR_INVALID_PARAMETER;
+  }
+
+  drv->vscreen = CALLOC_STRUCT(vl_screen);
+  if (!drv->vscreen)
+ goto error_screen;
+
+#if GALLIUM_STATIC_TARGETS
+  drv->vscreen->pscreen = dd_create_screen(drm_fd);
+#else
+  if (pipe_loader_drm_probe_fd(>dev, drm_fd))
+ drv->vscreen->pscreen = pipe_loader_create_screen(drv->dev, 
PIPE_SEARCH_DIR);
+#endif
+
+  if (!drv->vscreen->pscreen)
+ goto error_pipe;
+
+  }
+  break;
+   default:
+  FREE(drv);
+  return VA_STATUS_ERROR_INVALID_DISPLAY;
+   }
  
 drv->pipe = drv->vscreen->pscreen->context_create(drv->vscreen->pscreen,

   drv->vscreen, 0);
@@ -145,7 +197,10 @@ error_htab:
 drv->pipe->destroy(drv->pipe);
  
  error_pipe:

-   vl_screen_destroy(drv->vscreen);
+   if (ctx->display_type == VA_DISPLAY_GLX || ctx->display_type == 
VA_DISPLAY_X11)
+  vl_screen_destroy(drv->vscreen);
+   else
+  FREE(drv->vscreen);
  

Re: [Mesa-dev] [PATCH v2 6/8] st/va: handle Video Post Processing for configs

2015-10-29 Thread Christian König

On 22.10.2015 18:37, Julien Isorce wrote:

Add support for VA_PROFILE_NONE and VAEntrypointVideoProc
in the 4 following functions:

vlVaQueryConfigProfiles
vlVaQueryConfigEntrypoints
vlVaCreateConfig
vlVaQueryConfigAttributes

Signed-off-by: Julien Isorce 


Reviewed-by: Christian König 


---
  src/gallium/state_trackers/va/config.c | 20 
  src/gallium/state_trackers/va/va_private.h |  5 -
  2 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/va/config.c 
b/src/gallium/state_trackers/va/config.c
index cfb0b25..bde6615 100644
--- a/src/gallium/state_trackers/va/config.c
+++ b/src/gallium/state_trackers/va/config.c
@@ -52,6 +52,9 @@ vlVaQueryConfigProfiles(VADriverContextP ctx, VAProfile 
*profile_list, int *num_
  profile_list[(*num_profiles)++] = vap;
}
  
+   /* Support postprocessing through vl_compositor */

+   profile_list[(*num_profiles)++] = VAProfileNone;
+
 return VA_STATUS_SUCCESS;
  }
  
@@ -67,6 +70,11 @@ vlVaQueryConfigEntrypoints(VADriverContextP ctx, VAProfile profile,
  
 *num_entrypoints = 0;
  
+   if (profile == VAProfileNone) {

+   entrypoint_list[(*num_entrypoints)++] = VAEntrypointVideoProc;
+   return VA_STATUS_SUCCESS;
+   }
+
 p = ProfileToPipe(profile);
 if (p == PIPE_VIDEO_PROFILE_UNKNOWN)
return VA_STATUS_ERROR_UNSUPPORTED_PROFILE;
@@ -118,6 +126,11 @@ vlVaCreateConfig(VADriverContextP ctx, VAProfile profile, 
VAEntrypoint entrypoin
 if (!ctx)
return VA_STATUS_ERROR_INVALID_CONTEXT;
  
+   if (profile == VAProfileNone && entrypoint == VAEntrypointVideoProc) {

+   *config_id = PIPE_VIDEO_PROFILE_UNKNOWN;
+   return VA_STATUS_SUCCESS;
+   }
+
 p = ProfileToPipe(profile);
 if (p == PIPE_VIDEO_PROFILE_UNKNOWN)
return VA_STATUS_ERROR_UNSUPPORTED_PROFILE;
@@ -151,6 +164,13 @@ vlVaQueryConfigAttributes(VADriverContextP ctx, VAConfigID 
config_id, VAProfile
return VA_STATUS_ERROR_INVALID_CONTEXT;
  
 *profile = PipeToProfile(config_id);

+
+   if (config_id == PIPE_VIDEO_PROFILE_UNKNOWN) {
+  *entrypoint = VAEntrypointVideoProc;
+   *num_attribs = 0;
+  return VA_STATUS_SUCCESS;
+   }
+
 *entrypoint = VAEntrypointVLD;
  
 *num_attribs = 1;

diff --git a/src/gallium/state_trackers/va/va_private.h 
b/src/gallium/state_trackers/va/va_private.h
index c0287e7..770c7dd 100644
--- a/src/gallium/state_trackers/va/va_private.h
+++ b/src/gallium/state_trackers/va/va_private.h
@@ -147,7 +147,8 @@ PipeToProfile(enum pipe_video_profile profile)
 case PIPE_VIDEO_PROFILE_MPEG4_AVC_HIGH:
return VAProfileH264High;
 case PIPE_VIDEO_PROFILE_MPEG4_AVC_EXTENDED:
-   return VAProfileNone;
+   case PIPE_VIDEO_PROFILE_UNKNOWN:
+  return VAProfileNone;
 default:
assert(0);
return -1;
@@ -178,6 +179,8 @@ ProfileToPipe(VAProfile profile)
return PIPE_VIDEO_PROFILE_MPEG4_AVC_MAIN;
 case VAProfileH264High:
return PIPE_VIDEO_PROFILE_MPEG4_AVC_HIGH;
+   case VAProfileNone:
+   return PIPE_VIDEO_PROFILE_UNKNOWN;
 default:
return PIPE_VIDEO_PROFILE_UNKNOWN;
 }


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 02/15] virgl: rename virgl.h to virgl_screen.h

2015-10-29 Thread Emil Velikov
Provide a more meaningful name considering it's purpose.

Signed-off-by: Emil Velikov 
---
 src/gallium/drivers/virgl/Makefile.sources |  2 +-
 src/gallium/drivers/virgl/virgl.h  | 51 --
 src/gallium/drivers/virgl/virgl_context.c  |  2 +-
 src/gallium/drivers/virgl/virgl_context.h  |  2 +-
 src/gallium/drivers/virgl/virgl_screen.c   |  2 +-
 src/gallium/drivers/virgl/virgl_screen.h   | 51 ++
 src/gallium/drivers/virgl/virgl_texture.c  |  2 +-
 7 files changed, 56 insertions(+), 56 deletions(-)
 delete mode 100644 src/gallium/drivers/virgl/virgl.h
 create mode 100644 src/gallium/drivers/virgl/virgl_screen.h

diff --git a/src/gallium/drivers/virgl/Makefile.sources 
b/src/gallium/drivers/virgl/Makefile.sources
index ed309ae..c27d284 100644
--- a/src/gallium/drivers/virgl/Makefile.sources
+++ b/src/gallium/drivers/virgl/Makefile.sources
@@ -4,7 +4,6 @@ C_SOURCES := \
virgl_context.h \
virgl_encode.c \
virgl_encode.h \
-   virgl.h \
virgl_hw.h \
virgl_protocol.h \
virgl_public.h \
@@ -12,6 +11,7 @@ C_SOURCES := \
virgl_resource.c \
virgl_resource.h \
virgl_screen.c \
+   virgl_screen.h \
virgl_streamout.c \
virgl_texture.c \
virgl_tgsi.c \
diff --git a/src/gallium/drivers/virgl/virgl.h 
b/src/gallium/drivers/virgl/virgl.h
deleted file mode 100644
index d64576c..000
--- a/src/gallium/drivers/virgl/virgl.h
+++ /dev/null
@@ -1,51 +0,0 @@
-/*
- * Copyright 2014, 2015 Red Hat.
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the "Software"),
- * to deal in the Software without restriction, including without limitation
- * on the rights to use, copy, modify, merge, publish, distribute, sub
- * license, and/or sell copies of the Software, and to permit persons to whom
- * the Software is furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice (including the next
- * paragraph) shall be included in all copies or substantial portions of the
- * Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
- * THE AUTHOR(S) AND/OR THEIR SUPPLIERS BE LIABLE FOR ANY CLAIM,
- * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
- * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
- * USE OR OTHER DEALINGS IN THE SOFTWARE.
- */
-#ifndef VIRGL_H
-#define VIRGL_H
-
-#include "util/u_transfer.h"
-
-#include "virgl_hw.h"
-
-#include "virgl_winsys.h"
-#include "pipe/p_screen.h"
-struct virgl_screen {
-   struct pipe_screen base;
-   struct sw_winsys *winsys;
-   struct virgl_winsys *vws;
-
-   struct virgl_drm_caps caps;
-
-   uint32_t sub_ctx_id;
-};
-
-
-static inline struct virgl_screen *
-virgl_screen( struct pipe_screen *pipe )
-{
-   return (struct virgl_screen *)pipe;
-}
-
-#define VIRGL_MAP_BUFFER_ALIGNMENT 64
-
-#endif
diff --git a/src/gallium/drivers/virgl/virgl_context.c 
b/src/gallium/drivers/virgl/virgl_context.c
index 37a631a..3146459 100644
--- a/src/gallium/drivers/virgl/virgl_context.c
+++ b/src/gallium/drivers/virgl/virgl_context.c
@@ -46,7 +46,7 @@
 #include "virgl_context.h"
 
 #include "virgl_resource.h"
-#include "virgl.h"
+#include "virgl_screen.h"
 #include "state_tracker/sw_winsys.h"
  struct pipe_screen encscreen;
 
diff --git a/src/gallium/drivers/virgl/virgl_context.h 
b/src/gallium/drivers/virgl/virgl_context.h
index 878d786..948ea2d 100644
--- a/src/gallium/drivers/virgl/virgl_context.h
+++ b/src/gallium/drivers/virgl/virgl_context.h
@@ -27,7 +27,7 @@
 #include "pipe/p_context.h"
 #include "virgl_protocol.h"
 
-#include "virgl.h"
+#include "virgl_screen.h"
 #include "util/u_slab.h"
 #include "util/list.h"
 #include "indices/u_primconvert.h"
diff --git a/src/gallium/drivers/virgl/virgl_screen.c 
b/src/gallium/drivers/virgl/virgl_screen.c
index 2bc7f87..ebc42f4 100644
--- a/src/gallium/drivers/virgl/virgl_screen.c
+++ b/src/gallium/drivers/virgl/virgl_screen.c
@@ -34,7 +34,7 @@
 #include "state_tracker/sw_winsys.h"
 #include "tgsi/tgsi_exec.h"
 
-#include "virgl.h"
+#include "virgl_screen.h"
 #include "virgl_resource.h"
 #include "virgl_public.h"
 #include "virgl_context.h"
diff --git a/src/gallium/drivers/virgl/virgl_screen.h 
b/src/gallium/drivers/virgl/virgl_screen.h
new file mode 100644
index 000..d64576c
--- /dev/null
+++ b/src/gallium/drivers/virgl/virgl_screen.h
@@ -0,0 +1,51 @@
+/*
+ * Copyright 2014, 2015 Red Hat.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without 

[Mesa-dev] [PATCH 12/15] winsys/virgl: always memset prior to ioctl

2015-10-29 Thread Emil Velikov
Signed-off-by: Emil Velikov 
---
 src/gallium/winsys/virgl/drm/virgl_drm_winsys.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c 
b/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
index 11542f5..d9b4d58 100644
--- a/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
+++ b/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
@@ -55,6 +55,7 @@ static void virgl_hw_res_destroy(struct virgl_drm_winsys 
*qdws,
   if (res->ptr)
  os_munmap(res->ptr, res->size);
 
+  memset(, 0, sizeof(args));
   args.handle = res->bo_handle;
   drmIoctl(qdws->fd, DRM_IOCTL_GEM_CLOSE, );
   FREE(res);
@@ -65,6 +66,7 @@ static boolean virgl_drm_resource_is_busy(struct 
virgl_drm_winsys *qdws, struct
struct drm_virtgpu_3d_wait waitcmd;
int ret;
 
+   memset(, 0, sizeof(waitcmd));
waitcmd.handle = res->bo_handle;
waitcmd.flags = VIRTGPU_WAIT_NOWAIT;
 
@@ -174,6 +176,7 @@ static struct virgl_hw_res 
*virgl_drm_winsys_resource_create(struct virgl_winsys
if (!res)
   return NULL;
 
+   memset(, 0, sizeof(createcmd));
createcmd.target = target;
createcmd.format = format;
createcmd.bind = bind;
@@ -183,10 +186,8 @@ static struct virgl_hw_res 
*virgl_drm_winsys_resource_create(struct virgl_winsys
createcmd.array_size = array_size;
createcmd.last_level = last_level;
createcmd.nr_samples = nr_samples;
-   createcmd.res_handle = 0;
createcmd.stride = stride;
createcmd.size = size;
-   createcmd.flags = 0;
 
ret = drmIoctl(qdws->fd, DRM_IOCTL_VIRTGPU_RESOURCE_CREATE, );
if (ret != 0) {
@@ -237,6 +238,7 @@ virgl_bo_transfer_put(struct virgl_winsys *vws,
struct drm_virtgpu_3d_transfer_to_host tohostcmd;
int ret;
 
+   memset(, 0, sizeof(tohostcmd));
tohostcmd.bo_handle = res->bo_handle;
tohostcmd.box = *(struct drm_virtgpu_3d_box *)box;
tohostcmd.offset = buf_offset;
@@ -258,6 +260,7 @@ virgl_bo_transfer_get(struct virgl_winsys *vws,
struct drm_virtgpu_3d_transfer_from_host fromhostcmd;
int ret;
 
+   memset(, 0, sizeof(fromhostcmd));
fromhostcmd.bo_handle = res->bo_handle;
fromhostcmd.level = level;
fromhostcmd.offset = buf_offset;
@@ -430,10 +433,10 @@ static boolean 
virgl_drm_winsys_resource_get_handle(struct virgl_winsys *qws,
 
if (!res)
return FALSE;
-   memset(, 0, sizeof(flink));
 
if (whandle->type == DRM_API_HANDLE_TYPE_SHARED) {
   if (!res->flinked) {
+ memset(, 0, sizeof(flink));
  flink.handle = res->bo_handle;
 
  if (drmIoctl(qdws->fd, DRM_IOCTL_GEM_FLINK, )) {
@@ -474,6 +477,7 @@ static void *virgl_drm_resource_map(struct virgl_winsys 
*qws, struct virgl_hw_re
if (res->ptr)
   return res->ptr;
 
+   memset(_arg, 0, sizeof(mmap_arg));
mmap_arg.handle = res->bo_handle;
if (drmIoctl(qdws->fd, DRM_IOCTL_VIRTGPU_MAP, _arg))
   return NULL;
@@ -494,8 +498,8 @@ static void virgl_drm_resource_wait(struct virgl_winsys 
*qws, struct virgl_hw_re
struct drm_virtgpu_3d_wait waitcmd;
int ret;
 
+   memset(, 0, sizeof(waitcmd));
waitcmd.handle = res->bo_handle;
-   waitcmd.flags = 0;
  again:
ret = drmIoctl(qdws->fd, DRM_IOCTL_VIRTGPU_WAIT, );
if (ret == -EAGAIN)
-- 
2.6.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 15/15] winsys/virgl: rework line wrapping/indent

2015-10-29 Thread Emil Velikov
Wrap some of the 'omg it's getting out of hand' long lines, and
re-indent where things feel off.

Signed-off-by: Emil Velikov 
---
 src/gallium/winsys/virgl/drm/virgl_drm_winsys.c|  83 ---
 .../winsys/virgl/vtest/virgl_vtest_socket.c|  13 ++-
 .../winsys/virgl/vtest/virgl_vtest_winsys.c| 117 -
 .../winsys/virgl/vtest/virgl_vtest_winsys.h|   3 +-
 4 files changed, 124 insertions(+), 92 deletions(-)

diff --git a/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c 
b/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
index c9cdf68..d77ebd6 100644
--- a/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
+++ b/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
@@ -66,7 +66,8 @@ static void virgl_hw_res_destroy(struct virgl_drm_winsys 
*qdws,
   FREE(res);
 }
 
-static boolean virgl_drm_resource_is_busy(struct virgl_drm_winsys *qdws, 
struct virgl_hw_res *res)
+static boolean virgl_drm_resource_is_busy(struct virgl_drm_winsys *qdws,
+  struct virgl_hw_res *res)
 {
struct drm_virtgpu_3d_wait waitcmd;
int ret;
@@ -159,17 +160,18 @@ static void virgl_drm_resource_reference(struct 
virgl_drm_winsys *qdws,
*dres = sres;
 }
 
-static struct virgl_hw_res *virgl_drm_winsys_resource_create(struct 
virgl_winsys *qws,
-   enum pipe_texture_target target,
-   uint32_t format,
-   uint32_t bind,
-   uint32_t width,
-   uint32_t height,
-   uint32_t depth,
-   uint32_t array_size,
-   uint32_t last_level,
-   uint32_t nr_samples,
-   uint32_t size)
+static struct virgl_hw_res *
+virgl_drm_winsys_resource_create(struct virgl_winsys *qws,
+ enum pipe_texture_target target,
+ uint32_t format,
+ uint32_t bind,
+ uint32_t width,
+ uint32_t height,
+ uint32_t depth,
+ uint32_t array_size,
+ uint32_t last_level,
+ uint32_t nr_samples,
+ uint32_t size)
 {
struct virgl_drm_winsys *qdws = virgl_drm_winsys(qws);
struct drm_virtgpu_resource_create createcmd;
@@ -214,7 +216,8 @@ static struct virgl_hw_res 
*virgl_drm_winsys_resource_create(struct virgl_winsys
 
 static inline int virgl_is_res_compat(struct virgl_drm_winsys *qdws,
   struct virgl_hw_res *res,
-  uint32_t size, uint32_t bind, uint32_t 
format)
+  uint32_t size, uint32_t bind,
+  uint32_t format)
 {
if (res->bind != bind)
   return 0;
@@ -272,17 +275,18 @@ virgl_bo_transfer_get(struct virgl_winsys *vws,
return drmIoctl(vdws->fd, DRM_IOCTL_VIRTGPU_TRANSFER_FROM_HOST, 
);
 }
 
-static struct virgl_hw_res *virgl_drm_winsys_resource_cache_create(struct 
virgl_winsys *qws,
-   enum pipe_texture_target target,
-   uint32_t format,
-   uint32_t bind,
-   uint32_t width,
-   uint32_t height,
-   uint32_t depth,
-   uint32_t array_size,
-   uint32_t last_level,
-   uint32_t nr_samples,
-   uint32_t size)
+static struct virgl_hw_res *
+virgl_drm_winsys_resource_cache_create(struct virgl_winsys *qws,
+   enum pipe_texture_target target,
+   uint32_t format,
+   uint32_t bind,
+   uint32_t width,
+   uint32_t height,
+   uint32_t depth,
+   uint32_t array_size,
+   uint32_t last_level,
+   uint32_t nr_samples,
+   uint32_t size)
 {
struct virgl_drm_winsys *qdws = virgl_drm_winsys(qws);
struct virgl_hw_res *res, *curr_res;
@@ -355,8 +359,9 @@ alloc:
return 

[Mesa-dev] [PATCH 11/15] winsys/virgl: use MALLOC to match FREE

2015-10-29 Thread Emil Velikov
The uppercase versions are wrappers which must be matched.

Signed-off-by: Emil Velikov 
---
 src/gallium/winsys/virgl/drm/virgl_drm_winsys.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c 
b/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
index 8a74c40..11542f5 100644
--- a/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
+++ b/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
@@ -518,7 +518,7 @@ static struct virgl_cmd_buf 
*virgl_drm_cmd_buf_create(struct virgl_winsys *qws)
   FREE(cbuf);
   return NULL;
}
-   cbuf->res_hlist = malloc(cbuf->nres * sizeof(uint32_t));
+   cbuf->res_hlist = MALLOC(cbuf->nres * sizeof(uint32_t));
if (!cbuf->res_hlist) {
   FREE(cbuf->res_bo);
   FREE(cbuf);
-- 
2.6.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 13/15] winsys/virgl: remove temporary ret variable

2015-10-29 Thread Emil Velikov
Signed-off-by: Emil Velikov 
---
 src/gallium/winsys/virgl/drm/virgl_drm_winsys.c | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c 
b/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
index d9b4d58..0616de3 100644
--- a/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
+++ b/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
@@ -236,7 +236,6 @@ virgl_bo_transfer_put(struct virgl_winsys *vws,
 {
struct virgl_drm_winsys *vdws = virgl_drm_winsys(vws);
struct drm_virtgpu_3d_transfer_to_host tohostcmd;
-   int ret;
 
memset(, 0, sizeof(tohostcmd));
tohostcmd.bo_handle = res->bo_handle;
@@ -245,8 +244,7 @@ virgl_bo_transfer_put(struct virgl_winsys *vws,
tohostcmd.level = level;
   // tohostcmd.stride = stride;
   // tohostcmd.layer_stride = stride;
-   ret = drmIoctl(vdws->fd, DRM_IOCTL_VIRTGPU_TRANSFER_TO_HOST, );
-   return ret;
+   return drmIoctl(vdws->fd, DRM_IOCTL_VIRTGPU_TRANSFER_TO_HOST, );
 }
 
 static int
@@ -258,7 +256,6 @@ virgl_bo_transfer_get(struct virgl_winsys *vws,
 {
struct virgl_drm_winsys *vdws = virgl_drm_winsys(vws);
struct drm_virtgpu_3d_transfer_from_host fromhostcmd;
-   int ret;
 
memset(, 0, sizeof(fromhostcmd));
fromhostcmd.bo_handle = res->bo_handle;
@@ -267,8 +264,7 @@ virgl_bo_transfer_get(struct virgl_winsys *vws,
   // fromhostcmd.stride = stride;
   // fromhostcmd.layer_stride = layer_stride;
fromhostcmd.box = *(struct drm_virtgpu_3d_box *)box;
-   ret = drmIoctl(vdws->fd, DRM_IOCTL_VIRTGPU_TRANSFER_FROM_HOST, 
);
-   return ret;
+   return drmIoctl(vdws->fd, DRM_IOCTL_VIRTGPU_TRANSFER_FROM_HOST, 
);
 }
 
 static struct virgl_hw_res *virgl_drm_winsys_resource_cache_create(struct 
virgl_winsys *qws,
@@ -651,15 +647,13 @@ static int virgl_drm_get_caps(struct virgl_winsys *vws, 
struct virgl_drm_caps *c
 {
struct virgl_drm_winsys *vdws = virgl_drm_winsys(vws);
struct drm_virtgpu_get_caps args;
-   int ret;
 
memset(, 0, sizeof(args));
 
args.cap_set_id = 1;
args.addr = (unsigned long)>caps;
args.size = sizeof(union virgl_caps);
-   ret = drmIoctl(vdws->fd, DRM_IOCTL_VIRTGPU_GET_CAPS, );
-   return ret;
+   return drmIoctl(vdws->fd, DRM_IOCTL_VIRTGPU_GET_CAPS, );
 }
 
 #define PTR_TO_UINT(x) ((unsigned)((intptr_t)(x)))
-- 
2.6.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 10/15] winsys/virgl: remove calloc/malloc casts

2015-10-29 Thread Emil Velikov
Signed-off-by: Emil Velikov 
---
 src/gallium/winsys/virgl/drm/virgl_drm_winsys.c | 5 ++---
 src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.c | 3 +--
 2 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c 
b/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
index 31317b9..8a74c40 100644
--- a/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
+++ b/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
@@ -513,13 +513,12 @@ static struct virgl_cmd_buf 
*virgl_drm_cmd_buf_create(struct virgl_winsys *qws)
cbuf->ws = qws;
 
cbuf->nres = 512;
-   cbuf->res_bo = (struct virgl_hw_res **)
-  CALLOC(cbuf->nres, sizeof(struct virgl_hw_buf*));
+   cbuf->res_bo = CALLOC(cbuf->nres, sizeof(struct virgl_hw_buf*));
if (!cbuf->res_bo) {
   FREE(cbuf);
   return NULL;
}
-   cbuf->res_hlist = (uint32_t *)malloc(cbuf->nres * sizeof(uint32_t));
+   cbuf->res_hlist = malloc(cbuf->nres * sizeof(uint32_t));
if (!cbuf->res_hlist) {
   FREE(cbuf->res_bo);
   FREE(cbuf);
diff --git a/src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.c 
b/src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.c
index 1c8df6e..28c4c62 100644
--- a/src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.c
+++ b/src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.c
@@ -394,8 +394,7 @@ static struct virgl_cmd_buf 
*virgl_vtest_cmd_buf_create(struct virgl_winsys *vws
   return NULL;
 
cbuf->nres = 512;
-   cbuf->res_bo = (struct virgl_hw_res **)
-  CALLOC(cbuf->nres, sizeof(struct virgl_hw_buf*));
+   cbuf->res_bo = CALLOC(cbuf->nres, sizeof(struct virgl_hw_buf*));
if (!cbuf->res_bo) {
   FREE(cbuf);
   return NULL;
-- 
2.6.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 07/15] virgl: use virgl_screen/surface upcast wrappers

2015-10-29 Thread Emil Velikov
Signed-off-by: Emil Velikov 
---
 src/gallium/drivers/virgl/virgl_context.c  | 2 +-
 src/gallium/drivers/virgl/virgl_encode.c   | 4 ++--
 src/gallium/drivers/virgl/virgl_encode.h   | 5 +
 src/gallium/drivers/virgl/virgl_resource.c | 4 ++--
 src/gallium/drivers/virgl/virgl_screen.h   | 2 +-
 5 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/src/gallium/drivers/virgl/virgl_context.c 
b/src/gallium/drivers/virgl/virgl_context.c
index 2b6b356..32dde06 100644
--- a/src/gallium/drivers/virgl/virgl_context.c
+++ b/src/gallium/drivers/virgl/virgl_context.c
@@ -231,7 +231,7 @@ static void virgl_surface_destroy(struct pipe_context *ctx,
  struct pipe_surface *psurf)
 {
struct virgl_context *vctx = virgl_context(ctx);
-   struct virgl_surface *surf = (struct virgl_surface *)psurf;
+   struct virgl_surface *surf = virgl_surface(psurf);
 
pipe_resource_reference(>base.texture, NULL);
virgl_encode_delete_object(vctx, surf->handle, VIRGL_OBJECT_SURFACE);
diff --git a/src/gallium/drivers/virgl/virgl_encode.c 
b/src/gallium/drivers/virgl/virgl_encode.c
index d825397..4493c3f 100644
--- a/src/gallium/drivers/virgl/virgl_encode.c
+++ b/src/gallium/drivers/virgl/virgl_encode.c
@@ -323,14 +323,14 @@ int virgl_encode_clear(struct virgl_context *ctx,
 int virgl_encoder_set_framebuffer_state(struct virgl_context *ctx,
const struct pipe_framebuffer_state 
*state)
 {
-   struct virgl_surface *zsurf = (struct virgl_surface *)state->zsbuf;
+   struct virgl_surface *zsurf = virgl_surface(state->zsbuf);
int i;
 
virgl_encoder_write_cmd_dword(ctx, 
VIRGL_CMD0(VIRGL_CCMD_SET_FRAMEBUFFER_STATE, 0, 
VIRGL_SET_FRAMEBUFFER_STATE_SIZE(state->nr_cbufs)));
virgl_encoder_write_dword(ctx->cbuf, state->nr_cbufs);
virgl_encoder_write_dword(ctx->cbuf, zsurf ? zsurf->handle : 0);
for (i = 0; i < state->nr_cbufs; i++) {
-  struct virgl_surface *surf = (struct virgl_surface *)state->cbufs[i];
+  struct virgl_surface *surf = virgl_surface(state->cbufs[i]);
   virgl_encoder_write_dword(ctx->cbuf, surf ? surf->handle : 0);
}
 
diff --git a/src/gallium/drivers/virgl/virgl_encode.h 
b/src/gallium/drivers/virgl/virgl_encode.h
index eabc421..d792369 100644
--- a/src/gallium/drivers/virgl/virgl_encode.h
+++ b/src/gallium/drivers/virgl/virgl_encode.h
@@ -29,6 +29,11 @@ struct virgl_surface {
uint32_t handle;
 };
 
+static inline struct virgl_surface *virgl_surface(struct pipe_surface *surf)
+{
+   return (struct virgl_surface *)surf;
+}
+
 static inline void virgl_encoder_write_dword(struct virgl_cmd_buf *state,
 uint32_t dword)
 {
diff --git a/src/gallium/drivers/virgl/virgl_resource.c 
b/src/gallium/drivers/virgl/virgl_resource.c
index 758dd6b..52425f4 100644
--- a/src/gallium/drivers/virgl/virgl_resource.c
+++ b/src/gallium/drivers/virgl/virgl_resource.c
@@ -54,7 +54,7 @@ bool virgl_res_needs_readback(struct virgl_context *vctx,
 static struct pipe_resource *virgl_resource_create(struct pipe_screen *screen,
const struct pipe_resource 
*templ)
 {
-struct virgl_screen *vs = (struct virgl_screen *)screen;
+struct virgl_screen *vs = virgl_screen(screen);
 if (templ->target == PIPE_BUFFER)
 return virgl_buffer_create(vs, templ);
 else
@@ -65,7 +65,7 @@ static struct pipe_resource 
*virgl_resource_from_handle(struct pipe_screen *scre
 const struct 
pipe_resource *templ,
 struct winsys_handle 
*whandle)
 {
-struct virgl_screen *vs = (struct virgl_screen *)screen;
+struct virgl_screen *vs = virgl_screen(screen);
 if (templ->target == PIPE_BUFFER)
 return NULL;
 else
diff --git a/src/gallium/drivers/virgl/virgl_screen.h 
b/src/gallium/drivers/virgl/virgl_screen.h
index 82b876f..1a24eec 100644
--- a/src/gallium/drivers/virgl/virgl_screen.h
+++ b/src/gallium/drivers/virgl/virgl_screen.h
@@ -40,7 +40,7 @@ struct virgl_screen {
 
 
 static inline struct virgl_screen *
-virgl_screen( struct pipe_screen *pipe )
+virgl_screen(struct pipe_screen *pipe)
 {
return (struct virgl_screen *)pipe;
 }
-- 
2.6.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 05/15] virgl: add virgl_context/sampler_view/so_target() upcast wrappers

2015-10-29 Thread Emil Velikov
Signed-off-by: Emil Velikov 
---
 src/gallium/drivers/virgl/virgl_buffer.c|  6 +-
 src/gallium/drivers/virgl/virgl_context.c   | 98 ++---
 src/gallium/drivers/virgl/virgl_context.h   | 17 +
 src/gallium/drivers/virgl/virgl_encode.c|  2 +-
 src/gallium/drivers/virgl/virgl_query.c | 12 ++--
 src/gallium/drivers/virgl/virgl_streamout.c |  8 +--
 src/gallium/drivers/virgl/virgl_texture.c   |  4 +-
 7 files changed, 82 insertions(+), 65 deletions(-)

diff --git a/src/gallium/drivers/virgl/virgl_buffer.c 
b/src/gallium/drivers/virgl/virgl_buffer.c
index 93fb295..96cb82c 100644
--- a/src/gallium/drivers/virgl/virgl_buffer.c
+++ b/src/gallium/drivers/virgl/virgl_buffer.c
@@ -43,7 +43,7 @@ static void *virgl_buffer_transfer_map(struct pipe_context 
*ctx,
const struct pipe_box *box,
struct pipe_transfer **transfer)
 {
-   struct virgl_context *vctx = (struct virgl_context *)ctx;
+   struct virgl_context *vctx = virgl_context(ctx);
struct virgl_screen *vs = virgl_screen(ctx->screen);
struct virgl_buffer *vbuf = virgl_buffer(resource);
struct virgl_transfer *trans;
@@ -97,7 +97,7 @@ static void *virgl_buffer_transfer_map(struct pipe_context 
*ctx,
 static void virgl_buffer_transfer_unmap(struct pipe_context *ctx,
 struct pipe_transfer *transfer)
 {
-   struct virgl_context *vctx = (struct virgl_context *)ctx;
+   struct virgl_context *vctx = virgl_context(ctx);
struct virgl_transfer *trans = (struct virgl_transfer *)transfer;
struct virgl_buffer *vbuf = virgl_buffer(transfer->resource);
 
@@ -119,7 +119,7 @@ static void virgl_buffer_transfer_flush_region(struct 
pipe_context *ctx,
struct pipe_transfer *transfer,
const struct pipe_box *box)
 {
-   struct virgl_context *vctx = (struct virgl_context *)ctx;
+   struct virgl_context *vctx = virgl_context(ctx);
struct virgl_buffer *vbuf = virgl_buffer(transfer->resource);
 
if (!vbuf->on_list) {
diff --git a/src/gallium/drivers/virgl/virgl_context.c 
b/src/gallium/drivers/virgl/virgl_context.c
index 3146459..f222e53 100644
--- a/src/gallium/drivers/virgl/virgl_context.c
+++ b/src/gallium/drivers/virgl/virgl_context.c
@@ -195,7 +195,7 @@ static struct pipe_surface *virgl_create_surface(struct 
pipe_context *ctx,
 struct pipe_resource *resource,
 const struct pipe_surface 
*templ)
 {
-   struct virgl_context *vctx = (struct virgl_context *)ctx;
+   struct virgl_context *vctx = virgl_context(ctx);
struct virgl_surface *surf;
struct virgl_resource *res = virgl_resource(resource);
uint32_t handle;
@@ -230,7 +230,7 @@ static struct pipe_surface *virgl_create_surface(struct 
pipe_context *ctx,
 static void virgl_surface_destroy(struct pipe_context *ctx,
  struct pipe_surface *psurf)
 {
-   struct virgl_context *vctx = (struct virgl_context *)ctx;
+   struct virgl_context *vctx = virgl_context(ctx);
struct virgl_surface *surf = (struct virgl_surface *)psurf;
 
pipe_resource_reference(>base.texture, NULL);
@@ -241,7 +241,7 @@ static void virgl_surface_destroy(struct pipe_context *ctx,
 static void *virgl_create_blend_state(struct pipe_context *ctx,
   const struct pipe_blend_state 
*blend_state)
 {
-   struct virgl_context *vctx = (struct virgl_context *)ctx;
+   struct virgl_context *vctx = virgl_context(ctx);
uint32_t handle;
handle = virgl_object_assign_handle();
 
@@ -253,7 +253,7 @@ static void *virgl_create_blend_state(struct pipe_context 
*ctx,
 static void virgl_bind_blend_state(struct pipe_context *ctx,
void *blend_state)
 {
-   struct virgl_context *vctx = (struct virgl_context *)ctx;
+   struct virgl_context *vctx = virgl_context(ctx);
uint32_t handle = (unsigned long)blend_state;
virgl_encode_bind_object(vctx, handle, VIRGL_OBJECT_BLEND);
 }
@@ -261,7 +261,7 @@ static void virgl_bind_blend_state(struct pipe_context *ctx,
 static void virgl_delete_blend_state(struct pipe_context *ctx,
  void *blend_state)
 {
-   struct virgl_context *vctx = (struct virgl_context *)ctx;
+   struct virgl_context *vctx = virgl_context(ctx);
uint32_t handle = (unsigned long)blend_state;
virgl_encode_delete_object(vctx, handle, VIRGL_OBJECT_BLEND);
 }
@@ -269,7 +269,7 @@ static void virgl_delete_blend_state(struct pipe_context 
*ctx,
 static void *virgl_create_depth_stencil_alpha_state(struct pipe_context *ctx,
const struct 
pipe_depth_stencil_alpha_state *blend_state)
 {
-   struct virgl_context *vctx = (struct virgl_context *)ctx;
+   struct 

[Mesa-dev] [PATCH 08/15] virgl: introduce virgl_query() inline wrapper

2015-10-29 Thread Emil Velikov
Signed-off-by: Emil Velikov 
---
 src/gallium/drivers/virgl/virgl_query.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/src/gallium/drivers/virgl/virgl_query.c 
b/src/gallium/drivers/virgl/virgl_query.c
index ea50f2f..b06635b 100644
--- a/src/gallium/drivers/virgl/virgl_query.c
+++ b/src/gallium/drivers/virgl/virgl_query.c
@@ -37,13 +37,18 @@ struct virgl_query {
unsigned result_gotten_sent;
 };
 
+static inline struct virgl_query *virgl_query(struct pipe_query *q)
+{
+   return (struct virgl_query *)q;
+}
+
 static void virgl_render_condition(struct pipe_context *ctx,
   struct pipe_query *q,
   boolean condition,
   uint mode)
 {
struct virgl_context *vctx = virgl_context(ctx);
-   struct virgl_query *query = (struct virgl_query *)q;
+   struct virgl_query *query = virgl_query(q);
uint32_t handle = 0;
if (q)
   handle = query->handle;
@@ -82,7 +87,7 @@ static void virgl_destroy_query(struct pipe_context *ctx,
 struct pipe_query *q)
 {
struct virgl_context *vctx = virgl_context(ctx);
-   struct virgl_query *query = (struct virgl_query *)q;
+   struct virgl_query *query = virgl_query(q);
 
virgl_encode_delete_object(vctx, query->handle, VIRGL_OBJECT_QUERY);
 
@@ -94,7 +99,7 @@ static boolean virgl_begin_query(struct pipe_context *ctx,
  struct pipe_query *q)
 {
struct virgl_context *vctx = virgl_context(ctx);
-   struct virgl_query *query = (struct virgl_query *)q;
+   struct virgl_query *query = virgl_query(q);
 
query->buf->clean = FALSE;
virgl_encoder_begin_query(vctx, query->handle);
@@ -105,7 +110,7 @@ static void virgl_end_query(struct pipe_context *ctx,
struct pipe_query *q)
 {
struct virgl_context *vctx = virgl_context(ctx);
-   struct virgl_query *query = (struct virgl_query *)q;
+   struct virgl_query *query = virgl_query(q);
struct pipe_box box;
 
uint32_t qs = VIRGL_QUERY_STATE_WAIT_HOST;
@@ -123,7 +128,7 @@ static boolean virgl_get_query_result(struct pipe_context 
*ctx,
  union pipe_query_result *result)
 {
struct virgl_context *vctx = virgl_context(ctx);
-   struct virgl_query *query = (struct virgl_query *)q;
+   struct virgl_query *query = virgl_query(q);
struct pipe_transfer *transfer;
struct virgl_host_query_state *host_state;
 
-- 
2.6.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 03/15] virgl: remove sw_winsys pointer from virgl_screen

2015-10-29 Thread Emil Velikov
The screen already has a pointer to the (base) winsys object.
With the latter of which implemented/sub-classed as either drm or sw
based one, depending on the target.

Signed-off-by: Emil Velikov 
---
 src/gallium/drivers/virgl/virgl_public.h | 1 -
 src/gallium/drivers/virgl/virgl_screen.c | 1 -
 src/gallium/drivers/virgl/virgl_screen.h | 1 -
 3 files changed, 3 deletions(-)

diff --git a/src/gallium/drivers/virgl/virgl_public.h 
b/src/gallium/drivers/virgl/virgl_public.h
index 6a2c11b..a3ea560 100644
--- a/src/gallium/drivers/virgl/virgl_public.h
+++ b/src/gallium/drivers/virgl/virgl_public.h
@@ -24,7 +24,6 @@
 #define VIRGL_PUBLIC_H
 
 struct pipe_screen;
-struct sw_winsys;
 struct virgl_winsys;
 
 struct pipe_screen *
diff --git a/src/gallium/drivers/virgl/virgl_screen.c 
b/src/gallium/drivers/virgl/virgl_screen.c
index ebc42f4..fbc6aba 100644
--- a/src/gallium/drivers/virgl/virgl_screen.c
+++ b/src/gallium/drivers/virgl/virgl_screen.c
@@ -532,7 +532,6 @@ virgl_create_screen(struct virgl_winsys *vws)
   return NULL;
 
screen->vws = vws;
-   screen->winsys = NULL;
screen->base.get_name = virgl_get_name;
screen->base.get_vendor = virgl_get_vendor;
screen->base.get_param = virgl_get_param;
diff --git a/src/gallium/drivers/virgl/virgl_screen.h 
b/src/gallium/drivers/virgl/virgl_screen.h
index d64576c..82b876f 100644
--- a/src/gallium/drivers/virgl/virgl_screen.h
+++ b/src/gallium/drivers/virgl/virgl_screen.h
@@ -31,7 +31,6 @@
 #include "pipe/p_screen.h"
 struct virgl_screen {
struct pipe_screen base;
-   struct sw_winsys *winsys;
struct virgl_winsys *vws;
 
struct virgl_drm_caps caps;
-- 
2.6.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 04/15] winsys/virgl/drm: drop unneeded forward declaration

2015-10-29 Thread Emil Velikov
Signed-off-by: Emil Velikov 
---
 src/gallium/winsys/virgl/drm/virgl_drm_winsys.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/src/gallium/winsys/virgl/drm/virgl_drm_winsys.h 
b/src/gallium/winsys/virgl/drm/virgl_drm_winsys.h
index eac1d3e..a547654 100644
--- a/src/gallium/winsys/virgl/drm/virgl_drm_winsys.h
+++ b/src/gallium/winsys/virgl/drm/virgl_drm_winsys.h
@@ -39,8 +39,6 @@
 #include "virgl/virgl_hw.h"
 #include "virgl/virgl_winsys.h"
 
-struct virgl_drm_winsys;
-
 struct virgl_hw_res {
struct pipe_reference reference;
uint32_t res_handle;
-- 
2.6.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 06/15] virgl: introduce and use virgl_transfer/texture/resource inline wrappers

2015-10-29 Thread Emil Velikov
The only two remaining cases of (struct virgl_resource *) require a
closer look. Either the error checking is missing or the arguments
provided feel wrong.

Signed-off-by: Emil Velikov 
---
 src/gallium/drivers/virgl/virgl_buffer.c|  2 +-
 src/gallium/drivers/virgl/virgl_context.c   | 28 ++--
 src/gallium/drivers/virgl/virgl_encode.c|  4 ++--
 src/gallium/drivers/virgl/virgl_resource.h  | 10 ++
 src/gallium/drivers/virgl/virgl_screen.c|  2 +-
 src/gallium/drivers/virgl/virgl_streamout.c |  2 +-
 src/gallium/drivers/virgl/virgl_texture.c   | 10 +-
 7 files changed, 34 insertions(+), 24 deletions(-)

diff --git a/src/gallium/drivers/virgl/virgl_buffer.c 
b/src/gallium/drivers/virgl/virgl_buffer.c
index 96cb82c..13e8384 100644
--- a/src/gallium/drivers/virgl/virgl_buffer.c
+++ b/src/gallium/drivers/virgl/virgl_buffer.c
@@ -98,7 +98,7 @@ static void virgl_buffer_transfer_unmap(struct pipe_context 
*ctx,
 struct pipe_transfer *transfer)
 {
struct virgl_context *vctx = virgl_context(ctx);
-   struct virgl_transfer *trans = (struct virgl_transfer *)transfer;
+   struct virgl_transfer *trans = virgl_transfer(transfer);
struct virgl_buffer *vbuf = virgl_buffer(transfer->resource);
 
if (trans->base.usage & PIPE_TRANSFER_WRITE) {
diff --git a/src/gallium/drivers/virgl/virgl_context.c 
b/src/gallium/drivers/virgl/virgl_context.c
index f222e53..2b6b356 100644
--- a/src/gallium/drivers/virgl/virgl_context.c
+++ b/src/gallium/drivers/virgl/virgl_context.c
@@ -88,14 +88,14 @@ static void virgl_attach_res_framebuffer(struct 
virgl_context *vctx)
 
surf = vctx->framebuffer.zsbuf;
if (surf) {
-  res = (struct virgl_resource *)surf->texture;
+  res = virgl_resource(surf->texture);
   if (res)
  vws->emit_res(vws, vctx->cbuf, res->hw_res, FALSE);
}
for (i = 0; i < vctx->framebuffer.nr_cbufs; i++) {
   surf = vctx->framebuffer.cbufs[i];
   if (surf) {
- res = (struct virgl_resource *)surf->texture;
+ res = virgl_resource(surf->texture);
  if (res)
 vws->emit_res(vws, vctx->cbuf, res->hw_res, FALSE);
   }
@@ -114,7 +114,7 @@ static void virgl_attach_res_sampler_views(struct 
virgl_context *vctx,
   i = u_bit_scan(_mask);
   assert(tinfo->views[i]);
 
-  res = (struct virgl_resource *)tinfo->views[i]->base.texture;
+  res = virgl_resource(tinfo->views[i]->base.texture);
   if (res)
  vws->emit_res(vws, vctx->cbuf, res->hw_res, FALSE);
}
@@ -127,7 +127,7 @@ static void virgl_attach_res_vertex_buffers(struct 
virgl_context *vctx)
unsigned i;
 
for (i = 0; i < vctx->num_vertex_buffers; i++) {
-  res = (struct virgl_resource *)vctx->vertex_buffer[i].buffer;
+  res = virgl_resource(vctx->vertex_buffer[i].buffer);
   if (res)
  vws->emit_res(vws, vctx->cbuf, res->hw_res, FALSE);
}
@@ -138,7 +138,7 @@ static void virgl_attach_res_index_buffer(struct 
virgl_context *vctx)
struct virgl_winsys *vws = virgl_screen(vctx->base.screen)->vws;
struct virgl_resource *res;
 
-   res = (struct virgl_resource *)vctx->index_buffer.buffer;
+   res = virgl_resource(vctx->index_buffer.buffer);
if (res)
   vws->emit_res(vws, vctx->cbuf, res->hw_res, FALSE);
 }
@@ -150,7 +150,7 @@ static void virgl_attach_res_so_targets(struct 
virgl_context *vctx)
unsigned i;
 
for (i = 0; i < vctx->num_so_targets; i++) {
-  res = (struct virgl_resource *)vctx->so_targets[i].base.buffer;
+  res = virgl_resource(vctx->so_targets[i].base.buffer);
   if (res)
  vws->emit_res(vws, vctx->cbuf, res->hw_res, FALSE);
}
@@ -163,7 +163,7 @@ static void virgl_attach_res_uniform_buffers(struct 
virgl_context *vctx,
struct virgl_resource *res;
unsigned i;
for (i = 0; i < PIPE_MAX_CONSTANT_BUFFERS; i++) {
-  res = (struct virgl_resource *)vctx->ubos[shader_type][i];
+  res = virgl_resource(vctx->ubos[shader_type][i]);
   if (res) {
  vws->emit_res(vws, vctx->cbuf, res->hw_res, FALSE);
   }
@@ -436,7 +436,7 @@ static void virgl_set_constant_buffer(struct pipe_context 
*ctx,
 
if (buf) {
   if (!buf->user_buffer){
- struct virgl_resource *res = (struct virgl_resource *)buf->buffer;
+ struct virgl_resource *res = virgl_resource(buf->buffer);
  virgl_encoder_set_uniform_buffer(vctx, shader, index, 
buf->buffer_offset,
   buf->buffer_size, res);
  pipe_resource_reference(>ubos[shader][index], buf->buffer);
@@ -461,7 +461,7 @@ void virgl_transfer_inline_write(struct pipe_context *ctx,
 {
struct virgl_context *vctx = virgl_context(ctx);
struct virgl_screen *vs = virgl_screen(ctx->screen);
-   struct virgl_resource *grres = (struct virgl_resource *)res;
+   struct virgl_resource *grres = virgl_resource(res);
struct virgl_buffer *vbuf = 

[Mesa-dev] [PATCH 09/15] winsys/virgl: throw in some inline wrappers

2015-10-29 Thread Emil Velikov
Signed-off-by: Emil Velikov 
---
 src/gallium/winsys/virgl/drm/virgl_drm_winsys.c | 10 +-
 src/gallium/winsys/virgl/drm/virgl_drm_winsys.h | 14 ++
 src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.c | 10 +-
 src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.h | 16 
 4 files changed, 40 insertions(+), 10 deletions(-)

diff --git a/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c 
b/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
index 2d5bf25..31317b9 100644
--- a/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
+++ b/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
@@ -532,7 +532,7 @@ static struct virgl_cmd_buf 
*virgl_drm_cmd_buf_create(struct virgl_winsys *qws)
 
 static void virgl_drm_cmd_buf_destroy(struct virgl_cmd_buf *_cbuf)
 {
-   struct virgl_drm_cmd_buf *cbuf = (struct virgl_drm_cmd_buf *)_cbuf;
+   struct virgl_drm_cmd_buf *cbuf = virgl_drm_cmd_buf(_cbuf);
 
FREE(cbuf->res_hlist);
FREE(cbuf->res_bo);
@@ -597,7 +597,7 @@ static void virgl_drm_emit_res(struct virgl_winsys *qws,
  struct virgl_cmd_buf *_cbuf, struct virgl_hw_res 
*res, boolean write_buf)
 {
struct virgl_drm_winsys *qdws = virgl_drm_winsys(qws);
-   struct virgl_drm_cmd_buf *cbuf = (struct virgl_drm_cmd_buf *)_cbuf;
+   struct virgl_drm_cmd_buf *cbuf = virgl_drm_cmd_buf(_cbuf);
boolean already_in_list = virgl_drm_lookup_res(cbuf, res);
 
if (write_buf)
@@ -620,7 +620,7 @@ static boolean virgl_drm_res_is_ref(struct virgl_winsys 
*qws,
 static int virgl_drm_winsys_submit_cmd(struct virgl_winsys *qws, struct 
virgl_cmd_buf *_cbuf)
 {
struct virgl_drm_winsys *qdws = virgl_drm_winsys(qws);
-   struct virgl_drm_cmd_buf *cbuf = (struct virgl_drm_cmd_buf *)_cbuf;
+   struct virgl_drm_cmd_buf *cbuf = virgl_drm_cmd_buf(_cbuf);
struct drm_virtgpu_execbuffer eb;
int ret;
 
@@ -690,7 +690,7 @@ static bool virgl_fence_wait(struct virgl_winsys *vws,
  uint64_t timeout)
 {
struct virgl_drm_winsys *vdws = virgl_drm_winsys(vws);
-   struct virgl_hw_res *res = (struct virgl_hw_res *)fence;
+   struct virgl_hw_res *res = virgl_hw_res(fence);
 
if (timeout == 0)
   return virgl_drm_resource_is_busy(vdws, res);
@@ -715,7 +715,7 @@ static void virgl_fence_reference(struct virgl_winsys *vws,
 {
struct virgl_drm_winsys *vdws = virgl_drm_winsys(vws);
virgl_drm_resource_reference(vdws, (struct virgl_hw_res **)dst,
-(struct virgl_hw_res *)src);
+virgl_hw_res(src));
 }
 
 
diff --git a/src/gallium/winsys/virgl/drm/virgl_drm_winsys.h 
b/src/gallium/winsys/virgl/drm/virgl_drm_winsys.h
index a547654..c835272 100644
--- a/src/gallium/winsys/virgl/drm/virgl_drm_winsys.h
+++ b/src/gallium/winsys/virgl/drm/virgl_drm_winsys.h
@@ -39,6 +39,8 @@
 #include "virgl/virgl_hw.h"
 #include "virgl/virgl_winsys.h"
 
+struct pipe_fence_handle;
+
 struct virgl_hw_res {
struct pipe_reference reference;
uint32_t res_handle;
@@ -87,10 +89,22 @@ struct virgl_drm_cmd_buf {
 
 };
 
+static inline struct virgl_hw_res *
+virgl_hw_res(struct pipe_fence_handle *f)
+{
+   return (struct virgl_hw_res *)f;
+}
+
 static inline struct virgl_drm_winsys *
 virgl_drm_winsys(struct virgl_winsys *iws)
 {
return (struct virgl_drm_winsys *)iws;
 }
 
+static inline struct virgl_drm_cmd_buf *
+virgl_drm_cmd_buf(struct virgl_cmd_buf *cbuf)
+{
+   return (struct virgl_drm_cmd_buf *)cbuf;
+}
+
 #endif
diff --git a/src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.c 
b/src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.c
index 24ba7ec..1c8df6e 100644
--- a/src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.c
+++ b/src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.c
@@ -407,7 +407,7 @@ static struct virgl_cmd_buf 
*virgl_vtest_cmd_buf_create(struct virgl_winsys *vws
 
 static void virgl_vtest_cmd_buf_destroy(struct virgl_cmd_buf *_cbuf)
 {
-   struct virgl_vtest_cmd_buf *cbuf = (struct virgl_vtest_cmd_buf *)_cbuf;
+   struct virgl_vtest_cmd_buf *cbuf = virgl_vtest_cmd_buf(_cbuf);
 
FREE(cbuf->res_bo);
FREE(cbuf);
@@ -468,7 +468,7 @@ static void virgl_vtest_add_res(struct virgl_vtest_winsys 
*vtws,
 static int virgl_vtest_winsys_submit_cmd(struct virgl_winsys *vws, struct 
virgl_cmd_buf *_cbuf)
 {
struct virgl_vtest_winsys *vtws = virgl_vtest_winsys(vws);
-   struct virgl_vtest_cmd_buf *cbuf = (struct virgl_vtest_cmd_buf *)_cbuf;
+   struct virgl_vtest_cmd_buf *cbuf = virgl_vtest_cmd_buf(_cbuf);
int ret;
 
if (cbuf->base.cdw == 0)
@@ -485,7 +485,7 @@ static int virgl_vtest_winsys_submit_cmd(struct 
virgl_winsys *vws, struct virgl_
 static void virgl_vtest_emit_res(struct virgl_winsys *vws, struct 
virgl_cmd_buf *_cbuf, struct virgl_hw_res *res, boolean write_buf)
 {
struct virgl_vtest_winsys *vtws = virgl_vtest_winsys(vws);
-   struct virgl_vtest_cmd_buf *cbuf = (struct virgl_vtest_cmd_buf *)_cbuf;
+   struct virgl_vtest_cmd_buf 

Re: [Mesa-dev] [RFC] i965: Resolve color for all active shader images in intel_update_state().

2015-10-29 Thread Francisco Jerez
Francisco Jerez  writes:

> Chris Wilson  writes:
>
>> On Sat, Oct 03, 2015 at 05:57:05PM +0300, Francisco Jerez wrote:
>>> Jordan Justen  writes:
>>> 
>>> > From: Francisco Jerez 
>>> >
>>> > Fixes 
>>> > arb_shader_image_load_store/execution/load-from-cleared-image.shader_test
>>> >
>>> > Cc: Chris Wilson 
>>> > Cc: Jason Ekstrand 
>>> > Tested-by: Jordan Justen 
>>> > ---
>>> >  RE: i965: Perform an explicit flush after doing 
>>> > _mesa_meta_pbo_TexSubImage
>>> >
>>> >  curro has some concerns about potential perf impact by this and
>>> >  wanted it to be checked on small-core w/CPU bound apps.
>>> >  Unfortunately, he is on vacation now.
>>> 
>>> I've benchmarked this on VLV and none of the CPU-bound tests in the
>>> Finnish benchmarking system regress significantly, with n=6 and 95%
>>> confidence level, so s/RFC/PATCH/.  I'll CC mesa-stable so it probably
>>> makes sense to keep this independent from Chris' VBO resolve series.
>>
>> I ran patch this on bsw (and repeated it afresh just to be sure) using 
>> synmark:Ogl*:
>>
>> 6994ca2 glsl: fix whitespace
>>synmark:OglBatch3:277.02 (+0.00%): min/p50/90/95/99/max/std = 
>> 271.902 / 277.024 / 277.952 / 278.117 / 278.233 / 278.409 / 1.27475 n=30
>>synmark:OglBatch3:cpu:434.92 (+0.00%): min/p50/90/95/99/max/std = 
>> 429.869 / 434.755 / 437.818 / 438.236 / 439.022 / 439.251 / 2.19871 n=30
>>synmark:OglBatch4:154.76 (+0.00%): min/p50/90/95/99/max/std = 
>> 153.394 / 154.75 / 155.636 / 155.643 / 156.089 / 156.172 / 0.721397 n=30
>>synmark:OglBatch4:cpu:176.84 (+0.00%): min/p50/90/95/99/max/std = 
>> 176.239 / 176.838 / 177.068 / 177.394 / 177.451 / 177.46 / 0.273547 n=30
>>synmark:OglBatch5: 46.59 (+0.00%): min/p50/90/95/99/max/std = 
>> 45.9918 / 46.6053 / 46.819 / 46.842 / 46.8459 / 46.8538 / 0.26363 n=30
>>synmark:OglBatch5:cpu: 52.79 (+0.00%): min/p50/90/95/99/max/std = 
>> 52.1812 / 52.6714 / 53.3544 / 53.3605 / 53.3726 / 53.4059 / 0.402148 n=30
>>synmark:OglBatch6: 11.95 (+0.00%): min/p50/90/95/99/max/std = 
>> 11.7449 / 11.9523 / 12.0025 / 12.0026 / 12.0097 / 12.0304 / 0.0771611 n=30
>>synmark:OglBatch6:cpu: 14.17 (+0.00%): min/p50/90/95/99/max/std = 
>> 14.0292 / 14.169 / 14.1863 / 14.1889 / 14.1963 / 14.1999 / 0.0387371 n=30
>>synmark:OglBatch7:  3.04 (+0.00%): min/p50/90/95/99/max/std = 
>> 3.00939 / 3.03578 / 3.05513 / 3.0 / 3.05582 / 3.05847 / 0.0148493 n=30
>>synmark:OglBatch7:cpu:  3.66 (+0.00%): min/p50/90/95/99/max/std = 
>> 3.63355 / 3.66219 / 3.66685 / 3.66706 / 3.66789 / 3.66943 / 0.00683119 n=30
>> Patched
>>synmark:OglBatch3:276.06 (-0.35%): min/p50/90/95/99/max/std = 
>> 269.608 / 276.098 / 277.25 / 277.354 / 277.967 / 278.013 / 2.0933 n=30
>>synmark:OglBatch3:cpu:415.49 (-4.47%): min/p50/90/95/99/max/std = 
>> 412.316 / 415.554 / 417.828 / 417.9 / 418.471 / 419.22 / 1.84629 n=30
>>synmark:OglBatch4:144.26 (-6.78%): min/p50/90/95/99/max/std = 
>> 143.126 / 144.188 / 145.026 / 145.114 / 145.126 / 145.356 / 0.527859 n=30
>>synmark:OglBatch4:cpu:161.82 (-8.49%): min/p50/90/95/99/max/std = 
>> 161.247 / 161.82 / 162.12 / 162.169 / 162.172 / 162.222 / 0.254633 n=30
>>synmark:OglBatch5: 42.44 (-8.91%): min/p50/90/95/99/max/std = 
>> 41.856 / 42.4856 / 42.7209 / 42.8424 / 42.8436 / 42.8441 / 0.287101 n=30
>>synmark:OglBatch5:cpu: 47.90 (-9.27%): min/p50/90/95/99/max/std = 
>> 47.4268 / 47.7758 / 48.4164 / 48.4775 / 48.5086 / 48.5284 / 0.341355 n=30
>>synmark:OglBatch6: 10.86 (-9.09%): min/p50/90/95/99/max/std = 
>> 10.7564 / 10.8818 / 10.9238 / 10.926 / 10.9279 / 10.9535 / 0.0619808 n=30
>>synmark:OglBatch6:cpu: 12.80 (-9.62%): min/p50/90/95/99/max/std = 
>> 12.7149 / 12.8064 / 12.8179 / 12.8228 / 12.8249 / 12.8255 / 0.0235037 n=30
>>synmark:OglBatch7:  2.76 (-9.02%): min/p50/90/95/99/max/std = 
>> 2.74078 / 2.7634 / 2.77936 / 2.78025 / 2.78254 / 2.7827 / 0.0126239 n=30
>>synmark:OglBatch7:cpu:  3.29 (-10.12%): min/p50/90/95/99/max/std 
>> = 3.26676 / 3.29127 / 3.29445 / 3.29464 / 3.29472 / 3.29616 / 0.0072781 n=30
>>
>>
>> 6994ca2 glsl: fix whitespace
>>synmark:OglBatch3:276.90 (+0.00%): min/p50/90/95/99/max/std = 
>> 274.104 / 276.81 / 277.697 / 278.063 / 278.067 / 278.505 / 0.914328 n=30
>>synmark:OglBatch3:cpu:434.96 (+0.00%): min/p50/90/95/99/max/std = 
>> 429.492 / 434.784 / 437.174 / 437.482 / 437.548 / 439.812 / 2.09205 n=30
>>synmark:OglBatch4:154.06 (+0.00%): min/p50/90/95/99/max/std = 
>> 152.336 / 153.995 / 155.37 / 155.446 / 155.544 / 155.636 / 0.919322 n=30
>>synmark:OglBatch4:cpu:176.45 (+0.00%): 

[Mesa-dev] Problems with accuracy of coeffs_init + attribs_update

2015-10-29 Thread Oded Gabbay
Hi Roland, Jose

I wanted to bring a problem I found to your attention, and discuss
about it and ways to solve it.

I'm working on regressions of piglit gpu.py between x86-64 and
ppc64le, when running with llvmpipe.

One of the regressions manifests itself in 2 tests,
clip-distance-bulk-copy and clip-distance-itemized-copy

What happens in ppc64le is that *some* of the interpolated per-vertex
values (clip-distance values) that constitute the input into the
fragment shader, are not calculated according to the required accuracy
of the test (which is an error/distance of less than 1e-6)

It took a while, but I believe I found the reason. In general, when
running on ppc64le, the code path that is taken at
lp_build_interp_soa_init() is doing  bld->simple_interp = FALSE, which
means using coeffs_init() + attribs_update(). That's in contrast with
x86-64, where bld->simple_interp = TRUE, which means the code will use
coeffs_init_simple() + attribs_update_simple()

In specific, the problem lies in how the coeffs are calculated inside
coeffs_init. To simply put it, they are only *actually* calculated
correctly for the first quad. The coeffs are later *updated* for the
other quads, using dadx/dady and dadq.

--
side-note:
I believe you even documented it in coeffs_init():
  /*
   * a = a0 + (x * dadx + y * dady)
   * a0aos is the attrib value at top left corner of stamp
   */
--

The root cause for that, I believe, is because coeffs_init does *not*
take into account the different x/y offsets for the other quads. In
contrast, on x86-64, the code uses a function called calc_offset(),
which does take the different x/y offsets into account.

Please look at this definition (from lp_bld_interp.c) :

static const unsigned char quad_offset_x[16] = {0, 1, 0, 1, 2, 3, 2,
3, 0, 1, 0, 1, 2, 3, 2, 3};
static const unsigned char quad_offset_y[16] = {0, 0, 1, 1, 0, 0, 1,
1, 2, 2, 3, 3, 2, 2, 3, 3};

Now, look at how coeffs_init() uses them:

   for (i = 0; i < coeff_bld->type.length; i++) {
  LLVMValueRef nr = lp_build_const_int32(gallivm, i);
  LLVMValueRef pixxf = lp_build_const_float(gallivm, quad_offset_x[i]);
  LLVMValueRef pixyf = lp_build_const_float(gallivm, quad_offset_y[i]);
  pixoffx = LLVMBuildInsertElement(builder, pixoffx, pixxf, nr, "");
  pixoffy = LLVMBuildInsertElement(builder, pixoffy, pixyf, nr, "");
   }

So, in ppc64le, where coeff_bld->type.length == 4, we *always* take
the first four values from the above arrays. The code *never*
calculates the coeffs based on the other offsets.

Admittedly, that's *almost* always works and I doubt you will see a
difference in display. However, in the tests I mentioned above, it
creates, for some pixels, a bigger error than what is allowed.

The first thing that came into my mind was to change, in
lp_build_interp_soa_init():

"if (coeff_type.length > 4)"
to this:
"if (coeff_type.length >= 4)"

When I did that, I saw it fixes the above tests and didn't cause any
regressions on ppc64le and/or on x86-64.

However, I wanted to ask you guys if you remember why you allowed only
vectors with size above 4 to use the "simple" route ?
Was there any performance hit ?

I think that to fix coeffs_init()+attribs_update() is to basically
re-design them. Otherwise, I would have tried to fix them first.

In any case, I would love to hear your feedback and to discuss this further.

Thanks,

 Oded
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v3] r600g: Fix special negative immediate constants when using ABS modifier.

2015-10-29 Thread Emil Velikov
On 29 October 2015 at 09:24, Ivan Kalvachev  wrote:
> On 10/29/15, Ilia Mirkin  wrote:
>> On Wed, Oct 28, 2015 at 8:52 PM, Ivan Kalvachev 
>> wrote:
>>> I'm attaching v3 of the patch. Same as v2, but without the extra empty
>>> line.
>>
>> FYI, there's a lot of overhead to reviewing an attached patch (in
>> fact, gmail makes it extra difficult since you can't even see the
>> thing in the name of protection from the unknown). Please use 'git
>> send-email' (or equivalent mechanism) to make the patches appear
>> inline.
>>
>> Cheers,
>>
>>   -ilia
>
> Sorry about that.
> I did inline my v1 patch, to easy the review.
>
> Configuring smtp server is too much hassle for a single patch and I
> would like to avoid writing my email credentials if possible.
> If I'm about to send more patches, then I guess I would have to do that.
>
> I suspect that it is not possible to send mail directly to
> lists.freedesktop.org mail server, is it?
>
Setting things up it's as trivial as adding the following lines to
your $HOME/.config/git/config

[sendemail]
   smtpuser = ikalvac...@gmail.com
   smtpencryption = tls
   smtpserverport = 587
   smtpserver = smtp.gmail.com

For ease of use you can also set the TO address in
$(mesa_top)/.git/config. You can also move the above setup in here.

[sendemail]
   to = mesa-dev@lists.freedesktop.org


-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 1/2] st/va: implement VaDeriveImage

2015-10-29 Thread Christian König

Patch #1:

+   if (buf->data)
+ FREE(buf->data);

FREE() usually does a NULL check anyway.

Apart from that minor nitpick the patch is Reviewed-by: Christian König 



Regards,
Christian.

On 29.10.2015 12:47, Julien Isorce wrote:

And apply relatives change to:
vlVaBufferSetNumElements
vlVaCreateBuffer
vlVaMapBuffer
vlVaUnmapBuffer
vlVaDestroyBuffer
vlVaPutImage

It is unfortunate that there is no proper va buffer type and struct
for this. Only possible to use VAImageBufferType which is normally
used for normal user data array.
On of the consequences is that it is only possible VaDeriveImage
is only useful on surfaces backed with contiguous planes.
Implementation inspired from cgit.freedesktop.org/vaapi/intel-driver

Signed-off-by: Julien Isorce 
---
  src/gallium/state_trackers/va/buffer.c | 47 +--
  src/gallium/state_trackers/va/image.c  | 92 +-
  src/gallium/state_trackers/va/va_private.h |  5 ++
  3 files changed, 138 insertions(+), 6 deletions(-)

diff --git a/src/gallium/state_trackers/va/buffer.c 
b/src/gallium/state_trackers/va/buffer.c
index 8f9ba44..b619d0b 100644
--- a/src/gallium/state_trackers/va/buffer.c
+++ b/src/gallium/state_trackers/va/buffer.c
@@ -26,8 +26,11 @@
   *
   **/
  
+#include "pipe/p_screen.h"

  #include "util/u_memory.h"
  #include "util/u_handle_table.h"
+#include "util/u_transfer.h"
+#include "vl/vl_winsys.h"
  
  #include "va_private.h"
  
@@ -73,6 +76,10 @@ vlVaBufferSetNumElements(VADriverContextP ctx, VABufferID buf_id,

return VA_STATUS_ERROR_INVALID_CONTEXT;
  
 buf = handle_table_get(VL_VA_DRIVER(ctx)->htab, buf_id);

+
+   if (!buf || buf->derived_surface.resource)
+  return VA_STATUS_ERROR_INVALID_BUFFER;
+
 buf->data = REALLOC(buf->data, buf->size * buf->num_elements,
 buf->size * num_elements);
 buf->num_elements = num_elements;
@@ -86,16 +93,32 @@ vlVaBufferSetNumElements(VADriverContextP ctx, VABufferID 
buf_id,
  VAStatus
  vlVaMapBuffer(VADriverContextP ctx, VABufferID buf_id, void **pbuff)
  {
+   vlVaDriver *drv;
 vlVaBuffer *buf;
  
 if (!ctx)

return VA_STATUS_ERROR_INVALID_CONTEXT;
  
-   buf = handle_table_get(VL_VA_DRIVER(ctx)->htab, buf_id);

+   if (!pbuff)
+  return VA_STATUS_ERROR_INVALID_BUFFER;
+
+   drv = VL_VA_DRIVER(ctx);
+
+   buf = handle_table_get(drv->htab, buf_id);
 if (!buf)
return VA_STATUS_ERROR_INVALID_BUFFER;
  
-   *pbuff = buf->data;

+   if (buf->derived_surface.resource) {
+  *pbuff = pipe_buffer_map(drv->pipe, buf->derived_surface.resource,
+   PIPE_TRANSFER_WRITE,
+   >derived_surface.transfer);
+
+  if (!buf->derived_surface.transfer || !*pbuff)
+ return VA_STATUS_ERROR_INVALID_BUFFER;
+
+   } else {
+  *pbuff = buf->data;
+   }
  
 return VA_STATUS_SUCCESS;

  }
@@ -103,16 +126,25 @@ vlVaMapBuffer(VADriverContextP ctx, VABufferID buf_id, 
void **pbuff)
  VAStatus
  vlVaUnmapBuffer(VADriverContextP ctx, VABufferID buf_id)
  {
+   vlVaDriver *drv;
 vlVaBuffer *buf;
  
 if (!ctx)

return VA_STATUS_ERROR_INVALID_CONTEXT;
  
-   buf = handle_table_get(VL_VA_DRIVER(ctx)->htab, buf_id);

+   drv = VL_VA_DRIVER(ctx);
+
+   buf = handle_table_get(drv->htab, buf_id);
 if (!buf)
return VA_STATUS_ERROR_INVALID_BUFFER;
  
-   /* Nothing to do here */

+   if (buf->derived_surface.resource) {
+ if (!buf->derived_surface.transfer)
+return VA_STATUS_ERROR_INVALID_BUFFER;
+
+ pipe_buffer_unmap(drv->pipe, buf->derived_surface.transfer);
+ buf->derived_surface.transfer = NULL;
+   }
  
 return VA_STATUS_SUCCESS;

  }
@@ -129,7 +161,12 @@ vlVaDestroyBuffer(VADriverContextP ctx, VABufferID buf_id)
 if (!buf)
return VA_STATUS_ERROR_INVALID_BUFFER;
  
-   FREE(buf->data);

+   if (buf->data)
+ FREE(buf->data);
+
+   if (buf->derived_surface.resource)
+ pipe_resource_reference(>derived_surface.resource, NULL);
+
 FREE(buf);
 handle_table_remove(VL_VA_DRIVER(ctx)->htab, buf_id);
  
diff --git a/src/gallium/state_trackers/va/image.c b/src/gallium/state_trackers/va/image.c

index 8e64673..f266ce8 100644
--- a/src/gallium/state_trackers/va/image.c
+++ b/src/gallium/state_trackers/va/image.c
@@ -184,10 +184,95 @@ vlVaCreateImage(VADriverContextP ctx, VAImageFormat 
*format, int width, int heig
  VAStatus
  vlVaDeriveImage(VADriverContextP ctx, VASurfaceID surface, VAImage *image)
  {
+   vlVaDriver *drv;
+   vlVaSurface *surf;
+   vlVaBuffer *img_buf;
+   VAImage *img;
+   struct pipe_surface **surfaces;
+   int w;
+   int h;
+   int i;
+
 if (!ctx)
return VA_STATUS_ERROR_INVALID_CONTEXT;
  
-   return VA_STATUS_ERROR_UNIMPLEMENTED;

+   drv = VL_VA_DRIVER(ctx);
+
+   if (!drv)
+  return VA_STATUS_ERROR_INVALID_CONTEXT;
+
+   surf 

[Mesa-dev] [PATCH 14/15] virgl: unwrap the includes

2015-10-29 Thread Emil Velikov
Include what you want, rather than relying on a header foo.h N levels
down the include chain, to provide something that you need.

Signed-off-by: Emil Velikov 
---
 src/gallium/drivers/virgl/virgl_buffer.c|  2 ++
 src/gallium/drivers/virgl/virgl_context.c   |  7 ++-
 src/gallium/drivers/virgl/virgl_context.h   | 10 --
 src/gallium/drivers/virgl/virgl_encode.c|  8 ++--
 src/gallium/drivers/virgl/virgl_encode.h| 12 +++-
 src/gallium/drivers/virgl/virgl_query.c |  3 ++-
 src/gallium/drivers/virgl/virgl_resource.c  |  3 ++-
 src/gallium/drivers/virgl/virgl_resource.h  |  4 +++-
 src/gallium/drivers/virgl/virgl_screen.c|  3 ---
 src/gallium/drivers/virgl/virgl_screen.h|  7 ++-
 src/gallium/drivers/virgl/virgl_streamout.c |  3 ++-
 src/gallium/drivers/virgl/virgl_texture.c   |  8 +---
 src/gallium/drivers/virgl/virgl_winsys.h|  5 -
 src/gallium/winsys/virgl/drm/virgl_drm_winsys.c | 21 +
 src/gallium/winsys/virgl/drm/virgl_drm_winsys.h | 12 ++--
 src/gallium/winsys/virgl/vtest/virgl_vtest_public.h |  1 +
 src/gallium/winsys/virgl/vtest/virgl_vtest_socket.c |  6 --
 src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.c |  7 ---
 src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.h |  6 +++---
 19 files changed, 72 insertions(+), 56 deletions(-)

diff --git a/src/gallium/drivers/virgl/virgl_buffer.c 
b/src/gallium/drivers/virgl/virgl_buffer.c
index 13e8384..ce19fb9 100644
--- a/src/gallium/drivers/virgl/virgl_buffer.c
+++ b/src/gallium/drivers/virgl/virgl_buffer.c
@@ -21,9 +21,11 @@
  * USE OR OTHER DEALINGS IN THE SOFTWARE.
  */
 
+#include "util/u_inlines.h"
 #include "util/u_memory.h"
 #include "virgl_context.h"
 #include "virgl_resource.h"
+#include "virgl_screen.h"
 
 static void virgl_buffer_destroy(struct pipe_screen *screen,
  struct pipe_resource *buf)
diff --git a/src/gallium/drivers/virgl/virgl_context.c 
b/src/gallium/drivers/virgl/virgl_context.c
index 32dde06..cae6352 100644
--- a/src/gallium/drivers/virgl/virgl_context.c
+++ b/src/gallium/drivers/virgl/virgl_context.c
@@ -36,19 +36,16 @@
 #include "util/u_upload_mgr.h"
 #include "util/u_blitter.h"
 #include "tgsi/tgsi_text.h"
+#include "indices/u_primconvert.h"
 
 #include "pipebuffer/pb_buffer.h"
 #include "state_tracker/graw.h"
-#include "state_tracker/drm_driver.h"
 
 #include "virgl_encode.h"
-
 #include "virgl_context.h"
-
+#include "virgl_protocol.h"
 #include "virgl_resource.h"
 #include "virgl_screen.h"
-#include "state_tracker/sw_winsys.h"
- struct pipe_screen encscreen;
 
 static uint32_t next_handle;
 uint32_t virgl_object_assign_handle(void)
diff --git a/src/gallium/drivers/virgl/virgl_context.h 
b/src/gallium/drivers/virgl/virgl_context.h
index 3d8d3ce..adb8ade 100644
--- a/src/gallium/drivers/virgl/virgl_context.h
+++ b/src/gallium/drivers/virgl/virgl_context.h
@@ -25,15 +25,13 @@
 
 #include "pipe/p_state.h"
 #include "pipe/p_context.h"
-#include "virgl_protocol.h"
-
-#include "virgl_screen.h"
 #include "util/u_slab.h"
 #include "util/list.h"
-#include "indices/u_primconvert.h"
 
-struct virgl_resource;
-struct virgl_buffer;
+struct pipe_screen;
+struct tgsi_token;
+struct u_upload_mgr;
+struct virgl_cmd_buf;
 
 struct virgl_sampler_view {
struct pipe_sampler_view base;
diff --git a/src/gallium/drivers/virgl/virgl_encode.c 
b/src/gallium/drivers/virgl/virgl_encode.c
index 4493c3f..22fb529 100644
--- a/src/gallium/drivers/virgl/virgl_encode.c
+++ b/src/gallium/drivers/virgl/virgl_encode.c
@@ -25,11 +25,15 @@
 #include "util/u_memory.h"
 #include "util/u_math.h"
 #include "pipe/p_state.h"
-#include "virgl_encode.h"
-#include "virgl_resource.h"
 #include "tgsi/tgsi_dump.h"
 #include "tgsi/tgsi_parse.h"
 
+#include "virgl_context.h"
+#include "virgl_encode.h"
+#include "virgl_protocol.h"
+#include "virgl_resource.h"
+#include "virgl_screen.h"
+
 static int virgl_encoder_write_cmd_dword(struct virgl_context *ctx,
 uint32_t dword)
 {
diff --git a/src/gallium/drivers/virgl/virgl_encode.h 
b/src/gallium/drivers/virgl/virgl_encode.h
index d792369..030bcd6 100644
--- a/src/gallium/drivers/virgl/virgl_encode.h
+++ b/src/gallium/drivers/virgl/virgl_encode.h
@@ -23,7 +23,17 @@
 #ifndef VIRGL_ENCODE_H
 #define VIRGL_ENCODE_H
 
-#include "virgl_context.h"
+#include "pipe/p_defines.h"
+#include "pipe/p_state.h"
+
+#include "virgl_winsys.h"
+
+struct tgsi_token;
+
+struct virgl_context;
+struct virgl_resource;
+struct virgl_sampler_view;
+
 struct virgl_surface {
struct pipe_surface base;
uint32_t handle;
diff --git a/src/gallium/drivers/virgl/virgl_query.c 
b/src/gallium/drivers/virgl/virgl_query.c
index b06635b..b020055 100644
--- a/src/gallium/drivers/virgl/virgl_query.c
+++ b/src/gallium/drivers/virgl/virgl_query.c
@@ -23,9 +23,10 @@
 

[Mesa-dev] [PATCH 01/15] virgl: move virgl_hw.h into the driver dir

2015-10-29 Thread Emil Velikov
Strictly speaking virgl_hw.h should reside in the driver folder, as
it describes the hardware. Moving it allows us to nuke the following
strange dependency

winsys/vtest > driver > winsys/drm

Signed-off-by: Emil Velikov 
---
 src/gallium/drivers/virgl/Makefile.sources |   1 +
 src/gallium/drivers/virgl/virgl.h  |   2 +-
 src/gallium/drivers/virgl/virgl_hw.h   | 286 +
 src/gallium/drivers/virgl/virgl_resource.h |   2 +-
 src/gallium/winsys/virgl/drm/Makefile.am   |   1 -
 src/gallium/winsys/virgl/drm/Makefile.sources  |   1 -
 src/gallium/winsys/virgl/drm/virgl_drm_winsys.h|   2 +-
 src/gallium/winsys/virgl/drm/virgl_hw.h| 286 -
 src/gallium/winsys/virgl/vtest/Makefile.am |   1 -
 .../winsys/virgl/vtest/virgl_vtest_winsys.h|   2 +-
 10 files changed, 291 insertions(+), 293 deletions(-)
 create mode 100644 src/gallium/drivers/virgl/virgl_hw.h
 delete mode 100644 src/gallium/winsys/virgl/drm/virgl_hw.h

diff --git a/src/gallium/drivers/virgl/Makefile.sources 
b/src/gallium/drivers/virgl/Makefile.sources
index df010c0..ed309ae 100644
--- a/src/gallium/drivers/virgl/Makefile.sources
+++ b/src/gallium/drivers/virgl/Makefile.sources
@@ -5,6 +5,7 @@ C_SOURCES := \
virgl_encode.c \
virgl_encode.h \
virgl.h \
+   virgl_hw.h \
virgl_protocol.h \
virgl_public.h \
virgl_query.c \
diff --git a/src/gallium/drivers/virgl/virgl.h 
b/src/gallium/drivers/virgl/virgl.h
index ecd997b..d64576c 100644
--- a/src/gallium/drivers/virgl/virgl.h
+++ b/src/gallium/drivers/virgl/virgl.h
@@ -25,7 +25,7 @@
 
 #include "util/u_transfer.h"
 
-#include "virgl/drm/virgl_hw.h"
+#include "virgl_hw.h"
 
 #include "virgl_winsys.h"
 #include "pipe/p_screen.h"
diff --git a/src/gallium/drivers/virgl/virgl_hw.h 
b/src/gallium/drivers/virgl/virgl_hw.h
new file mode 100644
index 000..e3c56db
--- /dev/null
+++ b/src/gallium/drivers/virgl/virgl_hw.h
@@ -0,0 +1,286 @@
+/*
+ * Copyright 2014, 2015 Red Hat.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * on the rights to use, copy, modify, merge, publish, distribute, sub
+ * license, and/or sell copies of the Software, and to permit persons to whom
+ * the Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHOR(S) AND/OR THEIR SUPPLIERS BE LIABLE FOR ANY CLAIM,
+ * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
+ * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
+ * USE OR OTHER DEALINGS IN THE SOFTWARE.
+ */
+#ifndef VIRGL_HW_H
+#define VIRGL_HW_H
+
+struct virgl_box {
+   uint32_t x, y, z;
+   uint32_t w, h, d;
+};
+
+/* formats known by the HW device - based on gallium subset */
+enum virgl_formats {
+   VIRGL_FORMAT_B8G8R8A8_UNORM  = 1,
+   VIRGL_FORMAT_B8G8R8X8_UNORM  = 2,
+   VIRGL_FORMAT_A8R8G8B8_UNORM  = 3,
+   VIRGL_FORMAT_X8R8G8B8_UNORM  = 4,
+   VIRGL_FORMAT_B5G5R5A1_UNORM  = 5,
+   VIRGL_FORMAT_B4G4R4A4_UNORM  = 6,
+   VIRGL_FORMAT_B5G6R5_UNORM= 7,
+   VIRGL_FORMAT_L8_UNORM= 9,/**< ubyte luminance */
+   VIRGL_FORMAT_A8_UNORM= 10,   /**< ubyte alpha */
+   VIRGL_FORMAT_L8A8_UNORM  = 12,   /**< ubyte alpha, luminance */
+   VIRGL_FORMAT_L16_UNORM   = 13,   /**< ushort luminance */
+
+   VIRGL_FORMAT_Z16_UNORM   = 16,
+   VIRGL_FORMAT_Z32_UNORM   = 17,
+   VIRGL_FORMAT_Z32_FLOAT   = 18,
+   VIRGL_FORMAT_Z24_UNORM_S8_UINT   = 19,
+   VIRGL_FORMAT_S8_UINT_Z24_UNORM   = 20,
+   VIRGL_FORMAT_Z24X8_UNORM = 21,
+   VIRGL_FORMAT_S8_UINT = 23,   /**< ubyte stencil */
+
+   VIRGL_FORMAT_R32_FLOAT   = 28,
+   VIRGL_FORMAT_R32G32_FLOAT= 29,
+   VIRGL_FORMAT_R32G32B32_FLOAT = 30,
+   VIRGL_FORMAT_R32G32B32A32_FLOAT  = 31,
+
+   VIRGL_FORMAT_R16_UNORM   = 48,
+   VIRGL_FORMAT_R16G16_UNORM= 49,
+
+   VIRGL_FORMAT_R16G16B16A16_UNORM  = 51,
+
+   VIRGL_FORMAT_R16_SNORM   = 56,
+   VIRGL_FORMAT_R16G16_SNORM= 57,
+   VIRGL_FORMAT_R16G16B16A16_SNORM  = 59,
+
+   VIRGL_FORMAT_R8_UNORM= 64,
+   VIRGL_FORMAT_R8G8_UNORM  = 65,
+

Re: [Mesa-dev] [PATCH 0/7] st/va: VPP, dmabuf import and headless.

2015-10-29 Thread Christian König

Hi Julien,

if Emil or Ilia have no further comments please send out your full set 
of patches once more I would like to get this pusched upstream.


Best regards,
Christian.

On 17.10.2015 01:14, Julien Isorce wrote:

This patch serie adds initial support for Video Post Processing.
It also implements VaCreateSurfaces2 for common purpose and
also to import a dmabuf.
Finally it adds support for headless mode, i.e. using DRM
instead of X11 for device setup.

Julien Isorce (7):
   nvc0: fix crash when nv50_miptree_from_handle fails
   st/va: properly defines VAImageFormat formats and improve
 VaCreateImage
   st/va: in VaPutImage only destroy previous buffer if
 pipe->create_video_buffer succeeds
   st/va: implement VaCreateSurfaces2 and VaQuerySurfaceAttributes
   st/va: implement dmabuf import for VaCreateSurfaces2
   st/va: add initial Video Post Processing support
   st/va: add headless support, i.e. VA_DISPLAY_DRM

  src/gallium/drivers/nouveau/nvc0/nvc0_resource.c |   3 +-
  src/gallium/state_trackers/va/Makefile.am|   9 +
  src/gallium/state_trackers/va/config.c   |  20 +
  src/gallium/state_trackers/va/context.c  | 148 ++--
  src/gallium/state_trackers/va/image.c|  29 +-
  src/gallium/state_trackers/va/picture.c  |  89 -
  src/gallium/state_trackers/va/surface.c  | 449 ---
  src/gallium/state_trackers/va/va_private.h   |  59 ++-
  8 files changed, 706 insertions(+), 100 deletions(-)



___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v3] r600g: Fix special negative immediate constants when using ABS modifier.

2015-10-29 Thread Felix Schwarz
Am 29.10.2015 um 10:24 schrieb Ivan Kalvachev:
> Configuring smtp server is too much hassle for a single patch and I
> would like to avoid writing my email credentials if possible.
> If I'm about to send more patches, then I guess I would have to do that.

You might want to look into "git imap-send" and/or "git format-patch --stdout"
so git can generate emails which you can send with an email client like
thunderbird. That way you also get a nice way to "preview" the
messages/patches you are going to send.

Felix

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v2 7/8] st/va: add colospace conversion through Video Post Processing

2015-10-29 Thread Christian König

+if(src_surface->fence) {
+   screen->fence_finish(screen, src_surface->fence, PIPE_TIMEOUT_INFINITE);
+   screen->fence_reference(screen, _surface->fence, NULL);
+}
That shouldn't be necessary cause all render operations to the same 
surface are pipelined anyway.


Regards,
Christian.

On 22.10.2015 18:37, Julien Isorce wrote:

Add support for VPP in the following functions:
vlVaCreateContext
vlVaDestroyContext
vlVaBeginPicture
vlVaRenderPicture
vlVaEndPicture

Add support for VAProcFilterNone in:
vlVaQueryVideoProcFilters
vlVaQueryVideoProcFilterCaps
vlVaQueryVideoProcPipelineCaps

Add handleVAProcPipelineParameterBufferType helper.

One application is:
VASurfaceNV12 -> gstvaapipostproc -> VASurfaceRGBA

Signed-off-by: Julien Isorce 
---
  src/gallium/state_trackers/va/context.c| 91 +--
  src/gallium/state_trackers/va/picture.c| 86 +-
  src/gallium/state_trackers/va/surface.c| 98 +-
  src/gallium/state_trackers/va/va_private.h |  8 +++
  4 files changed, 248 insertions(+), 35 deletions(-)

diff --git a/src/gallium/state_trackers/va/context.c 
b/src/gallium/state_trackers/va/context.c
index 9be9085..170e9d6 100644
--- a/src/gallium/state_trackers/va/context.c
+++ b/src/gallium/state_trackers/va/context.c
@@ -87,6 +87,14 @@ static struct VADriverVTable vtable =
 
  };
  
+static struct VADriverVTableVPP vtable_vpp =

+{
+   1,
+   ,
+   ,
+   
+};
+
  PUBLIC VAStatus
  VA_DRIVER_INIT_FUNC(VADriverContextP ctx)
  {
@@ -122,6 +130,7 @@ VA_DRIVER_INIT_FUNC(VADriverContextP ctx)
 ctx->version_major = 0;
 ctx->version_minor = 1;
 *ctx->vtable = vtable;
+   *ctx->vtable_vpp = vtable_vpp;
 ctx->max_profiles = PIPE_VIDEO_PROFILE_MPEG4_AVC_HIGH - 
PIPE_VIDEO_PROFILE_UNKNOWN;
 ctx->max_entrypoints = 1;
 ctx->max_attributes = 1;
@@ -151,11 +160,15 @@ vlVaCreateContext(VADriverContextP ctx, VAConfigID 
config_id, int picture_width,
 struct pipe_video_codec templat = {};
 vlVaDriver *drv;
 vlVaContext *context;
+   int is_vpp;
  
 if (!ctx)

return VA_STATUS_ERROR_INVALID_CONTEXT;
  
-   if (!(picture_width && picture_height))

+   is_vpp = config_id == PIPE_VIDEO_PROFILE_UNKNOWN && !picture_width &&
+!picture_height && !flag && !render_targets && !num_render_targets;
+
+   if (!(picture_width && picture_height) && !is_vpp)
return VA_STATUS_ERROR_INVALID_IMAGE_FORMAT;
  
 drv = VL_VA_DRIVER(ctx);

@@ -163,38 +176,46 @@ vlVaCreateContext(VADriverContextP ctx, VAConfigID 
config_id, int picture_width,
 if (!context)
return VA_STATUS_ERROR_ALLOCATION_FAILED;
  
-   templat.profile = config_id;

-   templat.entrypoint = PIPE_VIDEO_ENTRYPOINT_BITSTREAM;
-   templat.chroma_format = PIPE_VIDEO_CHROMA_FORMAT_420;
-   templat.width = picture_width;
-   templat.height = picture_height;
-   templat.max_references = num_render_targets;
-   templat.expect_chunked_decode = true;
-
-   if (u_reduce_video_profile(templat.profile) ==
-   PIPE_VIDEO_FORMAT_MPEG4_AVC)
-  templat.level = u_get_h264_level(templat.width, templat.height,
-_references);
-
-   context->decoder = drv->pipe->create_video_codec(drv->pipe, );
-   if (!context->decoder) {
-  FREE(context);
-  return VA_STATUS_ERROR_ALLOCATION_FAILED;
-   }
-
-   if (u_reduce_video_profile(context->decoder->profile) ==
- PIPE_VIDEO_FORMAT_MPEG4_AVC) {
-  context->desc.h264.pps = CALLOC_STRUCT(pipe_h264_pps);
-  if (!context->desc.h264.pps) {
+   if (is_vpp) {
+  context->decoder = NULL;
+  if (!drv->compositor.upload) {
   FREE(context);
- return VA_STATUS_ERROR_ALLOCATION_FAILED;
+ return VA_STATUS_ERROR_INVALID_CONTEXT;
}
-  context->desc.h264.pps->sps = CALLOC_STRUCT(pipe_h264_sps);
-  if (!context->desc.h264.pps->sps) {
- FREE(context->desc.h264.pps);
+   } else {
+  templat.profile = config_id;
+  templat.entrypoint = PIPE_VIDEO_ENTRYPOINT_BITSTREAM;
+  templat.chroma_format = PIPE_VIDEO_CHROMA_FORMAT_420;
+  templat.width = picture_width;
+  templat.height = picture_height;
+  templat.max_references = num_render_targets;
+  templat.expect_chunked_decode = true;
+
+  if (u_reduce_video_profile(templat.profile) ==
+PIPE_VIDEO_FORMAT_MPEG4_AVC)
+templat.level = u_get_h264_level(templat.width, templat.height,
+ _references);
+
+  context->decoder = drv->pipe->create_video_codec(drv->pipe, );
+  if (!context->decoder) {
   FREE(context);
   return VA_STATUS_ERROR_ALLOCATION_FAILED;
}
+
+  if (u_reduce_video_profile(context->decoder->profile) ==
+ PIPE_VIDEO_FORMAT_MPEG4_AVC) {
+ context->desc.h264.pps = CALLOC_STRUCT(pipe_h264_pps);
+ if (!context->desc.h264.pps) {
+FREE(context);
+return 

[Mesa-dev] [PATCH] mesa: DispatchComputeIndirect should return INVALID_VALUE on unaligned

2015-10-29 Thread Marta Lofstedt
From: Marta Lofstedt 

From the ARB_compute_shader specification:

"An INVALID_OPERATION error is generated [...] if  is
less than zero or not a multiple of the size, in basic machine
units, of uint."

However, OpenGL ES 3.1 specification, section 17 and OpenGL 4.5
specification, section 19, has the updated definition:

"An INVALID_VALUE error is generated if indirect is negative or
is not a multiple of the size, in basic machine units, of uint."

Mesa should use the updated version.
---
 src/mesa/main/api_validate.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/src/mesa/main/api_validate.c b/src/mesa/main/api_validate.c
index 06efe02..9ee8252 100644
--- a/src/mesa/main/api_validate.c
+++ b/src/mesa/main/api_validate.c
@@ -960,14 +960,15 @@ valid_dispatch_indirect(struct gl_context *ctx,
if (!check_valid_to_compute(ctx, name))
   return GL_FALSE;
 
-   /* From the ARB_compute_shader specification:
+   /* From the OpenGL ES 3.1 specification, section 17 and the
+* OpenGL 4.5 specification, section 19:
 *
-* "An INVALID_OPERATION error is generated [...] if  is less
-*  than zero or not a multiple of the size, in basic machine units, of
-*  uint."
+*   "An INVALID_VALUE error is generated if indirect is negative
+*or is not a multiple of the size, in basic machine units,
+*of uint."
 */
if ((GLintptr)indirect & (sizeof(GLuint) - 1)) {
-  _mesa_error(ctx, GL_INVALID_OPERATION,
+  _mesa_error(ctx, GL_INVALID_VALUE,
   "%s(indirect is not aligned)", name);
   return GL_FALSE;
}
-- 
2.1.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 2/2] st/va: add support to export a surface as dmabuf

2015-10-29 Thread Christian König

@@ -108,6 +109,9 @@ vlVaMapBuffer(VADriverContextP ctx, VABufferID buf_id, void 
**pbuff)
 if (!buf)
return VA_STATUS_ERROR_INVALID_BUFFER;
  
+   if (buf->export_refcount > 0)

+  return VA_STATUS_ERROR_INVALID_BUFFER;

Why it is illegal to CPU map a buffer which is exported?


+  switch (buf_info->mem_type) {
+  case VA_SURFACE_ATTRIB_MEM_TYPE_DRM_PRIME:
+ close((intptr_t)buf_info->handle);
+ break;
Seriously? Are you sure this is correct? The VA-API driver is supposed 
to close the prime handle? Not the application?


Regards,
Christian.

On 29.10.2015 12:47, Julien Isorce wrote:

I.e. implements:
VaAcquireBufferHandle
VaReleaseBufferHandle
for memory of type VA_SURFACE_ATTRIB_MEM_TYPE_DRM_PRIME

And apply relatives change to:
vlVaMapBuffer
vlVaUnMapBuffer
vlVaDestroyBuffer

Implementation inspired from cgit.freedesktop.org/vaapi/intel-driver

Tested with gstreamer-vaapi with nouveau driver.

Signed-off-by: Julien Isorce 
---
  src/gallium/state_trackers/va/buffer.c | 136 -
  src/gallium/state_trackers/va/context.c|   4 +-
  src/gallium/state_trackers/va/va_private.h |   6 ++
  3 files changed, 144 insertions(+), 2 deletions(-)

diff --git a/src/gallium/state_trackers/va/buffer.c 
b/src/gallium/state_trackers/va/buffer.c
index b619d0b..4ad20d2 100644
--- a/src/gallium/state_trackers/va/buffer.c
+++ b/src/gallium/state_trackers/va/buffer.c
@@ -27,6 +27,7 @@
   **/
  
  #include "pipe/p_screen.h"

+#include "state_tracker/drm_driver.h"
  #include "util/u_memory.h"
  #include "util/u_handle_table.h"
  #include "util/u_transfer.h"
@@ -108,6 +109,9 @@ vlVaMapBuffer(VADriverContextP ctx, VABufferID buf_id, void 
**pbuff)
 if (!buf)
return VA_STATUS_ERROR_INVALID_BUFFER;
  
+   if (buf->export_refcount > 0)

+  return VA_STATUS_ERROR_INVALID_BUFFER;
+
 if (buf->derived_surface.resource) {
*pbuff = pipe_buffer_map(drv->pipe, buf->derived_surface.resource,
 PIPE_TRANSFER_WRITE,
@@ -138,6 +142,9 @@ vlVaUnmapBuffer(VADriverContextP ctx, VABufferID buf_id)
 if (!buf)
return VA_STATUS_ERROR_INVALID_BUFFER;
  
+   if (buf->export_refcount > 0)

+  return VA_STATUS_ERROR_INVALID_BUFFER;
+
 if (buf->derived_surface.resource) {
   if (!buf->derived_surface.transfer)
  return VA_STATUS_ERROR_INVALID_BUFFER;
@@ -164,8 +171,12 @@ vlVaDestroyBuffer(VADriverContextP ctx, VABufferID buf_id)
 if (buf->data)
   FREE(buf->data);
  
-   if (buf->derived_surface.resource)

+   if (buf->derived_surface.resource) {
+ if (buf->export_refcount > 0)
+   return VA_STATUS_ERROR_INVALID_BUFFER;
+
   pipe_resource_reference(>derived_surface.resource, NULL);
+   }
  
 FREE(buf);

 handle_table_remove(VL_VA_DRIVER(ctx)->htab, buf_id);
@@ -192,3 +203,126 @@ vlVaBufferInfo(VADriverContextP ctx, VABufferID buf_id, 
VABufferType *type,
  
 return VA_STATUS_SUCCESS;

  }
+
+VAStatus
+vlVaAcquireBufferHandle(VADriverContextP ctx, VABufferID buf_id,
+VABufferInfo *out_buf_info)
+{
+   uint32_t i;
+   uint32_t mem_type;
+   vlVaBuffer *buf ;
+   struct pipe_screen *screen;
+
+   /* List of supported memory types, in preferred order. */
+   static const uint32_t mem_types[] = {
+  VA_SURFACE_ATTRIB_MEM_TYPE_DRM_PRIME,
+  0
+   };
+
+   if (!ctx)
+  return VA_STATUS_ERROR_INVALID_CONTEXT;
+
+   buf = handle_table_get(VL_VA_DRIVER(ctx)->htab, buf_id);
+
+   if (!buf)
+  return VA_STATUS_ERROR_INVALID_BUFFER;
+
+   /* Only VA surface|image like buffers are supported for now .*/
+   if (buf->type != VAImageBufferType)
+  return VA_STATUS_ERROR_UNSUPPORTED_BUFFERTYPE;
+
+   if (!out_buf_info)
+  return VA_STATUS_ERROR_INVALID_PARAMETER;
+
+   if (!out_buf_info->mem_type)
+  mem_type = mem_types[0];
+   else {
+  mem_type = 0;
+  for (i = 0; mem_types[i] != 0; i++) {
+ if (out_buf_info->mem_type & mem_types[i]) {
+mem_type = out_buf_info->mem_type;
+break;
+ }
+  }
+  if (!mem_type)
+ return VA_STATUS_ERROR_UNSUPPORTED_MEMORY_TYPE;
+   }
+
+   if (!buf->derived_surface.resource)
+  return VA_STATUS_ERROR_INVALID_BUFFER;
+
+   screen = VL_VA_PSCREEN(ctx);
+
+   if (buf->derived_surface.fence) {
+  screen->fence_finish(screen, buf->derived_surface.fence, 
PIPE_TIMEOUT_INFINITE);
+  screen->fence_reference(screen, >derived_surface.fence, NULL);
+   }
+
+   if (buf->export_refcount > 0) {
+  if (buf->export_state.mem_type != mem_type)
+ return VA_STATUS_ERROR_INVALID_PARAMETER;
+   } else {
+  VABufferInfo * const buf_info = >export_state;
+
+  switch (mem_type) {
+  case VA_SURFACE_ATTRIB_MEM_TYPE_DRM_PRIME: {
+ struct winsys_handle whandle;
+
+ memset(, 0, sizeof(whandle));
+ whandle.type = 

Re: [Mesa-dev] [PATCH v2] st/mesa: fix mipmap generation for immutable textures with incomplete pyramids

2015-10-29 Thread Marek Olšák
On Wed, Oct 28, 2015 at 1:00 PM, Nicolai Hähnle  wrote:
> Without the clamping by NumLevels, the state tracker would reallocate the
> texture storage (incorrect) and even fail to copy the base level image
> after reallocation, leading to the graphical glitch of
> https://bugs.freedesktop.org/show_bug.cgi?id=91993 .
>
> A piglit test has been submitted for review as well (subtest of
> arb_texture_storage-texture-storage).
>
> v2: also bypass all calls to st_finalize_texture (suggested by Marek Olšák)
>
> Cc: mesa-sta...@lists.freedesktop.org
> Reviewed-by: Marek Olšák 

This looks good.

(a minor nit: an updated patch should not contain any reviewed-by
tags, because the updated version hadn't been seen by anybody at the
time of sending it to the list; it's okay to keep the tag now that
I've reviewed it)

Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] Problems with accuracy of coeffs_init + attribs_update

2015-10-29 Thread Roland Scheidegger
Am 29.10.2015 um 12:27 schrieb Oded Gabbay:
> Hi Roland, Jose
> 
> I wanted to bring a problem I found to your attention, and discuss
> about it and ways to solve it.
> 
> I'm working on regressions of piglit gpu.py between x86-64 and
> ppc64le, when running with llvmpipe.
> 
> One of the regressions manifests itself in 2 tests,
> clip-distance-bulk-copy and clip-distance-itemized-copy
There's actually a third one, interface-vs-unnamed-to-fs-unnamed, which
fails the same (and it's easier to debug...).


> 
> What happens in ppc64le is that *some* of the interpolated per-vertex
> values (clip-distance values) that constitute the input into the
> fragment shader, are not calculated according to the required accuracy
> of the test (which is an error/distance of less than 1e-6)
> 
> It took a while, but I believe I found the reason. In general, when
> running on ppc64le, the code path that is taken at
> lp_build_interp_soa_init() is doing  bld->simple_interp = FALSE, which
> means using coeffs_init() + attribs_update(). That's in contrast with
> x86-64, where bld->simple_interp = TRUE, which means the code will use
> coeffs_init_simple() + attribs_update_simple()
Note this isn't really about x86-64 per se. If you don't have AVX on a
x86-64 box, the other path will be taken too (and the test fail as well).

> 
> In specific, the problem lies in how the coeffs are calculated inside
> coeffs_init. To simply put it, they are only *actually* calculated
> correctly for the first quad. The coeffs are later *updated* for the
> other quads, using dadx/dady and dadq.
> 
> --
> side-note:
> I believe you even documented it in coeffs_init():
>   /*
>* a = a0 + (x * dadx + y * dady)
>* a0aos is the attrib value at top left corner of stamp
>*/
> --
> 
> The root cause for that, I believe, is because coeffs_init does *not*
> take into account the different x/y offsets for the other quads. In
> contrast, on x86-64, the code uses a function called calc_offset(),
> which does take the different x/y offsets into account.
> 
> Please look at this definition (from lp_bld_interp.c) :
> 
> static const unsigned char quad_offset_x[16] = {0, 1, 0, 1, 2, 3, 2,
> 3, 0, 1, 0, 1, 2, 3, 2, 3};
> static const unsigned char quad_offset_y[16] = {0, 0, 1, 1, 0, 0, 1,
> 1, 2, 2, 3, 3, 2, 2, 3, 3};
> 
> Now, look at how coeffs_init() uses them:
> 
>for (i = 0; i < coeff_bld->type.length; i++) {
>   LLVMValueRef nr = lp_build_const_int32(gallivm, i);
>   LLVMValueRef pixxf = lp_build_const_float(gallivm, quad_offset_x[i]);
>   LLVMValueRef pixyf = lp_build_const_float(gallivm, quad_offset_y[i]);
>   pixoffx = LLVMBuildInsertElement(builder, pixoffx, pixxf, nr, "");
>   pixoffy = LLVMBuildInsertElement(builder, pixoffy, pixyf, nr, "");
>}
> 
> So, in ppc64le, where coeff_bld->type.length == 4, we *always* take
> the first four values from the above arrays. The code *never*
> calculates the coeffs based on the other offsets.
> 
> Admittedly, that's *almost* always works and I doubt you will see a
> difference in display. However, in the tests I mentioned above, it
> creates, for some pixels, a bigger error than what is allowed.
Well, I'm not sure what error actually is allowed... GL of course is
vague (the test just seems to be built so the error allowed actually
passes on real hw).

I don't think there's an actual bug with the code. What it does in
coeffs_init, is simply calculate the dadx + dady values from one pixel
to the next (within a quad).
Then, in attrib_update, it simply uses these values (which are constant
for all quads, as the position of the pixels within a quad doesn't
change) to calculate the actual dadq value based on the actual pixel
offsets, and add that to the (also done in coeffs_init) starting value
of each quad.

So, the code is correct. However, it still gives different results
compared to the other method, and the reason is just float math. This
method does two interpolations (one for the start of the quad, the other
per pixel), whereas the other method does just one. And this is why the
results are different, because the results just aren't exact.


> 
> The first thing that came into my mind was to change, in
> lp_build_interp_soa_init():
> 
> "if (coeff_type.length > 4)"
> to this:
> "if (coeff_type.length >= 4)"
> 
> When I did that, I saw it fixes the above tests and didn't cause any
> regressions on ppc64le and/or on x86-64.
> 
> However, I wanted to ask you guys if you remember why you allowed only
> vectors with size above 4 to use the "simple" route ?
> Was there any performance hit ?
Some history, initially there actually only was the two-stage path (well
actually it was slightly different as back then the pixel shader wasn't
even executed in a loop but the idea was the same). The one-stage path
was actually done when extending to 256bit vectors (or maybe when
introducing the fs loop, I forgot...) because it was easier to code.
Albeit both paths were 

[Mesa-dev] [PATCH] gbm.h: Add a missing stddef.h include for size_t.

2015-10-29 Thread Emmanuel Gil Peyrot
This was causing compilation issues when one of its providers wasn’t
already included before gbm.h.
---
 src/gbm/main/gbm.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gbm/main/gbm.h b/src/gbm/main/gbm.h
index 2708e50..8db2153 100644
--- a/src/gbm/main/gbm.h
+++ b/src/gbm/main/gbm.h
@@ -35,6 +35,7 @@ extern "C" {
 
 #define __GBM__ 1
 
+#include 
 #include 
 
 /**
-- 
2.6.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] gbm.h: Add a missing stddef.h include for size_t.

2015-10-29 Thread Emil Velikov
Hi Emmanuel,

On 29 October 2015 at 15:22, Emmanuel Gil Peyrot
 wrote:
> This was causing compilation issues when one of its providers wasn’t
> already included before gbm.h.
Cc: "11.0" 
Reviewed-by: Emil Velikov 

I'll push this later on today. For future patches please include your
s-o-b line.

-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 2/2] st/va: add support to export a surface as dmabuf

2015-10-29 Thread Julien Isorce


-Original Message-
From: Christian König [mailto:deathsim...@vodafone.de] 
Sent: 29 October 2015 12:29
To: Julien Isorce; mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH 2/2] st/va: add support to export a surface as 
dmabuf

> @@ -108,6 +109,9 @@ vlVaMapBuffer(VADriverContextP ctx, VABufferID buf_id, 
> void **pbuff)
>  if (!buf)
> return VA_STATUS_ERROR_INVALID_BUFFER;
>   
> +   if (buf->export_refcount > 0)
> +  return VA_STATUS_ERROR_INVALID_BUFFER;
>>Why it is illegal to CPU map a buffer which is exported?

Hi, I think it is to prevent someone to write into the buffer while someone 
else is using the exported handle.
Either the user call VaMapBuffer or VaAcquireBufferHandle. It seems to be 
exclusive.
Also I took example here: 
http://cgit.freedesktop.org/vaapi/intel-driver/tree/src/i965_drv_video.c#n2447

> +  switch (buf_info->mem_type) {
> +  case VA_SURFACE_ATTRIB_MEM_TYPE_DRM_PRIME:
> + close((intptr_t)buf_info->handle);
> + break;
>>Seriously? Are you sure this is correct? The VA-API driver is supposed to 
>>close the prime handle? Not the application?

Good point actually. I think they assume the application can still call "dup" 
if it wants extra owner ship of the handle.
And this is what gstreamer-vaapi does in fact: 
https://github.com/01org/gstreamer-vaapi/blob/master/gst/vaapi/gstvaapivideomemory.c#L839
But again I started this impl from intel vaapi driver: 
http://cgit.freedesktop.org/vaapi/intel-driver/tree/src/i965_drv_video.c#n5731 

And for me it is fine since "importers" do not call close. For example when 
importing the dmabuf into an EGLIMage, eglCreateImage does not take ownership 
of the handle. 

Thx
Julien

>>Regards,
>>Christian.

On 29.10.2015 12:47, Julien Isorce wrote:
> I.e. implements:
> VaAcquireBufferHandle
> VaReleaseBufferHandle
> for memory of type VA_SURFACE_ATTRIB_MEM_TYPE_DRM_PRIME
>
> And apply relatives change to:
> vlVaMapBuffer
> vlVaUnMapBuffer
> vlVaDestroyBuffer
>
> Implementation inspired from cgit.freedesktop.org/vaapi/intel-driver
>
> Tested with gstreamer-vaapi with nouveau driver.
>
> Signed-off-by: Julien Isorce 
> ---
>   src/gallium/state_trackers/va/buffer.c | 136 
> -
>   src/gallium/state_trackers/va/context.c|   4 +-
>   src/gallium/state_trackers/va/va_private.h |   6 ++
>   3 files changed, 144 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/state_trackers/va/buffer.c 
> b/src/gallium/state_trackers/va/buffer.c
> index b619d0b..4ad20d2 100644
> --- a/src/gallium/state_trackers/va/buffer.c
> +++ b/src/gallium/state_trackers/va/buffer.c
> @@ -27,6 +27,7 @@
>
> **
> /
>   
>   #include "pipe/p_screen.h"
> +#include "state_tracker/drm_driver.h"
>   #include "util/u_memory.h"
>   #include "util/u_handle_table.h"
>   #include "util/u_transfer.h"
> @@ -108,6 +109,9 @@ vlVaMapBuffer(VADriverContextP ctx, VABufferID buf_id, 
> void **pbuff)
>  if (!buf)
> return VA_STATUS_ERROR_INVALID_BUFFER;
>   
> +   if (buf->export_refcount > 0)
> +  return VA_STATUS_ERROR_INVALID_BUFFER;
> +
>  if (buf->derived_surface.resource) {
> *pbuff = pipe_buffer_map(drv->pipe, buf->derived_surface.resource,
>  PIPE_TRANSFER_WRITE, @@ -138,6 +142,9 
> @@ vlVaUnmapBuffer(VADriverContextP ctx, VABufferID buf_id)
>  if (!buf)
> return VA_STATUS_ERROR_INVALID_BUFFER;
>   
> +   if (buf->export_refcount > 0)
> +  return VA_STATUS_ERROR_INVALID_BUFFER;
> +
>  if (buf->derived_surface.resource) {
>if (!buf->derived_surface.transfer)
>   return VA_STATUS_ERROR_INVALID_BUFFER; @@ -164,8 +171,12 @@ 
> vlVaDestroyBuffer(VADriverContextP ctx, VABufferID buf_id)
>  if (buf->data)
>FREE(buf->data);
>   
> -   if (buf->derived_surface.resource)
> +   if (buf->derived_surface.resource) {
> + if (buf->export_refcount > 0)
> +   return VA_STATUS_ERROR_INVALID_BUFFER;
> +
>pipe_resource_reference(>derived_surface.resource, NULL);
> +   }
>   
>  FREE(buf);
>  handle_table_remove(VL_VA_DRIVER(ctx)->htab, buf_id); @@ -192,3 
> +203,126 @@ vlVaBufferInfo(VADriverContextP ctx, VABufferID buf_id, 
> VABufferType *type,
>   
>  return VA_STATUS_SUCCESS;
>   }
> +
> +VAStatus
> +vlVaAcquireBufferHandle(VADriverContextP ctx, VABufferID buf_id,
> +VABufferInfo *out_buf_info) {
> +   uint32_t i;
> +   uint32_t mem_type;
> +   vlVaBuffer *buf ;
> +   struct pipe_screen *screen;
> +
> +   /* List of supported memory types, in preferred order. */
> +   static const uint32_t mem_types[] = {
> +  VA_SURFACE_ATTRIB_MEM_TYPE_DRM_PRIME,
> +  0
> +   };
> +
> +   if (!ctx)
> +  return VA_STATUS_ERROR_INVALID_CONTEXT;
> +
> +   buf = handle_table_get(VL_VA_DRIVER(ctx)->htab, buf_id);
> +
> +   if (!buf)
> +  return 

Re: [Mesa-dev] [PATCH 1/2] meta/blit: Always try to enable GL_ARB_sample_shading

2015-10-29 Thread Anuj Phogat
On Thu, Oct 22, 2015 at 2:34 AM, Neil Roberts  wrote:
> Previously this extension was only enabled when blitting between two
> multisampled buffers. However I don't think it does any harm to just
> enable it all the time. The ‘enable’ option is used instead of
> ‘require’ so that the shader will still compile if the extension isn't
> available in the cases where it isn't used. This will make the next
> patch simpler because it wants to add another optional extension.
> ---
>  src/mesa/drivers/common/meta_blit.c | 16 ++--
>  1 file changed, 2 insertions(+), 14 deletions(-)
>
> diff --git a/src/mesa/drivers/common/meta_blit.c 
> b/src/mesa/drivers/common/meta_blit.c
> index b92c2e2..496ce45 100644
> --- a/src/mesa/drivers/common/meta_blit.c
> +++ b/src/mesa/drivers/common/meta_blit.c
> @@ -357,17 +357,11 @@ setup_glsl_msaa_blit_shader(struct gl_context *ctx,
> shader_index == BLIT_MSAA_SHADER_2D_MULTISAMPLE_ARRAY_DEPTH_COPY ||
> shader_index == BLIT_MSAA_SHADER_2D_MULTISAMPLE_DEPTH_COPY) {
>char *sample_index;
> -  const char *arb_sample_shading_extension_string;
>
>if (dst_is_msaa) {
> - arb_sample_shading_extension_string = "#extension 
> GL_ARB_sample_shading : enable";
>   sample_index = "gl_SampleID";
>   name = "depth MSAA copy";
>} else {
> - /* Don't need that extension, since we're drawing to a 
> single-sampled
> -  * destination.
> -  */
> - arb_sample_shading_extension_string = "";
>   /* From the GL 4.3 spec:
>*
>* "If there is a multisample buffer (the value of 
> SAMPLE_BUFFERS
> @@ -397,7 +391,7 @@ setup_glsl_msaa_blit_shader(struct gl_context *ctx,
>fs_source = ralloc_asprintf(mem_ctx,
>"#version 130\n"
>"#extension GL_ARB_texture_multisample : 
> enable\n"
> -  "%s\n"
> +  "#extension GL_ARB_sample_shading : 
> enable\n"
>"uniform sampler2DMS%s texSampler;\n"
>"in %s texCoords;\n"
>"out vec4 out_color;\n"
> @@ -406,7 +400,6 @@ setup_glsl_msaa_blit_shader(struct gl_context *ctx,
>"{\n"
>"   gl_FragDepth = texelFetch(texSampler, 
> i%s(texCoords), %s).r;\n"
>"}\n",
> -  arb_sample_shading_extension_string,
>sampler_array_suffix,
>texcoord_type,
>texcoord_type,
> @@ -416,14 +409,12 @@ setup_glsl_msaa_blit_shader(struct gl_context *ctx,
> * sample).  Yes, this is ridiculous.
> */
>char *sample_resolve;
> -  const char *arb_sample_shading_extension_string;
>const char *merge_function;
>name = ralloc_asprintf(mem_ctx, "%svec4 MSAA %s",
>   vec4_prefix,
>   dst_is_msaa ? "copy" : "resolve");
>
>if (dst_is_msaa) {
> - arb_sample_shading_extension_string = "#extension 
> GL_ARB_sample_shading : enable";
>   sample_resolve = ralloc_asprintf(mem_ctx, "   out_color = 
> texelFetch(texSampler, i%s(texCoords), gl_SampleID);", texcoord_type);
>   merge_function = "";
>} else {
> @@ -439,8 +430,6 @@ setup_glsl_msaa_blit_shader(struct gl_context *ctx,
> "vec4 merge(vec4 a, vec4 b) { return (a + b); }\n";
>   }
>
> - arb_sample_shading_extension_string = "";
> -
>   /* We're assuming power of two samples for this resolution 
> procedure.
>*
>* To avoid losing any floating point precision if the samples all
> @@ -496,7 +485,7 @@ setup_glsl_msaa_blit_shader(struct gl_context *ctx,
>fs_source = ralloc_asprintf(mem_ctx,
>"#version 130\n"
>"#extension GL_ARB_texture_multisample : 
> enable\n"
> -  "%s\n"
> +  "#extension GL_ARB_sample_shading : 
> enable\n"
>"#define gvec4 %svec4\n"
>"uniform %ssampler2DMS%s texSampler;\n"
>"in %s texCoords;\n"
> @@ -507,7 +496,6 @@ setup_glsl_msaa_blit_shader(struct gl_context *ctx,
>"{\n"
>"%s\n" /* sample_resolve */
>"}\n",
> -  arb_sample_shading_extension_string,
>vec4_prefix,
>vec4_prefix,
>sampler_array_suffix,
> --
> 1.9.3

Re: [Mesa-dev] [PATCH v2 7/8] st/va: add colospace conversion through Video Post Processing

2015-10-29 Thread Julien Isorce
Ack. I confirm it still works without it. So I'll remove it. Thx

-Original Message-
From: Christian König [mailto:deathsim...@vodafone.de] 
Sent: 29 October 2015 14:02
To: Julien Isorce; mesa-dev@lists.freedesktop.org
Cc: emil.l.veli...@gmail.com
Subject: Re: [Mesa-dev] [PATCH v2 7/8] st/va: add colospace conversion through 
Video Post Processing

> +if(src_surface->fence) {
> +   screen->fence_finish(screen, src_surface->fence, 
> PIPE_TIMEOUT_INFINITE);
> +   screen->fence_reference(screen, _surface->fence, NULL);
> +}
That shouldn't be necessary cause all render operations to the same surface are 
pipelined anyway.

Regards,
Christian.

On 22.10.2015 18:37, Julien Isorce wrote:
> Add support for VPP in the following functions:
> vlVaCreateContext
> vlVaDestroyContext
> vlVaBeginPicture
> vlVaRenderPicture
> vlVaEndPicture
>
> Add support for VAProcFilterNone in:
> vlVaQueryVideoProcFilters
> vlVaQueryVideoProcFilterCaps
> vlVaQueryVideoProcPipelineCaps
>
> Add handleVAProcPipelineParameterBufferType helper.
>
> One application is:
> VASurfaceNV12 -> gstvaapipostproc -> VASurfaceRGBA
>
> Signed-off-by: Julien Isorce 
> ---
>   src/gallium/state_trackers/va/context.c| 91 +--
>   src/gallium/state_trackers/va/picture.c| 86 +-
>   src/gallium/state_trackers/va/surface.c| 98 
> +-
>   src/gallium/state_trackers/va/va_private.h |  8 +++
>   4 files changed, 248 insertions(+), 35 deletions(-)
>
> diff --git a/src/gallium/state_trackers/va/context.c 
> b/src/gallium/state_trackers/va/context.c
> index 9be9085..170e9d6 100644
> --- a/src/gallium/state_trackers/va/context.c
> +++ b/src/gallium/state_trackers/va/context.c
> @@ -87,6 +87,14 @@ static struct VADriverVTable vtable =
>  
>   };
>   
> +static struct VADriverVTableVPP vtable_vpp = {
> +   1,
> +   ,
> +   ,
> +   
> +};
> +
>   PUBLIC VAStatus
>   VA_DRIVER_INIT_FUNC(VADriverContextP ctx)
>   {
> @@ -122,6 +130,7 @@ VA_DRIVER_INIT_FUNC(VADriverContextP ctx)
>  ctx->version_major = 0;
>  ctx->version_minor = 1;
>  *ctx->vtable = vtable;
> +   *ctx->vtable_vpp = vtable_vpp;
>  ctx->max_profiles = PIPE_VIDEO_PROFILE_MPEG4_AVC_HIGH - 
> PIPE_VIDEO_PROFILE_UNKNOWN;
>  ctx->max_entrypoints = 1;
>  ctx->max_attributes = 1;
> @@ -151,11 +160,15 @@ vlVaCreateContext(VADriverContextP ctx, VAConfigID 
> config_id, int picture_width,
>  struct pipe_video_codec templat = {};
>  vlVaDriver *drv;
>  vlVaContext *context;
> +   int is_vpp;
>   
>  if (!ctx)
> return VA_STATUS_ERROR_INVALID_CONTEXT;
>   
> -   if (!(picture_width && picture_height))
> +   is_vpp = config_id == PIPE_VIDEO_PROFILE_UNKNOWN && !picture_width &&
> +!picture_height && !flag && !render_targets && 
> + !num_render_targets;
> +
> +   if (!(picture_width && picture_height) && !is_vpp)
> return VA_STATUS_ERROR_INVALID_IMAGE_FORMAT;
>   
>  drv = VL_VA_DRIVER(ctx);
> @@ -163,38 +176,46 @@ vlVaCreateContext(VADriverContextP ctx, VAConfigID 
> config_id, int picture_width,
>  if (!context)
> return VA_STATUS_ERROR_ALLOCATION_FAILED;
>   
> -   templat.profile = config_id;
> -   templat.entrypoint = PIPE_VIDEO_ENTRYPOINT_BITSTREAM;
> -   templat.chroma_format = PIPE_VIDEO_CHROMA_FORMAT_420;
> -   templat.width = picture_width;
> -   templat.height = picture_height;
> -   templat.max_references = num_render_targets;
> -   templat.expect_chunked_decode = true;
> -
> -   if (u_reduce_video_profile(templat.profile) ==
> -   PIPE_VIDEO_FORMAT_MPEG4_AVC)
> -  templat.level = u_get_h264_level(templat.width, templat.height,
> -_references);
> -
> -   context->decoder = drv->pipe->create_video_codec(drv->pipe, );
> -   if (!context->decoder) {
> -  FREE(context);
> -  return VA_STATUS_ERROR_ALLOCATION_FAILED;
> -   }
> -
> -   if (u_reduce_video_profile(context->decoder->profile) ==
> - PIPE_VIDEO_FORMAT_MPEG4_AVC) {
> -  context->desc.h264.pps = CALLOC_STRUCT(pipe_h264_pps);
> -  if (!context->desc.h264.pps) {
> +   if (is_vpp) {
> +  context->decoder = NULL;
> +  if (!drv->compositor.upload) {
>FREE(context);
> - return VA_STATUS_ERROR_ALLOCATION_FAILED;
> + return VA_STATUS_ERROR_INVALID_CONTEXT;
> }
> -  context->desc.h264.pps->sps = CALLOC_STRUCT(pipe_h264_sps);
> -  if (!context->desc.h264.pps->sps) {
> - FREE(context->desc.h264.pps);
> +   } else {
> +  templat.profile = config_id;
> +  templat.entrypoint = PIPE_VIDEO_ENTRYPOINT_BITSTREAM;
> +  templat.chroma_format = PIPE_VIDEO_CHROMA_FORMAT_420;
> +  templat.width = picture_width;
> +  templat.height = picture_height;
> +  templat.max_references = num_render_targets;
> +  templat.expect_chunked_decode = true;
> +
> +  if (u_reduce_video_profile(templat.profile) ==
> +

[Mesa-dev] [PATCH v4 7/9] st/va: add headless support, i.e. VA_DISPLAY_DRM

2015-10-29 Thread Julien Isorce
This patch allows to use gallium vaapi without requiring
a X server running for your second graphic card.

Signed-off-by: Julien Isorce 
---
 src/gallium/state_trackers/va/Makefile.am |  9 
 src/gallium/state_trackers/va/context.c   | 70 ---
 2 files changed, 73 insertions(+), 6 deletions(-)

diff --git a/src/gallium/state_trackers/va/Makefile.am 
b/src/gallium/state_trackers/va/Makefile.am
index 2a93a90..348cfe1 100644
--- a/src/gallium/state_trackers/va/Makefile.am
+++ b/src/gallium/state_trackers/va/Makefile.am
@@ -30,6 +30,15 @@ AM_CFLAGS = \
$(VA_CFLAGS) \
-DVA_DRIVER_INIT_FUNC="__vaDriverInit_$(VA_MAJOR)_$(VA_MINOR)"
 
+AM_CFLAGS += \
+   $(GALLIUM_PIPE_LOADER_DEFINES) \
+   -DPIPE_SEARCH_DIR=\"$(libdir)/gallium-pipe\"
+
+if HAVE_GALLIUM_STATIC_TARGETS
+AM_CFLAGS += \
+   -DGALLIUM_STATIC_TARGETS=1
+endif
+
 AM_CPPFLAGS = \
-I$(top_srcdir)/include
 
diff --git a/src/gallium/state_trackers/va/context.c 
b/src/gallium/state_trackers/va/context.c
index a107cc4..bd533c4 100644
--- a/src/gallium/state_trackers/va/context.c
+++ b/src/gallium/state_trackers/va/context.c
@@ -28,7 +28,8 @@
 
 #include "pipe/p_screen.h"
 #include "pipe/p_video_codec.h"
-
+#include "pipe-loader/pipe_loader.h"
+#include "state_tracker/drm_driver.h"
 #include "util/u_memory.h"
 #include "util/u_handle_table.h"
 #include "util/u_video.h"
@@ -36,6 +37,8 @@
 
 #include "va_private.h"
 
+#include 
+
 static struct VADriverVTable vtable =
 {
,
@@ -99,6 +102,8 @@ PUBLIC VAStatus
 VA_DRIVER_INIT_FUNC(VADriverContextP ctx)
 {
vlVaDriver *drv;
+   int drm_fd;
+   struct drm_state *drm_info;
 
if (!ctx)
   return VA_STATUS_ERROR_INVALID_CONTEXT;
@@ -107,9 +112,56 @@ VA_DRIVER_INIT_FUNC(VADriverContextP ctx)
if (!drv)
   return VA_STATUS_ERROR_ALLOCATION_FAILED;
 
-   drv->vscreen = vl_screen_create(ctx->native_dpy, ctx->x11_screen);
-   if (!drv->vscreen)
-  goto error_screen;
+   switch (ctx->display_type) {
+   case VA_DISPLAY_ANDROID:
+   case VA_DISPLAY_WAYLAND:
+  FREE(drv);
+  return VA_STATUS_ERROR_UNIMPLEMENTED;
+   case VA_DISPLAY_GLX:
+   case VA_DISPLAY_X11:
+  drv->vscreen = vl_screen_create(ctx->native_dpy, ctx->x11_screen);
+  if (!drv->vscreen)
+ goto error_screen;
+  break;
+   case VA_DISPLAY_DRM:
+   case VA_DISPLAY_DRM_RENDERNODES: {
+  drm_info = (struct drm_state *) ctx->drm_state;
+  if (!drm_info) {
+ FREE(drv);
+ return VA_STATUS_ERROR_INVALID_PARAMETER;
+  }
+
+#if GALLIUM_STATIC_TARGETS
+  drm_fd = drm_info->fd;
+#else
+  drm_fd = dup(drm_info->fd);
+#endif
+
+  if (drm_fd < 0) {
+ FREE(drv);
+ return VA_STATUS_ERROR_INVALID_PARAMETER;
+  }
+
+  drv->vscreen = CALLOC_STRUCT(vl_screen);
+  if (!drv->vscreen)
+ goto error_screen;
+
+#if GALLIUM_STATIC_TARGETS
+  drv->vscreen->pscreen = dd_create_screen(drm_fd);
+#else
+  if (pipe_loader_drm_probe_fd(>dev, drm_fd))
+ drv->vscreen->pscreen = pipe_loader_create_screen(drv->dev, 
PIPE_SEARCH_DIR);
+#endif
+
+  if (!drv->vscreen->pscreen)
+ goto error_pipe;
+
+  }
+  break;
+   default:
+  FREE(drv);
+  return VA_STATUS_ERROR_INVALID_DISPLAY;
+   }
 
drv->pipe = drv->vscreen->pscreen->context_create(drv->vscreen->pscreen,
  drv->vscreen, 0);
@@ -145,7 +197,10 @@ error_htab:
drv->pipe->destroy(drv->pipe);
 
 error_pipe:
-   vl_screen_destroy(drv->vscreen);
+   if (ctx->display_type == VA_DISPLAY_GLX || ctx->display_type == 
VA_DISPLAY_X11)
+  vl_screen_destroy(drv->vscreen);
+   else
+  FREE(drv->vscreen);
 
 error_screen:
FREE(drv);
@@ -282,7 +337,10 @@ vlVaTerminate(VADriverContextP ctx)
vl_compositor_cleanup_state(>cstate);
vl_compositor_cleanup(>compositor);
drv->pipe->destroy(drv->pipe);
-   vl_screen_destroy(drv->vscreen);
+   if (ctx->display_type == VA_DISPLAY_GLX || ctx->display_type == 
VA_DISPLAY_X11)
+  vl_screen_destroy(drv->vscreen);
+   else
+  FREE(drv->vscreen);
handle_table_destroy(drv->htab);
FREE(drv);
 
-- 
1.9.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH v4 6/9] st/va: add colospace conversion through Video Post Processing

2015-10-29 Thread Julien Isorce
Add support for VPP in the following functions:
vlVaCreateContext
vlVaDestroyContext
vlVaBeginPicture
vlVaRenderPicture
vlVaEndPicture

Add support for VAProcFilterNone in:
vlVaQueryVideoProcFilters
vlVaQueryVideoProcFilterCaps
vlVaQueryVideoProcPipelineCaps

Add handleVAProcPipelineParameterBufferType helper.

One application is:
VASurfaceNV12 -> gstvaapipostproc -> VASurfaceRGBA

Signed-off-by: Julien Isorce 
---
 src/gallium/state_trackers/va/context.c| 124 +
 src/gallium/state_trackers/va/picture.c|  81 ++-
 src/gallium/state_trackers/va/surface.c|  98 ++-
 src/gallium/state_trackers/va/va_private.h |   8 ++
 4 files changed, 259 insertions(+), 52 deletions(-)

diff --git a/src/gallium/state_trackers/va/context.c 
b/src/gallium/state_trackers/va/context.c
index 9cc402e..a107cc4 100644
--- a/src/gallium/state_trackers/va/context.c
+++ b/src/gallium/state_trackers/va/context.c
@@ -87,6 +87,14 @@ static struct VADriverVTable vtable =

 };
 
+static struct VADriverVTableVPP vtable_vpp =
+{
+   1,
+   ,
+   ,
+   
+};
+
 PUBLIC VAStatus
 VA_DRIVER_INIT_FUNC(VADriverContextP ctx)
 {
@@ -122,6 +130,7 @@ VA_DRIVER_INIT_FUNC(VADriverContextP ctx)
ctx->version_major = 0;
ctx->version_minor = 1;
*ctx->vtable = vtable;
+   *ctx->vtable_vpp = vtable_vpp;
ctx->max_profiles = PIPE_VIDEO_PROFILE_MPEG4_AVC_HIGH - 
PIPE_VIDEO_PROFILE_UNKNOWN;
ctx->max_entrypoints = 1;
ctx->max_attributes = 1;
@@ -151,11 +160,15 @@ vlVaCreateContext(VADriverContextP ctx, VAConfigID 
config_id, int picture_width,
struct pipe_video_codec templat = {};
vlVaDriver *drv;
vlVaContext *context;
+   int is_vpp;
 
if (!ctx)
   return VA_STATUS_ERROR_INVALID_CONTEXT;
 
-   if (!(picture_width && picture_height))
+   is_vpp = config_id == PIPE_VIDEO_PROFILE_UNKNOWN && !picture_width &&
+!picture_height && !flag && !render_targets && !num_render_targets;
+
+   if (!(picture_width && picture_height) && !is_vpp)
   return VA_STATUS_ERROR_INVALID_IMAGE_FORMAT;
 
drv = VL_VA_DRIVER(ctx);
@@ -163,52 +176,60 @@ vlVaCreateContext(VADriverContextP ctx, VAConfigID 
config_id, int picture_width,
if (!context)
   return VA_STATUS_ERROR_ALLOCATION_FAILED;
 
-   templat.profile = config_id;
-   templat.entrypoint = PIPE_VIDEO_ENTRYPOINT_BITSTREAM;
-   templat.chroma_format = PIPE_VIDEO_CHROMA_FORMAT_420;
-   templat.width = picture_width;
-   templat.height = picture_height;
-   templat.max_references = num_render_targets;
-   templat.expect_chunked_decode = true;
-
-   if (u_reduce_video_profile(templat.profile) ==
-   PIPE_VIDEO_FORMAT_MPEG4_AVC)
-  templat.level = u_get_h264_level(templat.width, templat.height,
-_references);
-
-   context->decoder = drv->pipe->create_video_codec(drv->pipe, );
-   if (!context->decoder) {
-  FREE(context);
-  return VA_STATUS_ERROR_ALLOCATION_FAILED;
-   }
-
-   if (u_reduce_video_profile(context->decoder->profile) ==
- PIPE_VIDEO_FORMAT_MPEG4_AVC) {
-  context->desc.h264.pps = CALLOC_STRUCT(pipe_h264_pps);
-  if (!context->desc.h264.pps) {
+   if (is_vpp) {
+  context->decoder = NULL;
+  if (!drv->compositor.upload) {
  FREE(context);
- return VA_STATUS_ERROR_ALLOCATION_FAILED;
+ return VA_STATUS_ERROR_INVALID_CONTEXT;
   }
-  context->desc.h264.pps->sps = CALLOC_STRUCT(pipe_h264_sps);
-  if (!context->desc.h264.pps->sps) {
- FREE(context->desc.h264.pps);
+   } else {
+  templat.profile = config_id;
+  templat.entrypoint = PIPE_VIDEO_ENTRYPOINT_BITSTREAM;
+  templat.chroma_format = PIPE_VIDEO_CHROMA_FORMAT_420;
+  templat.width = picture_width;
+  templat.height = picture_height;
+  templat.max_references = num_render_targets;
+  templat.expect_chunked_decode = true;
+
+  if (u_reduce_video_profile(templat.profile) ==
+PIPE_VIDEO_FORMAT_MPEG4_AVC)
+templat.level = u_get_h264_level(templat.width, templat.height,
+ _references);
+
+  context->decoder = drv->pipe->create_video_codec(drv->pipe, );
+  if (!context->decoder) {
  FREE(context);
  return VA_STATUS_ERROR_ALLOCATION_FAILED;
   }
-   }
 
-   if (u_reduce_video_profile(context->decoder->profile) ==
- PIPE_VIDEO_FORMAT_HEVC) {
-  context->desc.h265.pps = CALLOC_STRUCT(pipe_h265_pps);
-  if (!context->desc.h265.pps) {
- FREE(context);
- return VA_STATUS_ERROR_ALLOCATION_FAILED;
+  if (u_reduce_video_profile(context->decoder->profile) ==
+ PIPE_VIDEO_FORMAT_MPEG4_AVC) {
+ context->desc.h264.pps = CALLOC_STRUCT(pipe_h264_pps);
+ if (!context->desc.h264.pps) {
+FREE(context);
+return VA_STATUS_ERROR_ALLOCATION_FAILED;
+ }
+ context->desc.h264.pps->sps = CALLOC_STRUCT(pipe_h264_sps);
+ 

[Mesa-dev] [PATCH v4 2/9] st/va: do not destroy old buffer when new one failed

2015-10-29 Thread Julien Isorce
If formats are not the same vlVaPutImage re-creates the video
buffer with the right format. But if the creation of this new
video buffer fails then the surface looses its current buffer.
Let's just destroy the previous buffer on success.

Signed-off-by: Julien Isorce 
---
 src/gallium/state_trackers/va/image.c | 19 +--
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/src/gallium/state_trackers/va/image.c 
b/src/gallium/state_trackers/va/image.c
index 84d94c8..8e64673 100644
--- a/src/gallium/state_trackers/va/image.c
+++ b/src/gallium/state_trackers/va/image.c
@@ -346,13 +346,20 @@ vlVaPutImage(VADriverContextP ctx, VASurfaceID surface, 
VAImageID image,
if (format == PIPE_FORMAT_NONE)
   return VA_STATUS_ERROR_OPERATION_FAILED;
 
-   if (surf->buffer == NULL || format != surf->buffer->buffer_format) {
-  if (surf->buffer)
- surf->buffer->destroy(surf->buffer);
+   if (format != surf->buffer->buffer_format) {
+  struct pipe_video_buffer *tmp_buf;
+  enum pipe_format old_surf_format = surf->templat.buffer_format;
+
   surf->templat.buffer_format = format;
-  surf->buffer = drv->pipe->create_video_buffer(drv->pipe, >templat);
-  if (!surf->buffer)
- return VA_STATUS_ERROR_ALLOCATION_FAILED;
+  tmp_buf = drv->pipe->create_video_buffer(drv->pipe, >templat);
+
+  if (!tmp_buf) {
+  surf->templat.buffer_format = old_surf_format;
+  return VA_STATUS_ERROR_ALLOCATION_FAILED;
+  }
+
+  surf->buffer->destroy(surf->buffer);
+  surf->buffer = tmp_buf;
}
 
views = surf->buffer->get_sampler_view_planes(surf->buffer);
-- 
1.9.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH v4 5/9] st/va: handle Video Post Processing for configs

2015-10-29 Thread Julien Isorce
Add support for VA_PROFILE_NONE and VAEntrypointVideoProc
in the 4 following functions:

vlVaQueryConfigProfiles
vlVaQueryConfigEntrypoints
vlVaCreateConfig
vlVaQueryConfigAttributes

Signed-off-by: Julien Isorce 
---
 src/gallium/state_trackers/va/config.c | 20 
 src/gallium/state_trackers/va/va_private.h |  7 +--
 2 files changed, 25 insertions(+), 2 deletions(-)

diff --git a/src/gallium/state_trackers/va/config.c 
b/src/gallium/state_trackers/va/config.c
index 5030f9e..0f47aac 100644
--- a/src/gallium/state_trackers/va/config.c
+++ b/src/gallium/state_trackers/va/config.c
@@ -52,6 +52,9 @@ vlVaQueryConfigProfiles(VADriverContextP ctx, VAProfile 
*profile_list, int *num_
 profile_list[(*num_profiles)++] = vap;
   }
 
+   /* Support postprocessing through vl_compositor */
+   profile_list[(*num_profiles)++] = VAProfileNone;
+
return VA_STATUS_SUCCESS;
 }
 
@@ -67,6 +70,11 @@ vlVaQueryConfigEntrypoints(VADriverContextP ctx, VAProfile 
profile,
 
*num_entrypoints = 0;
 
+   if (profile == VAProfileNone) {
+   entrypoint_list[(*num_entrypoints)++] = VAEntrypointVideoProc;
+   return VA_STATUS_SUCCESS;
+   }
+
p = ProfileToPipe(profile);
if (p == PIPE_VIDEO_PROFILE_UNKNOWN)
   return VA_STATUS_ERROR_UNSUPPORTED_PROFILE;
@@ -118,6 +126,11 @@ vlVaCreateConfig(VADriverContextP ctx, VAProfile profile, 
VAEntrypoint entrypoin
if (!ctx)
   return VA_STATUS_ERROR_INVALID_CONTEXT;
 
+   if (profile == VAProfileNone && entrypoint == VAEntrypointVideoProc) {
+   *config_id = PIPE_VIDEO_PROFILE_UNKNOWN;
+   return VA_STATUS_SUCCESS;
+   }
+
p = ProfileToPipe(profile);
if (p == PIPE_VIDEO_PROFILE_UNKNOWN)
   return VA_STATUS_ERROR_UNSUPPORTED_PROFILE;
@@ -151,6 +164,13 @@ vlVaQueryConfigAttributes(VADriverContextP ctx, VAConfigID 
config_id, VAProfile
   return VA_STATUS_ERROR_INVALID_CONTEXT;
 
*profile = PipeToProfile(config_id);
+
+   if (config_id == PIPE_VIDEO_PROFILE_UNKNOWN) {
+  *entrypoint = VAEntrypointVideoProc;
+   *num_attribs = 0;
+  return VA_STATUS_SUCCESS;
+   }
+
*entrypoint = VAEntrypointVLD;
 
*num_attribs = 1;
diff --git a/src/gallium/state_trackers/va/va_private.h 
b/src/gallium/state_trackers/va/va_private.h
index 68cb703..3a02e58 100644
--- a/src/gallium/state_trackers/va/va_private.h
+++ b/src/gallium/state_trackers/va/va_private.h
@@ -146,10 +146,11 @@ PipeToProfile(enum pipe_video_profile profile)
   return VAProfileH264Main;
case PIPE_VIDEO_PROFILE_MPEG4_AVC_HIGH:
   return VAProfileH264High;
-   case PIPE_VIDEO_PROFILE_MPEG4_AVC_EXTENDED:
-   return VAProfileNone;
case PIPE_VIDEO_PROFILE_HEVC_MAIN:
   return VAProfileHEVCMain;
+   case PIPE_VIDEO_PROFILE_MPEG4_AVC_EXTENDED:
+   case PIPE_VIDEO_PROFILE_UNKNOWN:
+  return VAProfileNone;
default:
   assert(0);
   return -1;
@@ -182,6 +183,8 @@ ProfileToPipe(VAProfile profile)
   return PIPE_VIDEO_PROFILE_MPEG4_AVC_HIGH;
case VAProfileHEVCMain:
   return PIPE_VIDEO_PROFILE_HEVC_MAIN;
+   case VAProfileNone:
+   return PIPE_VIDEO_PROFILE_UNKNOWN;
default:
   return PIPE_VIDEO_PROFILE_UNKNOWN;
}
-- 
1.9.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 1/2] gallium/radeon: always return the last SDMA fence on SDMA flush if needed

2015-10-29 Thread Marek Olšák
From: Marek Olšák 

---
 src/gallium/drivers/radeon/r600_pipe_common.c | 11 +++
 src/gallium/drivers/radeon/r600_pipe_common.h |  1 +
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c 
b/src/gallium/drivers/radeon/r600_pipe_common.c
index 0ad3684..56977c0 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.c
+++ b/src/gallium/drivers/radeon/r600_pipe_common.c
@@ -192,13 +192,15 @@ static void r600_flush_dma_ring(void *ctx, unsigned flags,
struct r600_common_context *rctx = (struct r600_common_context *)ctx;
struct radeon_winsys_cs *cs = rctx->rings.dma.cs;
 
-   if (!cs->cdw) {
-   return;
-   }
+   if (!cs->cdw)
+   goto done;
 
rctx->rings.dma.flushing = true;
-   rctx->ws->cs_flush(cs, flags, fence, 0);
+   rctx->ws->cs_flush(cs, flags, >last_sdma_fence, 0);
rctx->rings.dma.flushing = false;
+done:
+   if (fence)
+   rctx->ws->fence_reference(fence, rctx->last_sdma_fence);
 }
 
 static enum pipe_reset_status r600_get_reset_status(struct pipe_context *ctx)
@@ -297,6 +299,7 @@ void r600_common_context_cleanup(struct r600_common_context 
*rctx)
if (rctx->allocator_so_filled_size) {
u_suballocator_destroy(rctx->allocator_so_filled_size);
}
+   rctx->ws->fence_reference(>last_sdma_fence, NULL);
 }
 
 void r600_context_add_resource_size(struct pipe_context *ctx, struct 
pipe_resource *r)
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.h 
b/src/gallium/drivers/radeon/r600_pipe_common.h
index c300c0b..b7f1a23 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.h
+++ b/src/gallium/drivers/radeon/r600_pipe_common.h
@@ -384,6 +384,7 @@ struct r600_common_context {
enum radeon_family  family;
enum chip_class chip_class;
struct r600_rings   rings;
+   struct pipe_fence_handle*last_sdma_fence;
unsignedinitial_gfx_cs_size;
unsignedgpu_reset_counter;
 
-- 
2.1.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 2/2] gallium/radeon: allow returning SDMA fences from pipe->flush

2015-10-29 Thread Marek Olšák
From: Marek Olšák 

pipe->flush never returned SDMA fences. This fixes it.
This is only an issue on amdgpu where fences can signal out of order.
---
 src/gallium/drivers/radeon/r600_pipe_common.c | 64 +++
 1 file changed, 56 insertions(+), 8 deletions(-)

diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c 
b/src/gallium/drivers/radeon/r600_pipe_common.c
index 56977c0..79e624e 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.c
+++ b/src/gallium/drivers/radeon/r600_pipe_common.c
@@ -31,6 +31,7 @@
 #include "util/u_memory.h"
 #include "util/u_format_s3tc.h"
 #include "util/u_upload_mgr.h"
+#include "os/os_time.h"
 #include "vl/vl_decoder.h"
 #include "vl/vl_video_buffer.h"
 #include "radeon/radeon_video.h"
@@ -40,6 +41,12 @@
 #define HAVE_LLVM 0
 #endif
 
+struct r600_multi_fence {
+   struct pipe_reference reference;
+   struct pipe_fence_handle *gfx;
+   struct pipe_fence_handle *sdma;
+};
+
 /*
  * pipe_context
  */
@@ -174,16 +181,34 @@ static void r600_flush_from_st(struct pipe_context *ctx,
   struct pipe_fence_handle **fence,
   unsigned flags)
 {
+   struct pipe_screen *screen = ctx->screen;
struct r600_common_context *rctx = (struct r600_common_context *)ctx;
unsigned rflags = 0;
+   struct pipe_fence_handle *gfx_fence = NULL;
+   struct pipe_fence_handle *sdma_fence = NULL;
 
if (flags & PIPE_FLUSH_END_OF_FRAME)
rflags |= RADEON_FLUSH_END_OF_FRAME;
 
if (rctx->rings.dma.cs) {
-   rctx->rings.dma.flush(rctx, rflags, NULL);
+   rctx->rings.dma.flush(rctx, rflags, fence ? _fence : NULL);
+   }
+   rctx->rings.gfx.flush(rctx, rflags, fence ? _fence : NULL);
+
+   /* Both engines can signal out of order, so we need to keep both 
fences. */
+   if (gfx_fence || sdma_fence) {
+   struct r600_multi_fence *multi_fence =
+   CALLOC_STRUCT(r600_multi_fence);
+   if (!multi_fence)
+   return;
+
+   multi_fence->reference.count = 1;
+   multi_fence->gfx = gfx_fence;
+   multi_fence->sdma = sdma_fence;
+
+   screen->fence_reference(screen, fence, NULL);
+   *fence = (struct pipe_fence_handle*)multi_fence;
}
-   rctx->rings.gfx.flush(rctx, rflags, fence);
 }
 
 static void r600_flush_dma_ring(void *ctx, unsigned flags,
@@ -757,12 +782,19 @@ static int r600_get_driver_query_info(struct pipe_screen 
*screen,
 }
 
 static void r600_fence_reference(struct pipe_screen *screen,
-struct pipe_fence_handle **ptr,
-struct pipe_fence_handle *fence)
+struct pipe_fence_handle **dst,
+struct pipe_fence_handle *src)
 {
-   struct radeon_winsys *rws = ((struct r600_common_screen*)screen)->ws;
-
-   rws->fence_reference(ptr, fence);
+   struct radeon_winsys *ws = ((struct r600_common_screen*)screen)->ws;
+   struct r600_multi_fence **rdst = (struct r600_multi_fence **)dst;
+   struct r600_multi_fence *rsrc = (struct r600_multi_fence *)src;
+
+   if (pipe_reference(&(*rdst)->reference, >reference)) {
+   ws->fence_reference(&(*rdst)->gfx, NULL);
+   ws->fence_reference(&(*rdst)->sdma, NULL);
+   FREE(*rdst);
+   }
+*rdst = rsrc;
 }
 
 static boolean r600_fence_finish(struct pipe_screen *screen,
@@ -770,8 +802,24 @@ static boolean r600_fence_finish(struct pipe_screen 
*screen,
 uint64_t timeout)
 {
struct radeon_winsys *rws = ((struct r600_common_screen*)screen)->ws;
+   struct r600_multi_fence *rfence = (struct r600_multi_fence *)fence;
+   int64_t abs_timeout = os_time_get_absolute_timeout(timeout);
+
+   if (rfence->sdma) {
+   if (!rws->fence_wait(rws, rfence->sdma, timeout))
+   return false;
+
+   /* Recompute the timeout after waiting. */
+   if (timeout && timeout != PIPE_TIMEOUT_INFINITE) {
+   int64_t time = os_time_get_nano();
+   timeout = abs_timeout > time ? abs_timeout - time : 0;
+   }
+   }
+
+   if (!rfence->gfx)
+   return true;
 
-   return rws->fence_wait(rws, fence, timeout);
+   return rws->fence_wait(rws, rfence->gfx, timeout);
 }
 
 static bool r600_interpret_tiling(struct r600_common_screen *rscreen,
-- 
2.1.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 1/2] st/va: implement VaDeriveImage

2015-10-29 Thread Julien Isorce
Ack. And I'll move this bit at the end just before the other FREE. Thx

-Original Message-
From: Christian König [mailto:deathsim...@vodafone.de] 
Sent: 29 October 2015 12:22
To: Julien Isorce; mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH 1/2] st/va: implement VaDeriveImage

Patch #1:
> +   if (buf->data)
> + FREE(buf->data);
FREE() usually does a NULL check anyway.

Apart from that minor nitpick the patch is Reviewed-by: Christian König 


Regards,
Christian.

On 29.10.2015 12:47, Julien Isorce wrote:
> And apply relatives change to:
> vlVaBufferSetNumElements
> vlVaCreateBuffer
> vlVaMapBuffer
> vlVaUnmapBuffer
> vlVaDestroyBuffer
> vlVaPutImage
>
> It is unfortunate that there is no proper va buffer type and struct 
> for this. Only possible to use VAImageBufferType which is normally 
> used for normal user data array.
> On of the consequences is that it is only possible VaDeriveImage is 
> only useful on surfaces backed with contiguous planes.
> Implementation inspired from cgit.freedesktop.org/vaapi/intel-driver
>
> Signed-off-by: Julien Isorce 
> ---
>   src/gallium/state_trackers/va/buffer.c | 47 +--
>   src/gallium/state_trackers/va/image.c  | 92 
> +-
>   src/gallium/state_trackers/va/va_private.h |  5 ++
>   3 files changed, 138 insertions(+), 6 deletions(-)
>
> diff --git a/src/gallium/state_trackers/va/buffer.c 
> b/src/gallium/state_trackers/va/buffer.c
> index 8f9ba44..b619d0b 100644
> --- a/src/gallium/state_trackers/va/buffer.c
> +++ b/src/gallium/state_trackers/va/buffer.c
> @@ -26,8 +26,11 @@
>*
>
> **
> /
>   
> +#include "pipe/p_screen.h"
>   #include "util/u_memory.h"
>   #include "util/u_handle_table.h"
> +#include "util/u_transfer.h"
> +#include "vl/vl_winsys.h"
>   
>   #include "va_private.h"
>   
> @@ -73,6 +76,10 @@ vlVaBufferSetNumElements(VADriverContextP ctx, VABufferID 
> buf_id,
> return VA_STATUS_ERROR_INVALID_CONTEXT;
>   
>  buf = handle_table_get(VL_VA_DRIVER(ctx)->htab, buf_id);
> +
> +   if (!buf || buf->derived_surface.resource)
> +  return VA_STATUS_ERROR_INVALID_BUFFER;
> +
>  buf->data = REALLOC(buf->data, buf->size * buf->num_elements,
>  buf->size * num_elements);
>  buf->num_elements = num_elements; @@ -86,16 +93,32 @@ 
> vlVaBufferSetNumElements(VADriverContextP ctx, VABufferID buf_id,
>   VAStatus
>   vlVaMapBuffer(VADriverContextP ctx, VABufferID buf_id, void **pbuff)
>   {
> +   vlVaDriver *drv;
>  vlVaBuffer *buf;
>   
>  if (!ctx)
> return VA_STATUS_ERROR_INVALID_CONTEXT;
>   
> -   buf = handle_table_get(VL_VA_DRIVER(ctx)->htab, buf_id);
> +   if (!pbuff)
> +  return VA_STATUS_ERROR_INVALID_BUFFER;
> +
> +   drv = VL_VA_DRIVER(ctx);
> +
> +   buf = handle_table_get(drv->htab, buf_id);
>  if (!buf)
> return VA_STATUS_ERROR_INVALID_BUFFER;
>   
> -   *pbuff = buf->data;
> +   if (buf->derived_surface.resource) {
> +  *pbuff = pipe_buffer_map(drv->pipe, buf->derived_surface.resource,
> +   PIPE_TRANSFER_WRITE,
> +   >derived_surface.transfer);
> +
> +  if (!buf->derived_surface.transfer || !*pbuff)
> + return VA_STATUS_ERROR_INVALID_BUFFER;
> +
> +   } else {
> +  *pbuff = buf->data;
> +   }
>   
>  return VA_STATUS_SUCCESS;
>   }
> @@ -103,16 +126,25 @@ vlVaMapBuffer(VADriverContextP ctx, VABufferID buf_id, 
> void **pbuff)
>   VAStatus
>   vlVaUnmapBuffer(VADriverContextP ctx, VABufferID buf_id)
>   {
> +   vlVaDriver *drv;
>  vlVaBuffer *buf;
>   
>  if (!ctx)
> return VA_STATUS_ERROR_INVALID_CONTEXT;
>   
> -   buf = handle_table_get(VL_VA_DRIVER(ctx)->htab, buf_id);
> +   drv = VL_VA_DRIVER(ctx);
> +
> +   buf = handle_table_get(drv->htab, buf_id);
>  if (!buf)
> return VA_STATUS_ERROR_INVALID_BUFFER;
>   
> -   /* Nothing to do here */
> +   if (buf->derived_surface.resource) {
> + if (!buf->derived_surface.transfer)
> +return VA_STATUS_ERROR_INVALID_BUFFER;
> +
> + pipe_buffer_unmap(drv->pipe, buf->derived_surface.transfer);
> + buf->derived_surface.transfer = NULL;
> +   }
>   
>  return VA_STATUS_SUCCESS;
>   }
> @@ -129,7 +161,12 @@ vlVaDestroyBuffer(VADriverContextP ctx, VABufferID 
> buf_id)
>  if (!buf)
> return VA_STATUS_ERROR_INVALID_BUFFER;
>   
> -   FREE(buf->data);
> +   if (buf->data)
> + FREE(buf->data);
> +
> +   if (buf->derived_surface.resource)
> + pipe_resource_reference(>derived_surface.resource, NULL);
> +
>  FREE(buf);
>  handle_table_remove(VL_VA_DRIVER(ctx)->htab, buf_id);
>   
> diff --git a/src/gallium/state_trackers/va/image.c 
> b/src/gallium/state_trackers/va/image.c
> index 8e64673..f266ce8 100644
> --- a/src/gallium/state_trackers/va/image.c
> +++ 

Re: [Mesa-dev] [PATCH 0/7] st/va: VPP, dmabuf import and headless.

2015-10-29 Thread Julien Isorce
Hi Christian,

Ok I'll send all of it including last 2 patches about dmabuf export. I
addressed all remarks already in my local branch and I did some round of
testing, so it should be ok.

Cheers
Julien


On 29 October 2015 at 12:10, Christian König 
wrote:

> Hi Julien,
>
> if Emil or Ilia have no further comments please send out your full set of
> patches once more I would like to get this pusched upstream.
>
> Best regards,
> Christian.
>
>
> On 17.10.2015 01:14, Julien Isorce wrote:
>
>> This patch serie adds initial support for Video Post Processing.
>> It also implements VaCreateSurfaces2 for common purpose and
>> also to import a dmabuf.
>> Finally it adds support for headless mode, i.e. using DRM
>> instead of X11 for device setup.
>>
>> Julien Isorce (7):
>>nvc0: fix crash when nv50_miptree_from_handle fails
>>st/va: properly defines VAImageFormat formats and improve
>>  VaCreateImage
>>st/va: in VaPutImage only destroy previous buffer if
>>  pipe->create_video_buffer succeeds
>>st/va: implement VaCreateSurfaces2 and VaQuerySurfaceAttributes
>>st/va: implement dmabuf import for VaCreateSurfaces2
>>st/va: add initial Video Post Processing support
>>st/va: add headless support, i.e. VA_DISPLAY_DRM
>>
>>   src/gallium/drivers/nouveau/nvc0/nvc0_resource.c |   3 +-
>>   src/gallium/state_trackers/va/Makefile.am|   9 +
>>   src/gallium/state_trackers/va/config.c   |  20 +
>>   src/gallium/state_trackers/va/context.c  | 148 ++--
>>   src/gallium/state_trackers/va/image.c|  29 +-
>>   src/gallium/state_trackers/va/picture.c  |  89 -
>>   src/gallium/state_trackers/va/surface.c  | 449
>> ---
>>   src/gallium/state_trackers/va/va_private.h   |  59 ++-
>>   8 files changed, 706 insertions(+), 100 deletions(-)
>>
>>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH v4 1/9] st/va: properly defines VAImageFormat formats and improve VaCreateImage

2015-10-29 Thread Julien Isorce
Also add RGBA, RGBX and BGRX.
Also extend ChromaToPipe and implement PipeToYCbCr.

Note that gstreamer-vaapi check all the VAImageFormat fields.

Signed-off-by: Julien Isorce 
---
 src/gallium/state_trackers/va/image.c  | 18 +++---
 src/gallium/state_trackers/va/va_private.h | 38 +-
 2 files changed, 52 insertions(+), 4 deletions(-)

diff --git a/src/gallium/state_trackers/va/image.c 
b/src/gallium/state_trackers/va/image.c
index b37a971..84d94c8 100644
--- a/src/gallium/state_trackers/va/image.c
+++ b/src/gallium/state_trackers/va/image.c
@@ -37,14 +37,21 @@
 
 #include "va_private.h"
 
-static const VAImageFormat formats[VL_VA_MAX_IMAGE_FORMATS] =
+static const VAImageFormat formats[] =
 {
{VA_FOURCC('N','V','1','2')},
{VA_FOURCC('I','4','2','0')},
{VA_FOURCC('Y','V','1','2')},
{VA_FOURCC('Y','U','Y','V')},
{VA_FOURCC('U','Y','V','Y')},
-   {VA_FOURCC('B','G','R','A')}
+   {.fourcc = VA_FOURCC('B','G','R','A'), .byte_order = VA_LSB_FIRST, 32, 32,
+0x00ff, 0xff00, 0x00ff, 0xff00},
+   {.fourcc = VA_FOURCC('R','G','B','A'), .byte_order = VA_LSB_FIRST, 32, 32,
+0x00ff, 0xff00, 0x00ff, 0xff00},
+   {.fourcc = VA_FOURCC('B','G','R','X'), .byte_order = VA_LSB_FIRST, 32, 24,
+0x00ff, 0xff00, 0x00ff, 0x},
+   {.fourcc = VA_FOURCC('R','G','B','X'), .byte_order = VA_LSB_FIRST, 32, 24,
+0x00ff, 0xff00, 0x00ff, 0x}
 };
 
 static void
@@ -72,6 +79,8 @@ vlVaQueryImageFormats(VADriverContextP ctx, VAImageFormat 
*format_list, int *num
enum pipe_format format;
int i;
 
+   STATIC_ASSERT(ARRAY_SIZE(formats) == VL_VA_MAX_IMAGE_FORMATS);
+
if (!ctx)
   return VA_STATUS_ERROR_INVALID_CONTEXT;
 
@@ -80,7 +89,7 @@ vlVaQueryImageFormats(VADriverContextP ctx, VAImageFormat 
*format_list, int *num
 
*num_formats = 0;
pscreen = VL_VA_PSCREEN(ctx);
-   for (i = 0; i < VL_VA_MAX_IMAGE_FORMATS; ++i) {
+   for (i = 0; i < ARRAY_SIZE(formats); ++i) {
   format = YCbCrToPipe(formats[i].fourcc);
   if (pscreen->is_video_format_supported(pscreen, format,
   PIPE_VIDEO_PROFILE_UNKNOWN,
@@ -149,6 +158,9 @@ vlVaCreateImage(VADriverContextP ctx, VAImageFormat 
*format, int width, int heig
   break;
 
case VA_FOURCC('B','G','R','A'):
+   case VA_FOURCC('R','G','B','A'):
+   case VA_FOURCC('B','G','R','X'):
+   case VA_FOURCC('R','G','B','X'):
   img->num_planes = 1;
   img->pitches[0] = w * 4;
   img->offsets[0] = 0;
diff --git a/src/gallium/state_trackers/va/va_private.h 
b/src/gallium/state_trackers/va/va_private.h
index 93af1be..6a0bd41 100644
--- a/src/gallium/state_trackers/va/va_private.h
+++ b/src/gallium/state_trackers/va/va_private.h
@@ -46,12 +46,14 @@
 #define VL_VA_DRIVER(ctx) ((vlVaDriver *)ctx->pDriverData)
 #define VL_VA_PSCREEN(ctx) (VL_VA_DRIVER(ctx)->vscreen->pscreen)
 
-#define VL_VA_MAX_IMAGE_FORMATS 6
+#define VL_VA_MAX_IMAGE_FORMATS 9
 
 static inline enum pipe_video_chroma_format
 ChromaToPipe(int format)
 {
switch (format) {
+   case VA_RT_FORMAT_YUV400:
+  return PIPE_VIDEO_CHROMA_FORMAT_400;
case VA_RT_FORMAT_YUV420:
   return PIPE_VIDEO_CHROMA_FORMAT_420;
case VA_RT_FORMAT_YUV422:
@@ -80,12 +82,46 @@ YCbCrToPipe(unsigned format)
   return PIPE_FORMAT_UYVY;
case VA_FOURCC('B','G','R','A'):
   return PIPE_FORMAT_B8G8R8A8_UNORM;
+   case VA_FOURCC('R','G','B','A'):
+  return PIPE_FORMAT_R8G8B8A8_UNORM;
+   case VA_FOURCC('B','G','R','X'):
+  return PIPE_FORMAT_B8G8R8X8_UNORM;
+   case VA_FOURCC('R','G','B','X'):
+  return PIPE_FORMAT_R8G8B8X8_UNORM;
default:
   assert(0);
   return PIPE_FORMAT_NONE;
}
 }
 
+static inline unsigned
+PipeToYCbCr(enum pipe_format p_format)
+{
+   switch (p_format) {
+   case PIPE_FORMAT_NV12:
+  return VA_FOURCC('N','V','1','2');
+   case PIPE_FORMAT_IYUV:
+  return VA_FOURCC('I','4','2','0');
+   case PIPE_FORMAT_YV12:
+  return VA_FOURCC('Y','V','1','2');
+   case PIPE_FORMAT_UYVY:
+  return VA_FOURCC('U','Y','V','Y');
+   case PIPE_FORMAT_YUYV:
+  return VA_FOURCC('Y','U','Y','V');
+   case PIPE_FORMAT_B8G8R8A8_UNORM:
+  return VA_FOURCC('B','G','R','A');
+   case PIPE_FORMAT_R8G8B8A8_UNORM:
+  return VA_FOURCC('R','G','B','A');
+   case PIPE_FORMAT_B8G8R8X8_UNORM:
+  return VA_FOURCC('B','G','R','X');
+   case PIPE_FORMAT_R8G8B8X8_UNORM:
+  return VA_FOURCC('R','G','B','X');
+   default:
+  assert(0);
+  return -1;
+   }
+}
+
 static inline VAProfile
 PipeToProfile(enum pipe_video_profile profile)
 {
-- 
1.9.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v2 2/7] st/va: properly defines VAImageFormat formats and improve VaCreateImage

2015-10-29 Thread Emil Velikov
On 20 October 2015 at 17:34, Julien Isorce  wrote:

>  static inline enum pipe_video_chroma_format
>  ChromaToPipe(int format)
>  {
> switch (format) {
> +   case VA_RT_FORMAT_YUV400:
> +  return PIPE_VIDEO_CHROMA_FORMAT_400;
Intentional ? We're barely handling it so might as well not bother
with it for now.

-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH v4 9/9] st/va: add support to export a surface as dmabuf

2015-10-29 Thread Julien Isorce
I.e. implements:
VaAcquireBufferHandle
VaReleaseBufferHandle
for memory of type VA_SURFACE_ATTRIB_MEM_TYPE_DRM_PRIME

And apply relatives change to:
vlVaMapBuffer
vlVaUnMapBuffer
vlVaDestroyBuffer

Implementation inspired from cgit.freedesktop.org/vaapi/intel-driver

Tested with gstreamer-vaapi with nouveau driver.

Signed-off-by: Julien Isorce 
---
 src/gallium/state_trackers/va/buffer.c | 136 -
 src/gallium/state_trackers/va/context.c|   4 +-
 src/gallium/state_trackers/va/va_private.h |   6 ++
 3 files changed, 144 insertions(+), 2 deletions(-)

diff --git a/src/gallium/state_trackers/va/buffer.c 
b/src/gallium/state_trackers/va/buffer.c
index 6e32541..8f8f22a 100644
--- a/src/gallium/state_trackers/va/buffer.c
+++ b/src/gallium/state_trackers/va/buffer.c
@@ -27,6 +27,7 @@
  **/
 
 #include "pipe/p_screen.h"
+#include "state_tracker/drm_driver.h"
 #include "util/u_memory.h"
 #include "util/u_handle_table.h"
 #include "util/u_transfer.h"
@@ -108,6 +109,9 @@ vlVaMapBuffer(VADriverContextP ctx, VABufferID buf_id, void 
**pbuff)
if (!buf)
   return VA_STATUS_ERROR_INVALID_BUFFER;
 
+   if (buf->export_refcount > 0)
+  return VA_STATUS_ERROR_INVALID_BUFFER;
+
if (buf->derived_surface.resource) {
   *pbuff = pipe_buffer_map(drv->pipe, buf->derived_surface.resource,
PIPE_TRANSFER_WRITE,
@@ -138,6 +142,9 @@ vlVaUnmapBuffer(VADriverContextP ctx, VABufferID buf_id)
if (!buf)
   return VA_STATUS_ERROR_INVALID_BUFFER;
 
+   if (buf->export_refcount > 0)
+  return VA_STATUS_ERROR_INVALID_BUFFER;
+
if (buf->derived_surface.resource) {
  if (!buf->derived_surface.transfer)
 return VA_STATUS_ERROR_INVALID_BUFFER;
@@ -161,8 +168,12 @@ vlVaDestroyBuffer(VADriverContextP ctx, VABufferID buf_id)
if (!buf)
   return VA_STATUS_ERROR_INVALID_BUFFER;
 
-   if (buf->derived_surface.resource)
+   if (buf->derived_surface.resource) {
+ if (buf->export_refcount > 0)
+   return VA_STATUS_ERROR_INVALID_BUFFER;
+
  pipe_resource_reference(>derived_surface.resource, NULL);
+   }
 
FREE(buf->data);
FREE(buf);
@@ -190,3 +201,126 @@ vlVaBufferInfo(VADriverContextP ctx, VABufferID buf_id, 
VABufferType *type,
 
return VA_STATUS_SUCCESS;
 }
+
+VAStatus
+vlVaAcquireBufferHandle(VADriverContextP ctx, VABufferID buf_id,
+VABufferInfo *out_buf_info)
+{
+   uint32_t i;
+   uint32_t mem_type;
+   vlVaBuffer *buf ;
+   struct pipe_screen *screen;
+
+   /* List of supported memory types, in preferred order. */
+   static const uint32_t mem_types[] = {
+  VA_SURFACE_ATTRIB_MEM_TYPE_DRM_PRIME,
+  0
+   };
+
+   if (!ctx)
+  return VA_STATUS_ERROR_INVALID_CONTEXT;
+
+   buf = handle_table_get(VL_VA_DRIVER(ctx)->htab, buf_id);
+
+   if (!buf)
+  return VA_STATUS_ERROR_INVALID_BUFFER;
+
+   /* Only VA surface|image like buffers are supported for now .*/
+   if (buf->type != VAImageBufferType)
+  return VA_STATUS_ERROR_UNSUPPORTED_BUFFERTYPE;
+
+   if (!out_buf_info)
+  return VA_STATUS_ERROR_INVALID_PARAMETER;
+
+   if (!out_buf_info->mem_type)
+  mem_type = mem_types[0];
+   else {
+  mem_type = 0;
+  for (i = 0; mem_types[i] != 0; i++) {
+ if (out_buf_info->mem_type & mem_types[i]) {
+mem_type = out_buf_info->mem_type;
+break;
+ }
+  }
+  if (!mem_type)
+ return VA_STATUS_ERROR_UNSUPPORTED_MEMORY_TYPE;
+   }
+
+   if (!buf->derived_surface.resource)
+  return VA_STATUS_ERROR_INVALID_BUFFER;
+
+   screen = VL_VA_PSCREEN(ctx);
+
+   if (buf->derived_surface.fence) {
+  screen->fence_finish(screen, buf->derived_surface.fence, 
PIPE_TIMEOUT_INFINITE);
+  screen->fence_reference(screen, >derived_surface.fence, NULL);
+   }
+
+   if (buf->export_refcount > 0) {
+  if (buf->export_state.mem_type != mem_type)
+ return VA_STATUS_ERROR_INVALID_PARAMETER;
+   } else {
+  VABufferInfo * const buf_info = >export_state;
+
+  switch (mem_type) {
+  case VA_SURFACE_ATTRIB_MEM_TYPE_DRM_PRIME: {
+ struct winsys_handle whandle;
+
+ memset(, 0, sizeof(whandle));
+ whandle.type = DRM_API_HANDLE_TYPE_FD;
+
+ if (!screen->resource_get_handle(screen, 
buf->derived_surface.resource, ))
+return VA_STATUS_ERROR_INVALID_BUFFER;
+
+ buf_info->handle = (intptr_t)whandle.handle;
+ break;
+  default:
+ return VA_STATUS_ERROR_UNSUPPORTED_MEMORY_TYPE;
+  }
+   }
+
+   buf_info->type = buf->type;
+   buf_info->mem_type = mem_type;
+   buf_info->mem_size = buf->num_elements * buf->size;
+
+   }
+
+   buf->export_refcount++;
+
+   *out_buf_info = buf->export_state;
+
+   return VA_STATUS_SUCCESS;
+}
+
+VAStatus
+vlVaReleaseBufferHandle(VADriverContextP ctx, VABufferID buf_id)
+{
+   vlVaBuffer *buf;
+
+   if (!ctx)
+  

[Mesa-dev] [PATCH v4 4/9] st/va: implement dmabuf import for VaCreateSurfaces2

2015-10-29 Thread Julien Isorce
For now it is limited to RGBA, BGRA, RGBX, BGRX surfaces.

Signed-off-by: Julien Isorce 
---
 src/gallium/state_trackers/va/surface.c | 97 -
 1 file changed, 96 insertions(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/va/surface.c 
b/src/gallium/state_trackers/va/surface.c
index c3c015e..c1f7182 100644
--- a/src/gallium/state_trackers/va/surface.c
+++ b/src/gallium/state_trackers/va/surface.c
@@ -29,6 +29,8 @@
 #include "pipe/p_screen.h"
 #include "pipe/p_video_codec.h"
 
+#include "state_tracker/drm_driver.h"
+
 #include "util/u_memory.h"
 #include "util/u_handle_table.h"
 #include "util/u_rect.h"
@@ -41,6 +43,8 @@
 
 #include "va_private.h"
 
+#include 
+
 VAStatus
 vlVaCreateSurfaces(VADriverContextP ctx, int width, int height, int format,
int num_surfaces, VASurfaceID *surfaces)
@@ -368,7 +372,8 @@ vlVaQuerySurfaceAttributes(VADriverContextP ctx, VAConfigID 
config,
 attribs[i].type = VASurfaceAttribMemoryType;
 attribs[i].value.type = VAGenericValueTypeInteger;
 attribs[i].flags = VA_SURFACE_ATTRIB_GETTABLE | VA_SURFACE_ATTRIB_SETTABLE;
-attribs[i].value.value.i = VA_SURFACE_ATTRIB_MEM_TYPE_VA;
+attribs[i].value.value.i = VA_SURFACE_ATTRIB_MEM_TYPE_VA |
+VA_SURFACE_ATTRIB_MEM_TYPE_DRM_PRIME;
 i++;
 
 attribs[i].type = VASurfaceAttribExternalBufferDescriptor;
@@ -402,6 +407,83 @@ vlVaQuerySurfaceAttributes(VADriverContextP ctx, 
VAConfigID config,
 return VA_STATUS_SUCCESS;
 }
 
+static VAStatus
+suface_from_external_memory(VADriverContextP ctx, vlVaSurface *surface,
+VASurfaceAttribExternalBuffers *memory_attibute,
+int index, VASurfaceID *surfaces,
+struct pipe_video_buffer *templat)
+{
+vlVaDriver *drv;
+struct pipe_screen *pscreen;
+struct pipe_resource *resource;
+struct pipe_resource res_templ;
+struct winsys_handle whandle;
+struct pipe_resource *resources[VL_NUM_COMPONENTS];
+
+if (!ctx)
+return VA_STATUS_ERROR_INVALID_PARAMETER;
+
+pscreen = VL_VA_PSCREEN(ctx);
+drv = VL_VA_DRIVER(ctx);
+
+if (!memory_attibute || !memory_attibute->buffers ||
+index > memory_attibute->num_buffers)
+return VA_STATUS_ERROR_INVALID_PARAMETER;
+
+if (surface->templat.width != memory_attibute->width ||
+surface->templat.height != memory_attibute->height ||
+memory_attibute->num_planes < 1)
+return VA_STATUS_ERROR_INVALID_PARAMETER;
+
+switch (memory_attibute->pixel_format) {
+case VA_FOURCC_RGBA:
+case VA_FOURCC_RGBX:
+case VA_FOURCC_BGRA:
+case VA_FOURCC_BGRX:
+if (memory_attibute->num_planes != 1)
+return VA_STATUS_ERROR_INVALID_PARAMETER;
+break;
+default:
+return VA_STATUS_ERROR_INVALID_PARAMETER;
+}
+
+memset(_templ, 0, sizeof(res_templ));
+res_templ.target = PIPE_TEXTURE_2D;
+res_templ.last_level = 0;
+res_templ.depth0 = 1;
+res_templ.array_size = 1;
+res_templ.width0 = memory_attibute->width;
+res_templ.height0 = memory_attibute->height;
+res_templ.format = surface->templat.buffer_format;
+res_templ.bind = PIPE_BIND_SAMPLER_VIEW;
+res_templ.usage = PIPE_USAGE_DEFAULT;
+
+memset(, 0, sizeof(struct winsys_handle));
+whandle.type = DRM_API_HANDLE_TYPE_FD;
+whandle.handle = memory_attibute->buffers[index];
+whandle.stride = memory_attibute->pitches[index];
+
+resource = pscreen->resource_from_handle(pscreen, _templ, );
+
+if (!resource)
+   return VA_STATUS_ERROR_ALLOCATION_FAILED;
+
+memset(resources, 0, sizeof resources);
+resources[0] = resource;
+
+surface->buffer = vl_video_buffer_create_ex2(drv->pipe, templat, 
resources);
+if (!surface->buffer)
+return VA_STATUS_ERROR_ALLOCATION_FAILED;
+
+util_dynarray_init(>subpics);
+surfaces[index] = handle_table_add(drv->htab, surface);
+
+if (!surfaces[index])
+  return VA_STATUS_ERROR_ALLOCATION_FAILED;
+
+return VA_STATUS_SUCCESS;
+}
+
 VAStatus
 vlVaCreateSurfaces2(VADriverContextP ctx, unsigned int format,
 unsigned int width, unsigned int height,
@@ -415,6 +497,7 @@ vlVaCreateSurfaces2(VADriverContextP ctx, unsigned int 
format,
 int i;
 int memory_type;
 int expected_fourcc;
+VAStatus vaStatus;
 
 if (!ctx)
return VA_STATUS_ERROR_INVALID_CONTEXT;
@@ -453,6 +536,7 @@ vlVaCreateSurfaces2(VADriverContextP ctx, unsigned int 
format,
 
 switch (attrib_list[i].value.value.i) {
 case VA_SURFACE_ATTRIB_MEM_TYPE_VA:
+case VA_SURFACE_ATTRIB_MEM_TYPE_DRM_PRIME:
memory_type = attrib_list[i].value.value.i;
break;
 default:
@@ -479,6 +563,12 @@ vlVaCreateSurfaces2(VADriverContextP ctx, unsigned int 
format,
 switch (memory_type) {
 case 

[Mesa-dev] [PATCH v4 3/9] st/va: implement VaCreateSurfaces2 and VaQuerySurfaceAttributes

2015-10-29 Thread Julien Isorce
Inspired from http://cgit.freedesktop.org/vaapi/intel-driver/
especially src/i965_drv_video.c::i965_CreateSurfaces2.

This patch is mainly to support gstreamer-vaapi and tools that uses
this newer libva API. The first advantage of using VaCreateSurfaces2
over existing VaCreateSurfaces, is that it is possible to select which
the pixel format for the surface. Indeed with the simple VaCreateSurfaces
function it is only possible to create a NV12 surface. It can be useful
to create a RGBA surface to use with video post processing.

The avaible pixel formats can be query with VaQuerySurfaceAttributes.

Signed-off-by: Julien Isorce 
---
 src/gallium/state_trackers/va/context.c|   5 +-
 src/gallium/state_trackers/va/surface.c| 294 -
 src/gallium/state_trackers/va/va_private.h |   6 +-
 3 files changed, 253 insertions(+), 52 deletions(-)

diff --git a/src/gallium/state_trackers/va/context.c 
b/src/gallium/state_trackers/va/context.c
index 5adbe76..9cc402e 100644
--- a/src/gallium/state_trackers/va/context.c
+++ b/src/gallium/state_trackers/va/context.c
@@ -81,7 +81,10 @@ static struct VADriverVTable vtable =
,
,
,
-   
+   ,
+   NULL, /* DEPRECATED VaGetSurfaceAttributes */
+   ,
+   
 };
 
 PUBLIC VAStatus
diff --git a/src/gallium/state_trackers/va/surface.c 
b/src/gallium/state_trackers/va/surface.c
index 8d4487b..c3c015e 100644
--- a/src/gallium/state_trackers/va/surface.c
+++ b/src/gallium/state_trackers/va/surface.c
@@ -36,6 +36,7 @@
 #include "util/u_surface.h"
 
 #include "vl/vl_compositor.h"
+#include "vl/vl_video_buffer.h"
 #include "vl/vl_winsys.h"
 
 #include "va_private.h"
@@ -44,56 +45,8 @@ VAStatus
 vlVaCreateSurfaces(VADriverContextP ctx, int width, int height, int format,
int num_surfaces, VASurfaceID *surfaces)
 {
-   struct pipe_video_buffer templat = {};
-   struct pipe_screen *pscreen;
-   vlVaDriver *drv;
-   int i;
-
-   if (!ctx)
-  return VA_STATUS_ERROR_INVALID_CONTEXT;
-
-   if (!(width && height))
-  return VA_STATUS_ERROR_INVALID_IMAGE_FORMAT;
-
-   drv = VL_VA_DRIVER(ctx);
-   pscreen = VL_VA_PSCREEN(ctx);
-
-   templat.buffer_format = pscreen->get_video_param
-   (
-  pscreen,
-  PIPE_VIDEO_PROFILE_UNKNOWN,
-  PIPE_VIDEO_ENTRYPOINT_BITSTREAM,
-  PIPE_VIDEO_CAP_PREFERED_FORMAT
-   );
-   templat.chroma_format = ChromaToPipe(format);
-   templat.width = width;
-   templat.height = height;
-   templat.interlaced = pscreen->get_video_param
-   (
-  pscreen,
-  PIPE_VIDEO_PROFILE_UNKNOWN,
-  PIPE_VIDEO_ENTRYPOINT_BITSTREAM,
-  PIPE_VIDEO_CAP_PREFERS_INTERLACED
-   );
-
-   for (i = 0; i < num_surfaces; ++i) {
-  vlVaSurface *surf = CALLOC(1, sizeof(vlVaSurface));
-  if (!surf)
- goto no_res;
-
-  surf->templat = templat;
-  surf->buffer = drv->pipe->create_video_buffer(drv->pipe, );
-  util_dynarray_init(>subpics);
-  surfaces[i] = handle_table_add(drv->htab, surf);
-   }
-
-   return VA_STATUS_SUCCESS;
-
-no_res:
-   if (i)
-  vlVaDestroySurfaces(ctx, surfaces, i);
-
-   return VA_STATUS_ERROR_ALLOCATION_FAILED;
+   return vlVaCreateSurfaces2(ctx, format, width, height, surfaces, 
num_surfaces,
+  NULL, 0);
 }
 
 VAStatus
@@ -349,3 +302,244 @@ vlVaUnlockSurface(VADriverContextP ctx, VASurfaceID 
surface)
 
return VA_STATUS_ERROR_UNIMPLEMENTED;
 }
+
+VAStatus
+vlVaQuerySurfaceAttributes(VADriverContextP ctx, VAConfigID config,
+   VASurfaceAttrib *attrib_list, unsigned int 
*num_attribs)
+{
+vlVaDriver *drv;
+VASurfaceAttrib *attribs;
+struct pipe_screen *pscreen;
+int i;
+
+if (config == VA_INVALID_ID)
+return VA_STATUS_ERROR_INVALID_CONFIG;
+
+if (!attrib_list && !num_attribs)
+return VA_STATUS_ERROR_INVALID_PARAMETER;
+
+if (!attrib_list) {
+*num_attribs = VASurfaceAttribCount;
+return VA_STATUS_SUCCESS;
+}
+
+if (!ctx)
+   return VA_STATUS_ERROR_INVALID_CONTEXT;
+
+drv = VL_VA_DRIVER(ctx);
+
+if (!drv)
+return VA_STATUS_ERROR_INVALID_CONTEXT;
+
+pscreen = VL_VA_PSCREEN(ctx);
+
+if (!pscreen)
+   return VA_STATUS_ERROR_INVALID_CONTEXT;
+
+attribs = CALLOC(VASurfaceAttribCount, sizeof(VASurfaceAttrib));
+
+if (!attribs)
+return VA_STATUS_ERROR_ALLOCATION_FAILED;
+
+i = 0;
+
+if (config == PIPE_VIDEO_PROFILE_UNKNOWN) {
+   /* Assume VAEntrypointVideoProc for now. */
+   attribs[i].type = VASurfaceAttribPixelFormat;
+   attribs[i].value.type = VAGenericValueTypeInteger;
+   attribs[i].flags = VA_SURFACE_ATTRIB_GETTABLE | 
VA_SURFACE_ATTRIB_SETTABLE;
+   attribs[i].value.value.i = VA_FOURCC_BGRA;
+   i++;
+
+   attribs[i].type = VASurfaceAttribPixelFormat;
+   attribs[i].value.type = VAGenericValueTypeInteger;
+   attribs[i].flags = VA_SURFACE_ATTRIB_GETTABLE | 
VA_SURFACE_ATTRIB_SETTABLE;
+   

[Mesa-dev] [PATCH v4 8/9] st/va: implement VaDeriveImage

2015-10-29 Thread Julien Isorce
And apply relatives change to:
vlVaBufferSetNumElements
vlVaCreateBuffer
vlVaMapBuffer
vlVaUnmapBuffer
vlVaDestroyBuffer
vlVaPutImage

It is unfortunate that there is no proper va buffer type and struct
for this. Only possible to use VAImageBufferType which is normally
used for normal user data array.
On of the consequences is that it is only possible VaDeriveImage
is only useful on surfaces backed with contiguous planes.
Implementation inspired from cgit.freedesktop.org/vaapi/intel-driver

Signed-off-by: Julien Isorce 
---
 src/gallium/state_trackers/va/buffer.c | 43 --
 src/gallium/state_trackers/va/image.c  | 92 +-
 src/gallium/state_trackers/va/va_private.h |  5 ++
 3 files changed, 135 insertions(+), 5 deletions(-)

diff --git a/src/gallium/state_trackers/va/buffer.c 
b/src/gallium/state_trackers/va/buffer.c
index 8f9ba44..6e32541 100644
--- a/src/gallium/state_trackers/va/buffer.c
+++ b/src/gallium/state_trackers/va/buffer.c
@@ -26,8 +26,11 @@
  *
  **/
 
+#include "pipe/p_screen.h"
 #include "util/u_memory.h"
 #include "util/u_handle_table.h"
+#include "util/u_transfer.h"
+#include "vl/vl_winsys.h"
 
 #include "va_private.h"
 
@@ -73,6 +76,10 @@ vlVaBufferSetNumElements(VADriverContextP ctx, VABufferID 
buf_id,
   return VA_STATUS_ERROR_INVALID_CONTEXT;
 
buf = handle_table_get(VL_VA_DRIVER(ctx)->htab, buf_id);
+
+   if (!buf || buf->derived_surface.resource)
+  return VA_STATUS_ERROR_INVALID_BUFFER;
+
buf->data = REALLOC(buf->data, buf->size * buf->num_elements,
buf->size * num_elements);
buf->num_elements = num_elements;
@@ -86,16 +93,32 @@ vlVaBufferSetNumElements(VADriverContextP ctx, VABufferID 
buf_id,
 VAStatus
 vlVaMapBuffer(VADriverContextP ctx, VABufferID buf_id, void **pbuff)
 {
+   vlVaDriver *drv;
vlVaBuffer *buf;
 
if (!ctx)
   return VA_STATUS_ERROR_INVALID_CONTEXT;
 
-   buf = handle_table_get(VL_VA_DRIVER(ctx)->htab, buf_id);
+   if (!pbuff)
+  return VA_STATUS_ERROR_INVALID_BUFFER;
+
+   drv = VL_VA_DRIVER(ctx);
+
+   buf = handle_table_get(drv->htab, buf_id);
if (!buf)
   return VA_STATUS_ERROR_INVALID_BUFFER;
 
-   *pbuff = buf->data;
+   if (buf->derived_surface.resource) {
+  *pbuff = pipe_buffer_map(drv->pipe, buf->derived_surface.resource,
+   PIPE_TRANSFER_WRITE,
+   >derived_surface.transfer);
+
+  if (!buf->derived_surface.transfer || !*pbuff)
+ return VA_STATUS_ERROR_INVALID_BUFFER;
+
+   } else {
+  *pbuff = buf->data;
+   }
 
return VA_STATUS_SUCCESS;
 }
@@ -103,16 +126,25 @@ vlVaMapBuffer(VADriverContextP ctx, VABufferID buf_id, 
void **pbuff)
 VAStatus
 vlVaUnmapBuffer(VADriverContextP ctx, VABufferID buf_id)
 {
+   vlVaDriver *drv;
vlVaBuffer *buf;
 
if (!ctx)
   return VA_STATUS_ERROR_INVALID_CONTEXT;
 
-   buf = handle_table_get(VL_VA_DRIVER(ctx)->htab, buf_id);
+   drv = VL_VA_DRIVER(ctx);
+
+   buf = handle_table_get(drv->htab, buf_id);
if (!buf)
   return VA_STATUS_ERROR_INVALID_BUFFER;
 
-   /* Nothing to do here */
+   if (buf->derived_surface.resource) {
+ if (!buf->derived_surface.transfer)
+return VA_STATUS_ERROR_INVALID_BUFFER;
+
+ pipe_buffer_unmap(drv->pipe, buf->derived_surface.transfer);
+ buf->derived_surface.transfer = NULL;
+   }
 
return VA_STATUS_SUCCESS;
 }
@@ -129,6 +161,9 @@ vlVaDestroyBuffer(VADriverContextP ctx, VABufferID buf_id)
if (!buf)
   return VA_STATUS_ERROR_INVALID_BUFFER;
 
+   if (buf->derived_surface.resource)
+ pipe_resource_reference(>derived_surface.resource, NULL);
+
FREE(buf->data);
FREE(buf);
handle_table_remove(VL_VA_DRIVER(ctx)->htab, buf_id);
diff --git a/src/gallium/state_trackers/va/image.c 
b/src/gallium/state_trackers/va/image.c
index 8e64673..f266ce8 100644
--- a/src/gallium/state_trackers/va/image.c
+++ b/src/gallium/state_trackers/va/image.c
@@ -184,10 +184,95 @@ vlVaCreateImage(VADriverContextP ctx, VAImageFormat 
*format, int width, int heig
 VAStatus
 vlVaDeriveImage(VADriverContextP ctx, VASurfaceID surface, VAImage *image)
 {
+   vlVaDriver *drv;
+   vlVaSurface *surf;
+   vlVaBuffer *img_buf;
+   VAImage *img;
+   struct pipe_surface **surfaces;
+   int w;
+   int h;
+   int i;
+
if (!ctx)
   return VA_STATUS_ERROR_INVALID_CONTEXT;
 
-   return VA_STATUS_ERROR_UNIMPLEMENTED;
+   drv = VL_VA_DRIVER(ctx);
+
+   if (!drv)
+  return VA_STATUS_ERROR_INVALID_CONTEXT;
+
+   surf = handle_table_get(drv->htab, surface);
+
+   if (!surf || !surf->buffer || surf->buffer->interlaced)
+  return VA_STATUS_ERROR_INVALID_SURFACE;
+
+   surfaces = surf->buffer->get_surfaces(surf->buffer);
+   if (!surfaces || !surfaces[0]->texture)
+  return VA_STATUS_ERROR_ALLOCATION_FAILED;
+
+   img = CALLOC(1, sizeof(VAImage));
+   if (!img)
+  return 

[Mesa-dev] [Bug 92645] kodi vdpau interop fails since mesa, meta: move gl_texture_object::TargetIndex initializations

2015-10-29 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=92645

Marek Olšák  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Marek Olšák  ---
Fixed by 6a4dc1ad492d7d53c5c17e6eb975f0ed44b674.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] radeonsi: add ETC2 support for Stoney

2015-10-29 Thread Marek Olšák
From: Marek Olšák 

Untested. I don't have Stoney.
---
 src/gallium/drivers/radeonsi/si_state.c | 28 
 src/gallium/drivers/radeonsi/sid.h  | 20 ++--
 2 files changed, 38 insertions(+), 10 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_state.c 
b/src/gallium/drivers/radeonsi/si_state.c
index 18b6405..63c5be0 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/si_state.c
@@ -1317,6 +1317,29 @@ static uint32_t si_translate_texformat(struct 
pipe_screen *screen,
}
}
 
+   if (desc->layout == UTIL_FORMAT_LAYOUT_ETC &&
+   sscreen->b.family >= CHIP_STONEY) {
+   switch (format) {
+   case PIPE_FORMAT_ETC2_RGB8:
+   case PIPE_FORMAT_ETC2_SRGB8:
+   return V_008F14_IMG_DATA_FORMAT_ETC2_RGB;
+   case PIPE_FORMAT_ETC2_RGB8A1:
+   case PIPE_FORMAT_ETC2_SRGB8A1:
+   return V_008F14_IMG_DATA_FORMAT_ETC2_RGBA1;
+   case PIPE_FORMAT_ETC2_RGBA8:
+   case PIPE_FORMAT_ETC2_SRGBA8:
+   return V_008F14_IMG_DATA_FORMAT_ETC2_RGBA;
+   case PIPE_FORMAT_ETC2_R11_UNORM:
+   case PIPE_FORMAT_ETC2_R11_SNORM:
+   return V_008F14_IMG_DATA_FORMAT_ETC2_R;
+   case PIPE_FORMAT_ETC2_RG11_UNORM:
+   case PIPE_FORMAT_ETC2_RG11_SNORM:
+   return V_008F14_IMG_DATA_FORMAT_ETC2_RG;
+   default:
+   goto out_unknown;
+   }
+   }
+
if (desc->layout == UTIL_FORMAT_LAYOUT_BPTC) {
if (!enable_compressed_formats)
goto out_unknown;
@@ -2542,12 +2565,17 @@ si_create_sampler_view_custom(struct pipe_context *ctx,
case PIPE_FORMAT_DXT3_SRGBA:
case PIPE_FORMAT_DXT5_SRGBA:
case PIPE_FORMAT_BPTC_SRGBA:
+   case PIPE_FORMAT_ETC2_SRGB8:
+   case PIPE_FORMAT_ETC2_SRGB8A1:
+   case PIPE_FORMAT_ETC2_SRGBA8:
num_format = 
V_008F14_IMG_NUM_FORMAT_SRGB;
break;
case PIPE_FORMAT_RGTC1_SNORM:
case PIPE_FORMAT_LATC1_SNORM:
case PIPE_FORMAT_RGTC2_SNORM:
case PIPE_FORMAT_LATC2_SNORM:
+   case PIPE_FORMAT_ETC2_R11_SNORM:
+   case PIPE_FORMAT_ETC2_RG11_SNORM:
/* implies float, so use SNORM/UNORM to 
determine
   whether data is signed or not */
case PIPE_FORMAT_BPTC_RGB_FLOAT:
diff --git a/src/gallium/drivers/radeonsi/sid.h 
b/src/gallium/drivers/radeonsi/sid.h
index 4bb2457..49d8e2c 100644
--- a/src/gallium/drivers/radeonsi/sid.h
+++ b/src/gallium/drivers/radeonsi/sid.h
@@ -2059,12 +2059,12 @@
 #define V_008F14_IMG_DATA_FORMAT_8_24   0x14
 #define V_008F14_IMG_DATA_FORMAT_24_8   0x15
 #define V_008F14_IMG_DATA_FORMAT_X24_8_32   0x16
-#define V_008F14_IMG_DATA_FORMAT_RESERVED_230x17
-#define V_008F14_IMG_DATA_FORMAT_RESERVED_240x18
-#define V_008F14_IMG_DATA_FORMAT_RESERVED_250x19
-#define V_008F14_IMG_DATA_FORMAT_RESERVED_260x1A
-#define V_008F14_IMG_DATA_FORMAT_RESERVED_270x1B
-#define V_008F14_IMG_DATA_FORMAT_RESERVED_280x1C
+#define V_008F14_IMG_DATA_FORMAT_8_AS_8_8_8_8   0x17 /* 
stoney+ */
+#define V_008F14_IMG_DATA_FORMAT_ETC2_RGB   0x18 /* 
stoney+ */
+#define V_008F14_IMG_DATA_FORMAT_ETC2_RGBA  0x19 /* 
stoney+ */
+#define V_008F14_IMG_DATA_FORMAT_ETC2_R 0x1A /* 
stoney+ */
+#define V_008F14_IMG_DATA_FORMAT_ETC2_RG0x1B /* 
stoney+ */
+#define V_008F14_IMG_DATA_FORMAT_ETC2_RGBA1 0x1C /* 
stoney+ */
 #define V_008F14_IMG_DATA_FORMAT_RESERVED_290x1D
 #define V_008F14_IMG_DATA_FORMAT_RESERVED_300x1E
 #define V_008F14_IMG_DATA_FORMAT_RESERVED_310x1F
@@ -2078,8 +2078,8 @@
 #define V_008F14_IMG_DATA_FORMAT_BC50x27
 #define V_008F14_IMG_DATA_FORMAT_BC60x28
 #define V_008F14_IMG_DATA_FORMAT_BC70x29
-#define V_008F14_IMG_DATA_FORMAT_RESERVED_420x2A
-#define V_008F14_IMG_DATA_FORMAT_RESERVED_43

Re: [Mesa-dev] [PATCH 2/2] mesa/sso: Add compute shader support

2015-10-29 Thread Jordan Justen
On 2015-10-29 03:04:38, Iago Toral wrote:
> On Thu, 2015-10-29 at 00:52 -0700, Jordan Justen wrote:
> > Signed-off-by: Jordan Justen 
> > ---
> >  src/mesa/main/api_validate.c |  2 +-
> >  src/mesa/main/pipelineobj.c  | 11 +++
> >  2 files changed, 12 insertions(+), 1 deletion(-)
> > 
> > diff --git a/src/mesa/main/api_validate.c b/src/mesa/main/api_validate.c
> > index c59b6f3..46f39e7 100644
> > --- a/src/mesa/main/api_validate.c
> > +++ b/src/mesa/main/api_validate.c
> > @@ -923,7 +923,7 @@ check_valid_to_compute(struct gl_context *ctx, const 
> > char *function)
> >  * "An INVALID_OPERATION error is generated if there is no active 
> > program
> >  *  for the compute shader stage."
> >  */
> > -   prog = ctx->Shader.CurrentProgram[MESA_SHADER_COMPUTE];
> > +   prog = ctx->_Shader->CurrentProgram[MESA_SHADER_COMPUTE];
> > if (prog == NULL || prog->_LinkedShaders[MESA_SHADER_COMPUTE] == NULL) {
> >_mesa_error(ctx, GL_INVALID_OPERATION,
> >"%s(no active compute shader)",
> 
> This hunk won't apply on current master, there is no such comment before
> this line. Maybe this is part of another series of patches?

I guess this depends on some nearby changed lines in my unreviewed
patch:

  "main: Match DispatchCompute* API validation from main specification"

http://patchwork.freedesktop.org/patch/61881/

-Jordan

> For the rest of the patch:
> Reviewed-by: Iago Toral Quiroga 
> 
> > diff --git a/src/mesa/main/pipelineobj.c b/src/mesa/main/pipelineobj.c
> > index c8c50fa..58730f4 100644
> > --- a/src/mesa/main/pipelineobj.c
> > +++ b/src/mesa/main/pipelineobj.c
> > @@ -255,6 +255,8 @@ _mesa_UseProgramStages(GLuint pipeline, GLbitfield 
> > stages, GLuint program)
> > if (_mesa_has_tessellation(ctx))
> >any_valid_stages |= GL_TESS_CONTROL_SHADER_BIT |
> >GL_TESS_EVALUATION_SHADER_BIT;
> > +   if (_mesa_has_compute_shaders(ctx))
> > +  any_valid_stages |= GL_COMPUTE_SHADER_BIT;
> >  
> > if (stages != GL_ALL_SHADER_BITS && (stages & ~any_valid_stages) != 0) {
> >_mesa_error(ctx, GL_INVALID_VALUE, "glUseProgramStages(Stages)");
> > @@ -336,6 +338,9 @@ _mesa_UseProgramStages(GLuint pipeline, GLbitfield 
> > stages, GLuint program)
> >  
> > if ((stages & GL_TESS_EVALUATION_SHADER_BIT) != 0)
> >_mesa_use_shader_program(ctx, GL_TESS_EVALUATION_SHADER, shProg, 
> > pipe);
> > +
> > +   if ((stages & GL_COMPUTE_SHADER_BIT) != 0)
> > +  _mesa_use_shader_program(ctx, GL_COMPUTE_SHADER, shProg, pipe);
> >  }
> >  
> >  /**
> > @@ -669,6 +674,12 @@ _mesa_GetProgramPipelineiv(GLuint pipeline, GLenum 
> > pname, GLint *params)
> >*params = pipe->CurrentProgram[MESA_SHADER_FRAGMENT]
> >   ? pipe->CurrentProgram[MESA_SHADER_FRAGMENT]->Name : 0;
> >return;
> > +   case GL_COMPUTE_SHADER:
> > +  if (!_mesa_has_compute_shaders(ctx))
> > + break;
> > +  *params = pipe->CurrentProgram[MESA_SHADER_COMPUTE]
> > + ? pipe->CurrentProgram[MESA_SHADER_COMPUTE]->Name : 0;
> > +  return;
> > default:
> >break;
> > }
> 
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] gbm.h: Add a missing stddef.h include for size_t.

2015-10-29 Thread Grazvydas Ignotas
Hi,

On Thu, Oct 29, 2015 at 6:21 PM, Emil Velikov  wrote:
> On 29 October 2015 at 15:22, Emmanuel Gil Peyrot
>  wrote:
>> This was causing compilation issues when one of its providers wasn’t
>> already included before gbm.h.
> Cc: "11.0" 
> Reviewed-by: Emil Velikov 
>
> I'll push this later on today. For future patches please include your
> s-o-b line.

Some of you keep insisting on adding s-o-b while the site says it's
not needed ( http://www.mesa3d.org/devinfo.html , "Patch formatting").
Maybe devinfo.html should be updated?

Gražvydas

>
> -Emil
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v4 1/9] st/va: properly defines VAImageFormat formats and improve VaCreateImage

2015-10-29 Thread Christian König

@@ -80,12 +82,46 @@ YCbCrToPipe(unsigned format)

...

+PipeToYCbCr(enum pipe_format p_format)


You should probably rename those two functions as well, cause when we 
start to handle RGB formats as well the name doesn't match any more.


BTW when do you use PipeToYCbCr?

Regards,
Christian.

On 29.10.2015 18:40, Julien Isorce wrote:

Also add RGBA, RGBX and BGRX.
Also extend ChromaToPipe and implement PipeToYCbCr.

Note that gstreamer-vaapi check all the VAImageFormat fields.

Signed-off-by: Julien Isorce 
---
  src/gallium/state_trackers/va/image.c  | 18 +++---
  src/gallium/state_trackers/va/va_private.h | 38 +-
  2 files changed, 52 insertions(+), 4 deletions(-)

diff --git a/src/gallium/state_trackers/va/image.c 
b/src/gallium/state_trackers/va/image.c
index b37a971..84d94c8 100644
--- a/src/gallium/state_trackers/va/image.c
+++ b/src/gallium/state_trackers/va/image.c
@@ -37,14 +37,21 @@
  
  #include "va_private.h"
  
-static const VAImageFormat formats[VL_VA_MAX_IMAGE_FORMATS] =

+static const VAImageFormat formats[] =
  {
 {VA_FOURCC('N','V','1','2')},
 {VA_FOURCC('I','4','2','0')},
 {VA_FOURCC('Y','V','1','2')},
 {VA_FOURCC('Y','U','Y','V')},
 {VA_FOURCC('U','Y','V','Y')},
-   {VA_FOURCC('B','G','R','A')}
+   {.fourcc = VA_FOURCC('B','G','R','A'), .byte_order = VA_LSB_FIRST, 32, 32,
+0x00ff, 0xff00, 0x00ff, 0xff00},
+   {.fourcc = VA_FOURCC('R','G','B','A'), .byte_order = VA_LSB_FIRST, 32, 32,
+0x00ff, 0xff00, 0x00ff, 0xff00},
+   {.fourcc = VA_FOURCC('B','G','R','X'), .byte_order = VA_LSB_FIRST, 32, 24,
+0x00ff, 0xff00, 0x00ff, 0x},
+   {.fourcc = VA_FOURCC('R','G','B','X'), .byte_order = VA_LSB_FIRST, 32, 24,
+0x00ff, 0xff00, 0x00ff, 0x}
  };
  
  static void

@@ -72,6 +79,8 @@ vlVaQueryImageFormats(VADriverContextP ctx, VAImageFormat 
*format_list, int *num
 enum pipe_format format;
 int i;
  
+   STATIC_ASSERT(ARRAY_SIZE(formats) == VL_VA_MAX_IMAGE_FORMATS);

+
 if (!ctx)
return VA_STATUS_ERROR_INVALID_CONTEXT;
  
@@ -80,7 +89,7 @@ vlVaQueryImageFormats(VADriverContextP ctx, VAImageFormat *format_list, int *num
  
 *num_formats = 0;

 pscreen = VL_VA_PSCREEN(ctx);
-   for (i = 0; i < VL_VA_MAX_IMAGE_FORMATS; ++i) {
+   for (i = 0; i < ARRAY_SIZE(formats); ++i) {
format = YCbCrToPipe(formats[i].fourcc);
if (pscreen->is_video_format_supported(pscreen, format,
PIPE_VIDEO_PROFILE_UNKNOWN,
@@ -149,6 +158,9 @@ vlVaCreateImage(VADriverContextP ctx, VAImageFormat 
*format, int width, int heig
break;
  
 case VA_FOURCC('B','G','R','A'):

+   case VA_FOURCC('R','G','B','A'):
+   case VA_FOURCC('B','G','R','X'):
+   case VA_FOURCC('R','G','B','X'):
img->num_planes = 1;
img->pitches[0] = w * 4;
img->offsets[0] = 0;
diff --git a/src/gallium/state_trackers/va/va_private.h 
b/src/gallium/state_trackers/va/va_private.h
index 93af1be..6a0bd41 100644
--- a/src/gallium/state_trackers/va/va_private.h
+++ b/src/gallium/state_trackers/va/va_private.h
@@ -46,12 +46,14 @@
  #define VL_VA_DRIVER(ctx) ((vlVaDriver *)ctx->pDriverData)
  #define VL_VA_PSCREEN(ctx) (VL_VA_DRIVER(ctx)->vscreen->pscreen)
  
-#define VL_VA_MAX_IMAGE_FORMATS 6

+#define VL_VA_MAX_IMAGE_FORMATS 9
  
  static inline enum pipe_video_chroma_format

  ChromaToPipe(int format)
  {
 switch (format) {
+   case VA_RT_FORMAT_YUV400:
+  return PIPE_VIDEO_CHROMA_FORMAT_400;
 case VA_RT_FORMAT_YUV420:
return PIPE_VIDEO_CHROMA_FORMAT_420;
 case VA_RT_FORMAT_YUV422:
@@ -80,12 +82,46 @@ YCbCrToPipe(unsigned format)
return PIPE_FORMAT_UYVY;
 case VA_FOURCC('B','G','R','A'):
return PIPE_FORMAT_B8G8R8A8_UNORM;
+   case VA_FOURCC('R','G','B','A'):
+  return PIPE_FORMAT_R8G8B8A8_UNORM;
+   case VA_FOURCC('B','G','R','X'):
+  return PIPE_FORMAT_B8G8R8X8_UNORM;
+   case VA_FOURCC('R','G','B','X'):
+  return PIPE_FORMAT_R8G8B8X8_UNORM;
 default:
assert(0);
return PIPE_FORMAT_NONE;
 }
  }
  
+static inline unsigned

+PipeToYCbCr(enum pipe_format p_format)
+{
+   switch (p_format) {
+   case PIPE_FORMAT_NV12:
+  return VA_FOURCC('N','V','1','2');
+   case PIPE_FORMAT_IYUV:
+  return VA_FOURCC('I','4','2','0');
+   case PIPE_FORMAT_YV12:
+  return VA_FOURCC('Y','V','1','2');
+   case PIPE_FORMAT_UYVY:
+  return VA_FOURCC('U','Y','V','Y');
+   case PIPE_FORMAT_YUYV:
+  return VA_FOURCC('Y','U','Y','V');
+   case PIPE_FORMAT_B8G8R8A8_UNORM:
+  return VA_FOURCC('B','G','R','A');
+   case PIPE_FORMAT_R8G8B8A8_UNORM:
+  return VA_FOURCC('R','G','B','A');
+   case PIPE_FORMAT_B8G8R8X8_UNORM:
+  return VA_FOURCC('B','G','R','X');
+   case PIPE_FORMAT_R8G8B8X8_UNORM:
+  return VA_FOURCC('R','G','B','X');
+   default:
+  assert(0);
+  return -1;
+   }
+}
+
  static inline VAProfile
  

Re: [Mesa-dev] [PATCH v4 2/9] st/va: do not destroy old buffer when new one failed

2015-10-29 Thread Christian König

On 29.10.2015 18:40, Julien Isorce wrote:

If formats are not the same vlVaPutImage re-creates the video
buffer with the right format. But if the creation of this new
video buffer fails then the surface looses its current buffer.
Let's just destroy the previous buffer on success.

Signed-off-by: Julien Isorce 


Reviewed-by: Christian König 

Should I push the patches already reviewed?

Regards,
Christian.


---
  src/gallium/state_trackers/va/image.c | 19 +--
  1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/src/gallium/state_trackers/va/image.c 
b/src/gallium/state_trackers/va/image.c
index 84d94c8..8e64673 100644
--- a/src/gallium/state_trackers/va/image.c
+++ b/src/gallium/state_trackers/va/image.c
@@ -346,13 +346,20 @@ vlVaPutImage(VADriverContextP ctx, VASurfaceID surface, 
VAImageID image,
 if (format == PIPE_FORMAT_NONE)
return VA_STATUS_ERROR_OPERATION_FAILED;
  
-   if (surf->buffer == NULL || format != surf->buffer->buffer_format) {

-  if (surf->buffer)
- surf->buffer->destroy(surf->buffer);
+   if (format != surf->buffer->buffer_format) {
+  struct pipe_video_buffer *tmp_buf;
+  enum pipe_format old_surf_format = surf->templat.buffer_format;
+
surf->templat.buffer_format = format;
-  surf->buffer = drv->pipe->create_video_buffer(drv->pipe, >templat);
-  if (!surf->buffer)
- return VA_STATUS_ERROR_ALLOCATION_FAILED;
+  tmp_buf = drv->pipe->create_video_buffer(drv->pipe, >templat);
+
+  if (!tmp_buf) {
+  surf->templat.buffer_format = old_surf_format;
+  return VA_STATUS_ERROR_ALLOCATION_FAILED;
+  }
+
+  surf->buffer->destroy(surf->buffer);
+  surf->buffer = tmp_buf;
 }
  
 views = surf->buffer->get_sampler_view_planes(surf->buffer);


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] Problems with accuracy of coeffs_init + attribs_update

2015-10-29 Thread Roland Scheidegger
Am 29.10.2015 um 20:10 schrieb Oded Gabbay:
> On Thu, Oct 29, 2015 at 9:02 PM, Ilia Mirkin  wrote:
>> On Thu, Oct 29, 2015 at 2:44 PM, Oded Gabbay  wrote:
>>> However, I would hate to keep the situation as is, meaning the test
>>> passes on x86-64 and fails on ppc64le.
>>
>> Sounds like it'd actually be a difference between AVX and SSE4.2 as
>> well -- what happens if you run on your x86_64 chip with
>> LP_NATIVE_VECTOR_WIDTH=128 ? It fails for me on my HSW chip, looking
>> at the results visually it's mostly good but there's a sprinkling of
>> red pixels.
>>
>>   -ilia
> 
> It fails on my Haswell chip - definitely sprinkling of red pixels.
> Also the error seems to be greater than 5e-7. Even with 1.6e-6 as
> failure point, it still fails, while on ppc64le it passes.
> Only when I went for 2e-6, the test passes.
> 
> As I said and Roland explained, the calculation method is inherently
> less accurate in the two-stages path. Although I don't know why on
> SSE4.2 the deviation is a bit larger than on VMX
> 

Does that have fma and does it auto-fuse mul/add to fma? Albeit I don't
think it should right now... Other than that, I'm not sure why the
results would be different - albeit on x86 we explicitly disable denorms
which could cause different results, for this example I don't think this
should be an issue.

Roland


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] i965: Invalid memory accesses after resizing brw_codegen's store table

2015-10-29 Thread Kristian Høgsberg
On Thu, Oct 29, 2015 at 12:32 AM, Iago Toral  wrote:
> On Wed, 2015-10-28 at 10:58 -0700, Kristian Høgsberg wrote:
>> On Wed, Oct 28, 2015 at 10:01:40AM +0100, Samuel Iglesias Gonsálvez wrote:
>> > There is no opinions about this issue or reviews of the proposed patch
>> > after one week.
>> >
>> > This is just a reminder in case you have missed it :-)
>>
>> Thanks for the reminder! How about something like this instead?
>
> Yeah, that works too. I was a bit concerned that this same problem may
> be affecting other places and this would only address it for
> brw_send_indirect_message, but after a quick review we don't generally
> need to hold pointers to previous instructions and the places where we
> do, like in brw_ENDIF or brw_WHILE we are careful to create the
> instructions we need before we look for pointers to others (which we do
> using indices into the store anyway).

Yea, it's not a general fix, but I'm not sure how we'd do that. In
your patch you were special casing the send instruction, which also
only covers some cases. What I had in mind when I wrote this
alternative fix was that: 1) it's a lot simpler and 2) it's local to
the cause of the problem and 3) doesn't suggest that you can safely
hold on to inst pointers (shows the opposite, in fact)

> Reviewed-by: Iago Toral Quiroga 
>
> I'll push this patch tomorrow if nobody else objects.

Thanks, good find.

> Thanks Kristian!
>
>> diff --git a/src/mesa/drivers/dri/i965/brw_eu_emit.c 
>> b/src/mesa/drivers/dri/i965/brw_eu_emit.c
>> index ebd811f..cd5c726 100644
>> --- a/src/mesa/drivers/dri/i965/brw_eu_emit.c
>> +++ b/src/mesa/drivers/dri/i965/brw_eu_emit.c
>> @@ -2511,12 +2511,20 @@ brw_send_indirect_message(struct brw_codegen *p,
>>struct brw_reg desc)
>>  {
>> const struct brw_device_info *devinfo = p->devinfo;
>> -   struct brw_inst *send, *setup;
>> +   struct brw_inst *send;
>> +   int setup;
>>
>> assert(desc.type == BRW_REGISTER_TYPE_UD);
>>
>> +   /* We hold on to the setup instruction (the SEND in the direct case, the 
>> OR
>> +* in the indirect case) by its index in the instruction store.  The
>> +* pointer returned by next_insn() may become invalid if emitting the 
>> SEND
>> +* in the indirect case reallocs the store.
>> +*/
>> +
>> if (desc.file == BRW_IMMEDIATE_VALUE) {
>> -  setup = send = next_insn(p, BRW_OPCODE_SEND);
>> +  setup = p->nr_insn;
>> +  send = next_insn(p, BRW_OPCODE_SEND);
>>brw_set_src1(p, send, desc);
>>
>> } else {
>> @@ -2531,7 +2539,8 @@ brw_send_indirect_message(struct brw_codegen *p,
>> * caller can specify additional descriptor bits with the usual
>> * brw_set_*_message() helper functions.
>> */
>> -  setup = brw_OR(p, addr, desc, brw_imm_ud(0));
>> +  setup = p->nr_insn;
>> +  brw_OR(p, addr, desc, brw_imm_ud(0));
>>
>>brw_pop_insn_state(p);
>>
>> @@ -2543,7 +2552,7 @@ brw_send_indirect_message(struct brw_codegen *p,
>> brw_set_src0(p, send, retype(payload, BRW_REGISTER_TYPE_UD));
>> brw_inst_set_sfid(devinfo, send, sfid);
>>
>> -   return setup;
>> +   return >store[setup];
>>  }
>>
>>  static struct brw_inst *
>>
>>
>> > Sam
>> >
>> > On 21/10/15 12:23, Iago Toral wrote:
>> > > Hi,
>> > >
>> > > The problem is with code like this (see brw_send_indirect_message):
>> > >
>> > > setup = brw_OR(p, addr, desc, brw_imm_ud(0));
>> > > send = next_insn(p, BRW_OPCODE_SEND);
>> > > ...
>> > > return setup;
>> > >
>> > > If next_insn triggers a realloc of the instruction store, then the setup
>> > > instruction pointer is no longer valid. Notice that this can happen
>> > > anywhere where we keep pointers to previous instructions before creating
>> > > new ones (!)
>> > >
>> > > The patch from Samuel fixes this by special-casing this for SEND
>> > > instructions only (since we know that the indirect versions can hit
>> > > this, maybe there are more situations though). It does so by trying to
>> > > make sure that we never realloc the store with a SEND instruction. For
>> > > this, we realloc before we reach the end of the current store (32
>> > > instructions before the limit) as long as the instruction is not a SEND
>> > > (so that if it is a SEND we still have up to 32 opportunities to do the
>> > > realloc without a different instruction before running out of space in
>> > > the store).
>> > >
>> > > Iago
>> > >
>> > > On Wed, 2015-10-21 at 09:02 +0200, Samuel Iglesias Gonsalvez wrote:
>> > >> Hello,
>> > >>
>> > >> I have found several invalid memory accesses when running
>> > >> dEQP-GLES31.functional.ssbo.* tests on i965 driver (and gen7+). That
>> > >> invalid memory accesses were unluckily happening when generating the
>> > >> assembly instructions for SSBO stores for different compute shaders.
>> > >>
>> > >> However it looks like this problem could happen to other shaders and
>> > >> situations. Because of that, I am going to explain 

Re: [Mesa-dev] Problems with accuracy of coeffs_init + attribs_update

2015-10-29 Thread Roland Scheidegger
Am 29.10.2015 um 19:44 schrieb Oded Gabbay:
> On Thu, Oct 29, 2015 at 5:31 PM, Roland Scheidegger  
> wrote:
>> Am 29.10.2015 um 12:27 schrieb Oded Gabbay:
>>> Hi Roland, Jose
>>>
>>> I wanted to bring a problem I found to your attention, and discuss
>>> about it and ways to solve it.
>>>
>>> I'm working on regressions of piglit gpu.py between x86-64 and
>>> ppc64le, when running with llvmpipe.
>>>
>>> One of the regressions manifests itself in 2 tests,
>>> clip-distance-bulk-copy and clip-distance-itemized-copy
>> There's actually a third one, interface-vs-unnamed-to-fs-unnamed, which
>> fails the same (and it's easier to debug...).
>>
> Yes, you are correct of course. It was also fixed by my change.
> 
>>
>>>
>>> What happens in ppc64le is that *some* of the interpolated per-vertex
>>> values (clip-distance values) that constitute the input into the
>>> fragment shader, are not calculated according to the required accuracy
>>> of the test (which is an error/distance of less than 1e-6)
>>>
>>> It took a while, but I believe I found the reason. In general, when
>>> running on ppc64le, the code path that is taken at
>>> lp_build_interp_soa_init() is doing  bld->simple_interp = FALSE, which
>>> means using coeffs_init() + attribs_update(). That's in contrast with
>>> x86-64, where bld->simple_interp = TRUE, which means the code will use
>>> coeffs_init_simple() + attribs_update_simple()
>> Note this isn't really about x86-64 per se. If you don't have AVX on a
>> x86-64 box, the other path will be taken too (and the test fail as well).
>>
> makes sense.
> 
>>>
>>> In specific, the problem lies in how the coeffs are calculated inside
>>> coeffs_init. To simply put it, they are only *actually* calculated
>>> correctly for the first quad. The coeffs are later *updated* for the
>>> other quads, using dadx/dady and dadq.
>>>
>>> --
>>> side-note:
>>> I believe you even documented it in coeffs_init():
>>>   /*
>>>* a = a0 + (x * dadx + y * dady)
>>>* a0aos is the attrib value at top left corner of stamp
>>>*/
>>> --
>>>
>>> The root cause for that, I believe, is because coeffs_init does *not*
>>> take into account the different x/y offsets for the other quads. In
>>> contrast, on x86-64, the code uses a function called calc_offset(),
>>> which does take the different x/y offsets into account.
>>>
>>> Please look at this definition (from lp_bld_interp.c) :
>>>
>>> static const unsigned char quad_offset_x[16] = {0, 1, 0, 1, 2, 3, 2,
>>> 3, 0, 1, 0, 1, 2, 3, 2, 3};
>>> static const unsigned char quad_offset_y[16] = {0, 0, 1, 1, 0, 0, 1,
>>> 1, 2, 2, 3, 3, 2, 2, 3, 3};
>>>
>>> Now, look at how coeffs_init() uses them:
>>>
>>>for (i = 0; i < coeff_bld->type.length; i++) {
>>>   LLVMValueRef nr = lp_build_const_int32(gallivm, i);
>>>   LLVMValueRef pixxf = lp_build_const_float(gallivm, quad_offset_x[i]);
>>>   LLVMValueRef pixyf = lp_build_const_float(gallivm, quad_offset_y[i]);
>>>   pixoffx = LLVMBuildInsertElement(builder, pixoffx, pixxf, nr, "");
>>>   pixoffy = LLVMBuildInsertElement(builder, pixoffy, pixyf, nr, "");
>>>}
>>>
>>> So, in ppc64le, where coeff_bld->type.length == 4, we *always* take
>>> the first four values from the above arrays. The code *never*
>>> calculates the coeffs based on the other offsets.
>>>
>>> Admittedly, that's *almost* always works and I doubt you will see a
>>> difference in display. However, in the tests I mentioned above, it
>>> creates, for some pixels, a bigger error than what is allowed.
>> Well, I'm not sure what error actually is allowed... GL of course is
>> vague (the test just seems to be built so the error allowed actually
>> passes on real hw).
>>
>> I don't think there's an actual bug with the code. What it does in
>> coeffs_init, is simply calculate the dadx + dady values from one pixel
>> to the next (within a quad).
>> Then, in attrib_update, it simply uses these values (which are constant
>> for all quads, as the position of the pixels within a quad doesn't
>> change) to calculate the actual dadq value based on the actual pixel
>> offsets, and add that to the (also done in coeffs_init) starting value
>> of each quad.
>>
>> So, the code is correct. However, it still gives different results
>> compared to the other method, and the reason is just float math. This
>> method does two interpolations (one for the start of the quad, the other
>> per pixel), whereas the other method does just one. And this is why the
>> results are different, because the results just aren't exact.
>>
> Yeah, I agree. I also wouldn't say it is a bug per-se, but it is a
> method of calculation that produces less accurate results then the
> other method (the simple path).
> 
>>
>>>
>>> The first thing that came into my mind was to change, in
>>> lp_build_interp_soa_init():
>>>
>>> "if (coeff_type.length > 4)"
>>> to this:
>>> "if (coeff_type.length >= 4)"
>>>
>>> When I did that, I saw it fixes the above tests 

Re: [Mesa-dev] Problems with accuracy of coeffs_init + attribs_update

2015-10-29 Thread Roland Scheidegger
Am 29.10.2015 um 20:33 schrieb Oded Gabbay:
> On Thu, Oct 29, 2015 at 9:25 PM, Roland Scheidegger  
> wrote:
>> Am 29.10.2015 um 20:10 schrieb Oded Gabbay:
>>> On Thu, Oct 29, 2015 at 9:02 PM, Ilia Mirkin  wrote:
 On Thu, Oct 29, 2015 at 2:44 PM, Oded Gabbay  wrote:
> However, I would hate to keep the situation as is, meaning the test
> passes on x86-64 and fails on ppc64le.

 Sounds like it'd actually be a difference between AVX and SSE4.2 as
 well -- what happens if you run on your x86_64 chip with
 LP_NATIVE_VECTOR_WIDTH=128 ? It fails for me on my HSW chip, looking
 at the results visually it's mostly good but there's a sprinkling of
 red pixels.

   -ilia
>>>
>>> It fails on my Haswell chip - definitely sprinkling of red pixels.
>>> Also the error seems to be greater than 5e-7. Even with 1.6e-6 as
>>> failure point, it still fails, while on ppc64le it passes.
>>> Only when I went for 2e-6, the test passes.
>>>
>>> As I said and Roland explained, the calculation method is inherently
>>> less accurate in the two-stages path. Although I don't know why on
>>> SSE4.2 the deviation is a bit larger than on VMX
>>>
>>
>> Does that have fma and does it auto-fuse mul/add to fma? Albeit I don't
>> think it should right now... Other than that, I'm not sure why the
>> results would be different - albeit on x86 we explicitly disable denorms
>> which could cause different results, for this example I don't think this
>> should be an issue.
>>
>> Roland
>>
>>
> 
> You asked about ppc64le ?
> If so, It does have fma instructions in its ISA, both for floating
> point and for vector. However, if I look in the LLVM IR, I don't see
> any fma intrinsic and if I look at the disassemble, I don't see any
> instructions of multiply-and-add.
> 
> So in theory it exists but it isn't used in the tests I mentioned.
Ok that's as expected then. It just isn't always very obvious if
auto-fusing is allowed or not (unsafe math of course always allows
this). Maybe there's some more differences in the fpu environments I
can't remember...

Roland


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] Problems with accuracy of coeffs_init + attribs_update

2015-10-29 Thread Ilia Mirkin
On Thu, Oct 29, 2015 at 2:44 PM, Oded Gabbay  wrote:
> However, I would hate to keep the situation as is, meaning the test
> passes on x86-64 and fails on ppc64le.

Sounds like it'd actually be a difference between AVX and SSE4.2 as
well -- what happens if you run on your x86_64 chip with
LP_NATIVE_VECTOR_WIDTH=128 ? It fails for me on my HSW chip, looking
at the results visually it's mostly good but there's a sprinkling of
red pixels.

  -ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v4 3/9] st/va: implement VaCreateSurfaces2 and VaQuerySurfaceAttributes

2015-10-29 Thread Emil Velikov
On 29 October 2015 at 17:40, Julien Isorce  wrote:
> +
> +VAStatus
> +vlVaCreateSurfaces2(VADriverContextP ctx, unsigned int format,
> +unsigned int width, unsigned int height,
> +VASurfaceID *surfaces, unsigned int num_surfaces,
> +VASurfaceAttrib *attrib_list, unsigned int num_attribs)
> +{
[snip]
> +if (VA_RT_FORMAT_YUV400 != format &&
Please drop this format.

> +VA_RT_FORMAT_YUV420 != format &&
> +VA_RT_FORMAT_YUV422 != format &&
> +VA_RT_FORMAT_YUV444 != format &&
> +VA_RT_FORMAT_RGB32  != format) {
Whereas RGB32, if it works, is by sheer luck. Because ...

[snip]
> +
> +memset(, 0, sizeof(templat));
> +
[snip]
> +if (format != VA_RT_FORMAT_RGB32)
> +   templat.chroma_format = ChromaToPipe(format);
> +
chroma_format defaults to 0 (thanks to memset above) which likely maps
to PIPE_VIDEO_CHROMA_FORMAT_400 from the pipe_video_chroma_format
enum. With most drivers (incl the 'software implementation' in aux/vl)
only handle 420/422/444.

[snip]
> +no_res:
> +   for (i = 0; i < num_surfaces; i++) {
> +  if (surfaces[i] != VA_INVALID_ID)
Should have caught this one sooner - this looks odd for couple of reasons.
 - vlVaDestroySurfaces removes a total of i surfaces. Thus we don't
need a loop here.
 - handle_table_add() returns 0 on error and 0x
(VA_INVALID_ID) is a valid handle.

-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] Problems with accuracy of coeffs_init + attribs_update

2015-10-29 Thread Oded Gabbay
On Thu, Oct 29, 2015 at 9:02 PM, Ilia Mirkin  wrote:
> On Thu, Oct 29, 2015 at 2:44 PM, Oded Gabbay  wrote:
>> However, I would hate to keep the situation as is, meaning the test
>> passes on x86-64 and fails on ppc64le.
>
> Sounds like it'd actually be a difference between AVX and SSE4.2 as
> well -- what happens if you run on your x86_64 chip with
> LP_NATIVE_VECTOR_WIDTH=128 ? It fails for me on my HSW chip, looking
> at the results visually it's mostly good but there's a sprinkling of
> red pixels.
>
>   -ilia

It fails on my Haswell chip - definitely sprinkling of red pixels.
Also the error seems to be greater than 5e-7. Even with 1.6e-6 as
failure point, it still fails, while on ppc64le it passes.
Only when I went for 2e-6, the test passes.

As I said and Roland explained, the calculation method is inherently
less accurate in the two-stages path. Although I don't know why on
SSE4.2 the deviation is a bit larger than on VMX

 Oded
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v4 5/9] st/va: handle Video Post Processing for configs

2015-10-29 Thread Christian König

On 29.10.2015 18:40, Julien Isorce wrote:

Add support for VA_PROFILE_NONE and VAEntrypointVideoProc
in the 4 following functions:

vlVaQueryConfigProfiles
vlVaQueryConfigEntrypoints
vlVaCreateConfig
vlVaQueryConfigAttributes

Signed-off-by: Julien Isorce 


Reviewed-by: Christian König 

But you should reorder the patch, e.g. commit patch #6 first and then 
patch #5. Otherwise we have a state where the state tracker claims to 
support post processing but doesn't.


Christian.


---
  src/gallium/state_trackers/va/config.c | 20 
  src/gallium/state_trackers/va/va_private.h |  7 +--
  2 files changed, 25 insertions(+), 2 deletions(-)

diff --git a/src/gallium/state_trackers/va/config.c 
b/src/gallium/state_trackers/va/config.c
index 5030f9e..0f47aac 100644
--- a/src/gallium/state_trackers/va/config.c
+++ b/src/gallium/state_trackers/va/config.c
@@ -52,6 +52,9 @@ vlVaQueryConfigProfiles(VADriverContextP ctx, VAProfile 
*profile_list, int *num_
  profile_list[(*num_profiles)++] = vap;
}
  
+   /* Support postprocessing through vl_compositor */

+   profile_list[(*num_profiles)++] = VAProfileNone;
+
 return VA_STATUS_SUCCESS;
  }
  
@@ -67,6 +70,11 @@ vlVaQueryConfigEntrypoints(VADriverContextP ctx, VAProfile profile,
  
 *num_entrypoints = 0;
  
+   if (profile == VAProfileNone) {

+   entrypoint_list[(*num_entrypoints)++] = VAEntrypointVideoProc;
+   return VA_STATUS_SUCCESS;
+   }
+
 p = ProfileToPipe(profile);
 if (p == PIPE_VIDEO_PROFILE_UNKNOWN)
return VA_STATUS_ERROR_UNSUPPORTED_PROFILE;
@@ -118,6 +126,11 @@ vlVaCreateConfig(VADriverContextP ctx, VAProfile profile, 
VAEntrypoint entrypoin
 if (!ctx)
return VA_STATUS_ERROR_INVALID_CONTEXT;
  
+   if (profile == VAProfileNone && entrypoint == VAEntrypointVideoProc) {

+   *config_id = PIPE_VIDEO_PROFILE_UNKNOWN;
+   return VA_STATUS_SUCCESS;
+   }
+
 p = ProfileToPipe(profile);
 if (p == PIPE_VIDEO_PROFILE_UNKNOWN)
return VA_STATUS_ERROR_UNSUPPORTED_PROFILE;
@@ -151,6 +164,13 @@ vlVaQueryConfigAttributes(VADriverContextP ctx, VAConfigID 
config_id, VAProfile
return VA_STATUS_ERROR_INVALID_CONTEXT;
  
 *profile = PipeToProfile(config_id);

+
+   if (config_id == PIPE_VIDEO_PROFILE_UNKNOWN) {
+  *entrypoint = VAEntrypointVideoProc;
+   *num_attribs = 0;
+  return VA_STATUS_SUCCESS;
+   }
+
 *entrypoint = VAEntrypointVLD;
  
 *num_attribs = 1;

diff --git a/src/gallium/state_trackers/va/va_private.h 
b/src/gallium/state_trackers/va/va_private.h
index 68cb703..3a02e58 100644
--- a/src/gallium/state_trackers/va/va_private.h
+++ b/src/gallium/state_trackers/va/va_private.h
@@ -146,10 +146,11 @@ PipeToProfile(enum pipe_video_profile profile)
return VAProfileH264Main;
 case PIPE_VIDEO_PROFILE_MPEG4_AVC_HIGH:
return VAProfileH264High;
-   case PIPE_VIDEO_PROFILE_MPEG4_AVC_EXTENDED:
-   return VAProfileNone;
 case PIPE_VIDEO_PROFILE_HEVC_MAIN:
return VAProfileHEVCMain;
+   case PIPE_VIDEO_PROFILE_MPEG4_AVC_EXTENDED:
+   case PIPE_VIDEO_PROFILE_UNKNOWN:
+  return VAProfileNone;
 default:
assert(0);
return -1;
@@ -182,6 +183,8 @@ ProfileToPipe(VAProfile profile)
return PIPE_VIDEO_PROFILE_MPEG4_AVC_HIGH;
 case VAProfileHEVCMain:
return PIPE_VIDEO_PROFILE_HEVC_MAIN;
+   case VAProfileNone:
+   return PIPE_VIDEO_PROFILE_UNKNOWN;
 default:
return PIPE_VIDEO_PROFILE_UNKNOWN;
 }


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] Problems with accuracy of coeffs_init + attribs_update

2015-10-29 Thread Oded Gabbay
On Thu, Oct 29, 2015 at 5:31 PM, Roland Scheidegger  wrote:
> Am 29.10.2015 um 12:27 schrieb Oded Gabbay:
>> Hi Roland, Jose
>>
>> I wanted to bring a problem I found to your attention, and discuss
>> about it and ways to solve it.
>>
>> I'm working on regressions of piglit gpu.py between x86-64 and
>> ppc64le, when running with llvmpipe.
>>
>> One of the regressions manifests itself in 2 tests,
>> clip-distance-bulk-copy and clip-distance-itemized-copy
> There's actually a third one, interface-vs-unnamed-to-fs-unnamed, which
> fails the same (and it's easier to debug...).
>
Yes, you are correct of course. It was also fixed by my change.

>
>>
>> What happens in ppc64le is that *some* of the interpolated per-vertex
>> values (clip-distance values) that constitute the input into the
>> fragment shader, are not calculated according to the required accuracy
>> of the test (which is an error/distance of less than 1e-6)
>>
>> It took a while, but I believe I found the reason. In general, when
>> running on ppc64le, the code path that is taken at
>> lp_build_interp_soa_init() is doing  bld->simple_interp = FALSE, which
>> means using coeffs_init() + attribs_update(). That's in contrast with
>> x86-64, where bld->simple_interp = TRUE, which means the code will use
>> coeffs_init_simple() + attribs_update_simple()
> Note this isn't really about x86-64 per se. If you don't have AVX on a
> x86-64 box, the other path will be taken too (and the test fail as well).
>
makes sense.

>>
>> In specific, the problem lies in how the coeffs are calculated inside
>> coeffs_init. To simply put it, they are only *actually* calculated
>> correctly for the first quad. The coeffs are later *updated* for the
>> other quads, using dadx/dady and dadq.
>>
>> --
>> side-note:
>> I believe you even documented it in coeffs_init():
>>   /*
>>* a = a0 + (x * dadx + y * dady)
>>* a0aos is the attrib value at top left corner of stamp
>>*/
>> --
>>
>> The root cause for that, I believe, is because coeffs_init does *not*
>> take into account the different x/y offsets for the other quads. In
>> contrast, on x86-64, the code uses a function called calc_offset(),
>> which does take the different x/y offsets into account.
>>
>> Please look at this definition (from lp_bld_interp.c) :
>>
>> static const unsigned char quad_offset_x[16] = {0, 1, 0, 1, 2, 3, 2,
>> 3, 0, 1, 0, 1, 2, 3, 2, 3};
>> static const unsigned char quad_offset_y[16] = {0, 0, 1, 1, 0, 0, 1,
>> 1, 2, 2, 3, 3, 2, 2, 3, 3};
>>
>> Now, look at how coeffs_init() uses them:
>>
>>for (i = 0; i < coeff_bld->type.length; i++) {
>>   LLVMValueRef nr = lp_build_const_int32(gallivm, i);
>>   LLVMValueRef pixxf = lp_build_const_float(gallivm, quad_offset_x[i]);
>>   LLVMValueRef pixyf = lp_build_const_float(gallivm, quad_offset_y[i]);
>>   pixoffx = LLVMBuildInsertElement(builder, pixoffx, pixxf, nr, "");
>>   pixoffy = LLVMBuildInsertElement(builder, pixoffy, pixyf, nr, "");
>>}
>>
>> So, in ppc64le, where coeff_bld->type.length == 4, we *always* take
>> the first four values from the above arrays. The code *never*
>> calculates the coeffs based on the other offsets.
>>
>> Admittedly, that's *almost* always works and I doubt you will see a
>> difference in display. However, in the tests I mentioned above, it
>> creates, for some pixels, a bigger error than what is allowed.
> Well, I'm not sure what error actually is allowed... GL of course is
> vague (the test just seems to be built so the error allowed actually
> passes on real hw).
>
> I don't think there's an actual bug with the code. What it does in
> coeffs_init, is simply calculate the dadx + dady values from one pixel
> to the next (within a quad).
> Then, in attrib_update, it simply uses these values (which are constant
> for all quads, as the position of the pixels within a quad doesn't
> change) to calculate the actual dadq value based on the actual pixel
> offsets, and add that to the (also done in coeffs_init) starting value
> of each quad.
>
> So, the code is correct. However, it still gives different results
> compared to the other method, and the reason is just float math. This
> method does two interpolations (one for the start of the quad, the other
> per pixel), whereas the other method does just one. And this is why the
> results are different, because the results just aren't exact.
>
Yeah, I agree. I also wouldn't say it is a bug per-se, but it is a
method of calculation that produces less accurate results then the
other method (the simple path).

>
>>
>> The first thing that came into my mind was to change, in
>> lp_build_interp_soa_init():
>>
>> "if (coeff_type.length > 4)"
>> to this:
>> "if (coeff_type.length >= 4)"
>>
>> When I did that, I saw it fixes the above tests and didn't cause any
>> regressions on ppc64le and/or on x86-64.
>>
>> However, I wanted to ask you guys if you remember why you allowed only
>> vectors with size above 4 

Re: [Mesa-dev] [PATCH v4 4/9] st/va: implement dmabuf import for VaCreateSurfaces2

2015-10-29 Thread Christian König

On 29.10.2015 18:40, Julien Isorce wrote:

For now it is limited to RGBA, BGRA, RGBX, BGRX surfaces.

Signed-off-by: Julien Isorce 
---
  src/gallium/state_trackers/va/surface.c | 97 -
  1 file changed, 96 insertions(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/va/surface.c 
b/src/gallium/state_trackers/va/surface.c
index c3c015e..c1f7182 100644
--- a/src/gallium/state_trackers/va/surface.c
+++ b/src/gallium/state_trackers/va/surface.c
@@ -29,6 +29,8 @@
  #include "pipe/p_screen.h"
  #include "pipe/p_video_codec.h"
  
+#include "state_tracker/drm_driver.h"

+
  #include "util/u_memory.h"
  #include "util/u_handle_table.h"
  #include "util/u_rect.h"
@@ -41,6 +43,8 @@
  
  #include "va_private.h"
  
+#include 

+
  VAStatus
  vlVaCreateSurfaces(VADriverContextP ctx, int width, int height, int format,
 int num_surfaces, VASurfaceID *surfaces)
@@ -368,7 +372,8 @@ vlVaQuerySurfaceAttributes(VADriverContextP ctx, VAConfigID 
config,
  attribs[i].type = VASurfaceAttribMemoryType;
  attribs[i].value.type = VAGenericValueTypeInteger;
  attribs[i].flags = VA_SURFACE_ATTRIB_GETTABLE | 
VA_SURFACE_ATTRIB_SETTABLE;
-attribs[i].value.value.i = VA_SURFACE_ATTRIB_MEM_TYPE_VA;
+attribs[i].value.value.i = VA_SURFACE_ATTRIB_MEM_TYPE_VA |
+VA_SURFACE_ATTRIB_MEM_TYPE_DRM_PRIME;
  i++;
  
  attribs[i].type = VASurfaceAttribExternalBufferDescriptor;

@@ -402,6 +407,83 @@ vlVaQuerySurfaceAttributes(VADriverContextP ctx, 
VAConfigID config,
  return VA_STATUS_SUCCESS;
  }
  
+static VAStatus

+suface_from_external_memory(VADriverContextP ctx, vlVaSurface *surface,
+VASurfaceAttribExternalBuffers *memory_attibute,
+int index, VASurfaceID *surfaces,
+struct pipe_video_buffer *templat)
+{
+vlVaDriver *drv;
+struct pipe_screen *pscreen;
+struct pipe_resource *resource;
+struct pipe_resource res_templ;
+struct winsys_handle whandle;
+struct pipe_resource *resources[VL_NUM_COMPONENTS];
+
+if (!ctx)
+return VA_STATUS_ERROR_INVALID_PARAMETER;
+
+pscreen = VL_VA_PSCREEN(ctx);
+drv = VL_VA_DRIVER(ctx);
+
+if (!memory_attibute || !memory_attibute->buffers ||
+index > memory_attibute->num_buffers)
+return VA_STATUS_ERROR_INVALID_PARAMETER;
+
+if (surface->templat.width != memory_attibute->width ||
+surface->templat.height != memory_attibute->height ||
+memory_attibute->num_planes < 1)
+return VA_STATUS_ERROR_INVALID_PARAMETER;
+
+switch (memory_attibute->pixel_format) {
+case VA_FOURCC_RGBA:
+case VA_FOURCC_RGBX:
+case VA_FOURCC_BGRA:
+case VA_FOURCC_BGRX:
+if (memory_attibute->num_planes != 1)
+return VA_STATUS_ERROR_INVALID_PARAMETER;
+break;
+default:
+return VA_STATUS_ERROR_INVALID_PARAMETER;
+}
+
+memset(_templ, 0, sizeof(res_templ));
+res_templ.target = PIPE_TEXTURE_2D;
+res_templ.last_level = 0;
+res_templ.depth0 = 1;
+res_templ.array_size = 1;
+res_templ.width0 = memory_attibute->width;
+res_templ.height0 = memory_attibute->height;
+res_templ.format = surface->templat.buffer_format;
+res_templ.bind = PIPE_BIND_SAMPLER_VIEW;
+res_templ.usage = PIPE_USAGE_DEFAULT;
+
+memset(, 0, sizeof(struct winsys_handle));
+whandle.type = DRM_API_HANDLE_TYPE_FD;
+whandle.handle = memory_attibute->buffers[index];
+whandle.stride = memory_attibute->pitches[index];
+
+resource = pscreen->resource_from_handle(pscreen, _templ, );
+
+if (!resource)
+   return VA_STATUS_ERROR_ALLOCATION_FAILED;
+
+memset(resources, 0, sizeof resources);
+resources[0] = resource;
+
+surface->buffer = vl_video_buffer_create_ex2(drv->pipe, templat, 
resources);


That's a bit tricky. At least the memory layout UVD uses isn't shareable 
using DMA-buf.


So after importing this buffer you can't use it as a decoding target for 
video decoding.


So you should probably have a flag or something that video buffers 
created like this can't be used for decoding frames.


Regards,
Christian.


+if (!surface->buffer)
+return VA_STATUS_ERROR_ALLOCATION_FAILED;
+
+util_dynarray_init(>subpics);
+surfaces[index] = handle_table_add(drv->htab, surface);
+
+if (!surfaces[index])
+  return VA_STATUS_ERROR_ALLOCATION_FAILED;
+
+return VA_STATUS_SUCCESS;
+}
+
  VAStatus
  vlVaCreateSurfaces2(VADriverContextP ctx, unsigned int format,
  unsigned int width, unsigned int height,
@@ -415,6 +497,7 @@ vlVaCreateSurfaces2(VADriverContextP ctx, unsigned int 
format,
  int i;
  int memory_type;
  int expected_fourcc;
+VAStatus vaStatus;
  
  if (!ctx)

 return VA_STATUS_ERROR_INVALID_CONTEXT;
@@ -453,6 +536,7 @@ vlVaCreateSurfaces2(VADriverContextP ctx, unsigned int 
format,
  

Re: [Mesa-dev] Problems with accuracy of coeffs_init + attribs_update

2015-10-29 Thread Oded Gabbay
On Thu, Oct 29, 2015 at 9:25 PM, Roland Scheidegger  wrote:
> Am 29.10.2015 um 20:10 schrieb Oded Gabbay:
>> On Thu, Oct 29, 2015 at 9:02 PM, Ilia Mirkin  wrote:
>>> On Thu, Oct 29, 2015 at 2:44 PM, Oded Gabbay  wrote:
 However, I would hate to keep the situation as is, meaning the test
 passes on x86-64 and fails on ppc64le.
>>>
>>> Sounds like it'd actually be a difference between AVX and SSE4.2 as
>>> well -- what happens if you run on your x86_64 chip with
>>> LP_NATIVE_VECTOR_WIDTH=128 ? It fails for me on my HSW chip, looking
>>> at the results visually it's mostly good but there's a sprinkling of
>>> red pixels.
>>>
>>>   -ilia
>>
>> It fails on my Haswell chip - definitely sprinkling of red pixels.
>> Also the error seems to be greater than 5e-7. Even with 1.6e-6 as
>> failure point, it still fails, while on ppc64le it passes.
>> Only when I went for 2e-6, the test passes.
>>
>> As I said and Roland explained, the calculation method is inherently
>> less accurate in the two-stages path. Although I don't know why on
>> SSE4.2 the deviation is a bit larger than on VMX
>>
>
> Does that have fma and does it auto-fuse mul/add to fma? Albeit I don't
> think it should right now... Other than that, I'm not sure why the
> results would be different - albeit on x86 we explicitly disable denorms
> which could cause different results, for this example I don't think this
> should be an issue.
>
> Roland
>
>

You asked about ppc64le ?
If so, It does have fma instructions in its ISA, both for floating
point and for vector. However, if I look in the LLVM IR, I don't see
any fma intrinsic and if I look at the disassemble, I don't see any
instructions of multiply-and-add.

So in theory it exists but it isn't used in the tests I mentioned.

 Oded
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v4 2/9] st/va: do not destroy old buffer when new one failed

2015-10-29 Thread Julien Isorce
Yes please. Thx
Julien

On 29 October 2015 at 19:12, Christian König 
wrote:

> On 29.10.2015 18:40, Julien Isorce wrote:
>
>> If formats are not the same vlVaPutImage re-creates the video
>> buffer with the right format. But if the creation of this new
>> video buffer fails then the surface looses its current buffer.
>> Let's just destroy the previous buffer on success.
>>
>> Signed-off-by: Julien Isorce 
>>
>
> Reviewed-by: Christian König 
>
> Should I push the patches already reviewed?
>
> Regards,
> Christian.
>
>
> ---
>>   src/gallium/state_trackers/va/image.c | 19 +--
>>   1 file changed, 13 insertions(+), 6 deletions(-)
>>
>> diff --git a/src/gallium/state_trackers/va/image.c
>> b/src/gallium/state_trackers/va/image.c
>> index 84d94c8..8e64673 100644
>> --- a/src/gallium/state_trackers/va/image.c
>> +++ b/src/gallium/state_trackers/va/image.c
>> @@ -346,13 +346,20 @@ vlVaPutImage(VADriverContextP ctx, VASurfaceID
>> surface, VAImageID image,
>>  if (format == PIPE_FORMAT_NONE)
>> return VA_STATUS_ERROR_OPERATION_FAILED;
>>   -   if (surf->buffer == NULL || format != surf->buffer->buffer_format) {
>> -  if (surf->buffer)
>> - surf->buffer->destroy(surf->buffer);
>> +   if (format != surf->buffer->buffer_format) {
>> +  struct pipe_video_buffer *tmp_buf;
>> +  enum pipe_format old_surf_format = surf->templat.buffer_format;
>> +
>> surf->templat.buffer_format = format;
>> -  surf->buffer = drv->pipe->create_video_buffer(drv->pipe,
>> >templat);
>> -  if (!surf->buffer)
>> - return VA_STATUS_ERROR_ALLOCATION_FAILED;
>> +  tmp_buf = drv->pipe->create_video_buffer(drv->pipe,
>> >templat);
>> +
>> +  if (!tmp_buf) {
>> +  surf->templat.buffer_format = old_surf_format;
>> +  return VA_STATUS_ERROR_ALLOCATION_FAILED;
>> +  }
>> +
>> +  surf->buffer->destroy(surf->buffer);
>> +  surf->buffer = tmp_buf;
>>  }
>>views = surf->buffer->get_sampler_view_planes(surf->buffer);
>>
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v2] st/mesa: fix mipmap generation for immutable textures with incomplete pyramids

2015-10-29 Thread Nicolai Hähnle

On 29.10.2015 14:13, Marek Olšák wrote:

On Wed, Oct 28, 2015 at 1:00 PM, Nicolai Hähnle  wrote:

Without the clamping by NumLevels, the state tracker would reallocate the
texture storage (incorrect) and even fail to copy the base level image
after reallocation, leading to the graphical glitch of
https://bugs.freedesktop.org/show_bug.cgi?id=91993 .

A piglit test has been submitted for review as well (subtest of
arb_texture_storage-texture-storage).

v2: also bypass all calls to st_finalize_texture (suggested by Marek Olšák)

Cc: mesa-sta...@lists.freedesktop.org
Reviewed-by: Marek Olšák 


This looks good.

(a minor nit: an updated patch should not contain any reviewed-by
tags, because the updated version hadn't been seen by anybody at the
time of sending it to the list; it's okay to keep the tag now that
I've reviewed it)


Sorry about that, I'll be more careful about that in the future.

Nicolai



Marek



___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 00/15] virgl: misc cleanups and bikeshedding

2015-10-29 Thread Dave Airlie
On 29 October 2015 at 21:12, Emil Velikov  wrote:
> On 29 October 2015 at 11:12, Emil Velikov  wrote:
>> Hi all,
>>
>> A slightly longer series (that builds on top of the previous sent a
>> minute ago), that moves/renames a couple of files, adds a few inline
>> wrappers, 'includes what you want' and related fixes.
>>
>> As some of these can be seen as bikeshedding, although rest assured
>> there is a method to the madness, I think.

While I do consider some of it bikesheddy in nature, I can't argue
against any of it,

All these look good to me, and the other 6 as well.

Reviewed-by: Dave Airlie 

for all of them.

Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] nouveau: fix double free when screen_create fails

2015-10-29 Thread Samuel Pitoiset



On 10/27/2015 02:01 PM, samuel.pitoiset wrote:



On 27/10/2015 12:52, Emil Velikov wrote:
On 27 October 2015 at 10:50, samuel.pitoiset 
 wrote:

On 27/10/2015 11:37, Emil Velikov wrote:

On 22 October 2015 at 00:16, Julien Isorce 
wrote:

The real fix is in nouveau_drm_winsys.c by setting dev to 0.
Which means dev's ownership has been passed to previous call.
Other changes are there to be consistent with what the
screen_create functions already do on errors.

Encountered this crash because nvc0_screen_create sometimes fails 
with:
nvc0_screen_create:717 - Error allocating PGRAPH context for M2MF: 
-16

Also see: https://bugs.freedesktop.org/show_bug.cgi?id=70354

Signed-off-by: Julien Isorce 
---
   src/gallium/drivers/nouveau/nv30/nv30_screen.c  | 5 -
   src/gallium/drivers/nouveau/nv50/nv50_screen.c  | 4 +++-
   src/gallium/winsys/nouveau/drm/nouveau_drm_winsys.c | 2 ++
   3 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nv30/nv30_screen.c
b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
index 0330164..9b8ddac 100644
--- a/src/gallium/drivers/nouveau/nv30/nv30_screen.c
+++ b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
@@ -425,8 +425,10 @@ nv30_screen_create(struct nouveau_device *dev)
  unsigned oclass = 0;
  int ret, i;

-   if (!screen)
+   if (!screen) {
+  nouveau_device_del();
 return NULL;
+   }


Imho having these in screen_create() seems like the wrong 'layer'.
Shouldn't one call nouveau_device_dev() from within
nouveau_drm_screen_unref
   and explicitly call the latter if the calloc() (here and in 
nv50/nvc0)

fails ?


We can't do that because nouveau_drm_screen_unref() needs a valid
nouveau_screen
object and in this case it is NULL.


Ouch I was under the impression that we've brought back the concept of
winsys in nouveau with the hash_table patches. Seems like we haven't
:(

If we are to do so (split things just like the radeon/amdgpu winsys)
then we can kill two birds with one stone. The missing device_del() on
calloc failure as well as other error paths in nvxx_screen_create().


Okay, I'll have a look at how radeon/amdgpu split those things.


Well, this doesn't seem to be "trivial" to do it properly actually.
This is on my todolist (but not with a top priority) so, if someone
else want to send a patch for this stuff, feel free to do it. :)





I agree that it's not really an elegant fix but we don't really have 
the

choice actually.
In my opinion, this is not that bad.


I never said it's "bad" just the wrong place for the fix. Or in other
words - if we're to fix things might as well do it properly :-)


Sure, I agree. :)



-Emil




___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 7/7] st/va: add headless support, i.e. VA_DISPLAY_DRM

2015-10-29 Thread Arnaud Vrac
On Thu, Oct 29, 2015 at 11:28 PM, Emil Velikov 
wrote:

> On 20 October 2015 at 17:40, Arnaud Vrac  wrote:
> > On Tue, Oct 20, 2015 at 6:35 PM, Emil Velikov 
> > wrote:
> >>
> >> On 20 October 2015 at 17:06, Julien Isorce 
> >> wrote:
> >> >
> >> >
> >> > On 19 October 2015 at 17:16, Emil Velikov 
> >> > wrote:
> >> >>
> >> >> On 17 October 2015 at 00:14, Julien Isorce 
> >> >> wrote:
> >> >> > This patch allows to use gallium vaapi without requiring
> >> >> > a X server running for your second graphic card.
> >> >> >
> >> >> I've sent a lengthy series which should mitigate the need of some
> >> >> hunks.
> >> >
> >> >
> >> > Ok I'll wait for your patches to land before going further on this
> >> > patch.
> >> > Should I expect vl_winsy_drm.c in your patches ? Not sure do
> understood
> >> > that
> >> > part. Actually I though about having "vl_screen_create_drm" and
> renames
> >> > vl_screen_create to vl_screen_create_x11 (because it takes XDisplay in
> >> > params) but then I got confused because vl_winsys.h includes Xlib.h.
> >> > Should
> >> > future vl_screen_create_drm be in another header, vl_drm.h ?
> >> >
> >> My series flattens the if GALLIUM_STATIC_TARGETS spaghetti. Although
> >> it's more of a FYI rather than "wait until they land".
> >>
> >> On the winsys_dri vs winsys_drm side - I'm not planning to do any work
> >> there, neither I did notice the Xlib.h dependency in vl_winsys.h.
> >>
> >> What I'm pondering is about having a 'proper' drm backend, although
> >> admittedly I haven't looked exactly what libva{-intel-driver,}'s
> >> definition of that is. I'd assume that moving the non-winsys specifics
> >> (from vl_winsys_dri.c) to vl_winsys.h and adding a
> >> vl_screen_texture_from_drawable() equivalent for drm (amongst others).
> >> As you can tell much of this is guesswork, so if you don't have the
> >> time and others are happy with the approach as is, feel free to
> >> ignore.
> >
> >
> > A wayland backend would be nice too.
> I'm afraid not many of us have the time and/or interest to work on
> that. Patches implementing it will be kindly accepted :-)
>
> > Right now vainfo under wayland just
> > crashes.
> >
> I guess we can separate the VA_DISPLAY_foo switch statement into a
> separate patch which can also go into stable. Personally I don't mind
> either way.
>

Julien added the VA_DISPLAY_WAYLAND in the switch in the latest patches, so
at least an error is now returned instead of crashing.

-- 
Arnaud
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v4 8/9] st/va: implement VaDeriveImage

2015-10-29 Thread Emil Velikov
Hi Julien,

One can separate the errors checks and get those separately (+stable).
I'll let others be the judge of that - I'm just going to point the
sections I have in mind.

On 29 October 2015 at 17:40, Julien Isorce  wrote:

> @@ -73,6 +76,10 @@ vlVaBufferSetNumElements(VADriverContextP ctx, VABufferID 
> buf_id,
>return VA_STATUS_ERROR_INVALID_CONTEXT;
>
> buf = handle_table_get(VL_VA_DRIVER(ctx)->htab, buf_id);
> +
> +   if (!buf || buf->derived_surface.resource)
> +  return VA_STATUS_ERROR_INVALID_BUFFER;
> +
Here ...


> @@ -86,16 +93,32 @@ vlVaBufferSetNumElements(VADriverContextP ctx, VABufferID 
> buf_id,
>  VAStatus
>  vlVaMapBuffer(VADriverContextP ctx, VABufferID buf_id, void **pbuff)
>  {
> +   vlVaDriver *drv;
> vlVaBuffer *buf;
>
> if (!ctx)
>return VA_STATUS_ERROR_INVALID_CONTEXT;
>
> -   buf = handle_table_get(VL_VA_DRIVER(ctx)->htab, buf_id);
> +   if (!pbuff)
> +  return VA_STATUS_ERROR_INVALID_BUFFER;
> +
> +   drv = VL_VA_DRIVER(ctx);
> +
> +   buf = handle_table_get(drv->htab, buf_id);
... and these two.


> diff --git a/src/gallium/state_trackers/va/image.c 
> b/src/gallium/state_trackers/va/image.c
> index 8e64673..f266ce8 100644
> --- a/src/gallium/state_trackers/va/image.c
> +++ b/src/gallium/state_trackers/va/image.c
> @@ -184,10 +184,95 @@ vlVaCreateImage(VADriverContextP ctx, VAImageFormat 
> *format, int width, int heig
>  VAStatus
>  vlVaDeriveImage(VADriverContextP ctx, VASurfaceID surface, VAImage *image)
>  {
> +   vlVaDriver *drv;
> +   vlVaSurface *surf;
> +   vlVaBuffer *img_buf;
> +   VAImage *img;
> +   struct pipe_surface **surfaces;
> +   int w;
> +   int h;
> +   int i;
> +
> if (!ctx)
>return VA_STATUS_ERROR_INVALID_CONTEXT;
>
> -   return VA_STATUS_ERROR_UNIMPLEMENTED;
> +   drv = VL_VA_DRIVER(ctx);
> +
> +   if (!drv)
> +  return VA_STATUS_ERROR_INVALID_CONTEXT;
> +
> +   surf = handle_table_get(drv->htab, surface);
> +
> +   if (!surf || !surf->buffer || surf->buffer->interlaced)
> +  return VA_STATUS_ERROR_INVALID_SURFACE;
> +
> +   surfaces = surf->buffer->get_surfaces(surf->buffer);
> +   if (!surfaces || !surfaces[0]->texture)
> +  return VA_STATUS_ERROR_ALLOCATION_FAILED;
> +
> +   img = CALLOC(1, sizeof(VAImage));
> +   if (!img)
> +  return VA_STATUS_ERROR_ALLOCATION_FAILED;
> +
> +   img->format.fourcc = PipeToYCbCr(surf->buffer->buffer_format);
> +   img->buf = VA_INVALID_ID;
> +   img->width = surf->buffer->width;
> +   img->height = surf->buffer->height;
> +   img->num_palette_entries = 0;
> +   img->entry_bytes = 0;
> +   w = align(surf->buffer->width, 2);
> +   h = align(surf->buffer->height, 2);
> +
> +   for (i = 0; i < ARRAY_SIZE(formats); ++i) {
> +  if (img->format.fourcc == formats[i].fourcc)
> + img->format = formats[i];
Break out of the loop ? Not a big deal either way.

-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v2 07/13] st/va: add headless support, i.e. VA_DISPLAY_DRM

2015-10-29 Thread Emil Velikov
On 29 October 2015 at 12:05, Christian König  wrote:
>
>> +  drm_info = (struct drm_state *) ctx->drm_state;
>> +  if (!drm_info) {
>> + FREE(drv);
>> + return VA_STATUS_ERROR_INVALID_PARAMETER;
>> +  }
>> +
>> +#if GALLIUM_STATIC_TARGETS
>> +  drm_fd = drm_info->fd;
>> +#else
>> +  drm_fd = dup(drm_info->fd);
>> +#endif
>> +
>> +  if (drm_fd < 0) {
>> + FREE(drv);
>> + return VA_STATUS_ERROR_INVALID_PARAMETER;
>> +  }
>> +
>> +  drv->vscreen = CALLOC_STRUCT(vl_screen);
>> +  if (!drv->vscreen)
>> + goto error_screen;
>> +
>> +#if GALLIUM_STATIC_TARGETS
>> +  drv->vscreen->pscreen = dd_create_screen(drm_fd);
>> +#else
>> +  if (pipe_loader_drm_probe_fd(>dev, drm_fd))
>> + drv->vscreen->pscreen = pipe_loader_create_screen(drv->dev,
>> PIPE_SEARCH_DIR);
>> +#endif
>> +
>> +  if (!drv->vscreen->pscreen)
>> + goto error_pipe;
>> +
>> +  }
>
>
> It would be nice to have this snip-set in something like a vl_winsys_drm.c
> if possible, but that's not a hard requirement and can happen when we
> actually need this elsewhere as well.
>
I doubt we'll need it elsewhere any time soon, so whenever one wants
to hack on something different it'll be fine :-P Although we should
consider splitting out the non platform specifics out of
vl_winsys_dri.c and perhaps fetching the xlib/xcb symbols via
dlsym/dlopen.

> Emil any further comments?

With the VA_RT_FORMAT_YUV400 handling dropped, and the
VA_RT_FORMAT_RGB32 + vlVaDestroySurfaces comments in  "st/va:
implement VaCreateSurfaces2 and VaQuerySurfaceAttributes" the whole 9
patches look great.  Fwiw
Reviewed-by: Emil Velikov 

Thank you for sticking around and addressing with all the comments Julien !

Christian, you are definitely more authoritative person on the topic,
so I'd leave the final decision up-to you.

> Did you static target cleanup already land? I
> would like to get at least quite a bunch of the patches upstream sooner than
> later.
>
Most people value their sanity and haven't looked at the static target
patches :( That said, none of that work is not a blocker for landing
these.

Cheers,
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 7/7] st/va: add headless support, i.e. VA_DISPLAY_DRM

2015-10-29 Thread Emil Velikov
On 20 October 2015 at 17:40, Arnaud Vrac  wrote:
> On Tue, Oct 20, 2015 at 6:35 PM, Emil Velikov 
> wrote:
>>
>> On 20 October 2015 at 17:06, Julien Isorce 
>> wrote:
>> >
>> >
>> > On 19 October 2015 at 17:16, Emil Velikov 
>> > wrote:
>> >>
>> >> On 17 October 2015 at 00:14, Julien Isorce 
>> >> wrote:
>> >> > This patch allows to use gallium vaapi without requiring
>> >> > a X server running for your second graphic card.
>> >> >
>> >> I've sent a lengthy series which should mitigate the need of some
>> >> hunks.
>> >
>> >
>> > Ok I'll wait for your patches to land before going further on this
>> > patch.
>> > Should I expect vl_winsy_drm.c in your patches ? Not sure do understood
>> > that
>> > part. Actually I though about having "vl_screen_create_drm" and renames
>> > vl_screen_create to vl_screen_create_x11 (because it takes XDisplay in
>> > params) but then I got confused because vl_winsys.h includes Xlib.h.
>> > Should
>> > future vl_screen_create_drm be in another header, vl_drm.h ?
>> >
>> My series flattens the if GALLIUM_STATIC_TARGETS spaghetti. Although
>> it's more of a FYI rather than "wait until they land".
>>
>> On the winsys_dri vs winsys_drm side - I'm not planning to do any work
>> there, neither I did notice the Xlib.h dependency in vl_winsys.h.
>>
>> What I'm pondering is about having a 'proper' drm backend, although
>> admittedly I haven't looked exactly what libva{-intel-driver,}'s
>> definition of that is. I'd assume that moving the non-winsys specifics
>> (from vl_winsys_dri.c) to vl_winsys.h and adding a
>> vl_screen_texture_from_drawable() equivalent for drm (amongst others).
>> As you can tell much of this is guesswork, so if you don't have the
>> time and others are happy with the approach as is, feel free to
>> ignore.
>
>
> A wayland backend would be nice too.
I'm afraid not many of us have the time and/or interest to work on
that. Patches implementing it will be kindly accepted :-)

> Right now vainfo under wayland just
> crashes.
>
I guess we can separate the VA_DISPLAY_foo switch statement into a
separate patch which can also go into stable. Personally I don't mind
either way.

Cheers,
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] i965/nir: Mark const index UBO surfaces as used

2015-10-29 Thread Jordan Justen
On 2015-10-29 02:17:20, Iago Toral wrote:
> On Thu, 2015-10-29 at 00:50 -0700, Jordan Justen wrote:
> > Signed-off-by: Jordan Justen 
> > ---
> >  src/mesa/drivers/dri/i965/brw_fs_nir.cpp   | 6 --
> >  src/mesa/drivers/dri/i965/brw_vec4_nir.cpp | 6 --
> >  2 files changed, 8 insertions(+), 4 deletions(-)
> > 
> > diff --git a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp 
> > b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> > index 4950ba4..6d69e96 100644
> > --- a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> > +++ b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> > @@ -1438,8 +1438,10 @@ fs_visitor::nir_emit_intrinsic(const fs_builder 
> > , nir_intrinsic_instr *instr
> >fs_reg surf_index;
> >  
> >if (const_index) {
> > - surf_index = fs_reg(stage_prog_data->binding_table.ubo_start +
> > - const_index->u[0]);
> > + unsigned index = stage_prog_data->binding_table.ubo_start +
> > +  const_index->u[0];
> > + surf_index = fs_reg(index);
> > + brw_mark_surface_used(prog_data, index);
> >} else {
> >   /* The block index is not a constant. Evaluate the index 
> > expression
> >* per-channel and add the base UBO index; we have to select a 
> > value
> > diff --git a/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp 
> > b/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
> > index 0f04f65..efbdaa9 100644
> > --- a/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
> > +++ b/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
> > @@ -749,8 +749,10 @@ vec4_visitor::nir_emit_intrinsic(nir_intrinsic_instr 
> > *instr)
> >   /* The block index is a constant, so just emit the binding table 
> > entry
> >* as an immediate.
> >*/
> > - surf_index = src_reg(prog_data->base.binding_table.ubo_start +
> > -  const_block_index->u[0]);
> > + unsigned index = prog_data->base.binding_table.ubo_start +
> > +  const_block_index->u[0];
> > + surf_index = src_reg(index);
> > + brw_mark_surface_used(_data->base, index);
> >} else {
> >   /* The block index is not a constant. Evaluate the index 
> > expression
> >* per-channel and add the base UBO index; we have to select a 
> > value
> 
> Is this necessary? As far as I can see, the generator opcodes will mark
> surfaces for which we have a constant index as used, so this should not
> be necessary.

Ah. You are correct.

I was debugging a UBO+SSBO test, and I noticed the discrepancy between
SSBO and UBO, but it appears SSBO has to mark it in brw_*_nir.cpp,
whereas the generator code can also mark it for the constant case for
UBOs.

Maybe we should just handle this in brw_*_nir.cpp for consistency?

-Jordan
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] gbm.h: Add a missing stddef.h include for size_t.

2015-10-29 Thread Matt Turner
On Thu, Oct 29, 2015 at 10:15 AM, Grazvydas Ignotas  wrote:
> Hi,
>
> On Thu, Oct 29, 2015 at 6:21 PM, Emil Velikov  
> wrote:
>> On 29 October 2015 at 15:22, Emmanuel Gil Peyrot
>>  wrote:
>>> This was causing compilation issues when one of its providers wasn’t
>>> already included before gbm.h.
>> Cc: "11.0" 
>> Reviewed-by: Emil Velikov 
>>
>> I'll push this later on today. For future patches please include your
>> s-o-b line.
>
> Some of you keep insisting on adding s-o-b while the site says it's
> not needed ( http://www.mesa3d.org/devinfo.html , "Patch formatting").
> Maybe devinfo.html should be updated?

I think it's kind of meaningless without an explanation of what it
means. The Linux kernel has a "Developer Certificate of Origin" in
Documentation/SubmittingPatches that explains what it means in that
context.

I'm not sure what lead the Linux community to create that and require
S-o-b and the certificate of origin. That seems like an important
question to answer before we start requiring S-o-b.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] gbm.h: Add a missing stddef.h include for size_t.

2015-10-29 Thread Emil Velikov
On 29 October 2015 at 17:15, Grazvydas Ignotas  wrote:
> Hi,
>
> On Thu, Oct 29, 2015 at 6:21 PM, Emil Velikov  
> wrote:
>> On 29 October 2015 at 15:22, Emmanuel Gil Peyrot
>>  wrote:
>>> This was causing compilation issues when one of its providers wasn’t
>>> already included before gbm.h.
>> Cc: "11.0" 
>> Reviewed-by: Emil Velikov 
>>
>> I'll push this later on today. For future patches please include your
>> s-o-b line.
>
> Some of you keep insisting on adding s-o-b while the site says it's
> not needed ( http://www.mesa3d.org/devinfo.html , "Patch formatting").
> Maybe devinfo.html should be updated?
>
True, in it's not required, esp if author == comitter.

I do nag^Wencourage people to use it and I haven't rejected patches
lacking it. At least I think I haven't ?

-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 1/2] [v3] i965/skl: Add GT4 PCI IDs

2015-10-29 Thread Ben Widawsky
Like other gen8+ hardware, the hardware automatically scales up thread counts
and URB sizes, so there is no need to do anything but add the PCI IDs.

FINISHME: This patch still needs testing before merge.

v2: Remove the PCI ID removal. That should be done as part of the next patch.

v3: Update the wm thread count to support GT4.

Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Ben Widawsky 
---
 include/pci_ids/i965_pci_ids.h  | 4 
 src/mesa/drivers/dri/i965/brw_device_info.c | 6 +-
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/include/pci_ids/i965_pci_ids.h b/include/pci_ids/i965_pci_ids.h
index 8a42599..626064a 100644
--- a/include/pci_ids/i965_pci_ids.h
+++ b/include/pci_ids/i965_pci_ids.h
@@ -124,6 +124,10 @@ CHIPSET(0x1921, skl_gt2, "Intel(R) Skylake ULT GT2F")
 CHIPSET(0x1926, skl_gt3, "Intel(R) Skylake ULT GT3")
 CHIPSET(0x192A, skl_gt3, "Intel(R) Skylake SRV GT3")
 CHIPSET(0x192B, skl_gt3, "Intel(R) Skylake Halo GT3")
+CHIPSET(0x1932, skl_gt4, "Intel(R) Skylake GT4")
+CHIPSET(0x193A, skl_gt4, "Intel(R) Skylake GT4")
+CHIPSET(0x193B, skl_gt4, "Intel(R) Skylake GT4")
+CHIPSET(0x193D, skl_gt4, "Intel(R) Skylake GT4")
 CHIPSET(0x22B0, chv, "Intel(R) HD Graphics (Cherryview)")
 CHIPSET(0x22B1, chv, "Intel(R) HD Graphics (Cherryview)")
 CHIPSET(0x22B2, chv, "Intel(R) HD Graphics (Cherryview)")
diff --git a/src/mesa/drivers/dri/i965/brw_device_info.c 
b/src/mesa/drivers/dri/i965/brw_device_info.c
index e86b530..2ebc084 100644
--- a/src/mesa/drivers/dri/i965/brw_device_info.c
+++ b/src/mesa/drivers/dri/i965/brw_device_info.c
@@ -311,7 +311,7 @@ static const struct brw_device_info brw_device_info_chv = {
.max_gs_threads = 336,   \
.max_hs_threads = 336,   \
.max_ds_threads = 336,   \
-   .max_wm_threads = 64 * 6,\
+   .max_wm_threads = 64 * 9,\
.max_cs_threads = 56,\
.urb = { \
   .size = 384,  \
@@ -335,6 +335,10 @@ static const struct brw_device_info 
brw_device_info_skl_gt3 = {
GEN9_FEATURES, .gt = 3,
 };
 
+static const struct brw_device_info brw_device_info_skl_gt4 = {
+   GEN9_FEATURES, .gt = 4,
+};
+
 static const struct brw_device_info brw_device_info_bxt = {
GEN9_FEATURES,
.is_broxton = 1,
-- 
2.6.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] i965: Replace default case with list of enum values.

2015-10-29 Thread Matt Turner
If we add a new file type, we'd like to get warnings if it's not
handled.

Unfortuately, gcc seems to have bugs (see the XXX).
---
 src/mesa/drivers/dri/i965/brw_fs.cpp  | 16 +---
 src/mesa/drivers/dri/i965/brw_fs_copy_propagation.cpp |  7 ---
 src/mesa/drivers/dri/i965/brw_fs_generator.cpp| 11 ---
 src/mesa/drivers/dri/i965/brw_ir_fs.h |  7 ---
 src/mesa/drivers/dri/i965/brw_vec4.cpp| 19 +++
 5 files changed, 32 insertions(+), 28 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp 
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index c40ca91..0258633 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -88,8 +88,6 @@ fs_inst::init(enum opcode opcode, uint8_t exec_size, const 
fs_reg ,
case IMM:
case UNIFORM:
   unreachable("Invalid destination register file");
-   default:
-  unreachable("Invalid register file");
}
 
this->writes_accumulator = false;
@@ -839,10 +837,10 @@ fs_inst::regs_read(int arg) const
   src[arg].component_size(exec_size),
   REG_SIZE);
case MRF:
-  unreachable("MRF registers are not allowed as sources");
-   default:
-  unreachable("Invalid register file");
+  break;
}
+   /* XXX: gcc warns if this is in the switch */
+   unreachable("MRF registers are not allowed as sources");
 }
 
 bool
@@ -4501,9 +4499,8 @@ fs_visitor::dump_instruction(backend_instruction 
*be_inst, FILE *file)
   if (inst->dst.fixed_hw_reg.subnr)
  fprintf(file, "+%d", inst->dst.fixed_hw_reg.subnr);
   break;
-   default:
-  fprintf(file, "???");
-  break;
+   case IMM:
+  unreachable("not reached");
}
fprintf(file, ":%s, ", brw_reg_type_letters(inst->dst.type));
 
@@ -4596,9 +4593,6 @@ fs_visitor::dump_instruction(backend_instruction 
*be_inst, FILE *file)
  if (inst->src[i].fixed_hw_reg.abs)
 fprintf(file, "|");
  break;
-  default:
- fprintf(file, "???");
- break;
   }
   if (inst->src[i].abs)
  fprintf(file, "|");
diff --git a/src/mesa/drivers/dri/i965/brw_fs_copy_propagation.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_copy_propagation.cpp
index 97e206d..2620482 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_copy_propagation.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_copy_propagation.cpp
@@ -416,9 +416,10 @@ fs_visitor::try_copy_propagate(fs_inst *inst, int arg, 
acp_entry *entry)
  inst->src[arg].subreg_offset = offset % 32;
   }
   break;
-   default:
-  unreachable("Invalid register file");
-  break;
+
+   case MRF:
+   case IMM:
+  unreachable("not reached");
}
 
if (has_source_modifiers) {
diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
index 139d1dd..4ef86dd 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
@@ -42,9 +42,13 @@ static uint32_t brw_file_from_reg(fs_reg *reg)
   return BRW_MESSAGE_REGISTER_FILE;
case IMM:
   return BRW_IMMEDIATE_VALUE;
-   default:
-  unreachable("not reached");
+   case BAD_FILE:
+   case HW_REG:
+   case ATTR:
+   case UNIFORM:
+  break;
}
+   unreachable("not reached"); /* XXX: gcc warns if this is in the switch */
 }
 
 static struct brw_reg
@@ -116,7 +120,8 @@ brw_reg_from_fs_reg(fs_inst *inst, fs_reg *reg, unsigned 
gen)
   /* Probably unused. */
   brw_reg = brw_null_reg();
   break;
-   default:
+   case ATTR:
+   case UNIFORM:
   unreachable("not reached");
}
if (reg->abs)
diff --git a/src/mesa/drivers/dri/i965/brw_ir_fs.h 
b/src/mesa/drivers/dri/i965/brw_ir_fs.h
index 7726e4b..4417555 100644
--- a/src/mesa/drivers/dri/i965/brw_ir_fs.h
+++ b/src/mesa/drivers/dri/i965/brw_ir_fs.h
@@ -97,7 +97,9 @@ byte_offset(fs_reg reg, unsigned delta)
case MRF:
   reg.reg += delta / 32;
   break;
-   default:
+   case IMM:
+   case HW_REG:
+   case UNIFORM:
   assert(delta == 0);
}
reg.subreg_offset += delta % 32;
@@ -119,7 +121,7 @@ horiz_offset(fs_reg reg, unsigned delta)
case MRF:
case ATTR:
   return byte_offset(reg, delta * reg.stride * type_sz(reg.type));
-   default:
+   case HW_REG:
   assert(delta == 0);
}
return reg;
@@ -163,7 +165,6 @@ half(fs_reg reg, unsigned idx)
 
case ATTR:
case HW_REG:
-   default:
   unreachable("Cannot take half of this register type");
}
return reg;
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4.cpp
index 3353e1e..01eb158 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
@@ -1427,9 +1427,10 @@ vec4_visitor::dump_instruction(backend_instruction 
*be_inst, FILE *file)
case BAD_FILE:
   fprintf(file, "(null)");
   break;
-   default:
-  

[Mesa-dev] [PATCH] i965/vec4: Don't disable channels in any/all comparisons.

2015-10-29 Thread Matt Turner
We've made a mistake in calling the Channel Enable bits "writemask",
because they do more than control which channels of the destination are
written -- they actually control which channels are enabled (surprise!
surprise!)

So, if we emit

   cmp.z.f0(8) null.xy<1>D  g10<4,4,1>.xyzzD g2<0,4,1>.xyzzD
   mov(8)  g12<1>.xUD   0xUD
   (+f0.all4h) mov(8)  g12<1>.xUD   0xUD

where the CMP instruction has only .xy channel enables, it won't write
the .zw channels of the flag register, which are of course read by the
+f0.all4 predicate.

We need to always emit CMP instructions whose flag result might be read
by such a predicate with all channels enabled.
---
 src/mesa/drivers/dri/i965/brw_vec4_nir.cpp | 52 ++
 1 file changed, 10 insertions(+), 42 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
index 0f04f65..33cc02e 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
@@ -1146,26 +1146,10 @@ vec4_visitor::nir_emit_alu(nir_alu_instr *instr)
case nir_op_ball_iequal3:
case nir_op_ball_fequal4:
case nir_op_ball_iequal4: {
-  dst_reg tmp = dst_reg(this, glsl_type::bool_type);
+  unsigned swiz =
+ brw_swizzle_for_size(nir_op_infos[instr->op].input_sizes[0]);
 
-  switch (instr->op) {
-  case nir_op_ball_fequal2:
-  case nir_op_ball_iequal2:
- tmp.writemask = WRITEMASK_XY;
- break;
-  case nir_op_ball_fequal3:
-  case nir_op_ball_iequal3:
- tmp.writemask = WRITEMASK_XYZ;
- break;
-  case nir_op_ball_fequal4:
-  case nir_op_ball_iequal4:
- tmp.writemask = WRITEMASK_XYZW;
- break;
-  default:
- unreachable("not reached");
-  }
-
-  emit(CMP(tmp, op[0], op[1],
+  emit(CMP(dst_null_d(), swizzle(op[0], swiz), swizzle(op[1], swiz),
brw_conditional_for_nir_comparison(instr->op)));
   emit(MOV(dst, src_reg(0)));
   inst = emit(MOV(dst, src_reg(~0)));
@@ -1179,26 +1163,10 @@ vec4_visitor::nir_emit_alu(nir_alu_instr *instr)
case nir_op_bany_inequal3:
case nir_op_bany_fnequal4:
case nir_op_bany_inequal4: {
-  dst_reg tmp = dst_reg(this, glsl_type::bool_type);
+  unsigned swiz =
+ brw_swizzle_for_size(nir_op_infos[instr->op].input_sizes[0]);
 
-  switch (instr->op) {
-  case nir_op_bany_fnequal2:
-  case nir_op_bany_inequal2:
- tmp.writemask = WRITEMASK_XY;
- break;
-  case nir_op_bany_fnequal3:
-  case nir_op_bany_inequal3:
- tmp.writemask = WRITEMASK_XYZ;
- break;
-  case nir_op_bany_fnequal4:
-  case nir_op_bany_inequal4:
- tmp.writemask = WRITEMASK_XYZW;
- break;
-  default:
- unreachable("not reached");
-  }
-
-  emit(CMP(tmp, op[0], op[1],
+  emit(CMP(dst_null_d(), swizzle(op[0], swiz), swizzle(op[1], swiz),
brw_conditional_for_nir_comparison(instr->op)));
 
   emit(MOV(dst, src_reg(0)));
@@ -1463,11 +1431,11 @@ vec4_visitor::nir_emit_alu(nir_alu_instr *instr)
case nir_op_bany2:
case nir_op_bany3:
case nir_op_bany4: {
-  dst_reg tmp = dst_reg(this, glsl_type::bool_type);
-  tmp.writemask = 
brw_writemask_for_size(nir_op_infos[instr->op].input_sizes[0]);
-
-  emit(CMP(tmp, op[0], src_reg(0), BRW_CONDITIONAL_NZ));
+  unsigned swiz =
+ brw_swizzle_for_size(nir_op_infos[instr->op].input_sizes[0]);
 
+  emit(CMP(dst_null_d(), swizzle(op[0], swiz), src_reg(0),
+   BRW_CONDITIONAL_NZ));
   emit(MOV(dst, src_reg(0)));
   inst = emit(MOV(dst, src_reg(~0)));
   inst->predicate = BRW_PREDICATE_ALIGN16_ANY4H;
-- 
2.4.9

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] i965: Clean up FBH code.

2015-10-29 Thread Matt Turner
It did a bunch of unnecessary stuff, emitting an extra MOV included.
---
 src/mesa/drivers/dri/i965/brw_fs_nir.cpp   |  7 +++
 src/mesa/drivers/dri/i965/brw_vec4_nir.cpp | 18 +-
 2 files changed, 8 insertions(+), 17 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
index 9c1f95c..b596614 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
@@ -906,12 +906,11 @@ fs_visitor::nir_emit_alu(const fs_builder , 
nir_alu_instr *instr)
* from the LSB side. If FBH didn't return an error (0x), then
* subtract the result from 31 to convert the MSB count into an LSB 
count.
*/
-
   bld.CMP(bld.null_reg_d(), result, fs_reg(-1), BRW_CONDITIONAL_NZ);
-  fs_reg neg_result(result);
-  neg_result.negate = true;
-  inst = bld.ADD(result, neg_result, fs_reg(31));
+
+  inst = bld.ADD(result, result, fs_reg(31));
   inst->predicate = BRW_PREDICATE_NORMAL;
+  inst->src[0].negate = true;
   break;
}
 
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
index 33cc02e..5463f3e 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
@@ -1291,26 +1291,18 @@ vec4_visitor::nir_emit_alu(nir_alu_instr *instr)
 
case nir_op_ufind_msb:
case nir_op_ifind_msb: {
-  src_reg temp = src_reg(this, glsl_type::uint_type);
-
-  inst = emit(FBH(dst_reg(temp), op[0]));
-  inst->dst.writemask = WRITEMASK_XYZW;
+  emit(FBH(retype(dst, BRW_REGISTER_TYPE_UD), op[0]));
 
   /* FBH counts from the MSB side, while GLSL's findMSB() wants the count
* from the LSB side. If FBH didn't return an error (0x), then
* subtract the result from 31 to convert the MSB count into an LSB 
count.
*/
+  src_reg src(dst);
+  emit(CMP(dst_null_d(), src, src_reg(-1), BRW_CONDITIONAL_NZ));
 
-  /* FBH only supports UD type for dst, so use a MOV to convert UD to D. */
-  temp.swizzle = BRW_SWIZZLE_NOOP;
-  emit(MOV(dst, temp));
-
-  src_reg src_tmp = src_reg(dst);
-  emit(CMP(dst_null_d(), src_tmp, src_reg(-1), BRW_CONDITIONAL_NZ));
-
-  src_tmp.negate = true;
-  inst = emit(ADD(dst, src_tmp, src_reg(31)));
+  inst = emit(ADD(dst, src, src_reg(31)));
   inst->predicate = BRW_PREDICATE_NORMAL;
+  inst->src[0].negate = true;
   break;
}
 
-- 
2.4.9

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] Patchwork/mesa-stable question (was: Re: [PATCH v3] r600g: Fix special negative immediate constants when using ABS modifier.)

2015-10-29 Thread Nicolai Hähnle

On 29.10.2015 10:24, Ivan Kalvachev wrote:
[snip]

On 10/29/15, Nicolai Hähnle  wrote:

On 29.10.2015 01:52, Ivan Kalvachev wrote:

On 10/26/15, Nicolai Hähnle  wrote:

On 25.10.2015 02:00, Ivan Kalvachev wrote:

Some constants (like 1.0 and 0.5) could be inlined as immediate inputs
without using their literal value. The
r600_bytecode_special_constants()
function emulates the negative of these constants by using NEG
modifier.

However some shaders define -1.0 constant and want to use it as 1.0.
They do so by using ABS modifier. But r600_bytecode_special_constants()
set NEG in addition to ABS. Since NEG modifier have priority over ABS
one,
we get -|1.0| as result, instead of |1.0|.

The patch simply prevents the additional switching of NEG when ABS is
set.


Nice catch. Is there a simple test case (e.g. in piglit) that exposes
the incorrect behavior?


Not that I know of.

I've located the bug investigating visual problem in Nine.
https://github.com/iXit/Mesa-3D/issues/126
https://github.com/iXit/Mesa-3D/issues/127

I also heard that it fixes artifacts in "Need for Speed: Undercover"
and "Skyrim", once again, when using Nine.


I see. I guess it's not too surprising that Nine creates shaders that
look a bit different from the Mesa statetracker's.

Reviewed-by: Nicolai Hähnle 

This should probably also go to stable.

Do you need somebody to push this for you or can you do it yourself?

Cheers,
Nicolai


Yes, please.
I'm not developer and I cannot push it myself.


I pushed the patch.

I am not familiar with patchwork yet and have a related question: on my 
push, I got the following error message related to patchwork:


remote: E: failed to find patch for rev 
f75f21a24ae2dd83507f3d4d8007f0fcfe6db802


Apparently, patchwork didn't pick up Ivan's v3 patch, perhaps because it 
wasn't inline. Is this something to worry about? Specifically, I believe 
the patch is a candidate for the stable branch, and I added the 
appropriate Cc: in the commit message. Does the message above prevent it 
from being picked up?


Sorry for the noise :/

Thanks!
Nicolai
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] Patchwork/mesa-stable question (was: Re: [PATCH v3] r600g: Fix special negative immediate constants when using ABS modifier.)

2015-10-29 Thread Ilia Mirkin
On Thu, Oct 29, 2015 at 7:11 PM, Nicolai Hähnle  wrote:
> On 29.10.2015 10:24, Ivan Kalvachev wrote:
> [snip]
>>
>> On 10/29/15, Nicolai Hähnle  wrote:
>>>
>>> On 29.10.2015 01:52, Ivan Kalvachev wrote:

 On 10/26/15, Nicolai Hähnle  wrote:
>
> On 25.10.2015 02:00, Ivan Kalvachev wrote:
>>
>> Some constants (like 1.0 and 0.5) could be inlined as immediate inputs
>> without using their literal value. The
>> r600_bytecode_special_constants()
>> function emulates the negative of these constants by using NEG
>> modifier.
>>
>> However some shaders define -1.0 constant and want to use it as 1.0.
>> They do so by using ABS modifier. But
>> r600_bytecode_special_constants()
>> set NEG in addition to ABS. Since NEG modifier have priority over ABS
>> one,
>> we get -|1.0| as result, instead of |1.0|.
>>
>> The patch simply prevents the additional switching of NEG when ABS is
>> set.
>
>
> Nice catch. Is there a simple test case (e.g. in piglit) that exposes
> the incorrect behavior?


 Not that I know of.

 I've located the bug investigating visual problem in Nine.
 https://github.com/iXit/Mesa-3D/issues/126
 https://github.com/iXit/Mesa-3D/issues/127

 I also heard that it fixes artifacts in "Need for Speed: Undercover"
 and "Skyrim", once again, when using Nine.
>>>
>>>
>>> I see. I guess it's not too surprising that Nine creates shaders that
>>> look a bit different from the Mesa statetracker's.
>>>
>>> Reviewed-by: Nicolai Hähnle 
>>>
>>> This should probably also go to stable.
>>>
>>> Do you need somebody to push this for you or can you do it yourself?
>>>
>>> Cheers,
>>> Nicolai
>>
>>
>> Yes, please.
>> I'm not developer and I cannot push it myself.
>
>
> I pushed the patch.
>
> I am not familiar with patchwork yet and have a related question: on my
> push, I got the following error message related to patchwork:
>
> remote: E: failed to find patch for rev
> f75f21a24ae2dd83507f3d4d8007f0fcfe6db802
>
> Apparently, patchwork didn't pick up Ivan's v3 patch,

Now you know why there are so many stale patches in patchwork... if
the diff part of the commit doesn't match 100% to something in
patchwork, the search fails.

> perhaps because it
> wasn't inline. Is this something to worry about? Specifically, I believe the
> patch is a candidate for the stable branch, and I added the appropriate Cc:
> in the commit message. Does the message above prevent it from being picked
> up?

Nope, all's well. Assuming that the thing you wanted to get pushed has
been. Patchwork isn't part of any "official" process, just a
convenience tool.

  -ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] Patchwork/mesa-stable question (was: Re: [PATCH v3] r600g: Fix special negative immediate constants when using ABS modifier.)

2015-10-29 Thread Matt Turner
On Thu, Oct 29, 2015 at 4:23 PM, Ilia Mirkin  wrote:
> On Thu, Oct 29, 2015 at 7:11 PM, Nicolai Hähnle  wrote:
>> perhaps because it
>> wasn't inline. Is this something to worry about? Specifically, I believe the
>> patch is a candidate for the stable branch, and I added the appropriate Cc:
>> in the commit message. Does the message above prevent it from being picked
>> up?
>
> Nope, all's well. Assuming that the thing you wanted to get pushed has
> been. Patchwork isn't part of any "official" process, just a
> convenience tool.

While that's true, not cleaning up patches you push just makes it
harder to find unapplied patches that have fallen through the cracks.

The nice thing to do when you see that message is to mark the patch as
accepted/superseded.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 7/7] st/va: add headless support, i.e. VA_DISPLAY_DRM

2015-10-29 Thread Emil Velikov
On 29 October 2015 at 23:04, Arnaud Vrac  wrote:
> On Thu, Oct 29, 2015 at 11:28 PM, Emil Velikov 
> wrote:
>>
>> On 20 October 2015 at 17:40, Arnaud Vrac  wrote:
>> > On Tue, Oct 20, 2015 at 6:35 PM, Emil Velikov 
>> > wrote:
>> >>
>> >> On 20 October 2015 at 17:06, Julien Isorce 
>> >> wrote:
>> >> >
>> >> >
>> >> > On 19 October 2015 at 17:16, Emil Velikov 
>> >> > wrote:
>> >> >>
>> >> >> On 17 October 2015 at 00:14, Julien Isorce 
>> >> >> wrote:
>> >> >> > This patch allows to use gallium vaapi without requiring
>> >> >> > a X server running for your second graphic card.
>> >> >> >
>> >> >> I've sent a lengthy series which should mitigate the need of some
>> >> >> hunks.
>> >> >
>> >> >
>> >> > Ok I'll wait for your patches to land before going further on this
>> >> > patch.
>> >> > Should I expect vl_winsy_drm.c in your patches ? Not sure do
>> >> > understood
>> >> > that
>> >> > part. Actually I though about having "vl_screen_create_drm" and
>> >> > renames
>> >> > vl_screen_create to vl_screen_create_x11 (because it takes XDisplay
>> >> > in
>> >> > params) but then I got confused because vl_winsys.h includes Xlib.h.
>> >> > Should
>> >> > future vl_screen_create_drm be in another header, vl_drm.h ?
>> >> >
>> >> My series flattens the if GALLIUM_STATIC_TARGETS spaghetti. Although
>> >> it's more of a FYI rather than "wait until they land".
>> >>
>> >> On the winsys_dri vs winsys_drm side - I'm not planning to do any work
>> >> there, neither I did notice the Xlib.h dependency in vl_winsys.h.
>> >>
>> >> What I'm pondering is about having a 'proper' drm backend, although
>> >> admittedly I haven't looked exactly what libva{-intel-driver,}'s
>> >> definition of that is. I'd assume that moving the non-winsys specifics
>> >> (from vl_winsys_dri.c) to vl_winsys.h and adding a
>> >> vl_screen_texture_from_drawable() equivalent for drm (amongst others).
>> >> As you can tell much of this is guesswork, so if you don't have the
>> >> time and others are happy with the approach as is, feel free to
>> >> ignore.
>> >
>> >
>> > A wayland backend would be nice too.
>> I'm afraid not many of us have the time and/or interest to work on
>> that. Patches implementing it will be kindly accepted :-)
>>
>> > Right now vainfo under wayland just
>> > crashes.
>> >
>> I guess we can separate the VA_DISPLAY_foo switch statement into a
>> separate patch which can also go into stable. Personally I don't mind
>> either way.
>
>
> Julien added the VA_DISPLAY_WAYLAND in the switch in the latest patches, so
> at least an error is now returned instead of crashing.
>
True. But as is the patch won't end up in stable. Which means that
mesa 11.0.x and earlier(?) will continue crashing.
Although my systems is fine - no wayland no problems :-P

-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v2] st/mesa: fix mipmap generation for immutable textures with incomplete pyramids

2015-10-29 Thread Emil Velikov
On 29 October 2015 at 22:56, Nicolai Hähnle  wrote:
> On 29.10.2015 14:13, Marek Olšák wrote:
>>
>> On Wed, Oct 28, 2015 at 1:00 PM, Nicolai Hähnle 
>> wrote:
>>>
>>> Without the clamping by NumLevels, the state tracker would reallocate the
>>> texture storage (incorrect) and even fail to copy the base level image
>>> after reallocation, leading to the graphical glitch of
>>> https://bugs.freedesktop.org/show_bug.cgi?id=91993 .
>>>
>>> A piglit test has been submitted for review as well (subtest of
>>> arb_texture_storage-texture-storage).
>>>
>>> v2: also bypass all calls to st_finalize_texture (suggested by Marek
>>> Olšák)
>>>
>>> Cc: mesa-sta...@lists.freedesktop.org
>>> Reviewed-by: Marek Olšák 
>>
>>
>> This looks good.
>>
>> (a minor nit: an updated patch should not contain any reviewed-by
>> tags, because the updated version hadn't been seen by anybody at the
>> time of sending it to the list; it's okay to keep the tag now that
>> I've reviewed it)
>
>
> Sorry about that, I'll be more careful about that in the future.
>
Fwiw some of us tend to add the revision based on which the r-b was
given, when the revision history is present in the commit message.
Something like:

v2: Changed foo and bar.

Reviewed-by: Slim Shady  (v1)

Then again, you might want to follow your colleague's suggestion.
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] texgetimage: fix regression with shadow 1d array

2015-10-29 Thread Dave Airlie
>
> What exactly are the parameters to glGetTextureSubImage() that hits this?

It's actually a call to glGetnTexImage

#4  0x772ce215 in get_tex_depth (ctx=0x9d03d0, dimensions=2,
xoffset=0, yoffset=0, zoffset=0, width=65, height=1, depth=40,
format=6402, type=5125,
pixels=0xe32a10, texImage=0x995d30) at main/texgetimage.c:96
#5  0x772cf62c in _mesa_GetTexSubImage_sw (ctx=0x9d03d0,
xoffset=0, yoffset=0, zoffset=0, width=65, height=40, depth=1,
format=6402, type=5125,
pixels=0xe32a10, texImage=0x995d30) at main/texgetimage.c:746
#6  0x7740bb86 in _mesa_meta_GetTexSubImage (ctx=0x9d03d0,
xoffset=0, yoffset=0, zoffset=0, width=65, height=40, depth=1,
format=6402, type=5125,
pixels=0xe32a10, texImage=0x995d30) at drivers/common/meta.c:3236
#7  0x7760a93c in intel_get_tex_sub_image (ctx=0x9d03d0,
xoffset=0, yoffset=0, zoffset=0, width=65, height=40, depth=1,
format=6402, type=5125,
pixels=0xe32a10, texImage=0x995d30) at intel_tex_image.c:508
#8  0x772d0a65 in get_texture_image (ctx=0x9d03d0,
texObj=0x9be130, target=35864, level=0, xoffset=0, yoffset=0,
zoffset=0, width=65, height=40,
depth=1, format=6402, type=5125, pixels=0xe32a10,
caller=0x776ec243 "glGetnTexImageARB") at main/texgetimage.c:1342

Is the backtrace.

> zoffset should always be zero for TEXTURE_1D_ARRAY, so I think we should be
> assigning zoffset = yoffset for the 1D array case, as we do in
> get_tex_rgba_uncompressed().
>
> Also, there's several other functions, like get_tex_depth_stencil(),
> get_tex_stencil(), etc. that would seem to need similar y/z height/depth
> translation for 1D_ARRAY.  In fact, maybe this should all be done in
> _mesa_GetTexSubImage_sw() before any of these functions are called.
>
> Do you have time to look into that?

I'll see if I can write a piglit for it, as using virgl is a bit of overhead.

Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] glsl: OpenGLES GLSL 3.1 precision qualifiers ordering rules

2015-10-29 Thread Jordan Justen
The OpenGLES GLSL 3.1 specification uses the precision qualifier
ordering rules from ARB_shading_language_420pack.

Signed-off-by: Jordan Justen 
---
 src/glsl/glsl_parser.yy | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy
index 2f2e10d..4636435 100644
--- a/src/glsl/glsl_parser.yy
+++ b/src/glsl/glsl_parser.yy
@@ -948,7 +948,8 @@ parameter_qualifier:
   if ($2.precision != ast_precision_none)
  _mesa_glsl_error(&@1, state, "duplicate precision qualifier");
 
-  if (!state->has_420pack() && $2.flags.i != 0)
+  if (!(state->has_420pack() || state->is_version(420, 310)) &&
+  $2.flags.i != 0)
  _mesa_glsl_error(&@1, state, "precision qualifiers must come last");
 
   $$ = $2;
@@ -1847,7 +1848,8 @@ type_qualifier:
   if ($2.precision != ast_precision_none)
  _mesa_glsl_error(&@1, state, "duplicate precision qualifier");
 
-  if (!state->has_420pack() && $2.flags.i != 0)
+  if (!(state->has_420pack() || state->is_version(420, 310)) &&
+  $2.flags.i != 0)
  _mesa_glsl_error(&@1, state, "precision qualifiers must come last");
 
   $$ = $2;
-- 
2.5.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] glsl: Add compute shader builtin variables for OpenGLES 3.1

2015-10-29 Thread Jordan Justen
Signed-off-by: Jordan Justen 
---
 src/glsl/builtin_variables.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/glsl/builtin_variables.cpp b/src/glsl/builtin_variables.cpp
index a6ad105..00113d5 100644
--- a/src/glsl/builtin_variables.cpp
+++ b/src/glsl/builtin_variables.cpp
@@ -710,7 +710,7 @@ builtin_variable_generator::generate_constants()
   }
}
 
-   if (state->is_version(430, 0) || state->ARB_compute_shader_enable) {
+   if (state->is_version(430, 310) || state->ARB_compute_shader_enable) {
   add_const("gl_MaxComputeAtomicCounterBuffers", 
MAX_COMPUTE_ATOMIC_COUNTER_BUFFERS);
   add_const("gl_MaxComputeAtomicCounters", MAX_COMPUTE_ATOMIC_COUNTERS);
   add_const("gl_MaxComputeImageUniforms", MAX_COMPUTE_IMAGE_UNIFORMS);
-- 
2.5.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] glsl: OpenGLES GLSL 3.1 precision qualifiers ordering rules

2015-10-29 Thread Ilia Mirkin
Would it make sense to just modify the has_420pack function? Or do you
not want all of it?

On Thu, Oct 29, 2015 at 3:47 AM, Jordan Justen
 wrote:
> The OpenGLES GLSL 3.1 specification uses the precision qualifier
> ordering rules from ARB_shading_language_420pack.
>
> Signed-off-by: Jordan Justen 
> ---
>  src/glsl/glsl_parser.yy | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy
> index 2f2e10d..4636435 100644
> --- a/src/glsl/glsl_parser.yy
> +++ b/src/glsl/glsl_parser.yy
> @@ -948,7 +948,8 @@ parameter_qualifier:
>if ($2.precision != ast_precision_none)
>   _mesa_glsl_error(&@1, state, "duplicate precision qualifier");
>
> -  if (!state->has_420pack() && $2.flags.i != 0)
> +  if (!(state->has_420pack() || state->is_version(420, 310)) &&
> +  $2.flags.i != 0)
>   _mesa_glsl_error(&@1, state, "precision qualifiers must come last");
>
>$$ = $2;
> @@ -1847,7 +1848,8 @@ type_qualifier:
>if ($2.precision != ast_precision_none)
>   _mesa_glsl_error(&@1, state, "duplicate precision qualifier");
>
> -  if (!state->has_420pack() && $2.flags.i != 0)
> +  if (!(state->has_420pack() || state->is_version(420, 310)) &&
> +  $2.flags.i != 0)
>   _mesa_glsl_error(&@1, state, "precision qualifiers must come last");
>
>$$ = $2;
> --
> 2.5.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 1/2] mesa/sso: Add MESA_VERBOSE=api trace support

2015-10-29 Thread Jordan Justen
Signed-off-by: Jordan Justen 
---
 src/mesa/main/pipelineobj.c | 33 +
 1 file changed, 33 insertions(+)

diff --git a/src/mesa/main/pipelineobj.c b/src/mesa/main/pipelineobj.c
index 51ee10f..c8c50fa 100644
--- a/src/mesa/main/pipelineobj.c
+++ b/src/mesa/main/pipelineobj.c
@@ -230,6 +230,10 @@ _mesa_UseProgramStages(GLuint pipeline, GLbitfield stages, 
GLuint program)
struct gl_shader_program *shProg = NULL;
GLbitfield any_valid_stages;
 
+   if (MESA_VERBOSE & VERBOSE_API)
+  _mesa_debug(ctx, "glUseProgramStages(%d, 0x%x, %d)\n",
+  pipeline, stages, program);
+
if (!pipe) {
   _mesa_error(ctx, GL_INVALID_OPERATION, "glUseProgramStages(pipeline)");
   return;
@@ -345,6 +349,9 @@ _mesa_ActiveShaderProgram(GLuint pipeline, GLuint program)
struct gl_shader_program *shProg = NULL;
struct gl_pipeline_object *pipe = _mesa_lookup_pipeline_object(ctx, 
pipeline);
 
+   if (MESA_VERBOSE & VERBOSE_API)
+  _mesa_debug(ctx, "glActiveShaderProgram(%d, %d)\n", pipeline, program);
+
if (program != 0) {
   shProg = _mesa_lookup_shader_program_err(ctx, program,

"glActiveShaderProgram(program)");
@@ -380,6 +387,9 @@ _mesa_BindProgramPipeline(GLuint pipeline)
GET_CURRENT_CONTEXT(ctx);
struct gl_pipeline_object *newObj = NULL;
 
+   if (MESA_VERBOSE & VERBOSE_API)
+  _mesa_debug(ctx, "glBindProgramPipeline(%d)\n", pipeline);
+
/* Rebinding the same pipeline object: no change.
 */
if (ctx->_Shader->Name == pipeline)
@@ -467,6 +477,9 @@ _mesa_DeleteProgramPipelines(GLsizei n, const GLuint 
*pipelines)
GET_CURRENT_CONTEXT(ctx);
GLsizei i;
 
+   if (MESA_VERBOSE & VERBOSE_API)
+  _mesa_debug(ctx, "glDeleteProgramPipelines(%d, %p)\n", n, pipelines);
+
if (n < 0) {
   _mesa_error(ctx, GL_INVALID_VALUE, "glDeleteProgramPipelines(n<0)");
   return;
@@ -551,6 +564,9 @@ _mesa_GenProgramPipelines(GLsizei n, GLuint *pipelines)
 {
GET_CURRENT_CONTEXT(ctx);
 
+   if (MESA_VERBOSE & VERBOSE_API)
+  _mesa_debug(ctx, "glGenProgramPipelines(%d, %p)\n", n, pipelines);
+
create_program_pipelines(ctx, n, pipelines, false);
 }
 
@@ -559,6 +575,9 @@ _mesa_CreateProgramPipelines(GLsizei n, GLuint *pipelines)
 {
GET_CURRENT_CONTEXT(ctx);
 
+   if (MESA_VERBOSE & VERBOSE_API)
+  _mesa_debug(ctx, "glCreateProgramPipelines(%d, %p)\n", n, pipelines);
+
create_program_pipelines(ctx, n, pipelines, true);
 }
 
@@ -574,6 +593,9 @@ _mesa_IsProgramPipeline(GLuint pipeline)
 {
GET_CURRENT_CONTEXT(ctx);
 
+   if (MESA_VERBOSE & VERBOSE_API)
+  _mesa_debug(ctx, "glIsProgramPipeline(%d)\n", pipeline);
+
struct gl_pipeline_object *obj = _mesa_lookup_pipeline_object(ctx, 
pipeline);
if (obj == NULL)
   return GL_FALSE;
@@ -590,6 +612,10 @@ _mesa_GetProgramPipelineiv(GLuint pipeline, GLenum pname, 
GLint *params)
GET_CURRENT_CONTEXT(ctx);
struct gl_pipeline_object *pipe = _mesa_lookup_pipeline_object(ctx, 
pipeline);
 
+   if (MESA_VERBOSE & VERBOSE_API)
+  _mesa_debug(ctx, "glGetProgramPipelineiv(%d, %d, %p)\n",
+  pipeline, pname, params);
+
/* Are geometry shaders available in this context?
 */
const bool has_gs = _mesa_has_geometry_shaders(ctx);
@@ -857,6 +883,9 @@ _mesa_ValidateProgramPipeline(GLuint pipeline)
 {
GET_CURRENT_CONTEXT(ctx);
 
+   if (MESA_VERBOSE & VERBOSE_API)
+  _mesa_debug(ctx, "glValidateProgramPipeline(%d)\n", pipeline);
+
struct gl_pipeline_object *pipe = _mesa_lookup_pipeline_object(ctx, 
pipeline);
 
if (!pipe) {
@@ -875,6 +904,10 @@ _mesa_GetProgramPipelineInfoLog(GLuint pipeline, GLsizei 
bufSize,
 {
GET_CURRENT_CONTEXT(ctx);
 
+   if (MESA_VERBOSE & VERBOSE_API)
+  _mesa_debug(ctx, "glGetProgramPipelineInfoLog(%d, %d, %p, %p)\n",
+  pipeline, bufSize, length, infoLog);
+
struct gl_pipeline_object *pipe = _mesa_lookup_pipeline_object(ctx, 
pipeline);
 
if (!pipe) {
-- 
2.5.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 2/2] mesa/sso: Add compute shader support

2015-10-29 Thread Jordan Justen
Signed-off-by: Jordan Justen 
---
 src/mesa/main/api_validate.c |  2 +-
 src/mesa/main/pipelineobj.c  | 11 +++
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/src/mesa/main/api_validate.c b/src/mesa/main/api_validate.c
index c59b6f3..46f39e7 100644
--- a/src/mesa/main/api_validate.c
+++ b/src/mesa/main/api_validate.c
@@ -923,7 +923,7 @@ check_valid_to_compute(struct gl_context *ctx, const char 
*function)
 * "An INVALID_OPERATION error is generated if there is no active program
 *  for the compute shader stage."
 */
-   prog = ctx->Shader.CurrentProgram[MESA_SHADER_COMPUTE];
+   prog = ctx->_Shader->CurrentProgram[MESA_SHADER_COMPUTE];
if (prog == NULL || prog->_LinkedShaders[MESA_SHADER_COMPUTE] == NULL) {
   _mesa_error(ctx, GL_INVALID_OPERATION,
   "%s(no active compute shader)",
diff --git a/src/mesa/main/pipelineobj.c b/src/mesa/main/pipelineobj.c
index c8c50fa..58730f4 100644
--- a/src/mesa/main/pipelineobj.c
+++ b/src/mesa/main/pipelineobj.c
@@ -255,6 +255,8 @@ _mesa_UseProgramStages(GLuint pipeline, GLbitfield stages, 
GLuint program)
if (_mesa_has_tessellation(ctx))
   any_valid_stages |= GL_TESS_CONTROL_SHADER_BIT |
   GL_TESS_EVALUATION_SHADER_BIT;
+   if (_mesa_has_compute_shaders(ctx))
+  any_valid_stages |= GL_COMPUTE_SHADER_BIT;
 
if (stages != GL_ALL_SHADER_BITS && (stages & ~any_valid_stages) != 0) {
   _mesa_error(ctx, GL_INVALID_VALUE, "glUseProgramStages(Stages)");
@@ -336,6 +338,9 @@ _mesa_UseProgramStages(GLuint pipeline, GLbitfield stages, 
GLuint program)
 
if ((stages & GL_TESS_EVALUATION_SHADER_BIT) != 0)
   _mesa_use_shader_program(ctx, GL_TESS_EVALUATION_SHADER, shProg, pipe);
+
+   if ((stages & GL_COMPUTE_SHADER_BIT) != 0)
+  _mesa_use_shader_program(ctx, GL_COMPUTE_SHADER, shProg, pipe);
 }
 
 /**
@@ -669,6 +674,12 @@ _mesa_GetProgramPipelineiv(GLuint pipeline, GLenum pname, 
GLint *params)
   *params = pipe->CurrentProgram[MESA_SHADER_FRAGMENT]
  ? pipe->CurrentProgram[MESA_SHADER_FRAGMENT]->Name : 0;
   return;
+   case GL_COMPUTE_SHADER:
+  if (!_mesa_has_compute_shaders(ctx))
+ break;
+  *params = pipe->CurrentProgram[MESA_SHADER_COMPUTE]
+ ? pipe->CurrentProgram[MESA_SHADER_COMPUTE]->Name : 0;
+  return;
default:
   break;
}
-- 
2.5.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v3] r600g: Fix special negative immediate constants when using ABS modifier.

2015-10-29 Thread Nicolai Hähnle

On 29.10.2015 01:52, Ivan Kalvachev wrote:

-- Forwarded message --
From: Ivan Kalvachev 
Date: Wed, 28 Oct 2015 23:46:44 +0200
Subject: [PATCH v3] r600g: Fix special negative immediate constants
when using ABS modifier.
To: Nicolai Hähnle 

On 10/26/15, Nicolai Hähnle  wrote:

Hi Ivan,

On 25.10.2015 02:00, Ivan Kalvachev wrote:

Some constants (like 1.0 and 0.5) could be inlined as immediate inputs
without using their literal value. The r600_bytecode_special_constants()
function emulates the negative of these constants by using NEG modifier.

However some shaders define -1.0 constant and want to use it as 1.0.
They do so by using ABS modifier. But r600_bytecode_special_constants()
set NEG in addition to ABS. Since NEG modifier have priority over ABS
one,
we get -|1.0| as result, instead of |1.0|.

The patch simply prevents the additional switching of NEG when ABS is
set.


Nice catch. Is there a simple test case (e.g. in piglit) that exposes
the incorrect behavior?


Not that I know of.

I've located the bug investigating visual problem in Nine.
https://github.com/iXit/Mesa-3D/issues/126
https://github.com/iXit/Mesa-3D/issues/127

I also heard that it fixes artifacts in "Need for Speed: Undercover"
and "Skyrim", once again, when using Nine.


I see. I guess it's not too surprising that Nine creates shaders that 
look a bit different from the Mesa statetracker's.


Reviewed-by: Nicolai Hähnle 

This should probably also go to stable.

Do you need somebody to push this for you or can you do it yourself?

Cheers,
Nicolai


Signed-off-by: Ivan Kalvachev 
---
   src/gallium/drivers/r600/r600_asm.c| 9 +
   src/gallium/drivers/r600/r600_shader.c | 2 +-
   2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/src/gallium/drivers/r600/r600_asm.c
b/src/gallium/drivers/r600/r600_asm.c
index bc69806..8fc622c 100644
--- a/src/gallium/drivers/r600/r600_asm.c
+++ b/src/gallium/drivers/r600/r600_asm.c
@@ -635,8 +635,9 @@ static int replace_gpr_with_pv_ps(struct r600_bytecode
*bc,
  return 0;
   }

-void r600_bytecode_special_constants(uint32_t value, unsigned *sel,
unsigned *neg)
+void r600_bytecode_special_constants(uint32_t value, unsigned *sel,
unsigned *neg, unsigned abs)
   {
+


Please remove the extra whitespace line.

Cheers,
Nicolai



I'm attaching v3 of the patch. Same as v2, but without the extra empty line.

Best Regards



___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev



___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 2/3] nvc0/ir: add support for PK2H/UP2H

2015-10-29 Thread Ilia Mirkin
Signed-off-by: Ilia Mirkin 
---
 .../drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp |  1 +
 .../drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp  |  5 -
 .../drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp  | 24 ++
 3 files changed, 29 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
index a327d57..01da535 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
@@ -736,6 +736,7 @@ CodeEmitterGM107::emitF2F()
emitCC   (0x2f);
emitField(0x2d, 1, (insn->op == OP_NEG) || insn->src(0).mod.neg());
emitFMZ  (0x2c, 1);
+   emitField(0x29, 1, insn->subOp);
emitRND  (0x27, rnd, 0x2a);
emitField(0x0a, 2, util_logbase2(typeSizeof(insn->sType)));
emitField(0x08, 2, util_logbase2(typeSizeof(insn->dType)));
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
index fd10314..de30c62 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
@@ -1022,7 +1022,10 @@ CodeEmitterNVC0::emitCVT(Instruction *i)
 
   // for 8/16 source types, the byte/word is in subOp. word 1 is
   // represented as 2.
-  code[1] |= i->subOp << 0x17;
+  if (!isFloatType(i->sType))
+ code[1] |= i->subOp << 0x17;
+  else
+ code[1] |= i->subOp << 0x18;
 
   if (sat)
  code[0] |= 0x20;
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
index 17e02a8..bea2d66 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
@@ -319,6 +319,10 @@ unsigned int Instruction::srcMask(unsigned int s) const
  x |= 2;
   return x;
}
+   case TGSI_OPCODE_PK2H:
+  return 0x3;
+   case TGSI_OPCODE_UP2H:
+  return 0x1;
default:
   break;
}
@@ -448,6 +452,7 @@ nv50_ir::DataType Instruction::inferSrcType() const
case TGSI_OPCODE_ATOMUMAX:
case TGSI_OPCODE_UBFE:
case TGSI_OPCODE_UMSB:
+   case TGSI_OPCODE_UP2H:
   return nv50_ir::TYPE_U32;
case TGSI_OPCODE_I2F:
case TGSI_OPCODE_I2D:
@@ -512,10 +517,12 @@ nv50_ir::DataType Instruction::inferDstType() const
case TGSI_OPCODE_DSGE:
case TGSI_OPCODE_DSLT:
case TGSI_OPCODE_DSNE:
+   case TGSI_OPCODE_PK2H:
   return nv50_ir::TYPE_U32;
case TGSI_OPCODE_I2F:
case TGSI_OPCODE_U2F:
case TGSI_OPCODE_D2F:
+   case TGSI_OPCODE_UP2H:
   return nv50_ir::TYPE_F32;
case TGSI_OPCODE_I2D:
case TGSI_OPCODE_U2D:
@@ -2801,6 +2808,23 @@ Converter::handleInstruction(const struct 
tgsi_full_instruction *insn)
   FOR_EACH_DST_ENABLED_CHANNEL(0, c, tgsi)
  mkCvt(OP_CVT, dstTy, dst0[c], srcTy, fetchSrc(0, c));
   break;
+   case TGSI_OPCODE_PK2H:
+  val0 = getScratch();
+  val1 = getScratch();
+  mkCvt(OP_CVT, TYPE_F16, val0, TYPE_F32, fetchSrc(0, 0));
+  mkCvt(OP_CVT, TYPE_F16, val1, TYPE_F32, fetchSrc(0, 1));
+  mkOp2(OP_SHL, TYPE_U32, val1, val1, loadImm(NULL, 16));
+  mkOp2(OP_OR, TYPE_U32, dst0[0], val0, val1);
+  break;
+   case TGSI_OPCODE_UP2H:
+  src0 = fetchSrc(0, 0);
+  if (dst0[0])
+ mkCvt(OP_CVT, TYPE_F32, dst0[0], TYPE_F16, src0);
+  if (dst0[1]) {
+ geni = mkCvt(OP_CVT, TYPE_F32, dst0[1], TYPE_F16, src0);
+ geni->subOp = 1;
+  }
+  break;
case TGSI_OPCODE_EMIT:
   /* export the saved viewport index */
   if (viewport != NULL) {
-- 
2.4.10

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 1/3] gallium: document PK2H/UP2H

2015-10-29 Thread Ilia Mirkin
Signed-off-by: Ilia Mirkin 
---
 src/gallium/docs/source/tgsi.rst | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/src/gallium/docs/source/tgsi.rst b/src/gallium/docs/source/tgsi.rst
index 01e18f3..1d19db3 100644
--- a/src/gallium/docs/source/tgsi.rst
+++ b/src/gallium/docs/source/tgsi.rst
@@ -458,7 +458,9 @@ while DDY is allowed to be the same for the entire 2x2 quad.
 
 .. opcode:: PK2H - Pack Two 16-bit Floats
 
-  TBD
+.. math::
+
+  dst.x = f32_to_f16(src.x) | f32_to_f16(src.y) << 16
 
 
 .. opcode:: PK2US - Pack Two Unsigned 16-bit Scalars
@@ -615,7 +617,11 @@ This instruction replicates its result.
 
 .. opcode:: UP2H - Unpack Two 16-Bit Floats
 
-  TBD
+.. math::
+
+  dst.x = f16\_to\_f32(src0.x & 0x)
+
+  dst.y = f16\_to\_f32(src0.x >> 16)
 
 .. note::
 
-- 
2.4.10

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 3/3] st/mesa: use PK2H/UP2H when gs5 is supported

2015-10-29 Thread Ilia Mirkin
ARB_gpu_shader5 should be a decent proxy for whether those instructions
are supported.

Signed-off-by: Ilia Mirkin 
---

Not actually ready to be committed, since r600/radeonsi need support
for these ops as well. Should be easy to implement, but want to get
the OK before I do so.

 src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp 
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index f481e89..fff18a4 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -2195,15 +2195,20 @@ glsl_to_tgsi_visitor::visit(ir_expression *ir)
   }
   break;
 
+   case ir_unop_pack_half_2x16:
+  emit_asm(ir, TGSI_OPCODE_PK2H, result_dst, op[0]);
+  break;
+   case ir_unop_unpack_half_2x16:
+  emit_asm(ir, TGSI_OPCODE_UP2H, result_dst, op[0]);
+  break;
+
case ir_unop_pack_snorm_2x16:
case ir_unop_pack_unorm_2x16:
-   case ir_unop_pack_half_2x16:
case ir_unop_pack_snorm_4x8:
case ir_unop_pack_unorm_4x8:
 
case ir_unop_unpack_snorm_2x16:
case ir_unop_unpack_unorm_2x16:
-   case ir_unop_unpack_half_2x16:
case ir_unop_unpack_half_2x16_split_x:
case ir_unop_unpack_half_2x16_split_y:
case ir_unop_unpack_snorm_4x8:
@@ -5794,13 +5799,14 @@ st_link_shader(struct gl_context *ctx, struct 
gl_shader_program *prog)
LOWER_PACK_SNORM_4x8 |
LOWER_UNPACK_SNORM_4x8 |
LOWER_UNPACK_UNORM_4x8 |
-   LOWER_PACK_UNORM_4x8 |
-   LOWER_PACK_HALF_2x16 |
-   LOWER_UNPACK_HALF_2x16;
+   LOWER_PACK_UNORM_4x8;
 
  if (ctx->Extensions.ARB_gpu_shader5)
 lower_inst |= LOWER_PACK_USE_BFI |
   LOWER_PACK_USE_BFE;
+ else
+lower_inst |= LOWER_PACK_HALF_2x16 |
+  LOWER_UNPACK_HALF_2x16;
 
  lower_packing_builtins(ir, lower_inst);
   }
-- 
2.4.10

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 3/3] st/mesa: use PK2H/UP2H when gs5 is supported

2015-10-29 Thread Ilia Mirkin
On Thu, Oct 29, 2015 at 2:52 AM, Ilia Mirkin  wrote:
> ARB_gpu_shader5 should be a decent proxy for whether those instructions
> are supported.
>
> Signed-off-by: Ilia Mirkin 
> ---
>
> Not actually ready to be committed, since r600/radeonsi need support
> for these ops as well. Should be easy to implement, but want to get
> the OK before I do so.

Oh, and to pre-empt the question of "why not the other pack/unpack
primitives", it's because nouveau codegen is able to optimize them
into reasonable forms (it does better with unpack than with pack), esp
after I adjusted the lowering passes to use BFI/BFE. Not ideal, but
the manual f32 <-> f16 stuff was a bit much. I wouldn't be opposed to
the other opcodes getting added too, just didn't seem too important.

>
>  src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 16 +++-
>  1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp 
> b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> index f481e89..fff18a4 100644
> --- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> +++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> @@ -2195,15 +2195,20 @@ glsl_to_tgsi_visitor::visit(ir_expression *ir)
>}
>break;
>
> +   case ir_unop_pack_half_2x16:
> +  emit_asm(ir, TGSI_OPCODE_PK2H, result_dst, op[0]);
> +  break;
> +   case ir_unop_unpack_half_2x16:
> +  emit_asm(ir, TGSI_OPCODE_UP2H, result_dst, op[0]);
> +  break;
> +
> case ir_unop_pack_snorm_2x16:
> case ir_unop_pack_unorm_2x16:
> -   case ir_unop_pack_half_2x16:
> case ir_unop_pack_snorm_4x8:
> case ir_unop_pack_unorm_4x8:
>
> case ir_unop_unpack_snorm_2x16:
> case ir_unop_unpack_unorm_2x16:
> -   case ir_unop_unpack_half_2x16:
> case ir_unop_unpack_half_2x16_split_x:
> case ir_unop_unpack_half_2x16_split_y:
> case ir_unop_unpack_snorm_4x8:
> @@ -5794,13 +5799,14 @@ st_link_shader(struct gl_context *ctx, struct 
> gl_shader_program *prog)
> LOWER_PACK_SNORM_4x8 |
> LOWER_UNPACK_SNORM_4x8 |
> LOWER_UNPACK_UNORM_4x8 |
> -   LOWER_PACK_UNORM_4x8 |
> -   LOWER_PACK_HALF_2x16 |
> -   LOWER_UNPACK_HALF_2x16;
> +   LOWER_PACK_UNORM_4x8;
>
>   if (ctx->Extensions.ARB_gpu_shader5)
>  lower_inst |= LOWER_PACK_USE_BFI |
>LOWER_PACK_USE_BFE;
> + else
> +lower_inst |= LOWER_PACK_HALF_2x16 |
> +  LOWER_UNPACK_HALF_2x16;
>
>   lower_packing_builtins(ir, lower_inst);
>}
> --
> 2.4.10
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] i965: Setup pull constant state for compute programs

2015-10-29 Thread Jordan Justen
Signed-off-by: Jordan Justen 
---
 src/mesa/drivers/dri/i965/brw_context.h  |  2 +-
 src/mesa/drivers/dri/i965/brw_state.h|  1 +
 src/mesa/drivers/dri/i965/brw_state_upload.c |  2 ++
 src/mesa/drivers/dri/i965/gen7_cs_state.c| 32 
 4 files changed, 36 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
b/src/mesa/drivers/dri/i965/brw_context.h
index 18c361e..887b57b 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -1177,7 +1177,7 @@ struct brw_context
 
int num_atoms[BRW_NUM_PIPELINES];
const struct brw_tracked_state render_atoms[60];
-   const struct brw_tracked_state compute_atoms[8];
+   const struct brw_tracked_state compute_atoms[9];
 
/* If (INTEL_DEBUG & DEBUG_BATCH) */
struct {
diff --git a/src/mesa/drivers/dri/i965/brw_state.h 
b/src/mesa/drivers/dri/i965/brw_state.h
index dc2b941..2c7c2f3 100644
--- a/src/mesa/drivers/dri/i965/brw_state.h
+++ b/src/mesa/drivers/dri/i965/brw_state.h
@@ -49,6 +49,7 @@ extern const struct brw_tracked_state brw_clip_unit;
 extern const struct brw_tracked_state brw_vs_pull_constants;
 extern const struct brw_tracked_state brw_gs_pull_constants;
 extern const struct brw_tracked_state brw_wm_pull_constants;
+extern const struct brw_tracked_state brw_cs_pull_constants;
 extern const struct brw_tracked_state brw_constant_buffer;
 extern const struct brw_tracked_state brw_curbe_offsets;
 extern const struct brw_tracked_state brw_invariant_state;
diff --git a/src/mesa/drivers/dri/i965/brw_state_upload.c 
b/src/mesa/drivers/dri/i965/brw_state_upload.c
index 79b8301..0344b8a 100644
--- a/src/mesa/drivers/dri/i965/brw_state_upload.c
+++ b/src/mesa/drivers/dri/i965/brw_state_upload.c
@@ -259,6 +259,7 @@ static const struct brw_tracked_state *gen7_compute_atoms[] 
=
_state_base_address,
_cs_image_surfaces,
_cs_push_constants,
+   _cs_pull_constants,
_cs_ubo_surfaces,
_cs_abo_surfaces,
_texture_surfaces,
@@ -353,6 +354,7 @@ static const struct brw_tracked_state *gen8_compute_atoms[] 
=
_state_base_address,
_cs_image_surfaces,
_cs_push_constants,
+   _cs_pull_constants,
_cs_ubo_surfaces,
_cs_abo_surfaces,
_texture_surfaces,
diff --git a/src/mesa/drivers/dri/i965/gen7_cs_state.c 
b/src/mesa/drivers/dri/i965/gen7_cs_state.c
index 6aeb0cb..da1d05f 100644
--- a/src/mesa/drivers/dri/i965/gen7_cs_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_cs_state.c
@@ -29,6 +29,7 @@
 #include "brw_shader.h"
 #include "intel_mipmap_tree.h"
 #include "intel_batchbuffer.h"
+#include "intel_buffer_objects.h"
 #include "brw_state.h"
 
 static unsigned
@@ -285,3 +286,34 @@ const struct brw_tracked_state gen7_cs_push_constants = {
},
.emit = gen7_upload_cs_push_constants,
 };
+
+/**
+ * Creates a new CS constant buffer reflecting the current CS program's
+ * constants, if needed by the CS program.
+ */
+static void
+brw_upload_cs_pull_constants(struct brw_context *brw)
+{
+   struct brw_stage_state *stage_state = >cs.base;
+
+   /* BRW_NEW_COMPUTE_PROGRAM */
+   struct brw_compute_program *cp =
+  (struct brw_compute_program *) brw->compute_program;
+
+   /* BRW_NEW_CS_PROG_DATA */
+   const struct brw_stage_prog_data *prog_data = >cs.prog_data->base;
+
+   /* _NEW_PROGRAM_CONSTANTS */
+   brw_upload_pull_constants(brw, BRW_NEW_SURFACES, >program.Base,
+ stage_state, prog_data, true);
+}
+
+const struct brw_tracked_state brw_cs_pull_constants = {
+   .dirty = {
+  .mesa = _NEW_PROGRAM_CONSTANTS,
+  .brw = BRW_NEW_BATCH |
+ BRW_NEW_COMPUTE_PROGRAM |
+ BRW_NEW_CS_PROG_DATA,
+   },
+   .emit = brw_upload_cs_pull_constants,
+};
-- 
2.5.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] main/get: Add MAX_COMBINED_COMPUTE_UNIFORM_COMPONENTS

2015-10-29 Thread Jordan Justen
Signed-off-by: Jordan Justen 
---
 src/mesa/main/get_hash_params.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/mesa/main/get_hash_params.py b/src/mesa/main/get_hash_params.py
index c295615..fbc7b8f 100644
--- a/src/mesa/main/get_hash_params.py
+++ b/src/mesa/main/get_hash_params.py
@@ -460,6 +460,7 @@ descriptor=[
   [ "MAX_COMPUTE_UNIFORM_COMPONENTS", "CONST(MAX_COMPUTE_UNIFORM_COMPONENTS), 
extra_ARB_compute_shader_es31" ],
   [ "MAX_COMPUTE_IMAGE_UNIFORMS", "CONST(MAX_COMPUTE_IMAGE_UNIFORMS), 
extra_ARB_compute_shader_es31" ],
   [ "DISPATCH_INDIRECT_BUFFER_BINDING", "LOC_CUSTOM, TYPE_INT, 0, 
extra_ARB_compute_shader_es31" ],
+  [ "MAX_COMBINED_COMPUTE_UNIFORM_COMPONENTS", 
"CONTEXT_INT(Const.Program[MESA_SHADER_COMPUTE].MaxCombinedUniformComponents), 
extra_ARB_compute_shader_es31" ],
 
 # GL_ARB_framebuffer_no_attachments / GLES 3.1
   ["MAX_FRAMEBUFFER_WIDTH", "CONTEXT_INT(Const.MaxFramebufferWidth), 
extra_ARB_framebuffer_no_attachments"],
-- 
2.5.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


  1   2   >