[Mesa-dev] [PATCH] mesa: call _mesa_set_vp_override in glDrawTex*

2011-08-21 Thread Chia-I Wu 
The driver may install its own vertex shader.  _mesa_set_vp_override
must be called so that core mesa can generate correct fragment program..
---
 src/mesa/main/drawtex.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/src/mesa/main/drawtex.c b/src/mesa/main/drawtex.c
index 2089cdf..83485a9 100644
--- a/src/mesa/main/drawtex.c
+++ b/src/mesa/main/drawtex.c
@@ -45,11 +45,15 @@ draw_texture(struct gl_context *ctx, GLfloat x, GLfloat y, 
GLfloat z,
   return;
}
 
+   _mesa_set_vp_override(ctx, GL_TRUE);
+
if (ctx-NewState)
   _mesa_update_state(ctx);
 
ASSERT(ctx-Driver.DrawTex);
ctx-Driver.DrawTex(ctx, x, y, z, width, height);
+
+   _mesa_set_vp_override(ctx, GL_FALSE);
 }
 
 
-- 
1.7.5.4

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

Re: [Mesa-dev] [PATCH 4/5] mesa: Fix glGetUniformfv of native integer uniforms.

2011-08-21 Thread Christoph Bumiller 
On 21.08.2011 06:00, Kenneth Graunke wrote:
 On 08/20/2011 02:47 PM, Christoph Bumiller wrote:
 On 20.08.2011 22:07, Dan McCabe wrote:
 On 08/20/2011 12:16 AM, Kenneth Graunke wrote:
 On 08/19/2011 05:56 PM, Eric Anholt wrote:
 We have to actually convert the values on the way out.  Fixes piglit
 ARB_shader_objects/getuniform.
 ---
   src/mesa/main/uniforms.c |   32 
   1 files changed, 28 insertions(+), 4 deletions(-)

 diff --git a/src/mesa/main/uniforms.c b/src/mesa/main/uniforms.c
 index cda840f..fbaa810 100644
 --- a/src/mesa/main/uniforms.c
 +++ b/src/mesa/main/uniforms.c
 @@ -55,13 +55,11 @@ static GLenum
   base_uniform_type(GLenum type)
   {
  switch (type) {
 -#if 0 /* not needed, for now */
  case GL_BOOL:
  case GL_BOOL_VEC2:
  case GL_BOOL_VEC3:
  case GL_BOOL_VEC4:
 return GL_BOOL;
 -#endif
  case GL_FLOAT:
  case GL_FLOAT_VEC2:
  case GL_FLOAT_VEC3:
 @@ -408,8 +406,12 @@ get_uniform(struct gl_context *ctx, GLuint
 program, GLint location,
  else {
 const struct gl_program_parameter *p =
prog-Parameters-Parameters[paramPos];
 +  gl_constant_value (*values)[4];
 GLint rows, cols, i, j, k;
 GLsizei numBytes;
 +  GLenum storage_type;
 +
 +  values = prog-Parameters-ParameterValues + paramPos + offset;

 get_uniform_rows_cols(p,rows,cols);

 @@ -421,15 +423,37 @@ get_uniform(struct gl_context *ctx, GLuint
 program, GLint location,
return;
 }

 +  if (ctx-Const.NativeIntegers) {
 + storage_type = base_uniform_type(p-DataType);
 +  } else {
 + storage_type = GL_FLOAT;
 +  }
 +
 switch (returnType) {
 case GL_FLOAT:
{
   GLfloat *params = (GLfloat *) paramsOut;
   k = 0;
   for (i = 0; i  rows; i++) {
 -   const int base = paramPos + offset + i;
  for (j = 0; j  cols; j++ ) {
 -  params[k++] =
 prog-Parameters-ParameterValues[base][j].f;
 +  switch (storage_type) {
 +  case GL_FLOAT:
 + params[k++] = values[i][j].f;
 + break;
 +  case GL_INT:
 + params[k++] = values[i][j].i;
 + break;
 +  case GL_UNSIGNED_INT:
 + params[k++] = values[i][j].u;
 + break;
 +  case GL_BOOL:
 + params[k++] = values[i][j].b;
 + break;
 +  default:
 + _mesa_problem(ctx, Invalid type in glGetUniform());
 + params[k++] = 0.0;
 + break;
 +  }
  }
   }
}
 Argh.  The OpenGL specification is so unclear on what happens when you
 call GetUniform{f, i, ui}v on a value of a different type.  Your code
 here assumes that it's legal to call GetUniformfv on an int/bool/uint
 uniform, and that the uniform's value should be implicitly converted to
 floating point.  That seems plausible.

 But what about calling GetUniformiv or GetUniformuiv on a float uniform?
   Is it supposed to convert the float value to an int/uint?  By what
 rounding rules...truncate?  We're certainly not doing that now.  If
 that's the proper behavior, we need your switch statement in the GL_INT
 and GL_UNSIGNED_INT returnType cases as well.

 The GL4.2 spec is quite clear on the issue:
 from 2.11.7:
 For all other [than boolean] uniform types, except for subroutine
 uniforms and atomic counters, the Uniform* command used must match the
 size and type of the uniform, as declared in the shader. No type
 conversions are done.
 An INVALID_OPERATION error will be generated if an attempt is made to
 use a non-matching Uniform* command.
 That's for glUniform, though, which -loads- uniforms.  I found no such
 text for gl*Get*Uniform...
Right, sorry, I assumed the behaviour for load might apply to Get as
well, but it doesn't.

Then most likely 6.1.2 applies, Querying GL State, Data Conversions.

E.g. float to int is rounded to nearest except for RGBA or depth values,
booleans are returned as 1/0 or 1.0/0.0, ...
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/3] auxiliary/os: add wrappers for mmap/munmap

2011-08-21 Thread Chia-I Wu 
From: Chia-I Wu o...@lunarg.com

The use of mmap() in winsys requires large file support.  Not all OSes
have LFS so a wrapper should be used.  In particular, os_mmap() should
call __mmap2() on Android.
---
 src/gallium/auxiliary/os/os_mman.h |   87 
 1 files changed, 87 insertions(+), 0 deletions(-)
 create mode 100644 src/gallium/auxiliary/os/os_mman.h

diff --git a/src/gallium/auxiliary/os/os_mman.h 
b/src/gallium/auxiliary/os/os_mman.h
new file mode 100644
index 000..b48eb053
--- /dev/null
+++ b/src/gallium/auxiliary/os/os_mman.h
@@ -0,0 +1,87 @@
+/**
+ *
+ * Copyright 2011 LunarG, Inc.
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * Software), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
+ * IN NO EVENT SHALL VMWARE AND/OR ITS SUPPLIERS BE LIABLE FOR
+ * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
+ * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
+ * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ **/
+
+/**
+ * @file
+ * OS independent memory mapping (with large file support).
+ *
+ * @author Chia-I Wu olva...@gmail.com
+ */
+
+#ifndef _OS_MMAN_H_
+#define _OS_MMAN_H_
+
+
+#include pipe/p_config.h
+#include pipe/p_compiler.h
+
+#if defined(PIPE_OS_UNIX)
+#  ifndef _FILE_OFFSET_BITS
+#error _FILE_OFFSET_BITS must be defined to 64
+#  endif
+#  include sys/mman.h
+#else
+#  error Unsupported OS
+#endif
+
+#if defined(PIPE_OS_ANDROID)
+#  include errno.h /* for EINVAL */
+#endif
+
+#ifdef  __cplusplus
+extern C {
+#endif
+
+
+#if defined(PIPE_OS_ANDROID)
+
+extern void *__mmap2(void *, size_t, int, int, int, size_t);
+
+static INLINE void *os_mmap(void *addr, size_t length, int prot, int flags, 
int fd, loff_t offset)
+{
+   /* offset must be aligned to 4096 (not necessarily the page size) */
+   if (unlikely(offset  4095)) {
+  errno = EINVAL;
+  return MAP_FAILED;
+   }
+
+   return __mmap2(addr, length, prot, flags, fd, (size_t) (offset  12));
+}
+
+#else
+/* assume large file support exists */
+#  define os_mmap(addr, length, prot, flags, fd, offset) mmap(addr, length, 
prot, flags, fd, offset)
+#endif
+
+#define os_munmap(addr, length) munmap(addr, length)
+
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* _OS_MMAN_H_ */
-- 
1.7.5.4

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

[Mesa-dev] [PATCH 2/3] winsys/radeon: use os_mmap() for memory mapping

2011-08-21 Thread Chia-I Wu 
From: Chia-I Wu o...@lunarg.com

os_mmap() guarantees large file support across OSes.
---
 src/gallium/winsys/radeon/drm/radeon_drm_bo.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c 
b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
index adfbefd..b45efe5 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
@@ -31,11 +31,11 @@
 #include util/u_memory.h
 #include util/u_simple_list.h
 #include os/os_thread.h
+#include os/os_mman.h
 
 #include state_tracker/drm_driver.h
 
 #include sys/ioctl.h
-#include sys/mman.h
 #include xf86drm.h
 #include errno.h
 
@@ -160,7 +160,7 @@ static void radeon_bo_destroy(struct pb_buffer *_buf)
 }
 
 if (bo-ptr)
-munmap(bo-ptr, bo-size);
+os_munmap(bo-ptr, bo-size);
 
 /* Close object. */
 args.handle = bo-handle;
@@ -278,7 +278,7 @@ static void *radeon_bo_map_internal(struct pb_buffer *_buf,
 return NULL;
 }
 
-ptr = mmap(0, args.size, PROT_READ|PROT_WRITE, MAP_SHARED,
+ptr = os_mmap(0, args.size, PROT_READ|PROT_WRITE, MAP_SHARED,
bo-rws-fd, args.addr_ptr);
 if (ptr == MAP_FAILED) {
 pipe_mutex_unlock(bo-map_mutex);
-- 
1.7.5.4

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

[Mesa-dev] [PATCH 3/3] winsys/vmwgfx: use os_mmap() for memory mapping

2011-08-21 Thread Chia-I Wu 
os_mmap() guarantees large file support across OSes.
---
 src/gallium/winsys/svga/drm/vmw_screen_ioctl.c |   11 ++-
 1 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c 
b/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c
index d92ba38..afdbd44 100644
--- a/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c
+++ b/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c
@@ -42,7 +42,8 @@
 #include xf86drm.h
 #include vmwgfx_drm.h
 
-#include sys/mman.h
+#include os/os_mman.h
+
 #include errno.h
 #include unistd.h
 
@@ -94,7 +95,7 @@ static void
 vmw_ioctl_fifo_unmap(struct vmw_winsys_screen *vws, void *mapping)
 {
VMW_FUNC;
-   (void)munmap(mapping, getpagesize());
+   (void)os_munmap(mapping, getpagesize());
 }
 
 
@@ -106,7 +107,7 @@ vmw_ioctl_fifo_map(struct vmw_winsys_screen *vws,
 
VMW_FUNC;
 
-   map = mmap(NULL, getpagesize(), PROT_READ, MAP_SHARED,
+   map = os_mmap(NULL, getpagesize(), PROT_READ, MAP_SHARED,
  vws-ioctl.drm_fd, fifo_offset);
 
if (map == MAP_FAILED) {
@@ -362,7 +363,7 @@ vmw_ioctl_region_destroy(struct vmw_region *region)
   region-ptr.gmrId, region-ptr.offset);
 
if (region-data) {
-  munmap(region-data, region-size);
+  os_munmap(region-data, region-size);
   region-data = NULL;
}
 
@@ -388,7 +389,7 @@ vmw_ioctl_region_map(struct vmw_region *region)
   region-ptr.gmrId, region-ptr.offset);
 
if (region-data == NULL) {
-  map = mmap(NULL, region-size, PROT_READ | PROT_WRITE, MAP_SHARED,
+  map = os_mmap(NULL, region-size, PROT_READ | PROT_WRITE, MAP_SHARED,
 region-drm_fd, region-map_handle);
   if (map == MAP_FAILED) {
 debug_printf(%s: Map failed.\n, __FUNCTION__);
-- 
1.7.5.4

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

Re: [Mesa-dev] [PATCH 2/3] winsys/radeon: use os_mmap() for memory mapping

2011-08-21 Thread Marek Olšák 
Reviewed-by: Marek Olšák mar...@gmail.com

On Sun, Aug 21, 2011 at 2:41 PM, Chia-I Wu olva...@gmail.com wrote:
 From: Chia-I Wu o...@lunarg.com

 os_mmap() guarantees large file support across OSes.
 ---
  src/gallium/winsys/radeon/drm/radeon_drm_bo.c |    6 +++---
  1 files changed, 3 insertions(+), 3 deletions(-)

 diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c 
 b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
 index adfbefd..b45efe5 100644
 --- a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
 +++ b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
 @@ -31,11 +31,11 @@
  #include util/u_memory.h
  #include util/u_simple_list.h
  #include os/os_thread.h
 +#include os/os_mman.h

  #include state_tracker/drm_driver.h

  #include sys/ioctl.h
 -#include sys/mman.h
  #include xf86drm.h
  #include errno.h

 @@ -160,7 +160,7 @@ static void radeon_bo_destroy(struct pb_buffer *_buf)
     }

     if (bo-ptr)
 -        munmap(bo-ptr, bo-size);
 +        os_munmap(bo-ptr, bo-size);

     /* Close object. */
     args.handle = bo-handle;
 @@ -278,7 +278,7 @@ static void *radeon_bo_map_internal(struct pb_buffer 
 *_buf,
         return NULL;
     }

 -    ptr = mmap(0, args.size, PROT_READ|PROT_WRITE, MAP_SHARED,
 +    ptr = os_mmap(0, args.size, PROT_READ|PROT_WRITE, MAP_SHARED,
                bo-rws-fd, args.addr_ptr);
     if (ptr == MAP_FAILED) {
         pipe_mutex_unlock(bo-map_mutex);
 --
 1.7.5.4

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

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

Re: [Mesa-dev] glsl: do_vec_index_to_cond_assign not called; has problems if called

2011-08-21 Thread Aras Pranckevicius 

  Looks like do_vec_index_to_cond_assing was lost in this commit:
 
 http://cgit.freedesktop.org/mesa/mesa/commit/?id=2f4fe151681a6f6afe1d452eece6cf4144f44e49

 Converting variable indexing of vectors to conditional assignments is a
 lowering pass, not an optimization.  We don't do it by default because
 some hardware may not need it.


Ah ok. Now I see that it's called much later, either in the driver or in
glsl_to_tgsi. Before commit 2f4fe151681 it used to be called inside the high
level IR optimization loop.


I ran this on the i965 driver with current Mesa master, and it ran just
 fine.  Can you provide a backtrace from the abort in IR validate?


Right, it probably does not happen anymore now
that do_vec_index_to_cond_assing is called much later in the process. Move
along, nothing to see here!

-- 
Aras Pranckevičius
work: http://unity3d.com
home: http://aras-p.info
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 40269] #ifdef isn't recognized in GLSL preprocessor

2011-08-21 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=40269

Alex Deucher ag...@yahoo.com changed:

   What|Removed |Added

Product|xorg|Mesa
  Component|Driver/Radeon   |Mesa core
 AssignedTo|xorg-driver-...@lists.x.org |mesa-dev@lists.freedesktop.
   ||org
  QAContact|xorg-t...@lists.x.org   |

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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/gen6+: Use non-normalized coordinates for GL_TEXTURE_RECTANGLE.

2011-08-21 Thread Kenneth Graunke 
On 08/17/2011 05:55 PM, Eric Anholt wrote:
 Improves performance of a GL_TEXTURE_RECTANGLE microbenchmark by 1.84%
 +/- .15% (n=3)
 ---
  src/mesa/drivers/dri/i965/brw_fs_visitor.cpp |3 ++-
  src/mesa/drivers/dri/i965/brw_wm_fp.c|4 +++-
  src/mesa/drivers/dri/i965/brw_wm_sampler_state.c |7 +++
  src/mesa/drivers/dri/i965/gen7_sampler_state.c   |7 +++
  4 files changed, 19 insertions(+), 2 deletions(-)

SAMPLER_STATE's Non-normalized Coordinate Enable bit also mentions
that TCX/Y/Z Address Control Mode must be TEXCOORDMODE_CLAMP or
TEXCOORDMODE_CLAMP_BORDER.

Apparently GL does not allow the use of GL_REPEAT or GL_MIRRORED_REPEAT
wrap modes with texture rectangles, so I think we're okay.  It might be
nice to comment about that.

Either way, with the extra gen = 6 check removed,
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/5] mesa: Make the gl_constant_value's bool occupy the same space as float/int.

2011-08-21 Thread Eric Anholt 
On Sat, 20 Aug 2011 15:10:18 -0700, Dan McCabe zen3d.li...@gmail.com wrote:
 On 08/20/2011 01:30 PM, Bryan Cain wrote:
  On 08/20/2011 03:05 PM, Dan McCabe wrote:
  What are the implications for other architectures that support doubles?
 
  I don't see what you mean.  gl_constant_value doesn't support doubles yet.
 
 Yet - that is the operative word.
 
 You can buy GPUs that support doubles today. Therefore, double support 
 should be on our radar (it appears to be on Eric's radar, based on his 
 commit comment). And we should understand what the implications are for 
 our code. Clearly, I don't understand the implications; if I did, I 
 wouldn't have asked. But perhaps Eric might.
 
 There are a couple of possible answers.
 
 I don't know - OK, but at least let's ask the question and start 
 thinking about it's answer.
 
 No impact - I like that answer.
 
 It affects this, and this, and this - While not ideal, at least we 
 then know what to do in the future and prepare ourselves for that future.

No, the other answer, not interested.  We have much we need to do
before then, doubles are totally uninteresting at this point.


pgpwB0kqQRepm.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] i965/gen6+: Use non-normalized coordinates for GL_TEXTURE_RECTANGLE.

2011-08-21 Thread Kenneth Graunke 
On 08/21/2011 09:38 AM, Kenneth Graunke wrote:
 On 08/17/2011 05:55 PM, Eric Anholt wrote:
 Improves performance of a GL_TEXTURE_RECTANGLE microbenchmark by 1.84%
 +/- .15% (n=3)
 ---
  src/mesa/drivers/dri/i965/brw_fs_visitor.cpp |3 ++-
  src/mesa/drivers/dri/i965/brw_wm_fp.c|4 +++-
  src/mesa/drivers/dri/i965/brw_wm_sampler_state.c |7 +++
  src/mesa/drivers/dri/i965/gen7_sampler_state.c   |7 +++
  4 files changed, 19 insertions(+), 2 deletions(-)
 
 SAMPLER_STATE's Non-normalized Coordinate Enable bit also mentions
 that TCX/Y/Z Address Control Mode must be TEXCOORDMODE_CLAMP or
 TEXCOORDMODE_CLAMP_BORDER.
 
 Apparently GL does not allow the use of GL_REPEAT or GL_MIRRORED_REPEAT
 wrap modes with texture rectangles, so I think we're okay.  It might be
 nice to comment about that.
 
 Either way, with the extra gen = 6 check removed,
 Reviewed-by: Kenneth Graunke kenn...@whitecape.org

Come to think of it, perhaps an assertion would be even better than a
comment.

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

[Mesa-dev] [Bug 40269] #ifdef isn't recognized in GLSL preprocessor

2011-08-21 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=40269

snake5crea...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||NOTOURBUG

--- Comment #2 from snake5crea...@gmail.com 2011-08-21 11:44:55 PDT ---
I was using the latest version of Mesa according to Synaptic.
However, I reinstalled everything and the bug seems to be gone.
So either it was a temporary problem with the configuration or something that
could happen if fglrx wouldn't be properly uninstalled, but in any case, the
problem is solved.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 3/5] mesa: Make the gl_constant_value's bool occupy the same space as float/int.

2011-08-21 Thread Kenneth Graunke 
On 08/21/2011 11:05 AM, Eric Anholt wrote:
 On Sat, 20 Aug 2011 15:10:18 -0700, Dan McCabe zen3d.li...@gmail.com wrote:
 On 08/20/2011 01:30 PM, Bryan Cain wrote:
 On 08/20/2011 03:05 PM, Dan McCabe wrote:
 What are the implications for other architectures that support doubles?

 I don't see what you mean.  gl_constant_value doesn't support doubles yet.

 Yet - that is the operative word.

 You can buy GPUs that support doubles today. Therefore, double support 
 should be on our radar (it appears to be on Eric's radar, based on his 
 commit comment). And we should understand what the implications are for 
 our code. Clearly, I don't understand the implications; if I did, I 
 wouldn't have asked. But perhaps Eric might.

 There are a couple of possible answers.

 I don't know - OK, but at least let's ask the question and start 
 thinking about it's answer.

 No impact - I like that answer.

 It affects this, and this, and this - While not ideal, at least we 
 then know what to do in the future and prepare ourselves for that future.
 
 No, the other answer, not interested.  We have much we need to do
 before then, doubles are totally uninteresting at this point.

Yeah, agreed.  We can cross that bridge when we come to it.  The
architecture and code will have evolved significantly by the time we get
there anyway.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev