date:20140822

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

  Priority: medium
Bug ID: 82946
  Assignee: mesa-dev@lists.freedesktop.org
   Summary: Build failure while linking libMesaOpenCL.la with any
Mesa release = 10.2: undefined references to
.LLST7{1,5,9}
  Severity: major
Classification: Unclassified
OS: Linux (All)
  Reporter: mc2...@mclink.it
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: 10.2
 Component: Other
   Product: Mesa

Created attachment 105097
  -- https://bugs.freedesktop.org/attachment.cgi?id=105097action=edit
Log of a failed  build

I'm trying to build a rpm package of Mesa 10.2.6 for Rosa Fresh 2012.1 R3, but
the build process always fails while linking libMesaOpenCL.la in
src/gallium/targets/opencl, with the error message below:

***
Making all in opencl
gmake[3]: Entering directory
`/home/giovanni/rpm/BUILD/Mesa-10.2.6/src/gallium/targets/opencl'
  CXXLDlibMesaOpenCL.la
../../../../src/gallium/state_trackers/clover/.libs/libclover.a(lt9-libclover_la-kernel.o):(.debug_types[wt.a9eb1c180a77705c]+0x1e1):
undefined reference to `.LLST71'
../../../../src/gallium/state_trackers/clover/.libs/libclover.a(lt9-libclover_la-kernel.o):(.debug_types[wt.a9eb1c180a77705c]+0x2bf):
undefined reference to `.LLST75'
../../../../src/gallium/state_trackers/clover/.libs/libclover.a(lt9-libclover_la-kernel.o):(.debug_types[wt.a9eb1c180a77705c]+0x391):
undefined reference to `.LLST79'
../../../../src/gallium/state_trackers/clover/.libs/libclover.a(lt9-libclover_la-kernel.o):(.debug_types[wt.ba46d5e26f0312cc]+0x22c):
undefined reference to `.LLST71'
../../../../src/gallium/state_trackers/clover/.libs/libclover.a(lt9-libclover_la-kernel.o):(.debug_types[wt.ba46d5e26f0312cc]+0x30a):
undefined reference to `.LLST75'
../../../../src/gallium/state_trackers/clover/.libs/libclover.a(lt9-libclover_la-kernel.o):(.debug_types[wt.ba46d5e26f0312cc]+0x3dc):
undefined reference to `.LLST79'
../../../../src/gallium/state_trackers/clover/.libs/libclover.a(lt9-libclover_la-kernel.o):(.debug_types[wt.925e964f0ba680c7]+0x1e1):
undefined reference to `.LLST71'
../../../../src/gallium/state_trackers/clover/.libs/libclover.a(lt9-libclover_la-kernel.o):(.debug_types[wt.925e964f0ba680c7]+0x2bf):
undefined reference to `.LLST75'
../../../../src/gallium/state_trackers/clover/.libs/libclover.a(lt9-libclover_la-kernel.o):(.debug_types[wt.925e964f0ba680c7]+0x391):
undefined reference to `.LLST79'
../../../../src/gallium/state_trackers/clover/.libs/libclover.a(lt9-libclover_la-kernel.o):(.debug_types[wt.cae0c7e56b9d064f]+0x578):
undefined reference to `.LLST71'
../../../../src/gallium/state_trackers/clover/.libs/libclover.a(lt9-libclover_la-kernel.o):(.debug_types[wt.cae0c7e56b9d064f]+0x656):
undefined reference to `.LLST75'
../../../../src/gallium/state_trackers/clover/.libs/libclover.a(lt9-libclover_la-kernel.o):(.debug_types[wt.cae0c7e56b9d064f]+0x728):
undefined reference to `.LLST79'
../../../../src/gallium/state_trackers/clover/.libs/libclover.a(lt9-libclover_la-kernel.o):(.debug_types[wt.b0ea443f945b6ea5]+0x3d1):
undefined reference to `.LLST71'
../../../../src/gallium/state_trackers/clover/.libs/libclover.a(lt9-libclover_la-kernel.o):(.debug_types[wt.b0ea443f945b6ea5]+0x4af):
undefined reference to `.LLST75'
../../../../src/gallium/state_trackers/clover/.libs/libclover.a(lt9-libclover_la-kernel.o):(.debug_types[wt.b0ea443f945b6ea5]+0x581):
undefined reference to `.LLST79'
../../../../src/gallium/state_trackers/clover/.libs/libclover.a(lt9-libclover_la-kernel.o):(.debug_types[wt.8993a09bd283ed4a]+0x441):
undefined reference to `.LLST71'
../../../../src/gallium/state_trackers/clover/.libs/libclover.a(lt9-libclover_la-kernel.o):(.debug_types[wt.8993a09bd283ed4a]+0x51f):
undefined reference to `.LLST75'
../../../../src/gallium/state_trackers/clover/.libs/libclover.a(lt9-libclover_la-kernel.o):(.debug_types[wt.8993a09bd283ed4a]+0x5f1):
undefined reference to `.LLST79'
../../../../src/gallium/state_trackers/clover/.libs/libclover.a(lt9-libclover_la-kernel.o):(.debug_types[wt.6e263beb89c080c1]+0x449):
undefined reference to `.LLST71'
../../../../src/gallium/state_trackers/clover/.libs/libclover.a(lt9-libclover_la-kernel.o):(.debug_types[wt.6e263beb89c080c1]+0x527):
undefined reference to `.LLST75'
../../../../src/gallium/state_trackers/clover/.libs/libclover.a(lt9-libclover_la-kernel.o):(.debug_types[wt.6e263beb89c080c1]+0x5f9):
undefined reference to `.LLST79'
collect2: error: ld returned 1 exit status
gmake[3]: *** [libMesaOpenCL.la] Error 1
***

The above error is present for me in any released source from Mesa 10.2 to Mesa
10.2.6, while any source from the 10.1.x series does not fail to build.

My build tools:
automake 1.14
libtool 2.4.2
gcc 4.7.4
llvm/clang 3.4 (I tested also the rel. 3.4.2 in a VM, with the same results)
libclc

[Mesa-dev] [Bug 82946] Build failure while linking libMesaOpenCL.la with any Mesa release = 10.2: undefined references to .LLST7{1, 5, 9}

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

Giovanni Mariani mc2...@mclink.it changed:

   What|Removed |Added

 CC||mc2...@mclink.it

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

Re: [Mesa-dev] [PATCH] i965: First step toward prelocation

2014-08-22 Thread Alex Deucher

On Thu, Aug 21, 2014 at 11:12 PM, Ben Widawsky
benjamin.widaw...@intel.com wrote:
 This was a quick proof of concept to show the new API for prelocating
 buffers.


What are prelocated buffers?

