from:"Mike Lothian"

Re: [Mesa-dev] [PATCH v3 (part2) 54/56] docs: Mark ARB_shader_storage_buffer_object as done for i965.

2015-07-14 Thread Mike Lothian

Hi Iago

Nice work, was it an oversight this wasn't enabled for GLES 3.1? Or is the
implementation slightly different?

Cheers

Mike

On Tue, 14 Jul 2015 at 08:48 Iago Toral Quiroga  wrote:

> ---
>  docs/GL3.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/docs/GL3.txt b/docs/GL3.txt
> index 33a282e..6427616 100644
> --- a/docs/GL3.txt
> +++ b/docs/GL3.txt
> @@ -164,7 +164,7 @@ GL 4.3, GLSL 4.30:
>GL_ARB_program_interface_query   DONE (all drivers)
>GL_ARB_robust_buffer_access_behavior not started
>GL_ARB_shader_image_size in progress
> (Martin Peres)
> -  GL_ARB_shader_storage_buffer_object  in progress (Iago
> Toral, Samuel Iglesias)
> +  GL_ARB_shader_storage_buffer_object  DONE (i965)
>GL_ARB_stencil_texturing DONE (i965/gen8+,
> nv50, nvc0, r600, radeonsi, llvmpipe, softpipe)
>GL_ARB_texture_buffer_range  DONE (nv50, nvc0,
> i965, r600, radeonsi, llvmpipe)
>GL_ARB_texture_query_levels  DONE (all drivers
> that support GLSL 1.30)
> --
> 1.9.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

Re: [Mesa-dev] [PATCH v2] gallium/hud: control visibility at startup and runtime.

2015-11-04 Thread Mike Lothian

Hi

On Wed, 4 Nov 2015, 8:53 a.m. Samuel Pitoiset 
wrote:

Hi Jimmy,

Some comments below.

On 11/04/2015 06:17 AM, Jimmy Berry wrote:
> - env GALLIUM_HUD_VISIBLE: control default visibility
> - env GALLIUM_HUD_SIGNAL_TOGGLE: toggle visibility via signal
> ---
> Thanks for the feedback.
>
> I believe all the suggested changes have been implemented.
>
> One note, all the logic except for the toggle was already in hud_create()
and
> not hud_draw().
>
> On the subject of allowing the user to specify the signo to use. It was
> suggested in the original thread that using a fixed signal might end up
stealing
> signals from the parent application. Seems like the user should except
funny
> behavior if they set the signal to something like SIGKILL. I am not
opposed to a
> fixed signo or alternatively providing a default. Something like:
>
> GALLIUM_HUD_TOGGLE_SIGNAL=-1 # (results in SIGUSR1)
>
>
>   docs/envvars.html   |  6 ++
>   src/gallium/auxiliary/hud/hud_context.c | 29
+
>   2 files changed, 35 insertions(+)
>
> diff --git a/docs/envvars.html b/docs/envvars.html
> index bdfe999..530bbb7 100644
> --- a/docs/envvars.html
> +++ b/docs/envvars.html
> @@ -179,6 +179,12 @@ Mesa EGL supports different sets of environment
variables.  See the
>   GALLIUM_HUD - draws various information on the screen, like
framerate,
>   cpu load, driver statistics, performance counters, etc.
>   Set GALLIUM_HUD=help and run e.g. glxgears for more info.
> +GALLIUM_HUD_VISIBLE - control default visibility, defaults to true.
> +GALLIUM_HUD_TOGGLE_SIGNAL - toggle visibility via user specified
signal.
> +Especially useful to toggle hud at specific points of application and
> +disable for unencumbered viewing the rest of the time. For example,
set
> +GALLIUM_HUD_VISIBLE to false and GALLIUM_HUD_SIGNAL_TOGGLE to 10
(SIGUSR1).
> +Use kill -10  to toggle the hud as desired.
>   GALLIUM_LOG_FILE - specifies a file for logging all errors,
warnings, etc.
>   rather than stderr.
>   GALLIUM_PRINT_OPTIONS - if non-zero, print all the Gallium
environment
> diff --git a/src/gallium/auxiliary/hud/hud_context.c
b/src/gallium/auxiliary/hud/hud_context.c
> index ffe30b8..bffbc2f 100644
> --- a/src/gallium/auxiliary/hud/hud_context.c
> +++ b/src/gallium/auxiliary/hud/hud_context.c
> @@ -33,6 +33,7 @@
>* Set GALLIUM_HUD=help for more info.
>*/
>
> +#include 
>   #include 
>
>   #include "hud/hud_context.h"
> @@ -51,6 +52,8 @@
>   #include "tgsi/tgsi_text.h"
>   #include "tgsi/tgsi_dump.h"
>
> +/* controlls the visibility of all hud contexts */

"Control the visibility of all HUD contexts"

> +static boolean huds_visible = TRUE;

Maybe, hud_is_hidden or something looks like a better name.

I'd have thought keeping the boolean TRUE/1 for the hud being on would make
more sense

