Re: [Mesa-dev] [PATCH 07/12] i965/cnl: Restore lossless compression for sRGB formats

2017-04-15 Thread Jason Ekstrand 

On April 14, 2017 5:37:55 PM Anuj Phogat  wrote:


From: Ben Widawsky 

This support was removed on gen9 (it worked before then) and was brought back
for gen10.

Signed-off-by: Ben Widawsky 
---
 src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c

index 467ada5..c8014b9 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -207,7 +207,7 @@ intel_miptree_supports_non_msrt_fast_clear(struct 
brw_context *brw,

if (!brw->format_supported_as_render_target[mt->format])
   return false;

-   if (brw->gen >= 9) {
+   if (brw->gen == 9) {
   mesa_format linear_format = _mesa_get_srgb_format_linear(mt->format);
   const uint32_t brw_format = 
brw_isl_format_for_mesa_format(linear_format);
   return isl_format_supports_ccs_e(>screen->devinfo, brw_format);


I thought sRGB was supported for CCS_E on CNL.  If so, we should update the 
table in isl_format_supports_ccs_e().  Also, I believe sRGB is supported 
for CCS_D even on sky lake, you just can't sample from it.



--
2.9.3

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



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

Re: [Mesa-dev] [PATCH 03/12] i965/cnl: Update the script generating genX_bits.h

2017-04-15 Thread Jason Ekstrand 

On April 14, 2017 5:37:16 PM Anuj Phogat  wrote:


Signed-off-by: Anuj Phogat 
---
 src/intel/genxml/gen_bits_header.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/intel/genxml/gen_bits_header.py 
b/src/intel/genxml/gen_bits_header.py

index 808e6cf..77cd966 100644
--- a/src/intel/genxml/gen_bits_header.py
+++ b/src/intel/genxml/gen_bits_header.py
@@ -84,6 +84,7 @@ static inline uint32_t ATTRIBUTE_PURE
 ${field.token_name}(const struct gen_device_info *devinfo)
 {
switch (devinfo->gen) {
+   case 10: return ${field.bits(10)};
case 9: return ${field.bits(9)};
case 8: return ${field.bits(8)};
case 7:
@@ -151,8 +152,7 @@ class Gen(object):
 def __init__(self, z):
 # Convert potential "major.minor" string
 z = float(z)
-if z < 10:
-z *= 10
+z *= 10
 self.tenx = int(z)


While we're here, we might as well just make this

self.tenx = int(float(z) * 10)

With that,

Reviewed-by: Jason Ekstrand 



 def __lt__(self, other):
--
2.9.3

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



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

Re: [Mesa-dev] [PATCH v3 1/4] gallium: Enable ARM NEON CPU detection.

2017-04-15 Thread Grazvydas Ignotas 
On Fri, Apr 14, 2017 at 8:47 PM, Eric Anholt  wrote:

> I wrote this code with reference to pixman, though I've only decided to
> cover Linux (what I'm testing) and Android (seems obvious enough).  Linux
> has getauxval() as a cleaner interface to the /proc entry, but it's more
> glibc-specific and I didn't want to add detection for that.
>
> This will be used to enable NEON at runtime on ARMv6 builds of vc4.
>
> v2: Actually initialize the temp vars in the Android path (noticed by
> daniels)
> v3: Actually pull in the cpufeatures library (change by robher).  Use
> O_CLOEXEC.  Break out of the loop when we find our feature.  Only do
> NEON detection, until someone actually wants VFP features.
>

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

Re: [Mesa-dev] [PATCH v3 4/4] vc4: Only build the NEON code on arm32.

2017-04-15 Thread Grazvydas Ignotas 
On Fri, Apr 14, 2017 at 8:47 PM, Eric Anholt  wrote:

> NEON is sufficiently different on arm64 that we can't just reuse this
> code.  Disable it on arm64 for now.
>
> Signed-off-by: Eric Anholt 
> ---
>  src/gallium/drivers/vc4/vc4_tiling_lt.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/vc4/vc4_tiling_lt.c
> b/src/gallium/drivers/vc4/vc4_tiling_lt.c
> index c9cbc65e2dbc..7de67b652daa 100644
> --- a/src/gallium/drivers/vc4/vc4_tiling_lt.c
> +++ b/src/gallium/drivers/vc4/vc4_tiling_lt.c
> @@ -61,7 +61,7 @@ static void
>  vc4_load_utile(void *cpu, void *gpu, uint32_t cpu_stride, uint32_t cpp)
>  {
>  uint32_t gpu_stride = vc4_utile_stride(cpp);
> -#if defined(VC4_BUILD_NEON) && defined(__ARM_ARCH)
> +#if defined(VC4_BUILD_NEON) && defined(__ARM_ARCH) && __ARM_ARCH <= 7
>

This doesn't look right, __ARM_ARCH can be 8 on 32bit, try -mcpu=cortex-a57
on a 32bit toolchain for example. Could use PIPE_ARCH_ARM I guess, or
!PIPE_ARCH_AARCH64, or maybe use the intrinsics...

Gražvydas

 if (gpu_stride == 8) {
>  __asm__ volatile (
>  /* Load from the GPU in one shot, no interleave,
> to
> @@ -118,7 +118,7 @@ vc4_store_utile(void *gpu, void *cpu, uint32_t
> cpu_stride, uint32_t cpp)
>  {
>  uint32_t gpu_stride = vc4_utile_stride(cpp);
>
> -#if defined(VC4_BUILD_NEON) && defined(__ARM_ARCH)
> +#if defined(VC4_BUILD_NEON) && defined(__ARM_ARCH) && __ARM_ARCH <= 7
>  if (gpu_stride == 8) {
>  __asm__ volatile (
>  /* Load each 8-byte line from cpu-side source,
> --
> 2.11.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] android: amd/addrlib: trivial fix for gfx9 support

2017-04-15 Thread Mauro Rossi 
2017-04-03 10:37 GMT+02:00 Nicolai Hähnle :

> On 01.04.2017 12:48, Mauro Rossi wrote:
>
>> Fixes the following build error:
>>
>> external/mesa/src/amd/addrlib/gfx9/gfx9addrlib.cpp:36:10: fatal error:
>> 'gfx9_gb_reg.h' file not found
>>  ^
>> 1 error generated.
>>
>> Fixes: 7f160ef "amd/addrlib: import gfx9 support"
>>
>
> Reviewed-by: Nicolai Hähnle 
>
> ---
>>  src/amd/Android.addrlib.mk | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/src/amd/Android.addrlib.mk b/src/amd/Android.addrlib.mk
>> index d296ce0431c..540de5554bd 100644
>> --- a/src/amd/Android.addrlib.mk
>> +++ b/src/amd/Android.addrlib.mk
>> @@ -37,7 +37,9 @@ LOCAL_C_INCLUDES := \
>> $(MESA_TOP)/src/amd/common \
>> $(MESA_TOP)/src/amd/addrlib \
>> $(MESA_TOP)/src/amd/addrlib/core \
>> +   $(MESA_TOP)/src/amd/addrlib/inc/chip/gfx9 \
>> $(MESA_TOP)/src/amd/addrlib/inc/chip/r800 \
>> +   $(MESA_TOP)/src/amd/addrlib/gfx9/chip \
>> $(MESA_TOP)/src/amd/addrlib/r800/chip
>>
>>  include $(MESA_COMMON_MK)
>>
>>
>
> --
> Lerne, wie die Welt wirklich ist,
> Aber vergiss niemals, wie sie sein sollte.
>

I'm sending a kind reminder for commit before 17.1 final release (there is
still time)
and I wish happy Easter to all develeopers and contributors
Cheers

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

[Mesa-dev] [Bug 100690] [Regression, bisected] TotalWar: Warhammer corrupted graphics

2017-04-15 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=100690

Bug ID: 100690
   Summary: [Regression, bisected] TotalWar: Warhammer corrupted
graphics
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Mesa core
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: gr.mue...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org

Created attachment 130856
  --> https://bugs.freedesktop.org/attachment.cgi?id=130856=edit
notice the red squares, which shouldnt be there

Worldmap in TotalWar shows some fancy colors.
Radeon HD 7970, LLVM 5.0.0svn_r300398

c5bf7cb52942cb7df9f5d73746ffbf3c102d12cc is the first bad commit
commit c5bf7cb52942cb7df9f5d73746ffbf3c102d12cc
Author: Kenneth Graunke 
Date:   Thu Feb 23 15:04:52 2017 -0800

mesa: Require mipmap completeness for glCopyImageSubData(), sometimes.

This patch makes glCopyImageSubData require mipmap completeness when the
texture object's built-in sampler object has a mipmapping MinFilter.

Fixes (on i965):
dEQP-GLES31.functional.debug.negative_coverage.*.buffer.copy_image_sub_data

Reviewed-by: Roland Scheidegger 

git bisect log
git bisect start
# bad: [667da4eaed37de143681711344aba19373bee1d0] winsys/amdgpu: sparse buffer
creation / destruction / commitment
git bisect bad 667da4eaed37de143681711344aba19373bee1d0
# good: [7ee91af30074a4381e4353122319e3b4b3fe7cbd] r600g: check NULL return
from r600_aligned_buffer_create
git bisect good 7ee91af30074a4381e4353122319e3b4b3fe7cbd
# good: [e113dfabad5c60ce3082c65abe3b2e5689bdf31b] intel: Add INTEL_CFLAGS to
aubinator CFLAGS.
git bisect good e113dfabad5c60ce3082c65abe3b2e5689bdf31b
# good: [03a67fbbf7847cbdcc26b3bd86ee43e09a55cce9] radv: fix order of the
guardband register emission.
git bisect good 03a67fbbf7847cbdcc26b3bd86ee43e09a55cce9
# good: [3dfe61ed6ec6773c2373ec7a139b7dfe794f60c8] gallium: decrease the size
of pipe_box - 24 -> 16 bytes
git bisect good 3dfe61ed6ec6773c2373ec7a139b7dfe794f60c8
# bad: [c6f69eea6ac549fc2ffa46944de4dd82c9b53329] anv/pipeline: Properly handle
unset gl_Layer and gl_ViewportIndex
git bisect bad c6f69eea6ac549fc2ffa46944de4dd82c9b53329
# good: [18b12bf53351e1a902dc1f2e527a94ec8d8f3eff] targets: export radeon
winsys_create functions to silence LLVM warning
git bisect good 18b12bf53351e1a902dc1f2e527a94ec8d8f3eff
# good: [567d77885e8579486354843e7280428dc96d4bd9] intel: genxml: add
RING_BUFFER_CTL registers
git bisect good 567d77885e8579486354843e7280428dc96d4bd9
# good: [1fde054b8f8435706d567d0584c44f9fc686a97c] intel/isl: Refactor and
clerify gen8 alignment calculations
git bisect good 1fde054b8f8435706d567d0584c44f9fc686a97c
# bad: [c5bf7cb52942cb7df9f5d73746ffbf3c102d12cc] mesa: Require mipmap
completeness for glCopyImageSubData(), sometimes.
git bisect bad c5bf7cb52942cb7df9f5d73746ffbf3c102d12cc
# good: [c161a104629ad49dc6a4f7d1fe82e87fc08121fe] libgl-xlib: Link with
libunwind.
git bisect good c161a104629ad49dc6a4f7d1fe82e87fc08121fe
# first bad commit: [c5bf7cb52942cb7df9f5d73746ffbf3c102d12cc] mesa: Require
mipmap completeness for glCopyImageSubData(), sometimes.

Verified bad commit with:
git revert c5bf7cb52942cb7df9f5d73746ffbf3c102d12cc

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

Re: [Mesa-dev] [PATCH v2 3/4] mesa: move glMultiDrawArrays to vbo and fix error handling

2017-04-15 Thread Nils Wallménius 
Hi Nicolai,

Re-replying as I seem to have messed up the quoting. Anyway a question
about a loop index below.

Den 13 apr. 2017 21:29 skrev "Nicolai Hähnle" :

From: Nicolai Hähnle 

[snip]


+/**
+ * Called to error check the function parameters.

+ *
+ * Note that glMultiDrawArrays is not part of GLES, so there's limited
scope
+ * for sharing code with the validation of glDrawArrays.
+ */
+bool
+_mesa_validate_MultiDrawArrays(struct gl_context *ctx, GLenum mode,
+   const GLsizei *count, GLsizei primcount)
+{
+   int i;
+
+   FLUSH_CURRENT(ctx, 0);
+
+   if (!_mesa_valid_prim_mode(ctx, mode, "glMultiDrawArrays"))
+  return false;
+
+   if (!check_valid_to_render(ctx, "glMultiDrawArrays"))
+  return false;
+
+   if (primcount < 0) {
+  _mesa_error(ctx, GL_INVALID_VALUE, "glMultiDrawArrays(primcount=%d)",
+  primcount);
+  return false;
+   }
+
+   for (i = 0; i < primcount; ++i) {
+  if (count[i] < 0) {
+ _mesa_error(ctx, GL_INVALID_VALUE, "glMultiDrawArrays(count[%d]=%
d)",
+ i, count[i]);
+ return false;
+  }
+   }
+
+   if (need_xfb_remaining_prims_check(ctx)) {
+  struct gl_transform_feedback_object *xfb_obj
+ = ctx->TransformFeedback.CurrentObject;
+  size_t prim_count = 0;
+
+  for (i = 0; i < prim_count; ++i)
+ prim_count += vbo_count_tessellated_primitives(mode, count[i], 1);


As prim_count is 0 the above loop will iterate 0 times, perhaps a mixup
with primcount?

BR
Nils

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

Re: [Mesa-dev] [PATCH v4 0/3] asynchronous pbo transfer with glthread

2017-04-15 Thread gregory hainaut 
On Sat, 15 Apr 2017 00:50:15 +0200
Dieter Nützel  wrote:

> Am 14.04.2017 07:53, schrieb gregory hainaut:
> > On Fri, 14 Apr 2017 05:20:38 +0200
> > Dieter Nützel  wrote:
> > 
> >> Am 14.04.2017 02:06, schrieb Dieter Nützel:
> >> > Hello Gregory,
> >> >
> >> > have you tested this with Mesa-demos/tests/pbo 'b' (benchmark)?
> >> > It result in crazy numbers and do not 'return' (one core stays @ 100%).
> >> 
> >> This is related to 'mesa_glthread=true'.
> >> If I disable (unset) it, all is fine after 'b' benchmark and 'pbo' 
> >> exit
> >> with ESC as expeted.
> >> Crazy numbers stay, maybe counter overrun due to BIG numbers? ;-)
> >> 
> >> Hope that helps.
> >> 
> >> Dieter
> > 
> > Hello Dieter,
> > 
> > I tested the demo. There is a pseudo unrelated bug on the exit of the
> > application.
> > 
> > Mesa 17.1.0-devel implementation error: In _mesa_DeleteHashTable,
> > found non-freed data
> > 
> > I will add a call to a _mesa_HashDeleteAll to fix it.
> > i.e. _mesa_HashDeleteAll(shared->ShadowBufferObjects, dummy_cb, ctx);
> > 
> > Now let's go back to the test behavior. The benchmarks will send 4s of
> > asynchronous PBO transfer commands. And then will sync gl_thread which
> > mean the application thread will be blocked until all PBO transfers are
> > done. Gl_thread is faster to dispatch command so you will need to wait
> > more before the thread goes back to real life.
> > 
> > On my side, I need to wait around 45 seconds for 6 millions of 
> > commands.
> > Result:  6,440,627 reads (gl thread on + PBO patches)
> > Result:274,960 reads (gl thread off)
> > 
> > In your case, "Result:  77,444,412 reads", I hope you're patient.
> > I think you must wait at least 10 minutes.
> 
> Now, I was patient...
> Tried 2 times but after ~20 minutes I've killed it at first and attached 
> gdb at it during second run.
> 
> 0x7fbda686e9a6 in pthread_cond_wait@@GLIBC_2.3.2 () from 
> /lib64/libpthread.so.0
> (gdb) bt
> #0  0x7fbda686e9a6 in pthread_cond_wait@@GLIBC_2.3.2 () from 
> /lib64/libpthread.so.0
> #1  0x7fbda5359453 in ?? () from /usr/local/lib/dri/r600_dri.so
> #2  0x7fbda53661f4 in ?? () from /usr/local/lib/dri/r600_dri.so
> #3  0x00401e18 in ?? ()
> #4  0x004028c7 in ?? ()
> #5  0x7fbda9925781 in fghRedrawWindow () from 
> /usr/lib64/libglut.so.3
> #6  0x7fbda9925c08 in ?? () from /usr/lib64/libglut.so.3
> #7  0x7fbda9926cf9 in fgEnumWindows () from /usr/lib64/libglut.so.3
> #8  0x7fbda9925ce4 in glutMainLoopEvent () from 
> /usr/lib64/libglut.so.3
> #9  0x7fbda9925d85 in glutMainLoop () from /usr/lib64/libglut.so.3
> #10 0x004019fc in ?? ()
> #11 0x7fbda957e541 in __libc_start_main () from /lib64/libc.so.6
> #12 0x00401afa in ?? ()
> 
> Should I do more or not worth it?
> 
> Dieter

Hello Dieter,

To be honest, I don't konw how much time you need to wait. 77 millions of
PBO transfer is quite huge. It depends on CPU/Memory/PCIe/VRAM/GPU speed.

Hum based on the image size (194*188*4), you need to approximately transfer
10522 GB of data from your GPU... Which is likely around 20 minutes if
PCIe run at full speed. Honestly I will let the application in background
for a couple of hours.

Backtrace without symbol is hard to read. But I'm pretty sure, it is
waiting on the glError call.

Cheers,
Gregory

 
> >> > mesa-demos/tests> ./pbo
> >> > ATTENTION: default value of option mesa_glthread overridden by
> >> > environment.
> >> > GL_VERSION = 4.1 Mesa 17.1.0-devel (git-7c8fe31e1c)
> >> > GL_RENDERER = Gallium 0.4 on AMD TURKS (DRM 2.49.0 /
> >> > 4.11.0-rc6-1.g5a51416-default, LLVM 5.0.0)
> >> > Loaded 194 by 188 image
> >> > Converting RGB image to RGBA
> >> > Benchmarking...
> >> > Result:  7712 reads in 4.00 seconds = -383971576.00
> >> > pixels/sec
> >> >
> >> > top - 02:04:42 up 10:05,  4 users,  load average: 1,03, 0,77, 0,71
> >> > Tasks: 265 total,   1 running, 264 sleeping,   0 stopped,   0 zombie
> >> > %Cpu0  :  1,3 us,  0,3 sy,  0,0 ni, 98,3 id,  0,0 wa,  0,0 hi,  0,0 si,
> >> >  0,0 st
> >> > %Cpu1  :  1,3 us,  0,3 sy,  0,0 ni, 98,3 id,  0,0 wa,  0,0 hi,  0,0 si,
> >> >  0,0 st
> >> > %Cpu2  :  1,7 us,  0,0 sy,  0,0 ni, 98,3 id,  0,0 wa,  0,0 hi,  0,0 si,
> >> >  0,0 st
> >> > %Cpu3  :  2,3 us,  0,3 sy,  0,0 ni, 97,3 id,  0,0 wa,  0,0 hi,  0,0 si,
> >> >  0,0 st
> >> > %Cpu4  :  1,7 us,  0,3 sy,  0,0 ni, 98,0 id,  0,0 wa,  0,0 hi,  0,0 si,
> >> >  0,0 st
> >> > %Cpu5  : 98,3 us,  1,7 sy,  0,0 ni,  0,0 id,  0,0 wa,  0,0 hi,  0,0 si,
> >> >  0,0 st
> >> > %Cpu6  :  2,0 us,  0,3 sy,  0,0 ni, 97,7 id,  0,0 wa,  0,0 hi,  0,0 si,
> >> >  0,0 st
> >> > %Cpu7  :  1,7 us,  0,0 sy,  0,0 ni, 98,3 id,  0,0 wa,  0,0 hi,  0,0 si,
> >> >  0,0 st
> >> > KiB Mem : 24680300 total,  8155356 free,  5751864 used, 10773080
> >> > buff/cache
> >> > KiB Swap:0 total,0 free,0 used. 18437888 avail
> >> > Mem
> >> >
> >> >   PID USER  PR  NIVIRTRESSHR S

Re: [Mesa-dev] [PATCH] nir: Add GLSL_TYPE_[U]INT64 to some switch statements

2017-04-15 Thread Alejandro Piñeiro 
Sorry, I answered your previous email without realizing that there was a
new one (with an extra CC).

Just in case you need another explicit Rb:
Reviewed-by: Alejandro Piñeiro 

On 15/04/17 00:25, Jason Ekstrand wrote:
> Cc: mesa-sta...@lists.freedesktop.org
> ---
>  src/compiler/nir/nir.c  | 2 ++
>  src/compiler/nir/nir_split_var_copies.c | 2 ++
>  2 files changed, 4 insertions(+)
>
> diff --git a/src/compiler/nir/nir.c b/src/compiler/nir/nir.c
> index 43fa60f..0abf9b6 100644
> --- a/src/compiler/nir/nir.c
> +++ b/src/compiler/nir/nir.c
> @@ -699,7 +699,9 @@ deref_foreach_leaf_build_recur(nir_deref_var *deref, 
> nir_deref *tail,
> assert(tail->child == NULL);
> switch (glsl_get_base_type(tail->type)) {
> case GLSL_TYPE_UINT:
> +   case GLSL_TYPE_UINT64:
> case GLSL_TYPE_INT:
> +   case GLSL_TYPE_INT64:
> case GLSL_TYPE_FLOAT:
> case GLSL_TYPE_DOUBLE:
> case GLSL_TYPE_BOOL:
> diff --git a/src/compiler/nir/nir_split_var_copies.c 
> b/src/compiler/nir/nir_split_var_copies.c
> index 58c7873..15a185e 100644
> --- a/src/compiler/nir/nir_split_var_copies.c
> +++ b/src/compiler/nir/nir_split_var_copies.c
> @@ -147,7 +147,9 @@ split_var_copy_instr(nir_intrinsic_instr *old_copy,
>break;
>  
> case GLSL_TYPE_UINT:
> +   case GLSL_TYPE_UINT64:
> case GLSL_TYPE_INT:
> +   case GLSL_TYPE_INT64:
> case GLSL_TYPE_FLOAT:
> case GLSL_TYPE_DOUBLE:
> case GLSL_TYPE_BOOL:

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

Re: [Mesa-dev] [PATCH] nir: Add GLSL_TYPE_[U]INT64 to some switch statements

2017-04-15 Thread Alejandro Piñeiro 
Reviewed-by: Alejandro Piñeiro 

On 14/04/17 23:55, Jason Ekstrand wrote:
> ---
>  src/compiler/nir/nir.c  | 2 ++
>  src/compiler/nir/nir_split_var_copies.c | 2 ++
>  2 files changed, 4 insertions(+)
>
> diff --git a/src/compiler/nir/nir.c b/src/compiler/nir/nir.c
> index 43fa60f..0abf9b6 100644
> --- a/src/compiler/nir/nir.c
> +++ b/src/compiler/nir/nir.c
> @@ -699,7 +699,9 @@ deref_foreach_leaf_build_recur(nir_deref_var *deref, 
> nir_deref *tail,
> assert(tail->child == NULL);
> switch (glsl_get_base_type(tail->type)) {
> case GLSL_TYPE_UINT:
> +   case GLSL_TYPE_UINT64:
> case GLSL_TYPE_INT:
> +   case GLSL_TYPE_INT64:
> case GLSL_TYPE_FLOAT:
> case GLSL_TYPE_DOUBLE:
> case GLSL_TYPE_BOOL:
> diff --git a/src/compiler/nir/nir_split_var_copies.c 
> b/src/compiler/nir/nir_split_var_copies.c
> index 58c7873..15a185e 100644
> --- a/src/compiler/nir/nir_split_var_copies.c
> +++ b/src/compiler/nir/nir_split_var_copies.c
> @@ -147,7 +147,9 @@ split_var_copy_instr(nir_intrinsic_instr *old_copy,
>break;
>  
> case GLSL_TYPE_UINT:
> +   case GLSL_TYPE_UINT64:
> case GLSL_TYPE_INT:
> +   case GLSL_TYPE_INT64:
> case GLSL_TYPE_FLOAT:
> case GLSL_TYPE_DOUBLE:
> case GLSL_TYPE_BOOL:

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