Alex

 It needs way more testing, to not ifdef the no-relocs, and to do a
 libdrm ABI dep bump.
 ---
  src/mesa/drivers/dri/i965/Makefile.am   | 1 +
  src/mesa/drivers/dri/i965/brw_performance_monitor.c | 6 +++---
  src/mesa/drivers/dri/i965/brw_program.c | 5 +++--
  src/mesa/drivers/dri/i965/brw_queryobj.c| 6 +++---
  src/mesa/drivers/dri/i965/brw_state_cache.c | 4 ++--
  src/mesa/drivers/dri/i965/intel_batchbuffer.c   | 3 +++
  src/mesa/drivers/dri/i965/intel_batchbuffer.h   | 8 
  7 files changed, 23 insertions(+), 10 deletions(-)

 diff --git a/src/mesa/drivers/dri/i965/Makefile.am 
 b/src/mesa/drivers/dri/i965/Makefile.am
 index 5809dc6..4b20d36 100644
 --- a/src/mesa/drivers/dri/i965/Makefile.am
 +++ b/src/mesa/drivers/dri/i965/Makefile.am
 @@ -24,6 +24,7 @@
  include Makefile.sources

  AM_CFLAGS = \
 +-DNO_RELOC \
 -I$(top_srcdir)/include \
 -I$(top_srcdir)/src/ \
 -I$(top_srcdir)/src/mapi \
 diff --git a/src/mesa/drivers/dri/i965/brw_performance_monitor.c 
 b/src/mesa/drivers/dri/i965/brw_performance_monitor.c
 index edfa3d2..e30c527 100644
 --- a/src/mesa/drivers/dri/i965/brw_performance_monitor.c
 +++ b/src/mesa/drivers/dri/i965/brw_performance_monitor.c
 @@ -1105,13 +1105,13 @@ brw_begin_perf_monitor(struct gl_context *ctx,
 * wasting memory for contexts that don't use performance monitors.
 */
if (!brw-perfmon.bookend_bo) {
 - brw-perfmon.bookend_bo = drm_intel_bo_alloc(brw-bufmgr,
 + brw-perfmon.bookend_bo = drm_intel_bo_alloc_wrapper(brw-bufmgr,
OA bookend BO,
BOOKEND_BO_SIZE_BYTES, 
 64);
}

monitor-oa_bo =
 - drm_intel_bo_alloc(brw-bufmgr, perf. monitor OA bo, 4096, 64);
 + drm_intel_bo_alloc_wrapper(brw-bufmgr, perf. monitor OA bo, 
 4096, 64);
  #ifdef DEBUG
/* Pre-filling the BO helps debug whether writes landed. */
drm_intel_bo_map(monitor-oa_bo, true);
 @@ -1146,7 +1146,7 @@ brw_begin_perf_monitor(struct gl_context *ctx,

 if (monitor_needs_statistics_registers(brw, m)) {
monitor-pipeline_stats_bo =
 - drm_intel_bo_alloc(brw-bufmgr, perf. monitor stats bo, 4096, 64);
 + drm_intel_bo_alloc_wrapper(brw-bufmgr, perf. monitor stats bo, 
 4096, 64);

/* Take starting snapshots. */
snapshot_statistics_registers(brw, monitor, 0);
 diff --git a/src/mesa/drivers/dri/i965/brw_program.c 
 b/src/mesa/drivers/dri/i965/brw_program.c
 index d782b4f..74ff40c 100644
 --- a/src/mesa/drivers/dri/i965/brw_program.c
 +++ b/src/mesa/drivers/dri/i965/brw_program.c
 @@ -43,6 +43,7 @@

  #include brw_context.h
  #include brw_wm.h
 +#include intel_batchbuffer.h

  static unsigned
  get_new_program_id(struct intel_screen *screen)
 @@ -242,7 +243,7 @@ brw_get_scratch_bo(struct brw_context *brw,
 }

 if (!old_bo) {
 -  *scratch_bo = drm_intel_bo_alloc(brw-bufmgr, scratch bo, size, 
 4096);
 +  *scratch_bo = drm_intel_bo_alloc_wrapper(brw-bufmgr, scratch bo, 
 size, 4096);
 }
  }

 @@ -265,7 +266,7 @@ void
  brw_init_shader_time(struct brw_context *brw)
  {
 const int max_entries = 4096;
 -   brw-shader_time.bo = drm_intel_bo_alloc(brw-bufmgr, shader time,
 +   brw-shader_time.bo = drm_intel_bo_alloc_wrapper(brw-bufmgr, shader 
 time,
  max_entries * SHADER_TIME_STRIDE,
  4096);
 brw-shader_time.shader_programs = rzalloc_array(brw, struct 
 gl_shader_program *,
 diff --git a/src/mesa/drivers/dri/i965/brw_queryobj.c 
 b/src/mesa/drivers/dri/i965/brw_queryobj.c
 index c053c34..cf5a2a5 100644
 --- a/src/mesa/drivers/dri/i965/brw_queryobj.c
 +++ b/src/mesa/drivers/dri/i965/brw_queryobj.c
 @@ -230,7 +230,7 @@ brw_begin_query(struct gl_context *ctx, struct 
 gl_query_object *q)
 * the system was doing other work, such as running other applications.
 */
drm_intel_bo_unreference(query-bo);
 -  query-bo = drm_intel_bo_alloc(brw-bufmgr, timer query, 4096, 4096);
 +  query-bo = drm_intel_bo_alloc_wrapper(brw-bufmgr, timer query, 
 4096, 4096);
brw_write_timestamp(brw, query-bo, 0);
break;

 @@ -388,7 +388,7 @@ ensure_bo_has_space(struct gl_context *ctx, struct 
 brw_query_object *query)
   brw_queryobj_get_results(ctx, query);
}

 -  query-bo = drm_intel_bo_alloc(brw-bufmgr, query, 4096, 1);
 +  query-bo = drm_intel_bo_alloc_wrapper(brw-bufmgr, query, 4096, 1);
query-last_index = 0;
 }
  }
 @@ -474,7 +474,7 @@ brw_query_counter(struct gl_context *ctx, struct 
 gl_query_object *q)
 assert(q-Target ==

[Mesa-dev] [Bug 82946] Build failure while linking libMesaOpenCL.la with any Mesa release = 10.2: undefined references to .LLST7{1, 5, 9}

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

--- Comment #1 from Francisco Jerez curroje...@riseup.net ---
Seems like a compiler bug to me.  Your debug section-related CXXFLAGS
(-Wa,--compress-debug-sections -gdwarf-4) probably have an influence, try
removing them, or upgrade to a more recent version of GCC (works for me with
the same compiler flags on GCC v4.9.1).

Thanks.

-- 
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] [PATCH] kms-swrast: Support Prime fd handling

Allows using prime fds as display target and from display target.
Test for PRIME capability after initializing kms_swrast screen.

Signed-off-by: Andreas Pokorny andreas.poko...@canonical.com
---
 src/gallium/state_trackers/dri/dri2.c |  8 +++
 src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c | 80 ---
 2 files changed, 78 insertions(+), 10 deletions(-)

diff --git a/src/gallium/state_trackers/dri/dri2.c 
b/src/gallium/state_trackers/dri/dri2.c
index a63448d..82f8a47 100644
--- a/src/gallium/state_trackers/dri/dri2.c
+++ b/src/gallium/state_trackers/dri/dri2.c
@@ -1333,6 +1333,7 @@ dri_kms_init_screen(__DRIscreen * sPriv)
const __DRIconfig **configs;
struct dri_screen *screen;
struct pipe_screen *pscreen = NULL;
+   uint64_t cap;
 
screen = CALLOC_STRUCT(dri_screen);
if (!screen)
@@ -1344,6 +1345,13 @@ dri_kms_init_screen(__DRIscreen * sPriv)
sPriv-driverPrivate = (void *)screen;
 
pscreen = kms_swrast_create_screen(screen-fd);
+
+   if (drmGetCap(sPriv-fd, DRM_CAP_PRIME, cap) == 0 
+  (cap  DRM_PRIME_CAP_IMPORT)) {
+  dri2ImageExtension.createImageFromFds = dri2_from_fds;
+  dri2ImageExtension.createImageFromDmaBufs = dri2_from_dma_bufs;
+   }
+
sPriv-extensions = dri_screen_extensions;
 
/* dri_init_screen_helper checks pscreen for us */
diff --git a/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c 
b/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
index c9934bb..286bd9c 100644
--- a/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
+++ b/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
@@ -38,6 +38,7 @@
 #include sys/mman.h
 #include unistd.h
 #include dlfcn.h
+#include fcntl.h
 #include xf86drm.h
 
 #include pipe/p_compiler.h
@@ -210,6 +211,38 @@ kms_sw_displaytarget_map(struct sw_winsys *ws,
return kms_sw_dt-mapped;
 }
 
+static struct kms_sw_displaytarget *
+kms_sw_displaytarget_add_from_prime(struct kms_sw_winsys *kms_sw, int fd)
+{
+   uint32_t handle;
+   struct kms_sw_displaytarget * kms_sw_dt;
+   int ret;
+
+   ret = drmPrimeFDToHandle(kms_sw-fd, fd, handle);
+
+   if (ret)
+  return NULL;
+
+   kms_sw_dt = CALLOC_STRUCT(kms_sw_displaytarget);
+   if (!kms_sw_dt)
+  return NULL;
+
+   kms_sw_dt-ref_count = 1;
+   kms_sw_dt-handle = handle;
+   kms_sw_dt-size = lseek(fd, 0, SEEK_END);
+
+   if (kms_sw_dt-size == (off_t)-1) {
+  FREE(kms_sw_dt);
+  return NULL;
+   }
+
+   lseek(fd, 0, SEEK_SET);
+
+   list_add(kms_sw_dt-link, kms_sw-bo_list);
+
+   return kms_sw_dt;
+}
+
 static void
 kms_sw_displaytarget_unmap(struct sw_winsys *ws,
struct sw_displaytarget *dt)
@@ -231,17 +264,34 @@ kms_sw_displaytarget_from_handle(struct sw_winsys *ws,
struct kms_sw_winsys *kms_sw = kms_sw_winsys(ws);
struct kms_sw_displaytarget *kms_sw_dt;
 
-   assert(whandle-type == DRM_API_HANDLE_TYPE_KMS);
+   assert(whandle-type == DRM_API_HANDLE_TYPE_KMS ||
+  whandle-type == DRM_API_HANDLE_TYPE_FD);
 
-   LIST_FOR_EACH_ENTRY(kms_sw_dt, kms_sw-bo_list, link) {
-  if (kms_sw_dt-handle == whandle-handle) {
+   switch(whandle-type) {
+   case DRM_API_HANDLE_TYPE_FD:
+  kms_sw_dt = kms_sw_displaytarget_add_from_prime(kms_sw, whandle-handle);
+  if (kms_sw_dt) {
  kms_sw_dt-ref_count++;
+ kms_sw_dt-width = templ-width0;
+ kms_sw_dt-height = templ-height0;
+ if (kms_sw_dt-height)
+kms_sw_dt-stride = kms_sw_dt-size/kms_sw_dt-height;
+ *stride = kms_sw_dt-stride;
+  }
+  return (struct sw_displaytarget *)kms_sw_dt;
+   case DRM_API_HANDLE_TYPE_KMS:
+  LIST_FOR_EACH_ENTRY(kms_sw_dt, kms_sw-bo_list, link) {
+ if (kms_sw_dt-handle == whandle-handle) {
+kms_sw_dt-ref_count++;
 
- DEBUG(KMS-DEBUG: imported buffer %u (size %u)\n, kms_sw_dt-handle, 
kms_sw_dt-size);
+DEBUG(KMS-DEBUG: imported buffer %u (size %u)\n, 
kms_sw_dt-handle, kms_sw_dt-size);
 
- *stride = kms_sw_dt-stride;
- return (struct sw_displaytarget *)kms_sw_dt;
+*stride = kms_sw_dt-stride;
+return (struct sw_displaytarget *)kms_sw_dt;
+ }
   }
+   default:
+   break;
}
 
assert(0);
@@ -253,16 +303,26 @@ kms_sw_displaytarget_get_handle(struct sw_winsys *winsys,
 struct sw_displaytarget *dt,
 struct winsys_handle *whandle)
 {
+   struct kms_sw_winsys *kms_sw = kms_sw_winsys(winsys);
struct kms_sw_displaytarget *kms_sw_dt = kms_sw_displaytarget(dt);
 
-   if (whandle-type == DRM_API_HANDLE_TYPE_KMS) {
+   switch(whandle-type) {
+   case DRM_API_HANDLE_TYPE_KMS:
   whandle-handle = kms_sw_dt-handle;
   whandle-stride = kms_sw_dt-stride;
-   } else {
+  return TRUE;
+   case DRM_API_HANDLE_TYPE_FD:
+  if (!drmPrimeHandleToFD(kms_sw-fd, kms_sw_dt-handle,
+ DRM_CLOEXEC, whandle-handle)) {
+ whandle-stride = kms_sw_dt-stride;
+

[Mesa-dev] [PATCH] kma-swrast: PRIME support v2

Hi, 
This adds support for dma_bufs throught fds to kms_swrast.

Andreas Pokorny (1):
  kms-swrast: Support Prime fd handling

 src/gallium/state_trackers/dri/dri2.c |  8 +++
 src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c | 80 ---
 2 files changed, 78 insertions(+), 10 deletions(-)

-- 
2.1.0.rc1

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

Re: [Mesa-dev] [Intel-gfx] [PATCH 00/68] Broadwell 48b addressing and prelocations (no relocs)

2014-08-22 Thread Daniel Vetter

On Fri, Aug 22, 2014 at 9:03 AM, Chris Wilson ch...@chris-wilson.co.uk wrote:
   If a GPU
   client uses only prelocations, the relocation process can be entirely
   skipped. This sounds like a big win initially,
 
  Close to zero if the client uses existing interfaces.
  -Chris

 Chris,

 I don't know if you've seen Ben's libdrm and Mesa patches, but with a few 
 patches to libdrm and virtually zero Mesa changes, he's apparently 
 eliminated our need to do any relocations for the 3D driver.  It wasn't 
 invasive at all---I was surprised.

 Indeed, you could do everything inside libdrm with the code I posted 2
 years ago.

I915_EXEC_NO_RELOC can be used to tell the kernel that it doesn't need
to walk all the reloc tables (if nothing moved) because userspace
didn't go insane and reuse reloc trees. So you'd need to implement a
flag + a libdrm function to set that (iirc mesa has been non-stupid
since years). And yeah I kinda expect any new reloc-less thing to get
benchmarked against an implementation using that, since the 48bit
specific thing proposed looks like a fairly short-lived stop-gap, and
since the current no-reloc we already have would work everywhere. And
yeah I've been poking people to look at this for years. too.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Intel-gfx] [PATCH 00/68] Broadwell 48b addressing and prelocations (no relocs)

2014-08-22 Thread Chris Wilson

On Fri, Aug 22, 2014 at 03:30:12PM +0200, Daniel Vetter wrote:
 On Fri, Aug 22, 2014 at 9:03 AM, Chris Wilson ch...@chris-wilson.co.uk 
 wrote:
If a GPU
client uses only prelocations, the relocation process can be entirely
skipped. This sounds like a big win initially,
  
   Close to zero if the client uses existing interfaces.
   -Chris
 
  Chris,
 
  I don't know if you've seen Ben's libdrm and Mesa patches, but with a few 
  patches to libdrm and virtually zero Mesa changes, he's apparently 
  eliminated our need to do any relocations for the 3D driver.  It wasn't 
  invasive at all---I was surprised.
 
  Indeed, you could do everything inside libdrm with the code I posted 2
  years ago.
 
 I915_EXEC_NO_RELOC can be used to tell the kernel that it doesn't need
 to walk all the reloc tables (if nothing moved) because userspace
 didn't go insane and reuse reloc trees. So you'd need to implement a
 flag + a libdrm function to set that (iirc mesa has been non-stupid
 since years). And yeah I kinda expect any new reloc-less thing to get
 benchmarked against an implementation using that, since the 48bit
 specific thing proposed looks like a fairly short-lived stop-gap, and
 since the current no-reloc we already have would work everywhere. And
 yeah I've been poking people to look at this for years. too.

Here, I was referring to soft-pinning. The API here is essentially
comprised of two parts:

1: a pin into the vm upon creation
2: implicit no-relocation upon execbuffer

By making those two steps independent, the API as I see is, is more
flexible and powerful.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC PATCH 00/16] A new IR for Mesa

2014-08-22 Thread Tom Stellard

On Fri, Aug 22, 2014 at 01:08:02PM +1000, Dave Airlie wrote:
 On 22 August 2014 12:46, Jason Ekstrand ja...@jlekstrand.net wrote:
  On Thu, Aug 21, 2014 at 7:36 PM, Dave Airlie airl...@gmail.com wrote:
 
  On 21 August 2014 19:10, Henri Verbeet hverb...@gmail.com wrote:
   On 21 August 2014 04:56, Michel Dänzer mic...@daenzer.net wrote:
   On 21.08.2014 04:29, Henri Verbeet wrote:
   For whatever it's worth, I have been avoiding radeonsi in part because
   of the LLVM dependency. Some of the other issues already mentioned
   aside, I also think it makes it just painful to do bisects over
   moderate/longer periods of time.
  
   More painful, sure, but not too bad IME. In particular, if you know the
   regression is in Mesa, you can always use a stable release of LLVM for
   the bisect. You only need to change the --with-llvm-prefix= parameter
   to
   Mesa's configure for that. Of course, it could still be mildly painful
   if you need to go so far back that the current stable LLVM release
   wasn't supported yet. But how often does that happen? Very rarely for
   me.
  
   Sure, it's not impossible, but is that really the kind of process you
   want users to go through when bisecting a regression? Perhaps throw in
   building 32-bit versions of both Mesa and LLVM on 64-bit as well if
   they want to run 32-bit applications.
  
   Without LLVM, I'm not sure there would be a driver you could avoid. :)
  
   R600g didn't really exist either, and that one seems to have worked
   out fine. I think in a large part because of work done by Jerome and
   Dave in the early days, but regardless. From what I've seen from SI, I
   don't think radeonsi needed to be a separate driver to start with, and
   while its ISA is certainly different from R600-Cayman, it doesn't
   particularly strike me as much harder to work with.
  
   Back to the more immediate topic though, I think think that on
   occasion the discussion is framed as Is there any reason using LLVM
   IR wouldn't work?, while it would perhaps be more appropriate to
   think of as Would using LLVM IR provide enough advantages to justify
   adding a LLVM dependency to core Mesa?.
 
  Could we use an llvm compatible IR? is also a question I'd like to see
  answered.
 
 
  What do you mean by llvm compatible?  Do you mean forking their IR inside
  mesa or just something that's easy to translate back and forth?
 
 
 Importing/forking the llvm IR code with a different symbol set, and
 trying to not intentionally
 be incompatible with their llvm.
 

What would be the purpose of doing this?  Avoiding a dependency on the LLVM 
libraries?

-Tom

 Dave.
 ___
 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] [RFC PATCH 00/16] A new IR for Mesa

2014-08-22 Thread Dave Airlie

On 23 August 2014 00:15, Tom Stellard t...@stellard.net wrote:
 On Fri, Aug 22, 2014 at 01:08:02PM +1000, Dave Airlie wrote:
 On 22 August 2014 12:46, Jason Ekstrand ja...@jlekstrand.net wrote:
  On Thu, Aug 21, 2014 at 7:36 PM, Dave Airlie airl...@gmail.com wrote:
 
  On 21 August 2014 19:10, Henri Verbeet hverb...@gmail.com wrote:
   On 21 August 2014 04:56, Michel Dänzer mic...@daenzer.net wrote:
   On 21.08.2014 04:29, Henri Verbeet wrote:
   For whatever it's worth, I have been avoiding radeonsi in part because
   of the LLVM dependency. Some of the other issues already mentioned
   aside, I also think it makes it just painful to do bisects over
   moderate/longer periods of time.
  
   More painful, sure, but not too bad IME. In particular, if you know the
   regression is in Mesa, you can always use a stable release of LLVM for
   the bisect. You only need to change the --with-llvm-prefix= parameter
   to
   Mesa's configure for that. Of course, it could still be mildly painful
   if you need to go so far back that the current stable LLVM release
   wasn't supported yet. But how often does that happen? Very rarely for
   me.
  
   Sure, it's not impossible, but is that really the kind of process you
   want users to go through when bisecting a regression? Perhaps throw in
   building 32-bit versions of both Mesa and LLVM on 64-bit as well if
   they want to run 32-bit applications.
  
   Without LLVM, I'm not sure there would be a driver you could avoid. :)
  
   R600g didn't really exist either, and that one seems to have worked
   out fine. I think in a large part because of work done by Jerome and
   Dave in the early days, but regardless. From what I've seen from SI, I
   don't think radeonsi needed to be a separate driver to start with, and
   while its ISA is certainly different from R600-Cayman, it doesn't
   particularly strike me as much harder to work with.
  
   Back to the more immediate topic though, I think think that on
   occasion the discussion is framed as Is there any reason using LLVM
   IR wouldn't work?, while it would perhaps be more appropriate to
   think of as Would using LLVM IR provide enough advantages to justify
   adding a LLVM dependency to core Mesa?.
 
  Could we use an llvm compatible IR? is also a question I'd like to see
  answered.
 
 
  What do you mean by llvm compatible?  Do you mean forking their IR inside
  mesa or just something that's easy to translate back and forth?
 

 Importing/forking the llvm IR code with a different symbol set, and
 trying to not intentionally
 be incompatible with their llvm.


 What would be the purpose of doing this?  Avoiding a dependency on the LLVM 
 libraries?

Spltting the problem of using llvm IR from the problem of linking with
llvm, since people
appear to be conflating them.

So yes avoid the direct dep for now.

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

Re: [Mesa-dev] [PATCH] glsl: uniform sampler should occupy 1 location

2014-08-22 Thread Micael

Is this because of the 64 bit handles? If so, I think I agree with you.
According to the ARB_bindless_texture spec changes:
When used as shader inputs, outputs, uniform block members, or
temporaries, the value of the sampler is a 64-bit unsigned integer handle
and never refers to a texture image unit.

However, should we consume 2 locs only if ARB_bindless_texture is present,
or always?


On Fri, Aug 22, 2014 at 8:36 AM, Dave Airlie airl...@gmail.com wrote:

 In the future for ARB_bindless_texture we might want this to be 2, I'm
 not sure if we should just do that now.

 Dave.

 On 22 August 2014 09:25, Micael Dias kam1k...@gmail.com wrote:
  ---
  If samplers occupy zero locations we can run into a lot of issues. See
 #82921.
  I briefly tested this with my own code (which was previously crashing and
  misbehaving) and also ran other apps and everything seems to work fine.
  I'm not used to contributing code in this fashion, so please forgive me
 if I'm
  making some mistake. Thanks.
 
   src/glsl/glsl_types.cpp | 2 ++
   1 file changed, 2 insertions(+)
 
  diff --git a/src/glsl/glsl_types.cpp b/src/glsl/glsl_types.cpp
  index 66e9b13..cc05193 100644
  --- a/src/glsl/glsl_types.cpp
  +++ b/src/glsl/glsl_types.cpp
  @@ -691,6 +691,8 @@ glsl_type::uniform_locations() const
 return size;
  case GLSL_TYPE_ARRAY:
 return this-length * this-fields.array-uniform_locations();
  +   case GLSL_TYPE_SAMPLER:
  +  return 1;
  default:
 break;
  }
  --
  2.1.0
 
  ___
  mesa-dev mailing list
  mesa-dev@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/mesa-dev




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

[Mesa-dev] [Bug 82946] Build failure while linking libMesaOpenCL.la with any Mesa release = 10.2: undefined references to .LLST7{1, 5, 9}

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

--- Comment #2 from Giovanni Mariani mc2...@mclink.it ---
(In reply to comment #1)
 Seems like a compiler bug to me.  Your debug section-related CXXFLAGS
 (-Wa,--compress-debug-sections -gdwarf-4) probably have an influence, try
 removing them, or upgrade to a more recent version of GCC (works for me with
 the same compiler flags on GCC v4.9.1).
 
 Thanks.
Removing the above part of CXXFLAGS gives me the same result as the old one...
I will look for a gcc upgrade (the nearly done Rosa 2014.1 will have gcc 4.9.1,
so perhaps I will wait for it).

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

Re: [Mesa-dev] [RFC PATCH 00/16] A new IR for Mesa

2014-08-22 Thread Connor Abbott

On Thu, Aug 21, 2014 at 11:08 PM, Dave Airlie airl...@gmail.com wrote:
 On 22 August 2014 12:46, Jason Ekstrand ja...@jlekstrand.net wrote:
 On Thu, Aug 21, 2014 at 7:36 PM, Dave Airlie airl...@gmail.com wrote:

 On 21 August 2014 19:10, Henri Verbeet hverb...@gmail.com wrote:
  On 21 August 2014 04:56, Michel Dänzer mic...@daenzer.net wrote:
  On 21.08.2014 04:29, Henri Verbeet wrote:
  For whatever it's worth, I have been avoiding radeonsi in part because
  of the LLVM dependency. Some of the other issues already mentioned
  aside, I also think it makes it just painful to do bisects over
  moderate/longer periods of time.
 
  More painful, sure, but not too bad IME. In particular, if you know the
  regression is in Mesa, you can always use a stable release of LLVM for
  the bisect. You only need to change the --with-llvm-prefix= parameter
  to
  Mesa's configure for that. Of course, it could still be mildly painful
  if you need to go so far back that the current stable LLVM release
  wasn't supported yet. But how often does that happen? Very rarely for
  me.
 
  Sure, it's not impossible, but is that really the kind of process you
  want users to go through when bisecting a regression? Perhaps throw in
  building 32-bit versions of both Mesa and LLVM on 64-bit as well if
  they want to run 32-bit applications.
 
  Without LLVM, I'm not sure there would be a driver you could avoid. :)
 
  R600g didn't really exist either, and that one seems to have worked
  out fine. I think in a large part because of work done by Jerome and
  Dave in the early days, but regardless. From what I've seen from SI, I
  don't think radeonsi needed to be a separate driver to start with, and
  while its ISA is certainly different from R600-Cayman, it doesn't
  particularly strike me as much harder to work with.
 
  Back to the more immediate topic though, I think think that on
  occasion the discussion is framed as Is there any reason using LLVM
  IR wouldn't work?, while it would perhaps be more appropriate to
  think of as Would using LLVM IR provide enough advantages to justify
  adding a LLVM dependency to core Mesa?.

 Could we use an llvm compatible IR? is also a question I'd like to see
 answered.


 What do you mean by llvm compatible?  Do you mean forking their IR inside
 mesa or just something that's easy to translate back and forth?


 Importing/forking the llvm IR code with a different symbol set, and
 trying to not intentionally
 be incompatible with their llvm.

That sounds like a huge amount of work, possibly even more work than
going it on our own because the LLVM project moves really quickly and
we'd have to import all of the changes. Also, it seems pretty ugly and
I'm sure distro maintainers would just looove a solution like that
/s. Just look at the situation with Chromium and Fedora now (or at
least last I checked).

Connor


 Dave.
 ___
 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] [RFC PATCH 00/16] A new IR for Mesa

2014-08-22 Thread Christian König


Am 22.08.2014 um 17:13 schrieb Connor Abbott:

On Thu, Aug 21, 2014 at 11:08 PM, Dave Airlie airl...@gmail.com wrote:

On 22 August 2014 12:46, Jason Ekstrand ja...@jlekstrand.net wrote:

On Thu, Aug 21, 2014 at 7:36 PM, Dave Airlie airl...@gmail.com wrote:

On 21 August 2014 19:10, Henri Verbeet hverb...@gmail.com wrote:

On 21 August 2014 04:56, Michel Dänzer mic...@daenzer.net wrote:

On 21.08.2014 04:29, Henri Verbeet wrote:

For whatever it's worth, I have been avoiding radeonsi in part because
of the LLVM dependency. Some of the other issues already mentioned
aside, I also think it makes it just painful to do bisects over
moderate/longer periods of time.

More painful, sure, but not too bad IME. In particular, if you know the
regression is in Mesa, you can always use a stable release of LLVM for
the bisect. You only need to change the --with-llvm-prefix= parameter
to
Mesa's configure for that. Of course, it could still be mildly painful
if you need to go so far back that the current stable LLVM release
wasn't supported yet. But how often does that happen? Very rarely for
me.


Sure, it's not impossible, but is that really the kind of process you
want users to go through when bisecting a regression? Perhaps throw in
building 32-bit versions of both Mesa and LLVM on 64-bit as well if
they want to run 32-bit applications.


Without LLVM, I'm not sure there would be a driver you could avoid. :)


R600g didn't really exist either, and that one seems to have worked
out fine. I think in a large part because of work done by Jerome and
Dave in the early days, but regardless. From what I've seen from SI, I
don't think radeonsi needed to be a separate driver to start with, and
while its ISA is certainly different from R600-Cayman, it doesn't
particularly strike me as much harder to work with.

Back to the more immediate topic though, I think think that on
occasion the discussion is framed as Is there any reason using LLVM
IR wouldn't work?, while it would perhaps be more appropriate to
think of as Would using LLVM IR provide enough advantages to justify
adding a LLVM dependency to core Mesa?.

Could we use an llvm compatible IR? is also a question I'd like to see
answered.


What do you mean by llvm compatible?  Do you mean forking their IR inside
mesa or just something that's easy to translate back and forth?


Importing/forking the llvm IR code with a different symbol set, and
trying to not intentionally
be incompatible with their llvm.

That sounds like a huge amount of work, possibly even more work than
going it on our own because the LLVM project moves really quickly and
we'd have to import all of the changes. Also, it seems pretty ugly and
I'm sure distro maintainers would just looove a solution like that
/s. Just look at the situation with Chromium and Fedora now (or at
least last I checked).


Actually the LLVM IR is considered stable and as Dave explained we 
wouldn't depend on LLVM, but rather just use the same concept for the IR.


This actually sounds like a pretty good idea to me. And I would say we 
should just continue moving the GLSL IR towards SSA and all the 
specialized GL opcodes into something similar to LLVM intrinsics.


Christian.



Connor


Dave.
___
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] [RFC PATCH 00/16] A new IR for Mesa

2014-08-22 Thread Connor Abbott

On Fri, Aug 22, 2014 at 11:27 AM, Christian König
deathsim...@vodafone.de wrote:
 Am 22.08.2014 um 17:13 schrieb Connor Abbott:

 On Thu, Aug 21, 2014 at 11:08 PM, Dave Airlie airl...@gmail.com wrote:

 On 22 August 2014 12:46, Jason Ekstrand ja...@jlekstrand.net wrote:

 On Thu, Aug 21, 2014 at 7:36 PM, Dave Airlie airl...@gmail.com wrote:

 On 21 August 2014 19:10, Henri Verbeet hverb...@gmail.com wrote:

 On 21 August 2014 04:56, Michel Dänzer mic...@daenzer.net wrote:

 On 21.08.2014 04:29, Henri Verbeet wrote:

 For whatever it's worth, I have been avoiding radeonsi in part
 because
 of the LLVM dependency. Some of the other issues already mentioned
 aside, I also think it makes it just painful to do bisects over
 moderate/longer periods of time.

 More painful, sure, but not too bad IME. In particular, if you know
 the
 regression is in Mesa, you can always use a stable release of LLVM
 for
 the bisect. You only need to change the --with-llvm-prefix= parameter
 to
 Mesa's configure for that. Of course, it could still be mildly
 painful
 if you need to go so far back that the current stable LLVM release
 wasn't supported yet. But how often does that happen? Very rarely for
 me.

 Sure, it's not impossible, but is that really the kind of process you
 want users to go through when bisecting a regression? Perhaps throw in
 building 32-bit versions of both Mesa and LLVM on 64-bit as well if
 they want to run 32-bit applications.

 Without LLVM, I'm not sure there would be a driver you could avoid.
 :)

 R600g didn't really exist either, and that one seems to have worked
 out fine. I think in a large part because of work done by Jerome and
 Dave in the early days, but regardless. From what I've seen from SI, I
 don't think radeonsi needed to be a separate driver to start with, and
 while its ISA is certainly different from R600-Cayman, it doesn't
 particularly strike me as much harder to work with.

 Back to the more immediate topic though, I think think that on
 occasion the discussion is framed as Is there any reason using LLVM
 IR wouldn't work?, while it would perhaps be more appropriate to
 think of as Would using LLVM IR provide enough advantages to justify
 adding a LLVM dependency to core Mesa?.

 Could we use an llvm compatible IR? is also a question I'd like to see
 answered.


 What do you mean by llvm compatible?  Do you mean forking their IR
 inside
 mesa or just something that's easy to translate back and forth?

 Importing/forking the llvm IR code with a different symbol set, and
 trying to not intentionally
 be incompatible with their llvm.

 That sounds like a huge amount of work, possibly even more work than
 going it on our own because the LLVM project moves really quickly and
 we'd have to import all of the changes. Also, it seems pretty ugly and
 I'm sure distro maintainers would just looove a solution like that
 /s. Just look at the situation with Chromium and Fedora now (or at
 least last I checked).


 Actually the LLVM IR is considered stable and as Dave explained we wouldn't
 depend on LLVM, but rather just use the same concept for the IR.

Except the optimization passes aren't, and those are what we would
actually use the IR for...


 This actually sounds like a pretty good idea to me. And I would say we
 should just continue moving the GLSL IR towards SSA and all the specialized
 GL opcodes into something similar to LLVM intrinsics.

So, in other words, using NIR ;) NIR already has intrinsics, and while
it does have some extra things (swizzles, writemasks, modifiers) those
are only there to make things a little easier on the drivers that want
to use them and absolutely aren't necessary. As of now, we already
don't care about writemasks in the optimization passes because they
don't matter with SSA, and we can avoid caring about the others as
well if it makes optimizations easier.

Connor


 Christian.



 Connor

 Dave.
 ___
 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] [RFC PATCH 00/16] A new IR for Mesa

2014-08-22 Thread Connor Abbott

On Fri, Aug 22, 2014 at 11:27 AM, Christian König
deathsim...@vodafone.de wrote:
 Am 22.08.2014 um 17:13 schrieb Connor Abbott:

 On Thu, Aug 21, 2014 at 11:08 PM, Dave Airlie airl...@gmail.com wrote:

 On 22 August 2014 12:46, Jason Ekstrand ja...@jlekstrand.net wrote:

 On Thu, Aug 21, 2014 at 7:36 PM, Dave Airlie airl...@gmail.com wrote:

 On 21 August 2014 19:10, Henri Verbeet hverb...@gmail.com wrote:

 On 21 August 2014 04:56, Michel Dänzer mic...@daenzer.net wrote:

 On 21.08.2014 04:29, Henri Verbeet wrote:

 For whatever it's worth, I have been avoiding radeonsi in part
 because
 of the LLVM dependency. Some of the other issues already mentioned
 aside, I also think it makes it just painful to do bisects over
 moderate/longer periods of time.

 More painful, sure, but not too bad IME. In particular, if you know
 the
 regression is in Mesa, you can always use a stable release of LLVM
 for
 the bisect. You only need to change the --with-llvm-prefix= parameter
 to
 Mesa's configure for that. Of course, it could still be mildly
 painful
 if you need to go so far back that the current stable LLVM release
 wasn't supported yet. But how often does that happen? Very rarely for
 me.

 Sure, it's not impossible, but is that really the kind of process you
 want users to go through when bisecting a regression? Perhaps throw in
 building 32-bit versions of both Mesa and LLVM on 64-bit as well if
 they want to run 32-bit applications.

 Without LLVM, I'm not sure there would be a driver you could avoid.
 :)

 R600g didn't really exist either, and that one seems to have worked
 out fine. I think in a large part because of work done by Jerome and
 Dave in the early days, but regardless. From what I've seen from SI, I
 don't think radeonsi needed to be a separate driver to start with, and
 while its ISA is certainly different from R600-Cayman, it doesn't
 particularly strike me as much harder to work with.

 Back to the more immediate topic though, I think think that on
 occasion the discussion is framed as Is there any reason using LLVM
 IR wouldn't work?, while it would perhaps be more appropriate to
 think of as Would using LLVM IR provide enough advantages to justify
 adding a LLVM dependency to core Mesa?.

 Could we use an llvm compatible IR? is also a question I'd like to see
 answered.


 What do you mean by llvm compatible?  Do you mean forking their IR
 inside
 mesa or just something that's easy to translate back and forth?

 Importing/forking the llvm IR code with a different symbol set, and
 trying to not intentionally
 be incompatible with their llvm.

 That sounds like a huge amount of work, possibly even more work than
 going it on our own because the LLVM project moves really quickly and
 we'd have to import all of the changes. Also, it seems pretty ugly and
 I'm sure distro maintainers would just looove a solution like that
 /s. Just look at the situation with Chromium and Fedora now (or at
 least last I checked).


 Actually the LLVM IR is considered stable and as Dave explained we wouldn't
 depend on LLVM, but rather just use the same concept for the IR.

 This actually sounds like a pretty good idea to me. And I would say we
 should just continue moving the GLSL IR towards SSA and all the specialized
 GL opcodes into something similar to LLVM intrinsics.

And, coming from the guy who's done the the existing moving GLSL IR
towards SSA, it just sucks. It's not worth it. That was one of the
main reasons I started on NIR, besides knowing that the Intel people
were against adding a dependency to LLVM to their driver.


 Christian.



 Connor

 Dave.
 ___
 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] [RFC PATCH 00/16] A new IR for Mesa

2014-08-22 Thread Tom Stellard

On Sat, Aug 23, 2014 at 12:17:00AM +1000, Dave Airlie wrote:
 On 23 August 2014 00:15, Tom Stellard t...@stellard.net wrote:
  On Fri, Aug 22, 2014 at 01:08:02PM +1000, Dave Airlie wrote:
  On 22 August 2014 12:46, Jason Ekstrand ja...@jlekstrand.net wrote:
   On Thu, Aug 21, 2014 at 7:36 PM, Dave Airlie airl...@gmail.com wrote:
  
   On 21 August 2014 19:10, Henri Verbeet hverb...@gmail.com wrote:
On 21 August 2014 04:56, Michel Dänzer mic...@daenzer.net wrote:
On 21.08.2014 04:29, Henri Verbeet wrote:
For whatever it's worth, I have been avoiding radeonsi in part 
because
of the LLVM dependency. Some of the other issues already mentioned
aside, I also think it makes it just painful to do bisects over
moderate/longer periods of time.
   
More painful, sure, but not too bad IME. In particular, if you know 
the
regression is in Mesa, you can always use a stable release of LLVM 
for
the bisect. You only need to change the --with-llvm-prefix= parameter
to
Mesa's configure for that. Of course, it could still be mildly 
painful
if you need to go so far back that the current stable LLVM release
wasn't supported yet. But how often does that happen? Very rarely for
me.
   
Sure, it's not impossible, but is that really the kind of process you
want users to go through when bisecting a regression? Perhaps throw in
building 32-bit versions of both Mesa and LLVM on 64-bit as well if
they want to run 32-bit applications.
   
Without LLVM, I'm not sure there would be a driver you could avoid. 
:)
   