>
>   struct hud_context {
>  struct pipe_context *pipe;
> @@ -95,6 +98,11 @@ struct hud_context {
>  } text, bg, whitelines;
>   };
>
> +static void
> +signal_visible_handler(int sig, siginfo_t *siginfo, void *context)
> +{
> +   huds_visible = !huds_visible;
> +}
>
>   static void
>   hud_draw_colored_prims(struct hud_context *hud, unsigned prim,
> @@ -441,6 +449,9 @@ hud_draw(struct hud_context *hud, struct
pipe_resource *tex)
>  struct hud_pane *pane;
>  struct hud_graph *gr;
>
> +   if (!huds_visible)
> +  return;
> +
>  hud->fb_width = tex->width0;
>  hud->fb_height = tex->height0;
>  hud->constants.two_div_fb_width = 2.0f / hud->fb_width;
> @@ -1125,6 +1136,10 @@ hud_create(struct pipe_context *pipe, struct
cso_context *cso)
>  struct pipe_sampler_view view_templ;
>  unsigned i;
>  const char *env = debug_get_option("GALLIUM_HUD", NULL);
> +   long signo = debug_get_num_option("GALLIUM_HUD_TOGGLE_SIGNAL", 0);
> +   boolean sig_handled = FALSE;
> +   struct sigaction action;
> +   huds_visible = debug_get_bool_option("GALLIUM_HUD_VISIBLE", TRUE);
>
>  if (!env || !*env)
> return NULL;
> @@ -1267,6 +1282,20 @@ hud_create(struct pipe_context *pipe, struct
cso_context *cso)
>
>  LIST_INITHEAD(&hud->pane_list);
>
> +   /* setup sig handler once for all hud contexts */
> +   if (!sig_handled) {
> +  memset(&action, 0, sizeof(action));

I think you can get rid of this memset() by doing 'struct sigaction
action = {};' above.

> +  action.sa_sigaction = &signal_visible_handler;
> +  action.sa_flags = SA_SIGINFO;
> +
> +  if (signo < 1 || signo >= NSIG)
> + fprintf(stderr, "gallium_hud: invalid signal %ld\n", signo);
> +  else if (sigaction(signo, &action, NULL) < 0)
> + fprintf(stderr, "gallium_hud: unable to set handler for signal
%ld\n", signo);
> +
> +  sig_handled = TRUE;
> +   }
> +
>  hud_parse_env_var(hud, env);
>  return hud;
>   }
>

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

Re: [Mesa-dev] [PATCH 2/2] vulkan/wsi/radv: add initial prime support

2017-02-20 Thread Mike Lothian

Feel free to add my "Tested by" to these

Tested with vulkaninfo, vulkancube, vulkanscene and The Talos
Principle 32bit & 64bit

Cheers

Mike

On 21 February 2017 at 02:26, Dave Airlie  wrote:
> From: Dave Airlie 
>
> This is a complete rewrite of my previous rfc patches.
>
> This adds the ability to present to a different GPU that rendering
> using a driver side operation that can copy from the tiled to
> linear shared image.
>
> This does prime support completely in the swapchain present code,
> and each queue has a precreated command buffer for each image
> and for the each queue family. This means presenting should work
> on graphics and compute queues and transfer in the future.
>
> Signed-off-by: Dave Airlie 
> ---
>  src/amd/vulkan/radv_meta.h  |   3 +
>  src/amd/vulkan/radv_meta_copy.c |  20 ++
>  src/amd/vulkan/radv_wsi.c   | 136 
> +---
>  src/amd/vulkan/radv_wsi_x11.c   |   4 +-
>  src/intel/vulkan/anv_wsi.c  |   5 +-
>  src/intel/vulkan/anv_wsi_x11.c  |   4 +-
>  src/vulkan/wsi/wsi_common.h |   8 +++
>  src/vulkan/wsi/wsi_common_wayland.c |   4 ++
>  src/vulkan/wsi/wsi_common_x11.c |  59 ++--
>  src/vulkan/wsi/wsi_common_x11.h |   1 +
>  10 files changed, 223 insertions(+), 21 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_meta.h b/src/amd/vulkan/radv_meta.h
> index 8eb3df3..d70fef1 100644
> --- a/src/amd/vulkan/radv_meta.h
> +++ b/src/amd/vulkan/radv_meta.h
> @@ -208,6 +208,9 @@ void radv_meta_resolve_compute_image(struct 
> radv_cmd_buffer *cmd_buffer,
>  uint32_t region_count,
>  const VkImageResolve *regions);
>
> +void radv_blit_to_prime_linear(struct radv_cmd_buffer *cmd_buffer,
> +  struct radv_image *image,
> +  struct radv_image *linear_image);
>  #ifdef __cplusplus
>  }
>  #endif
> diff --git a/src/amd/vulkan/radv_meta_copy.c b/src/amd/vulkan/radv_meta_copy.c
> index 2bd20b5..5473764 100644
> --- a/src/amd/vulkan/radv_meta_copy.c
> +++ b/src/amd/vulkan/radv_meta_copy.c
> @@ -430,3 +430,23 @@ void radv_CmdCopyImage(
> meta_copy_image(cmd_buffer, src_image, dest_image,
> regionCount, pRegions);
>  }
> +
> +void radv_blit_to_prime_linear(struct radv_cmd_buffer *cmd_buffer,
> +  struct radv_image *image,
> +  struct radv_image *linear_image)
> +{
> +   struct VkImageCopy image_copy = { 0 };
> +
> +   image_copy.srcSubresource.aspectMask = VK_IMAGE_ASPECT_COLOR_BIT;
> +   image_copy.srcSubresource.layerCount = 1;
> +
> +   image_copy.dstSubresource.aspectMask = VK_IMAGE_ASPECT_COLOR_BIT;
> +   image_copy.dstSubresource.layerCount = 1;
> +
> +   image_copy.extent.width = image->extent.width;
> +   image_copy.extent.height = image->extent.height;
> +   image_copy.extent.depth = 1;
> +
> +   meta_copy_image(cmd_buffer, image, linear_image,
> +   1, &image_copy);
> +}
> diff --git a/src/amd/vulkan/radv_wsi.c b/src/amd/vulkan/radv_wsi.c
> index ea8e784..4d0168f 100644
> --- a/src/amd/vulkan/radv_wsi.c
> +++ b/src/amd/vulkan/radv_wsi.c
> @@ -24,6 +24,7 @@
>   */
>
>  #include "radv_private.h"
> +#include "radv_meta.h"
>  #include "wsi_common.h"
>
>  static const struct wsi_callbacks wsi_cbs = {
> @@ -92,7 +93,7 @@ VkResult radv_GetPhysicalDeviceSurfaceSupportKHR(
>
> return iface->get_support(surface, &device->wsi_device,
>   &device->instance->alloc,
> - queueFamilyIndex, device->local_fd, 
> pSupported);
> + queueFamilyIndex, device->local_fd, true, 
> pSupported);
>  }
>
>  VkResult radv_GetPhysicalDeviceSurfaceCapabilitiesKHR(
> @@ -139,6 +140,8 @@ static VkResult
>  radv_wsi_image_create(VkDevice device_h,
>   const VkSwapchainCreateInfoKHR *pCreateInfo,
>   const VkAllocationCallbacks* pAllocator,
> + bool needs_linear_copy,
> + bool linear,
>   VkImage *image_p,
>   VkDeviceMemory *memory_p,
>   uint32_t *size,
> @@ -169,7 +172,7 @@ radv_wsi_image_create(VkDevice device_h,
>.arrayLayers = 1,
>.samples = 1,
>/* FIXME: Need a way to 
> use X tiling to allow scanout */
> -  .tiling = 
> VK_IMAGE_TILING_OPTIMAL,
> +  .tiling = linear ? 
> VK_IMAGE_TILING_LINEAR : VK_IMAGE_TILING_OPTIMAL,
>.usage = 
> VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT,
>

Re: [Mesa-dev] [PATCH v2 5/6] anv/Makefile: alphabetize

2017-02-21 Thread Mike Lothian

Should genX_blorp be above genX_cmd?

On Mon, 20 Feb 2017 at 19:26 Jason Ekstrand  wrote:

> ---
>  src/intel/vulkan/Makefile.sources | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/src/intel/vulkan/Makefile.sources
> b/src/intel/vulkan/Makefile.sources
> index bd78805..b99 100644
> --- a/src/intel/vulkan/Makefile.sources
> +++ b/src/intel/vulkan/Makefile.sources
> @@ -63,33 +63,33 @@ VULKAN_GENERATED_FILES := \
>
>
>  GEN7_FILES := \
> +   gen7_cmd_buffer.c \
> genX_cmd_buffer.c \
> genX_blorp_exec.c \
> genX_gpu_memcpy.c \
> genX_pipeline.c \
> -   gen7_cmd_buffer.c \
> genX_state.c
>
>  GEN75_FILES := \
> +   gen7_cmd_buffer.c \
> genX_cmd_buffer.c \
> genX_blorp_exec.c \
> genX_gpu_memcpy.c \
> genX_pipeline.c \
> -   gen7_cmd_buffer.c \
> genX_state.c
>
>  GEN8_FILES := \
> +   gen8_cmd_buffer.c \
> genX_cmd_buffer.c \
> genX_blorp_exec.c \
> genX_gpu_memcpy.c \
> genX_pipeline.c \
> -   gen8_cmd_buffer.c \
> genX_state.c
>
>  GEN9_FILES := \
> +   gen8_cmd_buffer.c \
> genX_cmd_buffer.c \
> genX_blorp_exec.c \
> genX_gpu_memcpy.c \
> genX_pipeline.c \
> -   gen8_cmd_buffer.c \
> genX_state.c
> --
> 2.5.0.400.gff86faf
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] vulkan: Fix gen_enum_to_str in out of tree builds

2017-02-22 Thread Mike Lothian

This fixes the build for me and I've tested vulkan programs still work

Reviewed-and-Tested-by: Mike Lothian 

On 23 February 2017 at 00:38, Dylan Baker  wrote:
> In some configurations the util directory is created when building out
> of tree, but not others. This patch ensures that it's created.
>
> cc: Matt Turner 
> Signed-off-by: Dylan Baker 
> ---
>  src/vulkan/Makefile.am | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/src/vulkan/Makefile.am b/src/vulkan/Makefile.am
> index fa72d63d65..5cdffbf901 100644
> --- a/src/vulkan/Makefile.am
> +++ b/src/vulkan/Makefile.am
> @@ -5,6 +5,9 @@ noinst_LTLIBRARIES = libvulkan_wsi.la libvulkan_util.la
>  vulkan_includedir = $(includedir)/vulkan
>  vulkan_api_xml = $(top_srcdir)/src/vulkan/registry/vk.xml
>
> +MKDIR_GEN = $(AM_V_at)$(MKDIR_P) $(@D)
> +PYTHON_GEN = $(AM_V_GEN)$(PYTHON2) $(PYTHON_FLAGS)
> +
>  EXTRA_DIST = \
> util/gen_enum_to_str.py
>
> @@ -13,7 +16,8 @@ BUILT_SOURCES = \
> util/vk_enum_to_str.h
>
>  util/vk_enum_to_str.c util/vk_enum_to_str.h: util/gen_enum_to_str.py 
> $(vulkan_api_xml)
> -   $(AM_V_GEN)$(PYTHON2) $(srcdir)/util/gen_enum_to_str.py
> +   $(MKDIR_GEN)
> +   $(PYTHON_GEN) $(srcdir)/util/gen_enum_to_str.py
>
>  libvulkan_util_la_SOURCES = $(VULKAN_UTIL_FILES)
>
> --
> 2.11.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Mesa git: compilation error in NINE after your latest commit - 'PIPE_CAP_USER_INDEX_BUFFERS' undeclared

2017-02-24 Thread Mike Lothian

I've got a patch for this, just testing it now

On Sat, 25 Feb 2017 at 00:10 Dieter Nützel  wrote:

> Making all in state_trackers/nine
> make[4]: Entering directory '/opt/mesa/src/gallium/state_trackers/nine'
>CC   device9.lo
> device9.c: In function 'NineDevice9_ctor':
> device9.c:122:49: error: 'PIPE_CAP_USER_INDEX_BUFFERS' undeclared (first
> use in this function)
>   #define GET_PCAP(n) pScreen->get_param(pScreen, PIPE_CAP_##n)
>   ^
> device9.c:476:36: note: in expansion of macro 'GET_PCAP'
>   This->driver_caps.user_ibufs = GET_PCAP(USER_INDEX_BUFFERS) &&
> !This->csmt_active;
>  ^
> device9.c:122:49: note: each undeclared identifier is reported only once
> for each function it appears in
>   #define GET_PCAP(n) pScreen->get_param(pScreen, PIPE_CAP_##n)
>   ^
> device9.c:476:36: note: in expansion of macro 'GET_PCAP'
>   This->driver_caps.user_ibufs = GET_PCAP(USER_INDEX_BUFFERS) &&
> !This->csmt_active;
>  ^
> Makefile:745: recipe for target 'device9.lo' failed
> make[4]: *** [device9.lo] Error 1
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] st/nine: Remove code for no USER_INDEX_BUFFERS as these are always on

2017-02-24 Thread Mike Lothian

This fixes 4a883966c1f74f43afc145d2c3d27af7b8c5e01a where the pipe cap
was removed

Now USER_INDEX_BUFFERS are always enabled remove code that checks for
them and works around them not being available

Signed-off-by: Mike Lothian 
Cc: Marek Olšák 
Cc: Axel Davy 
---
 src/gallium/state_trackers/nine/device9.c | 17 -
 1 file changed, 17 deletions(-)

diff --git a/src/gallium/state_trackers/nine/device9.c 
b/src/gallium/state_trackers/nine/device9.c
index b9b7a637d7..2217cc9d0c 100644
--- a/src/gallium/state_trackers/nine/device9.c
+++ b/src/gallium/state_trackers/nine/device9.c
@@ -473,7 +473,6 @@ NineDevice9_ctor( struct NineDevice9 *This,
 /* Allocate upload helper for drivers that suck (from st pov ;). */
 
 This->driver_caps.user_vbufs = GET_PCAP(USER_VERTEX_BUFFERS) && 
!This->csmt_active;
-This->driver_caps.user_ibufs = GET_PCAP(USER_INDEX_BUFFERS) && 
!This->csmt_active;
 This->driver_caps.user_cbufs = GET_PCAP(USER_CONSTANT_BUFFERS);
 This->driver_caps.user_sw_vbufs = 
This->screen_sw->get_param(This->screen_sw, PIPE_CAP_USER_VERTEX_BUFFERS);
 This->driver_caps.user_sw_cbufs = 
This->screen_sw->get_param(This->screen_sw, PIPE_CAP_USER_CONSTANT_BUFFERS);
@@ -488,11 +487,6 @@ NineDevice9_ctor( struct NineDevice9 *This,
 PIPE_BIND_VERTEX_BUFFER, 
PIPE_USAGE_STREAM);
 This->vertex_sw_uploader = u_upload_create(This->pipe_sw, 65536,
 PIPE_BIND_VERTEX_BUFFER, 
PIPE_USAGE_STREAM);
-if (!This->driver_caps.user_ibufs)
-This->index_uploader = u_upload_create(This->csmt_active ?
-This->pipe_secondary : 
This->context.pipe,
-   128 * 1024,
-   PIPE_BIND_INDEX_BUFFER, 
PIPE_USAGE_STREAM);
 if (!This->driver_caps.user_cbufs) {
 This->constbuf_alignment = GET_PCAP(CONSTANT_BUFFER_OFFSET_ALIGNMENT);
 This->constbuf_uploader = u_upload_create(This->context.pipe, 
This->vs_const_size,
@@ -2928,17 +2922,6 @@ NineDevice9_DrawIndexedPrimitiveUP( struct NineDevice9 
*This,
 vbuf.buffer_offset -= base;
 vbuf.user_buffer = NULL;
 }
-if (!This->driver_caps.user_ibufs) {
-u_upload_data(This->index_uploader,
-  0,
-  (prim_count_to_vertex_count(PrimitiveType, 
PrimitiveCount)) * ibuf.index_size,
-  4,
-  ibuf.user_buffer,
-  &ibuf.offset,
-  &ibuf.buffer);
-u_upload_unmap(This->index_uploader);
-ibuf.user_buffer = NULL;
-}
 
 NineBeforeDraw(This);
 nine_context_draw_indexed_primitive_from_vtxbuf_idxbuf(This, PrimitiveType,
-- 
2.11.1

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

Re: [Mesa-dev] [PATCH] st/nine: Remove code for no USER_INDEX_BUFFERS as these are always on

2017-02-25 Thread Mike Lothian

Ah that's what I did first, but figured it was probably in accurate naming
after that

On Sat, 25 Feb 2017 at 08:21 Axel Davy  wrote:

> Hi Mike,
>
> We really want not to use user index buffers when csmt is active (thus
> the !This->csmt_active).
> This should be a one line patch to just remove the part
> GET_PCAP(USER_INDEX_BUFFERS)
>
> Yours,
>
> Axel Davy
>
> On 25/02/2017 06:23, Mike Lothian wrote:
> > This fixes 4a883966c1f74f43afc145d2c3d27af7b8c5e01a where the pipe cap
> > was removed
> >
> > Now USER_INDEX_BUFFERS are always enabled remove code that checks for
> > them and works around them not being available
> >
> > Signed-off-by: Mike Lothian 
> > Cc: Marek Olšák 
> > Cc: Axel Davy 
> > ---
> >   src/gallium/state_trackers/nine/device9.c | 17 -
> >   1 file changed, 17 deletions(-)
> >
> > diff --git a/src/gallium/state_trackers/nine/device9.c
> b/src/gallium/state_trackers/nine/device9.c
> > index b9b7a637d7..2217cc9d0c 100644
> > --- a/src/gallium/state_trackers/nine/device9.c
> > +++ b/src/gallium/state_trackers/nine/device9.c
> > @@ -473,7 +473,6 @@ NineDevice9_ctor( struct NineDevice9 *This,
> >   /* Allocate upload helper for drivers that suck (from st pov ;). */
> >
> >   This->driver_caps.user_vbufs = GET_PCAP(USER_VERTEX_BUFFERS) &&
> !This->csmt_active;
> > -This->driver_caps.user_ibufs = GET_PCAP(USER_INDEX_BUFFERS) &&
> !This->csmt_active;
> >   This->driver_caps.user_cbufs = GET_PCAP(USER_CONSTANT_BUFFERS);
> >   This->driver_caps.user_sw_vbufs =
> This->screen_sw->get_param(This->screen_sw, PIPE_CAP_USER_VERTEX_BUFFERS);
> >   This->driver_caps.user_sw_cbufs =
> This->screen_sw->get_param(This->screen_sw, PIPE_CAP_USER_CONSTANT_BUFFERS);
> > @@ -488,11 +487,6 @@ NineDevice9_ctor( struct NineDevice9 *This,
> >
>  PIPE_BIND_VERTEX_BUFFER, PIPE_USAGE_STREAM);
> >   This->vertex_sw_uploader = u_upload_create(This->pipe_sw, 65536,
> >   PIPE_BIND_VERTEX_BUFFER,
> PIPE_USAGE_STREAM);
> > -if (!This->driver_caps.user_ibufs)
> > -This->index_uploader = u_upload_create(This->csmt_active ?
> > -
> This->pipe_secondary : This->context.pipe,
> > -   128 * 1024,
> > -   PIPE_BIND_INDEX_BUFFER,
> PIPE_USAGE_STREAM);
> >   if (!This->driver_caps.user_cbufs) {
> >   This->constbuf_alignment =
> GET_PCAP(CONSTANT_BUFFER_OFFSET_ALIGNMENT);
> >   This->constbuf_uploader = u_upload_create(This->context.pipe,
> This->vs_const_size,
> > @@ -2928,17 +2922,6 @@ NineDevice9_DrawIndexedPrimitiveUP( struct
> NineDevice9 *This,
> >   vbuf.buffer_offset -= base;
> >   vbuf.user_buffer = NULL;
> >   }
> > -if (!This->driver_caps.user_ibufs) {
> > -u_upload_data(This->index_uploader,
> > -  0,
> > -  (prim_count_to_vertex_count(PrimitiveType,
> PrimitiveCount)) * ibuf.index_size,
> > -  4,
> > -  ibuf.user_buffer,
> > -  &ibuf.offset,
> > -  &ibuf.buffer);
> > -u_upload_unmap(This->index_uploader);
> > -ibuf.user_buffer = NULL;
> > -}
> >
> >   NineBeforeDraw(This);
> >   nine_context_draw_indexed_primitive_from_vtxbuf_idxbuf(This,
> PrimitiveType,
>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v2] st/nine: Remove check for USER_INDEX_BUFFERS use csmt_active instead

2017-02-25 Thread Mike Lothian

This fixes 4a883966c1f74f43afc145d2c3d27af7b8c5e01a where the pipe cap
was removed

Now USER_INDEX_BUFFERS are always enabled remove the check and only
check for cmst_active

v2: Axel pointed out the code was still needed when cmst was inactive,
Rebase on master too

Fixes: 4a883966c1f7 ("gallium: remove PIPE_CAP_USER_INDEX_BUFFERS")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99953
Reported-and-tested-by: Vinson Lee  (v1)
Cc: Marek Olšák 
Cc: Axel Davy 
Signed-off-by: Mike Lothian 
---
 src/gallium/state_trackers/nine/device9.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/gallium/state_trackers/nine/device9.c 
b/src/gallium/state_trackers/nine/device9.c
index c3924a21e2..30ab8deed7 100644
--- a/src/gallium/state_trackers/nine/device9.c
+++ b/src/gallium/state_trackers/nine/device9.c
@@ -473,7 +473,6 @@ NineDevice9_ctor( struct NineDevice9 *This,
 /* Allocate upload helper for drivers that suck (from st pov ;). */
 
 This->driver_caps.user_vbufs = GET_PCAP(USER_VERTEX_BUFFERS) && 
!This->csmt_active;
-This->driver_caps.user_ibufs = GET_PCAP(USER_INDEX_BUFFERS) && 
!This->csmt_active;
 This->driver_caps.user_cbufs = GET_PCAP(USER_CONSTANT_BUFFERS);
 This->driver_caps.user_sw_vbufs = 
This->screen_sw->get_param(This->screen_sw, PIPE_CAP_USER_VERTEX_BUFFERS);
 This->driver_caps.user_sw_cbufs = 
This->screen_sw->get_param(This->screen_sw, PIPE_CAP_USER_CONSTANT_BUFFERS);
@@ -2896,7 +2895,7 @@ NineDevice9_DrawIndexedPrimitiveUP( struct NineDevice9 
*This,
 vbuf.buffer_offset -= base;
 vbuf.user_buffer = NULL;
 }
-if (!This->driver_caps.user_ibufs) {
+if (!This->cmst_active) {
 u_upload_data(This->context.pipe->stream_uploader,
   0,
   (prim_count_to_vertex_count(PrimitiveType, 
PrimitiveCount)) * ibuf.index_size,
-- 
2.11.1

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

Re: [Mesa-dev] [PATCH v2] st/nine: Remove check for USER_INDEX_BUFFERS use csmt_active instead

2017-02-25 Thread Mike Lothian

There's too many negatives, not sure if this should really be "if
(This->cmst_active) {" or not

On Sat, 25 Feb 2017 at 10:42 Mike Lothian  wrote:

> This fixes 4a883966c1f74f43afc145d2c3d27af7b8c5e01a where the pipe cap
> was removed
>
> Now USER_INDEX_BUFFERS are always enabled remove the check and only
> check for cmst_active
>
> v2: Axel pointed out the code was still needed when cmst was inactive,
> Rebase on master too
>
> Fixes: 4a883966c1f7 ("gallium: remove PIPE_CAP_USER_INDEX_BUFFERS")
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99953
> Reported-and-tested-by: Vinson Lee  (v1)
> Cc: Marek Olšák 
> Cc: Axel Davy 
> Signed-off-by: Mike Lothian 
> ---
>  src/gallium/state_trackers/nine/device9.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/src/gallium/state_trackers/nine/device9.c
> b/src/gallium/state_trackers/nine/device9.c
> index c3924a21e2..30ab8deed7 100644
> --- a/src/gallium/state_trackers/nine/device9.c
> +++ b/src/gallium/state_trackers/nine/device9.c
> @@ -473,7 +473,6 @@ NineDevice9_ctor( struct NineDevice9 *This,
>  /* Allocate upload helper for drivers that suck (from st pov ;). */
>
>  This->driver_caps.user_vbufs = GET_PCAP(USER_VERTEX_BUFFERS) &&
> !This->csmt_active;
> -This->driver_caps.user_ibufs = GET_PCAP(USER_INDEX_BUFFERS) &&
> !This->csmt_active;
>  This->driver_caps.user_cbufs = GET_PCAP(USER_CONSTANT_BUFFERS);
>  This->driver_caps.user_sw_vbufs =
> This->screen_sw->get_param(This->screen_sw, PIPE_CAP_USER_VERTEX_BUFFERS);
>  This->driver_caps.user_sw_cbufs =
> This->screen_sw->get_param(This->screen_sw, PIPE_CAP_USER_CONSTANT_BUFFERS);
> @@ -2896,7 +2895,7 @@ NineDevice9_DrawIndexedPrimitiveUP( struct
> NineDevice9 *This,
>  vbuf.buffer_offset -= base;
>  vbuf.user_buffer = NULL;
>  }
> -if (!This->driver_caps.user_ibufs) {
> +if (!This->cmst_active) {
>  u_upload_data(This->context.pipe->stream_uploader,
>0,
>(prim_count_to_vertex_count(PrimitiveType,
> PrimitiveCount)) * ibuf.index_size,
> --
> 2.11.1
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallium/nine: Fix build regression

2017-02-25 Thread Mike Lothian

Are we better off just checking for cmst_active now? Since that's all we're
checking

On Sat, 25 Feb 2017 at 11:12 Edward O'Callaghan 
wrote:

> commit 4a88396 dropped 'PIPE_CAP_USER_INDEX_BUFFERS' however
> this case was missed.
>
> Signed-off-by: Edward O'Callaghan 
> ---
>  src/gallium/state_trackers/nine/device9.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/state_trackers/nine/device9.c
> b/src/gallium/state_trackers/nine/device9.c
> index c3924a2..8a75859 100644
> --- a/src/gallium/state_trackers/nine/device9.c
> +++ b/src/gallium/state_trackers/nine/device9.c
> @@ -473,7 +473,7 @@ NineDevice9_ctor( struct NineDevice9 *This,
>  /* Allocate upload helper for drivers that suck (from st pov ;). */
>
>  This->driver_caps.user_vbufs = GET_PCAP(USER_VERTEX_BUFFERS) &&
> !This->csmt_active;
> -This->driver_caps.user_ibufs = GET_PCAP(USER_INDEX_BUFFERS) &&
> !This->csmt_active;
> +This->driver_caps.user_ibufs = !This->csmt_active;
>  This->driver_caps.user_cbufs = GET_PCAP(USER_CONSTANT_BUFFERS);
>  This->driver_caps.user_sw_vbufs =
> This->screen_sw->get_param(This->screen_sw, PIPE_CAP_USER_VERTEX_BUFFERS);
>  This->driver_caps.user_sw_cbufs =
> This->screen_sw->get_param(This->screen_sw, PIPE_CAP_USER_CONSTANT_BUFFERS);
> --
> 2.9.3
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/nine: Drop USER_INDEX_BUFFERS check

2017-02-25 Thread Mike Lothian

I think my question regarding the double negative still stands. Is it
"!This->cmst_active" ot "This->cmst_active"

On Sat, 25 Feb 2017 at 11:23 Edward O'Callaghan 
wrote:

> From: Mike Lothian 
>
> This fixes 4a883966c1f74f43afc145d2c3d27af7b8c5e01a where the
> PIPE_CAP was removed.
>
> Now USER_INDEX_BUFFERS are always enabled remove the check and only
> check for cmst_active directly.
>
> v2: Axel pointed out the code was still needed when cmst was inactive,
> Rebase on master too
> v3: drop struct member user_ibufs also && fixup shortlog (Edward).
>
> Fixes: 4a883966c1f7 ("gallium: remove PIPE_CAP_USER_INDEX_BUFFERS")
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99953
> Reported-and-tested-by: Vinson Lee  (v1)
> Cc: Marek Olšák 
> Cc: Axel Davy 
> Signed-off-by: Mike Lothian 
> Signed-off-by: Edward O'Callaghan 
> ---
>  src/gallium/state_trackers/nine/device9.c | 3 +--
>  src/gallium/state_trackers/nine/device9.h | 1 -
>  2 files changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/src/gallium/state_trackers/nine/device9.c
> b/src/gallium/state_trackers/nine/device9.c
> index c3924a2..30ab8de 100644
> --- a/src/gallium/state_trackers/nine/device9.c
> +++ b/src/gallium/state_trackers/nine/device9.c
> @@ -473,7 +473,6 @@ NineDevice9_ctor( struct NineDevice9 *This,
>  /* Allocate upload helper for drivers that suck (from st pov ;). */
>
>  This->driver_caps.user_vbufs = GET_PCAP(USER_VERTEX_BUFFERS) &&
> !This->csmt_active;
> -This->driver_caps.user_ibufs = GET_PCAP(USER_INDEX_BUFFERS) &&
> !This->csmt_active;
>  This->driver_caps.user_cbufs = GET_PCAP(USER_CONSTANT_BUFFERS);
>  This->driver_caps.user_sw_vbufs =
> This->screen_sw->get_param(This->screen_sw, PIPE_CAP_USER_VERTEX_BUFFERS);
>  This->driver_caps.user_sw_cbufs =
> This->screen_sw->get_param(This->screen_sw, PIPE_CAP_USER_CONSTANT_BUFFERS);
> @@ -2896,7 +2895,7 @@ NineDevice9_DrawIndexedPrimitiveUP( struct
> NineDevice9 *This,
>  vbuf.buffer_offset -= base;
>  vbuf.user_buffer = NULL;
>  }
> -if (!This->driver_caps.user_ibufs) {
> +if (!This->cmst_active) {
>  u_upload_data(This->context.pipe->stream_uploader,
>0,
>(prim_count_to_vertex_count(PrimitiveType,
> PrimitiveCount)) * ibuf.index_size,
> diff --git a/src/gallium/state_trackers/nine/device9.h
> b/src/gallium/state_trackers/nine/device9.h
> index 71ebbdc..4b1630c 100644
> --- a/src/gallium/state_trackers/nine/device9.h
> +++ b/src/gallium/state_trackers/nine/device9.h
> @@ -127,7 +127,6 @@ struct NineDevice9
>
>  struct {
>  boolean user_vbufs;
> -boolean user_ibufs;
>  boolean user_cbufs;
>  boolean user_sw_vbufs;
>  boolean user_sw_cbufs;
> --
> 2.9.3
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/nine: Drop USER_INDEX_BUFFERS check

2017-02-25 Thread Mike Lothian

Will do.

On Sat, 25 Feb 2017 at 11:31 Edward O'Callaghan 
wrote:

> oh yes I missed that, you want to have drop the negation in your patch
> Mike.
>
> On 02/25/2017 10:28 PM, Mike Lothian wrote:
> > I think my question regarding the double negative still stands. Is it
> > "!This->cmst_active" ot "This->cmst_active"
> >
> > On Sat, 25 Feb 2017 at 11:23 Edward O'Callaghan
> > mailto:funfunc...@folklore1984.net>>
> wrote:
> >
> > From: Mike Lothian mailto:m...@fireburn.co.uk
> >>
> >
> > This fixes 4a883966c1f74f43afc145d2c3d27af7b8c5e01a where the
> > PIPE_CAP was removed.
> >
> > Now USER_INDEX_BUFFERS are always enabled remove the check and only
> > check for cmst_active directly.
> >
> > v2: Axel pointed out the code was still needed when cmst was
> inactive,
> > Rebase on master too
> > v3: drop struct member user_ibufs also && fixup shortlog (Edward).
> >
> > Fixes: 4a883966c1f7 ("gallium: remove PIPE_CAP_USER_INDEX_BUFFERS")
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99953
> > Reported-and-tested-by: Vinson Lee  > <mailto:v...@freedesktop.org>> (v1)
> > Cc: Marek Olšák mailto:marek.ol...@amd.com>>
> > Cc: Axel Davy mailto:axel.d...@ens.fr>>
> > Signed-off-by: Mike Lothian  > <mailto:m...@fireburn.co.uk>>
> > Signed-off-by: Edward O'Callaghan  > <mailto:funfunc...@folklore1984.net>>
> > ---
> >  src/gallium/state_trackers/nine/device9.c | 3 +--
> >  src/gallium/state_trackers/nine/device9.h | 1 -
> >  2 files changed, 1 insertion(+), 3 deletions(-)
> >
> > diff --git a/src/gallium/state_trackers/nine/device9.c
> > b/src/gallium/state_trackers/nine/device9.c
> > index c3924a2..30ab8de 100644
> > --- a/src/gallium/state_trackers/nine/device9.c
> > +++ b/src/gallium/state_trackers/nine/device9.c
> > @@ -473,7 +473,6 @@ NineDevice9_ctor( struct NineDevice9 *This,
> >  /* Allocate upload helper for drivers that suck (from st pov
> ;). */
> >
> >  This->driver_caps.user_vbufs = GET_PCAP(USER_VERTEX_BUFFERS) &&
> > !This->csmt_active;
> > -This->driver_caps.user_ibufs = GET_PCAP(USER_INDEX_BUFFERS) &&
> > !This->csmt_active;
> >  This->driver_caps.user_cbufs = GET_PCAP(USER_CONSTANT_BUFFERS);
> >  This->driver_caps.user_sw_vbufs =
> > This->screen_sw->get_param(This->screen_sw,
> > PIPE_CAP_USER_VERTEX_BUFFERS);
> >  This->driver_caps.user_sw_cbufs =
> > This->screen_sw->get_param(This->screen_sw,
> > PIPE_CAP_USER_CONSTANT_BUFFERS);
> > @@ -2896,7 +2895,7 @@ NineDevice9_DrawIndexedPrimitiveUP( struct
> > NineDevice9 *This,
> >  vbuf.buffer_offset -= base;
> >  vbuf.user_buffer = NULL;
> >  }
> > -if (!This->driver_caps.user_ibufs) {
> > +if (!This->cmst_active) {
> >  u_upload_data(This->context.pipe->stream_uploader,
> >0,
> >(prim_count_to_vertex_count(PrimitiveType,
> > PrimitiveCount)) * ibuf.index_size,
> > diff --git a/src/gallium/state_trackers/nine/device9.h
> > b/src/gallium/state_trackers/nine/device9.h
> > index 71ebbdc..4b1630c 100644
> > --- a/src/gallium/state_trackers/nine/device9.h
> > +++ b/src/gallium/state_trackers/nine/device9.h
> > @@ -127,7 +127,6 @@ struct NineDevice9
> >
> >  struct {
> >  boolean user_vbufs;
> > -boolean user_ibufs;
> >  boolean user_cbufs;
> >  boolean user_sw_vbufs;
> >  boolean user_sw_cbufs;
> > --
> > 2.9.3
> >
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v4] st/nine: Drop USER_INDEX_BUFFERS check

2017-02-25 Thread Mike Lothian

This fixes 4a883966c1f74f43afc145d2c3d27af7b8c5e01a where the
PIPE_CAP was removed.

Now USER_INDEX_BUFFERS are always enabled remove the check and only
check for cmst_active directly.

v2: Axel pointed out the code was still needed when cmst was inactive,
Rebase on master too
v3: Drop struct member user_ibufs also && fixup shortlog (Edward).
v4: Fix negation

Fixes: 4a883966c1f7 ("gallium: remove PIPE_CAP_USER_INDEX_BUFFERS")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99953
Reported-and-tested-by: Vinson Lee  (v1)
Cc: Marek Olšák 
Cc: Axel Davy 
Signed-off-by: Mike Lothian 
Signed-off-by: Edward O'Callaghan 
---
 src/gallium/state_trackers/nine/device9.c | 3 +--
 src/gallium/state_trackers/nine/device9.h | 1 -
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/src/gallium/state_trackers/nine/device9.c 
b/src/gallium/state_trackers/nine/device9.c
index c3924a21e2..822a306544 100644
--- a/src/gallium/state_trackers/nine/device9.c
+++ b/src/gallium/state_trackers/nine/device9.c
@@ -473,7 +473,6 @@ NineDevice9_ctor( struct NineDevice9 *This,
 /* Allocate upload helper for drivers that suck (from st pov ;). */
 
 This->driver_caps.user_vbufs = GET_PCAP(USER_VERTEX_BUFFERS) && 
!This->csmt_active;
-This->driver_caps.user_ibufs = GET_PCAP(USER_INDEX_BUFFERS) && 
!This->csmt_active;
 This->driver_caps.user_cbufs = GET_PCAP(USER_CONSTANT_BUFFERS);
 This->driver_caps.user_sw_vbufs = 
This->screen_sw->get_param(This->screen_sw, PIPE_CAP_USER_VERTEX_BUFFERS);
 This->driver_caps.user_sw_cbufs = 
This->screen_sw->get_param(This->screen_sw, PIPE_CAP_USER_CONSTANT_BUFFERS);
@@ -2896,7 +2895,7 @@ NineDevice9_DrawIndexedPrimitiveUP( struct NineDevice9 
*This,
 vbuf.buffer_offset -= base;
 vbuf.user_buffer = NULL;
 }
-if (!This->driver_caps.user_ibufs) {
+if (This->cmst_active) {
 u_upload_data(This->context.pipe->stream_uploader,
   0,
   (prim_count_to_vertex_count(PrimitiveType, 
PrimitiveCount)) * ibuf.index_size,
diff --git a/src/gallium/state_trackers/nine/device9.h 
b/src/gallium/state_trackers/nine/device9.h
index 71ebbdc935..4b1630c40f 100644
--- a/src/gallium/state_trackers/nine/device9.h
+++ b/src/gallium/state_trackers/nine/device9.h
@@ -127,7 +127,6 @@ struct NineDevice9
 
 struct {
 boolean user_vbufs;
-boolean user_ibufs;
 boolean user_cbufs;
 boolean user_sw_vbufs;
 boolean user_sw_cbufs;
-- 
2.11.1

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

[Mesa-dev] [PATCH v5] st/nine: Drop USER_INDEX_BUFFERS check

2017-02-25 Thread Mike Lothian

This fixes 4a883966c1f74f43afc145d2c3d27af7b8c5e01a where the
PIPE_CAP was removed.

Now USER_INDEX_BUFFERS are always enabled remove the check and only
check for cmst_active directly.

v2: Axel pointed out the code was still needed when cmst was inactive,
Rebase on master too
v3: Drop struct member user_ibufs also && fixup shortlog (Edward).
v4: Fix negation
v5: Use the right variable name csmt != cmst (and learn git rebase)

Fixes: 4a883966c1f7 ("gallium: remove PIPE_CAP_USER_INDEX_BUFFERS")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99953
Reported-and-tested-by: Vinson Lee  (v1)
Cc: Marek Olšák 
Cc: Axel Davy 
Signed-off-by: Edward O'Callaghan 
Signed-off-by: Mike Lothian 
---
 src/gallium/state_trackers/nine/device9.c | 3 +--
 src/gallium/state_trackers/nine/device9.h | 1 -
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/src/gallium/state_trackers/nine/device9.c 
b/src/gallium/state_trackers/nine/device9.c
index c3924a21e2..843716207d 100644
--- a/src/gallium/state_trackers/nine/device9.c
+++ b/src/gallium/state_trackers/nine/device9.c
@@ -473,7 +473,6 @@ NineDevice9_ctor( struct NineDevice9 *This,
 /* Allocate upload helper for drivers that suck (from st pov ;). */
 
 This->driver_caps.user_vbufs = GET_PCAP(USER_VERTEX_BUFFERS) && 
!This->csmt_active;
-This->driver_caps.user_ibufs = GET_PCAP(USER_INDEX_BUFFERS) && 
!This->csmt_active;
 This->driver_caps.user_cbufs = GET_PCAP(USER_CONSTANT_BUFFERS);
 This->driver_caps.user_sw_vbufs = 
This->screen_sw->get_param(This->screen_sw, PIPE_CAP_USER_VERTEX_BUFFERS);
 This->driver_caps.user_sw_cbufs = 
This->screen_sw->get_param(This->screen_sw, PIPE_CAP_USER_CONSTANT_BUFFERS);
@@ -2896,7 +2895,7 @@ NineDevice9_DrawIndexedPrimitiveUP( struct NineDevice9 
*This,
 vbuf.buffer_offset -= base;
 vbuf.user_buffer = NULL;
 }
-if (!This->driver_caps.user_ibufs) {
+if (This->csmt_active) {
 u_upload_data(This->context.pipe->stream_uploader,
   0,
   (prim_count_to_vertex_count(PrimitiveType, 
PrimitiveCount)) * ibuf.index_size,
diff --git a/src/gallium/state_trackers/nine/device9.h 
b/src/gallium/state_trackers/nine/device9.h
index 71ebbdc935..4b1630c40f 100644
--- a/src/gallium/state_trackers/nine/device9.h
+++ b/src/gallium/state_trackers/nine/device9.h
@@ -127,7 +127,6 @@ struct NineDevice9
 
 struct {
 boolean user_vbufs;
-boolean user_ibufs;
 boolean user_cbufs;
 boolean user_sw_vbufs;
 boolean user_sw_cbufs;
-- 
2.11.1

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

Re: [Mesa-dev] [PATCH v5] st/nine: Drop USER_INDEX_BUFFERS check

2017-02-25 Thread Mike Lothian

Thanks for pushing and being patient with me

On Sat, 25 Feb 2017 at 12:13 Edward O'Callaghan 
wrote:

> Very noisy but you got there in the end,
>
> Reviewed-by: Edward O'Callaghan 
>
> On 02/25/2017 10:50 PM, Mike Lothian wrote:
> > This fixes 4a883966c1f74f43afc145d2c3d27af7b8c5e01a where the
> > PIPE_CAP was removed.
> >
> > Now USER_INDEX_BUFFERS are always enabled remove the check and only
> > check for cmst_active directly.
> >
> > v2: Axel pointed out the code was still needed when cmst was inactive,
> > Rebase on master too
> > v3: Drop struct member user_ibufs also && fixup shortlog (Edward).
> > v4: Fix negation
> > v5: Use the right variable name csmt != cmst (and learn git rebase)
> >
> > Fixes: 4a883966c1f7 ("gallium: remove PIPE_CAP_USER_INDEX_BUFFERS")
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99953
> > Reported-and-tested-by: Vinson Lee  (v1)
> > Cc: Marek Olšák 
> > Cc: Axel Davy 
> > Signed-off-by: Edward O'Callaghan 
> > Signed-off-by: Mike Lothian 
> > ---
> >  src/gallium/state_trackers/nine/device9.c | 3 +--
> >  src/gallium/state_trackers/nine/device9.h | 1 -
> >  2 files changed, 1 insertion(+), 3 deletions(-)
> >
> > diff --git a/src/gallium/state_trackers/nine/device9.c
> b/src/gallium/state_trackers/nine/device9.c
> > index c3924a21e2..843716207d 100644
> > --- a/src/gallium/state_trackers/nine/device9.c
> > +++ b/src/gallium/state_trackers/nine/device9.c
> > @@ -473,7 +473,6 @@ NineDevice9_ctor( struct NineDevice9 *This,
> >  /* Allocate upload helper for drivers that suck (from st pov ;). */
> >
> >  This->driver_caps.user_vbufs = GET_PCAP(USER_VERTEX_BUFFERS) &&
> !This->csmt_active;
> > -This->driver_caps.user_ibufs = GET_PCAP(USER_INDEX_BUFFERS) &&
> !This->csmt_active;
> >  This->driver_caps.user_cbufs = GET_PCAP(USER_CONSTANT_BUFFERS);
> >  This->driver_caps.user_sw_vbufs =
> This->screen_sw->get_param(This->screen_sw, PIPE_CAP_USER_VERTEX_BUFFERS);
> >  This->driver_caps.user_sw_cbufs =
> This->screen_sw->get_param(This->screen_sw, PIPE_CAP_USER_CONSTANT_BUFFERS);
> > @@ -2896,7 +2895,7 @@ NineDevice9_DrawIndexedPrimitiveUP( struct
> NineDevice9 *This,
> >  vbuf.buffer_offset -= base;
> >  vbuf.user_buffer = NULL;
> >  }
> > -if (!This->driver_caps.user_ibufs) {
> > +if (This->csmt_active) {
> >  u_upload_data(This->context.pipe->stream_uploader,
> >0,
> >(prim_count_to_vertex_count(PrimitiveType,
> PrimitiveCount)) * ibuf.index_size,
> > diff --git a/src/gallium/state_trackers/nine/device9.h
> b/src/gallium/state_trackers/nine/device9.h
> > index 71ebbdc935..4b1630c40f 100644
> > --- a/src/gallium/state_trackers/nine/device9.h
> > +++ b/src/gallium/state_trackers/nine/device9.h
> > @@ -127,7 +127,6 @@ struct NineDevice9
> >
> >  struct {
> >  boolean user_vbufs;
> > -boolean user_ibufs;
> >  boolean user_cbufs;
> >  boolean user_sw_vbufs;
> >  boolean user_sw_cbufs;
> >
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: handle the case of different GPU(v4.2)

2016-09-20 Thread Mike Lothian

Hi

I've just confirmed this works for getting details from vainfo and
vdpauinfo using DRI_PRIME=1 without needing to set up offloading with xrandr

I do however need to specify the driver still, is that something being
worked on? It would be great if it autoselected based on the card running
at DRI_PRIME=1 (or x if there's more than one card)

Cheers

Mike

On Tue, 20 Sep 2016 at 05:52 Nayan Deshmukh 
wrote:

> In case of prime when rendering is done on GPU other then the
> server GPU, use a seprate linear buffer for each back buffer
> which will be displayed using present extension.
>
> v2: Use a seprate linear buffer for each back buffer (Michel)
> v3: Change variable names and fix coding style (Leo and Emil)
> v4: Use PIPE_BIND_SAMPLER_VIEW for back buffer in case when
> a seprate linear buffer is used (Michel)
> v4.1: remove empty line
> v4.2: destroy the context and handle the case when
>   create_context fails (Emil)
>
> Signed-off-by: Nayan Deshmukh 
> Reviewed-by: Leo Liu 
> Acked-by: Michel Dänzer 
> ---
>  src/gallium/auxiliary/vl/vl_winsys_dri3.c | 66
> +--
>  1 file changed, 53 insertions(+), 13 deletions(-)
>
> diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
> b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
> index 3d596a6..191a64b 100644
> --- a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
> +++ b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
> @@ -49,6 +49,7 @@
>  struct vl_dri3_buffer
>  {
> struct pipe_resource *texture;
> +   struct pipe_resource *linear_texture;
>
> uint32_t pixmap;
> uint32_t sync_fence;
> @@ -69,6 +70,8 @@ struct vl_dri3_screen
> xcb_present_event_t eid;
> xcb_special_event_t *special_event;
>
> +   struct pipe_context *pipe;
> +
> struct vl_dri3_buffer *back_buffers[BACK_BUFFER_NUM];
> int cur_back;
>
> @@ -82,6 +85,7 @@ struct vl_dri3_screen
> int64_t last_ust, ns_frame, last_msc, next_msc;
>
> bool flushed;
> +   bool is_different_gpu;
>  };
>
>  static void
> @@ -102,6 +106,8 @@ dri3_free_back_buffer(struct vl_dri3_screen *scrn,
> xcb_sync_destroy_fence(scrn->conn, buffer->sync_fence);
> xshmfence_unmap_shm(buffer->shm_fence);
> pipe_resource_reference(&buffer->texture, NULL);
> +   if (buffer->linear_texture)
> +   pipe_resource_reference(&buffer->linear_texture, NULL);
> FREE(buffer);
>  }
>
> @@ -209,7 +215,7 @@ dri3_alloc_back_buffer(struct vl_dri3_screen *scrn)
> xcb_sync_fence_t sync_fence;
> struct xshmfence *shm_fence;
> int buffer_fd, fence_fd;
> -   struct pipe_resource templ;
> +   struct pipe_resource templ, *pixmap_buffer_texture;
> struct winsys_handle whandle;
> unsigned usage;
>
> @@ -226,8 +232,7 @@ dri3_alloc_back_buffer(struct vl_dri3_screen *scrn)
>goto close_fd;
>
> memset(&templ, 0, sizeof(templ));
> -   templ.bind = PIPE_BIND_RENDER_TARGET | PIPE_BIND_SAMPLER_VIEW |
> -PIPE_BIND_SCANOUT | PIPE_BIND_SHARED;
> +   templ.bind = PIPE_BIND_RENDER_TARGET | PIPE_BIND_SAMPLER_VIEW;
> templ.format = PIPE_FORMAT_B8G8R8X8_UNORM;
> templ.target = PIPE_TEXTURE_2D;
> templ.last_level = 0;
> @@ -235,16 +240,34 @@ dri3_alloc_back_buffer(struct vl_dri3_screen *scrn)
> templ.height0 = scrn->height;
> templ.depth0 = 1;
> templ.array_size = 1;
> -   buffer->texture =
> scrn->base.pscreen->resource_create(scrn->base.pscreen,
> - &templ);
> -   if (!buffer->texture)
> -  goto unmap_shm;
>
> +   if (scrn->is_different_gpu) {
> +  buffer->texture =
> scrn->base.pscreen->resource_create(scrn->base.pscreen,
> +&templ);
> +  if (!buffer->texture)
> + goto unmap_shm;
> +
> +  templ.bind |= PIPE_BIND_SCANOUT | PIPE_BIND_SHARED |
> +PIPE_BIND_LINEAR;
> +  buffer->linear_texture =
> scrn->base.pscreen->resource_create(scrn->base.pscreen,
> +  &templ);
> +  pixmap_buffer_texture = buffer->linear_texture;
> +
> +  if (!buffer->linear_texture)
> + goto no_linear_texture;
> +   } else {
> +  templ.bind |= PIPE_BIND_SCANOUT | PIPE_BIND_SHARED;
> +  buffer->texture =
> scrn->base.pscreen->resource_create(scrn->base.pscreen,
> +&templ);
> +  if (!buffer->texture)
> + goto unmap_shm;
> +  pixmap_buffer_texture = buffer->texture;
> +   }
> memset(&whandle, 0, sizeof(whandle));
> whandle.type= DRM_API_HANDLE_TYPE_FD;
> usage = PIPE_HANDLE_USAGE_EXPLICIT_FLUSH | PIPE_HANDLE_USAGE_READ;
> scrn->base.pscreen->resource_get_handle(scrn->base.pscreen, NULL,
> -   buffer->texture, &whandle,
> +   pixmap_buffer_texture,
> &whandle,
> usage);
> buffer_fd = whandle.handle

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: handle the case of different GPU(v4.2)

2016-09-20 Thread Mike Lothian

Here's what I currently have:

fireburn@axion ~ $ DRI_PRIME=1 vainfo
libva info: VA-API version 0.39.3
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/va/drivers/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_39
libva info: va_openDriver() returns 0
vainfo: VA-API version: 0.39 (libva 1.7.2)
vainfo: Driver version: Intel i965 driver for Intel(R) Skylake - 1.7.2
vainfo: Supported profile and entrypoints
  VAProfileMPEG2Simple: VAEntrypointVLD
  VAProfileMPEG2Simple: VAEntrypointEncSlice
  VAProfileMPEG2Main  : VAEntrypointVLD
  VAProfileMPEG2Main  : VAEntrypointEncSlice
  VAProfileH264ConstrainedBaseline: VAEntrypointVLD
  VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
  VAProfileH264ConstrainedBaseline: VAEntrypointEncSliceLP
  VAProfileH264Main   : VAEntrypointVLD
  VAProfileH264Main   : VAEntrypointEncSlice
  VAProfileH264Main   : VAEntrypointEncSliceLP
  VAProfileH264High   : VAEntrypointVLD
  VAProfileH264High   : VAEntrypointEncSlice
  VAProfileH264High   : VAEntrypointEncSliceLP
  VAProfileH264MultiviewHigh  : VAEntrypointVLD
  VAProfileH264MultiviewHigh  : VAEntrypointEncSlice
  VAProfileH264StereoHigh : VAEntrypointVLD
  VAProfileH264StereoHigh : VAEntrypointEncSlice
  VAProfileVC1Simple  : VAEntrypointVLD
  VAProfileVC1Main: VAEntrypointVLD
  VAProfileVC1Advanced: VAEntrypointVLD
  VAProfileNone   : VAEntrypointVideoProc
  VAProfileJPEGBaseline   : VAEntrypointVLD
  VAProfileJPEGBaseline   : VAEntrypointEncPicture
  VAProfileVP8Version0_3  : VAEntrypointVLD
  VAProfileVP8Version0_3  : VAEntrypointEncSlice
  VAProfileHEVCMain   : VAEntrypointVLD
  VAProfileHEVCMain   : VAEntrypointEncSlice


which picks up the i965 driver despite the DRI_PRIME=1 paramerter being fed
in - I have to manually specify LIBVA_DRIVER_NAME=radeonsi in order to get
it to get the details out of vainfo - the same goes for vdpauinfo

fireburn@axion ~ $ LIBVA_DRIVER_NAME=radeonsi DRI_PRIME=1 vainfo
libva info: VA-API version 0.39.3
libva info: va_getDriverName() returns 0
libva info: User requested driver 'radeonsi'
libva info: Trying to open /usr/lib64/va/drivers/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_0_39
libva info: va_openDriver() returns 0
vainfo: VA-API version: 0.39 (libva 1.7.2)
vainfo: Driver version: mesa gallium vaapi
vainfo: Supported profile and entrypoints
  VAProfileMPEG2Simple: VAEntrypointVLD
  VAProfileMPEG2Main  : VAEntrypointVLD
  VAProfileVC1Simple  : VAEntrypointVLD
  VAProfileVC1Main: VAEntrypointVLD
  VAProfileVC1Advanced: VAEntrypointVLD
  VAProfileH264Baseline   : VAEntrypointVLD
  VAProfileH264Baseline   : VAEntrypointEncSlice
  VAProfileH264Main   : VAEntrypointVLD
  VAProfileH264Main   : VAEntrypointEncSlice
  VAProfileH264High   : VAEntrypointVLD
  VAProfileH264High   : VAEntrypointEncSlice
  VAProfileNone   : VAEntrypointVideoProc


On Tue, 20 Sep 2016 at 14:13 Nayan Deshmukh 
wrote:

> Hi Mike,
>
>
> On Tue, Sep 20, 2016 at 5:45 PM, Mike Lothian  wrote:
>
>> Hi
>>
>> I've just confirmed this works for getting details from vainfo and
>> vdpauinfo using DRI_PRIME=1 without needing to set up offloading with xrandr
>>
>> I do however need to specify the driver still, is that something being
>> worked on? It would be great if it autoselected based on the card running
>> at DRI_PRIME=1 (or x if there's more than one card)
>>
>> I have a prime system and I don't need to specify any drivers in my
> system.
> Though I am not the right person to answer this question.
> Maybe Michel can answer this.
>
> Cheers,
> Nayan
>
>> Cheers
>>
>> Mike
>>
>> On Tue, 20 Sep 2016 at 05:52 Nayan Deshmukh 
>> wrote:
>>
>>> In case of prime when rendering is done on GPU other then the
>>> server GPU, use a seprate linear buffer for each back buffer
>>> which will be displayed using present extension.
>>>
>>> v2: Use a seprate linear buffer for each back buffer (Michel)
>>> v3: Change variable names and fix coding style (Leo and Emil)
>>> v4: Use PIPE_BIND_SAMPLER_VIEW for back buffer in case when
>>> a seprate linear buffer is used (Michel)
>>> v4.1: remove empty line
>>> v4.2: destroy the context and handle the case when
>

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: handle the case of different GPU(v4.2)

2016-09-20 Thread Mike Lothian

I'm running libva-1.7.2 but I notice this commit in git
https://cgit.freedesktop.org/vaapi/libva/commit/?id=a55ea7cb3143d57c8dba1b76ccea3511ea69adf2
but
that looks like it might only work with wayland

On Tue, 20 Sep 2016 at 14:40 Christian König 
wrote:

> Sounds like your version of libva ignores the DRI_PRIME environment
> parameter.
>
> Not sure what to do with this, but clearly a loader and not a driver
> problem.
>
> Regards,
> Christian.
>
>
> Am 20.09.2016 um 15:36 schrieb Mike Lothian:
>
> Here's what I currently have:
>
> fireburn@axion ~ $ DRI_PRIME=1 vainfo
> libva info: VA-API version 0.39.3
> libva info: va_getDriverName() returns 0
> libva info: Trying to open /usr/lib64/va/drivers/i965_drv_video.so
> libva info: Found init function __vaDriverInit_0_39
> libva info: va_openDriver() returns 0
> vainfo: VA-API version: 0.39 (libva 1.7.2)
> vainfo: Driver version: Intel i965 driver for Intel(R) Skylake - 1.7.2
> vainfo: Supported profile and entrypoints
>   VAProfileMPEG2Simple: VAEntrypointVLD
>   VAProfileMPEG2Simple: VAEntrypointEncSlice
>   VAProfileMPEG2Main  : VAEntrypointVLD
>   VAProfileMPEG2Main  : VAEntrypointEncSlice
>   VAProfileH264ConstrainedBaseline: VAEntrypointVLD
>   VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
>   VAProfileH264ConstrainedBaseline: VAEntrypointEncSliceLP
>   VAProfileH264Main   : VAEntrypointVLD
>   VAProfileH264Main   : VAEntrypointEncSlice
>   VAProfileH264Main   : VAEntrypointEncSliceLP
>   VAProfileH264High   : VAEntrypointVLD
>   VAProfileH264High   : VAEntrypointEncSlice
>   VAProfileH264High   : VAEntrypointEncSliceLP
>   VAProfileH264MultiviewHigh  : VAEntrypointVLD
>   VAProfileH264MultiviewHigh  : VAEntrypointEncSlice
>   VAProfileH264StereoHigh : VAEntrypointVLD
>   VAProfileH264StereoHigh : VAEntrypointEncSlice
>   VAProfileVC1Simple  : VAEntrypointVLD
>   VAProfileVC1Main: VAEntrypointVLD
>   VAProfileVC1Advanced: VAEntrypointVLD
>   VAProfileNone   : VAEntrypointVideoProc
>   VAProfileJPEGBaseline   : VAEntrypointVLD
>   VAProfileJPEGBaseline   : VAEntrypointEncPicture
>   VAProfileVP8Version0_3  : VAEntrypointVLD
>   VAProfileVP8Version0_3  : VAEntrypointEncSlice
>   VAProfileHEVCMain   : VAEntrypointVLD
>   VAProfileHEVCMain   : VAEntrypointEncSlice
>
>
> which picks up the i965 driver despite the DRI_PRIME=1 paramerter being
> fed in - I have to manually specify LIBVA_DRIVER_NAME=radeonsi in order to
> get it to get the details out of vainfo - the same goes for vdpauinfo
>
> fireburn@axion ~ $ LIBVA_DRIVER_NAME=radeonsi DRI_PRIME=1 vainfo
> libva info: VA-API version 0.39.3
> libva info: va_getDriverName() returns 0
> libva info: User requested driver 'radeonsi'
> libva info: Trying to open /usr/lib64/va/drivers/radeonsi_drv_video.so
> libva info: Found init function __vaDriverInit_0_39
> libva info: va_openDriver() returns 0
> vainfo: VA-API version: 0.39 (libva 1.7.2)
> vainfo: Driver version: mesa gallium vaapi
> vainfo: Supported profile and entrypoints
>   VAProfileMPEG2Simple: VAEntrypointVLD
>   VAProfileMPEG2Main  : VAEntrypointVLD
>   VAProfileVC1Simple  : VAEntrypointVLD
>   VAProfileVC1Main: VAEntrypointVLD
>   VAProfileVC1Advanced: VAEntrypointVLD
>   VAProfileH264Baseline   : VAEntrypointVLD
>   VAProfileH264Baseline   : VAEntrypointEncSlice
>   VAProfileH264Main   : VAEntrypointVLD
>   VAProfileH264Main   : VAEntrypointEncSlice
>   VAProfileH264High   : VAEntrypointVLD
>   VAProfileH264High   : VAEntrypointEncSlice
>   VAProfileNone   : VAEntrypointVideoProc
>
>
> On Tue, 20 Sep 2016 at 14:13 Nayan Deshmukh 
> wrote:
>
>> Hi Mike,
>>
>>
>> On Tue, Sep 20, 2016 at 5:45 PM, Mike Lothian 
>> wrote:
>>
>>> Hi
>>>
>>> I've just confirmed this works for getting details from vainfo and
>>> vdpauinfo using DRI_PRIME=1 without needing to set up offloading with xrandr
>>>
>>> I do however need to specify the driver still, is that something being
>>> worked on? It would be great if it autoselected based on the card running
>>> at DRI_PRIME=1 (or x if there's more than one card)
>>>
>>> I

Re: [Mesa-dev] [PATCH 13/13] radeonsi: enable GLSL 4.50

2016-10-08 Thread Mike Lothian

This doesn't seem to be enough to get glxinfo to report GL 4.5 on my
Tonga or Kabini systems

Even with MESA_GLSL_VERSION_OVERRIDE=440 or 450 the maximum reported
GLSL version is 430, the override works with 420 however

I'm wondering if there's something in the Gallium code that's limiting
it to a max option of 430

On 7 October 2016 at 20:55, Nicolai Hähnle  wrote:
> From: Nicolai Hähnle 
>
> ---
>  src/gallium/drivers/radeonsi/si_pipe.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_pipe.c 
> b/src/gallium/drivers/radeonsi/si_pipe.c
> index 5a3f101..6e7f6a3 100644
> --- a/src/gallium/drivers/radeonsi/si_pipe.c
> +++ b/src/gallium/drivers/radeonsi/si_pipe.c
> @@ -432,21 +432,21 @@ static int si_get_param(struct pipe_screen* pscreen, 
> enum pipe_cap param)
>
> case PIPE_CAP_CONSTANT_BUFFER_OFFSET_ALIGNMENT:
> case PIPE_CAP_TEXTURE_BUFFER_OFFSET_ALIGNMENT:
> case PIPE_CAP_MAX_TEXTURE_GATHER_COMPONENTS:
> return 4;
> case PIPE_CAP_SHADER_BUFFER_OFFSET_ALIGNMENT:
> return HAVE_LLVM >= 0x0309 ? 4 : 0;
>
> case PIPE_CAP_GLSL_FEATURE_LEVEL:
> if (si_have_tgsi_compute(sscreen))
> -   return 430;
> +   return 450;
> return HAVE_LLVM >= 0x0309 ? 420 :
>HAVE_LLVM >= 0x0307 ? 410 : 330;
>
> case PIPE_CAP_MAX_TEXTURE_BUFFER_SIZE:
> return MIN2(sscreen->b.info.max_alloc_size, INT_MAX);
>
> case PIPE_CAP_BUFFER_SAMPLER_VIEW_RGBA_ONLY:
> return 0;
>
> /* Unsupported features. */
> --
> 2.7.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 13/13] radeonsi: enable GLSL 4.50

2016-10-08 Thread Mike Lothian

Ignore me I don't think patch 12 applied correctly

On Sat, 8 Oct 2016, 9:14 am Mike Lothian,  wrote:

> This doesn't seem to be enough to get glxinfo to report GL 4.5 on my
> Tonga or Kabini systems
>
> Even with MESA_GLSL_VERSION_OVERRIDE=440 or 450 the maximum reported
> GLSL version is 430, the override works with 420 however
>
> I'm wondering if there's something in the Gallium code that's limiting
> it to a max option of 430
>
> On 7 October 2016 at 20:55, Nicolai Hähnle  wrote:
> > From: Nicolai Hähnle 
> >
> > ---
> >  src/gallium/drivers/radeonsi/si_pipe.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/src/gallium/drivers/radeonsi/si_pipe.c
> b/src/gallium/drivers/radeonsi/si_pipe.c
> > index 5a3f101..6e7f6a3 100644
> > --- a/src/gallium/drivers/radeonsi/si_pipe.c
> > +++ b/src/gallium/drivers/radeonsi/si_pipe.c
> > @@ -432,21 +432,21 @@ static int si_get_param(struct pipe_screen*
> pscreen, enum pipe_cap param)
> >
> > case PIPE_CAP_CONSTANT_BUFFER_OFFSET_ALIGNMENT:
> > case PIPE_CAP_TEXTURE_BUFFER_OFFSET_ALIGNMENT:
> > case PIPE_CAP_MAX_TEXTURE_GATHER_COMPONENTS:
> > return 4;
> > case PIPE_CAP_SHADER_BUFFER_OFFSET_ALIGNMENT:
> > return HAVE_LLVM >= 0x0309 ? 4 : 0;
> >
> > case PIPE_CAP_GLSL_FEATURE_LEVEL:
> > if (si_have_tgsi_compute(sscreen))
> > -   return 430;
> > +   return 450;
> > return HAVE_LLVM >= 0x0309 ? 420 :
> >HAVE_LLVM >= 0x0307 ? 410 : 330;
> >
> > case PIPE_CAP_MAX_TEXTURE_BUFFER_SIZE:
> > return MIN2(sscreen->b.info.max_alloc_size, INT_MAX);
> >
> > case PIPE_CAP_BUFFER_SAMPLER_VIEW_RGBA_ONLY:
> > return 0;
> >
> > /* Unsupported features. */
> > --
> > 2.7.4
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] docs: Fix GL status of radeonsi

2016-10-13 Thread Mike Lothian

Alternatively you could expose GLSL 440 until the bugs are squished for 450

On Thu, 13 Oct 2016 at 12:39 Nicolai Hähnle  wrote:

> On 13.10.2016 10:20, Andreas Boll wrote:
> > Currently radeonsi doesn't advertise GLSL 4.40 and "GL 4.4, GLSL 4.40 --
> > all DONE" means the driver actually advertises GL 4.4 and GLSL 4.40.
> >
> > So as long as radeonsi doesn't enable GLSL >= 4.40 it's not "all DONE".
> >
> > Fixes: 789119d21 ("st/mesa: enable ARB_enhanced_layouts and turn the cap
> on")
> > Signed-off-by: Andreas Boll 
>
> The only place where this could possibly matter is mesamatrix, and
> frankly, it should be fixed there. There's clearly something wrong
> there, since it didn't update the display at all.
>
> Nicolai
>
> > ---
> >  docs/features.txt | 18 +-
> >  1 file changed, 9 insertions(+), 9 deletions(-)
> >
> > diff --git a/docs/features.txt b/docs/features.txt
> > index ec2634f..9cc9111 100644
> > --- a/docs/features.txt
> > +++ b/docs/features.txt
> > @@ -188,23 +188,23 @@ GL 4.3, GLSL 4.30 -- all DONE: i965/gen8+, nvc0,
> radeonsi
> >GL_ARB_vertex_attrib_binding  DONE (all
> drivers)
> >
> >
> > -GL 4.4, GLSL 4.40 -- all DONE: i965/gen8+, radeonsi
> > +GL 4.4, GLSL 4.40 -- all DONE: i965/gen8+
> >
> >GL_MAX_VERTEX_ATTRIB_STRIDE   DONE (all
> drivers)
> > -  GL_ARB_buffer_storage DONE (i965,
> nv50, nvc0, r600)
> > -  GL_ARB_clear_texture  DONE (i965,
> nv50, nvc0, r600)
> > -  GL_ARB_enhanced_layouts   DONE (i965,
> llvmpipe, softpipe)
> > +  GL_ARB_buffer_storage DONE (i965,
> nv50, nvc0, r600, radeonsi)
> > +  GL_ARB_clear_texture  DONE (i965,
> nv50, nvc0, r600, radeonsi)
> > +  GL_ARB_enhanced_layouts   DONE (i965,
> radeonsi, llvmpipe, softpipe)
> >- compile-time constant expressions   DONE
> >- explicit byte offsets for blocksDONE
> >- forced alignment within blocks  DONE
> > -  - specified vec4-slot component numbers   DONE (i965,
> llvmpipe, softpipe)
> > +  - specified vec4-slot component numbers   DONE (i965,
> radeonsi, llvmpipe, softpipe)
> >- specified transform/feedback layout DONE
> >- input/output block locationsDONE
> >GL_ARB_multi_bind DONE (all
> drivers)
> > -  GL_ARB_query_buffer_objectDONE
> (i965/hsw+, nvc0)
> > -  GL_ARB_texture_mirror_clamp_to_edge   DONE (i965,
> nv50, nvc0, r600, llvmpipe, softpipe, swr)
> > -  GL_ARB_texture_stencil8   DONE
> (i965/hsw+, nv50, nvc0, r600, llvmpipe, softpipe, swr)
> > -  GL_ARB_vertex_type_10f_11f_11f_revDONE (i965,
> nv50, nvc0, r600, llvmpipe, softpipe, swr)
> > +  GL_ARB_query_buffer_objectDONE
> (i965/hsw+, nvc0, radeonsi)
> > +  GL_ARB_texture_mirror_clamp_to_edge   DONE (i965,
> nv50, nvc0, r600, radeonsi, llvmpipe, softpipe, swr)
> > +  GL_ARB_texture_stencil8   DONE
> (i965/hsw+, nv50, nvc0, r600, radeonsi, llvmpipe, softpipe, swr)
> > +  GL_ARB_vertex_type_10f_11f_11f_revDONE (i965,
> nv50, nvc0, r600, radeonsi, llvmpipe, softpipe, swr)
> >
> >  GL 4.5, GLSL 4.50:
> >
> >
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3 25/25] configure.ac: Add required LLVM versions to the top

2016-10-13 Thread Mike Lothian

If you recompile llvm and mesa each time, are there any downsides of using
the shared libs?

I think there were some issues with some programs / games that had clashing
symbols but I'm not sure if that's still an issue

On Thu, 13 Oct 2016 at 11:15 Emil Velikov  wrote:

> On 13 October 2016 at 04:07, Michel Dänzer  wrote:
> > On 13/10/16 03:37 AM, Tobias Droste wrote:
> >> Am Mittwoch, 12. Oktober 2016, 11:53:50 CEST schrieb Emil Velikov:
> 
>  +LLVM_VERSION_REQUIRED_OPENCL=3.6.0
>  +LLVM_VERSION_REQUIRED_R600=3.6.0
>  +LLVM_VERSION_REQUIRED_RADEONSI=3.6.0
> >>>
> >>> There's a small related gotcha: as-is at build time we get the
> >>> different codepaths thus, as people build against shared LLVM (hello
> >>> Archlinux, I'm looking at you) and update their LLVM without
> >>> rebuilding mesa (Arch I'm looking at you again) things go funny.
> >
> > What exactly happened there? LLVM upstream generates shared libraries
> > named libLLVM-..so*, so it shouldn't be possible for a
> > simple LLVM package update to break Mesa, unless Arch did something
> > really stupid.
> >
> The issue is not specific to Arch, but anyone who links against shared
> LLVM.
>
> Here is another take on it:
> At least swr and r600/radeonsi depend at _build_ time on the _patch_
> version of LLVM. The latter of which is not part of the DSO name. Thus
> at runtime as you change your LLVM (3.9.x>3.9.y) you'll execute the
> "3.9.x" codepath even though you are be using "3.9.y" LLVM. If
> anything I'm calling it a LLVM bug, since shared/static library users
> should not need to know patch version, let alone have different
> codepaths based on it. Runtime ones might be ok, compile time
> definitely not.
>
> On our end, we could a) bump the requirement such that there's no
> compile time patch version check, b) suggest static linking or c)
> pretend the {mis,ab,}use isn't there ;-)
>
> >
> >>> Tl;Dr; We really want to enable static linking by default and prod
> >>> distros to use it.
> >>
> >> I'm all in favor of statically linking LLVM (that's the way I'm doing
> this on
> >> my pc).
> >> I think the only reason this is not done is because people (also here
> on the
> >> list) don't want any static linkg of external libraries because of size
> or
> >> whatever.
> >> So changing the default to static is easy, but I doubt it will make
> everyone
> >> happy ;-)
> >
> > Indeed, it'd probably make many distro packagers unhappy, because
> > they'll just have to re-enable shared linking, because packaging
> > policies generally strongly discourage if not outright forbid static
> > linking.
> >
> The toggle is there and is not going away, afaict. If people are going
> to get upset that the default does not meet their policy... just
> toggle and get on with other things ;-)
>
> Thanks
> Emil
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] anv: Suffix the intel_icd file with the host CPU

2016-10-21 Thread Mike Lothian

Does this need to be target CPU rather than host?

On Fri, 21 Oct 2016 at 14:53 Emil Velikov  wrote:

> Thank you very very very much for this, Jason !
>
> On 21 October 2016 at 01:07, Jason Ekstrand  wrote:
>
> > drivers because they may put it in /usr/local or $HOME/.local or some
> > other
> Drop the "/usr/local or " part. The dynamic linker looks in there, by
> default.
>
> > more exotic location.  In this case, you can't use an ICD json file
> with
> > just a library name because it doesn't know where to find it; you
> also
> > have
> s/; you also have/, so you have/
>
> Please update .gitignore and drop the intel_icd.json reference from
> EXTRA_DIST.
>
> With those the series is:
> Reviewed-by: Emil Velikov 
>
> Thanks again,
> Emil
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 0/3] Flex 2.6.2 build fixes

2016-10-27 Thread Mike Lothian

Thanks

On Thu, 27 Oct 2016 at 12:51 Emil Velikov  wrote:

> Hi all,
>
> As pointed out by Mike, building Mesa with latest version of flex is
> not possible.
>
> Upon closer look it seems that the following functions are not expanded
> properly (the #define yyfoo ${prefix}foo is missing).
>
> yylex_init_extra
> yylex_destroy
> yy_scan_*
>
> Not 100% sure if this is flex bug or ours, regardless the series
> makes things compatible regardless of the version used.
>
> I've tested it against flex 2.6.1 + 2.6.2 and further testing would be
> appreciated.
>
> Thanks
> Emil
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] pipe-loader: add libamd_common for radeonsi

2016-11-03 Thread Mike Lothian

I'm probably not qualified enough to give a Reviewed-by line, but I can
confirm this fixes the build for me

On Thu, 3 Nov 2016 at 14:28 Nicolai Hähnle  wrote:

> From: Nicolai Hähnle 
>
> This fixes a build regression of commit
> 7115e56c21ace07cf04f5073ba73a533e2182099.
> Sorry for the breakage, this second location for link dependencies escaped
> my build tests.
> ---
>  src/gallium/targets/pipe-loader/Makefile.am | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/src/gallium/targets/pipe-loader/Makefile.am
> b/src/gallium/targets/pipe-loader/Makefile.am
> index 18b403f..ce504cf 100644
> --- a/src/gallium/targets/pipe-loader/Makefile.am
> +++ b/src/gallium/targets/pipe-loader/Makefile.am
> @@ -151,20 +151,21 @@ if HAVE_GALLIUM_RADEONSI
>  pipe_LTLIBRARIES += pipe_radeonsi.la
>
>  pipe_radeonsi_la_SOURCES = pipe_radeonsi.c
>  nodist_EXTRA_pipe_radeonsi_la_SOURCES = dummy.cpp
>  pipe_radeonsi_la_LIBADD = \
> $(PIPE_LIBS) \
> $(top_builddir)/src/gallium/winsys/radeon/drm/libradeonwinsys.la \
> $(top_builddir)/src/gallium/winsys/amdgpu/drm/libamdgpuwinsys.la \
> $(top_builddir)/src/gallium/drivers/radeon/libradeon.la \
> $(top_builddir)/src/gallium/drivers/radeonsi/libradeonsi.la \
> +   $(top_builddir)/src/amd/common/libamd_common.la \
> $(LIBDRM_LIBS) \
> $(RADEON_LIBS) \
> $(AMDGPU_LIBS)
>
>  endif
>
>  if HAVE_GALLIUM_FREEDRENO
>  pipe_LTLIBRARIES += pipe_msm.la
>
>  pipe_msm_la_SOURCES = pipe_msm.c
> --
> 2.7.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/3] radv: Incorporate GPU family into cache UUID.

2016-11-22 Thread Mike Lothian

Would it be possible to have a cache for each family? I imagine this might
cause issues when someone has multiple cards in their system

On Tue, 22 Nov 2016 at 01:20 Bas Nieuwenhuizen 
wrote:

> Invalidates the cache when someone switches cards.
>
> Signed-off-by: Bas Nieuwenhuizen 
> ---
>  src/amd/vulkan/radv_device.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
> index 04c0bdc..8595973 100644
> --- a/src/amd/vulkan/radv_device.c
> +++ b/src/amd/vulkan/radv_device.c
> @@ -61,9 +61,10 @@ radv_get_function_timestamp(void *ptr, uint32_t*
> timestamp)
>  }
>
>  static int
> -radv_device_get_cache_uuid(void *uuid)
> +radv_device_get_cache_uuid(enum radeon_family family, void *uuid)
>  {
> uint32_t mesa_timestamp, llvm_timestamp;
> +   uint16_t f = family;
> memset(uuid, 0, VK_UUID_SIZE);
> if (radv_get_function_timestamp(radv_device_get_cache_uuid,
> &mesa_timestamp) ||
> radv_get_function_timestamp(LLVMInitializeAMDGPUTargetInfo,
> &llvm_timestamp))
> @@ -71,7 +72,8 @@ radv_device_get_cache_uuid(void *uuid)
>
> memcpy(uuid, &mesa_timestamp, 4);
> memcpy((char*)uuid + 4, &llvm_timestamp, 4);
> -   snprintf((char*)uuid + 8, VK_UUID_SIZE - 8, "radv");
> +   memcpy((char*)uuid + 8, &f, 2);
> +   snprintf((char*)uuid + 10, VK_UUID_SIZE - 10, "radv");
> return 0;
>  }
>
> @@ -120,7 +122,7 @@ radv_physical_device_init(struct radv_physical_device
> *device,
> goto fail;
> }
>
> -   if (radv_device_get_cache_uuid(device->uuid)) {
> +   if (radv_device_get_cache_uuid(device->rad_info.family,
> device->uuid)) {
> radv_finish_wsi(device);
> device->ws->destroy(device->ws);
> goto fail;
> --
> 2.10.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] [rfc] radv: add initial prime support.

2016-11-23 Thread Mike Lothian

You are a star :D

I'll test this out tonight

On Wed, 23 Nov 2016 at 05:29 Dave Airlie  wrote:

> From: Dave Airlie 
>
> This is kind of a gross hacks, but vulkan doesn't specify anything
> but it would be nice to let people with prime systems at least
> see some stuff rendering for now.
>
> This creates a linear shadow image in GART that gets blitted to at the
> image transition.
>
> Now ideally:
> this would use SDMA - but we want to use SDMA for transfer queues
> maybe we don't expose a transfer queue on prime cards who knows.
>
> we wouldn't have to add two pointers to every image, but my other
> attempts at this were ugly.
>
> Is the image transition the proper place to hack this in? not
> really sure anywhere else is appropriate.
>
> It also relies on DRI_PRIME=1 being set, I should be able
> to work this out somehow automatically I think, probably getting
> a DRI3 fd from the X server and doing drmGetDevice on it, and
> comparing where we end up.
>
> Signed-off-by: Dave Airlie 
> ---
>  src/amd/vulkan/radv_cmd_buffer.c |  18 +++
>  src/amd/vulkan/radv_device.c |   3 ++
>  src/amd/vulkan/radv_meta.h   |   2 +
>  src/amd/vulkan/radv_meta_copy.c  |  31 +++
>  src/amd/vulkan/radv_private.h|   4 ++
>  src/amd/vulkan/radv_wsi.c| 111
> ++-
>  6 files changed, 144 insertions(+), 25 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_cmd_buffer.c
> b/src/amd/vulkan/radv_cmd_buffer.c
> index a2d55833..4432afc 100644
> --- a/src/amd/vulkan/radv_cmd_buffer.c
> +++ b/src/amd/vulkan/radv_cmd_buffer.c
> @@ -2296,6 +2296,20 @@ static void radv_handle_dcc_image_transition(struct
> radv_cmd_buffer *cmd_buffer,
> }
>  }
>
> +static void radv_handle_prime_image_transition(struct radv_cmd_buffer
> *cmd_buffer,
> +  struct radv_image *image,
> +  VkImageLayout src_layout,
> +  VkImageLayout dst_layout,
> +  VkImageSubresourceRange
> range,
> +  VkImageAspectFlags
> pending_clears)
> +{
> +   cmd_buffer->state.flush_bits |= RADV_CMD_FLUSH_AND_INV_FRAMEBUFFER;
> +   si_emit_cache_flush(cmd_buffer);
> +   radv_blit_to_prime_linear(cmd_buffer, image);
> +   cmd_buffer->state.flush_bits |= RADV_CMD_FLUSH_AND_INV_FRAMEBUFFER;
> +   si_emit_cache_flush(cmd_buffer);
> +}
> +
>  static void radv_handle_image_transition(struct radv_cmd_buffer
> *cmd_buffer,
>  struct radv_image *image,
>  VkImageLayout src_layout,
> @@ -2314,6 +2328,10 @@ static void radv_handle_image_transition(struct
> radv_cmd_buffer *cmd_buffer,
> if (image->surface.dcc_size)
> radv_handle_dcc_image_transition(cmd_buffer, image,
> src_layout,
>  dst_layout, range,
> pending_clears);
> +
> +   if (image->prime_image && dst_layout ==
> VK_IMAGE_LAYOUT_PRESENT_SRC_KHR)
> +   radv_handle_prime_image_transition(cmd_buffer, image,
> src_layout,
> +  dst_layout, range,
> pending_clears);
>  }
>
>  void radv_CmdPipelineBarrier(
> diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
> index c639d53..b21447f 100644
> --- a/src/amd/vulkan/radv_device.c
> +++ b/src/amd/vulkan/radv_device.c
> @@ -105,6 +105,9 @@ radv_physical_device_init(struct radv_physical_device
> *device,
> }
> drmFreeVersion(version);
>
> +   if (getenv("DRI_PRIME"))
> +   device->is_different_gpu = true;
> +
> device->_loader_data.loaderMagic = ICD_LOADER_MAGIC;
> device->instance = instance;
> assert(strlen(path) < ARRAY_SIZE(device->path));
> diff --git a/src/amd/vulkan/radv_meta.h b/src/amd/vulkan/radv_meta.h
> index 97d020c..e43a0e7 100644
> --- a/src/amd/vulkan/radv_meta.h
> +++ b/src/amd/vulkan/radv_meta.h
> @@ -186,6 +186,8 @@ void radv_meta_resolve_compute_image(struct
> radv_cmd_buffer *cmd_buffer,
>  uint32_t region_count,
>  const VkImageResolve *regions);
>
> +void radv_blit_to_prime_linear(struct radv_cmd_buffer *cmd_buffer,
> +  struct radv_image *image);
>  #ifdef __cplusplus
>  }
>  #endif
> diff --git a/src/amd/vulkan/radv_meta_copy.c
> b/src/amd/vulkan/radv_meta_copy.c
> index 4c01eb7..3fd8d0c 100644
> --- a/src/amd/vulkan/radv_meta_copy.c
> +++ b/src/amd/vulkan/radv_meta_copy.c
> @@ -397,3 +397,34 @@ void radv_CmdCopyImage(
>
> radv_meta_restore(&saved_state, cmd_buffer);
>  }
> +
> +void radv_blit_to_prime_linear(struct radv_cmd_buffer *cmd_buffer,
> +  struct radv_image *image)
> +{
> +   struct radv_meta_saved_state saved_state;
> +   struct

Re: [Mesa-dev] [PATCH] [rfc] radv: add initial prime support.

2016-11-23 Thread Mike Lothian

I think it would be good to keep the DRI_PRIME switch to allow for
switching between anvil and radv, handy for testing / comparing /
benchmarking both

It seems that Vulkan automatically uses the first card listed in vulkaninfo
(in my case it's the amdgpu card) with no way to select which is used,
hence why I've only been seeing garbage since the radv driver was added
into mesa

If DRI_PRIME=0 is passed will this now automatically use anvil?

Thanks

Mike

On Wed, 23 Nov 2016 at 10:47 Nicolai Hähnle  wrote:

> On 23.11.2016 06:28, Dave Airlie wrote:
> > From: Dave Airlie 
> >
> > This is kind of a gross hacks, but vulkan doesn't specify anything
> > but it would be nice to let people with prime systems at least
> > see some stuff rendering for now.
> >
> > This creates a linear shadow image in GART that gets blitted to at the
> > image transition.
> >
> > Now ideally:
> > this would use SDMA - but we want to use SDMA for transfer queues
> > maybe we don't expose a transfer queue on prime cards who knows.
>
> Why is there a problem here? What stops you from just having multiple
> SDMA queues?
>
>
> > we wouldn't have to add two pointers to every image, but my other
> > attempts at this were ugly.
> >
> > Is the image transition the proper place to hack this in? not
> > really sure anywhere else is appropriate.
>
> So I'm not too deep into Vulkan, but isn't conceptually the blit to
> shadow image a part of the present operation, not of the image
> transition? I'd somehow expect the present part to have its own queue
> (which could be SDMA) on which the blit happens.
>
> Cheers,
> Nicolai
>
> >
> > It also relies on DRI_PRIME=1 being set, I should be able
> > to work this out somehow automatically I think, probably getting
> > a DRI3 fd from the X server and doing drmGetDevice on it, and
> > comparing where we end up.
> >
> > Signed-off-by: Dave Airlie 
> > ---
> >  src/amd/vulkan/radv_cmd_buffer.c |  18 +++
> >  src/amd/vulkan/radv_device.c |   3 ++
> >  src/amd/vulkan/radv_meta.h   |   2 +
> >  src/amd/vulkan/radv_meta_copy.c  |  31 +++
> >  src/amd/vulkan/radv_private.h|   4 ++
> >  src/amd/vulkan/radv_wsi.c| 111
> ++-
> >  6 files changed, 144 insertions(+), 25 deletions(-)
> >
> > diff --git a/src/amd/vulkan/radv_cmd_buffer.c
> b/src/amd/vulkan/radv_cmd_buffer.c
> > index a2d55833..4432afc 100644
> > --- a/src/amd/vulkan/radv_cmd_buffer.c
> > +++ b/src/amd/vulkan/radv_cmd_buffer.c
> > @@ -2296,6 +2296,20 @@ static void
> radv_handle_dcc_image_transition(struct radv_cmd_buffer *cmd_buffer,
> >   }
> >  }
> >
> > +static void radv_handle_prime_image_transition(struct radv_cmd_buffer
> *cmd_buffer,
> > +struct radv_image *image,
> > +VkImageLayout src_layout,
> > +VkImageLayout dst_layout,
> > +VkImageSubresourceRange
> range,
> > +VkImageAspectFlags
> pending_clears)
> > +{
> > + cmd_buffer->state.flush_bits |= RADV_CMD_FLUSH_AND_INV_FRAMEBUFFER;
> > + si_emit_cache_flush(cmd_buffer);
> > + radv_blit_to_prime_linear(cmd_buffer, image);
> > + cmd_buffer->state.flush_bits |= RADV_CMD_FLUSH_AND_INV_FRAMEBUFFER;
> > + si_emit_cache_flush(cmd_buffer);
> > +}
> > +
> >  static void radv_handle_image_transition(struct radv_cmd_buffer
> *cmd_buffer,
> >struct radv_image *image,
> >VkImageLayout src_layout,
> > @@ -2314,6 +2328,10 @@ static void radv_handle_image_transition(struct
> radv_cmd_buffer *cmd_buffer,
> >   if (image->surface.dcc_size)
> >   radv_handle_dcc_image_transition(cmd_buffer, image,
> src_layout,
> >dst_layout, range,
> pending_clears);
> > +
> > + if (image->prime_image && dst_layout ==
> VK_IMAGE_LAYOUT_PRESENT_SRC_KHR)
> > + radv_handle_prime_image_transition(cmd_buffer, image,
> src_layout,
> > +dst_layout, range,
> pending_clears);
> >  }
> >
> >  void radv_CmdPipelineBarrier(
> > diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
> > index c639d53..b21447f 100644
> > --- a/src/amd/vulkan/radv_device.c
> > +++ b/src/amd/vulkan/radv_device.c
> > @@ -105,6 +105,9 @@ radv_physical_device_init(struct
> radv_physical_device *device,
> >   }
> >   drmFreeVersion(version);
> >
> > + if (getenv("DRI_PRIME"))
> > + device->is_different_gpu = true;
> > +
> >   device->_loader_data.loaderMagic = ICD_LOADER_MAGIC;
> >   device->instance = instance;
> >   assert(strlen(path) < ARRAY_SIZE(device->path));
> > diff --git a/src/amd/vulkan/radv_meta.h b/src/amd/vulkan/radv_meta.h
> > index 97d020c..e43a0e7 100644
> > --- a/src/amd/vulkan/rad

Re: [Mesa-dev] [PATCH] [rfc] radv: add initial prime support.

2016-11-23 Thread Mike Lothian

It works with the Talos Principle and performs well, I'm seeing some
artefacts in the grass which can be seen in https://imgur.com/a/3litB I'm
not sure if that's caused by one of the LLVM bugs that have been mentioned

On Wed, 23 Nov 2016 at 11:13 Mike Lothian  wrote:

> I think it would be good to keep the DRI_PRIME switch to allow for
> switching between anvil and radv, handy for testing / comparing /
> benchmarking both
>
> It seems that Vulkan automatically uses the first card listed in
> vulkaninfo (in my case it's the amdgpu card) with no way to select which is
> used, hence why I've only been seeing garbage since the radv driver was
> added into mesa
>
> If DRI_PRIME=0 is passed will this now automatically use anvil?
>
> Thanks
>
> Mike
>
> On Wed, 23 Nov 2016 at 10:47 Nicolai Hähnle  wrote:
>
> On 23.11.2016 06:28, Dave Airlie wrote:
> > From: Dave Airlie 
> >
> > This is kind of a gross hacks, but vulkan doesn't specify anything
> > but it would be nice to let people with prime systems at least
> > see some stuff rendering for now.
> >
> > This creates a linear shadow image in GART that gets blitted to at the
> > image transition.
> >
> > Now ideally:
> > this would use SDMA - but we want to use SDMA for transfer queues
> > maybe we don't expose a transfer queue on prime cards who knows.
>
> Why is there a problem here? What stops you from just having multiple
> SDMA queues?
>
>
> > we wouldn't have to add two pointers to every image, but my other
> > attempts at this were ugly.
> >
> > Is the image transition the proper place to hack this in? not
> > really sure anywhere else is appropriate.
>
> So I'm not too deep into Vulkan, but isn't conceptually the blit to
> shadow image a part of the present operation, not of the image
> transition? I'd somehow expect the present part to have its own queue
> (which could be SDMA) on which the blit happens.
>
> Cheers,
> Nicolai
>
> >
> > It also relies on DRI_PRIME=1 being set, I should be able
> > to work this out somehow automatically I think, probably getting
> > a DRI3 fd from the X server and doing drmGetDevice on it, and
> > comparing where we end up.
> >
> > Signed-off-by: Dave Airlie 
> > ---
> >  src/amd/vulkan/radv_cmd_buffer.c |  18 +++
> >  src/amd/vulkan/radv_device.c |   3 ++
> >  src/amd/vulkan/radv_meta.h   |   2 +
> >  src/amd/vulkan/radv_meta_copy.c  |  31 +++
> >  src/amd/vulkan/radv_private.h|   4 ++
> >  src/amd/vulkan/radv_wsi.c| 111
> ++-
> >  6 files changed, 144 insertions(+), 25 deletions(-)
> >
> > diff --git a/src/amd/vulkan/radv_cmd_buffer.c
> b/src/amd/vulkan/radv_cmd_buffer.c
> > index a2d55833..4432afc 100644
> > --- a/src/amd/vulkan/radv_cmd_buffer.c
> > +++ b/src/amd/vulkan/radv_cmd_buffer.c
> > @@ -2296,6 +2296,20 @@ static void
> radv_handle_dcc_image_transition(struct radv_cmd_buffer *cmd_buffer,
> >   }
> >  }
> >
> > +static void radv_handle_prime_image_transition(struct radv_cmd_buffer
> *cmd_buffer,
> > +struct radv_image *image,
> > +VkImageLayout src_layout,
> > +VkImageLayout dst_layout,
> > +VkImageSubresourceRange
> range,
> > +VkImageAspectFlags
> pending_clears)
> > +{
> > + cmd_buffer->state.flush_bits |= RADV_CMD_FLUSH_AND_INV_FRAMEBUFFER;
> > + si_emit_cache_flush(cmd_buffer);
> > + radv_blit_to_prime_linear(cmd_buffer, image);
> > + cmd_buffer->state.flush_bits |= RADV_CMD_FLUSH_AND_INV_FRAMEBUFFER;
> > + si_emit_cache_flush(cmd_buffer);
> > +}
> > +
> >  static void radv_handle_image_transition(struct radv_cmd_buffer
> *cmd_buffer,
> >struct radv_image *image,
> >VkImageLayout src_layout,
> > @@ -2314,6 +2328,10 @@ static void radv_handle_image_transition(struct
> radv_cmd_buffer *cmd_buffer,
> >   if (image->surface.dcc_size)
> >   radv_handle_dcc_image_transition(cmd_buffer, image,
> src_layout,
> >dst_layout, range,
> pending_clears);
> > +
> > + if (image->prime_image && dst_layout ==
> VK_IMAGE_LAYOUT_PRESENT_SRC_KHR)
> > + radv_handle_prime_image_

Re: [Mesa-dev] [PATCH] [rfc] radv: add initial prime support.

2016-12-09 Thread Mike Lothian

Hi

This no longer applies cleanly since radv/meta: cleanup image info setup.
 71a9574ffa1463773ad7587262bacc50ed37c042

Regards

Mike

On Wed, 23 Nov 2016 at 05:29 Dave Airlie  wrote:

> From: Dave Airlie 
>
> This is kind of a gross hacks, but vulkan doesn't specify anything
> but it would be nice to let people with prime systems at least
> see some stuff rendering for now.
>
> This creates a linear shadow image in GART that gets blitted to at the
> image transition.
>
> Now ideally:
> this would use SDMA - but we want to use SDMA for transfer queues
> maybe we don't expose a transfer queue on prime cards who knows.
>
> we wouldn't have to add two pointers to every image, but my other
> attempts at this were ugly.
>
> Is the image transition the proper place to hack this in? not
> really sure anywhere else is appropriate.
>
> It also relies on DRI_PRIME=1 being set, I should be able
> to work this out somehow automatically I think, probably getting
> a DRI3 fd from the X server and doing drmGetDevice on it, and
> comparing where we end up.
>
> Signed-off-by: Dave Airlie 
> ---
>  src/amd/vulkan/radv_cmd_buffer.c |  18 +++
>  src/amd/vulkan/radv_device.c |   3 ++
>  src/amd/vulkan/radv_meta.h   |   2 +
>  src/amd/vulkan/radv_meta_copy.c  |  31 +++
>  src/amd/vulkan/radv_private.h|   4 ++
>  src/amd/vulkan/radv_wsi.c| 111
> ++-
>  6 files changed, 144 insertions(+), 25 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_cmd_buffer.c
> b/src/amd/vulkan/radv_cmd_buffer.c
> index a2d55833..4432afc 100644
> --- a/src/amd/vulkan/radv_cmd_buffer.c
> +++ b/src/amd/vulkan/radv_cmd_buffer.c
> @@ -2296,6 +2296,20 @@ static void radv_handle_dcc_image_transition(struct
> radv_cmd_buffer *cmd_buffer,
> }
>  }
>
> +static void radv_handle_prime_image_transition(struct radv_cmd_buffer
> *cmd_buffer,
> +  struct radv_image *image,
> +  VkImageLayout src_layout,
> +  VkImageLayout dst_layout,
> +  VkImageSubresourceRange
> range,
> +  VkImageAspectFlags
> pending_clears)
> +{
> +   cmd_buffer->state.flush_bits |= RADV_CMD_FLUSH_AND_INV_FRAMEBUFFER;
> +   si_emit_cache_flush(cmd_buffer);
> +   radv_blit_to_prime_linear(cmd_buffer, image);
> +   cmd_buffer->state.flush_bits |= RADV_CMD_FLUSH_AND_INV_FRAMEBUFFER;
> +   si_emit_cache_flush(cmd_buffer);
> +}
> +
>  static void radv_handle_image_transition(struct radv_cmd_buffer
> *cmd_buffer,
>  struct radv_image *image,
>  VkImageLayout src_layout,
> @@ -2314,6 +2328,10 @@ static void radv_handle_image_transition(struct
> radv_cmd_buffer *cmd_buffer,
> if (image->surface.dcc_size)
> radv_handle_dcc_image_transition(cmd_buffer, image,
> src_layout,
>  dst_layout, range,
> pending_clears);
> +
> +   if (image->prime_image && dst_layout ==
> VK_IMAGE_LAYOUT_PRESENT_SRC_KHR)
> +   radv_handle_prime_image_transition(cmd_buffer, image,
> src_layout,
> +  dst_layout, range,
> pending_clears);
>  }
>
>  void radv_CmdPipelineBarrier(
> diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
> index c639d53..b21447f 100644
> --- a/src/amd/vulkan/radv_device.c
> +++ b/src/amd/vulkan/radv_device.c
> @@ -105,6 +105,9 @@ radv_physical_device_init(struct radv_physical_device
> *device,
> }
> drmFreeVersion(version);
>
> +   if (getenv("DRI_PRIME"))
> +   device->is_different_gpu = true;
> +
> device->_loader_data.loaderMagic = ICD_LOADER_MAGIC;
> device->instance = instance;
> assert(strlen(path) < ARRAY_SIZE(device->path));
> diff --git a/src/amd/vulkan/radv_meta.h b/src/amd/vulkan/radv_meta.h
> index 97d020c..e43a0e7 100644
> --- a/src/amd/vulkan/radv_meta.h
> +++ b/src/amd/vulkan/radv_meta.h
> @@ -186,6 +186,8 @@ void radv_meta_resolve_compute_image(struct
> radv_cmd_buffer *cmd_buffer,
>  uint32_t region_count,
>  const VkImageResolve *regions);
>
> +void radv_blit_to_prime_linear(struct radv_cmd_buffer *cmd_buffer,
> +  struct radv_image *image);
>  #ifdef __cplusplus
>  }
>  #endif
> diff --git a/src/amd/vulkan/radv_meta_copy.c
> b/src/amd/vulkan/radv_meta_copy.c
> index 4c01eb7..3fd8d0c 100644
> --- a/src/amd/vulkan/radv_meta_copy.c
> +++ b/src/amd/vulkan/radv_meta_copy.c
> @@ -397,3 +397,34 @@ void radv_CmdCopyImage(
>
> radv_meta_restore(&saved_state, cmd_buffer);
>  }
> +
> +void radv_blit_to_prime_linear(struct radv_cmd_buffer *cmd_buffer,
> +  struct radv

Re: [Mesa-dev] [PATCH 0/5] nvc0: better instruction pipelining for Maxwell GPUs

2016-12-23 Thread Mike Lothian

Thanks for all your work on Nouveau and I look forward to your
contributions to radeonsi

On Thu, 22 Dec 2016 at 23:16 Samuel Pitoiset 
wrote:

> Hello,
>
> This series makes use of the scheduling control code in order to improve
> the
> instruction pipelining on Maxwell GPUs.
>
> Starting with the Kepler architecture, where a control instruction has to
> be
> inserted every 7 instructions, Maxwell added additional control codes and
> the
> control instruction now has to be every 3 instructions. Maxwell control
> codes
> are really powerful and well documented [1]. By the way, I would like to
> thank
> Scott Gray who did an awesome reverse engineering work, although I had to
> figure out the missing parts myself.
>
> On Maxwell, control codes are mainly used for setting the number of stall
> counts and for producing/consumming dependency barriers in order to avoid
> hazards. I'm not going to explain in details how do they work because the
> documentation is quite good and because I added explanations here and there
> in the source code. But the main thing to understand is that the previous
> control code used by default (ie. st 0x0) means "wait for all dependencies
> and stall the pipeline for 15 cycles which is the maximum".
> Which is quite bad...
>
> Now, let's have a look at the (impressive) performance improvements. :-)
> I measured on a GeForce GTX 750 Ti (GM107) reclocked to the highest perf
> level,
> with and without the control codes (NV50_PROG_SCHED=0/1).
>
> app: number of FPS without -> number of FPS with (+gain%)
>
> FurMark:   13  ->  42  (+223%)
> Pixmark Piano: 2   ->  7   (+250%)
> Pixmark Volposion: 6   ->  20  (+233%)
> Julia F32: 61  ->  219 (+259%)
> LightMarks:352 ->  685 (+94%)
> Heaven (low):  51  ->  102 (+100%)
> Heaven (ultra):14  ->  27  (+93%)
> Valley (low):  30  ->  68  (+126%)
> Valley (ultra):18  ->  39  (+100%)
> Talos (low):   32  ->  50  (+56%)
> Talos (ultra): 7   ->  14  (+100%)
> Shadow of Mordor (lowest): 13  ->  20  (+53%)
>
> That's it! I think it's enough to understand the power of Maxwell control
> codes. We may get additional numbers from Phoronix (wink, wink, Michael).
> As I said in the main patch, the control codes can be disabled with
> 'export NV50_PROG_SCHED=0'.
>
> Now, let's have a look how nouveau performs compared to NVIDIA's blob.
>
> FurMark:   42  ->  59   (+40%)
> Pixmark Piano: 7   ->  13   (+85%)
> Pixmark Volposion: 20  ->  42   (+110%)
> Julia F32: 219 ->  351  (+60%)
> LightMarks:685 ->  1192 (+74%)
> Heaven (low):  102 ->  144  (+41%)
> Heaven (ultra):27  ->  46   (+70%)
> Valley (low):  68  ->  94   (+38%)
> Valley (ultra):39  ->  60   (+53%)
> Talos (low):   50  ->  128  (+156%)
> Talos (ultra): 14  ->  30   (+114%)
> Shadow of Mordor (lowest): 20  ->  77   (+285%)
>
> Nouveau is still far away from the blob, but now I think Maxwell is
> actually
> in roughly the same shape as Kepler in terms of performance and features.
> Speaking about this, I will enable OpenGL 4.3 on Maxwell in a separate
> patch,
> later on.
>
> The overhead at compile time added by this seris is rather small. For a
> full
> shader-db run with my private repository of shaders, it takes approximately
> 208s for compiling 25k shaders before the series and approximately 211s
> after.
> Less than 2% of overhead and it's comparable to a full shader-db run on
> Kepler.
>
> No regressions with both piglit and dEQP (tested multiple times) and all
> benchmarks/games I have tried render fine and seem to be quite stable.
>
> Due to a lack of time, some parts are still left to do and some others
> could
> be improved. With the following ideas implemented I'm pretty sure we can
> improve performance significantly.
>
> * Add support for the yield flag. This seems to be a hint to the hardware
> for
>   improving how the work is balanced between the warps. I didn't figure out
>   how and where to use it without breaking a bunch of things. Need time and
>   patience.
>
> * Add support for dual-issue, the rules are pretty different than Kepler
>   especially because of the dependency barriers. Note that the yield flag
> has
>   to be set, otherwise the hardware won't dual-issue and in fact it will
> wait
>   for all dependencies (ie. st 0x0) which is really different that what you
>   are looking for.
>
> * Reduce stall counts. A bunch of instructions have a read latency which
> is the
>   number of cycles before they can actually read the sources. This should
> be
>   fairly easy to implement but will require some reverse engineering to
>   completely understand the idea.
>
> This is my last contribution for the Nouveau driver for a while because I
> have
> been hired by Valve to work on radeonsi. Do not expec

Re: [Mesa-dev] Testing patches 9987 and 9988

2016-07-19 Thread Mike Lothian

Hi

You're best replying directly to the posts on the mailing list for these.
Most folk won't know the their patch series by their patchwork ID

I think Marek posted a branch with his patches applied, it might be easier
to test that, I'm sure he'll rebase his patches after review

Cheers

Mike

On Tue, 19 Jul 2016, 2:54 p.m. ⚛, <0xe2.0x9a.0...@gmail.com> wrote:

> Hello
>
> I would like to test http://patchwork.freedesktop.org/series/9987/ and
> http://patchwork.freedesktop.org/series/9988/ but the mbox patches
> aren't compatible with mesa-git.
>
> Would it be possible to update 9987 and 9988 to match mesa-git?
>
> Do 9987 and 9988 assume additional public patches that need to be
> applied prior to them?
>
> Thanks
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/3] configure.ac: report an error if LLVM shared libs are disabled and CL is enabled

2013-10-08 Thread Mike Lothian

Just had a failure because of this - should the default for shared libs not
be yes now?


On 7 October 2013 13:27, Tom Stellard  wrote:

> On Mon, Oct 07, 2013 at 01:05:15PM +0200, Marek Olšák wrote:
> > From: Marek Olšák 
> >
>
> Reviewed-by: Tom Stellard 
>
> > ---
> >  configure.ac | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/configure.ac b/configure.ac
> > index 559c9a3..6158c6e 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -1532,8 +1532,9 @@ AC_ARG_WITH([llvm-shared-libs],
> >  [with_llvm_shared_libs=no])
> >  AS_IF([test x$enable_opencl = xyes],
> >  [
> > -AC_MSG_WARN([OpenCL required, forcing LLVM shared libraries])
> > -with_llvm_shared_libs=yes
> > +if test "x$with_llvm_shared_libs" != xyes; then
> > +AC_MSG_ERROR([OpenCL requires LLVM shared libraries])
> > +fi
> >  ])
> >
> >  AC_ARG_WITH([llvm-prefix],
> > --
> > 1.8.1.2
> >
> > ___
> > 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 mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 0/3] Enable GL 3.2 support for i965, bump Mesa version.

2013-10-11 Thread Mike Lothian

Well done on getting this enabled

Out of interest how far is SandyBridge from 3.2?

Cheers

Mike
On 11 Oct 2013 05:28, "Paul Berry"  wrote:

> It's been a long and rocky road, but geometry shader support in Mesa's
> i965/gen7 driver has finally reached a point I'm willing to call
> "feature complete".  Since geometry shaders were the last remaining
> feature needed for GL 3.2, it's time to turn on GL 3.2 support.  Here
> is a short patch series to turn it on.
>
> Patch 1 enables GLSL 1.50 and GL 3.2 for i965/gen7 parts (Ivy Bridge
> and Haswell).  Patch 2 removes the old warning message "Geometry
> shader support is currently experimental".  Patch 3 bumps the Mesa
> major version from 9 to 10 to reflect the fact that we now support a
> new version of OpenGL.
>
> Note: although geometry shaders are feature complete, there are still
> a few bugs that I still need to iron out before the next release.
> Here is a list of all the current GLSL 1.50 and GL 3.2 piglit failures
> on Ivy Bridge and Haswell.  With a few minor exceptions that are
> unfixable due to hardware limitations, or which are too obscure to be
> worth fixing, I believe I can take care of all of these by the Nov 27
> release date.
>
> OpenGL 3.2 piglit failures:
> --
>
> - layered-rendering/clear-{color,depth}: It appears that our glClear
>   implementation doesn't clear all layers of a layered attachment.
>
> -
> layered-rendering/{framebuffer-layered-attachments,framebuffertexture-defaults}:
>   I have not investigated, but I believe Jordan Justen may be working
>   on this.
>
> - minmax: GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS has the wrong value.
>
> GLSL 1.50 piglit failures:
> -
>
> - built-in constants/* (9 failures) and compiler/constants.geom: a few
>   new GLSL 1.50 built-in constants aren't being set up properly.
>
> -
> compiler/{vs,gs}-redeclares-pervertex-out-{after,after-other,before}-global-redeclaration.geom:
>   We're not flagging an error if both gl_PerVertex and one of its
>   members are redeclared.
>
> -
> compiler/incorrect-{in,out}-layout-qualifiers-with-variable-declarations.geom:
>   We're not flagging an error if GS layout qualifiers are improperly
>   applied to variables.
>
> - compiler/interface-blocks-name-reused-globally.vert: We're not
>   flagging an error if an interface block name conflicts with a global
>   variable name.
>
> - compiler/interface-blocks-structs-defined-within-block-instanced.vert:
>   We're not flagging an error if a struct is defined inside an
>   interface block.
>
> - compiler/layout-fs-no-output.frag: We're not flagging an error if GS
>   layout qualifiers are used in a non-geometry shader.
>
> - compiler/layout-not-case-sensitive-{in,max-vert,out}.geom and
>   compiler/layout-not-case-sensitive.frag: Layout qualifiers should be
>   case-insensitive--they are not.
>
> - compiler/layout-vs-no-{input,output}.vert: We're not flagging an
>   error if GS layout qualifiers are used in a non-geometry shader.
>
> - execution/geometry/clip-distance-bulk-copy: Test is broken.  I have
>   a patch on the Piglit list to fix this.
>
> - execution/geometry/triangle-strip-orientation (Ivy Bridge only):
>   Vertices in triangle strips are improperly ordered.  I am working on
>   a fix for this.
>
> - glsl-1.50-geometry-primitive-id-restart GL_POINTS other (Ivy Bridge
>   only): A hardware workaround is required.  I am working on a fix for
>   this.
>
> - glsl-1.50-geometry-primitive-types * (10 failures): Failing due to
>   bugs in transform feedback (I accidentally dropped a patch from
>   Bryan Cain's original geometry shader series).  I am working on a
>   fix for this.
>
> - glsl-1.50-geometry-tri-strip-ordering-with-prim-restart * (4
>   failures): Vertices in triangle strips are improperly ordered.  I am
>   working on a fix for this.
>
> -
> linker/interstage-{pervertex,pervertex-in,pervertex-out}-redeclaration-unneeded:
>   We're not accounting for the fact that a compilation unit is not
>   required to redeclare gl_PerVertex if it does not use it.
>
> - query-gs-prim-types: New geometry shader informational queries are
>   not implemented yet.
>
> [PATCH 1/3] i965: Turn on GLSL 1.50 and GL 3.2 support for i965 gen7.
> [PATCH 2/3] mesa: Remove warning that geometry shader support is
> experimental.
> [PATCH 3/3] mesa: Bump version to 10.0.0.
> ___
> 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] [Bug 70410] egl-static/Makefile: linking fails with llvm >= 3.4

2013-10-12 Thread Mike Lothian

Out of interest which compiler are you using and which linker?

I'm sure I was seeing this with gcc 4.7 and ld.bfd but not on my gcc 4.8
system with ld.gold (both llvm's were compiled with the gold use flag
though)

I've not seen any issues on the gcc 4.7 system since upgrading to 4.8 still
with ld.bfd

I did have --disable-terminfo in the llvm build in my overlay but I figured
the problem was fixed so removed it and carried on using  from portage
- hopefully we can figure out the root cause though


On 13 October 2013 01:07,  wrote:

>   *Comment # 3  on bug
> 70410  from David
> "okias" Heidelberger  *
>
> --enable-terminfo=no
> --enable-curses=no
> it works well, after this. Thank you.
>
> But it has still problem described in bugreport (if this two options arent
> passed to llvm).
>
>  --
> You are receiving this mail because:
>
>- 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 mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] texelFetch*Offset from EXT_gpu_shader4

2013-10-14 Thread Mike Lothian

Hi

I'm going to try adding in support for texelFetch*Offset to try and get
anti aliasing working in the Unigine demos

I'm not sure if anything more will be required but I just wanted to check
no one else is working on this

Thanks

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

Re: [Mesa-dev] [PATCH 3/3] mesa: Bump version to 11.0.0.

2013-10-18 Thread Mike Lothian

It seems a bit silly to skip version 10 entirely

Is this really necessary?
On 18 Oct 2013 07:57, "Kenneth Graunke"  wrote:

> Mesa now supports OpenGL 3.3 and GLSL 3.30, so bump the Mesa major
> version from 10 to 11 to reflect this.
>
> Also update the release notes, and add appropriate FAQ entries.
>
> http://en.wikipedia.org/wiki/Up_to_eleven
>
> Signed-off-by: Kenneth Graunke 
> Reviewed-by: Matt Turner 
> ---
>  VERSION |  2 +-
>  docs/relnotes.html  |  3 +-
>  docs/relnotes/10.0.html | 65 
>  docs/relnotes/11.0.html | 80
> +
>  4 files changed, 83 insertions(+), 67 deletions(-)
>  delete mode 100644 docs/relnotes/10.0.html
>  create mode 100644 docs/relnotes/11.0.html
>
> diff --git a/VERSION b/VERSION
> index 8e92e83..2b1181d 100644
> --- a/VERSION
> +++ b/VERSION
> @@ -1 +1 @@
> -10.0.0-devel
> +11.0.0-devel
> diff --git a/docs/relnotes.html b/docs/relnotes.html
> index 82072dd..fb31555 100644
> --- a/docs/relnotes.html
> +++ b/docs/relnotes.html
> @@ -21,7 +21,8 @@ The release notes summarize what's new or changed in
> each Mesa release.
>  
>
>  
> -10.0 release notes
> +11.0 release notes
> +Mesa 10.0 was never released.
>  9.2.1 release notes
>  9.2 release notes
>  9.1.7 release notes
> diff --git a/docs/relnotes/10.0.html b/docs/relnotes/10.0.html
> deleted file mode 100644
> index 0b25f49..000
> --- a/docs/relnotes/10.0.html
> +++ /dev/null
> @@ -1,65 +0,0 @@
> - http://www.w3.org/TR/html4/loose.dtd";>
> -
> -
> -  
> -  Mesa Release Notes
> -  
> -
> -
> -
> -
> -  The Mesa 3D Graphics Library
> -
> -
> -
> -
> -
> -Mesa 10.0 Release Notes / TBD
> -
> -
> -Mesa 10.0 is a new development release.
> -People who are concerned with stability and reliability should stick
> -with a previous release or wait for Mesa 10.0.1.
> -
> -
> -Mesa 10.0 implements the OpenGL 3.3 API, but the version reported by
> -glGetString(GL_VERSION) or glGetIntegerv(GL_MAJOR_VERSION) /
> -glGetIntegerv(GL_MINOR_VERSION) depends on the particular driver being
> used.
> -Some drivers don't support all the features required in OpenGL 3.3.
>  OpenGL
> -3.3 is only available if requested at context creation
> -because compatibility contexts are not supported.
> -
> -
> -
> -MD5 checksums
> -
> -TBD.
> -
> -
> -
> -New features
> -
> -
> -Note: some of the new features are only available with certain drivers.
> -
> -
> -
> -GL_AMD_seamless_cubemap_per_texture on i965.
> -GL_ARB_conservative_depth on i965.
> -GL_ARB_texture_gather on i965.
> -GL_ARB_texture_query_levels on i965.
> -GL_KHR_debug
> -
> -
> -
> -Bug fixes
> -
> -TBD.
> -
> -Changes
> -
> -TBD.
> -
> -
> -
> -
> diff --git a/docs/relnotes/11.0.html b/docs/relnotes/11.0.html
> new file mode 100644
> index 000..2fb8135
> --- /dev/null
> +++ b/docs/relnotes/11.0.html
> @@ -0,0 +1,80 @@
> + http://www.w3.org/TR/html4/loose.dtd";>
> +
> +
> +  
> +  Mesa Release Notes
> +  
> +
> +
> +
> +
> +  The Mesa 3D Graphics Library
> +
> +
> +
> +
> +
> +Mesa 11.0 Release Notes / TBD
> +
> +
> +Mesa 11.0 is a new development release.
> +People who are concerned with stability and reliability should stick
> +with a previous release or wait for Mesa 11.0.1.
> +
> +
> +
> +Mesa 11.0 implements the OpenGL 3.3 API, but the version reported by
> +glGetString(GL_VERSION) or glGetIntegerv(GL_MAJOR_VERSION) /
> +glGetIntegerv(GL_MINOR_VERSION) depends on the particular driver being
> used.
> +Some drivers don't support all the features required in OpenGL 3.3.
>  OpenGL
> +3.3 is only available if requested at context creation
> +because compatibility contexts are not supported.
> +
> +
> +FAQ
> +
> +Q: What happened to Mesa 10.0?
> +
> +  A: The Mesa community increases the major version number each
> time
> +  the project gains support for a new version of desktop OpenGL.  Mesa 9.2
> +  supported OpenGL 3.1.  When it gained support for OpenGL 3.2, it became
> +  Mesa 10.0.  But before Mesa 10.0 was ever released, the developers
> +  completed OpenGL 3.3 support, causing the version to increase to 11.0.
> +
> +Q: Why didn't you just make Mesa 10.0 better?
> +
> +  A: This Mesa  href="http://en.wikipedia.org/wiki/Up_to_eleven";>goes
> to eleven.
> +
> +
> +MD5 checksums
> +
> +TBD.
> +
> +
> +
> +New features
> +
> +
> +Note: some of the new features are only available with certain drivers.
> +
> +
> +
> +GL_AMD_seamless_cubemap_per_texture on i965.
> +GL_ARB_conservative_depth on i965.
> +GL_ARB_texture_gather on i965.
> +GL_ARB_texture_query_levels on i965.
> +GL_KHR_debug
> +
> +
> +
> +Bug fixes
> +
> +TBD.
> +
> +Changes
> +
> +TBD.
> +
> +
> +
> +
> --
> 1.8.3.2
>
> ___
> 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/li

Re: [Mesa-dev] [PATCH] clover: fix build with LLVM 3.4

2013-11-03 Thread Mike Lothian

This fixes the build for me

Feel free to add my tested by


On 1 November 2013 15:25, Aaron Watry  wrote:

> dso_list was added as an argument for createInternalizePass in 3.4, and
> then
> it was removed again in the same llvm version.
> ---
>  src/gallium/state_trackers/clover/llvm/invocation.cpp | 5 -
>  1 file changed, 5 deletions(-)
>
> diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp
> b/src/gallium/state_trackers/clover/llvm/invocation.cpp
> index 4ae496f..3f50317 100644
> --- a/src/gallium/state_trackers/clover/llvm/invocation.cpp
> +++ b/src/gallium/state_trackers/clover/llvm/invocation.cpp
> @@ -267,12 +267,7 @@ namespace {
>   llvm::Function *kernel = *I;
>   export_list.push_back(kernel->getName().data());
>}
> -#if HAVE_LLVM < 0x0304
>PM.add(llvm::createInternalizePass(export_list));
> -#else
> -  std::vector dso_list;
> -  PM.add(llvm::createInternalizePass(export_list, dso_list));
> -#endif
>PM.run(*mod);
> }
>
> --
> 1.8.3.2
>
> ___
> 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] More projects for newbies

2013-11-23 Thread Mike Lothian

Sounds good
On 22 Nov 2013 19:05, "Ian Romanick"  wrote:

> I've posted a wiki with some project suggestions for people wanting to
> get into Mesa development:
>
> http://wiki.freedesktop.org/dri/NewbieProjects/
>
> These projects are a little bit larger than the one I previously posted
> to the mailing list
> (http://lists.freedesktop.org/archives/mesa-dev/2013-October/046374.html),
> but I've tried to be very detailed.
>
> I have two hopes for this wiki:
>
> 1. People already experienced with Mesa development will avoid these
> projects. :)
>
> 2. Other people will add projects with similar scope and level of
> detail.  For example, I think someone could probably add a project for
> GL_ARB_buffer_storage and GL_ARB_clear_texture.
> ___
> 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] mesa fail to build since llvm-3.4svn r187618

2013-08-06 Thread Mike Lothian

I'm using this patch on my system


On 6 August 2013 22:36, Laurent Carlier  wrote:

> Since llvm-3.4svn r187618 TargetOptions doesn't provide anymore
> RealignStack:
>
> make[3]: Entering directory
> `/home/lordh/archdevel/mesa/git/mesatst/src/gallium/auxiliary'
>   CXX  gallivm/lp_bld_misc.lo
> gallivm/lp_bld_misc.cpp: In function 'LLVMBool
> lp_build_create_jit_compiler_for_module(LLVMOpaqueExecutionEngine**,
> LLVMModuleRef, unsigned int, int, char**)':
> gallivm/lp_bld_misc.cpp:276:12: error: 'class llvm::TargetOptions' has no
> member named 'RealignStack'
> options.RealignStack = true;
> ^
> make[3]: *** [gallivm/lp_bld_misc.lo] Error 1
>
> Commenting the line seems to fix the problem
> --
> Laurent Carlier
> ArchLinux Developer
> http://www.archlinux.org
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>


0001-Quick-fix-for-llvm-3.4-since-removal-of-realign-stac.patch
Description: Binary data
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH mesa 3/3] egl: Update to Wayland 1.2 server API

2013-08-09 Thread Mike Lothian

Hi

I seem to have a missing symbol wayland_drm_buffer_get in libgbm.so.1

I'm pretty sure its related

Regards

Mike
On 18 Jul 2013 13:15, "Ander Conselvan de Oliveira" <
ander.conselvan.de.olive...@intel.com> wrote:

> Since Wayland 1.2, struct wl_buffer and a few functions are deprecated.
>
> References to wl_buffer are replaced with wl_resource and some getter
> functions and calls to deprecated functions are replaced with the proper
> new API. The latter changes are related to resource versioning.
>
> Signed-off-by: Ander Conselvan de Oliveira <
> ander.conselvan.de.olive...@intel.com>
> ---
>  docs/specs/WL_bind_wayland_display.spec|  8 ++-
>  include/EGL/eglmesaext.h   |  6 +-
>  src/egl/drivers/dri2/egl_dri2.c| 28 +
>  src/egl/drivers/dri2/egl_dri2.h|  1 -
>  src/egl/main/eglapi.c  |  2 +-
>  src/egl/main/eglapi.h  |  2 +-
>  src/egl/wayland/wayland-drm/wayland-drm.c  | 66
> +-
>  src/egl/wayland/wayland-drm/wayland-drm.h  | 13 +++--
>  .../state_trackers/egl/common/egl_g3d_api.c|  2 +-
>  .../state_trackers/egl/common/egl_g3d_image.c  |  4 +-
>  .../egl/common/native_wayland_bufmgr.h |  6 +-
>  .../egl/common/native_wayland_drm_bufmgr.c | 25 +---
>  src/gbm/backends/dri/gbm_dri.c |  5 +-
>  13 files changed, 99 insertions(+), 69 deletions(-)
>
> diff --git a/docs/specs/WL_bind_wayland_display.spec
> b/docs/specs/WL_bind_wayland_display.spec
> index 02bd6ea..8f0083c 100644
> --- a/docs/specs/WL_bind_wayland_display.spec
> +++ b/docs/specs/WL_bind_wayland_display.spec
> @@ -17,7 +17,7 @@ Status
>
>  Version
>
> -Version 1, March 1, 2011
> +Version 5, July 16, 2013
>
>  Number
>
> @@ -57,7 +57,7 @@ New Procedures and Functions
>   struct wl_display *display);
>
>  EGLBoolean eglQueryWaylandBufferWL(EGLDisplay dpy,
> -   struct wl_buffer *buffer,
> +   struct wl_resource *buffer,
> EGLint attribute, EGLint *value);
>
>  New Tokens
> @@ -173,3 +173,7 @@ Revision History
>  Use EGL_TEXTURE_FORMAT, EGL_TEXTURE_RGB, and EGL_TEXTURE_RGBA,
>  and just define the new YUV texture formats.  Add support for
>  EGL_WIDTH and EGL_HEIGHT in the query attributes (Kristian
> Høgsberg)
> +Version 5, July 16, 2013
> +Change eglQueryWaylandBufferWL to take a resource pointer to the
> +buffer instead of a pointer to a struct wl_buffer, as the latter
> has
> +been deprecated. (Ander Conselvan de Oliveira)
> diff --git a/include/EGL/eglmesaext.h b/include/EGL/eglmesaext.h
> index d476d18..e0eae28 100644
> --- a/include/EGL/eglmesaext.h
> +++ b/include/EGL/eglmesaext.h
> @@ -120,15 +120,15 @@ typedef EGLDisplay (EGLAPIENTRYP
> PFNEGLGETDRMDISPLAYMESA) (int fd);
>  #define EGL_TEXTURE_Y_XUXV_WL   0x31D9
>
>  struct wl_display;
> -struct wl_buffer;
> +struct wl_resource;
>  #ifdef EGL_EGLEXT_PROTOTYPES
>  EGLAPI EGLBoolean EGLAPIENTRY eglBindWaylandDisplayWL(EGLDisplay dpy,
> struct wl_display *display);
>  EGLAPI EGLBoolean EGLAPIENTRY eglUnbindWaylandDisplayWL(EGLDisplay dpy,
> struct wl_display *display);
> -EGLAPI EGLBoolean EGLAPIENTRY eglQueryWaylandBufferWL(EGLDisplay dpy,
> struct wl_buffer *buffer, EGLint attribute, EGLint *value);
> +EGLAPI EGLBoolean EGLAPIENTRY eglQueryWaylandBufferWL(EGLDisplay dpy,
> struct wl_resource *buffer, EGLint attribute, EGLint *value);
>  #endif
>  typedef EGLBoolean (EGLAPIENTRYP PFNEGLBINDWAYLANDDISPLAYWL) (EGLDisplay
> dpy, struct wl_display *display);
>  typedef EGLBoolean (EGLAPIENTRYP PFNEGLUNBINDWAYLANDDISPLAYWL)
> (EGLDisplay dpy, struct wl_display *display);
> -typedef EGLBoolean (EGLAPIENTRYP PFNEGLQUERYWAYLANDBUFFERWL) (EGLDisplay
> dpy, struct wl_buffer *buffer, EGLint attribute, EGLint *value);
> +typedef EGLBoolean (EGLAPIENTRYP PFNEGLQUERYWAYLANDBUFFERWL) (EGLDisplay
> dpy, struct wl_resource *buffer, EGLint attribute, EGLint *value);
>
>  #endif
>
> diff --git a/src/egl/drivers/dri2/egl_dri2.c
> b/src/egl/drivers/dri2/egl_dri2.c
> index 1bce314..44fd8a8 100644
> --- a/src/egl/drivers/dri2/egl_dri2.c
> +++ b/src/egl/drivers/dri2/egl_dri2.c
> @@ -41,6 +41,10 @@
>
>  #include "egl_dri2.h"
>
> +#ifdef HAVE_WAYLAND_PLATFORM
> +#include "wayland-drm.h"
> +#endif
> +
>  const __DRIuseInvalidateExtension use_invalidate = {
> { __DRI_USE_INVALIDATE, 1 }
>  };
> @@ -1195,7 +1199,7 @@ dri2_create_image_wayland_wl_buffer(_EGLDisplay
> *disp, _EGLContext *ctx,
> EGLClientBuffer _buffer,
> const EGLint *attr_list)
>  {
> -   struct wl_drm_buffer *buffer = (struct wl_drm_buffer *) _buffer;
> +   struct wl_drm_buffer *buffer;
> struct dri2_egl_display *dri2_dp

Re: [Mesa-dev] Direct3D 9 state tracker

2013-08-09 Thread Mike Lothian

Hi Chris

Just a quick note for any Gentoo users - I've added these alternative
sources into the FireBurn overlay

You just need to set the nine use flag and you'll get Chris's versions

Cheers

Mike


On 16 July 2013 19:43, Christoph Bumiller wrote:

> So, about two months ago I had the insane idea to pick up Joakim
> Sindholt's Direct3D 9 state tracker that he'd started about 3 years ago
> with the goal to make it run StarCraft 2 so I could finally play at a
> reasonable frame rate ...
>
> With help from Joakim and advice from the wine developers, as well as
> wine's d3d9 tests, things went surprisingly smooth and my original goal
> has been achieved and surpassed, hence I thought I'd post a note here in
> case someone who doesn't yet know about it is interested in trying it out.
>
> ... Now wait, didn't we have a D3D10/11 state tracker already that we
> kicked out because it was unmaintained and not really useful ?
> Yes, but there are a couple of differences to d3d1x:
>
> - the original author has not vanished [yet] (Luca, if you can hear me:
> You cannot leave your children out to die like that !)
> - it's written in C instead of C++ and not relying on horrific multiple
> inheritance with templates hacks to make gcc generate COM-compatible
> vtables (and I'm still not sure if that actually worked)
> - gallium wasn't ready for D3D11, and still isn't (at least the pipe
> drivers aren't), but it is ready for D3D9, and all the features required
> from the pipe drivers are well tested via OpenGL
> - there are no motivating applications using Direct3D 10/11 yet (at
> least for me)
> - and most importantly, contrary to d3d1x, d3d9/st already actually
> works for real applications !
>
> So far I've tried Skyrim, Civilization 5, Anno 1404 and StarCraft 2 on
> the nvc0 and r600g drivers, which work pretty well, at up to x2 the fps
> I get with wined3d (NOTE: no thorough benchmarking done yet).
> Civilization 4 works, too, but it still has a couple of (not too severe)
> rendering issues because I didn't pay much attention to the fixed
> function pipeline and its interaction with the earlier shader versions yet.
>
> If people think it's a good idea to merge it, I'd clean up the few
> modifications I did to gallium, and, once they've been cleared, merge
> the state tracker itself.
> Unfortunately, for proper window system integration, a few modifications
> to wine are required (it used to run without them, but fully correct
> operation isn't possible like that).
>
> Here's the links to the mesa branch containing the state tracker and to
> a patched version of wine:
> https://github.com/chrisbmr/Mesa-3D/tree/gallium-nine
> https://github.com/chrisbmr/wine/tree/d3dadapter9-wip
> (The wine modifications only affect { d3d9.dll.so, gdi32.dll.so,
> user32.dll.so, wineps.drv.so and winex11.drv.so }, so you don't have to
> replace all of it).
>
> Some usage hints:
>
> https://github.com/chrisbmr/Mesa-3D/blob/gallium-nine/src/gallium/state_trackers/nine/README
>
> ___
> 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 1/6] radeon/llvm: remove uneeded inclusion

2013-03-29 Thread Mike Lothian

Hi

This include is also in
src/gallium/state_trackers/clover/llvm/invocation.cpp

diff -Naur a/src/gallium/state_trackers/clover/llvm/invocation.cpp
b/src/gallium/state_trackers/clover/llvm/invocation.cpp
--- a/src/gallium/state_trackers/clover/llvm/invocation.cpp
 2013-03-29 11:15:52.851581526 +
+++ b/src/gallium/state_trackers/clover/llvm/invocation.cpp2013-03-29
11:32:41.580559478 +
@@ -37,7 +37,6 @@
 #include 
 #include 
 #include 
-#include 
 #endif
 #include 
 #include 

Cheers

Mike



On 26 March 2013 12:11, Christian König  wrote:

> Am 26.03.2013 12:53, schrieb Michel Dänzer:
>
>  On Die, 2013-03-26 at 11:56 +0100, Christian König wrote:
>>
>>> From: Christian König 
>>>
>>> The include isn't needed and the file has moved with LLVM master.
>>>
>>> Signed-off-by: Christian König 
>>>
>> Reviewed-by: Michel Dänzer 
>>
>> The rest of the series seems unchanged, so my review of it stands.
>>
>
> How about the LLVM changes? I know we could improve WQM now that it is in
> the backend, but I would rather like to let it stay like this for another
> round (as good or as bad as it is) and try to get this patchset committed
> first.
>
> Christian.
>
> __**_
> 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 1/6] radeon/llvm: remove uneeded inclusion

2013-03-29 Thread Mike Lothian

Sorry that patch doesn't fix the build

diff -Naur a/src/gallium/state_trackers/clover/llvm/invocation.cpp
b/src/gallium/state_trackers/clover/llvm/invocation.cpp
--- a/src/gallium/state_trackers/clover/llvm/invocation.cpp 2013-03-29
12:14:25.514504748 +
+++ b/src/gallium/state_trackers/clover/llvm/invocation.cpp 2013-03-29
12:13:03.978506530 +
@@ -37,7 +37,8 @@
 #include 
 #include 
 #include 
-#include 
+#include 
+#include 
 #endif
 #include 
 #include 


This one does however



On 29 March 2013 11:40, Mike Lothian  wrote:

> Hi
>
> This include is also in
> src/gallium/state_trackers/clover/llvm/invocation.cpp
>
> diff -Naur a/src/gallium/state_trackers/clover/llvm/invocation.cpp
> b/src/gallium/state_trackers/clover/llvm/invocation.cpp
> --- a/src/gallium/state_trackers/clover/llvm/invocation.cpp
>  2013-03-29 11:15:52.851581526 +
> +++ b/src/gallium/state_trackers/clover/llvm/invocation.cpp2013-03-29
> 11:32:41.580559478 +
> @@ -37,7 +37,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #endif
>  #include 
>  #include 
>
> Cheers
>
> Mike
>
>
>
> On 26 March 2013 12:11, Christian König  wrote:
>
>> Am 26.03.2013 12:53, schrieb Michel Dänzer:
>>
>>  On Die, 2013-03-26 at 11:56 +0100, Christian König wrote:
>>>
>>>> From: Christian König 
>>>>
>>>> The include isn't needed and the file has moved with LLVM master.
>>>>
>>>> Signed-off-by: Christian König 
>>>>
>>> Reviewed-by: Michel Dänzer 
>>>
>>> The rest of the series seems unchanged, so my review of it stands.
>>>
>>
>> How about the LLVM changes? I know we could improve WQM now that it is in
>> the backend, but I would rather like to let it stay like this for another
>> round (as good or as bad as it is) and try to get this patchset committed
>> first.
>>
>> Christian.
>>
>> __**_
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> http://lists.freedesktop.org/**mailman/listinfo/mesa-dev<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] Fix Clover build with latest LLVM 3.3 snapshot

2013-03-31 Thread Mike Lothian

I've already posted this

Clover seems to be working as well as it normally does


On 31 March 2013 11:00, Armin K  wrote:

> Build tested only.
> ---
>  src/gallium/state_trackers/clover/llvm/invocation.cpp | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp
> b/src/gallium/state_trackers/clover/llvm/invocation.cpp
> index 2785d10..7971bd9 100644
> --- a/src/gallium/state_trackers/clover/llvm/invocation.cpp
> +++ b/src/gallium/state_trackers/clover/llvm/invocation.cpp
> @@ -37,7 +37,8 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
> +#include 
>  #endif
>  #include 
>  #include 
> --
> 1.8.2
>
> ___
> 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 1/7] loader: Use dlsym to get our udev symbols instead of explicit linking.

2014-01-26 Thread Mike Lothian

It also gets MetroLL working for me again - I'm just going to check for bug
reports on the graphical issues I'm seeing (which were there the last time
I got it loaded) before raising any new ones


On 26 January 2014 14:15, Alexandre Demers wrote:

> This patch fixes bug 71543 where libudev.so.0 and libudev.so.1 are in
> conflict. With this patch, I was able to launch Garry's Mod (which
> previously would crash before showing anything).
>
> So you can add
>
> Tested-by: Alexandre Demers
>
> --
> Alexandre Demers
>
>
> ___
> 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] Gallium docs online builds

2014-04-03 Thread Mike Lothian

Wow this is great. Thanks for doing this

Starting to read through it all now

Mike
On 31 Mar 2014 17:43, "Ilia Mirkin"  wrote:

> Hi everyone,
>
> I've set up a readthedocs.org build to point at the gallium docs:
>
> http://gallium.readthedocs.org/en/latest/
>
> I didn't find any publicly available built docs otherwise (except some
> rather outdated ones[1]), and this is able to build against the latest
> git and auto-updates without us doing anything (might need to set up a
> commit hook to get that to work, I'll investigate later). There are
> also versioned builds (tailing the respective branches) for 9.0 and
> later.
>
> I don't really like their default scheme, I'm more used to the
> "regular" one, it's selectable somehow (I think by making conf.py
> changes). But I thought I'd give it a shot, perhaps I'm just used to
> the other one but this one's fine too.
>
> If anyone is interested in being added as a maintainer, email me your
> readthedocs.org username. Conversely, if you hate the idea and think I
> should take this down, let me know, and I'll be happy to comply (if
> there's consensus).
>
> Cheers,
>
>   -ilia
>
> [1] http://people.freedesktop.org/~csimpson/gallium-docs/
> ___
> 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] Add #include to *_dpm.c files

2013-07-02 Thread Mike Lothian

Hi

This patch allows me to compile using GCC 4.7.3 system when using ld.bfd -
it doesn't seem to be required on my GCC 4.8.1 system using ld.gold - I'm
not sure why

Cheers

Mike


seq_file.patch
Description: Binary data
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] drm/radeon/dpm: Add #include to *_dpm.c files

2013-07-02 Thread Mike Lothian

Hi

I sent this to the wrong mailing list and it had the wrong patch format

Fixed thanks to glisse

Cheers

Mike


On 2 July 2013 21:34, Mike Lothian  wrote:

> Hi
>
> This patch allows me to compile using GCC 4.7.3 system when using ld.bfd -
> it doesn't seem to be required on my GCC 4.8.1 system using ld.gold - I'm
> not sure why
>
> Cheers
>
> Mike
>


0001-Add-include-linux-seq_file.h-to-_dpm.c-files.patch
Description: Binary data
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] R600/SI: Add pattern for zero-extending i1 to i32

2014-02-05 Thread Mike Lothian

I can confirm this fixes the opencl-example tests and bfgminer now runs
without crashing

Thanks

Mike


On 4 February 2014 03:56, Michel Dänzer  wrote:

> From: Michel Dänzer 
>
> Fixes opencl-example if_* tests with radeonsi.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74469
> Signed-off-by: Michel Dänzer 
> ---
>  lib/Target/R600/SIInstructions.td | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/lib/Target/R600/SIInstructions.td
> b/lib/Target/R600/SIInstructions.td
> index 7e37821..59fe2ae 100644
> --- a/lib/Target/R600/SIInstructions.td
> +++ b/lib/Target/R600/SIInstructions.td
> @@ -1827,6 +1827,11 @@ def : Pat <
>(V_CNDMASK_B32_e64 (i32 0), (i32 -1), $src0)
>  >;
>
> +def : Pat <
> +  (i32 (zext i1:$src0)),
> +  (V_CNDMASK_B32_e64 (i32 0), (i32 1), $src0)
> +>;
> +
>  // 1. Offset as 8bit DWORD immediate
>  def : Pat <
>(SIload_constant i128:$sbase, IMM8bitDWORD:$offset),
> --
> 1.9.rc1
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radv: take LDS into account for compute shader occupancy stats

2019-02-01 Thread Mike Lothian

Hi

I think you've left a few references to the old ac_nir_get_max_workgroup_size

FAILED: src/amd/vulkan/9198681@@vulkan_radeon@sha/radv_nir_to_llvm.c.o
x86_64-pc-linux-gnu-gcc -m32
-Isrc/amd/vulkan/9198681@@vulkan_radeon@sha -Isrc/amd/vulkan
-I../mesa-/src/amd/vulkan -Isrc/../include
-I../mesa-/src/../include -Isrc -I../mesa-/src -Isrc/mapi
rc/mesa -I../mesa-/src/gallium/include -Isrc/gallium/auxiliary
-I../mesa-/src/gallium/auxiliary -Isrc/amd -I../mesa-/src/amd
-Isrc/amd/common -I../mesa-/src/amd/common -Isrc/compiler -I.
-/src/vulkan/util -Isrc/vulkan/wsi -I../mesa-/src/vulkan/wsi
-Isrc/compiler/nir -I../mesa-/src/compiler/nir
-I/usr/lib/llvm/9/include -I/usr/include/libdrm
-fdiagnostics-color=always -DNDEBU
'-DPACKAGE_BUGREPORT="https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa";'
-DGLX_USE_TLS -DHAVE_ST_VDPAU -DENABLE_ST_OMX_BELLAGIO=0
-DENABLE_ST_OMX_TIZONIA=0 -DHAVE_X11_PLATFORM -DGLX_INDIRECT_REND
M_PLATFORM -DHAVE_SURFACELESS_PLATFORM -DENABLE_SHADER_CACHE
-DHAVE___BUILTIN_BSWAP32 -DHAVE___BUILTIN_BSWAP64 -DHAVE___BUILTIN_CLZ
-DHAVE___BUILTIN_CLZLL -DHAVE___BUILTIN_CTZ -DHAVE___BUILTIN_EXPECT -D
UILTIN_POPCOUNT -DHAVE___BUILTIN_POPCOUNTLL
-DHAVE___BUILTIN_UNREACHABLE -DHAVE_FUNC_ATTRIBUTE_CONST
-DHAVE_FUNC_ATTRIBUTE_FLATTEN -DHAVE_FUNC_ATTRIBUTE_MALLOC
-DHAVE_FUNC_ATTRIBUTE_PURE -DHAVE_FUNC_ATT
LT -DHAVE_FUNC_ATTRIBUTE_WEAK -DHAVE_FUNC_ATTRIBUTE_FORMAT
-DHAVE_FUNC_ATTRIBUTE_PACKED -DHAVE_FUNC_ATTRIBUTE_RETURNS_NONNULL
-DHAVE_FUNC_ATTRIBUTE_VISIBILITY -DHAVE_FUNC_ATTRIBUTE_ALIAS
-DHAVE_FUNC_ATT
S -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM
-DMAJOR_IN_SYSMACROS -DHAVE_SYS_SYSCTL_H -DHAVE_LINUX_FUTEX_H
-DHAVE_ENDIAN_H -DHAVE_DLFCN_H -DHAVE_STRTOF -DHAVE_MKOSTEMP
-DHAVE_POSIX_MEMALI
RTOD_L -DHAVE_DLADDR -DHAVE_DL_ITERATE_PHDR -DHAVE_ZLIB -DHAVE_PTHREAD
-DHAVE_PTHREAD_SETAFFINITY -DHAVE_LIBDRM -DHAVE_LLVM=0x0900
-DMESA_LLVM_VERSION_PATCH=0 -DHAVE_WAYLAND_PLATFORM
-DWL_HIDE_DEPRECATE
S=1 -Werror=implicit-function-declaration -Werror=missing-prototypes
-Werror=return-type -fno-math-errno -fno-trapping-math
-Wno-missing-field-initializers -Wno-format-truncation -fPIC -pthread
-D_FILE_
-D__STDC_LIMIT_MACROS -D_LARGEFILE_SOURCE -D__STDC_CONSTANT_MACROS
-fvisibility=hidden -Wno-override-init -DVK_USE_PLATFORM_XCB_KHR
-DVK_USE_PLATFORM_XLIB_KHR -DVK_USE_PLATFORM_WAYLAND_KHR -DVK_USE_PLAT
O3 -march=native -pipe -MD -MQ
'src/amd/vulkan/9198681@@vulkan_radeon@sha/radv_nir_to_llvm.c.o' -MF
'src/amd/vulkan/9198681@@vulkan_radeon@sha/radv_nir_to_llvm.c.o.d' -o
'src/amd/vulkan/9198681@@vulkan_
/amd/vulkan/radv_nir_to_llvm.c
In file included from ../mesa-/src/mesa/main/macros.h:35,
 from ../mesa-/src/amd/vulkan/radv_private.h:51,
 from ../mesa-/src/amd/vulkan/radv_nir_to_llvm.c:28:
../mesa-/src/amd/vulkan/radv_nir_to_llvm.c: In function
‘ac_translate_nir_to_llvm’:
../mesa-/src/amd/vulkan/radv_nir_to_llvm.c:3453:33: error:
implicit declaration of function ‘ac_nir_get_max_workgroup_size’; did
you mean ‘radv_nir_get_max_workgroup_size’? [-Werror=implicit-functio

ac_nir_get_max_workgroup_size(ctx.options->chip_class,
 ^
../mesa-/src/util/u_math.h:659:31: note: in definition of macro ‘MAX2’
 #define MAX2( A, B )   ( (A)>(B) ? (A) : (B) )
   ^
cc1: some warnings being treated as errors

Cheers

Mike

On Fri, 1 Feb 2019 at 11:07, Timothy Arceri  wrote:
>
> Ported from d205faeb6c96.
> ---
>  src/amd/vulkan/radv_nir_to_llvm.c |  6 +++---
>  src/amd/vulkan/radv_private.h |  3 +++
>  src/amd/vulkan/radv_shader.c  | 10 --
>  3 files changed, 14 insertions(+), 5 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_nir_to_llvm.c 
> b/src/amd/vulkan/radv_nir_to_llvm.c
> index e80938527e5..d90a4c0de1e 100644
> --- a/src/amd/vulkan/radv_nir_to_llvm.c
> +++ b/src/amd/vulkan/radv_nir_to_llvm.c
> @@ -3372,9 +3372,9 @@ ac_setup_rings(struct radv_shader_context *ctx)
> }
>  }
>
> -static unsigned
> -ac_nir_get_max_workgroup_size(enum chip_class chip_class,
> - const struct nir_shader *nir)
> +unsigned
> +radv_nir_get_max_workgroup_size(enum chip_class chip_class,
> +   const struct nir_shader *nir)
>  {
> switch (nir->info.stage) {
> case MESA_SHADER_TESS_CTRL:
> diff --git a/src/amd/vulkan/radv_private.h b/src/amd/vulkan/radv_private.h
> index 85c18906f84..e5b8286ea62 100644
> --- a/src/amd/vulkan/radv_private.h
> +++ b/src/amd/vulkan/radv_private.h
> @@ -1934,6 +1934,9 @@ void radv_compile_nir_shader(struct ac_llvm_compiler 
> *ac_llvm,
>  int nir_count,
>  const struct radv_nir_compiler_options *options);
>
> +unsigned radv_nir_get_max_workgroup_size(enum chip_class chip_class,
> +const struct nir_shader *nir);
> +
>  /* radv_shader_info.h */
>  s

Re: [Mesa-dev] [PATCH] meson: drop the xcb-xrandr version requirement

2019-02-04 Thread Mike Lothian

I'm a bit confused by this patch

It's in a section called xlib_lease, for leases to work I think the
newer version is required, but I think the underlying code was changed
to build without the newer headers

Do leases work with the old code, or should this section be renamed?

On Sun, 3 Feb 2019 at 11:52, Erik Faye-Lund
 wrote:
>
> On Sat, 2019-02-02 at 12:58 -0500, Marek Olšák wrote:
> >
> >
> > On Sat, Feb 2, 2019, 12:41 PM Eric Engestrom <
> > eric.engest...@intel.com wrote:
> > > On Saturday, 2019-02-02 10:32:15 -0500, Marek Olšák wrote:
> > > > On Sat, Feb 2, 2019, 7:17 AM Eric Engestrom <
> > > eric.engest...@intel.com wrote:
> > > >
> > > > > On Friday, 2019-02-01 15:42:17 -0500, Marek Olšák wrote:
> > > > > > If there is no feedback soon, I'll push this.
> > > > >
> > > > > Have you tested that xcb-randr < 1.12 works?
> > > > > Probably shouldn't remove a restriction unless you're sure it
> > > isn't
> > > > > needed :)
> > > > >
> > > >
> > > > Is this a joke? I'm just mirroring autotools. Supporting the same
> > > linux
> > > > distributions as autotools is a requirement for meson's general
> > > acceptance.
> > >
> > > No, I'm being serious: just because a restriction didn't exist on
> > > autotools doesn't mean that code path was exercised by people
> > > running
> > > an old xcb-randr, hence the need to test it :)
> > >
> > > I didn't mean to offend you, I was just asking the question to make
> > > sure
> > > this was tested before we claim to support xcb-randr < 1.12, as it
> > > might
> > > be that autotools was simply missing the version check.
> >
> > Ok. I use old xcb-xrandr on some of my systems, one of them used to
> > be my main system. Not being able to use meson on those systems
> > without this patch is a big deal for me.
>
> This sounds like you have indeed tested on xcb-randr < 1.12, so I
> suppose the answer to the question is "yes"? If so, I think it's all
> good, no?
>
> Anyway, I think this seems like the right move, and since Keith has't
> responded, feel free to add:
>
> Reviewed-by: Erik Faye-Lund 
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 0/5] RadeonSI: Displayable DCC for Ravens

2019-03-01 Thread Mike Lothian

Hi

What do you mean by kernel driver version? It doesn't seem to match up
with a kernel version or a DC Version

Cheers

Mike

On Thu, 28 Feb 2019 at 21:20, Marek Olšák  wrote:
>
> Hi,
>
> This series enables DCC for scanout on Ravens.
>
> It requires kernel driver version >= 3.31.0 and my xf86-video-amdgpu patch.
>
> There is one issue to resolve: Steam crashes in 
> addrlib/ComputeDccAddrFromCoord.
>
> Please review,
>
> Thanks,
> Marek
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 0/5] RadeonSI: Displayable DCC for Ravens

2019-03-01 Thread Mike Lothian

Thanks, I notice your 5.2-wip is version 3.30.0, so I'll wait until
it's updated before testing

Cheers

Mike

On Fri, 1 Mar 2019 at 15:17, Alex Deucher  wrote:
>
> On Fri, Mar 1, 2019 at 10:11 AM Mike Lothian  wrote:
> >
> > Hi
> >
> > What do you mean by kernel driver version? It doesn't seem to match up
> > with a kernel version or a DC Version
>
> It's not the DC version or the kernel version.  There is a drm
> interface to get the drm driver version so that userspace can check
> what features are supported by the kernel driver.  See amdgpu_drv.c in
> the amdgpu kernel driver.
>
> Alex
>
> >
> > Cheers
> >
> > Mike
> >
> > On Thu, 28 Feb 2019 at 21:20, Marek Olšák  wrote:
> > >
> > > Hi,
> > >
> > > This series enables DCC for scanout on Ravens.
> > >
> > > It requires kernel driver version >= 3.31.0 and my xf86-video-amdgpu 
> > > patch.
> > >
> > > There is one issue to resolve: Steam crashes in 
> > > addrlib/ComputeDccAddrFromCoord.
> > >
> > > Please review,
> > >
> > > Thanks,
> > > Marek
> > > ___
> > > mesa-dev mailing list
> > > mesa-dev@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC 0/3] V2: Improve GLSL support of GL_ARB_separate_shader_objects

2015-10-03 Thread Mike Lothian

Would it be better to have is_interstage=0 rather than a double negative?

On Sat, 3 Oct 2015 10:32 am Gregory Hainaut 
wrote:

> > In short, SSO allow to match by name but you can't make any hypothesis
> on the
> > previous/next stage. Therefore you must consider all inputs and output as
> > actives.
>
> New version based on Ian's feedbacks.
> * Real interstage variables of the program are still optimized
> * Both output and input of the program remains active
> * An old bug still remains if name and explicit location rendezvous are
> mixed
>
> Commits decription:
> 1/ add a not_interstage parameter that will be 1 when variable is either an
>input of output of the program. I didn't know where to put the
> ir_set_not_interstage_io
>function. Maybe it can be moved in linker.cpp.
> 2/ Set the interstage parameter based on the shader position in the
> pipeline
>program. Potentially can be squased with the previous one.
> 3/ Don't do deadcode removal of not_interstage variable with the exception
>of the built-in varyings because they don't impact location of others
> variables
>
> Gregory Hainaut (4):
>   glsl IR: add not_interstage attribute to ir_variable
>   glsl link: annotate not_interstage attribute of the ir_var after link
> phase
>   glsl IR: only allow optimization of interstage variable
>   allow compilation on my system
>
>  configure.ac   |  6 --
>  src/glsl/ir.h  |  6 ++
>  src/glsl/ir_optimization.h |  2 ++
>  src/glsl/linker.cpp| 47
> ++
>  src/glsl/opt_dead_code.cpp | 37 
>  5 files changed, 96 insertions(+), 2 deletions(-)
>
> --
> 2.1.4
>
> ___
> 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 5/5] st/mesa: enable AoA for gallium drivers reporting GLSL 1.30

2016-02-07 Thread Mike Lothian

Does that also add in AoA for OpenGL ES 3.1 or will that require more work?

On Mon, 8 Feb 2016 at 03:46 Dave Airlie  wrote:

> From: Dave Airlie 
>
> Signed-off-by: Dave Airlie 
> ---
>  docs/GL3.txt   | 2 +-
>  docs/relnotes/11.2.0.html  | 1 +
>  src/mesa/state_tracker/st_extensions.c | 1 +
>  3 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/docs/GL3.txt b/docs/GL3.txt
> index 257fc73..02dc842 100644
> --- a/docs/GL3.txt
> +++ b/docs/GL3.txt
> @@ -149,7 +149,7 @@ GL 4.2, GLSL 4.20:
>
>  GL 4.3, GLSL 4.30:
>
> -  GL_ARB_arrays_of_arrays  DONE (i965)
> +  GL_ARB_arrays_of_arrays  DONE (all drivers
> that support GLSL 1.30)
>GL_ARB_ES3_compatibility DONE (all drivers
> that support GLSL 3.30)
>GL_ARB_clear_buffer_object   DONE (all drivers)
>GL_ARB_compute_shaderDONE (i965)
> diff --git a/docs/relnotes/11.2.0.html b/docs/relnotes/11.2.0.html
> index 0d92ed4..069eca2 100644
> --- a/docs/relnotes/11.2.0.html
> +++ b/docs/relnotes/11.2.0.html
> @@ -44,6 +44,7 @@ Note: some of the new features are only available with
> certain drivers.
>  
>
>  
> +GL_ARB_arrays_of_arrays on all gallium drivers that provide GLSL
> 1.30
>  GL_ARB_base_instance on freedreno/a4xx
>  GL_ARB_compute_shader on i965
>  GL_ARB_copy_image on r600
> diff --git a/src/mesa/state_tracker/st_extensions.c
> b/src/mesa/state_tracker/st_extensions.c
> index f25bd74..feabe62 100644
> --- a/src/mesa/state_tracker/st_extensions.c
> +++ b/src/mesa/state_tracker/st_extensions.c
> @@ -808,6 +808,7 @@ void st_init_extensions(struct pipe_screen *screen,
>}
>
>extensions->EXT_shader_integer_mix = GL_TRUE;
> +  extensions->ARB_arrays_of_arrays = GL_TRUE;
> } else {
>/* Optional integer support for GLSL 1.2. */
>if (screen->get_shader_param(screen, PIPE_SHADER_VERTEX,
> --
> 2.5.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 5/5] st/mesa: enable AoA for gallium drivers reporting GLSL 1.30

2016-02-08 Thread Mike Lothian

Cool, thanks.

On Mon, 8 Feb 2016, 4:33 a.m. Dave Airlie  wrote:

> On 8 February 2016 at 14:26, Mike Lothian  wrote:
> > Does that also add in AoA for OpenGL ES 3.1 or will that require more
> work?
>
> Good question, I've no idea. but I think desktop is > GLES in this
> case, so I should
> update GL3.txt for that as well then.
>
> Dave.
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] radeonsi: Enable GLSL 4.30 and therefore OpenGL 4.3

2016-04-14 Thread Mike Lothian

This is the last necessary bit for OpenGL 4.3 support, All
driver-specific functionality has been implemented as part of
extensions.
---

Was testing Bas's patches with Middle-Earth: Shadow of Mordor but 
needed this to expose OpenGL 4.3

 src/gallium/drivers/radeonsi/si_pipe.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeonsi/si_pipe.c 
b/src/gallium/drivers/radeonsi/si_pipe.c
index 94bd666..b789d4c 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.c
+++ b/src/gallium/drivers/radeonsi/si_pipe.c
@@ -338,7 +338,7 @@ static int si_get_param(struct pipe_screen* pscreen, enum 
pipe_cap param)
return HAVE_LLVM >= 0x0309 ? 4 : 0;
 
case PIPE_CAP_GLSL_FEATURE_LEVEL:
-   return HAVE_LLVM >= 0x0309 ? 420 :
+   return HAVE_LLVM >= 0x0309 ? 430 :
   HAVE_LLVM >= 0x0307 ? 410 : 330;
 
case PIPE_CAP_MAX_TEXTURE_BUFFER_SIZE:
-- 
2.8.1

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

Re: [Mesa-dev] [PATCH v2 20/20] radeonsi: enable TGSI support cap for compute shaders

2016-04-15 Thread Mike Lothian

Hi

I've tested this with Middle-Earth Shadow of Mordor on my Tonga based M395X

Feel free to add my tested by if it's worth anything

Cheers

Mike

On Wed, 13 Apr 2016, 8:30 p.m. Bas Nieuwenhuizen, 
wrote:

> v2: Use chip_class instead of family.
>
> Signed-off-by: Bas Nieuwenhuizen 
> Reviewed-by: Nicolai Hähnle 
> ---
>  docs/GL3.txt  |  4 ++--
>  docs/relnotes/11.3.0.html |  1 +
>  src/gallium/drivers/radeon/r600_pipe_common.c | 21 -
>  src/gallium/drivers/radeonsi/si_pipe.c|  3 ++-
>  4 files changed, 21 insertions(+), 8 deletions(-)
>
> diff --git a/docs/GL3.txt b/docs/GL3.txt
> index dc75cf8..6b5e016 100644
> --- a/docs/GL3.txt
> +++ b/docs/GL3.txt
> @@ -167,7 +167,7 @@ GL 4.3, GLSL 4.30:
>GL_ARB_arrays_of_arrays   DONE (all drivers
> that support GLSL 1.30)
>GL_ARB_ES3_compatibility  DONE (all drivers
> that support GLSL 3.30)
>GL_ARB_clear_buffer_objectDONE (all drivers)
> -  GL_ARB_compute_shader DONE (i965)
> +  GL_ARB_compute_shader DONE (i965,
> radeonsi)
>GL_ARB_copy_image DONE (i965, nv50,
> nvc0, r600, radeonsi)
>GL_KHR_debug  DONE (all drivers)
>GL_ARB_explicit_uniform_location  DONE (all drivers
> that support GLSL)
> @@ -225,7 +225,7 @@ GL 4.5, GLSL 4.50:
>  These are the extensions cherry-picked to make GLES 3.1
>  GLES3.1, GLSL ES 3.1
>GL_ARB_arrays_of_arrays   DONE (all drivers
> that support GLSL 1.30)
> -  GL_ARB_compute_shader DONE (i965)
> +  GL_ARB_compute_shader DONE (i965,
> radeonsi)
>GL_ARB_draw_indirect  DONE (i965, nvc0,
> r600, radeonsi, llvmpipe, softpipe)
>GL_ARB_explicit_uniform_location  DONE (all drivers
> that support GLSL)
>GL_ARB_framebuffer_no_attachments DONE (i965, nvc0,
> r600, radeonsi, softpipe)
> diff --git a/docs/relnotes/11.3.0.html b/docs/relnotes/11.3.0.html
> index 0f9aed8..5a7083c 100644
> --- a/docs/relnotes/11.3.0.html
> +++ b/docs/relnotes/11.3.0.html
> @@ -45,6 +45,7 @@ Note: some of the new features are only available with
> certain drivers.
>
>  
>  OpenGL 4.2 on radeonsi
> +GL_ARB_compute_shader on radeonsi
>  GL_ARB_framebuffer_no_attachments on nvc0, r600, radeonsi,
> softpipe
>  GL_ARB_internalformat_query2 on all drivers
>  GL_ARB_robust_buffer_access_behavior on radeonsi
> diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c
> b/src/gallium/drivers/radeon/r600_pipe_common.c
> index a7477ab..64da62f 100644
> --- a/src/gallium/drivers/radeon/r600_pipe_common.c
> +++ b/src/gallium/drivers/radeon/r600_pipe_common.c
> @@ -645,23 +645,34 @@ static int r600_get_compute_param(struct pipe_screen
> *screen,
> uint64_t *grid_size = ret;
> grid_size[0] = 65535;
> grid_size[1] = 65535;
> -   grid_size[2] = 1;
> +   grid_size[2] = 65535;
> }
> return 3 * sizeof(uint64_t) ;
>
> case PIPE_COMPUTE_CAP_MAX_BLOCK_SIZE:
> if (ret) {
> uint64_t *block_size = ret;
> -   block_size[0] = 256;
> -   block_size[1] = 256;
> -   block_size[2] = 256;
> +   if (rscreen->chip_class >= SI && HAVE_LLVM >=
> 0x309 &&
> +   ir_type == PIPE_SHADER_IR_TGSI) {
> +   block_size[0] = 2048;
> +   block_size[1] = 2048;
> +   block_size[2] = 2048;
> +   } else {
> +   block_size[0] = 256;
> +   block_size[1] = 256;
> +   block_size[2] = 256;
> +   }
> }
> return 3 * sizeof(uint64_t);
>
> case PIPE_COMPUTE_CAP_MAX_THREADS_PER_BLOCK:
> if (ret) {
> uint64_t *max_threads_per_block = ret;
> -   *max_threads_per_block = 256;
> +   if (rscreen->chip_class >= SI && HAVE_LLVM >=
> 0x309 &&
> +   ir_type == PIPE_SHADER_IR_TGSI)
> +   *max_threads_per_block = 2048;
> +   else
> +   *max_threads_per_block = 256;
> }
> return sizeof(uint64_t);
>
> diff --git a/src/gallium/drivers/radeonsi/si_pipe.c
> b/src/gallium/drivers/radeonsi/si_pipe.c
> index 8db8ca6..d169469 100644
> --- a/src/gallium/drivers/radeonsi/si_pipe.c
> +++ b/src

Re: [Mesa-dev] [PATCH 00/20] Begin enabling OpenGL ES 3.1

2015-04-30 Thread Mike Lothian

Isn't that override to change the GL version rather than the GLES version?

On Thu, 30 Apr 2015 00:26 Ian Romanick  wrote:

> There's still a fair amount functionality left to be implemented before
> GLES 3.1 can actually be enabled.  Compute shaders and SSBOs are the
> biggest things left to finish.  This series just allows people to start
> testing the things that are implemented.  To get a GLES 3.1 context, set
> the environment variable
>
> MESA_GL_VERSION_OVERRIDE=3.1
>
> The GLES3 experience taught me that there is a huge pile of little
> differences between GLES and desktop GL... and it takes a really, really
> long time to get those ironed out enough to pass Khronos conformance
> tests.  Getting the initial boiler plate stuff out now lets people start
> testing and fixing sooner.
>
> This is also available in the gles3.1-enabling branch of my fd.o tree at
> git://people.freedesktop.org/~idr/mesa.
>
> I have tested this with the glsl-es-3.10 patches that I just sent to the
> piglit list.  I get the expected set of passes and failures from the
> minimum-maximums.txt test.
>
> ___
> 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] mapi: fix LTO compilation

2016-06-06 Thread Mike Lothian

This doesn't seem to affect me using GCC 6.1 and gold

On Thu, 2 Jun 2016, 6:42 p.m. Jan Ziak (⚛), <0xe2.0x9a.0...@gmail.com>
wrote:

> LTO compilation can sometimes fail with GCC 4.9 and GCC 5.3 because
> src/mapi uses unusual mixing of C code and assembly code. The issue
> may be present in case of GCC 6.1 as well.
>
> This is a Mesa bug rather than a compiler bug (although in an ideal
> world the compilation with -flto should fail if and only if normal
> compilation fails).
>
> The error message:
>
> entry_x86-64_tls.h:61: undefined reference to `x86_64_entry_start'
>
> Without the patch:
> - using "-flto -O2 -DDEBUG" fails with GCC 4.9 and 5.3
> - using "-flto -O3 -DDEBUG" succeeds with GCC 4.9 and 5.3
> - using "-flto -O2 -DNDEBUG" succeeds with GCC 4.9 and 5.3
>
> The patch assumes that the assembler understands ".hidden" directive.
>
> Signed-off-by: Jan Ziak (⚛) <0xe2.0x9a.0...@gmail.com>
> ---
>  src/mapi/entry_x86-64_tls.h |  5 +++--
>  src/mapi/entry_x86_tls.h| 12 +---
>  2 files changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/src/mapi/entry_x86-64_tls.h b/src/mapi/entry_x86-64_tls.h
> index 38faccc..acabecc 100644
> --- a/src/mapi/entry_x86-64_tls.h
> +++ b/src/mapi/entry_x86-64_tls.h
> @@ -28,6 +28,8 @@
>
>  __asm__(".text\n"
>  ".balign 32\n"
> +".globl x86_64_entry_start\n"
> +".hidden x86_64_entry_start\n"
>  "x86_64_entry_start:");
>
>  #define STUB_ASM_ENTRY(func) \
> @@ -54,8 +56,7 @@ entry_patch_public(void)
>  {
>  }
>
> -static char
> -x86_64_entry_start[];
> +extern char x86_64_entry_start[];
>
>  mapi_func
>  entry_get_public(int slot)
> diff --git a/src/mapi/entry_x86_tls.h b/src/mapi/entry_x86_tls.h
> index 46d2ece..6078b9a 100644
> --- a/src/mapi/entry_x86_tls.h
> +++ b/src/mapi/entry_x86_tls.h
> @@ -29,7 +29,9 @@
>
>  __asm__(".text");
>
> -__asm__("x86_current_tls:\n\t"
> +__asm__( ".globl x86_current_tls\n"
> +   ".hidden x86_current_tls\n"
> +   "x86_current_tls:\n\t"
> "call 1f\n"
>  "1:\n\t"
>  "popl %eax\n\t"
> @@ -42,6 +44,8 @@ __asm__(".section wtext, \"awx\", @progbits");
>  #endif /* GLX_X86_READONLY_TEXT */
>
>  __asm__(".balign 16\n"
> +".globl x86_entry_start\n"
> +".hidden x86_entry_start\n"
>  "x86_entry_start:");
>
>  #define STUB_ASM_ENTRY(func) \
> @@ -60,6 +64,8 @@ __asm__(".balign 16\n"
>
>  #ifndef GLX_X86_READONLY_TEXT
>  __asm__(".balign 16\n"
> +".globl x86_entry_end\n"
> +".hidden x86_entry_end\n"
>  "x86_entry_end:");
>  __asm__(".text");
>  #endif /* GLX_X86_READONLY_TEXT */
> @@ -71,8 +77,8 @@ __asm__(".text");
>  extern unsigned long
>  x86_current_tls();
>
> -static char x86_entry_start[];
> -static char x86_entry_end[];
> +extern char x86_entry_start[];
> +extern char x86_entry_end[];
>
>  void
>  entry_patch_public(void)
> --
> 2.8.3
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mapi: fix LTO compilation

2016-06-06 Thread Mike Lothian

I'm running Gentoo too, it didn't take significantly longer to compile GCC
6.1 than any other version of GCC

I use portage to compile mesa

On Mon, 6 Jun 2016, 5:58 p.m. ⚛, <0xe2.0x9a.0...@gmail.com> wrote:

> On Mon, Jun 6, 2016 at 3:39 PM, Mike Lothian  wrote:
> >
> > This doesn't seem to affect me using GCC 6.1 and gold
>
> I don't have GCC 6.1 installed at the moment, and it takes quite long
> to install it on Gentoo.
>
> Can you please send me the output of the following command?
>
> $ cd mesa/src/mapi
> $ make clean
> $ make V=1 -j1 &> output_file_to_send.txt
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mapi: fix LTO compilation

2016-06-06 Thread Mike Lothian

I only have /var/log/portage/elog/ the file(s) you specified don't exist on
my system

On Mon, 6 Jun 2016 at 21:13 ⚛ <0xe2.0x9a.0...@gmail.com> wrote:

> On Mon, Jun 6, 2016 at 9:01 PM, Mike Lothian  wrote:
> >
> > I'm running Gentoo too, it didn't take significantly longer to compile
> GCC 6.1 than any other version of GCC
> >
> > I use portage to compile mesa
>
> Ok. What is the output of a command like:
>
> $ ls --sort=time /var/log/portage/media-libs:mesa-*.log | xargs grep
> "CFLAGS:" | head
>
> > On Mon, 6 Jun 2016, 5:58 p.m. , <0xe2.0x9a.0...@gmail.com> wrote:
> >>
> >> On Mon, Jun 6, 2016 at 3:39 PM, Mike Lothian 
> wrote:
> >> >
> >> > This doesn't seem to affect me using GCC 6.1 and gold
> >>
> >> I don't have GCC 6.1 installed at the moment, and it takes quite long
> >> to install it on Gentoo.
> >>
> >> Can you please send me the output of the following command?
> >>
> >> $ cd mesa/src/mapi
> >> $ make clean
> >> $ make V=1 -j1 &> output_file_to_send.txt
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Let's identify the R9 285 bottleneck in respect to R7 370

2016-06-20 Thread Mike Lothian

Ah it's not a regression, in that case it might be possible to profile the
running benchmark to see where some bottlenecks lie, but from what ive read
on here before, this is difficult to set up and the results aren't always
useful.

As you're unaffected by this I doubt you'll be able to help further, I take
it your hardware doesn't have these issues?

On Mon, 20 Jun 2016, 3:03 p.m. ⚛, <0xe2.0x9a.0...@gmail.com> wrote:

> On Mon, Jun 20, 2016 at 3:36 PM, Nicolai Hähnle 
> wrote:
> > On 20.06.2016 11:59, wrote:
> >>
> >> Hello.
> >>
> >> The result file at
> >> http://openbenchmarking.org/result/1606180-PTS-MIDJUNEA78 is showing
> >> multiple issues, some of them are:
> >>
> >> [Minor issue] Kernel 4.7.0-999-generic (x86_64) 20160616 has a
> >> performance regression on R9 290
> >>
> >> [Major issue] R7 370 yields 133 FPS in Tesseract, while R9 285
> >> unexpectedly yields 111.81 FPS in Tesseract
> >
> > It would be most helpful if people with the affected hardware could first
> > identify the responsible component and then bisect.
>
> About the R9 285 issue:
>
> I don't understand. How might a person bisect something that doesn't exist?
>
> Or, if I am in error and you are right, and bisecting is possible then
> I would like to see a previous Tesseract v2014-05-12 result with >=
> 140 FPS on R9 285.
>
> There was a point in time when Mesa was able to run Tesseract at >=
> 140 FPS on R9 285?
>
> > Cheers,
> > Nicolai
> >
> >> R7 370: 1996.8 GFLOPS
> >> R9 285: 3290 GLOPS
> >>
> >> I would like this forum thread to identify the cause of the major
> >> issue. So the question is:
> >>
> >> *** What might be causing R9 285 to perform worse than R7 370? ***
> >>
> >> (I don't have access to R7 370 nor R9 285. My current answer to the
> >> question is: I don't know.)
> >> ___
> >> mesa-dev mailing list
> >> mesa-dev@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >>
> >
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 0/7] DRI3 support for EGL (v4)

2015-11-17 Thread Mike Lothian

Hi

Out of interest have any of you tested this on Plasma5? When I set OpenGL &
EGL in kwin and I'm using DRI3 compositing is disabled (it wasn't before)

This is on Kabini using the latest mesa, xorg and radeon drivers from got

Cheers

Mike

On Tue, 17 Nov 2015, 3:31 p.m. Martin Peres 
wrote:

>
> On 10/11/15 20:26, Axel Davy wrote:
> > Hi,
> >
> > I did take a look, and it looks good to me.
> >
> > I'm happy you implemented DRI_PRIME support as well.
> > About it, do you need testers to check everything works ?
> >
> > A mistake about it I noticed is that you don't disable
> > EGL_KHR_image_pixmap
> > when is_different_gpu is set.
> > It should be disabled, just like GLX_EXT_texture_from_pixmap is for GLX.
>
> Thanks for the review, I followed your suggestion! Sorry for the late
> answer though.
>
> I just pushed the patches.
> ___
> 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 0/7] DRI3 support for EGL (v4)

2015-12-06 Thread Mike Lothian

Hi

Have you had any success with this?

Cheers

Mike

On Wed, 18 Nov 2015 at 02:27 Boyan Ding  wrote:

> 2015-11-18 8:04 GMT+08:00 Martin Peres :
> >
> >
> > On 18/11/15 01:37, Mike Lothian wrote:
> >>
> >>
> >> Hi
> >>
> >> Out of interest have any of you tested this on Plasma5? When I set
> OpenGL
> >> & EGL in kwin and I'm using DRI3 compositing is disabled (it wasn't
> before)
> >>
> >> This is on Kabini using the latest mesa, xorg and radeon drivers from
> got
> >>
> >> Cheers
> >>
> >> Mike
> >
> >
> > Hey Mike,
> >
> > I do use plasma 5, but with glx. Anyway, I can reproduce the issue so I
> will
> > have a look at it tomorrow! For the record, I get the following errors:
> >
> > QXcbConnection: XCB error: 3 (BadWindow), sequence: 171, resource id:
> > 73400326, major code: 20 (GetProperty), minor code: 0
> > kwin_core: Failed to initialize compositing, compositing disabled
> > QXcbConnection: XCB error: 3 (BadWindow), sequence: 2171, resource id:
> 108,
> > major code: 3 (GetWindowAttributes), minor code: 0
> >
> > Thanks for testing and bug report,
> > Martin
> >
> >
>
> Hi,
>
> I do remember that Plasma 5 was running okay with compositing on when
> I was writing v2 of the patch series. But I also reproduced the same
> failure with current git. Seems weird.
>
> I'll try to test and see what's happening when I'm free.
>
> Regards,
> Boyan Ding
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/3] i965: Use MESA_FORMAT_B8G8R8X8_SRGB for RGB visuals

2015-12-13 Thread Mike Lothian

Hi

These three commits have stopped Plasma5's kwin  working on my skylake
system

Reverting back to 7752bbc44e78e982de3cd4c34862adc38a338234 fixed it for me

I can send you more details / raise a bug if you like

Cheers

Mike

On Sat, 12 Dec 2015 at 20:56 Kenneth Graunke  wrote:

> On Friday, December 11, 2015 12:32:18 PM Neil Roberts wrote:
> > Previously if the visual didn't have an alpha channel then it would
> > pick a format that is not sRGB-capable. I don't think there's any
> > reason not to always have an sRGB-capable visual. Since 28090b30 there
> > are now visuals advertised without an alpha channel which means that
> > games that don't request alpha bits in the config would end up without
> > an sRGB-capable visual. This was breaking supertuxkart which assumes
> > the winsys buffer is always sRGB-capable.
> >
> > The previous code always used an RGBA format if the visual config
> > itself was marked as sRGB-capable regardless of whether the visual has
> > alpha bits. I think we don't actually advertise any sRGB-capable
> > visuals (but we just use sRGB formats anyway) so it shouldn't make any
> > difference. However this patch also changes it to use RGBX if an
> > sRGB-capable visual is requested without alpha bits for consistency.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92759
> > Cc: "11.0 11.1" 
> > Cc: Ilia Mirkin 
> > Suggested-by: Ilia Mirkin 
> > ---
> >  src/mesa/drivers/dri/i965/intel_screen.c | 13 ++---
> >  1 file changed, 6 insertions(+), 7 deletions(-)
>
> The whole series is:
> Reviewed-by: Kenneth Graunke 
>
> We definitely should have the same behavior regardless of whether the
> config has an alpha channel.  So, this is good.
> ___
> 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 10/10] docs: Mark ARB_tessellation_shader as done on all i965 platforms.

2015-12-25 Thread Mike Lothian

Isn't it gen7+ now?

On Fri, 25 Dec 2015 at 01:34 Kenneth Graunke  wrote:

> We now support all Intel GPUs which can do tessellation.
> ---
>  docs/GL3.txt  | 2 +-
>  docs/relnotes/11.2.0.html | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/docs/GL3.txt b/docs/GL3.txt
> index 58aace9..f12e0ba 100644
> --- a/docs/GL3.txt
> +++ b/docs/GL3.txt
> @@ -112,7 +112,7 @@ GL 4.0, GLSL 4.00 --- all DONE: nvc0, r600, radeonsi
>GL_ARB_gpu_shader_fp64   DONE (llvmpipe,
> softpipe)
>GL_ARB_sample_shadingDONE (i965, nv50)
>GL_ARB_shader_subroutine DONE (i965, nv50,
> llvmpipe, softpipe)
> -  GL_ARB_tessellation_shader   DONE (i965/gen8+)
> +  GL_ARB_tessellation_shader   DONE (i965)
>GL_ARB_texture_buffer_object_rgb32   DONE (i965,
> llvmpipe, softpipe)
>GL_ARB_texture_cube_map_arrayDONE (i965, nv50,
> llvmpipe, softpipe)
>GL_ARB_texture_gatherDONE (i965, nv50,
> llvmpipe, softpipe)
> diff --git a/docs/relnotes/11.2.0.html b/docs/relnotes/11.2.0.html
> index 6f1752c..23bb31c 100644
> --- a/docs/relnotes/11.2.0.html
> +++ b/docs/relnotes/11.2.0.html
> @@ -47,7 +47,7 @@ Note: some of the new features are only available with
> certain drivers.
>  GL_ARB_base_instance on freedreno/a4xx
>  GL_ARB_compute_shader on i965
>  GL_ARB_copy_image on r600
> -GL_ARB_tessellation_shader on i965/gen8+ and r600 (evergreen/cayman
> only)
> +GL_ARB_tessellation_shader on i965 and r600 (evergreen/cayman
> only)
>  GL_ARB_texture_buffer_object_rgb32 on freedreno/a4xx
>  GL_ARB_texture_buffer_range on freedreno/a4xx
>  GL_ARB_texture_query_lod on freedreno/a4xx
> --
> 2.6.4
>
> ___
> 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 37/37] i965/gen6: enable OpenGL 3.2

2014-08-14 Thread Mike Lothian

I think everything that's required for GL 3.3 has already been added can we
jump directly there?
On 14 Aug 2014 12:13, "Iago Toral Quiroga"  wrote:

> From: Samuel Iglesias Gonsalvez 
>
> Signed-off-by: Samuel Iglesias Gonsalvez 
> ---
>  src/mesa/drivers/dri/i965/intel_screen.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
> b/src/mesa/drivers/dri/i965/intel_screen.c
> index ea0fc58..83101a5 100644
> --- a/src/mesa/drivers/dri/i965/intel_screen.c
> +++ b/src/mesa/drivers/dri/i965/intel_screen.c
> @@ -1273,7 +1273,7 @@ set_max_gl_versions(struct intel_screen *screen)
>psp->max_gl_es2_version = 30;
>break;
> case 6:
> -  psp->max_gl_core_version = 31;
> +  psp->max_gl_core_version = 32;
>psp->max_gl_compat_version = 30;
>psp->max_gl_es1_version = 11;
>psp->max_gl_es2_version = 30;
> --
> 1.9.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

Re: [Mesa-dev] [PATCH 36/37] i965/gen6: enable GLSL 1.50

2014-08-14 Thread Mike Lothian

We can probably just change this to check for gen >= 6 and expose 3.30
On 14 Aug 2014 12:13, "Iago Toral Quiroga"  wrote:

> From: Samuel Iglesias Gonsalvez 
>
> Signed-off-by: Samuel Iglesias Gonsalvez 
> ---
>  src/mesa/drivers/dri/i965/intel_extensions.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c
> b/src/mesa/drivers/dri/i965/intel_extensions.c
> index e134cd9..9875b7c 100644
> --- a/src/mesa/drivers/dri/i965/intel_extensions.c
> +++ b/src/mesa/drivers/dri/i965/intel_extensions.c
> @@ -246,7 +246,7 @@ intelInitExtensions(struct gl_context *ctx)
> if (brw->gen >= 7)
>ctx->Const.GLSLVersion = 330;
> else if (brw->gen >= 6)
> -  ctx->Const.GLSLVersion = 140;
> +  ctx->Const.GLSLVersion = 150;
> else
>ctx->Const.GLSLVersion = 120;
> _mesa_override_glsl_version(&ctx->Const);
> --
> 1.9.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

Re: [Mesa-dev] [PATCH 00/37] Geometry shader support in Sandy Bridge

2014-08-20 Thread Mike Lothian

On 20 August 2014 11:18, Samuel Iglesias Gonsálvez  wrote:
> On Wed, 2014-08-20 at 11:16 +0200, Iago Toral wrote:
>> El 2014-08-16 09:11, Jordan Justen escribió:
>> > On Thu, Aug 14, 2014 at 4:11 AM, Iago Toral Quiroga 
>> > wrote:
>> >> Hi,
>> >>
>> >> this series brings support for geometry shaders in Sandy Bridge (gen6)
>> >> and is
>> >> combined work from Samuel and myself. A few notes:
>> >>
>> >> 1.- Some patches have been based on original work by Ilia Mirkin,
>> >> specifically
>> >> the idea of using arrays to buffer the output of the GS, subclassing
>> >> the
>> >> vec4_gs_visitor for gen6 and generalizing emit_urb_slot().
>> >>
>> >> 2.- Geometry shaders were already being used in gen6 to implement
>> >> transform
>> >> feedback support for vertex shaders. We have not changed this. These
>> >> patches
>> >> focus on adding support for user-provided geometry shaders and
>> >> transform
>> >> feedback support for the geometry shader stage. In the future it
>> >> probably
>> >> makes sense to merge transform feedback support for the vertex shader
>> >> stage
>> >> in our implementation so there is only one code path for geometry
>> >> shaders
>> >> in gen6, but it is probably better to tackle that at a later moment,
>> >> once we
>> >> have merged this work.
>> >>
>> >> 2.- On Ivy Bridge there are no piglit regressions.
>> >>
>> >> 3.- On Sandy Bridge we get these results after enabling OpenGL 3.2 and
>> >> GLSL 1.50 (*1):
>> >>
>> >>   crash:+0
>> >>   fail:+15 (*2)
>> >>   pass:  +3265
>> >>   skip:  -3280
>> >
>> > Maybe a list of the failures? Or posting the piglit comparison results
>> > might be helpful.
>> >
>> > For example:
>> > http://people.freedesktop.org/~kwg/stuff/bdw-2014-05-13/summary/regressions.html
>> >
>> > This is not really a big deal, but it would just be nice to quickly
>> > see what tests are failing.
>> >
>> >> (*1) Including Jordan's patches from the series
>> >> "Gen6 render surface state changes" since these are required to enable
>> >> layered rendering in geometry shaders. The numbers were obtained by
>> >> comparing
>> >> master with Jordan's patches on top (OpenGL 3.1, GLSL 1.40) against
>> >> master
>> >> with these and Jordan's patches on top (OpenGL 3.2, GLSL 1.50)
>> >
>> > I finally pushed my gen6-layered series to master. (a1dca70)
>> >
>> > I wonder if you might push these patches to a publicly available
>> > branch?
>> >
>> > Thanks!
>> >
>> > -Jordan
>>
>> Sure. Samuel, can you do this?
>
> Sure!
>
> The public branch with the submitted patches rebased on top
> of yesterday's master is here:
>
> https://github.com/samuelig/mesa/tree/gs-support-snb-for-submission
>
> And the piglit comparison between yesterday's master which already have
> Jordan's patches in SNB (OpenGL 3.1, GLSL 1.40) and our patches
> (OpenGL 3.2, GLSL 1.50) is here:
>
> http://samuelig.es/mesa-dev/all-submitted-patches-19-aug/
>
> Sorry for the delay, uploading the whole piglit's HTML output is taking
> a lot of time with my Internet connection :-S If you find that some
> files are missing just try again later (FTP transfer is still uploading
> files).
>
> Best regards,
>
> Samuel
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>

Hi I tested the branch - glxinfo reports GL 3.2 and GLSL 1.50 however
when I run Heaven 4 I get a blank screen when rendering and the
following messages:

GLFrameBuffer::enable(): incomplete attachment
GLFrameBuffer::enable(): incomplete attachment
GLFrameBuffer::enable(): incomplete attachment
GLFrameBuffer::enable(): incomplete attachment
OpenGL error: invalid framebuffer operation

This only happens when at 8xAA - is the demo mis detecting the AA
abilities of Sandybridge?

Valley seem to have rendering issues no matter what the AA level - I
get black trees in the foreground

With Oil Rush I always get white game rendering (the overlays are
fine) no matter what the AA level

Metro Last Light seems to play fine even at the highest levels
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 00/37] Geometry shader support in Sandy Bridge

2014-08-20 Thread Mike Lothian

On 21 August 2014 00:41, Matt Turner  wrote:
> On Wed, Aug 20, 2014 at 4:30 PM, Mike Lothian  wrote:
>> Hi I tested the branch - glxinfo reports GL 3.2 and GLSL 1.50 however
>> when I run Heaven 4 I get a blank screen when rendering and the
>> following messages:
>>
>> GLFrameBuffer::enable(): incomplete attachment
>> GLFrameBuffer::enable(): incomplete attachment
>> GLFrameBuffer::enable(): incomplete attachment
>> GLFrameBuffer::enable(): incomplete attachment
>> OpenGL error: invalid framebuffer operation
>>
>> This only happens when at 8xAA - is the demo mis detecting the AA
>> abilities of Sandybridge?
>
> Sounds like it. Sandybridge can only do 4x MSAA.

Hmm mis detecting or is the driver mis advertising?
>
>> Valley seem to have rendering issues no matter what the AA level - I
>> get black trees in the foreground
>
> Possibly need some workaround. Can't remember.
>
>> With Oil Rush I always get white game rendering (the overlays are
>> fine) no matter what the AA level
>
> This sounds like the problem where their shaders put #extension in the
> wrong place. Try running with
> MESA_EXTENSION_OVERRIDE=-GL_ARB_sample_shading. I think there's a
> driconf for this now.

Yes that fixed the Oil Rush one - I don't need to pass that with r600g
though so I'm thinking that maybe i965 isn't using that driconf file
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 00/37] Geometry shader support in Sandy Bridge

2014-08-20 Thread Mike Lothian

On 21 August 2014 00:58, Matt Turner  wrote:
> On Wed, Aug 20, 2014 at 4:49 PM, Mike Lothian  wrote:
>> On 21 August 2014 00:41, Matt Turner  wrote:
>>> On Wed, Aug 20, 2014 at 4:30 PM, Mike Lothian  wrote:
>>>> Hi I tested the branch - glxinfo reports GL 3.2 and GLSL 1.50 however
>>>> when I run Heaven 4 I get a blank screen when rendering and the
>>>> following messages:
>>>>
>>>> GLFrameBuffer::enable(): incomplete attachment
>>>> GLFrameBuffer::enable(): incomplete attachment
>>>> GLFrameBuffer::enable(): incomplete attachment
>>>> GLFrameBuffer::enable(): incomplete attachment
>>>> OpenGL error: invalid framebuffer operation
>>>>
>>>> This only happens when at 8xAA - is the demo mis detecting the AA
>>>> abilities of Sandybridge?
>>>
>>> Sounds like it. Sandybridge can only do 4x MSAA.
>
> glxinfo -l | grep GL_MAX_SAMPLES
>
> will tell you.

It does indeed report 4 - must be a general bug of Unigine then
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] i965/gen6: Enable GLSL 3.30 and OpenGL 3.3

2014-09-19 Thread Mike Lothian

Hi

I'm pretty sure this is all thats needed to switch on GLSL 3.30 and
OpenGL 3.3 on Sandybridge

Cheers

Mike
From b16937f37681f8e44c86cdb86bd76fd1bbfab998 Mon Sep 17 00:00:00 2001
From: Mike Lothian 
Date: Fri, 19 Sep 2014 22:56:46 +0100
Subject: [PATCH] i965/gen6: Enable GLSL 3.30 and OpenGL 3.3

---
 src/mesa/drivers/dri/i965/intel_extensions.c | 4 +---
 src/mesa/drivers/dri/i965/intel_screen.c | 7 +--
 2 files changed, 2 insertions(+), 9 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c b/src/mesa/drivers/dri/i965/intel_extensions.c
index b7c64c6..4e6627e 100644
--- a/src/mesa/drivers/dri/i965/intel_extensions.c
+++ b/src/mesa/drivers/dri/i965/intel_extensions.c
@@ -243,10 +243,8 @@ intelInitExtensions(struct gl_context *ctx)
ctx->Extensions.OES_standard_derivatives = true;
ctx->Extensions.OES_EGL_image_external = true;
 
-   if (brw->gen >= 7)
+   if (brw->gen >= 6)
   ctx->Const.GLSLVersion = 330;
-   else if (brw->gen >= 6)
-  ctx->Const.GLSLVersion = 150;
else
   ctx->Const.GLSLVersion = 120;
_mesa_override_glsl_version(&ctx->Const);
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c b/src/mesa/drivers/dri/i965/intel_screen.c
index 8070e97..41964ec 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -1269,13 +1269,8 @@ set_max_gl_versions(struct intel_screen *screen)
switch (screen->devinfo->gen) {
case 8:
case 7:
-  psp->max_gl_core_version = 33;
-  psp->max_gl_compat_version = 30;
-  psp->max_gl_es1_version = 11;
-  psp->max_gl_es2_version = 30;
-  break;
case 6:
-  psp->max_gl_core_version = 32;
+  psp->max_gl_core_version = 33;
   psp->max_gl_compat_version = 30;
   psp->max_gl_es1_version = 11;
   psp->max_gl_es2_version = 30;
-- 
2.1.0

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

[Mesa-dev] [PATCH] i965/gen6: Enable GLSL 3.30 and OpenGL 3.3

2014-09-19 Thread Mike Lothian

Hi 

This is the first time I've used git send-mail - hopefully it should be inline 
now

I've run piglit and there don't seem to be any failures related to the new 
enablement (I do get some GS fails though)

Cheers

Mike

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

[Mesa-dev] [PATCH] i965/gen6: Enable GLSL 3.30 and OpenGL 3.3

2014-09-19 Thread Mike Lothian

---
 src/mesa/drivers/dri/i965/intel_extensions.c | 4 +---
 src/mesa/drivers/dri/i965/intel_screen.c | 7 +--
 2 files changed, 2 insertions(+), 9 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c 
b/src/mesa/drivers/dri/i965/intel_extensions.c
index b7c64c6..4e6627e 100644
--- a/src/mesa/drivers/dri/i965/intel_extensions.c
+++ b/src/mesa/drivers/dri/i965/intel_extensions.c
@@ -243,10 +243,8 @@ intelInitExtensions(struct gl_context *ctx)
ctx->Extensions.OES_standard_derivatives = true;
ctx->Extensions.OES_EGL_image_external = true;
 
-   if (brw->gen >= 7)
+   if (brw->gen >= 6)
   ctx->Const.GLSLVersion = 330;
-   else if (brw->gen >= 6)
-  ctx->Const.GLSLVersion = 150;
else
   ctx->Const.GLSLVersion = 120;
_mesa_override_glsl_version(&ctx->Const);
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index 8070e97..41964ec 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -1269,13 +1269,8 @@ set_max_gl_versions(struct intel_screen *screen)
switch (screen->devinfo->gen) {
case 8:
case 7:
-  psp->max_gl_core_version = 33;
-  psp->max_gl_compat_version = 30;
-  psp->max_gl_es1_version = 11;
-  psp->max_gl_es2_version = 30;
-  break;
case 6:
-  psp->max_gl_core_version = 32;
+  psp->max_gl_core_version = 33;
   psp->max_gl_compat_version = 30;
   psp->max_gl_es1_version = 11;
   psp->max_gl_es2_version = 30;
-- 
2.1.0

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

Re: [Mesa-dev] [PATCH] i965: Add RGBX8888 and RGBA8888 to EGL configure and reorder the list

2017-05-18 Thread Mike Lothian

Can you make sure whatever you do it's well tested

I shudder every time I see such requests as it nearly always seems to cause
breakage for me

On Thu, 18 May 2017 at 11:25 Emil Velikov  wrote:

> On 18 May 2017 at 05:10, Chih-Wei Huang  wrote:
> > 2017-05-18 12:01 GMT+08:00 Xu, Randy :
> >>
> >>> -Original Message-
> >>> From: Palli, Tapani
> >>> >
> >>> > It's just applied. Isn't it?
> >>> > Yesterday without this patch
> >>> > the color format is mismatch apparently.
> >>>
> >>> Yeah we do need this. TBH I don't quite understand why but will try to
> figure
> >>> it out. I remember we used to have a patch in Surfaceflinger at one
> point
> >>> because visual was hardcoded there and this might be related.
> >>>
> >>> // Tapani
> >>
> >> Sorry, that's for different issue, I mix it with RGB565 blending one.
> >> This patch is required because some Android GLES test apps, like
> gl2_basic, need to create RGBA surface.
> >
> > Indeed it is.
> >
> > As Emil pointed out, the patch was merged before
> > but reverted later since it broke desktop.
> >
> > So what's the current upstreaming plan?
> >
> No idea about a plan, but how you can fix it once and for all:
>
> Extend the loader extension(s) to have a get_caps() callback,
> analogous to __DRIimageExtension::getCapabilities.
> Then the DRI module will query [the loader] and advertise the
> RGBX/RGBA visuals when possible.
>
> -Emil
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Bug 101088] `gallium: remove pipe_index_buffer and set_index_buffer` causes glitches and crash in gallium nine

2017-05-22 Thread Mike Lothian

This fixes WoW for me

Thanks

On Mon, 22 May 2017 at 00:18  wrote:

> *Comment # 4  on
> bug 101088  from Axel
> Davy  *
>
> Should be fixed 
> byhttps://lists.freedesktop.org/archives/mesa-dev/2017-May/156453.html
>
> Please confirm.
>
> --
> You are receiving this mail because:
>
>- You are the assignee for the bug.
>
>
>- You are the QA Contact for the bug.
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965: Add RGBX8888 and RGBA8888 to EGL configure and reorder the list

2017-05-22 Thread Mike Lothian

I'm quite sure on Gentoo lib points to lib64 and we have a lib32

On Mon, 22 May 2017 at 22:46 Rob Herring  wrote:

> On Mon, May 22, 2017 at 9:16 AM, Emil Velikov 
> wrote:
> > On 20 May 2017 at 01:16, Rob Herring  wrote:
> >> On Fri, May 19, 2017 at 12:57 PM, Emil Velikov <
> emil.l.veli...@gmail.com> wrote:
> >>> On 18 May 2017 at 23:01, Rob Herring  wrote:
>  On Thu, May 18, 2017 at 5:25 AM, Emil Velikov <
> emil.l.veli...@gmail.com> wrote:
> > On 18 May 2017 at 05:10, Chih-Wei Huang 
> wrote:
> >> 2017-05-18 12:01 GMT+08:00 Xu, Randy :
> >>>
>  -Original Message-
>  From: Palli, Tapani
>  >
>  > It's just applied. Isn't it?
>  > Yesterday without this patch
>  > the color format is mismatch apparently.
> 
>  Yeah we do need this. TBH I don't quite understand why but will
> try to figure
>  it out. I remember we used to have a patch in Surfaceflinger at
> one point
>  because visual was hardcoded there and this might be related.
> 
>  // Tapani
> >>>
> >>> Sorry, that's for different issue, I mix it with RGB565 blending
> one.
> >>> This patch is required because some Android GLES test apps, like
> gl2_basic, need to create RGBA surface.
> >>
> >> Indeed it is.
> >>
> >> As Emil pointed out, the patch was merged before
> >> but reverted later since it broke desktop.
> >>
> >> So what's the current upstreaming plan?
> >>
> > No idea about a plan, but how you can fix it once and for all:
> >
> > Extend the loader extension(s) to have a get_caps() callback,
> > analogous to __DRIimageExtension::getCapabilities.
> > Then the DRI module will query [the loader] and advertise the
> > RGBX/RGBA visuals when possible.
> 
>  Could we do something compile time instead to enable just for Android?
>  Seems like a lot of complexity when the platform needing these pixel
>  formats doesn't need the backwards compatibility. Or maybe there are
>  other things needing this interface?
> 
> >>> Having a short/mid term ifdef ANDROID is perfectly fine.
> >>>
> >>> Can we address some of the existing ones before/alongside the newly
> added ones?
> >>> Afacit the nouveau bits are no longer applicable.
> >>
> >> Yeah. I don't explicitly warn for KK or less, but will add that and fix
> these.
> >>
> >>> While for the
> >>> gbm/egl 'use "gallium_dri.so"' one can either use your latest build
> >>> rework or MESA_LOADER_DRIVER_OVERRIDE.
> >>
> >> How does the build rework help? My only reservation with using an env
> >> var is generally Android things don't rely on them and it would break
> >> working systems. I'm not even completely certain I can set env vars
> >> globally. It would be nice if the build system could set defaults for
> >> env vars we could use.
> >>
> > IIRC with the rework you have the dri driver names are known as we
> > reach targets/dri/Android.mk
>
> Not really because we have things like freedreno -> msm and virgl ->
> virtio_gpu, but having a variable like TARGET_DRIVERS is simple
> enough.
>
> > Thus one can reuse them to create the separate drivers
> >   - be that one blob + {sym,hard}links as we do in autotools/scons, or
> >  - completely separate drivers like i965 and other classic drivers.
>
> Got it. Symlinks are really easy in master:
>
> LOCAL_MODULE_SYMLINKS := $(foreach d, $(GALLIUM_TARGET_DRIVERS),
> $(d)_dri.so)
>
> However, that only works in master. There is LOCAL_POST_INSTALL_CMD,
> but it doesn't support multilib, so we need something like this:
>
> LOCAL_POST_INSTALL_CMD := \
> $(foreach l, lib lib64, \
>  mkdir -p $(TARGET_OUT_SHARED_LIBRARIES)/$(l)/$(MESA_DRI_MODULE_REL_PATH);
> \
>  $(foreach d, $(GALLIUM_TARGET_DRIVERS), ln -sf gallium_dri.so
> $(TARGET_OUT)/$(l)/$(MESA_DRI_MODULE_REL_PATH)/$(d)_dri.so;) \
> )
>
> This will install broken links when we're not on a multilib build. A
> bit ugly, but should be harmless.
>
> Rob
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 00/17] radv: Support for subgroup_vote and shader_ballot

2017-06-12 Thread Mike Lothian

I found some patches on the git mailing list but looks like none of them
have been merged

http://git.661346.n2.nabble.com/PATCH-send-mail-Add-option-to-sleep-between-sending-each-email-td6769476.html

On Mon, 12 Jun 2017 at 23:22 Connor Abbott  wrote:

> On Mon, Jun 12, 2017 at 2:30 AM, Nicolai Hähnle 
> wrote:
> > FYI, somehow your mails don't show up in a single thread for me. They're
> in
> > groups of 00-04, 05-09, 10-14, 15-17. Not sure what's up with that.
>
> For some reason, the server at Valve rate-limits sending email, so git
> send-email failed when I tried to send them all at once, and I had to
> send some manually. Is there some way to automatically sleep between
> sending emails out?
>
> >
> > On 10.06.2017 01:43, Connor Abbott wrote:
> >>
> >> From: Connor Abbott 
> >>
> >> This series adds all the bits to enable EXT_shader_subgroup_vote and
> >> EXT_shader_subgroup_ballot for radv. It's based on my previous series to
> >> fix some 64-bit bugs in radv and anv, since nothing would work without
> >> them.
> >>
> >> Patches 1-4 are a resend of my previous series to add ARB_shader_ballot
> >> and ARB_shader_group_vote support to NIR, with some changes suggested by
> >> Jason and minor bugfixes. Patches 5-8 add SPIRV-to-NIR support for the
> >> SPIR-V extensions. Finally, the rest of the patches move some of the
> >> existing logic for ARB_shader_ballot and ARB_shader_group_vote into ac
> >> when appropriate and turn on the extension for radv.
> >>
> >> One question I had was about how to handle the differences between
> >> SPIR-V and GL here. SPIR-V decided to make the things that return a
> >> bitmask of invocations return a uvec4, whereas in the GL extension they
> >> return a uint64_t. Right now, in NIR, we use the GL semantics, and we
> >> translate that in vtn. I'm open to changing that, though.
> >
> >
> > Pragmatically, I'd say stick with the GL semantics for now. We'd only
> ever
> > have to change that if somebody decides to build a GPU with 128-wide
> waves,
> > but given how having wider waves increasingly hurts with divergence, that
> > seems unlikely to happen.
> >
> >
> >> I wrote a few crucible tests to test the extension (mostly copied from
> >> the piglit ARB_shader_ballot and ARB_shader_group_vote coverage), which
> >> I'll send out shortly. One of the tests is crashing because of
> >> https://github.com/KhronosGroup/glslang/issues/930, but other than that
> >> it passes the tests.
> >
> >
> > Looks like an alternative GLSL-to-SPIRV compiler would really be nice to
> > have...
> >
> > I've sent comments on some of the patches, mostly the NIR attribute
> stuff.
> > Sorry I didn't notice that sooner.
> >
> > Cheers,
> > Nicolai
> >
> >
> >
> >> I also made sure I didn't regress piglit on
> >> radeonsi. It might be a good idea to run it on Intel's CI system,
> >> especially given patches 5 and 6.
> >>
> >> This series is also available at:
> >> git://people.freedesktop.org/~cwabbott0/mesa radv-shader-ballot
> >>
> >> Connor Abbott (17):
> >>nir: introduce new convergent and cross-thread attributes
> >>nir/gcm: use the new cross-thread attribute
> >>nir: take cross-thread operations into account into a few places
> >>nir: add ARB_shader_ballot and ARB_shader_group_vote instructions
> >>mesa: fix 64-bit issues with system_values_read
> >>compiler: add new system values for SPV_KHR_shader_ballot
> >>nir/lower_system_values: handle SPIR-V shader_ballot system values
> >>nir/spirv: add plumbing for KHR_shader_ballot and KHR_subgroup_vote
> >>ac: add i32_0 convenience member to ac_llvm_context
> >>radeonsi: move llvm_get_type_size() to ac
> >>radeonsi: move emit_optimization_barrier() to ac
> >>ac: add i64 type to ac_llvm_context
> >>radeonsi: move si_emit_ballot() to ac
> >>ac: add i32_1 convenience member to ac_llvm_context
> >>radeonsi: move the guts of ARB_shader_group_vote emission to ac
> >>ac: enable the AMDGPU asm parser
> >>radv/ac: enable EXT_shader_subgroup_ballot and
> >>  EXT_shader_subgroup_vote
> >>
> >>   src/amd/common/ac_llvm_build.c | 127
> >> +++
> >>   src/amd/common/ac_llvm_build.h |  18 
> >>   src/amd/common/ac_llvm_util.c  |   4 +
> >>   src/amd/common/ac_nir_to_llvm.c|  75 
> >>   src/amd/vulkan/radv_device.c   |   8 ++
> >>   src/amd/vulkan/radv_pipeline.c |   2 +
> >>   src/compiler/nir/nir.c |  28 ++
> >>   src/compiler/nir/nir.h |  80 +
> >>   src/compiler/nir/nir_instr_set.c   |  22 +
> >>   src/compiler/nir/nir_intrinsics.h  |  30 +++
> >>   src/compiler/nir/nir_lower_system_values.c |  38 
> >>   src/compiler/nir/nir_opt_gcm.c |  72 +--
> >>   src/compiler/nir/nir_opt_peephole_select.c |  11 +++
> >>   src/compiler/shader_enums.c|   5 ++
>

Re: [Mesa-dev] [PATCH v3 8/8] egl/wayland: Use linux-dmabuf interface for buffers

2017-07-18 Thread Mike Lothian

Hi

I'm currently getting a build failure with this patch in an out of tree
build

Making all in egl
make[3]: Entering directory
'/var/tmp/portage/media-libs/mesa-/work/mesa--abi_x86_32.x86/src/egl'

/usr/bin/wayland-scanner code <
/usr/share/wayland-protocols/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
> drivers/dri2/linux-dmabuf-unstable-v1-protocol.c
/usr/bin/wayland-scanner client-header <
/usr/share/wayland-protocols/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
> drivers/dri2/linux-dmabuf-unstable-v1-client-protocol.h
/usr/bin/python2.7
 
/var/tmp/portage/media-libs/mesa-/work/mesa-/src/egl/generate/gen_egl_dispatch.py
source \
   
/var/tmp/portage/media-libs/mesa-/work/mesa-/src/egl/generate/eglFunctionList.py
\
   
/var/tmp/portage/media-libs/mesa-/work/mesa-/src/egl/generate/egl.xml
\
   
/var/tmp/portage/media-libs/mesa-/work/mesa-/src/egl/generate/egl_other.xml
> g_egldispatchstubs.c
/usr/bin/python2.7
 
/var/tmp/portage/media-libs/mesa-/work/mesa-/src/egl/generate/gen_egl_dispatch.py
header \
   
/var/tmp/portage/media-libs/mesa-/work/mesa-/src/egl/generate/eglFunctionList.py
\
   
/var/tmp/portage/media-libs/mesa-/work/mesa-/src/egl/generate/egl.xml
\
   
/var/tmp/portage/media-libs/mesa-/work/mesa-/src/egl/generate/egl_other.xml
> g_egldispatchstubs.h
/bin/sh: drivers/dri2/linux-dmabuf-unstable-v1-protocol.c: No such file or
directory
make[3]: *** [Makefile:1609:
drivers/dri2/linux-dmabuf-unstable-v1-protocol.c] Error 1
make[3]: *** Waiting for unfinished jobs
/bin/sh: drivers/dri2/linux-dmabuf-unstable-v1-client-protocol.h: No such
file or directory
make[3]: *** [Makefile:1613:
drivers/dri2/linux-dmabuf-unstable-v1-client-protocol.h] Error 1

I've checked and
/usr/share/wayland-protocols/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
does exist on my system

Cheers

Mike

On Fri, 14 Jul 2017 at 14:36 Daniel Stone  wrote:

> When available, use the zwp_linux_dambuf_v1 interface to create buffers,
> which allows multiple planes and buffer modifiers to be used.
>
> Reviewed-by: Emil Velikov 
> Signed-off-by: Daniel Stone 
> ---
>  configure.ac|   5 +-
>  src/egl/Makefile.am |  23 +++-
>  src/egl/drivers/dri2/.gitignore |   2 +
>  src/egl/drivers/dri2/egl_dri2.c |   7 ++
>  src/egl/drivers/dri2/egl_dri2.h |  10 ++
>  src/egl/drivers/dri2/platform_wayland.c | 195
> +---
>  6 files changed, 221 insertions(+), 21 deletions(-)
>  create mode 100644 src/egl/drivers/dri2/.gitignore
>
> diff --git a/configure.ac b/configure.ac
> index 46fcd8f3fe..c5803e0f6e 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -88,6 +88,7 @@ LIBOMXIL_BELLAGIO_REQUIRED=0.0
>  LIBVA_REQUIRED=0.38.0
>  VDPAU_REQUIRED=1.1
>  WAYLAND_REQUIRED=1.11
> +WAYLAND_PROTOCOLS_REQUIRED=1.8
>  XCB_REQUIRED=1.9.3
>  XCBDRI2_REQUIRED=1.8
>  XCBGLX_REQUIRED=1.8.1
> @@ -1686,7 +1687,9 @@ for plat in $platforms; do
> case "$plat" in
> wayland)
>
> -   PKG_CHECK_MODULES([WAYLAND], [wayland-client >=
> $WAYLAND_REQUIRED wayland-server >= $WAYLAND_REQUIRED])
> +   PKG_CHECK_MODULES([WAYLAND], [wayland-client >=
> $WAYLAND_REQUIRED wayland-server >= $WAYLAND_REQUIRED wayland-protocols >=
> $WAYLAND_PROTOCOLS_REQUIRED])
> +ac_wayland_protocols_pkgdatadir=`$PKG_CONFIG
> --variable=pkgdatadir wayland-protocols`
> +AC_SUBST(WAYLAND_PROTOCOLS_DATADIR,
> $ac_wayland_protocols_pkgdatadir)
>
> if test "x$WAYLAND_SCANNER" = "x:"; then
> AC_MSG_ERROR([wayland-scanner is needed to compile
> the wayland platform])
> diff --git a/src/egl/Makefile.am b/src/egl/Makefile.am
> index 81090387b5..19295de3ed 100644
> --- a/src/egl/Makefile.am
> +++ b/src/egl/Makefile.am
> @@ -21,6 +21,8 @@
>
>  include Makefile.sources
>
> +BUILT_SOURCES =
> +
>  AM_CFLAGS = \
> -I$(top_srcdir)/include \
> -I$(top_srcdir)/src/egl/main \
> @@ -61,11 +63,27 @@ endif
>  endif
>
>  if HAVE_PLATFORM_WAYLAND
> +WL_DMABUF_XML =
> $(WAYLAND_PROTOCOLS_DATADIR)/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
> +
> +drivers/dri2/linux-dmabuf-unstable-v1-protocol.c: $(WL_DMABUF_XML)
> +   $(MKDIR_GEN)
> +   $(AM_V_GEN)$(WAYLAND_SCANNER) code < $< > $@
> +
> +drivers/dri2/linux-dmabuf-unstable-v1-client-protocol.h: $(WL_DMABUF_XML)
> +   $(MKDIR_GEN)
> +   $(AM_V_GEN)$(WAYLAND_SCANNER) client-header < $< > $@
> +
> +BUILT_SOURCES += \
> +   drivers/dri2/linux-dmabuf-unstable-v1-protocol.c \
> +   drivers/dri2/linux-dmabuf-unstable-v1-client-protocol.h
> +
>  AM_CFLAGS += $(WAYLAND_CFLAGS)
>  libEGL_common_la_LIBADD += $(WAYLAND_LIBS)
>  libEGL_common_la_LIBADD += $(LIBDRM_LIBS)
>  libEGL_common_la_LIBADD += $(top_builddir)/src/egl/wayland/wayland-drm/
> libwayland-drm.la
> -dri2_backend_FILES += drivers/dri2/platform_wayland.c

[Mesa-dev] [PATCH] egl/wayland: Fix linking libEGL_common.la

2017-07-20 Thread Mike Lothian

Because libmesautil.la includes string_to_uint_map.o, -lstdc++ is
required for linking to succeed

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101851

Signed-off-by: Mike Lothian 
---
 src/egl/Makefile.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/egl/Makefile.am b/src/egl/Makefile.am
index 7c1a4929b8..830ed52b86 100644
--- a/src/egl/Makefile.am
+++ b/src/egl/Makefile.am
@@ -83,7 +83,7 @@ AM_CFLAGS += $(WAYLAND_CFLAGS)
 libEGL_common_la_LIBADD += $(WAYLAND_LIBS)
 libEGL_common_la_LIBADD += $(LIBDRM_LIBS)
 libEGL_common_la_LIBADD += 
$(top_builddir)/src/egl/wayland/wayland-drm/libwayland-drm.la
-libEGL_common_la_LIBADD += $(top_builddir)/src/util/libmesautil.la
+libEGL_common_la_LIBADD += $(top_builddir)/src/util/libmesautil.la -lstdc++
 dri2_backend_FILES += drivers/dri2/platform_wayland.c  \
drivers/dri2/linux-dmabuf-unstable-v1-protocol.c
 endif
-- 
2.13.3

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

Re: [Mesa-dev] [PATCH] egl/wayland: Fix linking libEGL_common.la

2017-07-23 Thread Mike Lothian

This is only an issue when using ld.gold, ld.bfd works fine which is
probably why no one else has seen it. It only started being a problem when
the dmabuff stuff landed and the makefiles were cleaned up

I tried playing around with the dummy.cpp but I couldn't get it to trigger
the c++ compiler

On Fri, 21 Jul 2017 at 13:27 Emil Velikov  wrote:

> On 20 July 2017 at 21:25, Mike Lothian  wrote:
> > Because libmesautil.la includes string_to_uint_map.o, -lstdc++ is
> > required for linking to succeed
> >
> It's a bit suspicious why not many others are seeing this issue.
> Suspecting the GCC version/build flags has something to do here.
>
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101851
> >
> > Signed-off-by: Mike Lothian 
> > ---
> >  src/egl/Makefile.am | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/src/egl/Makefile.am b/src/egl/Makefile.am
> > index 7c1a4929b8..830ed52b86 100644
> > --- a/src/egl/Makefile.am
> > +++ b/src/egl/Makefile.am
> > @@ -83,7 +83,7 @@ AM_CFLAGS += $(WAYLAND_CFLAGS)
> >  libEGL_common_la_LIBADD += $(WAYLAND_LIBS)
> >  libEGL_common_la_LIBADD += $(LIBDRM_LIBS)
> >  libEGL_common_la_LIBADD += $(top_builddir)/src/egl/wayland/wayland-drm/
> libwayland-drm.la
> > -libEGL_common_la_LIBADD += $(top_builddir)/src/util/libmesautil.la
> > +libEGL_common_la_LIBADD += $(top_builddir)/src/util/libmesautil.la
> -lstdc++
>
> As mentioned by Ken - ideally we won't be pulling C++ into libEGL. Can
> you give try converting string_to_uint_map to C?
> Alternatively use the dummy.cpp suggestion from Matt. We already have
> some examples in the codebase.
>
> Thanks
> Emil
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] egl/wayland: Fix linking libEGL_common.la

2017-07-23 Thread Mike Lothian

If I try and compile mesa with clang (even using ld.bfd) I get these errors:

libtool: link: clang++ -m32 -fvisibility=hidden -Werror=pointer-arith
-Werror=vla -O2 -march=native -pipe -Wall -fno-math-errno
-fno-trapping-math -Qunused-arguments -O2 -march=native -pipe -fuse-ld=bfd
-o glsl_compiler glsl/main.o  glsl/.libs/libstandal
one.a -lz -lpthread -pthread
glsl/.libs/libstandalone.a(libmesautil_la-disk_cache.o): In function
`disk_cache_remove':
/var/tmp/portage/media-libs/mesa-/work/mesa-/src/util/disk_cache.c:(.text+0x752):
undefined reference to `__atomic_fetch_add_8'
glsl/.libs/libstandalone.a(libmesautil_la-disk_cache.o): In function
`cache_put':
/var/tmp/portage/media-libs/mesa-/work/mesa-/src/util/disk_cache.c:(.text+0xa76):
undefined reference to `__atomic_fetch_add_8'
/var/tmp/portage/media-libs/mesa-/work/mesa-/src/util/disk_cache.c:(.text+0xe40):
undefined reference to `__atomic_fetch_add_8'


On Mon, 24 Jul 2017 at 00:03 Mike Lothian  wrote:

> This is only an issue when using ld.gold, ld.bfd works fine which is
> probably why no one else has seen it. It only started being a problem when
> the dmabuff stuff landed and the makefiles were cleaned up
>
> I tried playing around with the dummy.cpp but I couldn't get it to trigger
> the c++ compiler
>
> On Fri, 21 Jul 2017 at 13:27 Emil Velikov 
> wrote:
>
>> On 20 July 2017 at 21:25, Mike Lothian  wrote:
>> > Because libmesautil.la includes string_to_uint_map.o, -lstdc++ is
>> > required for linking to succeed
>> >
>> It's a bit suspicious why not many others are seeing this issue.
>> Suspecting the GCC version/build flags has something to do here.
>>
>> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101851
>> >
>> > Signed-off-by: Mike Lothian 
>> > ---
>> >  src/egl/Makefile.am | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/src/egl/Makefile.am b/src/egl/Makefile.am
>> > index 7c1a4929b8..830ed52b86 100644
>> > --- a/src/egl/Makefile.am
>> > +++ b/src/egl/Makefile.am
>> > @@ -83,7 +83,7 @@ AM_CFLAGS += $(WAYLAND_CFLAGS)
>> >  libEGL_common_la_LIBADD += $(WAYLAND_LIBS)
>> >  libEGL_common_la_LIBADD += $(LIBDRM_LIBS)
>> >  libEGL_common_la_LIBADD += $(top_builddir)/src/egl/wayland/wayland-drm/
>> libwayland-drm.la
>> > -libEGL_common_la_LIBADD += $(top_builddir)/src/util/libmesautil.la
>> > +libEGL_common_la_LIBADD += $(top_builddir)/src/util/libmesautil.la
>> -lstdc++
>>
>> As mentioned by Ken - ideally we won't be pulling C++ into libEGL. Can
>> you give try converting string_to_uint_map to C?
>> Alternatively use the dummy.cpp suggestion from Matt. We already have
>> some examples in the codebase.
>>
>> Thanks
>> Emil
>>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] threaded opengl

2017-07-23 Thread Mike Lothian

I think you also need to provide info on how much of a speed up it provides
because some games are slower with glthread

On Mon, 24 Jul 2017 at 01:33 siyia  wrote:

> sorry executable is "mb_warband_linux" start.sh or mb_warband.sh are
> local scripts to start the game so:
>
> 
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 00/14] Better Travis-CI integration, take 2

2017-04-21 Thread Mike Lothian

Is nine and clover built with this?

On Fri, 21 Apr 2017, 1:25 pm Gustaw Smolarczyk, 
wrote:

> 2017-04-21 14:08 GMT+02:00 Emil Velikov :
> > Note: GCC 5/6 crashes with internal compiler error at seemingly random
> > stages of the build. Unless any of the SWR devs sort it out, we might
> > want to disable it for now.
> >
> > A sample report can be seen at
> > https://travis-ci.org/evelikov/Mesa/builds/223590028
>
>
> Hello,
>
> The ICEs look like an external factor is involved.
>
> > g++-5: internal compiler error: Killed (program cc1plus)
>
> Looks like someone killed the cc1plus process. Maybe too much memory
> was used and kernel OOM killer was unleashed?
>
> Regards,
> Gustaw
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 00/14] Better Travis-CI integration, take 2

2017-04-21 Thread Mike Lothian

Use a lower make j number and make sure you're not using LTO

On Fri, 21 Apr 2017, 2:33 pm Emil Velikov,  wrote:

> On 21 April 2017 at 13:25, Gustaw Smolarczyk  wrote:
> > 2017-04-21 14:08 GMT+02:00 Emil Velikov :
> >> Note: GCC 5/6 crashes with internal compiler error at seemingly random
> >> stages of the build. Unless any of the SWR devs sort it out, we might
> >> want to disable it for now.
> >>
> >> A sample report can be seen at
> >> https://travis-ci.org/evelikov/Mesa/builds/223590028
> >
> >
> > Hello,
> >
> > The ICEs look like an external factor is involved.
> >
> >> g++-5: internal compiler error: Killed (program cc1plus)
> >
> > Looks like someone killed the cc1plus process. Maybe too much memory
> > was used and kernel OOM killer was unleashed?
> >
> Perfectly possible, although I doubt it since
>  - SWR + Autotools has no issues
>  - building SCons + SWR alongside Chromium with two dozen tabs, barely
> reaches 2.5G while the instance should have 4GiB.
>
> In either case - if anyone has suggestions how to address this I'm all
> ears.
>
> -Emil
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] clover: Fix build against clang SVN >= r301442

2017-04-26 Thread Mike Lothian

Tested-and-reviewed-by: Mike Lothian 

On Thu, 27 Apr 2017 at 04:33 Michel Dänzer  wrote:

> From: Michel Dänzer 
>
> Hardcode the OpenCL InputKind in compat::set_lang_defaults.
>
> Signed-off-by: Michel Dänzer 
> ---
>  src/gallium/state_trackers/clover/llvm/compat.hpp | 10 ++
>  src/gallium/state_trackers/clover/llvm/invocation.cpp |  2 +-
>  2 files changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/src/gallium/state_trackers/clover/llvm/compat.hpp
> b/src/gallium/state_trackers/clover/llvm/compat.hpp
> index cee51b9dd1..ee8c2a78e4 100644
> --- a/src/gallium/state_trackers/clover/llvm/compat.hpp
> +++ b/src/gallium/state_trackers/clover/llvm/compat.hpp
> @@ -76,14 +76,16 @@ namespace clover {
>
>   inline void
>   set_lang_defaults(clang::CompilerInvocation &inv,
> -   clang::LangOptions &lopts, clang::InputKind ik,
> +   clang::LangOptions &lopts,
> const ::llvm::Triple &t,
> clang::PreprocessorOptions &ppopts,
> clang::LangStandard::Kind std) {
> -#if HAVE_LLVM >= 0x0309
> -inv.setLangDefaults(lopts, ik, t, ppopts, std);
> +#if HAVE_LLVM >= 0x0500
> +inv.setLangDefaults(lopts, clang::InputKind::OpenCL, t,
> ppopts, std);
> +#elif HAVE_LLVM >= 0x0309
> +inv.setLangDefaults(lopts, clang::IK_OpenCL, t, ppopts, std);
>  #else
> -inv.setLangDefaults(lopts, ik, std);
> +inv.setLangDefaults(lopts, clang::IK_OpenCL, std);
>  #endif
>   }
>
> diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp
> b/src/gallium/state_trackers/clover/llvm/invocation.cpp
> index deebef5726..64c0ec4c23 100644
> --- a/src/gallium/state_trackers/clover/llvm/invocation.cpp
> +++ b/src/gallium/state_trackers/clover/llvm/invocation.cpp
> @@ -126,7 +126,7 @@ namespace {
>c->getDiagnosticOpts().ShowCarets = false;
>
>compat::set_lang_defaults(c->getInvocation(), c->getLangOpts(),
> -clang::IK_OpenCL,
> ::llvm::Triple(target.triple),
> +::llvm::Triple(target.triple),
>  c->getPreprocessorOpts(),
>  clang::LangStandard::lang_opencl11);
>
> --
> 2.11.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 0/4] Call for testing: Gallium set_index_buffer removal etc.

2017-04-29 Thread Mike Lothian

Hi

I've just tested this with Nine. It causes a weird white strobing effect -
I think there are other graphical glitches too but it's hard to tell

I was testing the blizzard app http://eu.battle.net/en/app/ the same also
happens when World of Warcraft is launched

This doesn't happen if I use CSMT rather than Nine

Cheers

Mike

On Sat, 29 Apr 2017 at 00:12 Marek Olšák  wrote:

> Hi,
>
> This series shrinks various gallium structures and removes
> set_index_buffer in order to decrease CPU overhead.
>
>
> PART 1: Performance results
>
> All testing below was done with radeonsi, and I used the drawoverhead
> microbenchmark from mesa/demos ported to piglit and using GL 3.0
> Compat and GL 3.2 Core (same GL states in both contexts).
>
> 1) Performance difference for the removal of set_index_buffer only:
>
>   Compat: DrawElements: 5.1 -> 5.3 million draws/second
>   Core:   DrawElements: 5.1 -> 5.5 million draws/second
>
> The result is better for the core profile where u_vbuf is disabled.
>
>
> 2) Performance difference with all 4 patches (Core profile only)
>
>DrawArrays: 8.3 -> 8.5 million draws/second
>DrawElements: 5.2 -> 5.8 million draws/second
>
>
> 3) Performance difference with threaded Gallium (Core profile only):
>
>DrawElements: 5.9 -> 7.1 million draws/second
>
> Threaded Gallium is still work in progress and might require
> a non-trivial amount of driver work.
>
>
> PART 2: Call for testing
>
> These drivers have been tested:
> - ddebug
> - llvmpipe
> - r300 (also with SWTCL)
> - r600
> - radeonsi
> - softpipe
> - trace
>
> These drivers need testing:
> - etnaviv
> - freedreno
> - nv30
> - nv50
> - nvc0
> - svga
> - swr
> - vc4
> - virgl
>
> The following state trackers might need testing:
> - nine
>
> You can get the patches by fetching:
>   git://people.freedesktop.org/~mareko/mesa gallium-cleanup
>
> I'd like to ask to you for testing drivers that I couldn't test.
> Please let me know when you're done testing and if things are good.
> After that, I'll push everything assuming the code review goes well.
> You can also ignore this if you don't mind fixing your driver in
> the master branch later.
>
> Thanks,
>
> Marek
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [ANNOUNCE] mesa 17.1.0-rc3

2017-05-01 Thread Mike Lothian

Hi

I think this email is sent from a script so just wanted to point out:

not available -> now available

If it's just a bog standard typo in a manually written email - just ignore
me

Mike

On Mon, 1 May 2017 at 13:24 Emil Velikov  wrote:

> Hello all,
>
> The third release candidate for Mesa 17.1.0 is not available.
>
>
> Andres Gomez (2):
>   travis: replace Trusty-based LLVM toolchain apt-get with apt addon
>   travis: add the possibility of using the txc-dxtn library
>
> Emil Velikov (15):
>   travis: explicitly LD_LIBRARY_PATH the local libraries
>   travis: enable apt cache
>   travis: automatically manage ccache caching
>   travis: remove unused -dev packages
>   travis: rework "if test" blocks in the script section
>   travis: split out matrix from env
>   travis: add separate "scons" and "scons llvm" targets
>   travis: add "scons swr" to the build matrix
>   travis: add "make swr" to the build matrix
>   travis: split the make target to three separate ones
>   travis: model scons check target like the make one
>   travis: add Gallium state-tracker targets
>   travis: enable wayland support
>   travis: bump MAKEFLAGS to -j4
>   Update version to 17.1.0-rc3
>
> Francisco Jerez (2):
>   intel/fs: Use regs_written() in spilling cost heuristic for
> improved accuracy.
>   intel/fs: Take into account amount of data read in spilling cost
> heuristic.
>
> Ilia Mirkin (1):
>   gallium/targets: fix bool setting on BE architectures
>
> Jason Ekstrand (2):
>   anv: Don't place scratch buffers above the 32-bit boundary
>   anv/cmd_buffer: Use the device allocator for QueueSubmit
>
> Kenneth Graunke (1):
>   i965/vec4: Avoid reswizzling MACH instructions in
> opt_register_coalesce().
>
> Marek Olšák (7):
>   radeonsi/gfx9: fix texture buffer objects and image buffers with
> IDXEN==0
>   radeonsi/gfx9: fix most things wrong with shader images
>   radeonsi/gfx9: fix 1D array shader images
>   radeonsi/gfx9: add a workaround for viewing a slice of 3D as a 2D
> image
>   radeonsi/gfx9: set MAX_PRIMGRP_IN_WAVE in the correct register
>   radeonsi/gfx9: don't set deprecated field PARTIAL_ES_WAVE_ON
>   radeonsi: adjust ESGS ring buffer size computation on VI
>
> Nicolai Hähnle (1):
>   st/mesa: don't cast the incomplete framebufer to st_framebuffer
>
> Timothy Arceri (3):
>   disk_cache: reduce default cache size to 5% of filesystem
>   disk_cache: use block size rather than file size
>   util/disk_cache: remove percentage based max cache limit
>
> git tag: mesa-17.1.0-rc3
>
> https://mesa.freedesktop.org/archive/mesa-17.1.0-rc3.tar.gz
> MD5:  d84e7611ea97c74b6e5c0e8c957ca133  mesa-17.1.0-rc3.tar.gz
> SHA1: f5821fea3c614d643eb82880596936d0c9df34d7  mesa-17.1.0-rc3.tar.gz
> SHA256: 8d162d72b85457b6614865c6c1dab4670300c88904266580330bb1ce81d6023f
>  mesa-17.1.0-rc3.tar.gz
> SHA512:
> 704f20fd47672f1e4c9c7e822b7c6e575cbedddb3a813b3f1c27d02e1531a4ac7a28142c5ef0c98dbe6ccd1c3a8062f04fccb360eb82507d89c6d8dd8c33f433
>  mesa-17.1.0-rc3.tar.gz
> PGP:  https://mesa.freedesktop.org/archive/mesa-17.1.0-rc3.tar.gz.sig
>
> https://mesa.freedesktop.org/archive/mesa-17.1.0-rc3.tar.xz
> MD5:  0630035d846918e5b291b2a893d066b2  mesa-17.1.0-rc3.tar.xz
> SHA1: b8d9bcb63462167de9ee83f2093552fa49679c90  mesa-17.1.0-rc3.tar.xz
> SHA256: 52831657b7ac64b3dd4899f2f6d995c062fc77ac436017470daddfc1ebc0e85e
>  mesa-17.1.0-rc3.tar.xz
> SHA512:
> b5f5d2d517fb92fa1d31a44b88cf7c00fbe186747482c2286e97a352c016719c6454a79f777df6a8540997df464820cb1a8c2e3054a26517bb062b25e1a2d114
>  mesa-17.1.0-rc3.tar.xz
> PGP:  https://mesa.freedesktop.org/archive/mesa-17.1.0-rc3.tar.xz.sig
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 00/18] anv: Rework the allocation data structures

2017-05-05 Thread Mike Lothian

I'm seeing the following failure with GCC 7.1:

/var/tmp/portage/media-libs/mesa-/work/mesa-/src/intel/vulkan/anv_allocator.c:
In function ‘anv_state_stream_alloc’:
/var/tmp/portage/media-libs/mesa-/work/mesa-/src/intel/vulkan/anv_allocator.c:930:28:
error: ‘struct anv_state_stream_block’ has no member named ‘_vg_ptr’
   VG_NOACCESS_WRITE(&sb->_vg_ptr, NULL);
^
/var/tmp/portage/media-libs/mesa-/work/mesa-/src/intel/vulkan/anv_allocator.c:53:44:
note: in definition of macro ‘VG_NOACCESS_WRITE’
 #define VG_NOACCESS_WRITE(__ptr, __val) (*(__ptr) = (__val))
^
At top level:
/var/tmp/portage/media-libs/mesa-/work/mesa-/src/intel/vulkan/anv_allocator.c:1214:1:
warning: ‘anv_bo_cache_lookup’ defined but not used [-Wunused-function]
 anv_bo_cache_lookup(struct anv_bo_cache *cache, uint32_t gem_handle)
 ^~~


On Thu, 4 May 2017 at 09:09 Juan A. Suarez Romero 
wrote:

> On Tue, 2017-05-02 at 06:44 -0700, Jason Ekstrand wrote:
> > Juan,
> >
> > Were you planning to review the rest of the series?  Just wondering.
> >
>
> Sorry, it took a bit more to review the remaining patches.
>
> Now it is done.
>
>
> J.A.
>
> > --Jason
> >
> >
> > On April 26, 2017 7:35:29 AM Jason Ekstrand 
> wrote:
> >
> > > This absurdly long series does something fairly simple:  It pulls the
> > > block_pool into the state_pool and makes the state pool capable of
> > > allocating states larger than the block size.  Unfortunately, there
> was no
> > > good way to do it in less than 18 patches. :-(
> > >
> > > Cc: Juan A. Suarez Romero 
> > >
> > > Jason Ekstrand (18):
> > >   anv/allocator: Add no-valgrind versions of state_pool_alloc/free
> > >   anv/allocator: Return a null state for zero-size allocations
> > >   anv/allocator: Convert the state stream to pull from a state pool
> > >   anv: Get rid of a bunch of uses of size_t
> > >   anv/allocator: Remove the state_size field from fixed_size_state_pool
> > >   anv/allocator: Roll fixed_size_state_pool into state_pool
> > >   anv/allocator: Pull the userptr part of block_pool_grow into a helper
> > >   anv/allocator: Drop the block_size field from block_pool
> > >   anv/allocator: Add support for "back" allocations to state_pool
> > >   anv: Allocate binding table blocks through the state pool
> > >   anv/allocator: Get rid of the ability to free blocks
> > >   anv/allocator: Embed the block_pool in the state_pool
> > >   anv/allocator: Rework a comment
> > >   anv/allocator: Add the capability to allocate blocks of different
> > > sizes
> > >   anv/allocator: Add helpers for dealing with bucket sizes
> > >   anv/allocator: Support pushing multiple blocks onto a free list at
> > > once
> > >   anv/allocator: Allow state pools to allocate large states
> > >   anv: Drop the instruction pool block size
> > >
> > >  src/intel/vulkan/anv_allocator.c   | 589
> -
> > >  src/intel/vulkan/anv_batch_chain.c |  84 ++-
> > >  src/intel/vulkan/anv_blorp.c   |   4 +-
> > >  src/intel/vulkan/anv_cmd_buffer.c  |   8 +-
> > >  src/intel/vulkan/anv_descriptor_set.c  |   4 +-
> > >  src/intel/vulkan/anv_device.c  |  26 +-
> > >  src/intel/vulkan/anv_gem.c |   2 +-
> > >  src/intel/vulkan/anv_gem_stubs.c   |   2 +-
> > >  src/intel/vulkan/anv_private.h |  74 +--
> > >  src/intel/vulkan/gen8_cmd_buffer.c |   6 +-
> > >  src/intel/vulkan/genX_blorp_exec.c |   2 +-
> > >  src/intel/vulkan/genX_cmd_buffer.c |  15 +-
> > >  src/intel/vulkan/tests/block_pool_no_free.c|   8 +-
> > >  src/intel/vulkan/tests/state_pool.c|   5 +-
> > >  src/intel/vulkan/tests/state_pool_free_list_only.c |   5 +-
> > >  src/intel/vulkan/tests/state_pool_no_free.c|   5 +-
> > >  16 files changed, 461 insertions(+), 378 deletions(-)
> > >
> > > --
> > > 2.5.0.400.gff86faf
> > >
> >
> >
> >
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/3] RFC: vulkan/wsi: Rework the way prime support works

2017-11-16 Thread Mike Lothian

Will this allow us to select between iGPU and dGPU like we can with OpenGL?
Or is it just going to force radv like before?

On Thu, 16 Nov 2017 at 10:09 Grazvydas Ignotas  wrote:

> On Thu, Nov 16, 2017 at 12:33 AM, Dave Airlie  wrote:
> > On 15 November 2017 at 04:40, Jason Ekstrand 
> wrote:
> >> This commit significantly reworks the way prime support works and lets
> >> us pull it even further into radv.  The old mechanism required the
> >> specific WSI layer to be aware of the linear shadow copy that has to be
> >> done in order for prime to work.  In the new paradigm, we better define
> >> what bits of wsi_image go to the client and what bits go off to the
> >> window system.  It's then the job of the driver to allocate two separate
> >> images and stash whatever intermediates it needs in driver_private.
> >> There are a few advantages to this method:
> >>
> >>  1) It separates supporting prime from the driver decision as to whether
> >> it's better to render directly into the window-system-compatible
> >> image or if it's better to blit.
> >>
> >>  2) Because of this separation, it's now possible for a driver to use a
> >> different scheme for WSI image presentation where it hooks the
> >> vkCmdPipelineBarrier that transitions the image to
> >> VK_IMAGE_LAYOUT_PRESENT_SRC_KHR and does the blit there.
> >>
> >>  3) It lets us pull more of the details into radv and, in my opinion,
> >> actually makes the radv code more straightforward.
> >
> > For the record, PRIME is not radv specific, stop trying to make it so,
> > anv should support display to other GPUs.
>
> Yes it would be great if that worked, would make radv vs anv testing
> so much easier as I much prefer my display to be on dGPU.
>
> Gražvydas
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] V3 i965/Gallium ARB_get_program_binary support

2017-12-05 Thread Mike Lothian

I can confirm this fixes the Dead Island crash, which makes this the first
time I've been able to play the game since purchasing it :D

The patches doesn't apply cleanly to master so I used the following fixup
https://github.com/FireBurn/mesa/tree/gallium-program-binary

If you're happy with that feel free to add my Tested-by

On Tue, 5 Dec 2017 at 05:03 Timothy Arceri  wrote:

> Ping! The outstanding patches for review are:
>
> 4, 12, 22, 23
>
> Gallium specific patches:
>
> 17-21
>
> The following have a v1 r-b Nicolai but have changed since:
>
> 13, 14, 15
>
> Branch available here:
>
> https://github.com/tarceri/Mesa.git gallium-program-binary
>
> On 29/11/17 12:24, Timothy Arceri wrote:
> > V3:
> > This is basically the V2 that Jordan sent with feedback addressed,
> > gallium support added, some minor functional changes such as only
> > storing the default uniforms to either disk or program binary cache
> > (rather than fixing them up later) and some refactoring to allow
> > greater code sharing between gallium and i965.
> >
> > This series adds i965/gallium support for ARB_get_program_binary
> > with greater than 0 supported formats. Today we support this extension,
> > but advertise support for 0 formats. This series allows i965/gallium
> > to advertise support for 1 format.
> >
> > This series defines a common Mesa format for ARB_get_program_binary,
> > along with helper functions to read and write the format. The binary
> > saved can only be reloaded on the exact same Mesa build using the
> > exact same hardware.
> >
> > The i965/gallium implementation saves out a serialized nir/tgsi
> > represenation of the program. For i965 we can later add support for
> > saving the gen binary program as well. (We will still need the nir
> > program for state based recompiles.)
> >
> > This implementation passes piglit, deqp and glcts functions. It also
> > works with (and fixes a crash in) Dead Island with makes use of the
> > extension.
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965/miptree: Move isl_surf_get_(hiz|mcs)_surf out of the assert

2017-06-21 Thread Mike Lothian

Do intel run mesa through any of their test boxes like they do with kernel
patches?

On Wed, 21 Jun 2017 at 19:23 Jason Ekstrand  wrote:

> On Wed, Jun 21, 2017 at 11:20 AM, Pohjolainen, Topi <
> topi.pohjolai...@gmail.com> wrote:
>
>> On Wed, Jun 21, 2017 at 11:16:39AM -0700, Jason Ekstrand wrote:
>> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101538
>> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101539
>>
>> I guess also:
>>
>> https://bugs.freedesktop.org/show_bug.cgi?id=101535
>>
>> Thanks for the quick fix!!
>>
>
> No problem.  I've landed it now so peoples desktops can start working
> again.
>
>
>> Reviewed-by: Topi Pohjolainen 
>>
>> > Cc: Topi Pohjolainen 
>> > ---
>> >  src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 10 ++
>> >  1 file changed, 6 insertions(+), 4 deletions(-)
>> >
>> > diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
>> b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
>> > index abc7f98..3b7262f 100644
>> > --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
>> > +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
>> > @@ -1672,8 +1672,9 @@ intel_miptree_alloc_mcs(struct brw_context *brw,
>> >  * calculate equivalent MCS surface against it.
>> >  */
>> > intel_miptree_get_isl_surf(brw, mt, &temp_main_surf);
>> > -   assert(isl_surf_get_mcs_surf(&brw->isl_dev, &temp_main_surf,
>> > -&temp_mcs_surf));
>> > +   MAYBE_UNUSED bool ok =
>> > +  isl_surf_get_mcs_surf(&brw->isl_dev, &temp_main_surf,
>> &temp_mcs_surf);
>> > +   assert(ok);
>> >
>> > /* Buffer needs to be initialised requiring the buffer to be
>> immediately
>> >  * mapped to cpu space for writing. Therefore do not use the gpu
>> access
>> > @@ -1832,8 +1833,9 @@ intel_miptree_alloc_hiz(struct brw_context *brw,
>> > struct isl_surf temp_hiz_surf;
>> >
>> > intel_miptree_get_isl_surf(brw, mt, &temp_main_surf);
>> > -   assert(isl_surf_get_hiz_surf(&brw->isl_dev, &temp_main_surf,
>> > -&temp_hiz_surf));
>> > +   MAYBE_UNUSED bool ok =
>> > +  isl_surf_get_hiz_surf(&brw->isl_dev, &temp_main_surf,
>> &temp_hiz_surf);
>> > +   assert(ok);
>> >
>> > const uint32_t alloc_flags = BO_ALLOC_FOR_RENDER;
>> > mt->hiz_buf = intel_alloc_aux_buffer(brw, "hiz-miptree",
>> > --
>> > 2.5.0.400.gff86faf
>> >
>> > ___
>> > mesa-dev mailing list
>> > mesa-dev@lists.freedesktop.org
>> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965/miptree: Move isl_surf_get_(hiz|mcs)_surf out of the assert

2017-06-21 Thread Mike Lothian

On Thu, 22 Jun 2017 at 00:12 Matt Turner  wrote:

> On Wed, Jun 21, 2017 at 3:50 PM, Mike Lothian  wrote:
> > Do intel run mesa through any of their test boxes like they do with
> kernel
> > patches?
>
> Don't top quote.
>
> Yes, we have a CI system that we use extensively and has massively
> reduced the number of regressions we have. Immense thanks to Mark
> Janes for all of the work he's done on it.
>
> In this instance, the CI didn't catch it because it tests debug builds
> (as you'd expect), so the assert and the function it called were
> executed. In release builds, however, the assert and that necessary
> function call were removed.
>

Sorry, top posting is the default in Inbox and there doesn't appear to be
away to change it

I wasn't criticising, it's very rare that a serious bug creaps into master,
having said that it would have been nice to have a response on IRC when the
issue was pointed out

Least it's fixed now and I'm back to testing master again

Mike

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

Re: [Mesa-dev] configure fails to find llvm since recent llvm commit.

2017-07-04 Thread Mike Lothian

Hi

I'm not seeing this issue on Gentoo. My llvm-config --version shows
"5.0.0git-79da0992d18"

I'm attaching the patch we use

Regards

Mike

On Tue, 4 Jul 2017 at 10:10 Emil Velikov  wrote:

> On 3 July 2017 at 22:51, Andy Furniss  wrote:
> > Emil Velikov wrote:
> >>
> >> On 3 July 2017 at 16:31, Andy Furniss  wrote:
> >>>
> >>> Rafael Avila de Espindola wrote:
> 
> 
>  What check is configure doing?
> >>>
> >>>
> >>>
> >>> Not sure just a user.
> >>>
>  Is the llvm build a clean one? What is the value of
> LLVM_APPEND_VC_REV?
> >>>
> >>>
> >>>
> >>> It is a clean build.
> >>> A reply to the list advised to start using
> >>>
> >>> -DLLVM_APPEND_VC_REV=OFF
> >>>
> >>> With this it is OK.
> >>>
> >> Skimming through the LLVM it's not obvious what is the before/after
> >> output of `llvm-config --version'. Can anyone share some examples?
> >
> >
> > On current git head, well it was when I started the build from clean,
> > probably not by now :-)
> >
> > Without -DLLVM_APPEND_VC_REV=OFF the output is
> >
> > 5.0.0git-5a8feb7
> >
> > With it, it's
> >
> > 5.0.0svn
> >
> So the version is FOOgit-$SHA while the DSO uses, FOOsvn. At the same
> time at least 3.9.0/3.9.1 has broken llvm-config --libnames/libfiles,
> so we cannot rely on that.
> Doesn't seem like LLVM is giving us something robust to work with here.
>
> LLVM users/devs (Rafael), I would suggest up-streaming a patch which
> changes that toggle default value, for now.
> As LLVM does a few releases where it has a reliable way of determining
> the library name users can switch to it.
>
> How does this sound?
>
> Thanks
> Emil
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>


0007-llvm-config-Clean-up-exported-values-update-for-shar.patch
Description: Binary data
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Gallium ARB_get_program_binary support

2017-12-09 Thread Mike Lothian

I can confirm these sort the crash on Dead Island and I can confirm I'm
also seeing the segfault with Dirt Rally

On Fri, 8 Dec 2017 at 09:58 Timothy Arceri  wrote:

> Core support in now in master so this is just a resend of the gallium
> patches.
>
> Resolves crash in Dead Island:
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85564
>
> Branch available here:
>
> https://github.com/tarceri/Mesa.git gallium-program-binary
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Gallium ARB_get_program_binary support

2017-12-11 Thread Mike Lothian

Tested with Dead Island, Dirt Rally and Serious Sam BFG (which I believe
uses this extension)

Do you know any other games that use this?

On Mon, 11 Dec 2017 at 02:17 Dieter Nützel  wrote:

> For the V2 series:
>
> Tested-by: Dieter Nützel 
> and
> Acked-by: Dieter Nützel 
> if this is worth from my side.
>
> on RX580 8GB
>
> with DiRT Rally, UH, UV, Blender 2.79, smoketest, F1 2017 (Vulkan),
> glmark2 (parallel with
> OpenCL (/opt/opencl-example>./run_tests.sh))
>
> Dieter
>
> Am 10.12.2017 23:06, schrieb Timothy Arceri:
> > On 10/12/17 17:56, Dieter Nützel wrote:
> >> First BAD commit is patch [PATCH 2/5].
> >> https://patchwork.freedesktop.org/patch/192329/
> >
> >
> > Thanks! I've sent a V2 of that patch, I've also confirmed DiRT Rally
> > no longer segfaults at start-up.
> >
> >> With it I get this in dmesg:
> >>
> >> [34581.836122] OGL_Dispatch_33[4887]: segfault at 0 ip
> >> 9ebeafda sp a95580d4 error 4 in
> >> libc-2.26.so[7f6afcaf7000+1b1000]
> >> [34706.224082] perf: interrupt took too long (5089 > 4913), lowering
> >> kernel.perf_event_max_sample_rate to 39250
> >> [34918.80] OGL_Dispatch_33[19897]: segfault at 0 ip
> >> d9adbd7a sp e6e1b769 error 4 in
> >> libc-2.26.so[7f2fc4777000+1b1000]
> >> [35148.576818] OGL_Dispatch_33[2934]: segfault at 0 ip
> >> 78a41511 sp 1f147296 error 4 in
> >> libc-2.26.so[7ff11fa23000+1b1000]
> >> [35172.410621] OGL_Dispatch_33[3371]: segfault at 0 ip
> >> ef37ae37 sp 99ce37ab error 4 in
> >> libc-2.26.so[7f0af78ff000+1b1000]
> >> [35383.940291] OGL_Dispatch_33[18591]: segfault at 0 ip
> >> 813f92d2 sp 7c9305e7 error 4 in
> >> libc-2.26.so[7fee87426000+1b1000]
> >>
> >> It's in the morning, now.
> >> Here in 'OLD' Germany, near Hamburg.
> >> Good night! ;-)
> >>
> >> Dieter
> >>
> >> Am 10.12.2017 05:15, schrieb Timothy Arceri:
> >>> Hi, as always thanks for testing :)
> >>>
> >>> Are you able to find out which patch causes the crash? I'm curious if
> >>> its the ARB_get_program_binary support or if I break the regular
> >>> cache
> >>> when re-factoring.
> >>>
> >>> Thanks,
> >>> Tim
> >>>
> >>> On 09/12/17 15:58, Dieter Nützel wrote:
>  Hello Tim,
> 
>  first time ever, that I got a real regression with your GREAT work.
>  ;-)
> 
>  DiRT Rally sig fault (SIGSEGV(11) with this series.
>  (see attachment)
> 
>  Bad cache hit re-read?
>  Removing .cache/mesa_shader_cache do not help.
>  Searching for the rigth Feral (Steam?) cache dir. - Alex/James?
> 
>  Then I'll have to find which of the five did it.
> 
>   From the log I got this:
>  [1209/054156:ERROR:sandbox_linux.cc(325)] InitializeSandbox() called
>  with multiple threads in process gpu-process
>  [1209/054157:INFO:CONSOLE(0)] "The specified value '!' does not
>  conform to the required format.  The format is '#rrggbb' where rr,
>  gg, bb are two-digit hexadecimal numbers.", source:
> 
> file://localhost/home1/alexander/My%20Games/Steam/steamapps/common/DiRT%20Rally/share/FeralUI/PGOW/Core/feralUI.html
>  (0)
>  Installing breakpad exception handler for
>  appid(steam)/version(1509425745)
>  [1209/054158:INFO:CONSOLE(0)] "Synchronous XMLHttpRequest on the
>  main thread is deprecated because of its detrimental effects to the
>  end user's experience. For more help, check
>  http://xhr.spec.whatwg.org/.";, source:  (0)
>  [1209/054208:WARNING:x11_util.cc(1490)] X error received: serial
>  4814, error_code 3 (BadWindow (invalid Window parameter)),
>  request_code 4, minor_code 0 (X_DestroyWindow)
>  SDL2 initialised [built against 2.0.5, running with 2.0.5]
>  DirtRally: dumped to
>  "/home/alexander/.local/share/feral-interactive/DiRT
>  Rally/crashes/2363a778-c194-621f-0f837dfb-191070fd.dmp"
> 
>  Cheers,
>  Dieter
> 
>  Am 08.12.2017 10:57, schrieb Timothy Arceri:
> > Core support in now in master so this is just a resend of the
> > gallium
> > patches.
> >
> > Resolves crash in Dead Island:
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85564
> >
> > Branch available here:
> >
> > https://github.com/tarceri/Mesa.git gallium-program-binary
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Gallium ARB_get_program_binary support

2017-12-11 Thread Mike Lothian

I'll check that when I'm next home

On Mon, 11 Dec 2017 at 21:19 Timothy Arceri  wrote:

> On 12/12/17 08:13, Mike Lothian wrote:
> > Tested with Dead Island, Dirt Rally and Serious Sam BFG (which I believe
> > uses this extension)
> >
> > Do you know any other games that use this?
>
> I believe Dying Light uses it also.
>
>
> >
> > On Mon, 11 Dec 2017 at 02:17 Dieter Nützel  > <mailto:die...@nuetzel-hh.de>> wrote:
> >
> > For the V2 series:
> >
> > Tested-by: Dieter Nützel  > <mailto:die...@nuetzel-hh.de>>
> > and
> > Acked-by: Dieter Nützel  > <mailto:die...@nuetzel-hh.de>>
> > if this is worth from my side.
> >
> > on RX580 8GB
> >
> > with DiRT Rally, UH, UV, Blender 2.79, smoketest, F1 2017 (Vulkan),
> > glmark2 (parallel with
> > OpenCL (/opt/opencl-example>./run_tests.sh))
> >
> > Dieter
> >
> > Am 10.12.2017 23:06, schrieb Timothy Arceri:
> >  > On 10/12/17 17:56, Dieter Nützel wrote:
> >  >> First BAD commit is patch [PATCH 2/5].
> >  >> https://patchwork.freedesktop.org/patch/192329/
> >  >
> >  >
> >  > Thanks! I've sent a V2 of that patch, I've also confirmed DiRT
> Rally
> >  > no longer segfaults at start-up.
> >  >
> >  >> With it I get this in dmesg:
> >  >>
> >  >> [34581.836122] OGL_Dispatch_33[4887]: segfault at 0 ip
> >  >> 9ebeafda sp a95580d4 error 4 in
> >  >> libc-2.26.so <http://libc-2.26.so>[7f6afcaf7000+1b1000]
> >  >> [34706.224082] perf: interrupt took too long (5089 > 4913),
> lowering
> >  >> kernel.perf_event_max_sample_rate to 39250
> >  >> [34918.80] OGL_Dispatch_33[19897]: segfault at 0 ip
> >  >> d9adbd7a sp e6e1b769 error 4 in
> >  >> libc-2.26.so <http://libc-2.26.so>[7f2fc4777000+1b1000]
> >  >> [35148.576818] OGL_Dispatch_33[2934]: segfault at 0 ip
> >  >> 78a41511 sp 1f147296 error 4 in
> >  >> libc-2.26.so <http://libc-2.26.so>[7ff11fa23000+1b1000]
> >  >> [35172.410621] OGL_Dispatch_33[3371]: segfault at 0 ip
> >  >> ef37ae37 sp 99ce37ab error 4 in
> >  >> libc-2.26.so <http://libc-2.26.so>[7f0af78ff000+1b1000]
> >  >> [35383.940291] OGL_Dispatch_33[18591]: segfault at 0 ip
> >  >> 813f92d2 sp 7c9305e7 error 4 in
> >  >> libc-2.26.so <http://libc-2.26.so>[7fee87426000+1b1000]
> >  >>
> >  >> It's in the morning, now.
> >  >> Here in 'OLD' Germany, near Hamburg.
> >  >> Good night! ;-)
> >  >>
> >  >> Dieter
> >  >>
> >  >> Am 10.12.2017 05:15, schrieb Timothy Arceri:
> >  >>> Hi, as always thanks for testing :)
> >  >>>
> >  >>> Are you able to find out which patch causes the crash? I'm
> > curious if
> >  >>> its the ARB_get_program_binary support or if I break the regular
> >  >>> cache
> >  >>> when re-factoring.
> >  >>>
> >  >>> Thanks,
> >  >>> Tim
> >  >>>
> >  >>> On 09/12/17 15:58, Dieter Nützel wrote:
> >  >>>> Hello Tim,
> >  >>>>
> >  >>>> first time ever, that I got a real regression with your GREAT
> > work.
> >  >>>> ;-)
> >  >>>>
> >  >>>> DiRT Rally sig fault (SIGSEGV(11) with this series.
> >  >>>> (see attachment)
> >  >>>>
> >  >>>> Bad cache hit re-read?
> >  >>>> Removing .cache/mesa_shader_cache do not help.
> >  >>>> Searching for the rigth Feral (Steam?) cache dir. - Alex/James?
> >  >>>>
> >  >>>> Then I'll have to find which of the five did it.
> >  >>>>
> >  >>>>  From the log I got this:
> >  >>>> [1209/054156:ERROR:sandbox_linux.cc(325)] InitializeSandbox()
> > called
> >  >>>> with multiple threads in process gpu-process
> >  >>>> [1209/054157:INFO:CONSOLE(0)] "

1 2 3 >

1 - 100 of 212 matches

Mail list logo