R600g didn't really exist either, and that one seems to have worked
out fine. I think in a large part because of work done by Jerome and
Dave in the early days, but regardless. From what I've seen from SI, I
don't think radeonsi needed to be a separate driver to start with, and
while its ISA is certainly different from R600-Cayman, it doesn't
particularly strike me as much harder to work with.
   
Back to the more immediate topic though, I think think that on
occasion the discussion is framed as Is there any reason using LLVM
IR wouldn't work?, while it would perhaps be more appropriate to
think of as Would using LLVM IR provide enough advantages to justify
adding a LLVM dependency to core Mesa?.
  
   Could we use an llvm compatible IR? is also a question I'd like to see
   answered.
  
  
   What do you mean by llvm compatible?  Do you mean forking their IR inside
   mesa or just something that's easy to translate back and forth?
  
 
  Importing/forking the llvm IR code with a different symbol set, and
  trying to not intentionally
  be incompatible with their llvm.
 
 
  What would be the purpose of doing this?  Avoiding a dependency on the LLVM 
  libraries?
 
 Spltting the problem of using llvm IR from the problem of linking with
 llvm, since people
 appear to be conflating them.
 
 So yes avoid the direct dep for now.
 

The main advantage of using LLVM IR is having access to all the
functionality provided by the libraries, so while it would be possible
to use the IR without the library, it would be a lot of work with no
benefit.

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

[Mesa-dev] [PATCH] kms-swrast: Support Prime fd handling

Allows using prime fds as display target and from display target.
Test for PRIME capability after initializing kms_swrast screen.

Signed-off-by: Andreas Pokorny andreas.poko...@canonical.com
---
 src/gallium/state_trackers/dri/dri2.c |  8 +++
 src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c | 80 ---
 2 files changed, 78 insertions(+), 10 deletions(-)

diff --git a/src/gallium/state_trackers/dri/dri2.c 
b/src/gallium/state_trackers/dri/dri2.c
index a63448d..82f8a47 100644
--- a/src/gallium/state_trackers/dri/dri2.c
+++ b/src/gallium/state_trackers/dri/dri2.c
@@ -1333,6 +1333,7 @@ dri_kms_init_screen(__DRIscreen * sPriv)
const __DRIconfig **configs;
struct dri_screen *screen;
struct pipe_screen *pscreen = NULL;
+   uint64_t cap;
 
screen = CALLOC_STRUCT(dri_screen);
if (!screen)
@@ -1344,6 +1345,13 @@ dri_kms_init_screen(__DRIscreen * sPriv)
sPriv-driverPrivate = (void *)screen;
 
pscreen = kms_swrast_create_screen(screen-fd);
+
+   if (drmGetCap(sPriv-fd, DRM_CAP_PRIME, cap) == 0 
+  (cap  DRM_PRIME_CAP_IMPORT)) {
+  dri2ImageExtension.createImageFromFds = dri2_from_fds;
+  dri2ImageExtension.createImageFromDmaBufs = dri2_from_dma_bufs;
+   }
+
sPriv-extensions = dri_screen_extensions;
 
/* dri_init_screen_helper checks pscreen for us */
diff --git a/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c 
b/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
index c9934bb..ba0660c 100644
--- a/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
+++ b/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
@@ -38,6 +38,7 @@
 #include sys/mman.h
 #include unistd.h
 #include dlfcn.h
+#include fcntl.h
 #include xf86drm.h
 
 #include pipe/p_compiler.h
@@ -210,6 +211,38 @@ kms_sw_displaytarget_map(struct sw_winsys *ws,
return kms_sw_dt-mapped;
 }
 
+static struct kms_sw_displaytarget *
+kms_sw_displaytarget_add_from_prime(struct kms_sw_winsys *kms_sw, int fd)
+{
+   uint32_t handle = -1;
+   struct kms_sw_displaytarget * kms_sw_dt;
+   int ret;
+
+   ret = drmPrimeFDToHandle(kms_sw-fd, fd, handle);
+
+   if (ret)
+  return NULL;
+
+   kms_sw_dt = CALLOC_STRUCT(kms_sw_displaytarget);
+   if (!kms_sw_dt)
+  return NULL;
+
+   kms_sw_dt-ref_count = 1;
+   kms_sw_dt-handle = handle;
+   kms_sw_dt-size = lseek(fd, 0, SEEK_END);
+
+   if (kms_sw_dt-size == (off_t)-1) {
+  FREE(kms_sw_dt);
+  return NULL;
+   }
+
+   lseek(fd, 0, SEEK_SET);
+
+   list_add(kms_sw_dt-link, kms_sw-bo_list);
+
+   return kms_sw_dt;
+}
+
 static void
 kms_sw_displaytarget_unmap(struct sw_winsys *ws,
struct sw_displaytarget *dt)
@@ -231,17 +264,34 @@ kms_sw_displaytarget_from_handle(struct sw_winsys *ws,
struct kms_sw_winsys *kms_sw = kms_sw_winsys(ws);
struct kms_sw_displaytarget *kms_sw_dt;
 
-   assert(whandle-type == DRM_API_HANDLE_TYPE_KMS);
+   assert(whandle-type == DRM_API_HANDLE_TYPE_KMS ||
+  whandle-type == DRM_API_HANDLE_TYPE_FD);
 
-   LIST_FOR_EACH_ENTRY(kms_sw_dt, kms_sw-bo_list, link) {
-  if (kms_sw_dt-handle == whandle-handle) {
+   switch(whandle-type) {
+   case DRM_API_HANDLE_TYPE_FD:
+  kms_sw_dt = kms_sw_displaytarget_add_from_prime(kms_sw, whandle-handle);
+  if (kms_sw_dt) {
  kms_sw_dt-ref_count++;
+ kms_sw_dt-width = templ-width0;
+ kms_sw_dt-height = templ-height0;
+ kms_sw_dt-stride = whandle-stride;
+ if (stride)
+*stride = kms_sw_dt-stride;
+  }
+  return (struct sw_displaytarget *)kms_sw_dt;
+   case DRM_API_HANDLE_TYPE_KMS:
+  LIST_FOR_EACH_ENTRY(kms_sw_dt, kms_sw-bo_list, link) {
+ if (kms_sw_dt-handle == whandle-handle) {
+kms_sw_dt-ref_count++;
 
- DEBUG(KMS-DEBUG: imported buffer %u (size %u)\n, kms_sw_dt-handle, 
kms_sw_dt-size);
+DEBUG(KMS-DEBUG: imported buffer %u (size %u)\n, 
kms_sw_dt-handle, kms_sw_dt-size);
 
- *stride = kms_sw_dt-stride;
- return (struct sw_displaytarget *)kms_sw_dt;
+*stride = kms_sw_dt-stride;
+return (struct sw_displaytarget *)kms_sw_dt;
+ }
   }
+   default:
+   break;
}
 
assert(0);
@@ -253,16 +303,26 @@ kms_sw_displaytarget_get_handle(struct sw_winsys *winsys,
 struct sw_displaytarget *dt,
 struct winsys_handle *whandle)
 {
+   struct kms_sw_winsys *kms_sw = kms_sw_winsys(winsys);
struct kms_sw_displaytarget *kms_sw_dt = kms_sw_displaytarget(dt);
 
-   if (whandle-type == DRM_API_HANDLE_TYPE_KMS) {
+   switch(whandle-type) {
+   case DRM_API_HANDLE_TYPE_KMS:
   whandle-handle = kms_sw_dt-handle;
   whandle-stride = kms_sw_dt-stride;
-   } else {
+  return TRUE;
+   case DRM_API_HANDLE_TYPE_FD:
+  if (!drmPrimeHandleToFD(kms_sw-fd, kms_sw_dt-handle,
+ DRM_CLOEXEC, whandle-handle)) {
+ whandle-stride = kms_sw_dt-stride;
+ return TRUE;
+  }

[Mesa-dev] [PATCH] kms-swrast: Support Prime fd handling v3

Hi, 
This should be the final version. Not sure why I even messed with guessing the 
stride value. 

regards
Andreas Pokorny

Andreas Pokorny (1):
  kms-swrast: Support Prime fd handling

 src/gallium/state_trackers/dri/dri2.c |  8 +++
 src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c | 80 ---
 2 files changed, 78 insertions(+), 10 deletions(-)

-- 
2.1.0.rc1

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

Re: [Mesa-dev] [PATCH] i965: Fix JIP/UIP calculations.

2014-08-22 Thread Kenneth Graunke

On Thursday, August 21, 2014 11:10:26 PM Matt Turner wrote:
 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82846
 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82929
 ---
 Planning to commit this to master as well as to 10.3 directly,
 since BDW is just broken without it.
 
  src/mesa/drivers/dri/i965/brw_eu_compact.c | 14 ++
  1 file changed, 6 insertions(+), 8 deletions(-)
 
 diff --git a/src/mesa/drivers/dri/i965/brw_eu_compact.c 
 b/src/mesa/drivers/dri/i965/brw_eu_compact.c
 index 3680c55..4f509dd 100644
 --- a/src/mesa/drivers/dri/i965/brw_eu_compact.c
 +++ b/src/mesa/drivers/dri/i965/brw_eu_compact.c
 @@ -1029,19 +1029,17 @@ update_uip_jip(struct brw_context *brw, brw_inst 
 *insn,
  {
 int scale = brw-gen = 8 ? sizeof(brw_compact_inst) : 1;
  
 -   int32_t jip = brw_inst_jip(brw, insn);
 -   jip -= scale *
 -  compacted_between(this_old_ip, this_old_ip + jip, compacted_counts);
 -   brw_inst_set_jip(brw, insn, jip);
 +   int32_t jip = brw_inst_jip(brw, insn) / scale;
 +   jip -= compacted_between(this_old_ip, this_old_ip + jip, 
 compacted_counts);
 +   brw_inst_set_jip(brw, insn, jip * scale);
  
 if (brw_inst_opcode(brw, insn) == BRW_OPCODE_ENDIF ||
 brw_inst_opcode(brw, insn) == BRW_OPCODE_WHILE)
return;
  
 -   int32_t uip = brw_inst_uip(brw, insn);
 -   uip -= scale *
 -  compacted_between(this_old_ip, this_old_ip + uip, compacted_counts);
 -   brw_inst_set_uip(brw, insn, uip);
 +   int32_t uip = brw_inst_uip(brw, insn) / scale;
 +   uip -= compacted_between(this_old_ip, this_old_ip + uip, 
 compacted_counts);
 +   brw_inst_set_uip(brw, insn, uip * scale);
  }
  
  void
 

Seems okay to me.
Reviewed-by: Kenneth Graunke kenn...@whitecape.org

signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965: First step toward prelocation

2014-08-22 Thread Ben Widawsky

On Fri, Aug 22, 2014 at 08:15:28AM -0400, Alex Deucher wrote:
 On Thu, Aug 21, 2014 at 11:12 PM, Ben Widawsky
 benjamin.widaw...@intel.com wrote:
  This was a quick proof of concept to show the new API for prelocating
  buffers.
 
 
 What are prelocated buffers?

http://lists.freedesktop.org/archives/mesa-dev/2014-August/066432.html

 
 Alex
 
  It needs way more testing, to not ifdef the no-relocs, and to do a
  libdrm ABI dep bump.
  ---
   src/mesa/drivers/dri/i965/Makefile.am   | 1 +
   src/mesa/drivers/dri/i965/brw_performance_monitor.c | 6 +++---
   src/mesa/drivers/dri/i965/brw_program.c | 5 +++--
   src/mesa/drivers/dri/i965/brw_queryobj.c| 6 +++---
   src/mesa/drivers/dri/i965/brw_state_cache.c | 4 ++--
   src/mesa/drivers/dri/i965/intel_batchbuffer.c   | 3 +++
   src/mesa/drivers/dri/i965/intel_batchbuffer.h   | 8 
   7 files changed, 23 insertions(+), 10 deletions(-)
 
  diff --git a/src/mesa/drivers/dri/i965/Makefile.am 
  b/src/mesa/drivers/dri/i965/Makefile.am
  index 5809dc6..4b20d36 100644
  --- a/src/mesa/drivers/dri/i965/Makefile.am
  +++ b/src/mesa/drivers/dri/i965/Makefile.am
  @@ -24,6 +24,7 @@
   include Makefile.sources
 
   AM_CFLAGS = \
  +-DNO_RELOC \
  -I$(top_srcdir)/include \
  -I$(top_srcdir)/src/ \
  -I$(top_srcdir)/src/mapi \
  diff --git a/src/mesa/drivers/dri/i965/brw_performance_monitor.c 
  b/src/mesa/drivers/dri/i965/brw_performance_monitor.c
  index edfa3d2..e30c527 100644
  --- a/src/mesa/drivers/dri/i965/brw_performance_monitor.c
  +++ b/src/mesa/drivers/dri/i965/brw_performance_monitor.c
  @@ -1105,13 +1105,13 @@ brw_begin_perf_monitor(struct gl_context *ctx,
  * wasting memory for contexts that don't use performance monitors.
  */
 if (!brw-perfmon.bookend_bo) {
  - brw-perfmon.bookend_bo = drm_intel_bo_alloc(brw-bufmgr,
  + brw-perfmon.bookend_bo = drm_intel_bo_alloc_wrapper(brw-bufmgr,
 OA bookend BO,
 
  BOOKEND_BO_SIZE_BYTES, 64);
 }
 
 monitor-oa_bo =
  - drm_intel_bo_alloc(brw-bufmgr, perf. monitor OA bo, 4096, 64);
  + drm_intel_bo_alloc_wrapper(brw-bufmgr, perf. monitor OA bo, 
  4096, 64);
   #ifdef DEBUG
 /* Pre-filling the BO helps debug whether writes landed. */
 drm_intel_bo_map(monitor-oa_bo, true);
  @@ -1146,7 +1146,7 @@ brw_begin_perf_monitor(struct gl_context *ctx,
 
  if (monitor_needs_statistics_registers(brw, m)) {
 monitor-pipeline_stats_bo =
  - drm_intel_bo_alloc(brw-bufmgr, perf. monitor stats bo, 4096, 
  64);
  + drm_intel_bo_alloc_wrapper(brw-bufmgr, perf. monitor stats bo, 
  4096, 64);
 
 /* Take starting snapshots. */
 snapshot_statistics_registers(brw, monitor, 0);
  diff --git a/src/mesa/drivers/dri/i965/brw_program.c 
  b/src/mesa/drivers/dri/i965/brw_program.c
  index d782b4f..74ff40c 100644
  --- a/src/mesa/drivers/dri/i965/brw_program.c
  +++ b/src/mesa/drivers/dri/i965/brw_program.c
  @@ -43,6 +43,7 @@
 
   #include brw_context.h
   #include brw_wm.h
  +#include intel_batchbuffer.h
 
   static unsigned
   get_new_program_id(struct intel_screen *screen)
  @@ -242,7 +243,7 @@ brw_get_scratch_bo(struct brw_context *brw,
  }
 
  if (!old_bo) {
  -  *scratch_bo = drm_intel_bo_alloc(brw-bufmgr, scratch bo, size, 
  4096);
  +  *scratch_bo = drm_intel_bo_alloc_wrapper(brw-bufmgr, scratch bo, 
  size, 4096);
  }
   }
 
  @@ -265,7 +266,7 @@ void
   brw_init_shader_time(struct brw_context *brw)
   {
  const int max_entries = 4096;
  -   brw-shader_time.bo = drm_intel_bo_alloc(brw-bufmgr, shader time,
  +   brw-shader_time.bo = drm_intel_bo_alloc_wrapper(brw-bufmgr, shader 
  time,
   max_entries * 
  SHADER_TIME_STRIDE,
   4096);
  brw-shader_time.shader_programs = rzalloc_array(brw, struct 
  gl_shader_program *,
  diff --git a/src/mesa/drivers/dri/i965/brw_queryobj.c 
  b/src/mesa/drivers/dri/i965/brw_queryobj.c
  index c053c34..cf5a2a5 100644
  --- a/src/mesa/drivers/dri/i965/brw_queryobj.c
  +++ b/src/mesa/drivers/dri/i965/brw_queryobj.c
  @@ -230,7 +230,7 @@ brw_begin_query(struct gl_context *ctx, struct 
  gl_query_object *q)
  * the system was doing other work, such as running other 
  applications.
  */
 drm_intel_bo_unreference(query-bo);
  -  query-bo = drm_intel_bo_alloc(brw-bufmgr, timer query, 4096, 
  4096);
  +  query-bo = drm_intel_bo_alloc_wrapper(brw-bufmgr, timer query, 
  4096, 4096);
 brw_write_timestamp(brw, query-bo, 0);
 break;
 
  @@ -388,7 +388,7 @@ ensure_bo_has_space(struct gl_context *ctx, struct 
  brw_query_object *query)
brw_queryobj_get_results(ctx, query);
 }
 
  -  query-bo =

[Mesa-dev] [Bug 82946] Build failure while linking libMesaOpenCL.la with any Mesa release = 10.2: undefined references to .LLST7{1, 5, 9}

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

Giovanni Mariani mc2...@mclink.it changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTOURBUG

--- Comment #3 from Giovanni Mariani mc2...@mclink.it ---
OK. I tried another time and indeed I can confirm that removing the -gdwarf-4
from CXXFLAGS fixes the build with gcc 4.7.4 (perhaps the first time I did not
massage CXXFLAGS correctly).
Hence not a bug in Mesa: closing.

-- 
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] [PATCH] i965: Handle ir_triop_csel in emit_bool_to_cond_code().

2014-08-22 Thread Kenneth Graunke

ir_triop_csel can return a boolean expression, so we need to handle it
here; we simply forgot when we added it.

Fixes Piglit's EXT_shader_integer_mix/{vs,fs}-mix-if-bool.

Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
 src/mesa/drivers/dri/i965/brw_fs_visitor.cpp   | 20 ++--
 src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 20 ++--
 2 files changed, 36 insertions(+), 4 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index f2c22bb..700115c 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -2246,10 +2246,10 @@ fs_visitor::emit_bool_to_cond_code(ir_rvalue *ir)
   return;
}
 
-   fs_reg op[2];
+   fs_reg op[3];
fs_inst *inst;
 
-   assert(expr-get_num_operands() = 2);
+   assert(expr-get_num_operands() = 3);
for (unsigned int i = 0; i  expr-get_num_operands(); i++) {
   assert(expr-operands[i]-type-is_scalar());
 
@@ -2336,6 +2336,22 @@ fs_visitor::emit_bool_to_cond_code(ir_rvalue *ir)
brw_conditional_for_comparison(expr-operation)));
   break;
 
+   case ir_triop_csel: {
+  /* Expand the boolean condition into the flag register. */
+  inst = emit(MOV(reg_null_d, op[0]));
+  inst-conditional_mod = BRW_CONDITIONAL_NZ;
+
+  /* Select which boolean to return. */
+  fs_reg temp(this, expr-operands[1]-type);
+  inst = emit(SEL(temp, op[1], op[2]));
+  inst-predicate = BRW_PREDICATE_NORMAL;
+
+  /* Expand the result to a condition code. */
+  inst = emit(MOV(reg_null_d, temp));
+  inst-conditional_mod = BRW_CONDITIONAL_NZ;
+  break;
+   }
+
default:
   unreachable(not reached);
}
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
index 6e48be7..4dcedfe 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
@@ -777,10 +777,10 @@ vec4_visitor::emit_bool_to_cond_code(ir_rvalue *ir,
*predicate = BRW_PREDICATE_NORMAL;
 
if (expr) {
-  src_reg op[2];
+  src_reg op[3];
   vec4_instruction *inst;
 
-  assert(expr-get_num_operands() = 2);
+  assert(expr-get_num_operands() = 3);
   for (unsigned int i = 0; i  expr-get_num_operands(); i++) {
 expr-operands[i]-accept(this);
 op[i] = this-result;
@@ -852,6 +852,22 @@ vec4_visitor::emit_bool_to_cond_code(ir_rvalue *ir,
  brw_conditional_for_comparison(expr-operation)));
 break;
 
+  case ir_triop_csel: {
+ /* Expand the boolean condition into the flag register. */
+ inst = emit(MOV(dst_null_d(), op[0]));
+ inst-conditional_mod = BRW_CONDITIONAL_NZ;
+
+ /* Select which boolean to return. */
+ dst_reg temp(this, expr-operands[1]-type);
+ inst = emit(BRW_OPCODE_SEL, temp, op[1], op[2]);
+ inst-predicate = BRW_PREDICATE_NORMAL;
+
+ /* Expand the result to a condition code. */
+ inst = emit(MOV(dst_null_d(), src_reg(temp)));
+ inst-conditional_mod = BRW_CONDITIONAL_NZ;
+ break;
+  }
+
   default:
 unreachable(not reached);
   }
-- 
2.0.2

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

Re: [Mesa-dev] [Intel-gfx] [PATCH 00/68] Broadwell 48b addressing and prelocations (no relocs)

2014-08-22 Thread Daniel Vetter

On Fri, Aug 22, 2014 at 3:38 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
 On Fri, Aug 22, 2014 at 03:30:12PM +0200, Daniel Vetter wrote:
 On Fri, Aug 22, 2014 at 9:03 AM, Chris Wilson ch...@chris-wilson.co.uk 
 wrote:
If a GPU
client uses only prelocations, the relocation process can be entirely
skipped. This sounds like a big win initially,
  
   Close to zero if the client uses existing interfaces.
   -Chris
 
  Chris,
 
  I don't know if you've seen Ben's libdrm and Mesa patches, but with a few 
  patches to libdrm and virtually zero Mesa changes, he's apparently 
  eliminated our need to do any relocations for the 3D driver.  It wasn't 
  invasive at all---I was surprised.
 
  Indeed, you could do everything inside libdrm with the code I posted 2
  years ago.

 I915_EXEC_NO_RELOC can be used to tell the kernel that it doesn't need
 to walk all the reloc tables (if nothing moved) because userspace
 didn't go insane and reuse reloc trees. So you'd need to implement a
 flag + a libdrm function to set that (iirc mesa has been non-stupid
 since years). And yeah I kinda expect any new reloc-less thing to get
 benchmarked against an implementation using that, since the 48bit
 specific thing proposed looks like a fairly short-lived stop-gap, and
 since the current no-reloc we already have would work everywhere. And
 yeah I've been poking people to look at this for years. too.

 Here, I was referring to soft-pinning. The API here is essentially
 comprised of two parts:

 1: a pin into the vm upon creation
 2: implicit no-relocation upon execbuffer

 By making those two steps independent, the API as I see is, is more
 flexible and powerful.

Well I admit to not having read the patches over the terrible wifi
here, but I presumed Ben's patches


-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/6] mesa: Begin tracking whether a program needs re-linking.

On 05/14/2014 05:28 PM, Kenneth Graunke wrote:
 Tracking this will allow us to issue warnings when using a program that
 hasn't yet been relinked, or when re-linking unnecessarily.
 
 The following functions cause changes that don't take effect until the
 program has been re-linked:
 
 - glAttachShader
 - glBindAttribLocation
 - glBindFragDataLocation
 - glBindFragDataLocationIndexed
 - glTransformFeedbackVaryings
 - glProgramParameteri (separable/binary retrievable hint)
 - glUniformBlockBinding

And also glDetachShader, right?

 OpenGL also allows the application to recompile shaders that have been
 attached to programs and linked---at which point, they need relinking.
 That case will be handled shortly.
 
 Signed-off-by: Kenneth Graunke kenn...@whitecape.org
 ---
  src/mesa/main/mtypes.h| 1 +
  src/mesa/main/shader_query.cpp| 3 ++-
  src/mesa/main/shaderapi.c | 6 ++
  src/mesa/main/transformfeedback.c | 1 +
  src/mesa/main/uniforms.c  | 2 ++
  5 files changed, 12 insertions(+), 1 deletion(-)
 
 diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
 index 917d071..741f936 100644
 --- a/src/mesa/main/mtypes.h
 +++ b/src/mesa/main/mtypes.h
 @@ -2744,6 +2744,7 @@ struct gl_shader_program
 struct gl_active_atomic_buffer *AtomicBuffers;
 unsigned NumAtomicBuffers;
  
 +   bool NeedsRelink;
 GLboolean LinkStatus;   /** GL_LINK_STATUS */
 GLboolean Validated;
 GLboolean _Used;/** Ever used for drawing? */
 diff --git a/src/mesa/main/shader_query.cpp b/src/mesa/main/shader_query.cpp
 index 36d1d9c..db3be0c 100644
 --- a/src/mesa/main/shader_query.cpp
 +++ b/src/mesa/main/shader_query.cpp
 @@ -74,6 +74,7 @@ _mesa_BindAttribLocation(GLhandleARB program, GLuint index,
  * Note that this attribute binding won't go into effect until
  * glLinkProgram is called again.
  */
 +   shProg-NeedsRelink = true;
  }
  
  static bool
 @@ -365,7 +366,7 @@ _mesa_BindFragDataLocationIndexed(GLuint program, GLuint 
 colorNumber,
  * Note that this binding won't go into effect until
  * glLinkProgram is called again.
  */
 -
 +   shProg-NeedsRelink = true;
  }
  
  GLint GLAPIENTRY
 diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
 index 28739da..59d30ff 100644
 --- a/src/mesa/main/shaderapi.c
 +++ b/src/mesa/main/shaderapi.c
 @@ -284,6 +284,7 @@ attach_shader(struct gl_context *ctx, GLuint program, 
 GLuint shader)
 shProg-Shaders[n] = NULL; /* since realloc() didn't zero the new space */
 _mesa_reference_shader(ctx, shProg-Shaders[n], sh);
 shProg-NumShaders++;
 +   shProg-NeedsRelink = true;
  }
  
  
 @@ -914,6 +915,9 @@ link_program(struct gl_context *ctx, GLuint program)
  
 _mesa_glsl_link_shader(ctx, shProg);
  
 +   if (shProg-LinkStatus == GL_TRUE)
 +  shProg-NeedsRelink = false;
 +
 if (shProg-LinkStatus == GL_FALSE  
 (ctx-_Shader-Flags  GLSL_REPORT_ERRORS)) {
_mesa_debug(ctx, Error linking program %u:\n%s\n,
 @@ -1770,6 +1774,7 @@ _mesa_ProgramParameteri(GLuint program, GLenum pname, 
 GLint value)
 * is loaded again a recompile can be avoided.
 */
shProg-BinaryRetreivableHint = value;
 +  shProg-NeedsRelink = true;
return;
  
 case GL_PROGRAM_SEPARABLE:
 @@ -1785,6 +1790,7 @@ _mesa_ProgramParameteri(GLuint program, GLenum pname, 
 GLint value)
   return;
}
shProg-SeparateShader = value;
 +  shProg-NeedsRelink = true;
return;
  
 default:
 diff --git a/src/mesa/main/transformfeedback.c 
 b/src/mesa/main/transformfeedback.c
 index a737463..c037faa 100644
 --- a/src/mesa/main/transformfeedback.c
 +++ b/src/mesa/main/transformfeedback.c
 @@ -771,6 +771,7 @@ _mesa_TransformFeedbackVaryings(GLuint program, GLsizei 
 count,
 /* No need to invoke FLUSH_VERTICES or flag NewTransformFeedback since
  * the varyings won't be used until shader link time.
  */
 +   shProg-NeedsRelink = true;
  }
  
  
 diff --git a/src/mesa/main/uniforms.c b/src/mesa/main/uniforms.c
 index 1daade4..39a61f7 100644
 --- a/src/mesa/main/uniforms.c
 +++ b/src/mesa/main/uniforms.c
 @@ -1043,6 +1043,8 @@ _mesa_UniformBlockBinding(GLuint program,
   sh-UniformBlocks[stage_index].Binding = uniformBlockBinding;
}
}
 +
 +  shProg-NeedsRelink = true;
 }
  }
  
 

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

Re: [Mesa-dev] [RFC PATCH 00/16] A new IR for Mesa

On 08/18/2014 05:44 AM, Roland Scheidegger wrote:
Am 16.08.2014 02:12, schrieb Connor Abbott:
I know what you might be thinking right now. Wait, *another* IR? Don't
we already have like 5 of those, not counting all the driver-specific
ones? Isn't this stuff complicated enough already? Well, there are some
pretty good reasons to start afresh (again...). In the years we've been
using GLSL IR, we've come to realize that, in fact, it's not what we
want *at all* to do optimizations on. Ian has done a talk at FOSDEM that
highlights some of the problems they've run into:

https://urldefense.proofpoint.com/v1/url?u=https://video.fosdem.org/2014/H1301_Cornil/Saturday/Three_Years_Experience_with_a_Treelike_Shader_IR.webmk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0Am=iXhCeAYmidPDc1lFo757Cc9V0PvWAN4n3X%2Fw%2B%2F7Lx%2Fs%3D%0As=f103fb26bf53eee64318a490517d1ee9ab88ecd29fcdbe49d54b5a27e7581c2e

But here's the summary:

* GLSL IR is way too much of a memory hog, since it has to make a new
variable for each temporary the compiler creates and then each time you
want to dereference that temporary you need to create an
ir_dereference_variable that points to it which is also very
cache-unfriendly (downright cache-mean!).

* The expression trees were originally added so that we could do
pattern matching to automatically optimize things, but this turned out
to be both very difficult to do and not very helpful. Instead, all it
does is add more complexity to the IR without much benefit - with SSA or
having proper use-def chains, we could get back what the trees give us
while also being able to do lots more optimizations.

* We don't have the concept of basic blocks in GLSL IR, which makes a
lot of optimizations harder because they were originally designed with
basic blocks in mind - take, for example, my SSA series. I had to map a
whole lot of concepts that were based on the control flow graph to this
tree of statements that GLSL IR uses, and the end result wound up
looking nothing at all like the original paper. This problem gets even
worse for things like e.g. Global Code Motion that depend upon having
the dominance tree.

I originally wanted to modify GLSL IR to fix these problems by adding
new instruction types that would address these issues and then
converting back and forth between the old and the new form, but I
realized that fixing all the problems would basically mean a complete
rewrite - and if that's the case, then why don't we start from scratch?
So I took Ken's suggestions and started designing, and then at Intel
over the summer started implementing, a completely new IR which I call
NIR that's at a lower level than GLSL IR, but still high-level enough to
be mostly device-independant (different drivers may have different
passes and different ways of lowering e.g. matrix multiplies) so that
we can do generic optimizations on it. Having support for SSA from the
beginning was also a must, because lots of optimisations that we really
want for cleaning up DX9-translated games are either a lot easier in or
made possible by SSA. I also made the decision for it to be typeless,
because that's what the cool kids are all doing :) and for a
lower-level, flat IR it seemed like the thing to do (it could have gone
either way, though). So the key design points of NIR (pronounced either
like near as in NIR is near! or to rhyme with burr) are:

* It's flat (no expression trees)

* It's typeless

* Modifiers (abs, negate, saturate), swizzles, and write masks are part
of ALU instructions

* It includes enough GLSL-like things (variables that you can load from
or store to, function calls) to be hardware-agnostic (although we don't
have a way to represent matrix multiplies right now, but that could
easily be added) to be able to do optimizations at a high level, while
having lowering passes that convert variables to registers and
input/output/uniform loads/stores that will open up more opportunities
for optimization and save memory while being more hardware-specific.

* Control flow consists of a tree of if statements and loops, like in
GLSL IR, except the leaves of the tree are now basic blocks instead of
instructions. Also, each basic block keeps track of its successors and
predecessors, so the control flow graph is explicit in the IR.

* SSA is natively supported, and SSA uses point directly to the SSA
definition, which means that the use-def chains are always there, and
def-use chains are kept by tracking the set of all uses for each
definition.

* It's written in C.

(see the README in patch 3 and nir.h in patch 4 for more details)

Some things that are missing or could be improved:

* There's currently no alias tracking for inputs, outputs, and uniforms.
This is especially important for uniforms because we don't pack them
like we pack inputs and outputs.

* We need a way to represent matrix multiplies so that we can

Re: [Mesa-dev] [Intel-gfx] [PATCH 00/68] Broadwell 48b addressing and prelocations (no relocs)

2014-08-22 Thread Daniel Vetter

On Fri, Aug 22, 2014 at 3:38 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
 On Fri, Aug 22, 2014 at 03:30:12PM +0200, Daniel Vetter wrote:
 On Fri, Aug 22, 2014 at 9:03 AM, Chris Wilson ch...@chris-wilson.co.uk 
 wrote:
If a GPU
client uses only prelocations, the relocation process can be entirely
skipped. This sounds like a big win initially,
  
   Close to zero if the client uses existing interfaces.
   -Chris
 
  Chris,
 
  I don't know if you've seen Ben's libdrm and Mesa patches, but with a few 
  patches to libdrm and virtually zero Mesa changes, he's apparently 
  eliminated our need to do any relocations for the 3D driver.  It wasn't 
  invasive at all---I was surprised.
 
  Indeed, you could do everything inside libdrm with the code I posted 2
  years ago.

 I915_EXEC_NO_RELOC can be used to tell the kernel that it doesn't need
 to walk all the reloc tables (if nothing moved) because userspace
 didn't go insane and reuse reloc trees. So you'd need to implement a
 flag + a libdrm function to set that (iirc mesa has been non-stupid
 since years). And yeah I kinda expect any new reloc-less thing to get
 benchmarked against an implementation using that, since the 48bit
 specific thing proposed looks like a fairly short-lived stop-gap, and
 since the current no-reloc we already have would work everywhere. And
 yeah I've been poking people to look at this for years. too.

 Here, I was referring to soft-pinning. The API here is essentially
 comprised of two parts:

 1: a pin into the vm upon creation
 2: implicit no-relocation upon execbuffer

 By making those two steps independent, the API as I see is, is more
 flexible and powerful.

Well I admit to not having read the patches over the terrible wifi
here, but I presumed Ben's patches did implement softpin. I guess I've
made a mess of all of this now. In any case I still want to see
relative improvements over what we have since the prelocated stuff
looks like a gen8 oneshot. And we still can't do relocation-less
execbuf because the gpu can't fault, so I'm not sure at all whether
this is actually useful for opencl 2.0.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC PATCH 00/16] A new IR for Mesa

On 08/19/2014 11:33 PM, Francisco Jerez wrote:
 Connor Abbott cwabbo...@gmail.com writes:
 
 On Tue, Aug 19, 2014 at 11:40 AM, Francisco Jerez curroje...@riseup.net 
 wrote:
 Tom Stellard t...@stellard.net writes:

 On Tue, Aug 19, 2014 at 11:04:59AM -0400, Connor Abbott wrote:
 On Mon, Aug 18, 2014 at 8:52 PM, Michel Dänzer mic...@daenzer.net wrote:
 On 19.08.2014 01:28, Connor Abbott wrote:
 On Mon, Aug 18, 2014 at 4:32 AM, Michel Dänzer mic...@daenzer.net 
 wrote:
 On 16.08.2014 09:12, Connor Abbott wrote:
 I know what you might be thinking right now. Wait, *another* IR? 
 Don't
 we already have like 5 of those, not counting all the driver-specific
 ones? Isn't this stuff complicated enough already? Well, there are 
 some
 pretty good reasons to start afresh (again...). In the years we've 
 been
 using GLSL IR, we've come to realize that, in fact, it's not what we
 want *at all* to do optimizations on.

 Did you evaluate using LLVM IR instead of inventing yet another one?


 --
 Earthling Michel Dänzer|  
 http://www.amd.com
 Libre software enthusiast  |Mesa and X 
 developer

 Yes. See

 http://lists.freedesktop.org/archives/mesa-dev/2014-February/053502.html

 and

 http://lists.freedesktop.org/archives/mesa-dev/2014-February/053522.html

 I know Ian can't deal with LLVM for some reason. I was wondering if
 *you* evaluated it, and if so, why you rejected it.


 --
 Earthling Michel Dänzer|  http://www.amd.com
 Libre software enthusiast  |Mesa and X developer


 Well, first of all, the fact that Ian and Ken don't want to use it
 means that any plan to use LLVM for the Intel driver is dead in the
 water anyways - you can translate NIR into LLVM if you want, but for
 i965 we want to share optimizations between our 2 backends (FS and
 vec4) that we can't do today in GLSL IR so this is what we want to use
 for that, and since nobody else does anything with the core GLSL
 compiler except when they have to, when we start moving things out of
 GLSL IR this will probably replace GLSL IR as the infrastructure that
 all Mesa drivers use. But with that in mind, here are a few reasons
 why we wouldn't want to use LLVM:

 * LLVM wasn't built to understand structured CFG's, meaning that you
 need to re-structurize it using a pass that's fragile and prone to
 break if some other pass optimizes the shader in a way that makes it
 non-structured (i.e. not expressible in terms of loops and if
 statements). This loss of information also means that passes that need
 to know things like, for example, the loop nesting depth need to do an
 analysis pass whereas with NIR you can just walk up the control flow
 tree and count the number of loops we hit.


 LLVM has a pass to structurize the CFG.  We use it in the radeon
 drivers, and it is run after all of the other LLVM optimizations which have
 no concept of structured CFG.  It's not bug free, but it works really
 well even with all of the complex OpenCL kernels we throw at it.

 Your point about losing information when the CFG is de-structurized is
 valid, but for things like loop depth, I'm not sure why we couldn't write 
 an
 LLVM analysis pass for this (if one doesn't already exist).


 I don't think this is such a big deal either.  At least the
 structurization pass used on newer AMD hardware isn't fragile in the
 way you seem to imply -- AFAIK (unlike the old AMDIL heuristic
 algorithm) it's guaranteed to give you a valid structurized output no
 matter what the previous optimization passes have done to the CFG,
 modulo bugs.  I admit that the situation is nevertheless suboptimal.
 Ideally this information wouldn't get lost along the way.  For the long
 term we may want to represent structured control flow directly in the IR
 as you say, I just don't see how reinventing the IR saves us any work if
 we could just fix the existing one.

 It seems to me that something like how we represent control flow is a
 pretty fundamental part of the IR - it affects any optimization pass
 that needs to do anything beyond adding and removing instructions. How
 would you fix that, especially given that LLVM is primarily designed
 for CPU's where you don't want to be restricted to structured control
 flow at all? It seems like our goals (preserve the structure) conflict
 with the way LLVM has been designed.

 I think we can fix this by introducing new structured variants of the
 branch instruction in a way that doesn't alter the fundamental structure
 of the IR.  E.g. an if branch could look like:
 
 ifbr i1 cond, label iftrue, label iffalse, label join
 
 Where both branches are guaranteed to converge at join.  Sure, this
 will require fixing many assumptions, but on the one hand it's not
 immediately required (as we can address this problem for the time being
 using the same solution AMD uses) and on the other hand it's still less
 work than starting from scratch.
 

 * LLVM doesn't

[Mesa-dev] [PATCH 1/2] u_vbuf: Simplify the format fallback translation.

2014-08-22 Thread Eric Anholt

Individual caps made supporting new fallbacks more complicated than it
needed to be.  Instead, just make a table of fallbacks at context init
time.
---
 src/gallium/auxiliary/cso_cache/cso_context.c |  12 +-
 src/gallium/auxiliary/util/u_vbuf.c   | 178 --
 src/gallium/auxiliary/util/u_vbuf.h   |  11 +-
 3 files changed, 84 insertions(+), 117 deletions(-)

diff --git a/src/gallium/auxiliary/cso_cache/cso_context.c 
b/src/gallium/auxiliary/cso_cache/cso_context.c
index ca91b67..3d8860f 100644
--- a/src/gallium/auxiliary/cso_cache/cso_context.c
+++ b/src/gallium/auxiliary/cso_cache/cso_context.c
@@ -239,18 +239,8 @@ static void cso_init_vbuf(struct cso_context *cso)
 {
struct u_vbuf_caps caps;
 
-   u_vbuf_get_caps(cso-pipe-screen, caps);
-
/* Install u_vbuf if there is anything unsupported. */
-   if (!caps.buffer_offset_unaligned ||
-   !caps.buffer_stride_unaligned ||
-   !caps.velem_src_offset_unaligned ||
-   !caps.format_fixed32 ||
-   !caps.format_float16 ||
-   !caps.format_float64 ||
-   !caps.format_norm32 ||
-   !caps.format_scaled32 ||
-   !caps.user_vertex_buffers) {
+   if (u_vbuf_get_caps(cso-pipe-screen, caps)) {
   cso-vbuf = u_vbuf_create(cso-pipe, caps,
 cso-aux_vertex_buffer_index);
}
diff --git a/src/gallium/auxiliary/util/u_vbuf.c 
b/src/gallium/auxiliary/util/u_vbuf.c
index c475ee1..42f5915 100644
--- a/src/gallium/auxiliary/util/u_vbuf.c
+++ b/src/gallium/auxiliary/util/u_vbuf.c
@@ -191,47 +191,87 @@ u_vbuf_create_vertex_elements(struct u_vbuf *mgr, 
unsigned count,
   const struct pipe_vertex_element *attribs);
 static void u_vbuf_delete_vertex_elements(struct u_vbuf *mgr, void *cso);
 
+static const struct {
+   enum pipe_format from, to;
+} vbuf_format_fallbacks[] = {
+   { PIPE_FORMAT_R32_FIXED,PIPE_FORMAT_R32_FLOAT },
+   { PIPE_FORMAT_R32G32_FIXED, PIPE_FORMAT_R32G32_FLOAT },
+   { PIPE_FORMAT_R32G32B32_FIXED,  PIPE_FORMAT_R32G32B32_FLOAT },
+   { PIPE_FORMAT_R32G32B32A32_FIXED,   PIPE_FORMAT_R32G32B32A32_FLOAT },
+   { PIPE_FORMAT_R16_FLOAT,PIPE_FORMAT_R32_FLOAT },
+   { PIPE_FORMAT_R16G16_FLOAT, PIPE_FORMAT_R32G32_FLOAT },
+   { PIPE_FORMAT_R16G16B16_FLOAT,  PIPE_FORMAT_R32G32B32_FLOAT },
+   { PIPE_FORMAT_R16G16B16A16_FLOAT,   PIPE_FORMAT_R32G32B32A32_FLOAT },
+   { PIPE_FORMAT_R64_FLOAT,PIPE_FORMAT_R32_FLOAT },
+   { PIPE_FORMAT_R64G64_FLOAT, PIPE_FORMAT_R32G32_FLOAT },
+   { PIPE_FORMAT_R64G64B64_FLOAT,  PIPE_FORMAT_R32G32B32_FLOAT },
+   { PIPE_FORMAT_R64G64B64A64_FLOAT,   PIPE_FORMAT_R32G32B32A32_FLOAT },
+   { PIPE_FORMAT_R32_UNORM,PIPE_FORMAT_R32_FLOAT },
+   { PIPE_FORMAT_R32G32_UNORM, PIPE_FORMAT_R32G32_FLOAT },
+   { PIPE_FORMAT_R32G32B32_UNORM,  PIPE_FORMAT_R32G32B32_FLOAT },
+   { PIPE_FORMAT_R32G32B32A32_UNORM,   PIPE_FORMAT_R32G32B32A32_FLOAT },
+   { PIPE_FORMAT_R32_SNORM,PIPE_FORMAT_R32_FLOAT },
+   { PIPE_FORMAT_R32G32_SNORM, PIPE_FORMAT_R32G32_FLOAT },
+   { PIPE_FORMAT_R32G32B32_SNORM,  PIPE_FORMAT_R32G32B32_FLOAT },
+   { PIPE_FORMAT_R32G32B32A32_SNORM,   PIPE_FORMAT_R32G32B32A32_FLOAT },
+   { PIPE_FORMAT_R32_USCALED,  PIPE_FORMAT_R32_FLOAT },
+   { PIPE_FORMAT_R32G32_USCALED,   PIPE_FORMAT_R32G32_FLOAT },
+   { PIPE_FORMAT_R32G32B32_USCALED,PIPE_FORMAT_R32G32B32_FLOAT },
+   { PIPE_FORMAT_R32G32B32A32_USCALED, PIPE_FORMAT_R32G32B32A32_FLOAT },
+   { PIPE_FORMAT_R32_SSCALED,  PIPE_FORMAT_R32_FLOAT },
+   { PIPE_FORMAT_R32G32_SSCALED,   PIPE_FORMAT_R32G32_FLOAT },
+   { PIPE_FORMAT_R32G32B32_SSCALED,PIPE_FORMAT_R32G32B32_FLOAT },
+   { PIPE_FORMAT_R32G32B32A32_SSCALED, PIPE_FORMAT_R32G32B32A32_FLOAT },
+};
 
-void u_vbuf_get_caps(struct pipe_screen *screen, struct u_vbuf_caps *caps)
+boolean u_vbuf_get_caps(struct pipe_screen *screen, struct u_vbuf_caps *caps)
 {
-   caps-format_fixed32 =
-  screen-is_format_supported(screen, PIPE_FORMAT_R32_FIXED, PIPE_BUFFER,
-  0, PIPE_BIND_VERTEX_BUFFER);
-
-   caps-format_float16 =
-  screen-is_format_supported(screen, PIPE_FORMAT_R16_FLOAT, PIPE_BUFFER,
-  0, PIPE_BIND_VERTEX_BUFFER);
-
-   caps-format_float64 =
-  screen-is_format_supported(screen, PIPE_FORMAT_R64_FLOAT, PIPE_BUFFER,
-  0, PIPE_BIND_VERTEX_BUFFER);
-
-   caps-format_norm32 =
-  screen-is_format_supported(screen, PIPE_FORMAT_R32_UNORM, PIPE_BUFFER,
-  0, PIPE_BIND_VERTEX_BUFFER) 
-  screen-is_format_supported(screen, PIPE_FORMAT_R32_SNORM, PIPE_BUFFER,
-  0, PIPE_BIND_VERTEX_BUFFER);
-
-   caps-format_scaled32 =
-  screen-is_format_supported(screen, PIPE_FORMAT_R32_USCALED, PIPE_BUFFER,
-  0, PIPE_BIND_VERTEX_BUFFER) 
-

[Mesa-dev] [PATCH 2/2] u_vbuf: Add a few more format fallbacks.

2014-08-22 Thread Eric Anholt

Fixes piglit draw-vertices and gl-2.0-vertexattribpointer on vc4, where
I'm only advertising R32F to RGBA32F support so far.

Note: regresses gl-1.5-normal3b3s-invariance due to introduced flushes and
missing depth buffer load/store support in the driver.
---
 src/gallium/auxiliary/util/u_vbuf.c | 32 
 1 file changed, 32 insertions(+)

diff --git a/src/gallium/auxiliary/util/u_vbuf.c 
b/src/gallium/auxiliary/util/u_vbuf.c
index 42f5915..a372d69 100644
--- a/src/gallium/auxiliary/util/u_vbuf.c
+++ b/src/gallium/auxiliary/util/u_vbuf.c
@@ -222,6 +222,38 @@ static const struct {
{ PIPE_FORMAT_R32G32_SSCALED,   PIPE_FORMAT_R32G32_FLOAT },
{ PIPE_FORMAT_R32G32B32_SSCALED,PIPE_FORMAT_R32G32B32_FLOAT },
{ PIPE_FORMAT_R32G32B32A32_SSCALED, PIPE_FORMAT_R32G32B32A32_FLOAT },
+   { PIPE_FORMAT_R16_UNORM,PIPE_FORMAT_R32_FLOAT },
+   { PIPE_FORMAT_R16G16_UNORM, PIPE_FORMAT_R32G32_FLOAT },
+   { PIPE_FORMAT_R16G16B16_UNORM,  PIPE_FORMAT_R32G32B32_FLOAT },
+   { PIPE_FORMAT_R16G16B16A16_UNORM,   PIPE_FORMAT_R32G32B32A32_FLOAT },
+   { PIPE_FORMAT_R16_SNORM,PIPE_FORMAT_R32_FLOAT },
+   { PIPE_FORMAT_R16G16_SNORM, PIPE_FORMAT_R32G32_FLOAT },
+   { PIPE_FORMAT_R16G16B16_SNORM,  PIPE_FORMAT_R32G32B32_FLOAT },
+   { PIPE_FORMAT_R16G16B16A16_SNORM,   PIPE_FORMAT_R32G32B32A32_FLOAT },
+   { PIPE_FORMAT_R16_USCALED,  PIPE_FORMAT_R32_FLOAT },
+   { PIPE_FORMAT_R16G16_USCALED,   PIPE_FORMAT_R32G32_FLOAT },
+   { PIPE_FORMAT_R16G16B16_USCALED,PIPE_FORMAT_R32G32B32_FLOAT },
+   { PIPE_FORMAT_R16G16B16A16_USCALED, PIPE_FORMAT_R32G32B32A32_FLOAT },
+   { PIPE_FORMAT_R16_SSCALED,  PIPE_FORMAT_R32_FLOAT },
+   { PIPE_FORMAT_R16G16_SSCALED,   PIPE_FORMAT_R32G32_FLOAT },
+   { PIPE_FORMAT_R16G16B16_SSCALED,PIPE_FORMAT_R32G32B32_FLOAT },
+   { PIPE_FORMAT_R16G16B16A16_SSCALED, PIPE_FORMAT_R32G32B32A32_FLOAT },
+   { PIPE_FORMAT_R8_UNORM, PIPE_FORMAT_R32_FLOAT },
+   { PIPE_FORMAT_R8G8_UNORM,   PIPE_FORMAT_R32G32_FLOAT },
+   { PIPE_FORMAT_R8G8B8_UNORM, PIPE_FORMAT_R32G32B32_FLOAT },
+   { PIPE_FORMAT_R8G8B8A8_UNORM,   PIPE_FORMAT_R32G32B32A32_FLOAT },
+   { PIPE_FORMAT_R8_SNORM, PIPE_FORMAT_R32_FLOAT },
+   { PIPE_FORMAT_R8G8_SNORM,   PIPE_FORMAT_R32G32_FLOAT },
+   { PIPE_FORMAT_R8G8B8_SNORM, PIPE_FORMAT_R32G32B32_FLOAT },
+   { PIPE_FORMAT_R8G8B8A8_SNORM,   PIPE_FORMAT_R32G32B32A32_FLOAT },
+   { PIPE_FORMAT_R8_USCALED,   PIPE_FORMAT_R32_FLOAT },
+   { PIPE_FORMAT_R8G8_USCALED, PIPE_FORMAT_R32G32_FLOAT },
+   { PIPE_FORMAT_R8G8B8_USCALED,   PIPE_FORMAT_R32G32B32_FLOAT },
+   { PIPE_FORMAT_R8G8B8A8_USCALED, PIPE_FORMAT_R32G32B32A32_FLOAT },
+   { PIPE_FORMAT_R8_SSCALED,   PIPE_FORMAT_R32_FLOAT },
+   { PIPE_FORMAT_R8G8_SSCALED, PIPE_FORMAT_R32G32_FLOAT },
+   { PIPE_FORMAT_R8G8B8_SSCALED,   PIPE_FORMAT_R32G32B32_FLOAT },
+   { PIPE_FORMAT_R8G8B8A8_SSCALED, PIPE_FORMAT_R32G32B32A32_FLOAT },
 };
 
 boolean u_vbuf_get_caps(struct pipe_screen *screen, struct u_vbuf_caps *caps)
-- 
2.1.0

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

Re: [Mesa-dev] [RFC PATCH 00/16] A new IR for Mesa

On 08/20/2014 09:11 AM, Francisco Jerez wrote:
 Connor Abbott cwabbo...@gmail.com writes:
 
 On Wed, Aug 20, 2014 at 7:01 AM, Francisco Jerez curroje...@riseup.net 
 wrote:
 Connor Abbott cwabbo...@gmail.com writes:

 On Tue, Aug 19, 2014 at 11:33 PM, Francisco Jerez curroje...@riseup.net 
 wrote:
 Connor Abbott cwabbo...@gmail.com writes:

 On Tue, Aug 19, 2014 at 11:40 AM, Francisco Jerez 
 curroje...@riseup.net wrote:
 Tom Stellard t...@stellard.net writes:

 On Tue, Aug 19, 2014 at 11:04:59AM -0400, Connor Abbott wrote:
 On Mon, Aug 18, 2014 at 8:52 PM, Michel Dänzer mic...@daenzer.net 
 wrote:
 On 19.08.2014 01:28, Connor Abbott wrote:
 On Mon, Aug 18, 2014 at 4:32 AM, Michel Dänzer mic...@daenzer.net 
 wrote:
 On 16.08.2014 09:12, Connor Abbott wrote:
 I know what you might be thinking right now. Wait, *another* IR? 
 Don't
 we already have like 5 of those, not counting all the 
 driver-specific
 ones? Isn't this stuff complicated enough already? Well, there 
 are some
 pretty good reasons to start afresh (again...). In the years 
 we've been
 using GLSL IR, we've come to realize that, in fact, it's not what 
 we
 want *at all* to do optimizations on.

 Did you evaluate using LLVM IR instead of inventing yet another 
 one?


 --
 Earthling Michel Dänzer|  
 http://www.amd.com
 Libre software enthusiast  |Mesa and X 
 developer

 Yes. See

 http://lists.freedesktop.org/archives/mesa-dev/2014-February/053502.html

 and

 http://lists.freedesktop.org/archives/mesa-dev/2014-February/053522.html

 I know Ian can't deal with LLVM for some reason. I was wondering if
 *you* evaluated it, and if so, why you rejected it.


 --
 Earthling Michel Dänzer|  
 http://www.amd.com
 Libre software enthusiast  |Mesa and X 
 developer


 Well, first of all, the fact that Ian and Ken don't want to use it
 means that any plan to use LLVM for the Intel driver is dead in the
 water anyways - you can translate NIR into LLVM if you want, but for
 i965 we want to share optimizations between our 2 backends (FS and
 vec4) that we can't do today in GLSL IR so this is what we want to use
 for that, and since nobody else does anything with the core GLSL
 compiler except when they have to, when we start moving things out of
 GLSL IR this will probably replace GLSL IR as the infrastructure that
 all Mesa drivers use. But with that in mind, here are a few reasons
 why we wouldn't want to use LLVM:

 * LLVM wasn't built to understand structured CFG's, meaning that you
 need to re-structurize it using a pass that's fragile and prone to
 break if some other pass optimizes the shader in a way that makes it
 non-structured (i.e. not expressible in terms of loops and if
 statements). This loss of information also means that passes that need
 to know things like, for example, the loop nesting depth need to do an
 analysis pass whereas with NIR you can just walk up the control flow
 tree and count the number of loops we hit.


 LLVM has a pass to structurize the CFG.  We use it in the radeon
 drivers, and it is run after all of the other LLVM optimizations which 
 have
 no concept of structured CFG.  It's not bug free, but it works really
 well even with all of the complex OpenCL kernels we throw at it.

 Your point about losing information when the CFG is de-structurized is
 valid, but for things like loop depth, I'm not sure why we couldn't 
 write an
 LLVM analysis pass for this (if one doesn't already exist).


 I don't think this is such a big deal either.  At least the
 structurization pass used on newer AMD hardware isn't fragile in the
 way you seem to imply -- AFAIK (unlike the old AMDIL heuristic
 algorithm) it's guaranteed to give you a valid structurized output no
 matter what the previous optimization passes have done to the CFG,
 modulo bugs.  I admit that the situation is nevertheless suboptimal.
 Ideally this information wouldn't get lost along the way.  For the long
 term we may want to represent structured control flow directly in the IR
 as you say, I just don't see how reinventing the IR saves us any work if
 we could just fix the existing one.

 It seems to me that something like how we represent control flow is a
 pretty fundamental part of the IR - it affects any optimization pass
 that needs to do anything beyond adding and removing instructions. How
 would you fix that, especially given that LLVM is primarily designed
 for CPU's where you don't want to be restricted to structured control
 flow at all? It seems like our goals (preserve the structure) conflict
 with the way LLVM has been designed.

 I think we can fix this by introducing new structured variants of the
 branch instruction in a way that doesn't alter the fundamental structure
 of the IR.  E.g. an if branch could look like:

 ifbr i1 cond, label iftrue, label iffalse, label join

 Where both branches are guaranteed to converge at join.  Sure, this
 will

Re: [Mesa-dev] [RFC PATCH 00/16] A new IR for Mesa

On 08/20/2014 11:58 AM, Tom Stellard wrote:
 On Wed, Aug 20, 2014 at 11:13:13AM -0700, Kenneth Graunke wrote:
 On Wednesday, August 20, 2014 06:41:08 PM Michel Dänzer wrote:
 On 20.08.2014 00:04, Connor Abbott wrote:
 On Mon, Aug 18, 2014 at 8:52 PM, Michel Dänzer mic...@daenzer.net wrote:
 On 19.08.2014 01:28, Connor Abbott wrote:
 On Mon, Aug 18, 2014 at 4:32 AM, Michel Dänzer mic...@daenzer.net 
 wrote:
 On 16.08.2014 09:12, Connor Abbott wrote:
 I know what you might be thinking right now. Wait, *another* IR? Don't
 we already have like 5 of those, not counting all the driver-specific
 ones? Isn't this stuff complicated enough already? Well, there are 
 some
 pretty good reasons to start afresh (again...). In the years we've been
 using GLSL IR, we've come to realize that, in fact, it's not what we
 want *at all* to do optimizations on.

 Did you evaluate using LLVM IR instead of inventing yet another one?

 Yes. See

 http://lists.freedesktop.org/archives/mesa-dev/2014-February/053502.html

 and

 http://lists.freedesktop.org/archives/mesa-dev/2014-February/053522.html

 I know Ian can't deal with LLVM for some reason. I was wondering if
 *you* evaluated it, and if so, why you rejected it.

 First of all, thank you for sharing more specific information than
 'table-flipping rage'.


 * LLVM is on a different release schedule (6 months vs. 3 months), has
 a different review process, etc., which means that to add support for
 new functionality that involves shaders, we now have to submit patches
 to two separate projects, and then 2 months later when we ship Mesa it
 turns out that nobody can actually use the new feature because it
 depends upon an unreleased version of LLVM that won't be released for
 another 3 months and then packaged by distros even later...

 This has indeed been frustrating at times, but it's better now for
 backend changes since Tom has been making LLVM point releases.

 Yeah - absolutely.

 As for the GLSL frontend, I agree with Tom that it shouldn't require
 that much direct interaction with the LLVM project.


 we've already had problems where distros refused to ship newer Mesa
 releases because radeon depended on a version of LLVM newer than the
 one they were shipping, [...]

 That's news to me, can you be more specific?

 That sounds like basically a distro issue though, since different LLVM
 versions can be installed in parallel (and the one used by default
 doesn't have to be the newest one). And it even works if another part of
 the same process uses a different version of LLVM.

 Yes, one can argue that it's a distribution issue - but it's an extremely 
 painful problem for distributions.

 For example, Debian was stuck on Mesa 9.2.2 for 4 months (2013-12-08 to 
 2014-03-22), and I was told this was because of LLVM versioning changes in 
 the other drivers (primarily radeon, I believe, but probably also llvmpipe).

 Mesa 9.2.2 hung the GPU every 5-10 minutes on Sandybridge, and we fixed that 
 in Mesa 9.2.3.  But we couldn't get people to actually ship it, and had to 
 field tons of bug reports from upset users for several months.

 Gentoo has also had trouble updating for similar reasons; Matt (the Gentoo 
 Mesa package mantainer) can probably comment more.

 I've also heard stories from friends of mine who use radeonsi that they 
 couldn't get new GL features or compiler fixes unless they upgrade both Mesa 
 /and/ LLVM, and that LLVM was usually either not released or not available 
 in their distribution for a few months.

 Those are the sorts of things I'd like to avoid.  The compiler is easily the 
 most crucial part of a modern graphics stack; splitting it out into a 
 separate repository and project seems like a nightmare for people who care 
 about getting new drivers released and shipped in distributions in a timely 
 fashion.

 Or, looking at it the other way: today, everything you need as an Intel or 
 (AFAIK) Nouveau 3D user is nicely contained within Mesa.  Our community has 
 complete control over when we do those releases.  New important bug fixes, 
 performance improvements, or features?  Ship a new Mesa, and you're done.  
 That's a really nice feature I'd hate to lose.

 
 It has been a challenge to match versions of LLVM and Mesa for radeonsi,
 but as Michel mention this has been made easier now that we are doing
 LLVM point releases.
 
 However, as I mentioned before if we were using LLVM IR as a common IR
 it is unlikely that there would be any new features in Mesa that would
 depend on changes in LLVM.  The only thing we would need to modify LLVM
 for would be:
 - Extending the C API
 - Bug fixes for optimization passes
 - Optimization pass improvements
 
 And remember all these changes would be for improving common code that
 is shared between drivers.  All of the important compiler features would
 still go into the driver specific backends, which for most drivers are a
 part of Mesa.
 
 Even for a big new feature like geometry shaders you

[Mesa-dev] [PATCH] glsl: allow precision qualifier on sampler arrays

2014-08-22 Thread Frank Henigman

If a precision qualifer is allowed on type T, it should be allowed
on an array of T.  Refactor the check to ensure this is the case.
---
I wanted to expand the comment to say why is_record() is in there,
but I don't understand why it is.  I thought structs couldn't have
precision qualifiers.

 src/glsl/ast_to_hir.cpp | 75 +++--
 1 file changed, 41 insertions(+), 34 deletions(-)

diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index 30b02d0..998404a 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -3202,6 +3202,41 @@ validate_identifier(const char *identifier, YYLTYPE loc,
}
 }
 
+static bool
+precision_qualifier_allowed(const glsl_type *type)
+{
+   /* Precision qualifiers apply to floating point, integer and sampler
+* types.
+*
+* Section 4.5.2 (Precision Qualifiers) of the GLSL 1.30 spec says:
+*Any floating point or any integer declaration can have the type
+*preceded by one of these precision qualifiers [...] Literal
+*constants do not have precision qualifiers. Neither do Boolean
+*variables.
+*
+* Section 4.5 (Precision and Precision Qualifiers) of the GLSL 1.30
+* spec also says:
+*
+* Precision qualifiers are added for code portability with OpenGL
+* ES, not for functionality. They have the same syntax as in OpenGL
+* ES.
+*
+* Section 8 (Built-In Functions) of the GLSL ES 1.00 spec says:
+*
+* uniform lowp sampler2D sampler;
+* highp vec2 coord;
+* ...
+* lowp vec4 col = texture2D (sampler, coord);
+*// texture2D returns lowp
+*
+* From this, we infer that GLSL 1.30 (and later) should allow precision
+* qualifiers on sampler types just like float and integer types.
+*/
+   return type-is_float()
+   || type-is_integer()
+   || type-is_record()
+   || type-is_sampler();
+}
 
 ir_rvalue *
 ast_declarator_list::hir(exec_list *instructions,
@@ -3689,41 +3724,13 @@ ast_declarator_list::hir(exec_list *instructions,
   }
 
 
-  /* Precision qualifiers apply to floating point, integer and sampler
-   * types.
-   *
-   * Section 4.5.2 (Precision Qualifiers) of the GLSL 1.30 spec says:
-   *Any floating point or any integer declaration can have the type
-   *preceded by one of these precision qualifiers [...] Literal
-   *constants do not have precision qualifiers. Neither do Boolean
-   *variables.
-   *
-   * Section 4.5 (Precision and Precision Qualifiers) of the GLSL 1.30
-   * spec also says:
-   *
-   * Precision qualifiers are added for code portability with OpenGL
-   * ES, not for functionality. They have the same syntax as in OpenGL
-   * ES.
-   *
-   * Section 8 (Built-In Functions) of the GLSL ES 1.00 spec says:
-   *
-   * uniform lowp sampler2D sampler;
-   * highp vec2 coord;
-   * ...
-   * lowp vec4 col = texture2D (sampler, coord);
-   *// texture2D returns lowp
-   *
-   * From this, we infer that GLSL 1.30 (and later) should allow precision
-   * qualifiers on sampler types just like float and integer types.
+  /* If a precision qualifier is allowed on a type, it is allowed on
+   * an array of that type.
*/
-  if (this-type-qualifier.precision != ast_precision_none
-   !var-type-is_float()
-   !var-type-is_integer()
-   !var-type-is_record()
-   !var-type-is_sampler()
-   !(var-type-is_array()
-(var-type-fields.array-is_float()
-   || var-type-fields.array-is_integer( {
+  if (!(this-type-qualifier.precision == ast_precision_none
+  || precision_qualifier_allowed(var-type)
+  || (var-type-is_array()
+  precision_qualifier_allowed(var-type-fields.array {
 
  _mesa_glsl_error(loc, state,
   precision qualifiers apply only to floating point
-- 
2.1.0.rc2.206.gedb03e5

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

Re: [Mesa-dev] [PATCH] glsl: uniform sampler should occupy 1 location

I'm not sure this is correct, and I think we need a more complex fix.
As Dave points out, bindless will make it even more complex.

In a non-bindless, static-sampler-array-indexing world, applications
assume that samplers will use zero uniform locations.  The sampler
information is baked into the instructions, and it isn't represented
anywhere else in GPU memory.  As a result, I would not be surprised to
see previously working applications fail to link (due to using too many
uniforms) with this change.

It seems that the only time a sampler needs non-zero space is when it is
part of any array samplers (or array of structures containing samplers,
etc.) or is bindless.  In the array cases, it is probably only necessary
when the index is dynamic.  I think the array splitting and structure
splitting passes may make that moot.

The 82921 bug seems to be an orthognal issue.  There is a difference
between the API visible locations assigned to a uniform and the GPU
visible locations where the uniform is stored.  My guess is that we're
using the same accounting for both in places where we should not.

On 08/21/2014 04:25 PM, Micael Dias wrote:
 ---
 If samplers occupy zero locations we can run into a lot of issues. See #82921.
 I briefly tested this with my own code (which was previously crashing and
 misbehaving) and also ran other apps and everything seems to work fine.
 I'm not used to contributing code in this fashion, so please forgive me if I'm
 making some mistake. Thanks.
 
  src/glsl/glsl_types.cpp | 2 ++
  1 file changed, 2 insertions(+)
 
 diff --git a/src/glsl/glsl_types.cpp b/src/glsl/glsl_types.cpp
 index 66e9b13..cc05193 100644
 --- a/src/glsl/glsl_types.cpp
 +++ b/src/glsl/glsl_types.cpp
 @@ -691,6 +691,8 @@ glsl_type::uniform_locations() const
return size;
 case GLSL_TYPE_ARRAY:
return this-length * this-fields.array-uniform_locations();
 +   case GLSL_TYPE_SAMPLER:
 +  return 1;
 default:
break;
 }
 

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

Re: [Mesa-dev] [RFC PATCH 00/16] A new IR for Mesa

2014-08-22 Thread Matt Turner

On Fri, Aug 22, 2014 at 2:17 PM, Tom Stellard t...@stellard.net wrote:
 On Fri, Aug 22, 2014 at 02:10:03PM -0700, Ian Romanick wrote:
 Speaking of new shader stages... how would LLVM handle the 'precise'
 keyword in tesselation shaders?  I can envision ways to handle this in
 an IR that we control, but it's less obvious how we would handle it in
 LLVM or another external compiler package.


 What exactly does precise do? LLVM has fast-math flags you can apply to
 instructions and also some global flags.

Just search for precise in
https://www.opengl.org/registry/specs/ARB/gpu_shader5.txt
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC PATCH 00/16] A new IR for Mesa

On 08/22/2014 02:17 PM, Tom Stellard wrote:
 On Fri, Aug 22, 2014 at 02:10:03PM -0700, Ian Romanick wrote:
 On 08/20/2014 11:58 AM, Tom Stellard wrote:
 On Wed, Aug 20, 2014 at 11:13:13AM -0700, Kenneth Graunke wrote:
 On Wednesday, August 20, 2014 06:41:08 PM Michel Dänzer wrote:
 On 20.08.2014 00:04, Connor Abbott wrote:
 On Mon, Aug 18, 2014 at 8:52 PM, Michel Dänzer mic...@daenzer.net 
 wrote:
 On 19.08.2014 01:28, Connor Abbott wrote:
 On Mon, Aug 18, 2014 at 4:32 AM, Michel Dänzer mic...@daenzer.net 
 wrote:
 On 16.08.2014 09:12, Connor Abbott wrote:
 I know what you might be thinking right now. Wait, *another* IR? 
 Don't
 we already have like 5 of those, not counting all the driver-specific
 ones? Isn't this stuff complicated enough already? Well, there are 
 some
 pretty good reasons to start afresh (again...). In the years we've 
 been
 using GLSL IR, we've come to realize that, in fact, it's not what we
 want *at all* to do optimizations on.

 Did you evaluate using LLVM IR instead of inventing yet another one?

 Yes. See

 http://lists.freedesktop.org/archives/mesa-dev/2014-February/053502.html

 and

 http://lists.freedesktop.org/archives/mesa-dev/2014-February/053522.html

 I know Ian can't deal with LLVM for some reason. I was wondering if
 *you* evaluated it, and if so, why you rejected it.

 First of all, thank you for sharing more specific information than
 'table-flipping rage'.


 * LLVM is on a different release schedule (6 months vs. 3 months), has
 a different review process, etc., which means that to add support for
 new functionality that involves shaders, we now have to submit patches
 to two separate projects, and then 2 months later when we ship Mesa it
 turns out that nobody can actually use the new feature because it
 depends upon an unreleased version of LLVM that won't be released for
 another 3 months and then packaged by distros even later...

 This has indeed been frustrating at times, but it's better now for
 backend changes since Tom has been making LLVM point releases.

 Yeah - absolutely.

 As for the GLSL frontend, I agree with Tom that it shouldn't require
 that much direct interaction with the LLVM project.


 we've already had problems where distros refused to ship newer Mesa
 releases because radeon depended on a version of LLVM newer than the
 one they were shipping, [...]

 That's news to me, can you be more specific?

 That sounds like basically a distro issue though, since different LLVM
 versions can be installed in parallel (and the one used by default
 doesn't have to be the newest one). And it even works if another part of
 the same process uses a different version of LLVM.

 Yes, one can argue that it's a distribution issue - but it's an extremely 
 painful problem for distributions.

 For example, Debian was stuck on Mesa 9.2.2 for 4 months (2013-12-08 to 
 2014-03-22), and I was told this was because of LLVM versioning changes in 
 the other drivers (primarily radeon, I believe, but probably also 
 llvmpipe).

 Mesa 9.2.2 hung the GPU every 5-10 minutes on Sandybridge, and we fixed 
 that in Mesa 9.2.3.  But we couldn't get people to actually ship it, and 
 had to field tons of bug reports from upset users for several months.

 Gentoo has also had trouble updating for similar reasons; Matt (the Gentoo 
 Mesa package mantainer) can probably comment more.

 I've also heard stories from friends of mine who use radeonsi that they 
 couldn't get new GL features or compiler fixes unless they upgrade both 
 Mesa /and/ LLVM, and that LLVM was usually either not released or not 
 available in their distribution for a few months.

 Those are the sorts of things I'd like to avoid.  The compiler is easily 
 the most crucial part of a modern graphics stack; splitting it out into a 
 separate repository and project seems like a nightmare for people who care 
 about getting new drivers released and shipped in distributions in a 
 timely fashion.

 Or, looking at it the other way: today, everything you need as an Intel or 
 (AFAIK) Nouveau 3D user is nicely contained within Mesa.  Our community 
 has complete control over when we do those releases.  New important bug 
 fixes, performance improvements, or features?  Ship a new Mesa, and you're 
 done.  That's a really nice feature I'd hate to lose.


 It has been a challenge to match versions of LLVM and Mesa for radeonsi,
 but as Michel mention this has been made easier now that we are doing
 LLVM point releases.

 However, as I mentioned before if we were using LLVM IR as a common IR
 it is unlikely that there would be any new features in Mesa that would
 depend on changes in LLVM.  The only thing we would need to modify LLVM
 for would be:
 - Extending the C API
 - Bug fixes for optimization passes
 - Optimization pass improvements

 And remember all these changes would be for improving common code that
 is shared between drivers.  All of the important compiler features would
 still go into the driver specific

Re: [Mesa-dev] [PATCH] glcpp: Don't use alternation in the lookahead for empty pragmas.

2014-08-22 Thread Carl Worth

Kenneth Graunke kenn...@whitecape.org writes:
 Erm.  Shouldn't there be a star here? ^^^

Yikes! I don't know which is more embarrassing. The regression that I
committed that showed I didn't take enough care in running piglit, or
this patch which I submitted to fix it which showed I took even less
care in compiling!

 I can't imagine this compiles...or worse, it does, and continues the comment 
 to the */ in the rule below...

 +HASHpragma{HSPACE}*/[\r\n] {
  BEGIN INITIAL;
  }

That would have been really bad. It looks like the extended comment
could have formed a legal rule.

Fortunately, the patch as sent didn't compile at all. I had actually
compiled this patch earlier and run piglit. I must have introduced the
bug after that, but before sending the patch off.

 With that fixed, and piglit tested, this would get my Reviewed-by.

Thanks. I fixed this, added your Reviewed-by and a CC to stable, and
pushed this out.

-Carl

PS. Oddly, in a complete run of piglit, I saw that piglit's
17000-consecutive-chars-identifier test was fixed by my patch, but that
the 16385-consecutive-chars.frag test was passing before the patch, (but
that's the test that was originally cited in the bugzilla report).

-- 
carl.d.wo...@intel.com


pgp4DhzPOQbsz.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH V4 1/3] mesa: implement GL_MAX_VERTEX_ATTRIB_STRIDE

Patches 1 and 3 are

Reviewed-by: Ian Romanick ian.d.roman...@intel.com

On 08/20/2014 01:14 AM, Timothy Arceri wrote:
 V2: moved test for the VertexAttrib*Pointer() functions
  to update_array(), and made constant available for drivers to set
 
 Signed-off-by: Timothy Arceri t_arc...@yahoo.com.au
 ---
  Although 4.4 is a while away GL_MAX_VERTEX_ATTRIB_STRIDE is used in
  the ARB_direct_state_access spec so it seemed worth while adding this now.
 
  I've added MAX_VERTEX_ATTRIB_STRIDE to ARB_vertex_attrib_binding.xml
  as it didn't seem like it was worth putting it somewhere on its own
  as its really just a bug fix. Let me know if this should be moved.
 
  Finally I've assumed that 2048 is an ok value for i965.
 
  V4: add cap for all gallium drivers set to default (except r600g)
 
  V3: adds values for r600g and radeonsi (I'm unsable to test either of these 
 patches)
 
  src/mapi/glapi/gen/ARB_vertex_attrib_binding.xml |  1 +
  src/mesa/main/context.c  |  3 +++
  src/mesa/main/get_hash_params.py |  3 +++
  src/mesa/main/mtypes.h   |  3 +++
  src/mesa/main/varray.c   | 22 ++
  5 files changed, 32 insertions(+)
 
 diff --git a/src/mapi/glapi/gen/ARB_vertex_attrib_binding.xml 
 b/src/mapi/glapi/gen/ARB_vertex_attrib_binding.xml
 index 0ee6a3c..7e62688 100644
 --- a/src/mapi/glapi/gen/ARB_vertex_attrib_binding.xml
 +++ b/src/mapi/glapi/gen/ARB_vertex_attrib_binding.xml
 @@ -53,6 +53,7 @@
  enum name=VERTEX_BINDING_STRIDE value=0x82D8/
  enum name=MAX_VERTEX_ATTRIB_RELATIVE_OFFSET value=0x82D9/
  enum name=MAX_VERTEX_ATTRIB_BINDINGS value=0x82DA/
 +enum name=MAX_VERTEX_ATTRIB_STRIDE value=0x82E5/
  
  /category
  /OpenGLAPI
 diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
 index 2320842..fbdbd68 100644
 --- a/src/mesa/main/context.c
 +++ b/src/mesa/main/context.c
 @@ -670,6 +670,9 @@ _mesa_init_constants(struct gl_constants *consts, gl_api 
 api)
? GL_CONTEXT_CORE_PROFILE_BIT
: GL_CONTEXT_COMPATIBILITY_PROFILE_BIT;
  
 +   /* GL 4.4 */
 +   consts-MaxVertexAttribStride = 2048;
 +
 /** GL_EXT_gpu_shader4 */
 consts-MinProgramTexelOffset = -8;
 consts-MaxProgramTexelOffset = 7;
 diff --git a/src/mesa/main/get_hash_params.py 
 b/src/mesa/main/get_hash_params.py
 index ff85820..aace8a5 100644
 --- a/src/mesa/main/get_hash_params.py
 +++ b/src/mesa/main/get_hash_params.py
 @@ -712,6 +712,9 @@ descriptor=[
[ MAX_GEOMETRY_INPUT_COMPONENTS, 
 CONTEXT_INT(Const.Program[MESA_SHADER_GEOMETRY].MaxInputComponents), 
 extra_version_32 ],
[ MAX_GEOMETRY_OUTPUT_COMPONENTS, 
 CONTEXT_INT(Const.Program[MESA_SHADER_GEOMETRY].MaxOutputComponents), 
 extra_version_32 ],
  
 +# GL 4.4
 +  [ MAX_VERTEX_ATTRIB_STRIDE, CONTEXT_ENUM(Const.MaxVertexAttribStride), 
 NO_EXTRA ],
 +
  # GL_ARB_robustness
[ RESET_NOTIFICATION_STRATEGY_ARB, CONTEXT_ENUM(Const.ResetStrategy), 
 NO_EXTRA ],
  
 diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
 index cb2a4df..adb6788 100644
 --- a/src/mesa/main/mtypes.h
 +++ b/src/mesa/main/mtypes.h
 @@ -3414,6 +3414,9 @@ struct gl_constants
 /** OpenGL version 3.2 */
 GLbitfield ProfileMask;   /** Mask of CONTEXT_x_PROFILE_BIT */
  
 +   /** OpenGL version 4.4 */
 +   GLuint MaxVertexAttribStride;
 +
 /** GL_EXT_transform_feedback */
 GLuint MaxTransformFeedbackBuffers;
 GLuint MaxTransformFeedbackSeparateComponents;
 diff --git a/src/mesa/main/varray.c b/src/mesa/main/varray.c
 index 5d3cc2a..7d169f9 100644
 --- a/src/mesa/main/varray.c
 +++ b/src/mesa/main/varray.c
 @@ -424,6 +424,13 @@ update_array(struct gl_context *ctx,
return;
 }
  
 +   if (ctx-API == API_OPENGL_CORE  ctx-Version = 44 
 +   stride  ctx-Const.MaxVertexAttribStride) {
 +  _mesa_error(ctx, GL_INVALID_VALUE, %s(stride=%d  
 +  GL_MAX_VERTEX_ATTRIB_STRIDE), func, stride);
 +  return;
 +   }
 +
 /* Page 29 (page 44 of the PDF) of the OpenGL 3.3 spec says:
  *
  * An INVALID_OPERATION error is generated under any of the following
 @@ -1437,6 +1444,13 @@ _mesa_BindVertexBuffer(GLuint bindingIndex, GLuint 
 buffer, GLintptr offset,
return;
 }
  
 +   if (ctx-API == API_OPENGL_CORE  ctx-Version = 44 
 +   stride  ctx-Const.MaxVertexAttribStride) {
 +  _mesa_error(ctx, GL_INVALID_VALUE, glBindVertexBuffer(stride=%d  
 +  GL_MAX_VERTEX_ATTRIB_STRIDE), stride);
 +  return;
 +   }
 +
 if (buffer == 
 vao-VertexBinding[VERT_ATTRIB_GENERIC(bindingIndex)].BufferObj-Name) {
vbo = vao-VertexBinding[VERT_ATTRIB_GENERIC(bindingIndex)].BufferObj;
 } else if (buffer != 0) {
 @@ -1565,6 +1579,14 @@ _mesa_BindVertexBuffers(GLuint first, GLsizei count, 
 const GLuint *buffers,
   continue;
}
  
 +  if (ctx-API == API_OPENGL_CORE  ctx-Version = 44 
 +  strides[i]

Re: [Mesa-dev] [PATCH 04/17] glsl: Add a pass to lower ir_unop_saturate to clamp(x, 0, 1)

On 08/18/2014 05:17 AM, Abdiel Janulgue wrote:
 Signed-off-by: Abdiel Janulgue abdiel.janul...@linux.intel.com
 ---
  src/glsl/ir_optimization.h  |  1 +
  src/glsl/lower_instructions.cpp | 29 +
  2 files changed, 30 insertions(+)
 
 diff --git a/src/glsl/ir_optimization.h b/src/glsl/ir_optimization.h
 index b83c225..1c6f72b 100644
 --- a/src/glsl/ir_optimization.h
 +++ b/src/glsl/ir_optimization.h
 @@ -40,6 +40,7 @@
  #define LDEXP_TO_ARITH 0x100
  #define CARRY_TO_ARITH 0x200
  #define BORROW_TO_ARITH0x400
 +#define SAT_TO_CLAMP   0x800
  
  /**
   * \see class lower_packing_builtins_visitor
 diff --git a/src/glsl/lower_instructions.cpp b/src/glsl/lower_instructions.cpp
 index 176070c..6842853 100644
 --- a/src/glsl/lower_instructions.cpp
 +++ b/src/glsl/lower_instructions.cpp
 @@ -41,6 +41,7 @@
   * - BITFIELD_INSERT_TO_BFM_BFI
   * - CARRY_TO_ARITH
   * - BORROW_TO_ARITH
 + * - SAT_TO_CLAMP
   *
   * SUB_TO_ADD_NEG:
   * ---
 @@ -104,6 +105,10 @@
   * 
   * Converts ir_borrow into (x  y).
   *
 + * SAT_TO_CLAMP:
 + * -
 + * Converts ir_unop_saturate into min(max(x, 0.0), 1.0)
 + *
   */
  
  #include main/core.h /* for M_LOG2E */
 @@ -139,6 +144,7 @@ private:
 void ldexp_to_arith(ir_expression *);
 void carry_to_arith(ir_expression *);
 void borrow_to_arith(ir_expression *);
 +   void sat_to_clamp(ir_expression *);
  };
  
  } /* anonymous namespace */
 @@ -484,6 +490,24 @@ 
 lower_instructions_visitor::borrow_to_arith(ir_expression *ir)
 this-progress = true;
  }
  
 +void
 +lower_instructions_visitor::sat_to_clamp(ir_expression *ir)
 +{
 +   /* Translates
 +*   ir_unop_saturate x
 +* into
 +*   ir_binop_min (ir_binop_max(x, 0.0), 1.0)
 +*/

I infer from this code that ir_unop_sat can only operate on
floating-point values.  If this is the case, you should also add checks
to ir_validate for this condition.

 +
 +   ir-operation = ir_binop_min;
 +   ir-operands[0] = new(ir) ir_expression(ir_binop_max, 
 ir-operands[0]-type,
 +   ir-operands[0],
 +   new(ir) ir_constant(0.0f));
 +   ir-operands[1] = new(ir) ir_constant(1.0f);
 +
 +   this-progress = true;
 +}
 +
  ir_visitor_status
  lower_instructions_visitor::visit_leave(ir_expression *ir)
  {
 @@ -540,6 +564,11 @@ lower_instructions_visitor::visit_leave(ir_expression 
 *ir)
   borrow_to_arith(ir);
break;
  
 +   case ir_unop_saturate:
 +  if (lowering(SAT_TO_CLAMP))
 + sat_to_clamp(ir);
 +  break;
 +
 default:
return visit_continue;
 }
 

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

Re: [Mesa-dev] Clamp/saturate optimizations v3

Patches 2, 3, 4, 5, 6, 9, 10, 11, 12, 15, and 17 are

Reviewed-by: Ian Romanick ian.d.roman...@intel.com

(Additional question below.)

On 08/18/2014 05:17 AM, Abdiel Janulgue wrote:
 v3 of clamp and saturate optimizations
 
 Changes since v1: 
  - Only remove the old try_emit_saturate operations after the new 
 optimizations are
in place. (Matt, Ian)
  - Output [min/max](saturate(x),b) instead of saturate([min/max](x,b)) as 
 suggested
by Ilia Mirkin.
  - The change above required some refactoring in the fs/vec4 backend to allow
propagation of certain instructions with saturate flag to SEL. For other 
 instructions,
we don't propagate saturate instructions, similar to the previous 
 behaviour.
 Since v2:
  - Fix comments to reflect we are doing a commutative operation, add missing 
 conditions
when optimizing clamp in opt_algebraic pass.
  - Refactor try_emit_saturate() in i965/fs instead of completely removing it. 
 This fixed a
a regression where the changes emitted an (extra) unnecessary saturated 
 mov when the 
expression generating src can do saturate directly instead.
  - Fix regression in the i965/vec4 copy-propagate optimization caused by 
 ignoring 
channels in the propagated instruction.
  - Count generated loops from the fs/vec4 generator.
 
 Results from our shader-db:
 
 total instructions in shared programs: 4538627 - 4560104 (0.47%)
 instructions in affected programs: 45144 - 66621 (47.57%)
 total loops in shared programs:887 - 711 (-19.84%)
 GAINED:0
 LOST:  36

Can we try benchmarking the applications that have shaders that lost
SIMD16 before pushing these changes?  I'd hate to have an optimization
that actually makes performance worse. :(

 I modified shader-db a bit to catch loops unrolls. The shaders that show 
 increase in
 instruction count are all due to the loop unroll pass triggered by this 
 optimization
 on games that contain looped clamp/saturate operation. The unroll pass also
 resulted in a few shaders with looped clamp/sat skipping SIMD16 generation.
 
 ** No piglit regressions observed **
 
 Abdiel Janulgue (17):
   i965/vec4/fs: Count loops in shader debug
   glsl: Add ir_unop_saturate
   glsl: Add constant evaluation of ir_unop_saturate
   glsl: Add a pass to lower ir_unop_saturate to clamp(x, 0, 1)
   ir_to_mesa, glsl_to_tgsi: lower ir_unop_saturate
   ir_to_mesa, glsl_to_tgsi: Add support for ir_unop_saturate
   i965/fs: Add support for ir_unop_saturate
   i965/vec4: Add support for ir_unop_saturate
   glsl: Implement saturate as ir_unop_saturate
   glsl: Optimize clamp(x, 0, 1) as saturate(x)
   glsl: Optimize clamp(x, 0.0, b), where b  1.0 as min(saturate(x),b)
   glsl: Optimize clamp(x, b, 1.0), where b  0.0 as max(saturate(x),b)
   i965/fs: Allow propagation of instructions with saturate flag to sel
   i965/vec4: Allow propagation of instructions with saturate flag to sel
   ir_to_mesa, glsl_to_tgsi: Remove try_emit_saturate
   i965/fs: Refactor try_emit_saturate
   i965/vec4: Remove try_emit_saturate
 
  src/glsl/ir.cpp  |  2 +
  src/glsl/ir.h|  1 +
  src/glsl/ir_builder.cpp  |  6 +-
  src/glsl/ir_constant_expression.cpp  |  6 ++
  src/glsl/ir_optimization.h   |  1 +
  src/glsl/ir_validate.cpp |  1 +
  src/glsl/lower_instructions.cpp  | 29 
  src/glsl/opt_algebraic.cpp   | 98 
 ++
  src/mesa/drivers/dri/i965/brw_fs_channel_expressions.cpp |  1 +
  src/mesa/drivers/dri/i965/brw_fs_copy_propagation.cpp| 18 -
  src/mesa/drivers/dri/i965/brw_fs_generator.cpp   |  6 +-
  src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 27 ---
  src/mesa/drivers/dri/i965/brw_vec4.h |  2 +-
  src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp  | 85 
 +++---
  src/mesa/drivers/dri/i965/brw_vec4_generator.cpp |  6 +-
  src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp   | 25 ++-
  src/mesa/program/ir_to_mesa.cpp  | 59 
 +++-
  src/mesa/state_tracker/st_glsl_to_tgsi.cpp   | 63 
 +++--
  18 files changed, 261 insertions(+), 175 deletions(-)
 
 ___
 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 01/11] glapi: add ARB_gpu_shader_fp64

Either this patch or a patch right after it should add the
ProgramUniformd and ProgramUniformMatrix*d functions in
ARB_separate_shader_objects.  These are already in
ARB_separate_shader_objects.xml, but they're all commented out.

On 08/14/2014 03:52 AM, Dave Airlie wrote:
 From: Dave Airlie airl...@redhat.com
 
 Just add the xml file covering this extension,
 and dummy interface files in mesa, and fix up
 sanity tests.
 
 Signed-off-by: Dave Airlie airl...@redhat.com
 ---
  src/mapi/glapi/gen/ARB_gpu_shader_fp64.xml | 143 
 +
  src/mapi/glapi/gen/Makefile.am |   1 +
  src/mapi/glapi/gen/gl_API.xml  |   2 +
  src/mesa/main/tests/dispatch_sanity.cpp|  36 
  src/mesa/main/uniforms.c   |  95 +++
  src/mesa/main/uniforms.h   |  43 +
  6 files changed, 302 insertions(+), 18 deletions(-)
  create mode 100644 src/mapi/glapi/gen/ARB_gpu_shader_fp64.xml
 
 diff --git a/src/mapi/glapi/gen/ARB_gpu_shader_fp64.xml 
 b/src/mapi/glapi/gen/ARB_gpu_shader_fp64.xml
 new file mode 100644
 index 000..4f860ef
 --- /dev/null
 +++ b/src/mapi/glapi/gen/ARB_gpu_shader_fp64.xml
 @@ -0,0 +1,143 @@
 +?xml version=1.0?
 +!DOCTYPE OpenGLAPI SYSTEM gl_API.dtd
 +
 +OpenGLAPI
 +
 +category name=GL_ARB_gpu_shader_fp64 number=89
 +
 +function name=Uniform1d offset=assign
 +param name=location type=GLint/
 +param name=x type=GLdouble/
 +/function
 +
 +function name=Uniform2d offset=assign
 +param name=location type=GLint/
 +param name=x type=GLdouble/
 +param name=y type=GLdouble/
 +/function
 +
 +function name=Uniform3d offset=assign
 +param name=location type=GLint/
 +param name=x type=GLdouble/
 +param name=y type=GLdouble/
 +param name=z type=GLdouble/
 +/function
 +
 +function name=Uniform4d offset=assign
 +param name=location type=GLint/
 +param name=x type=GLdouble/
 +param name=y type=GLdouble/
 +param name=z type=GLdouble/
 +param name=w type=GLdouble/
 +/function
 +
 +function name=Uniform1dv offset=assign
 +param name=location type=GLint/
 +param name=count type=GLsizei/
 +param name=value type=const GLdouble */
 +/function
 +
 +function name=Uniform2dv offset=assign
 +param name=location type=GLint/
 +param name=count type=GLsizei/
 +param name=value type=const GLdouble */
 +/function
 +
 +function name=Uniform3dv offset=assign
 +param name=location type=GLint/
 +param name=count type=GLsizei/
 +param name=value type=const GLdouble */
 +/function
 +
 +function name=Uniform4dv offset=assign
 +param name=location type=GLint/
 +param name=count type=GLsizei/
 +param name=value type=const GLdouble */
 +/function
 +
 +function name=UniformMatrix2dv offset=assign
 +param name=location type=GLint/
 +param name=count type=GLsizei/
 +param name=transpose type=GLboolean/
 +param name=value type=const GLdouble */
 +/function
 +
 +function name=UniformMatrix3dv offset=assign
 +param name=location type=GLint/
 +param name=count type=GLsizei/
 +param name=transpose type=GLboolean/
 +param name=value type=const GLdouble */
 +/function
 +
 +function name=UniformMatrix4dv offset=assign
 +param name=location type=GLint/
 +param name=count type=GLsizei/
 +param name=transpose type=GLboolean/
 +param name=value type=const GLdouble */
 +/function
 +
 +function name=UniformMatrix2x3dv offset=assign
 +param name=location type=GLint/
 +param name=count type=GLsizei/
 +param name=transpose type=GLboolean/
 +param name=value type=const GLdouble */
 +/function
 +
 +function name=UniformMatrix2x4dv offset=assign
 +param name=location type=GLint/
 +param name=count type=GLsizei/
 +param name=transpose type=GLboolean/
 +param name=value type=const GLdouble */
 +/function
 +
 +function name=UniformMatrix3x2dv offset=assign
 +param name=location type=GLint/
 +param name=count type=GLsizei/
 +param name=transpose type=GLboolean/
 +param name=value type=const GLdouble */
 +/function
 +
 +function name=UniformMatrix3x4dv offset=assign
 +param name=location type=GLint/
 +param name=count type=GLsizei/
 +param name=transpose type=GLboolean/
 +param name=value type=const GLdouble */
 +/function
 +
 +function name=UniformMatrix4x2dv offset=assign
 +param name=location type=GLint/
 +param name=count type=GLsizei/
 +param name=transpose type=GLboolean/
 +param name=value type=const GLdouble */
 +/function
 +
 +function name=UniformMatrix4x3dv offset=assign
 +

Re: [Mesa-dev] [PATCH 03/11] mesa: add mesa_type_is_double helper function

On 08/14/2014 03:52 AM, Dave Airlie wrote:
 This is a helper to return if a type is based on a double.
 
 Signed-off-by: Dave Airlie airl...@redhat.com
 ---
  src/mesa/program/prog_parameter.h | 22 ++
  1 file changed, 22 insertions(+)
 
 diff --git a/src/mesa/program/prog_parameter.h 
 b/src/mesa/program/prog_parameter.h
 index 6b3b3c2..9ee0f5e 100644
 --- a/src/mesa/program/prog_parameter.h
 +++ b/src/mesa/program/prog_parameter.h
 @@ -151,6 +151,28 @@ _mesa_lookup_parameter_constant(const struct 
 gl_program_parameter_list *list,
  const gl_constant_value v[], GLuint vSize,
  GLint *posOut, GLuint *swizzleOut);
  
 +static INLINE GLboolean mesa_type_is_double(int dataType)

s/GLboolean/bool/ and

Reviewed-by: Ian Romanick ian.d.roman...@intel.com

 +{
 +   switch (dataType) {
 +   case GL_DOUBLE:
 +   case GL_DOUBLE_VEC2:
 +   case GL_DOUBLE_VEC3:
 +   case GL_DOUBLE_VEC4:
 +   case GL_DOUBLE_MAT2:
 +   case GL_DOUBLE_MAT2x3:
 +   case GL_DOUBLE_MAT2x4:
 +   case GL_DOUBLE_MAT3:
 +   case GL_DOUBLE_MAT3x2:
 +   case GL_DOUBLE_MAT3x4:
 +   case GL_DOUBLE_MAT4:
 +   case GL_DOUBLE_MAT4x2:
 +   case GL_DOUBLE_MAT4x3:
 +  return GL_TRUE;
 +   default:
 +  return GL_FALSE;
 +   }
 +}
 +
  #ifdef __cplusplus
  }
  #endif
 

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

Re: [Mesa-dev] [PATCH 06/11] glsl: add ARB_gpu_shader_fp64 to the glsl extensions.

This patch is

Reviewed-by: Ian Romanick ian.d.roman...@intel.com

On 08/14/2014 03:52 AM, Dave Airlie wrote:
 From: Dave Airlie airl...@redhat.com
 
 Signed-off-by: Dave Airlie airl...@redhat.com
 ---
  src/glsl/glsl_parser_extras.cpp | 1 +
  src/glsl/glsl_parser_extras.h   | 2 ++
  src/glsl/standalone_scaffolding.cpp | 1 +
  3 files changed, 4 insertions(+)
 
 diff --git a/src/glsl/glsl_parser_extras.cpp b/src/glsl/glsl_parser_extras.cpp
 index ad91c46..53fbb25 100644
 --- a/src/glsl/glsl_parser_extras.cpp
 +++ b/src/glsl/glsl_parser_extras.cpp
 @@ -521,6 +521,7 @@ static const _mesa_glsl_extension 
 _mesa_glsl_supported_extensions[] = {
 EXT(ARB_fragment_coord_conventions, true,  false, 
 ARB_fragment_coord_conventions),
 EXT(ARB_fragment_layer_viewport,true,  false, 
 ARB_fragment_layer_viewport),
 EXT(ARB_gpu_shader5,true,  false, ARB_gpu_shader5),
 +   EXT(ARB_gpu_shader_fp64,true,  false, 
 ARB_gpu_shader_fp64),
 EXT(ARB_sample_shading, true,  false, ARB_sample_shading),
 EXT(ARB_separate_shader_objects,true,  false, dummy_true),
 EXT(ARB_shader_atomic_counters, true,  false, 
 ARB_shader_atomic_counters),
 diff --git a/src/glsl/glsl_parser_extras.h b/src/glsl/glsl_parser_extras.h
 index ce66e2f..6f5c0b1 100644
 --- a/src/glsl/glsl_parser_extras.h
 +++ b/src/glsl/glsl_parser_extras.h
 @@ -407,6 +407,8 @@ struct _mesa_glsl_parse_state {
 bool ARB_fragment_layer_viewport_warn;
 bool ARB_gpu_shader5_enable;
 bool ARB_gpu_shader5_warn;
 +   bool ARB_gpu_shader_fp64_enable;
 +   bool ARB_gpu_shader_fp64_warn;
 bool ARB_sample_shading_enable;
 bool ARB_sample_shading_warn;
 bool ARB_separate_shader_objects_enable;
 diff --git a/src/glsl/standalone_scaffolding.cpp 
 b/src/glsl/standalone_scaffolding.cpp
 index 2b76dd1..63e3cde 100644
 --- a/src/glsl/standalone_scaffolding.cpp
 +++ b/src/glsl/standalone_scaffolding.cpp
 @@ -100,6 +100,7 @@ void initialize_context_to_defaults(struct gl_context 
 *ctx, gl_api api)
 ctx-Extensions.ARB_fragment_coord_conventions = true;
 ctx-Extensions.ARB_fragment_layer_viewport = true;
 ctx-Extensions.ARB_gpu_shader5 = true;
 +   ctx-Extensions.ARB_gpu_shader_fp64 = true;
 ctx-Extensions.ARB_sample_shading = true;
 ctx-Extensions.ARB_shader_bit_encoding = true;
 ctx-Extensions.ARB_shader_stencil_export = true;
 

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

[Mesa-dev] [PATCH] auxilary/os: Add Solaris support in os_get_total_physical_memory.

2014-08-22 Thread Vinson Lee

The patch fixes the build on Oracle Solaris.

  CC os/os_misc.lo
os/os_misc.c, line 59: #error: unexpected platform in os_sysinfo.c

Signed-off-by: Vinson Lee v...@freedesktop.org
---
 src/gallium/auxiliary/os/os_misc.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/gallium/auxiliary/os/os_misc.c 
b/src/gallium/auxiliary/os/os_misc.c
index ef84c79..4c5a22d 100644
--- a/src/gallium/auxiliary/os/os_misc.c
+++ b/src/gallium/auxiliary/os/os_misc.c
@@ -47,7 +47,7 @@
 #endif
 
 
-#if defined(PIPE_OS_LINUX) || defined(PIPE_OS_CYGWIN)
+#if defined(PIPE_OS_LINUX) || defined(PIPE_OS_CYGWIN) || 
defined(PIPE_OS_SOLARIS)
 #  include unistd.h
 #elif defined(PIPE_OS_APPLE) || defined(PIPE_OS_BSD)
 #  include sys/sysctl.h
@@ -111,7 +111,7 @@ os_get_option(const char *name)
 bool
 os_get_total_physical_memory(uint64_t *size)
 {
-#if defined(PIPE_OS_LINUX) || defined(PIPE_OS_CYGWIN)
+#if defined(PIPE_OS_LINUX) || defined(PIPE_OS_CYGWIN) || 
defined(PIPE_OS_SOLARIS)
const long phys_pages = sysconf(_SC_PHYS_PAGES);
const long page_size = sysconf(_SC_PAGE_SIZE);
 
-- 
1.7.9.2

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

Re: [Mesa-dev] [PATCH 07/11] glsl: add double support

There is a handful of minor comments below.

There is one additional thing missing: handling doubles in UBOs.  Many
places in the linker (a bunch of which I just changed) assume, for
alignment purposes, that every basic type is 4-bytes.  Several places in
the std140 packing rules say things like ...rounded up to the base
alignment of a vec4.  In most of those places we just set the alignment
to 16 because it will be. :)  With dvec4, the alignment could be 32 instead.

I think we can punt on that for a little bit.  I'm putting together a
random UBO test generator that should hit all the cases.  I hope to
have that out on the piglit list next week.

On 08/14/2014 03:52 AM, Dave Airlie wrote:
 This adds the guts of the fp64 implementation to the GLSL compiler.
 
 - builtin double types
 - double constant support
 - lexer parsing for double types (lf, LF)
 - enforcing flat on double fs inputs
 - double operations (d2f,f2d, pack/unpack, frexp - in 2 parts)
 - ir builder bits.
 - double constant expression handling
 
 Signed-off-by: Dave Airlie airl...@redhat.com
 ---
  src/glsl/ast.h |   2 +
  src/glsl/ast_function.cpp  |  36 ++
  src/glsl/ast_to_hir.cpp|  28 -
  src/glsl/builtin_type_macros.h |  16 +++
  src/glsl/builtin_types.cpp |  30 +
  src/glsl/glsl_lexer.ll |  42 ++-
  src/glsl/glsl_parser.yy|  33 +-
  src/glsl/glsl_parser_extras.cpp|   4 +
  src/glsl/glsl_types.cpp|  74 ++--
  src/glsl/glsl_types.h  |  18 ++-
  src/glsl/ir.cpp|  90 +-
  src/glsl/ir.h  |  17 +++
  src/glsl/ir_builder.cpp|  11 ++
  src/glsl/ir_builder.h  |   3 +
  src/glsl/ir_clone.cpp  |   1 +
  src/glsl/ir_constant_expression.cpp| 207 
 -
  src/glsl/ir_print_visitor.cpp  |  11 ++
  src/glsl/ir_set_program_inouts.cpp |  24 +++-
  src/glsl/ir_validate.cpp   |  45 ++-
  src/glsl/link_uniform_initializers.cpp |   4 +
  src/glsl/link_uniforms.cpp |   2 +
  src/glsl/link_varyings.cpp |   3 +-
  src/mesa/program/ir_to_mesa.cpp|   6 +
  23 files changed, 641 insertions(+), 66 deletions(-)
 
 diff --git a/src/glsl/ast.h b/src/glsl/ast.h
 index 15bf086..99274ed 100644
 --- a/src/glsl/ast.h
 +++ b/src/glsl/ast.h
 @@ -189,6 +189,7 @@ enum ast_operators {
 ast_uint_constant,
 ast_float_constant,
 ast_bool_constant,
 +   ast_double_constant,
  
 ast_sequence,
 ast_aggregate
 @@ -236,6 +237,7 @@ public:
float float_constant;
unsigned uint_constant;
int bool_constant;
 +  double double_constant;
 } primary_expression;
  
  
 diff --git a/src/glsl/ast_function.cpp b/src/glsl/ast_function.cpp
 index 39c7bee..6169ae6 100644
 --- a/src/glsl/ast_function.cpp
 +++ b/src/glsl/ast_function.cpp
 @@ -570,6 +570,10 @@ convert_component(ir_rvalue *src, const glsl_type 
 *desired_type)
result = new(ctx) ir_expression(ir_unop_i2u,
 new(ctx) ir_expression(ir_unop_b2i, src));
break;
 +  case GLSL_TYPE_DOUBLE:
 +  result = new(ctx) ir_expression(ir_unop_f2u,
 +  new(ctx) ir_expression(ir_unop_d2f, src));
 +  break;
}
break;
 case GLSL_TYPE_INT:
 @@ -583,6 +587,10 @@ convert_component(ir_rvalue *src, const glsl_type 
 *desired_type)
case GLSL_TYPE_BOOL:
result = new(ctx) ir_expression(ir_unop_b2i, src);
break;
 +  case GLSL_TYPE_DOUBLE:
 +  result = new(ctx) ir_expression(ir_unop_f2i,
 +  new(ctx) ir_expression(ir_unop_d2f, src));

Don't we just want an ir_unop_d2i?  There are values that can be exactly
represented in a double and a 32-bit integer that cannot be represented
in a float... right?

 +  break;
}
break;
 case GLSL_TYPE_FLOAT:
 @@ -596,6 +604,9 @@ convert_component(ir_rvalue *src, const glsl_type 
 *desired_type)
case GLSL_TYPE_BOOL:
result = new(ctx) ir_expression(ir_unop_b2f, desired_type, src, NULL);
break;
 +  case GLSL_TYPE_DOUBLE:
 +  result = new(ctx) ir_expression(ir_unop_d2f, desired_type, src, NULL);
 +  break;
}
break;
 case GLSL_TYPE_BOOL:
 @@ -610,8 +621,30 @@ convert_component(ir_rvalue *src, const glsl_type 
 *desired_type)
case GLSL_TYPE_FLOAT:
result = new(ctx) ir_expression(ir_unop_f2b, desired_type, src, NULL);
break;
 +  case GLSL_TYPE_DOUBLE:
 +  result = new(ctx) ir_expression(ir_unop_f2b,
 +  new(ctx) ir_expression(ir_unop_d2f, src));
 +  break;
}
break;
 +   case GLSL_TYPE_DOUBLE:
 +  switch (b) {
 +  case GLSL_TYPE_INT:
 + result = new(ctx) ir_expression(ir_unop_f2d,
 +  new(ctx) ir_expression(ir_unop_i2f,

Re: [Mesa-dev] [PATCH] auxilary/os: Add Solaris support in os_get_total_physical_memory.

2014-08-22 Thread Emil Velikov

On 23/08/14 01:28, Vinson Lee wrote:
 The patch fixes the build on Oracle Solaris.
 
   CC os/os_misc.lo
 os/os_misc.c, line 59: #error: unexpected platform in os_sysinfo.c
 
Does mesa even run on Solaris or is this just to silence the buildbot ?

FWIW Reviewed-by: Emil Velikov emil.l.veli...@gmail.com

 Signed-off-by: Vinson Lee v...@freedesktop.org
 ---
  src/gallium/auxiliary/os/os_misc.c |4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/src/gallium/auxiliary/os/os_misc.c 
 b/src/gallium/auxiliary/os/os_misc.c
 index ef84c79..4c5a22d 100644
 --- a/src/gallium/auxiliary/os/os_misc.c
 +++ b/src/gallium/auxiliary/os/os_misc.c
 @@ -47,7 +47,7 @@
  #endif
  
  
 -#if defined(PIPE_OS_LINUX) || defined(PIPE_OS_CYGWIN)
 +#if defined(PIPE_OS_LINUX) || defined(PIPE_OS_CYGWIN) || 
 defined(PIPE_OS_SOLARIS)
  #  include unistd.h
  #elif defined(PIPE_OS_APPLE) || defined(PIPE_OS_BSD)
  #  include sys/sysctl.h
 @@ -111,7 +111,7 @@ os_get_option(const char *name)
  bool
  os_get_total_physical_memory(uint64_t *size)
  {
 -#if defined(PIPE_OS_LINUX) || defined(PIPE_OS_CYGWIN)
 +#if defined(PIPE_OS_LINUX) || defined(PIPE_OS_CYGWIN) || 
 defined(PIPE_OS_SOLARIS)
 const long phys_pages = sysconf(_SC_PHYS_PAGES);
 const long page_size = sysconf(_SC_PAGE_SIZE);
  
 

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

Re: [Mesa-dev] [PATCH 05/11] mesa: add double uniform support.

It's hard to tell from just the patch whether this restriction is
enforced:

(15) Can the 64-bit uniform APIs be used to load values for uniforms of
 type bool, bvec2, bvec3, or bvec4?

  RESOLVED:  No.  OpenGL 2.0 and beyond did allow bool variable to be
  set with Uniform*i* and Uniform*f APIs, and OpenGL 3.0 extended that
  support to Uniform*ui* for orthogonality.  But it seems pointless to
  extended this capability forward to 64-bit Uniform APIs as well.


On 08/14/2014 03:52 AM, Dave Airlie wrote:
 From: Dave Airlie airl...@redhat.com
 
 This adds support for the new uniform interfaces
 from ARB_gpu_shader_fp64.
 
 Signed-off-by: Dave Airlie airl...@redhat.com
 ---
  src/mesa/main/uniform_query.cpp   | 50 +
  src/mesa/main/uniforms.c  | 91 
 +++
  src/mesa/main/uniforms.h  |  3 +-
  src/mesa/program/ir_to_mesa.cpp   | 17 +++-
  src/mesa/program/prog_parameter.c | 16 ---
  5 files changed, 143 insertions(+), 34 deletions(-)
 
 diff --git a/src/mesa/main/uniform_query.cpp b/src/mesa/main/uniform_query.cpp
 index 7e630e6..d7024cb 100644
 --- a/src/mesa/main/uniform_query.cpp
 +++ b/src/mesa/main/uniform_query.cpp
 @@ -449,6 +449,9 @@ log_uniform(const void *values, enum glsl_base_type 
 basicType,
case GLSL_TYPE_FLOAT:
printf(%g , v[i].f);
break;
 +  case GLSL_TYPE_DOUBLE:
 +  printf(%g , *(double* )v[i * 2].f);
 +  break;
default:
assert(!Should not get here.);
break;
 @@ -509,11 +512,11 @@ _mesa_propagate_uniforms_to_driver_storage(struct 
 gl_uniform_storage *uni,
  */
 const unsigned components = MAX2(1, uni-type-vector_elements);
 const unsigned vectors = MAX2(1, uni-type-matrix_columns);
 -
 +   const int dmul = uni-type-base_type == GLSL_TYPE_DOUBLE ? 2 : 1;
 /* Store the data in the driver's requested type in the driver's storage
  * areas.
  */
 -   unsigned src_vector_byte_stride = components * 4;
 +   unsigned src_vector_byte_stride = components * 4 * dmul;
  
 for (i = 0; i  uni-num_driver_storage; i++) {
struct gl_uniform_driver_storage *const store = 
 uni-driver_storage[i];
 @@ -612,6 +615,7 @@ _mesa_uniform(struct gl_context *ctx, struct 
 gl_shader_program *shProg,
 unsigned components;
 unsigned src_components;
 enum glsl_base_type basicType;
 +   int size_mul = 1;
  
 struct gl_uniform_storage *const uni =
validate_uniform_parameters(ctx, shProg, location, count,
 @@ -670,6 +674,26 @@ _mesa_uniform(struct gl_context *ctx, struct 
 gl_shader_program *shProg,
basicType = GLSL_TYPE_INT;
src_components = 4;
break;
 +   case GL_DOUBLE:
 +  basicType = GLSL_TYPE_DOUBLE;
 +  src_components = 1;
 +  size_mul = 2;
 +  break;
 +   case GL_DOUBLE_VEC2:
 +  basicType = GLSL_TYPE_DOUBLE;
 +  src_components = 2;
 +  size_mul = 2;
 +  break;
 +   case GL_DOUBLE_VEC3:
 +  basicType = GLSL_TYPE_DOUBLE;
 +  src_components = 3;
 +  size_mul = 2;
 +  break;
 +   case GL_DOUBLE_VEC4:
 +  basicType = GLSL_TYPE_DOUBLE;
 +  src_components = 4;
 +  size_mul = 2;
 +  break;
 case GL_BOOL:
 case GL_BOOL_VEC2:
 case GL_BOOL_VEC3:
 @@ -683,6 +707,15 @@ _mesa_uniform(struct gl_context *ctx, struct 
 gl_shader_program *shProg,
 case GL_FLOAT_MAT4x2:
 case GL_FLOAT_MAT4x3:
 case GL_FLOAT_MAT4:
 +   case GL_DOUBLE_MAT2:
 +   case GL_DOUBLE_MAT2x3:
 +   case GL_DOUBLE_MAT2x4:
 +   case GL_DOUBLE_MAT3x2:
 +   case GL_DOUBLE_MAT3:
 +   case GL_DOUBLE_MAT3x4:
 +   case GL_DOUBLE_MAT4x2:
 +   case GL_DOUBLE_MAT4x3:
 +   case GL_DOUBLE_MAT4:
 default:
_mesa_problem(NULL, Invalid type in %s, __func__);
return;
 @@ -789,7 +822,7 @@ _mesa_uniform(struct gl_context *ctx, struct 
 gl_shader_program *shProg,
  */
 if (!uni-type-is_boolean()) {
memcpy(uni-storage[components * offset], values,
 -  sizeof(uni-storage[0]) * components * count);
 +  sizeof(uni-storage[0]) * components * count * size_mul);
 } else {
const union gl_constant_value *src =
(const union gl_constant_value *) values;
 @@ -892,13 +925,14 @@ extern C void
  _mesa_uniform_matrix(struct gl_context *ctx, struct gl_shader_program 
 *shProg,
GLuint cols, GLuint rows,
   GLint location, GLsizei count,
 - GLboolean transpose, const GLfloat *values)
 + GLboolean transpose,
 + const GLvoid *values, GLenum type)
  {
 unsigned offset;
 unsigned vectors;
 unsigned components;
 unsigned elements;
 -
 +   int size_mul = mesa_type_is_double(type) ? 2 : 1;
 struct gl_uniform_storage *const uni =
validate_uniform_parameters(ctx, shProg, location, count,
offset, glUniformMatrix, false);
 @@ -936,7 +970,7 @@

Re: [Mesa-dev] [PATCH 02/11] mesa: add ARB_gpu_shader_fp64 extension info

On 08/14/2014 03:52 AM, Dave Airlie wrote:
 From: Dave Airlie airl...@redhat.com
 
 This just adds the entries to extensions.c and mtypes.h
 
 Signed-off-by: Dave Airlie airl...@redhat.com
 ---
  src/mesa/main/extensions.c | 1 +
  src/mesa/main/mtypes.h | 1 +
  2 files changed, 2 insertions(+)
 
 diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
 index 4f322d0..1445a9d 100644
 --- a/src/mesa/main/extensions.c
 +++ b/src/mesa/main/extensions.c
 @@ -117,6 +117,7 @@ static const struct extension extension_table[] = {
 { GL_ARB_framebuffer_sRGB,o(EXT_framebuffer_sRGB),  
   GL, 1998 },
 { GL_ARB_get_program_binary,  o(dummy_true),
   GL, 2010 },
 { GL_ARB_gpu_shader5, o(ARB_gpu_shader5),   
   GL, 2010 },
 +   { GL_ARB_gpu_shader_fp64, o(ARB_gpu_shader_fp64),   
   GL, 2010 },
 { GL_ARB_half_float_pixel,o(dummy_true),
   GL, 2003 },
 { GL_ARB_half_float_vertex,   o(ARB_half_float_vertex), 
   GL, 2008 },
 { GL_ARB_instanced_arrays,o(ARB_instanced_arrays),  
   GL, 2008 },

The extension spec says, OpenGL 3.2 and GLSL 1.50 are required.  Many
times these requirements are excessive... and there just because people
didn't want to think about the interactions with older versions. :)  In
this case, however, I think it's reasonable.  In GLSL 1.50 the rules
about where interpolation qualifiers were specified changed.  The last
bit of issue 9 alludes to this.

(9) Are double-precision varyings (values passed between shader stages)
supported by this extension?  If so, is double-precision interpolation
is supported?

  RESOLVED:  Double-precision shader inputs and outputs are supported,
  except for vertex shader inputs and fragment shader outputs.
  Additionally, double-precision vertex shader inputs are provided by the
  separate extension EXT_vertex_attrib_64bit.  No known extension provides
  double-precision fragment outputs, but that doesn't seem important since
  OpenGL provides no pixel/texture formats with double-precision
  components that could reasonably receive such outputs.

  Interpolation not supported in this extension for double-precision
  floating-point components.  As with integer types in OpenGL 3.0,
  double-precision floating-point fragment shader inputs must be qualified
  as flat.

  Note that this extension reformulates the spec language requiring flat
  qualifiers, in addition to adding doubles to the list of flat types.
  In GLSL 1.30, the spec applies these requirements to vertex shader
  outputs but imposes no requirement on fragment inputs.  We move this
  requirement to fragment inputs, since vertex shader outputs may be
  passed to tessellation or geometry shaders without interpolation, and
  thus without the need for qualification by flat.

Because of this, it seems like we should restrict this extension to
core profile.  Opinions?

 diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
 index 742ce3e..121f2ea 100644
 --- a/src/mesa/main/mtypes.h
 +++ b/src/mesa/main/mtypes.h
 @@ -3572,6 +3572,7 @@ struct gl_extensions
 GLboolean ARB_explicit_uniform_location;
 GLboolean ARB_geometry_shader4;
 GLboolean ARB_gpu_shader5;
 +   GLboolean ARB_gpu_shader_fp64;
 GLboolean ARB_half_float_vertex;
 GLboolean ARB_instanced_arrays;
 GLboolean ARB_internalformat_query;
 

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

[Mesa-dev] [Bug 82978] New: [swrast] piglit glsl-uniform-initializer-6 regression