date:20150831

Re: [Mesa-dev] [PATCH 00/42] RadeonSI cleaning up states

2015-08-31 Thread Christian König


On 31.08.2015 05:50, Alex Deucher wrote:

On Sun, Aug 30, 2015 at 3:11 PM, Marek Olšák  wrote:

Hi,

Nothing special here, just a lot of cosmetic changes and a few 
micro-optimizations.

This series starts with some fixes for 11.0 (patches 3-5).

Then it converts a half of pm4 states into atoms. All direct states are 
converted (set_* functions and derived states). All CSOs (init_config, blend, 
DSA, rasterizer, shaders) will remain as pm4 states.

The viewport and scissor states are optimized. The main thing is that setting 
non-zero viewports and scissors is delayed until a shader that writes 
VIEWPORT_INDEX appears (which is typically never).

The geometry and tessellation ring registers and border color registers are 
moved to the init_config state, removing 3 more states.

All shared functions for writing registers are renamed to radeon_xxx, e.g. 
radeon_set_context_reg instead of r600_write_context_reg. r600_context_bo_reloc 
is renamed to radeon_add_to_buffer_list. It now makes sense when you're reading 
it.

Radeonsi no longer counts how much CS space it needs for draw calls and CP DMA. 
One need_cs_space call will make sure there are at least 2048 dwords and that's 
it. Even that is too many, but it's safe.

Uploading border colors is rewritten. Now it's using a static buffer, so the 
limit is 4096 unique border colors per context. Thanks to that, sampler states 
are finally immutable, which will be useful for the constant engine.

Lastly, the INDIRECT_BUFFER packet is used for the init_config state on CIK and 
later.

For the series:
Reviewed-by: Alex Deucher 


Nice cleanup. Whole series is Acked-by: Christian König 



Regards,
Christian.




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

[Mesa-dev] [PATCH] mesa: change 'SHADER_SUBST' facility to work with env variables

2015-08-31 Thread Tapani Pälli

Patch modifies existing shader source and replace functionality to work
with environment variables rather than enable dumping on compile time.
Also instead of _mesa_str_checksum, _mesa_sha1_compute is used to avoid
collisions.

Functionality is controlled via 2 environment variables:

MESA_SHADER_DUMP_PATH - path where shader sources are dumped
MESA_SHADER_READ_PATH - path where replacement shaders are read

Signed-off-by: Tapani Pälli 
Suggested-by: Eero Tamminen 
---
 docs/shading.html |   9 +++
 src/mesa/main/shaderapi.c | 136 --
 2 files changed, 105 insertions(+), 40 deletions(-)

diff --git a/docs/shading.html b/docs/shading.html
index 77a0ee4..784329e 100644
--- a/docs/shading.html
+++ b/docs/shading.html
@@ -63,6 +63,15 @@ execution.  These are generally used for debugging.
 Example:  export MESA_GLSL=dump,nopt
 
 
+
+Shaders can be dumped and replaced on runtime for debugging purposes. 
+This is controlled via following environment variables:
+
+MESA_SHADER_DUMP_PATH - path where shader sources are dumped
+MESA_SHADER_READ_PATH - path where replacement shaders are read
+
+Note, path set must exist before running for dumping or replacing to work.
+
 
 GLSL Version
 
diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
index 0e0e0d6..d3abfc9 100644
--- a/src/mesa/main/shaderapi.c
+++ b/src/mesa/main/shaderapi.c
@@ -53,15 +53,13 @@
 #include "program/prog_parameter.h"
 #include "util/ralloc.h"
 #include "util/hash_table.h"
+#include "util/mesa-sha1.h"
 #include 
 #include "../glsl/glsl_parser_extras.h"
 #include "../glsl/ir.h"
 #include "../glsl/ir_uniform.h"
 #include "../glsl/program.h"
 
-/** Define this to enable shader substitution (see below) */
-#define SHADER_SUBST 0
-
 
 /**
  * Return mask of GLSL_x flags by examining the MESA_GLSL env var.
@@ -1512,24 +1510,101 @@ _mesa_LinkProgram(GLhandleARB programObj)
link_program(ctx, programObj);
 }
 
+/**
+ * Generate a SHA-1 hash value string for given source string.
+ */
+static void
+generate_sha1(const char *source, char sha_str[64])
+{
+   unsigned char sha[20];
+   _mesa_sha1_compute(source, strlen(source), sha);
+   _mesa_sha1_format(sha_str, sha);
+}
+
+/**
+ * Construct a full path for shader replacement functionality using
+ * following format:
+ *
+ * /_.glsl
+ */
+static void
+construct_name(const gl_shader_stage stage, const char *source,
+   const char *path, char *name, unsigned length)
+{
+   char sha[64];
+   static const char *types[] = {
+  "VS", "TC", "TE", "GS", "FS", "CS",
+   };
 
+   generate_sha1(source, sha);
+   _mesa_snprintf(name, length, "%s/%s_%s.glsl", path, types[stage],
+  sha);
+}
+
+/**
+ * Write given shader source to a file in MESA_SHADER_DUMP_PATH.
+ */
+static void
+dump_shader(const gl_shader_stage stage, const char *source)
+{
+   char name[PATH_MAX];
+   static bool path_exists = true;
+   char *dump_path;
+   FILE *f;
+
+   if (!path_exists)
+  return NULL;
+
+   dump_path = getenv("MESA_SHADER_DUMP_PATH");
+
+   if (!dump_path) {
+  path_exists = false;
+  return NULL;
+   }
+
+   construct_name(stage, source, dump_path, name, PATH_MAX);
+
+   f = fopen(name, "w");
+   if (f) {
+  fputs(source, f);
+  fclose(f);
+   } else {
+  GET_CURRENT_CONTEXT(ctx);
+  _mesa_warning(ctx, "could not open %s for dumping shader", name);
+   }
+}
 
 /**
  * Read shader source code from a file.
  * Useful for debugging to override an app's shader.
  */
 static GLcharARB *
-read_shader(const char *fname)
+read_shader(const gl_shader_stage stage, const char *source)
 {
-   int shader_size = 0;
-   FILE *f = fopen(fname, "r");
-   GLcharARB *buffer, *shader;
-   int len;
+   char name[PATH_MAX];
+   char *read_path;
+   static bool path_exists = true;
+   int len, shader_size = 0;
+   GLcharARB *buffer;
+   FILE *f;
 
-   if (!f) {
+   if (!path_exists)
+  return NULL;
+
+   read_path = getenv("MESA_SHADER_READ_PATH");
+
+   if (!read_path) {
+  path_exists = false;
   return NULL;
}
 
+   construct_name(stage, source, read_path, name, PATH_MAX);
+
+   f = fopen(name, "r");
+
+   if (!f)
+  return NULL;
+
/* allocate enough room for the entire shader */
fseek(f, 0, SEEK_END);
shader_size = ftell(f);
@@ -1547,13 +1622,9 @@ read_shader(const char *fname)
 
fclose(f);
 
-   shader = strdup(buffer);
-   free(buffer);
-
-   return shader;
+   return buffer;
 }
 
-
 /**
  * Called via glShaderSource() and glShaderSourceARB() API functions.
  * Basically, concatenate the source code strings into one long string
@@ -1566,14 +1637,15 @@ _mesa_ShaderSource(GLhandleARB shaderObj, GLsizei count,
GET_CURRENT_CONTEXT(ctx);
GLint *offsets;
GLsizei i, totalLength;
-   GLcharARB *source;
-   GLuint checksum;
+   GLcharARB *source, *replacement;
 
if (!shaderObj || string == NULL) {
   _mesa_error(ctx, GL_INVALID_VALUE, "glShaderSourceARB");
   return;

Re: [Mesa-dev] [PATCH] r600/sb: update last_cf for finalize if.

2015-08-31 Thread Glenn Kennard


On Mon, 31 Aug 2015 06:23:38 +0200, Dave Airlie  wrote:


From: Dave Airlie 

As Glenn did for finalize_loop we need to update_cf when we
add a POP at the end of a shader.

I think this fixes one of the earlier shader going off end
of memory problems we've stopped.

Signed-off-by: Dave Airlie 
---
 src/gallium/drivers/r600/sb/sb_bc_finalize.cpp | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/gallium/drivers/r600/sb/sb_bc_finalize.cpp  
b/src/gallium/drivers/r600/sb/sb_bc_finalize.cpp

index e8ed5a2..726e438 100644
--- a/src/gallium/drivers/r600/sb/sb_bc_finalize.cpp
+++ b/src/gallium/drivers/r600/sb/sb_bc_finalize.cpp
@@ -199,6 +199,9 @@ void bc_finalizer::finalize_if(region_node* r) {
cf_node *if_jump = sh.create_cf(CF_OP_JUMP);
cf_node *if_pop = sh.create_cf(CF_OP_POP);
+   if (!last_cf || last_cf->get_parent_region() == r) {
+   last_cf = if_pop;
+   }
if_pop->bc.pop_count = 1;
if_pop->jump_after(if_pop);



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

[Mesa-dev] [PATCH v2] mesa: Allow query of GL_VERTEX_BINDING_BUFFER

2015-08-31 Thread Marta Lofstedt

From: Marta Lofstedt 

According to OpenGL ES 3.1 specification table : 20.2 and
OpenGL specification 4.4 table 23.4. The glGetIntegeri_v
functions should report the name  of the buffer bound
when called with GL_VERTEX_BINDING_BUFFER.

Signed-off-by: Marta Lofstedt 
---
 src/mesa/main/get.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
index 4855187..13860dd 100644
--- a/src/mesa/main/get.c
+++ b/src/mesa/main/get.c
@@ -1992,6 +1992,14 @@ find_value_indexed(const char *func, GLenum pname, 
GLuint index, union value *v)
   v->value_int = 
ctx->Array.VAO->VertexBinding[VERT_ATTRIB_GENERIC(index)].Stride;
   return TYPE_INT;
 
+   case GL_VERTEX_BINDING_BUFFER:
+  if (ctx->API == GLES2 && ctx->Version < 31)
+ goto invalid_enum;
+  if (index >= ctx->Const.Program[MESA_SHADER_VERTEX].MaxAttribs)
+ goto invalid_value;
+  v->value_int = 
ctx->Array.VAO->VertexBinding[VERT_ATTRIB_GENERIC(index)].BufferObj->Name;
+  return TYPE_INT;
+
/* ARB_shader_image_load_store */
case GL_IMAGE_BINDING_NAME: {
   struct gl_texture_object *t;
-- 
1.9.1

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

Re: [Mesa-dev] No VAAPI driver hardlinks?

2015-08-31 Thread Emil Velikov

On 30 August 2015 at 00:21, Matt Turner  wrote:
> Hi Emil,
>
> src/gallium/targets/vdpau has a block that installs per-driver
> hardlinks, but src/gallium/targets/va does not (presumably because it
> was added later), which leads to:
>
> https://bugs.gentoo.org/549564
>
> Presumably it's mostly a matter of copy-n-paste?
>
I believe I opted against the hardlinks as only r600 was supported
initially, not 100% sure. Considering that radeonsi works (plus
possible nouveau support on the horizon) I don't have any objections
if we add the hunk for the vaapi targets. Will send a patch in a bit.

> Also, it appears that there's a minor problem with that block as well:
>
> https://bugs.gentoo.org/545230
>
Quite odd that one will enable vdpau if they don't build any of
r300/r600/radeonsi/nouveau. Either way a fix will be coming shortly,
covering all the targets.

-Emil

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

Re: [Mesa-dev] nv3x libreoffice impress opengl animations not working

2015-08-31 Thread Hans de Goede


Hi,

On 28-08-15 11:02, Ilia Mirkin wrote:

On Fri, Aug 28, 2015 at 4:54 AM, Hans de Goede  wrote:

Hi,

On 27-08-15 20:19, Ilia Mirkin wrote:


On Thu, Aug 27, 2015 at 1:59 PM, Alex Deucher 
wrote:






2) Since the glretrace does work outside of libreoffice impress, I
think
it may have something to do with the visual chosen by libreoffice
impress,
is there an easy way to find out what visual lo is choosing?




No, it's not because of the visual. It seems to me that libreoffice
changed the behavior of malloc and calloc.




I'm pretty sure that this is not libreoffice changing malloc / calloc,
it links normally to libc, and the same slide transition works fine
with an nv84 card which also has a gallium based mesa driver.

I really believe this is due to libreoffice doing something opengl
related differently then glretrace, be it the visual or something else
back buffer related ...



Does libreoffice use llvm?  I have vague recollections of there being
issues with llvm and libreoffice in the past because radeonsi uses
llvm as well.



FWIW the nv30 gallium driver will only use llvm as part of 'draw' when
falling back to the swtnl path. This should be extremely rare. But
easy enough to build mesa with --disable-gallium-llvm to double-check
(or what was the env var? DRAW_USE_LLVM=0 or something along those
lines).



I've tried building with --disable-gallium-llvm, this does not help,
this is not really surprising since on Fedora both libreoffice and
mesa use the system llvm, so there should be no problems with them
expecting different llvm versions.

I've done some further debugging adding some debug printf-s to the
texture creation paths for nv3x, this bit is interesting, glretrace
does:

nv30_miptree_from_handle 1350x863 uniform_pitch 6144 usage 0 flags 0
nv30_miptree_create 1350x863 uniform_pitch 5440 usage 0 flags 0 bind 1
target 2

So it gets a texture from a handle, which I believe is the child-window
in which the animation will be shown, and then create another texture
with the same dimensions to serve as back buffer I presume.

ooimpress however does this:

nv30_miptree_from_handle 1350x863 uniform_pitch 6144 usage 0 flags 0
nv30_miptree_create 2700x1726 uniform_pitch 10816 usage 0 flags 0 bind a
target 2
nv30_miptree_create 2700x1726 uniform_pitch 10816 usage 0 flags 0 bind 1
target 2

Notice how it is creating 2 (back?) buffers and they are twice the size of
the "sheet" area of impress to which the animation gets rendered.


bind a = rt/sampler view, bind 1 = depth/stencil. However nv3x doesn't
do NPOT textures... so those sizes are a bit odd. Perhaps there's some
logic that attempts to round-up-to-nearest-POT size, but instead
multiplies width by 2?


Ok, some debugging / poking at thing further I now know where the multiply
by 2 comes from, the pipe_resource *tmpl passed into nv30_miptree_create
has templ->nr_samples = 4, and nv30_miptree_create has:

   switch (tmpl->nr_samples) {
   case 4:
  mt->ms_mode = 0x4000;
  mt->ms_x = 1;
  mt->ms_y = 1;
  break;
   case 2:
  mt->ms_mode = 0x3000;
  mt->ms_x = 1;
  mt->ms_y = 0;
  break;
   default:
  mt->ms_mode = 0x;
  mt->ms_x = 0;
  mt->ms_y = 0;
  break;
   }

So it seems that glretrace is doing a normal rendering which works,
where as ooimpress is doing a 4 way msaa rendering which does not work.

Interestingly enough nv30_screen_get_param returns 0 for
PIPE_CAP_TEXTURE_MULTISAMPLE and for PIPE_CAP_SAMPLER_VIEW_TARGET

And this hack:

--- a/src/gallium/drivers/nouveau/nv30/nv30_screen.c
+++ b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
@@ -319,7 +319,7 @@ nv30_screen_is_format_supported(struct pipe_screen *pscreen,
 unsigned sample_count,
 unsigned bindings)
 {
-   if (sample_count > 4)
+   if (sample_count > 0)
   return false;
if (!(0x0017 & (1 << sample_count)))
   return false;

Fixes the slide animation misrendering (and sometimes crashing)
in libreoffice impress.

As said I think this is a hack, I currently do not understand things
good enough to come up with a better fix.

Hints how to further investigate this are appreciated.

Regards,

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

[Mesa-dev] [PATCH v3] mesa: Allow query of GL_VERTEX_BINDING_BUFFER

2015-08-31 Thread Marta Lofstedt

From: Marta Lofstedt 

According to OpenGL ES 3.1 specification table : 20.2 and
OpenGL specification 4.4 table 23.4. The glGetIntegeri_v
functions should report the name  of the buffer bound
when called with GL_VERTEX_BINDING_BUFFER.

Signed-off-by: Marta Lofstedt 
---
 src/mesa/main/get.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
index 4855187..d5df530 100644
--- a/src/mesa/main/get.c
+++ b/src/mesa/main/get.c
@@ -1992,6 +1992,14 @@ find_value_indexed(const char *func, GLenum pname, 
GLuint index, union value *v)
   v->value_int = 
ctx->Array.VAO->VertexBinding[VERT_ATTRIB_GENERIC(index)].Stride;
   return TYPE_INT;
 
+   case GL_VERTEX_BINDING_BUFFER:
+  if (ctx->API == API_OPENGLES2 && ctx->Version < 31)
+ goto invalid_enum;
+  if (index >= ctx->Const.Program[MESA_SHADER_VERTEX].MaxAttribs)
+ goto invalid_value;
+  v->value_int = 
ctx->Array.VAO->VertexBinding[VERT_ATTRIB_GENERIC(index)].BufferObj->Name;
+  return TYPE_INT;
+
/* ARB_shader_image_load_store */
case GL_IMAGE_BINDING_NAME: {
   struct gl_texture_object *t;
-- 
1.9.1

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

[Mesa-dev] [PATCH] meta: Compute correct buffer size with SkipRows/SkipPixels

2015-08-31 Thread Chris Wilson

From: Jason Ekstrand 

If the user is specifying a subregion of a buffer using SKIP_ROWS and
SKIP_PIXELS, we must compute the buffer size carefully as the end of the
last row may be much shorter than stride*image_height*depth. The current
code tries to memcpy from beyond the end of the user data, for example
causing:

==28136== Invalid read of size 8
==28136==at 0x4C2D94E: memcpy@@GLIBC_2.14 (vg_replace_strmem.c:915)
==28136==by 0xB4ADFE3: brw_bo_write (brw_batch.c:1856)
==28136==by 0xB5B3531: brw_buffer_data (intel_buffer_objects.c:208)
==28136==by 0xB0F6275: _mesa_buffer_data (bufferobj.c:1600)
==28136==by 0xB0F6346: _mesa_BufferData (bufferobj.c:1631)
==28136==by 0xB37A1EE: create_texture_for_pbo (meta_tex_subimage.c:103)
==28136==by 0xB37A467: _mesa_meta_pbo_TexSubImage (meta_tex_subimage.c:176)
==28136==by 0xB5C8D61: intelTexSubImage (intel_tex_subimage.c:195)
==28136==by 0xB254AB4: _mesa_texture_sub_image (teximage.c:3654)
==28136==by 0xB254C9F: texsubimage (teximage.c:3712)
==28136==by 0xB2550E9: _mesa_TexSubImage2D (teximage.c:3853)
==28136==by 0x401CA0: UploadTexSubImage2D (teximage.c:171)
==28136==  Address 0xd8bfbe0 is 0 bytes after a block of size 1,024 alloc'd
==28136==at 0x4C28C20: malloc (vg_replace_malloc.c:296)
==28136==by 0x402014: PerfDraw (teximage.c:270)
==28136==by 0x402648: Draw (glmain.c:182)
==28136==by 0x8385E63: ??? (in /usr/lib/x86_64-linux-gnu/libglut.so.3.9.0)
==28136==by 0x83896C8: fgEnumWindows (in 
/usr/lib/x86_64-linux-gnu/libglut.so.3.9.0)
==28136==by 0x838641C: glutMainLoopEvent (in 
/usr/lib/x86_64-linux-gnu/libglut.so.3.9.0)
==28136==by 0x8386C1C: glutMainLoop (in 
/usr/lib/x86_64-linux-gnu/libglut.so.3.9.0)
==28136==by 0x4019C1: main (glmain.c:262)
==28136==
==28136== Invalid read of size 8
==28136==at 0x4C2D940: memcpy@@GLIBC_2.14 (vg_replace_strmem.c:915)
==28136==by 0xB4ADFE3: brw_bo_write (brw_batch.c:1856)
==28136==by 0xB5B3531: brw_buffer_data (intel_buffer_objects.c:208)
==28136==by 0xB0F6275: _mesa_buffer_data (bufferobj.c:1600)
==28136==by 0xB0F6346: _mesa_BufferData (bufferobj.c:1631)
==28136==by 0xB37A1EE: create_texture_for_pbo (meta_tex_subimage.c:103)
==28136==by 0xB37A467: _mesa_meta_pbo_TexSubImage (meta_tex_subimage.c:176)
==28136==by 0xB5C8D61: intelTexSubImage (intel_tex_subimage.c:195)
==28136==by 0xB254AB4: _mesa_texture_sub_image (teximage.c:3654)
==28136==by 0xB254C9F: texsubimage (teximage.c:3712)
==28136==by 0xB2550E9: _mesa_TexSubImage2D (teximage.c:3853)
==28136==by 0x401CA0: UploadTexSubImage2D (teximage.c:171)
==28136==  Address 0xd8bfbe8 is 8 bytes after a block of size 1,024 alloc'd
==28136==at 0x4C28C20: malloc (vg_replace_malloc.c:296)
==28136==by 0x402014: PerfDraw (teximage.c:270)
==28136==by 0x402648: Draw (glmain.c:182)
==28136==by 0x8385E63: ??? (in /usr/lib/x86_64-linux-gnu/libglut.so.3.9.0)
==28136==by 0x83896C8: fgEnumWindows (in 
/usr/lib/x86_64-linux-gnu/libglut.so.3.9.0)
==28136==by 0x838641C: glutMainLoopEvent (in 
/usr/lib/x86_64-linux-gnu/libglut.so.3.9.0)
==28136==by 0x8386C1C: glutMainLoop (in 
/usr/lib/x86_64-linux-gnu/libglut.so.3.9.0)
==28136==by 0x4019C1: main (glmain.c:262)
==28136==

Fixes: 7f396189f073d626c5f7a2c232dac92b65f5a23f
Cc: Jason Ekstrand 
Cc: Neil Roberts 
---
 src/mesa/drivers/common/meta_tex_subimage.c | 35 +
 1 file changed, 21 insertions(+), 14 deletions(-)

diff --git a/src/mesa/drivers/common/meta_tex_subimage.c 
b/src/mesa/drivers/common/meta_tex_subimage.c
index 16d8f5d..e2351c6 100644
--- a/src/mesa/drivers/common/meta_tex_subimage.c
+++ b/src/mesa/drivers/common/meta_tex_subimage.c
@@ -46,8 +46,9 @@
 #include "varray.h"
 
 static struct gl_texture_image *
-create_texture_for_pbo(struct gl_context *ctx, bool create_pbo,
-   GLenum pbo_target, int width, int height,
+create_texture_for_pbo(struct gl_context *ctx,
+   bool create_pbo, GLenum pbo_target,
+   int dims, int width, int height, int depth,
GLenum format, GLenum type, const void *pixels,
const struct gl_pixelstore_attrib *packing,
GLuint *tmp_pbo, GLuint *tmp_tex)
@@ -73,8 +74,12 @@ create_texture_for_pbo(struct gl_context *ctx, bool 
create_pbo,
   return NULL;
 
/* Account for SKIP_PIXELS, SKIP_ROWS, ALIGNMENT, and SKIP_IMAGES */
-   pixels = _mesa_image_address3d(packing, pixels,
-  width, height, format, type, 0, 0, 0);
+   uint32_t first_pixel = _mesa_image_offset(dims, packing, width, height,
+ format, type,
+ 0, 0, 0);
+   uint32_t last_pixel =  _mesa_image_offset(dims, packing, width, height,
+ format, type,
+

Re: [Mesa-dev] [PATCH] meta: Compute correct buffer size with SkipRows/SkipPixels

2015-08-31 Thread Chris Wilson

On Mon, Aug 31, 2015 at 02:47:48PM +0100, Chris Wilson wrote:
> From: Jason Ekstrand 

Sorry for the confusion Jason, I was messing around with git trying to
reference the right commit easily.
-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] [PATCH 02/14] util: added ffsll() function

2015-08-31 Thread Brian Paul


On 08/28/2015 07:36 PM, Jason Ekstrand wrote:


On Aug 28, 2015 2:31 PM, "Brian Paul" mailto:bri...@vmware.com>> wrote:
 >
 > v2: fix errant _GNU_SOURCE test, per Matt Turner.
 > ---
 >  src/gallium/auxiliary/util/u_math.h | 20 
 >  1 file changed, 20 insertions(+)
 >
 > diff --git a/src/gallium/auxiliary/util/u_math.h
b/src/gallium/auxiliary/util/u_math.h
 > index 56bd185..c551974 100644
 > --- a/src/gallium/auxiliary/util/u_math.h
 > +++ b/src/gallium/auxiliary/util/u_math.h
 > @@ -389,6 +389,26 @@ unsigned ffs( unsigned u )
 >  #define ffs __builtin_ffs
 >  #endif
 >
 > +#ifdef HAVE___BUILTIN_FFSLL
 > +#define ffsll __builtin_ffsll
 > +#else
 > +static inline int
 > +ffsll(long long int val)
 > +{
 > +   int bit;
 > +

Might be better to do

if (val & 0x)
 return ffs(val &0x);
else
 return ffs(val >> 32);

That may be a little cheaper.  I don't know if its actually better but
its one less ffs call (which may cross a library boundary)


I like that too, but I just copied the implementation from imports.c
As was suggested, we can look at consolidating this function and a few 
others into src/util/ later.


-Brian


--Jason

 > +   bit = ffs((unsigned) (val & 0x));
 > +   if (bit != 0)
 > +  return bit;
 > +
 > +   bit = ffs((unsigned) (val >> 32));
 > +   if (bit != 0)
 > +  return 32 + bit;
 > +
 > +   return 0;
 > +}
 > +#endif
 > +
 >  #endif /* FFS_DEFINED */
 >
 >  /**
 > --
 > 1.9.1
 >
 > ___
 > mesa-dev mailing list
 > mesa-dev@lists.freedesktop.org 
 > http://lists.freedesktop.org/mailman/listinfo/mesa-dev




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

Re: [Mesa-dev] [PATCH 02/14] util: added ffsll() function

2015-08-31 Thread Jason Ekstrand

On Aug 31, 2015 7:35 AM, "Brian Paul"  wrote:
>
> On 08/28/2015 07:36 PM, Jason Ekstrand wrote:
>>
>>
>> On Aug 28, 2015 2:31 PM, "Brian Paul" > > wrote:
>>  >
>>  > v2: fix errant _GNU_SOURCE test, per Matt Turner.
>>  > ---
>>  >  src/gallium/auxiliary/util/u_math.h | 20 
>>  >  1 file changed, 20 insertions(+)
>>  >
>>  > diff --git a/src/gallium/auxiliary/util/u_math.h
>> b/src/gallium/auxiliary/util/u_math.h
>>  > index 56bd185..c551974 100644
>>  > --- a/src/gallium/auxiliary/util/u_math.h
>>  > +++ b/src/gallium/auxiliary/util/u_math.h
>>  > @@ -389,6 +389,26 @@ unsigned ffs( unsigned u )
>>  >  #define ffs __builtin_ffs
>>  >  #endif
>>  >
>>  > +#ifdef HAVE___BUILTIN_FFSLL
>>  > +#define ffsll __builtin_ffsll
>>  > +#else
>>  > +static inline int
>>  > +ffsll(long long int val)
>>  > +{
>>  > +   int bit;
>>  > +
>>
>> Might be better to do
>>
>> if (val & 0x)
>>  return ffs(val &0x);
>> else
>>  return ffs(val >> 32);
>>
>> That may be a little cheaper.  I don't know if its actually better but
>> its one less ffs call (which may cross a library boundary)
>
>
> I like that too, but I just copied the implementation from imports.c
> As was suggested, we can look at consolidating this function and a few
others into src/util/ later.

Seems like as good a reason as any any to keep it as-is.

Reviewed-by: Jason Ekstrand 

> -Brian
>
>> --Jason
>>
>>  > +   bit = ffs((unsigned) (val & 0x));
>>  > +   if (bit != 0)
>>  > +  return bit;
>>  > +
>>  > +   bit = ffs((unsigned) (val >> 32));
>>  > +   if (bit != 0)
>>  > +  return 32 + bit;
>>  > +
>>  > +   return 0;
>>  > +}
>>  > +#endif
>>  > +
>>  >  #endif /* FFS_DEFINED */
>>  >
>>  >  /**
>>  > --
>>  > 1.9.1
>>  >
>>  > ___
>>  > mesa-dev mailing list
>>  > mesa-dev@lists.freedesktop.org 
>>  > http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>> <
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev&d=BQMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=T0t4QG7chq2ZwJo6wilkFznRSFy-8uDKartPGbomVj8&m=u0DJgAjhxxl7RyNVZSQ37HS6W5StpIt-qUTJtm0MFVk&s=_xGcOvu0RaFHWkqySgjs5TAsOM1kiitqJg77nThabd0&e=
>
>>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa: change 'SHADER_SUBST' facility to work with env variables

2015-08-31 Thread Brian Paul


Looks good.  Just some minor nitpicks below.

Reviewed-by: Brian Paul 


On 08/31/2015 01:23 AM, Tapani Pälli wrote:

Patch modifies existing shader source and replace functionality to work
with environment variables rather than enable dumping on compile time.
Also instead of _mesa_str_checksum, _mesa_sha1_compute is used to avoid
collisions.

Functionality is controlled via 2 environment variables:


s/2/two/




MESA_SHADER_DUMP_PATH - path where shader sources are dumped
MESA_SHADER_READ_PATH - path where replacement shaders are read

Signed-off-by: Tapani Pälli 
Suggested-by: Eero Tamminen 
---
  docs/shading.html |   9 +++
  src/mesa/main/shaderapi.c | 136 --
  2 files changed, 105 insertions(+), 40 deletions(-)

diff --git a/docs/shading.html b/docs/shading.html
index 77a0ee4..784329e 100644
--- a/docs/shading.html
+++ b/docs/shading.html
@@ -63,6 +63,15 @@ execution.  These are generally used for debugging.
  Example:  export MESA_GLSL=dump,nopt
  

+
+Shaders can be dumped and replaced on runtime for debugging purposes.
+This is controlled via following environment variables:
+
+MESA_SHADER_DUMP_PATH - path where shader sources are dumped
+MESA_SHADER_READ_PATH - path where replacement shaders are read


Do these directories need to be different to prevent collisions between 
the dumped shaders and the replacement shaders?




+
+Note, path set must exist before running for dumping or replacing to work.
+

  GLSL Version

diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
index 0e0e0d6..d3abfc9 100644
--- a/src/mesa/main/shaderapi.c
+++ b/src/mesa/main/shaderapi.c
@@ -53,15 +53,13 @@
  #include "program/prog_parameter.h"
  #include "util/ralloc.h"
  #include "util/hash_table.h"
+#include "util/mesa-sha1.h"
  #include 
  #include "../glsl/glsl_parser_extras.h"
  #include "../glsl/ir.h"
  #include "../glsl/ir_uniform.h"
  #include "../glsl/program.h"

-/** Define this to enable shader substitution (see below) */
-#define SHADER_SUBST 0
-

  /**
   * Return mask of GLSL_x flags by examining the MESA_GLSL env var.
@@ -1512,24 +1510,101 @@ _mesa_LinkProgram(GLhandleARB programObj)
 link_program(ctx, programObj);
  }

+/**
+ * Generate a SHA-1 hash value string for given source string.
+ */
+static void
+generate_sha1(const char *source, char sha_str[64])
+{
+   unsigned char sha[20];
+   _mesa_sha1_compute(source, strlen(source), sha);
+   _mesa_sha1_format(sha_str, sha);
+}
+
+/**
+ * Construct a full path for shader replacement functionality using
+ * following format:
+ *
+ * /_.glsl
+ */
+static void
+construct_name(const gl_shader_stage stage, const char *source,
+   const char *path, char *name, unsigned length)
+{
+   char sha[64];
+   static const char *types[] = {
+  "VS", "TC", "TE", "GS", "FS", "CS",
+   };

+   generate_sha1(source, sha);
+   _mesa_snprintf(name, length, "%s/%s_%s.glsl", path, types[stage],
+  sha);
+}
+
+/**
+ * Write given shader source to a file in MESA_SHADER_DUMP_PATH.
+ */
+static void
+dump_shader(const gl_shader_stage stage, const char *source)
+{
+   char name[PATH_MAX];
+   static bool path_exists = true;
+   char *dump_path;
+   FILE *f;
+
+   if (!path_exists)
+  return NULL;
+
+   dump_path = getenv("MESA_SHADER_DUMP_PATH");
+


Could remove that empty line.


+   if (!dump_path) {
+  path_exists = false;
+  return NULL;
+   }
+
+   construct_name(stage, source, dump_path, name, PATH_MAX);
+
+   f = fopen(name, "w");
+   if (f) {
+  fputs(source, f);
+  fclose(f);
+   } else {
+  GET_CURRENT_CONTEXT(ctx);
+  _mesa_warning(ctx, "could not open %s for dumping shader", name);
+   }
+}

  /**
   * Read shader source code from a file.
   * Useful for debugging to override an app's shader.
   */
  static GLcharARB *
-read_shader(const char *fname)
+read_shader(const gl_shader_stage stage, const char *source)
  {
-   int shader_size = 0;
-   FILE *f = fopen(fname, "r");
-   GLcharARB *buffer, *shader;
-   int len;
+   char name[PATH_MAX];
+   char *read_path;
+   static bool path_exists = true;
+   int len, shader_size = 0;
+   GLcharARB *buffer;
+   FILE *f;

-   if (!f) {
+   if (!path_exists)
+  return NULL;
+
+   read_path = getenv("MESA_SHADER_READ_PATH");
+
+   if (!read_path) {
+  path_exists = false;
return NULL;
 }

+   construct_name(stage, source, read_path, name, PATH_MAX);
+
+   f = fopen(name, "r");
+


Could remove that empty line.


+   if (!f)
+  return NULL;
+
 /* allocate enough room for the entire shader */
 fseek(f, 0, SEEK_END);
 shader_size = ftell(f);
@@ -1547,13 +1622,9 @@ read_shader(const char *fname)

 fclose(f);

-   shader = strdup(buffer);
-   free(buffer);
-
-   return shader;
+   return buffer;
  }

-
  /**
   * Called via glShaderSource() and glShaderSourceARB() API functions.
   * Basically, concatenate the source code strings into one long string
@@ -1566,14 +1637

[Mesa-dev] Mesa 11.0.0 release candidate 2

2015-08-31 Thread Emil Velikov

The second release candidate for Mesa 11.0.0 is now available.


Chris Wilson (1):
  i965: Always re-emit the pipeline select during invariant state emission

Daniel Scharrer (1):
  mesa: add missing queries for ARB_direct_state_access

Dave Airlie (5):
  mesa/arb_gpu_shader_fp64: add support for glGetUniformdv
  mesa: enable texture stencil8 for multisample
  mesa/texgetimage: fix missing stencil check
  gallium/util: fix debug_get_flags_option on 32-bit
  r600: port si_conv_prim_to_gs_out from radeonsi

Emil Velikov (1):
  Update version to 11.0.0-rc2

Glenn Kennard (4):
  r600g: Fix assert in tgsi_cmp
  r600g/sb: Handle undef in read port tracker
  r600g/sb: Don't read junk after EOP
  r600g/sb: Don't crash on empty if jump target

Ilia Mirkin (5):
  nv50,nvc0: disable depth bounds test on blit
  nv50: account for the int RT0 rule for alpha-to-one/cov
  nv50: fix 2d engine blits for 64- and 128-bit formats
  mesa: only copy the requested teximage faces
  freedreno/a3xx: add basic clip plane support

Jason Ekstrand (1):
  i965/fs: Split VGRFs after lowering pull constants

Marek Olšák (3):
  Revert "radeon/winsys: increase the IB size for VM"
  mesa: create multisample fallback textures like normal textures
  gallium/radeon: fix the ADDRESS_HI mask for EVENT_WRITE CIK packets

Neil Roberts (2):
  i965: Swap the order of the vertex ID and edge flag attributes
  i965/bdw: Fix 3DSTATE_VF_INSTANCING when the edge flag is used


git tag: mesa-11.0.0-rc2

ftp://ftp.freedesktop.org/pub/mesa/10.6.0/mesa-11.0.0-rc2.tar.gz
MD5: 49e4d80f87930ca7b60838f6363fc3d6  mesa-11.0.0-rc2.tar.gz
SHA1: fafd18a79288c4f6e696b4fbc758b83768c0a9cb  mesa-11.0.0-rc2.tar.gz
SHA256: 65b72bc9a92a59f40ae569b0120cbfda60cfab8a8215f6adfe13d163a27993ba  
mesa-11.0.0-rc2.tar.gz
PGP: ftp://ftp.freedesktop.org/pub/mesa/10.6.0/mesa-11.0.0-rc2.tar.gz.sig

ftp://ftp.freedesktop.org/pub/mesa/10.6.0/mesa-11.0.0-rc2.tar.xz
MD5: 9e65faf8df4f122aca61b0c5ce8acb35  mesa-11.0.0-rc2.tar.xz
SHA1: e8f8ebfa769fa5c8cc73f2efdc0e0e5cc18213bc  mesa-11.0.0-rc2.tar.xz
SHA256: e45008b21cc9919c5d4f7c83d69dd15a2f247f8a299be45a0370ed0d26304341  
mesa-11.0.0-rc2.tar.xz
PGP: ftp://ftp.freedesktop.org/pub/mesa/10.6.0/mesa-11.0.0-rc2.tar.xz.sig

--
-Emil



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] nouveau: Use targ in nv50_ir_generate_code

2015-08-31 Thread Marcos Paulo de souza


ping :)

Em 27-08-2015 12:59, Marcos Paulo de Souza escreveu:

instead of call prog->getTarget(), since the target never change in prog.

Signed-off-by: Marcos Paulo de Souza 
---
  src/gallium/drivers/nouveau/codegen/nv50_ir.cpp | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
index cce6055..1dad098 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
@@ -1195,7 +1195,7 @@ nv50_ir_generate_code(struct nv50_ir_prog_info *info)
prog->print();
  
 targ->parseDriverInfo(info);

-   prog->getTarget()->runLegalizePass(prog, nv50_ir::CG_STAGE_PRE_SSA);
+   targ->runLegalizePass(prog, nv50_ir::CG_STAGE_PRE_SSA);
  
 prog->convertToSSA();
  
@@ -1203,7 +1203,7 @@ nv50_ir_generate_code(struct nv50_ir_prog_info *info)

prog->print();
  
 prog->optimizeSSA(info->optLevel);

-   prog->getTarget()->runLegalizePass(prog, nv50_ir::CG_STAGE_SSA);
+   targ->runLegalizePass(prog, nv50_ir::CG_STAGE_SSA);
  
 if (prog->dbgFlags & NV50_IR_DEBUG_BASIC)

prog->print();
@@ -1212,7 +1212,7 @@ nv50_ir_generate_code(struct nv50_ir_prog_info *info)
ret = -4;
goto out;
 }
-   prog->getTarget()->runLegalizePass(prog, nv50_ir::CG_STAGE_POST_RA);
+   targ->runLegalizePass(prog, nv50_ir::CG_STAGE_POST_RA);
  
 prog->optimizePostRA(info->optLevel);
  


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

Re: [Mesa-dev] [PATCH] nouveau: Use targ in nv50_ir_generate_code

2015-08-31 Thread Tobias Klausmann




On 31.08.2015 17:19, Marcos Paulo de souza wrote:

ping :)

Em 27-08-2015 12:59, Marcos Paulo de Souza escreveu:
instead of call prog->getTarget(), since the target never change in 
prog.


It is not changing now, don't know if it will in the future. Using 
prog->getTarget() may save us from hassling with this piece of code 
again. Plus it is more explicit to read in my eyes.




Signed-off-by: Marcos Paulo de Souza 
---
  src/gallium/drivers/nouveau/codegen/nv50_ir.cpp | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp

index cce6055..1dad098 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
@@ -1195,7 +1195,7 @@ nv50_ir_generate_code(struct nv50_ir_prog_info 
*info)

prog->print();
   targ->parseDriverInfo(info);
-   prog->getTarget()->runLegalizePass(prog, nv50_ir::CG_STAGE_PRE_SSA);
+   targ->runLegalizePass(prog, nv50_ir::CG_STAGE_PRE_SSA);
   prog->convertToSSA();
  @@ -1203,7 +1203,7 @@ nv50_ir_generate_code(struct 
nv50_ir_prog_info *info)

prog->print();
   prog->optimizeSSA(info->optLevel);
-   prog->getTarget()->runLegalizePass(prog, nv50_ir::CG_STAGE_SSA);
+   targ->runLegalizePass(prog, nv50_ir::CG_STAGE_SSA);
   if (prog->dbgFlags & NV50_IR_DEBUG_BASIC)
prog->print();
@@ -1212,7 +1212,7 @@ nv50_ir_generate_code(struct nv50_ir_prog_info 
*info)

ret = -4;
goto out;
 }
-   prog->getTarget()->runLegalizePass(prog, nv50_ir::CG_STAGE_POST_RA);
+   targ->runLegalizePass(prog, nv50_ir::CG_STAGE_POST_RA);
   prog->optimizePostRA(info->optLevel);





Greetings,
Tobias

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

Re: [Mesa-dev] [PATCH] nouveau: Use targ in nv50_ir_generate_code

2015-08-31 Thread Ilia Mirkin

On Mon, Aug 31, 2015 at 12:21 PM, Tobias Klausmann
 wrote:
>
>
> On 31.08.2015 17:19, Marcos Paulo de souza wrote:
>>
>> ping :)
>>
>> Em 27-08-2015 12:59, Marcos Paulo de Souza escreveu:
>>>
>>> instead of call prog->getTarget(), since the target never change in prog.
>
>
> It is not changing now, don't know if it will in the future. Using
> prog->getTarget() may save us from hassling with this piece of code again.
> Plus it is more explicit to read in my eyes.

but... targ gets used *right above* each one of those instances.
Changing the target on a program object would be insanity.

>
>
>>>
>>> Signed-off-by: Marcos Paulo de Souza 
>>> ---
>>>   src/gallium/drivers/nouveau/codegen/nv50_ir.cpp | 6 +++---
>>>   1 file changed, 3 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
>>> b/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
>>> index cce6055..1dad098 100644
>>> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
>>> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
>>> @@ -1195,7 +1195,7 @@ nv50_ir_generate_code(struct nv50_ir_prog_info
>>> *info)
>>> prog->print();
>>>targ->parseDriverInfo(info);
>>> -   prog->getTarget()->runLegalizePass(prog, nv50_ir::CG_STAGE_PRE_SSA);
>>> +   targ->runLegalizePass(prog, nv50_ir::CG_STAGE_PRE_SSA);
>>>prog->convertToSSA();
>>>   @@ -1203,7 +1203,7 @@ nv50_ir_generate_code(struct nv50_ir_prog_info
>>> *info)
>>> prog->print();
>>>prog->optimizeSSA(info->optLevel);
>>> -   prog->getTarget()->runLegalizePass(prog, nv50_ir::CG_STAGE_SSA);
>>> +   targ->runLegalizePass(prog, nv50_ir::CG_STAGE_SSA);
>>>if (prog->dbgFlags & NV50_IR_DEBUG_BASIC)
>>> prog->print();
>>> @@ -1212,7 +1212,7 @@ nv50_ir_generate_code(struct nv50_ir_prog_info
>>> *info)
>>> ret = -4;
>>> goto out;
>>>  }
>>> -   prog->getTarget()->runLegalizePass(prog, nv50_ir::CG_STAGE_POST_RA);
>>> +   targ->runLegalizePass(prog, nv50_ir::CG_STAGE_POST_RA);
>>>prog->optimizePostRA(info->optLevel);
>>
>>
>>
>
> Greetings,
> Tobias
>
>
> ___
> 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] nouveau: Use targ in nv50_ir_generate_code

2015-08-31 Thread Tobias Klausmann




On 31.08.2015 18:23, Ilia Mirkin wrote:

On Mon, Aug 31, 2015 at 12:21 PM, Tobias Klausmann
 wrote:


On 31.08.2015 17:19, Marcos Paulo de souza wrote:

ping :)

Em 27-08-2015 12:59, Marcos Paulo de Souza escreveu:

instead of call prog->getTarget(), since the target never change in prog.


It is not changing now, don't know if it will in the future. Using
prog->getTarget() may save us from hassling with this piece of code again.
Plus it is more explicit to read in my eyes.

but... targ gets used *right above* each one of those instances.


Kill it alltogether, meaning lets use prog->getTarget() as a default 
pattern.



Changing the target on a program object would be insanity.




Signed-off-by: Marcos Paulo de Souza 
---
   src/gallium/drivers/nouveau/codegen/nv50_ir.cpp | 6 +++---
   1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
index cce6055..1dad098 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
@@ -1195,7 +1195,7 @@ nv50_ir_generate_code(struct nv50_ir_prog_info
*info)
 prog->print();
targ->parseDriverInfo(info);
-   prog->getTarget()->runLegalizePass(prog, nv50_ir::CG_STAGE_PRE_SSA);
+   targ->runLegalizePass(prog, nv50_ir::CG_STAGE_PRE_SSA);
prog->convertToSSA();
   @@ -1203,7 +1203,7 @@ nv50_ir_generate_code(struct nv50_ir_prog_info
*info)
 prog->print();
prog->optimizeSSA(info->optLevel);
-   prog->getTarget()->runLegalizePass(prog, nv50_ir::CG_STAGE_SSA);
+   targ->runLegalizePass(prog, nv50_ir::CG_STAGE_SSA);
if (prog->dbgFlags & NV50_IR_DEBUG_BASIC)
 prog->print();
@@ -1212,7 +1212,7 @@ nv50_ir_generate_code(struct nv50_ir_prog_info
*info)
 ret = -4;
 goto out;
  }
-   prog->getTarget()->runLegalizePass(prog, nv50_ir::CG_STAGE_POST_RA);
+   targ->runLegalizePass(prog, nv50_ir::CG_STAGE_POST_RA);
prog->optimizePostRA(info->optLevel);




Greetings,
Tobias


___
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] nv3x libreoffice impress opengl animations not working

2015-08-31 Thread Ilia Mirkin

On Mon, Aug 31, 2015 at 8:58 AM, Hans de Goede  wrote:
> Hi,
>
>
> On 28-08-15 11:02, Ilia Mirkin wrote:
>>
>> On Fri, Aug 28, 2015 at 4:54 AM, Hans de Goede 
>> wrote:
>>>
>>> Hi,
>>>
>>> On 27-08-15 20:19, Ilia Mirkin wrote:


 On Thu, Aug 27, 2015 at 1:59 PM, Alex Deucher 
 wrote:
>>>
>>>
>>>
>>> 
>>>
 2) Since the glretrace does work outside of libreoffice impress, I
 think
 it may have something to do with the visual chosen by libreoffice
 impress,
 is there an easy way to find out what visual lo is choosing?
>>>
>>>
>>>
>>>
>>> No, it's not because of the visual. It seems to me that libreoffice
>>> changed the behavior of malloc and calloc.
>>
>>
>>
>>
>> I'm pretty sure that this is not libreoffice changing malloc / calloc,
>> it links normally to libc, and the same slide transition works fine
>> with an nv84 card which also has a gallium based mesa driver.
>>
>> I really believe this is due to libreoffice doing something opengl
>> related differently then glretrace, be it the visual or something else
>> back buffer related ...
>>
>
> Does libreoffice use llvm?  I have vague recollections of there being
> issues with llvm and libreoffice in the past because radeonsi uses
> llvm as well.



 FWIW the nv30 gallium driver will only use llvm as part of 'draw' when
 falling back to the swtnl path. This should be extremely rare. But
 easy enough to build mesa with --disable-gallium-llvm to double-check
 (or what was the env var? DRAW_USE_LLVM=0 or something along those
 lines).
>>>
>>>
>>>
>>> I've tried building with --disable-gallium-llvm, this does not help,
>>> this is not really surprising since on Fedora both libreoffice and
>>> mesa use the system llvm, so there should be no problems with them
>>> expecting different llvm versions.
>>>
>>> I've done some further debugging adding some debug printf-s to the
>>> texture creation paths for nv3x, this bit is interesting, glretrace
>>> does:
>>>
>>> nv30_miptree_from_handle 1350x863 uniform_pitch 6144 usage 0 flags 0
>>> nv30_miptree_create 1350x863 uniform_pitch 5440 usage 0 flags 0 bind 1
>>> target 2
>>>
>>> So it gets a texture from a handle, which I believe is the child-window
>>> in which the animation will be shown, and then create another texture
>>> with the same dimensions to serve as back buffer I presume.
>>>
>>> ooimpress however does this:
>>>
>>> nv30_miptree_from_handle 1350x863 uniform_pitch 6144 usage 0 flags 0
>>> nv30_miptree_create 2700x1726 uniform_pitch 10816 usage 0 flags 0 bind a
>>> target 2
>>> nv30_miptree_create 2700x1726 uniform_pitch 10816 usage 0 flags 0 bind 1
>>> target 2
>>>
>>> Notice how it is creating 2 (back?) buffers and they are twice the size
>>> of
>>> the "sheet" area of impress to which the animation gets rendered.
>>
>>
>> bind a = rt/sampler view, bind 1 = depth/stencil. However nv3x doesn't
>> do NPOT textures... so those sizes are a bit odd. Perhaps there's some
>> logic that attempts to round-up-to-nearest-POT size, but instead
>> multiplies width by 2?
>
>
> Ok, some debugging / poking at thing further I now know where the multiply
> by 2 comes from, the pipe_resource *tmpl passed into nv30_miptree_create
> has templ->nr_samples = 4, and nv30_miptree_create has:
>
>switch (tmpl->nr_samples) {
>case 4:
>   mt->ms_mode = 0x4000;
>   mt->ms_x = 1;
>   mt->ms_y = 1;
>   break;
>case 2:
>   mt->ms_mode = 0x3000;
>   mt->ms_x = 1;
>   mt->ms_y = 0;
>   break;
>default:
>   mt->ms_mode = 0x;
>   mt->ms_x = 0;
>   mt->ms_y = 0;
>   break;
>}
>
> So it seems that glretrace is doing a normal rendering which works,
> where as ooimpress is doing a 4 way msaa rendering which does not work.
>
> Interestingly enough nv30_screen_get_param returns 0 for
> PIPE_CAP_TEXTURE_MULTISAMPLE and for PIPE_CAP_SAMPLER_VIEW_TARGET
>
> And this hack:
>
> --- a/src/gallium/drivers/nouveau/nv30/nv30_screen.c
> +++ b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
> @@ -319,7 +319,7 @@ nv30_screen_is_format_supported(struct pipe_screen
> *pscreen,
>  unsigned sample_count,
>  unsigned bindings)
>  {
> -   if (sample_count > 4)
> +   if (sample_count > 0)
>return false;
> if (!(0x0017 & (1 << sample_count)))
>return false;
>
> Fixes the slide animation misrendering (and sometimes crashing)
> in libreoffice impress.
>
> As said I think this is a hack, I currently do not understand things
> good enough to come up with a better fix.
>
> Hints how to further investigate this are appreciated.

Not surprising that ms gets somehow messed up.
PIPE_CAP_TEXTURE_MULTISAMPLE == ARB_texture_multisample, aka allowing
the existence of MS textures (as opposed to just renderbuffers) as
well as sampling from those

Re: [Mesa-dev] [PATCH] nouveau: Use targ in nv50_ir_generate_code

2015-08-31 Thread Ilia Mirkin

On Mon, Aug 31, 2015 at 12:26 PM, Tobias Klausmann
 wrote:
>
>
> On 31.08.2015 18:23, Ilia Mirkin wrote:
>>
>> On Mon, Aug 31, 2015 at 12:21 PM, Tobias Klausmann
>>  wrote:
>>>
>>>
>>> On 31.08.2015 17:19, Marcos Paulo de souza wrote:

 ping :)

 Em 27-08-2015 12:59, Marcos Paulo de Souza escreveu:
>
> instead of call prog->getTarget(), since the target never change in
> prog.
>>>
>>>
>>> It is not changing now, don't know if it will in the future. Using
>>> prog->getTarget() may save us from hassling with this piece of code
>>> again.
>>> Plus it is more explicit to read in my eyes.
>>
>> but... targ gets used *right above* each one of those instances.
>
>
> Kill it alltogether, meaning lets use prog->getTarget() as a default
> pattern.

Strongly disagree, it's shorter and clearer to just use 'targ' there,
instead of wondering what it is that prog->getTarget() does.

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

Re: [Mesa-dev] Mesa 11.0.0 release candidate 2

2015-08-31 Thread Marek Olšák

Hi Emil,

Would you please also pick this for 11.0:

commit 03b7ec877843cd622717b01c1047e08baf34facf
r600: move prim convert from geom shader to function.

It allegedly fixes a compile failure caused by "r600: port
si_conv_prim_to_gs_out from radeonsi".

Thanks,

Marek

On Mon, Aug 31, 2015 at 5:05 PM, Emil Velikov  wrote:
> The second release candidate for Mesa 11.0.0 is now available.
>
>
> Chris Wilson (1):
>   i965: Always re-emit the pipeline select during invariant state emission
>
> Daniel Scharrer (1):
>   mesa: add missing queries for ARB_direct_state_access
>
> Dave Airlie (5):
>   mesa/arb_gpu_shader_fp64: add support for glGetUniformdv
>   mesa: enable texture stencil8 for multisample
>   mesa/texgetimage: fix missing stencil check
>   gallium/util: fix debug_get_flags_option on 32-bit
>   r600: port si_conv_prim_to_gs_out from radeonsi
>
> Emil Velikov (1):
>   Update version to 11.0.0-rc2
>
> Glenn Kennard (4):
>   r600g: Fix assert in tgsi_cmp
>   r600g/sb: Handle undef in read port tracker
>   r600g/sb: Don't read junk after EOP
>   r600g/sb: Don't crash on empty if jump target
>
> Ilia Mirkin (5):
>   nv50,nvc0: disable depth bounds test on blit
>   nv50: account for the int RT0 rule for alpha-to-one/cov
>   nv50: fix 2d engine blits for 64- and 128-bit formats
>   mesa: only copy the requested teximage faces
>   freedreno/a3xx: add basic clip plane support
>
> Jason Ekstrand (1):
>   i965/fs: Split VGRFs after lowering pull constants
>
> Marek Olšák (3):
>   Revert "radeon/winsys: increase the IB size for VM"
>   mesa: create multisample fallback textures like normal textures
>   gallium/radeon: fix the ADDRESS_HI mask for EVENT_WRITE CIK packets
>
> Neil Roberts (2):
>   i965: Swap the order of the vertex ID and edge flag attributes
>   i965/bdw: Fix 3DSTATE_VF_INSTANCING when the edge flag is used
>
>
> git tag: mesa-11.0.0-rc2
>
> ftp://ftp.freedesktop.org/pub/mesa/10.6.0/mesa-11.0.0-rc2.tar.gz
> MD5: 49e4d80f87930ca7b60838f6363fc3d6  mesa-11.0.0-rc2.tar.gz
> SHA1: fafd18a79288c4f6e696b4fbc758b83768c0a9cb  mesa-11.0.0-rc2.tar.gz
> SHA256: 65b72bc9a92a59f40ae569b0120cbfda60cfab8a8215f6adfe13d163a27993ba  
> mesa-11.0.0-rc2.tar.gz
> PGP: ftp://ftp.freedesktop.org/pub/mesa/10.6.0/mesa-11.0.0-rc2.tar.gz.sig
>
> ftp://ftp.freedesktop.org/pub/mesa/10.6.0/mesa-11.0.0-rc2.tar.xz
> MD5: 9e65faf8df4f122aca61b0c5ce8acb35  mesa-11.0.0-rc2.tar.xz
> SHA1: e8f8ebfa769fa5c8cc73f2efdc0e0e5cc18213bc  mesa-11.0.0-rc2.tar.xz
> SHA256: e45008b21cc9919c5d4f7c83d69dd15a2f247f8a299be45a0370ed0d26304341  
> mesa-11.0.0-rc2.tar.xz
> PGP: ftp://ftp.freedesktop.org/pub/mesa/10.6.0/mesa-11.0.0-rc2.tar.xz.sig
>
> --
> -Emil
>
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Mesa 11.0.0 release candidate 2

2015-08-31 Thread Rob Clark

Emil, could you also cherry-pick:

afb6c24a207fe7b9917644b940e4c5d1870c5c92 and then
000e225360c020e8b3de142c4c898baad321d242

(the 2nd depends on the 1st)

Those fix x11 font rendering (ie. xterm) with glamor..

BR,
-R


On Mon, Aug 31, 2015 at 12:55 PM, Marek Olšák  wrote:
> Hi Emil,
>
> Would you please also pick this for 11.0:
>
> commit 03b7ec877843cd622717b01c1047e08baf34facf
> r600: move prim convert from geom shader to function.
>
> It allegedly fixes a compile failure caused by "r600: port
> si_conv_prim_to_gs_out from radeonsi".
>
> Thanks,
>
> Marek
>
> On Mon, Aug 31, 2015 at 5:05 PM, Emil Velikov  
> wrote:
>> The second release candidate for Mesa 11.0.0 is now available.
>>
>>
>> Chris Wilson (1):
>>   i965: Always re-emit the pipeline select during invariant state 
>> emission
>>
>> Daniel Scharrer (1):
>>   mesa: add missing queries for ARB_direct_state_access
>>
>> Dave Airlie (5):
>>   mesa/arb_gpu_shader_fp64: add support for glGetUniformdv
>>   mesa: enable texture stencil8 for multisample
>>   mesa/texgetimage: fix missing stencil check
>>   gallium/util: fix debug_get_flags_option on 32-bit
>>   r600: port si_conv_prim_to_gs_out from radeonsi
>>
>> Emil Velikov (1):
>>   Update version to 11.0.0-rc2
>>
>> Glenn Kennard (4):
>>   r600g: Fix assert in tgsi_cmp
>>   r600g/sb: Handle undef in read port tracker
>>   r600g/sb: Don't read junk after EOP
>>   r600g/sb: Don't crash on empty if jump target
>>
>> Ilia Mirkin (5):
>>   nv50,nvc0: disable depth bounds test on blit
>>   nv50: account for the int RT0 rule for alpha-to-one/cov
>>   nv50: fix 2d engine blits for 64- and 128-bit formats
>>   mesa: only copy the requested teximage faces
>>   freedreno/a3xx: add basic clip plane support
>>
>> Jason Ekstrand (1):
>>   i965/fs: Split VGRFs after lowering pull constants
>>
>> Marek Olšák (3):
>>   Revert "radeon/winsys: increase the IB size for VM"
>>   mesa: create multisample fallback textures like normal textures
>>   gallium/radeon: fix the ADDRESS_HI mask for EVENT_WRITE CIK packets
>>
>> Neil Roberts (2):
>>   i965: Swap the order of the vertex ID and edge flag attributes
>>   i965/bdw: Fix 3DSTATE_VF_INSTANCING when the edge flag is used
>>
>>
>> git tag: mesa-11.0.0-rc2
>>
>> ftp://ftp.freedesktop.org/pub/mesa/10.6.0/mesa-11.0.0-rc2.tar.gz
>> MD5: 49e4d80f87930ca7b60838f6363fc3d6  mesa-11.0.0-rc2.tar.gz
>> SHA1: fafd18a79288c4f6e696b4fbc758b83768c0a9cb  mesa-11.0.0-rc2.tar.gz
>> SHA256: 65b72bc9a92a59f40ae569b0120cbfda60cfab8a8215f6adfe13d163a27993ba  
>> mesa-11.0.0-rc2.tar.gz
>> PGP: ftp://ftp.freedesktop.org/pub/mesa/10.6.0/mesa-11.0.0-rc2.tar.gz.sig
>>
>> ftp://ftp.freedesktop.org/pub/mesa/10.6.0/mesa-11.0.0-rc2.tar.xz
>> MD5: 9e65faf8df4f122aca61b0c5ce8acb35  mesa-11.0.0-rc2.tar.xz
>> SHA1: e8f8ebfa769fa5c8cc73f2efdc0e0e5cc18213bc  mesa-11.0.0-rc2.tar.xz
>> SHA256: e45008b21cc9919c5d4f7c83d69dd15a2f247f8a299be45a0370ed0d26304341  
>> mesa-11.0.0-rc2.tar.xz
>> PGP: ftp://ftp.freedesktop.org/pub/mesa/10.6.0/mesa-11.0.0-rc2.tar.xz.sig
>>
>> --
>> -Emil
>>
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Mesa 11.0.0 release candidate 2

2015-08-31 Thread Alexander von Gluck IV


Good afternoon,

One more cherry pick for 11.0:

5abbd1caccf4653ac1a8760de68d8ed101c814d8
egl: scons: fix the haiku build, do not build the dri2 backend


Fixes the scons build after support for scons building egl + dri2
was dropped.

 -- Alex

On 2015-08-31 10:05, Emil Velikov wrote:

The second release candidate for Mesa 11.0.0 is now available.


Chris Wilson (1):
  i965: Always re-emit the pipeline select during invariant state 
emission


Daniel Scharrer (1):
  mesa: add missing queries for ARB_direct_state_access

Dave Airlie (5):
  mesa/arb_gpu_shader_fp64: add support for glGetUniformdv
  mesa: enable texture stencil8 for multisample
  mesa/texgetimage: fix missing stencil check
  gallium/util: fix debug_get_flags_option on 32-bit
  r600: port si_conv_prim_to_gs_out from radeonsi

Emil Velikov (1):
  Update version to 11.0.0-rc2

Glenn Kennard (4):
  r600g: Fix assert in tgsi_cmp
  r600g/sb: Handle undef in read port tracker
  r600g/sb: Don't read junk after EOP
  r600g/sb: Don't crash on empty if jump target

Ilia Mirkin (5):
  nv50,nvc0: disable depth bounds test on blit
  nv50: account for the int RT0 rule for alpha-to-one/cov
  nv50: fix 2d engine blits for 64- and 128-bit formats
  mesa: only copy the requested teximage faces
  freedreno/a3xx: add basic clip plane support

Jason Ekstrand (1):
  i965/fs: Split VGRFs after lowering pull constants

Marek Olšák (3):
  Revert "radeon/winsys: increase the IB size for VM"
  mesa: create multisample fallback textures like normal textures
  gallium/radeon: fix the ADDRESS_HI mask for EVENT_WRITE CIK 
packets


Neil Roberts (2):
  i965: Swap the order of the vertex ID and edge flag attributes
  i965/bdw: Fix 3DSTATE_VF_INSTANCING when the edge flag is used


git tag: mesa-11.0.0-rc2

ftp://ftp.freedesktop.org/pub/mesa/10.6.0/mesa-11.0.0-rc2.tar.gz
MD5: 49e4d80f87930ca7b60838f6363fc3d6  mesa-11.0.0-rc2.tar.gz
SHA1: fafd18a79288c4f6e696b4fbc758b83768c0a9cb  mesa-11.0.0-rc2.tar.gz
SHA256:
65b72bc9a92a59f40ae569b0120cbfda60cfab8a8215f6adfe13d163a27993ba
mesa-11.0.0-rc2.tar.gz
PGP: 
ftp://ftp.freedesktop.org/pub/mesa/10.6.0/mesa-11.0.0-rc2.tar.gz.sig


ftp://ftp.freedesktop.org/pub/mesa/10.6.0/mesa-11.0.0-rc2.tar.xz
MD5: 9e65faf8df4f122aca61b0c5ce8acb35  mesa-11.0.0-rc2.tar.xz
SHA1: e8f8ebfa769fa5c8cc73f2efdc0e0e5cc18213bc  mesa-11.0.0-rc2.tar.xz
SHA256:
e45008b21cc9919c5d4f7c83d69dd15a2f247f8a299be45a0370ed0d26304341
mesa-11.0.0-rc2.tar.xz
PGP: 
ftp://ftp.freedesktop.org/pub/mesa/10.6.0/mesa-11.0.0-rc2.tar.xz.sig


--
-Emil


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


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

Re: [Mesa-dev] [PATCH] i965/fs: Use greater-equal cmod to implement maximum.

2015-08-31 Thread Matt Turner

On Fri, Aug 28, 2015 at 6:42 PM, Jordan Justen
 wrote:
> On 2015-08-28 17:12:31, Matt Turner wrote:
>> See commit 3b7f683f.
>
> That commit message seems short enough to replicate, although it is
> also valuable to mention the hash here too.
>
> Reviewed-by: Jordan Justen 

Thanks!

> It almost seems like we could rename emit_minmax to emit_cmpsel,
> optionally make it private, and add emit_min and emit_max.

I like the idea of separate emit_min/emit_max functions (or maybe just
make them macros around emit_minmax).
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 91826] Mesa 11.0.0-rc2 - state_trackers/clover does not build on FreeBSD

2015-08-31 Thread bugzilla-daemon

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

Bug ID: 91826
   Summary: Mesa 11.0.0-rc2 - state_trackers/clover does not build
on FreeBSD
   Product: Mesa
   Version: 11.0
  Hardware: x86-64 (AMD64)
OS: FreeBSD
Status: NEW
  Severity: normal
  Priority: medium
 Component: Other
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: k...@rainbow-runner.nl
QA Contact: mesa-dev@lists.freedesktop.org

Mesa 11.0.0 rc2 doesn't build on FreeBSD with the build failure below. Used
compiler is Clang 3.6.1 and we use llvm's libc++ as c++ standard library.

This seems to be that clang is picky about this piece of code. A quick test
shows that GCC 5.2.1 build the code just fine, even if it issues a warning
about the issue clang errors on. 

Sorry my c++ know how is almost non existing, so can't help with making a patch
for this issue.

Clang:
src/gallium/state_trackers/clover % gmake
  CXX  llvm/libclllvm_la-invocation.lo
llvm/invocation.cpp:388:12: warning: unused variable 'str_node'
  [-Wunused-variable]
  auto str_node = llvm::cast(node->getOperand(0));
   ^
llvm/invocation.cpp:468:40: error: typename specifier refers to non-type member
  'type' in 'clover::module::argument'
typename module::argument::type marg_type;
~~~^~~~
./core/module.hpp:97:15: note: referenced member 'type' is declared here
 type type;
  ^
1 warning and 1 error generated.
Makefile:859: recipe for target 'llvm/libclllvm_la-invocation.lo' failed
gmake: *** [llvm/libclllvm_la-invocation.lo] Error 1


GCC:
  CXXLDlibcltgsi.la
llvm/invocation.cpp: In function 'llvm::MDNode*
{anonymous}::node_from_op_checked(const llvm::MDOperand&, llvm::StringRef,
unsigned int)':
llvm/invocation.cpp:388:12: warning: unused variable 'str_node'
[-Wunused-variable]
   auto str_node = llvm::cast(node->getOperand(0));
^
In file included from ./core/compiler.hpp:27:0,
 from llvm/invocation.cpp:23:
./core/module.hpp: In function 'std::vector
{anonymous}::get_kernel_args(const llvm::Module*, const string&, const unsigned
int (&)[7])':
./core/module.hpp:86:50: warning: 'marg_type' may be used uninitialized in this
function [-Wmaybe-uninitialized]
 ext_type(ext_type), semantic(semantic) { }
  ^
llvm/invocation.cpp:468:45: note: 'marg_type' was declared here
 typename module::argument::type marg_type;
 ^
  CXXLDlibclllvm.la

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

Re: [Mesa-dev] [PATCH 1/2] mesa/texcompress: correct mapping of S3TC formats in conversion function

2015-08-31 Thread Chad Versace

On Wed 26 Aug 2015, Nanley Chery wrote:
> From: Nanley Chery 
> 
> MESA_FORMAT_RGBA_DXT5 should actually be reserved for GL_RGBA[4]_DXT5_S3TC.
> Also, Gallium and other dri drivers (radeon and nouveau) follow this mapping
> scheme.
> 
> Cc: Brian Paul 
> Cc: Chad Versace 
> Cc: Ian Romanick 
> Signed-off-by: Nanley Chery 
> ---
>  src/mesa/main/texcompress.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Reviewed-by: Chad Versace 

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

Re: [Mesa-dev] [PATCH v2 2/2] mesa/texformat: use format conversion function in _mesa_choose_tex_format

2015-08-31 Thread Chad Versace

On Fri 28 Aug 2015, Nanley Chery wrote:
> I should add that this patch enables this function to handle ASTC formats.
> This in turn enables such formats to be used for GL calls such as
> Tex*Storage*.
> 
> - Nanley
> 
> On Wed, Aug 26, 2015 at 2:38 PM, Nanley Chery  wrote:
> 
> > From: Nanley Chery 
> >
> > This function's cases for non-generic compressed formats duplicate
> > the GL to MESA translation in _mesa_glenum_to_compressed_format().
> > This patch replaces the switch cases with a call to the translation
> > function.
> >
> > Cc: Brian Paul 
> > Cc: Chad Versace 
> > Cc: Ian Romanick 
> > Signed-off-by: Nanley Chery 
> > ---
> >  src/mesa/main/texformat.c | 94
> > +++
> >  1 file changed, 13 insertions(+), 81 deletions(-)

This patch looks good to me. Please comment in the commit message that
this change teaches the function about ASTC, thus enabling ASTC for
glTex*Storage*() calls. And then this patch will be
Reviewed-by: Chad Versace 

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

Re: [Mesa-dev] [PATCH] nouveau: Use targ in nv50_ir_generate_code

2015-08-31 Thread Marcos Paulo de souza




Em 31-08-2015 13:31, Ilia Mirkin escreveu:

On Mon, Aug 31, 2015 at 12:26 PM, Tobias Klausmann
 wrote:


On 31.08.2015 18:23, Ilia Mirkin wrote:

On Mon, Aug 31, 2015 at 12:21 PM, Tobias Klausmann
 wrote:


On 31.08.2015 17:19, Marcos Paulo de souza wrote:

ping :)

Em 27-08-2015 12:59, Marcos Paulo de Souza escreveu:

instead of call prog->getTarget(), since the target never change in
prog.


It is not changing now, don't know if it will in the future. Using
prog->getTarget() may save us from hassling with this piece of code
again.
Plus it is more explicit to read in my eyes.

but... targ gets used *right above* each one of those instances.


Kill it alltogether, meaning lets use prog->getTarget() as a default
pattern.

Strongly disagree, it's shorter and clearer to just use 'targ' there,
instead of wondering what it is that prog->getTarget() does.
To keep everybody happy, maybe we can add some methods in prog and use 
the target member of program.


What do you think?


   -ilia


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

Re: [Mesa-dev] [PATCH] nouveau: Use targ in nv50_ir_generate_code

2015-08-31 Thread Ilia Mirkin

On Mon, Aug 31, 2015 at 5:28 PM, Marcos Paulo de souza
 wrote:
>
>
> Em 31-08-2015 13:31, Ilia Mirkin escreveu:
>>
>> On Mon, Aug 31, 2015 at 12:26 PM, Tobias Klausmann
>>  wrote:
>>>
>>>
>>> On 31.08.2015 18:23, Ilia Mirkin wrote:

 On Mon, Aug 31, 2015 at 12:21 PM, Tobias Klausmann
  wrote:
>
>
> On 31.08.2015 17:19, Marcos Paulo de souza wrote:
>>
>> ping :)
>>
>> Em 27-08-2015 12:59, Marcos Paulo de Souza escreveu:
>>>
>>> instead of call prog->getTarget(), since the target never change in
>>> prog.
>
>
> It is not changing now, don't know if it will in the future. Using
> prog->getTarget() may save us from hassling with this piece of code
> again.
> Plus it is more explicit to read in my eyes.

 but... targ gets used *right above* each one of those instances.
>>>
>>>
>>> Kill it alltogether, meaning lets use prog->getTarget() as a default
>>> pattern.
>>
>> Strongly disagree, it's shorter and clearer to just use 'targ' there,
>> instead of wondering what it is that prog->getTarget() does.
>
> To keep everybody happy, maybe we can add some methods in prog and use the
> target member of program.
>
> What do you think?

Like prog->getTarget()? :) I think your patch is fine as-is. I've just
been lazy about pushing it since it's pretty minor and doesn't
actually fix anything. I'll get around to it.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] mesa: Move gl_vert_attrib from mtypes.h to shader_enums.h

2015-08-31 Thread Jason Ekstrand

It is a shader enum after all...
---
 src/glsl/shader_enums.h | 108 
 src/mesa/main/mtypes.h  | 107 ---
 2 files changed, 108 insertions(+), 107 deletions(-)

diff --git a/src/glsl/shader_enums.h b/src/glsl/shader_enums.h
index c6f4678..9bb163f 100644
--- a/src/glsl/shader_enums.h
+++ b/src/glsl/shader_enums.h
@@ -45,6 +45,114 @@ typedef enum
 
 #define MESA_SHADER_STAGES (MESA_SHADER_COMPUTE + 1)
 
+
+/**
+ * Indexes for vertex program attributes.
+ * GL_NV_vertex_program aliases generic attributes over the conventional
+ * attributes.  In GL_ARB_vertex_program shader the aliasing is optional.
+ * In GL_ARB_vertex_shader / OpenGL 2.0 the aliasing is disallowed (the
+ * generic attributes are distinct/separate).
+ */
+typedef enum
+{
+   VERT_ATTRIB_POS = 0,
+   VERT_ATTRIB_WEIGHT = 1,
+   VERT_ATTRIB_NORMAL = 2,
+   VERT_ATTRIB_COLOR0 = 3,
+   VERT_ATTRIB_COLOR1 = 4,
+   VERT_ATTRIB_FOG = 5,
+   VERT_ATTRIB_COLOR_INDEX = 6,
+   VERT_ATTRIB_EDGEFLAG = 7,
+   VERT_ATTRIB_TEX0 = 8,
+   VERT_ATTRIB_TEX1 = 9,
+   VERT_ATTRIB_TEX2 = 10,
+   VERT_ATTRIB_TEX3 = 11,
+   VERT_ATTRIB_TEX4 = 12,
+   VERT_ATTRIB_TEX5 = 13,
+   VERT_ATTRIB_TEX6 = 14,
+   VERT_ATTRIB_TEX7 = 15,
+   VERT_ATTRIB_POINT_SIZE = 16,
+   VERT_ATTRIB_GENERIC0 = 17,
+   VERT_ATTRIB_GENERIC1 = 18,
+   VERT_ATTRIB_GENERIC2 = 19,
+   VERT_ATTRIB_GENERIC3 = 20,
+   VERT_ATTRIB_GENERIC4 = 21,
+   VERT_ATTRIB_GENERIC5 = 22,
+   VERT_ATTRIB_GENERIC6 = 23,
+   VERT_ATTRIB_GENERIC7 = 24,
+   VERT_ATTRIB_GENERIC8 = 25,
+   VERT_ATTRIB_GENERIC9 = 26,
+   VERT_ATTRIB_GENERIC10 = 27,
+   VERT_ATTRIB_GENERIC11 = 28,
+   VERT_ATTRIB_GENERIC12 = 29,
+   VERT_ATTRIB_GENERIC13 = 30,
+   VERT_ATTRIB_GENERIC14 = 31,
+   VERT_ATTRIB_GENERIC15 = 32,
+   VERT_ATTRIB_MAX = 33
+} gl_vert_attrib;
+
+/**
+ * Symbolic constats to help iterating over
+ * specific blocks of vertex attributes.
+ *
+ * VERT_ATTRIB_FF
+ *   includes all fixed function attributes as well as
+ *   the aliased GL_NV_vertex_program shader attributes.
+ * VERT_ATTRIB_TEX
+ *   include the classic texture coordinate attributes.
+ *   Is a subset of VERT_ATTRIB_FF.
+ * VERT_ATTRIB_GENERIC
+ *   include the OpenGL 2.0+ GLSL generic shader attributes.
+ *   These alias the generic GL_ARB_vertex_shader attributes.
+ */
+#define VERT_ATTRIB_FF(i)   (VERT_ATTRIB_POS + (i))
+#define VERT_ATTRIB_FF_MAX  VERT_ATTRIB_GENERIC0
+
+#define VERT_ATTRIB_TEX(i)  (VERT_ATTRIB_TEX0 + (i))
+#define VERT_ATTRIB_TEX_MAX MAX_TEXTURE_COORD_UNITS
+
+#define VERT_ATTRIB_GENERIC(i)  (VERT_ATTRIB_GENERIC0 + (i))
+#define VERT_ATTRIB_GENERIC_MAX MAX_VERTEX_GENERIC_ATTRIBS
+
+/**
+ * Bitflags for vertex attributes.
+ * These are used in bitfields in many places.
+ */
+/*@{*/
+#define VERT_BIT_POS BITFIELD64_BIT(VERT_ATTRIB_POS)
+#define VERT_BIT_WEIGHT  BITFIELD64_BIT(VERT_ATTRIB_WEIGHT)
+#define VERT_BIT_NORMAL  BITFIELD64_BIT(VERT_ATTRIB_NORMAL)
+#define VERT_BIT_COLOR0  BITFIELD64_BIT(VERT_ATTRIB_COLOR0)
+#define VERT_BIT_COLOR1  BITFIELD64_BIT(VERT_ATTRIB_COLOR1)
+#define VERT_BIT_FOG BITFIELD64_BIT(VERT_ATTRIB_FOG)
+#define VERT_BIT_COLOR_INDEX BITFIELD64_BIT(VERT_ATTRIB_COLOR_INDEX)
+#define VERT_BIT_EDGEFLAGBITFIELD64_BIT(VERT_ATTRIB_EDGEFLAG)
+#define VERT_BIT_TEX0BITFIELD64_BIT(VERT_ATTRIB_TEX0)
+#define VERT_BIT_TEX1BITFIELD64_BIT(VERT_ATTRIB_TEX1)
+#define VERT_BIT_TEX2BITFIELD64_BIT(VERT_ATTRIB_TEX2)
+#define VERT_BIT_TEX3BITFIELD64_BIT(VERT_ATTRIB_TEX3)
+#define VERT_BIT_TEX4BITFIELD64_BIT(VERT_ATTRIB_TEX4)
+#define VERT_BIT_TEX5BITFIELD64_BIT(VERT_ATTRIB_TEX5)
+#define VERT_BIT_TEX6BITFIELD64_BIT(VERT_ATTRIB_TEX6)
+#define VERT_BIT_TEX7BITFIELD64_BIT(VERT_ATTRIB_TEX7)
+#define VERT_BIT_POINT_SIZE  BITFIELD64_BIT(VERT_ATTRIB_POINT_SIZE)
+#define VERT_BIT_GENERIC0BITFIELD64_BIT(VERT_ATTRIB_GENERIC0)
+
+#define VERT_BIT(i)  BITFIELD64_BIT(i)
+#define VERT_BIT_ALL BITFIELD64_RANGE(0, VERT_ATTRIB_MAX)
+
+#define VERT_BIT_FF(i)   VERT_BIT(i)
+#define VERT_BIT_FF_ALL  BITFIELD64_RANGE(0, VERT_ATTRIB_FF_MAX)
+#define VERT_BIT_TEX(i)  VERT_BIT(VERT_ATTRIB_TEX(i))
+#define VERT_BIT_TEX_ALL \
+   BITFIELD64_RANGE(VERT_ATTRIB_TEX(0), VERT_ATTRIB_TEX_MAX)
+
+#define VERT_BIT_GENERIC(i)  VERT_BIT(VERT_ATTRIB_GENERIC(i))
+#define VERT_BIT_GENERIC_ALL \
+   BITFIELD64_RANGE(VERT_ATTRIB_GENERIC(0), VERT_ATTRIB_GENERIC_MAX)
+/*@}*/
+
+
 /**
  * Indexes for vertex shader outputs, geometry shader inputs/outputs, and
  * fragment shader inputs.
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index a172952..85a9f5d 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -94,113 +94,6 @@ struct vbo_context;
 #define PRIM_OUTSIDE_BEGIN_END   (PRIM_M

Re: [Mesa-dev] [PATCH demos] egl: Remove demos using EGL_MESA_screen_surface.

2015-08-31 Thread Marek Olšák

Reviewed-by: Marek Olšák 

Marek

On Sat, Aug 29, 2015 at 1:09 AM, Matt Turner  wrote:
> The remnants of the extension were removed from Mesa in commit 7a58262e.
>
> Bugzilla: https://bugs.gentoo.org/show_bug.cgi?id=555186
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91020
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91643
> ---
> demo1 and eglscreen didn't look useful, but maybe demo2 and demo3 are?
> They'd have to be ported to something newer -- EGL_MESA_drm_image?
>
> If someone is interested in porting any of these, I'd be happy to submit
> a smaller patch that simply adds some ifdefs to eglut_screen.c (to make
> it a no-op).
>
>  src/egl/eglut/CMakeLists.txt |   6 -
>  src/egl/eglut/Makefile.am|  10 +-
>  src/egl/eglut/eglut_screen.c | 180 ---
>  src/egl/opengl/.gitignore|   6 -
>  src/egl/opengl/CMakeLists.txt|  17 -
>  src/egl/opengl/Makefile.am   |  11 -
>  src/egl/opengl/demo1.c   | 147 -
>  src/egl/opengl/demo2.c   | 216 -
>  src/egl/opengl/demo3.c   | 647 
> ---
>  src/egl/opengl/eglinfo.c |  45 ---
>  src/egl/opengl/eglscreen.c   | 120 
>  src/egl/opengles1/.gitignore |   4 -
>  src/egl/opengles1/CMakeLists.txt |   4 -
>  src/egl/opengles1/Makefile.am|  14 -
>  src/egl/opengles2/.gitignore |   1 -
>  src/egl/opengles2/CMakeLists.txt |   4 -
>  src/egl/opengles2/Makefile.am|   7 +-
>  src/egl/openvg/.gitignore|   2 -
>  src/egl/openvg/CMakeLists.txt|   4 -
>  src/egl/openvg/Makefile.am   |   8 -
>  20 files changed, 4 insertions(+), 1449 deletions(-)
>  delete mode 100644 src/egl/eglut/eglut_screen.c
>  delete mode 100644 src/egl/opengl/demo1.c
>  delete mode 100644 src/egl/opengl/demo2.c
>  delete mode 100644 src/egl/opengl/demo3.c
>  delete mode 100644 src/egl/opengl/eglscreen.c
>
> diff --git a/src/egl/eglut/CMakeLists.txt b/src/egl/eglut/CMakeLists.txt
> index a885977..0417b48 100644
> --- a/src/egl/eglut/CMakeLists.txt
> +++ b/src/egl/eglut/CMakeLists.txt
> @@ -9,9 +9,3 @@ if (X11_FOUND)
> install (TARGETS eglut_x11 DESTINATION ${LIBDIR})
> endif (BUILD_SHARED_LIBS)
>  endif (X11_FOUND)
> -
> -add_library (eglut_screen eglut.h eglut.c eglutint.h eglut_screen.c)
> -target_link_libraries (eglut_screen ${EGL_LIBRARIES})
> -if (BUILD_SHARED_LIBS)
> -   install (TARGETS eglut_screen DESTINATION ${LIBDIR})
> -endif (BUILD_SHARED_LIBS)
> diff --git a/src/egl/eglut/Makefile.am b/src/egl/eglut/Makefile.am
> index 2d2f2af..b765069 100644
> --- a/src/egl/eglut/Makefile.am
> +++ b/src/egl/eglut/Makefile.am
> @@ -33,17 +33,12 @@ if HAVE_WAYLAND
>  eglut_wayland = libeglut_wayland.la
>  endif
>
> -noinst_LTLIBRARIES = libeglut_screen.la $(eglut_x11) $(eglut_wayland)
> +noinst_LTLIBRARIES = $(eglut_x11) $(eglut_wayland)
>  endif
>
> -libeglut_screen_la_SOURCES = \
> -   eglut.c \
> -   eglut.h \
> -   eglutint.h \
> -   eglut_screen.c
> -
>  libeglut_x11_la_SOURCES = \
> eglut.c \
> +   eglut.h \
> eglutint.h \
> eglut_x11.c
>  libeglut_x11_la_CFLAGS = $(X11_CFLAGS) $(EGL_CFLAGS)
> @@ -52,6 +47,7 @@ libeglut_x11_la_LIBADD = $(X11_LIBS) $(EGL_LIBS)
>
>  libeglut_wayland_la_SOURCES = \
> eglut.c \
> +   eglut.h \
> eglutint.h \
> eglut_wayland.c
>
> diff --git a/src/egl/eglut/eglut_screen.c b/src/egl/eglut/eglut_screen.c
> deleted file mode 100644
> index 021a8f1..000
> --- a/src/egl/eglut/eglut_screen.c
> +++ /dev/null
> @@ -1,180 +0,0 @@
> -/*
> - * Copyright (C) 2010 LunarG Inc.
> - *
> - * 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, sublicense,
> - * 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 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 NONINFRINGEMENT.  IN NO EVENT SHALL
> - * THE AUTHORS OR COPYRIGHT HOLDERS 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.
> - *
> - * Authors:
> - *Chia-I Wu 
> - */
> -
> -#include 
> -#include 
> -#include 
> -
> -#define EGL_EGLEXT_PROTOTYPES
> -#include "EGL/egl.h"
> -#include "EGL/eglext.h"
> -
> -#include "eglutint.h"
> -
> -#define MAX

Re: [Mesa-dev] [PATCH 11/17] nir: Trivial clean ups in the generated nir_constant_expressions.c

2015-08-31 Thread Ian Romanick

On 08/27/2015 06:41 AM, Jason Ekstrand wrote:
> 
> On Aug 27, 2015 4:08 AM, "Ian Romanick"  > wrote:
>>
>> On 08/26/2015 10:11 PM, Jason Ekstrand wrote:
>> > On Wed, Aug 26, 2015 at 10:20 AM, Ian Romanick  > wrote:
>> >> From: Ian Romanick  >
>> >>
>> >> Signed-off-by: Ian Romanick  >
>> >> ---
>> >>  src/glsl/nir/nir_constant_expressions.py | 13 +
>> >>  1 file changed, 5 insertions(+), 8 deletions(-)
>> >>
>> >> diff --git a/src/glsl/nir/nir_constant_expressions.py
> b/src/glsl/nir/nir_constant_expressions.py
>> >> index e2feff3..099bb77 100644
>> >> --- a/src/glsl/nir/nir_constant_expressions.py
>> >> +++ b/src/glsl/nir/nir_constant_expressions.py
>> >> @@ -226,7 +226,6 @@ static nir_const_value
>> >>  evaluate_${name}(unsigned num_components, nir_const_value *_src)
>> >>  {
>> >> nir_const_value _dst_val = { { {0, 0, 0, 0} } };
>> >> -
>> >
>> > I'd keep the blank line
>> >
>> >> ## For each non-per-component input, create a variable srcN that
>> >> ## contains x, y, z, and w elements which are filled in with the
>> >> ## appropriately-typed values.
>> >> @@ -238,7 +237,7 @@ evaluate_${name}(unsigned num_components,
> nir_const_value *_src)
>> >>   <% continue %>
>> >>%endif
>> >>
>> >> -   struct ${op.input_types[j]}_vec src${j} = {
>> >> +   const struct ${op.input_types[j]}_vec src${j} = {
>> >>% for k in range(op.input_sizes[j]):
>> >>   % if op.input_types[j] == "bool":
>> >>_src[${j}].u[${k}] != 0,
>> >> @@ -280,17 +279,17 @@ evaluate_${name}(unsigned num_components,
> nir_const_value *_src)
>> >> ## Avoid unused variable warnings
>> >> <% continue %>
>> >>  % elif op.input_types[j] == "bool":
>> >> -  bool src${j} = _src[${j}].u[_i] != 0;
>> >> +  const bool src${j} = _src[${j}].u[_i] != 0;
>> >>  % else:
>> >> -  ${op.input_types[j]} src${j} =
> _src[${j}].${op.input_types[j][:1]}[_i];
>> >> +  const ${op.input_types[j]} src${j} =
> _src[${j}].${op.input_types[j][:1]}[_i];
>> >>  % endif
>> >>   % endfor
>> >> -
>> >
>> > Same here.  Other than that, I like the cleanup.  With the blank
> lines kept,
>>
>> You should look at the generated code.  To me, the spurious blank lines
>> are the most objectionable part.  If someone submitted C code formatted
>> that way, we'd tell them to go fix it.  Right?
> 
> The generator, not the generated C code, is what's checked into the repo
> and is what people will be editing. I'd far rather keep that clean. 
> Again just run it through indent if it bothers you.

What, exactly, do the spurious blank lines in the generator add to
readability?  Having the C code in the generator consistently formatted
_as C code in this project_ and they Mako consistently indented as Mako
seems much more logical... otherwise you have to actually go look at the
generated code to see what the flow of the generated C code is intended
to be.  That's just weird.

Also like I said before... we have NEVER used indent during the build
except in cases where it was absolutely necessary.  I see no reason to
start now.

>> > Reviewed-by: Jason Ekstrand  >
>> >
>> >>   ## Create an appropriately-typed variable dst and assign the
>> >>   ## result of the const_expr to it.  If const_expr already
> contains
>> >>   ## writes to dst, just include const_expr directly.
>> >>   % if "dst" in op.const_expr:
>> >>${op.output_type} dst;
>> >> +
>> >>${op.const_expr}
>> >>   % else:
>> >>${op.output_type} dst = ${op.const_expr};
>> >> @@ -344,10 +343,8 @@ nir_eval_const_opcode(nir_op op, unsigned
> num_components,
>> >>  {
>> >> switch (op) {
>> >>  % for name in sorted(opcodes.iterkeys()):
>> >> -   case nir_op_${name}: {
>> >> +   case nir_op_${name}:
>> >>return evaluate_${name}(num_components, src);
>> >> -  break;
>> >> -   }
>> >>  % endfor
>> >> default:
>> >>unreachable("shouldn't get here");
>> >> --
>> >> 2.1.0
>> >>
>> >> ___
>> >> mesa-dev mailing list
>> >> mesa-dev@lists.freedesktop.org 
>> >> http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

Re: [Mesa-dev] [PATCH] i965: Don't check for draw-time errors that cannot occur in core profile

2015-08-31 Thread Ian Romanick

ping. :)

On 08/10/2015 11:48 AM, Matt Turner wrote:
> On Mon, Aug 10, 2015 at 10:12 AM, Ian Romanick  wrote:
>> From: Ian Romanick 
>>
>> On many CPU-limited applications, this is *the* hot path.  The idea is
>> to generate per-API versions of brw_draw_prims that elide some checks.
>> This patch removes render-mode and "is everything in VBOs" checks from
>> core-profile contexts.
>>
>> On my IVB laptop (which may have experienced thermal throttling):
>>
>> Gl32Batch7: 3.70955% +/- 1.11344%
> 
> I'm getting 3.18414% +/- 0.587956% (n=113) on my IVB, , which probably
> matches your numbers depending on your value of n.
> 
>> OglBatch7:  1.04398% +/- 0.772788%
> 
> I'm getting 1.15377% +/- 1.05898% (n=34) on my IVB, which probably
> matches your numbers depending on your value of n.

This is another thing that make me feel a little uncomfortable with the
way we've done performance measurements in the past.  If I run my test
before and after this patch for 121 iterations, which I have done, I can
cut the data at any point and oscillate between "no difference" or X%
+/- some-large-fraction-of-X%.  Since the before and after code for the
compatibility profile path should be identical, "no difference" is the
only believable result.

Using a higher confidence threshold (e.g., -c 98) results in "no
difference" throughout, as expected.  I feel like 90% isn't a tight
enough confidence interval for a lot of what we do, but I'm unsure how
to determine what confidence level we should use.  We could
experimentally determine it by running a test some number of times and
finding the interval that detects no change in some random partitioning
of the test results.  Ugh.

> I'll review soon.


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

Re: [Mesa-dev] [PATCH] i965: Don't check for draw-time errors that cannot occur in core profile

2015-08-31 Thread Ilia Mirkin

On Mon, Aug 31, 2015 at 7:06 PM, Ian Romanick  wrote:
> ping. :)
>
> On 08/10/2015 11:48 AM, Matt Turner wrote:
>> On Mon, Aug 10, 2015 at 10:12 AM, Ian Romanick  wrote:
>>> From: Ian Romanick 
>>>
>>> On many CPU-limited applications, this is *the* hot path.  The idea is
>>> to generate per-API versions of brw_draw_prims that elide some checks.
>>> This patch removes render-mode and "is everything in VBOs" checks from
>>> core-profile contexts.
>>>
>>> On my IVB laptop (which may have experienced thermal throttling):
>>>
>>> Gl32Batch7: 3.70955% +/- 1.11344%
>>
>> I'm getting 3.18414% +/- 0.587956% (n=113) on my IVB, , which probably
>> matches your numbers depending on your value of n.
>>
>>> OglBatch7:  1.04398% +/- 0.772788%
>>
>> I'm getting 1.15377% +/- 1.05898% (n=34) on my IVB, which probably
>> matches your numbers depending on your value of n.
>
> This is another thing that make me feel a little uncomfortable with the
> way we've done performance measurements in the past.  If I run my test
> before and after this patch for 121 iterations, which I have done, I can
> cut the data at any point and oscillate between "no difference" or X%
> +/- some-large-fraction-of-X%.  Since the before and after code for the
> compatibility profile path should be identical, "no difference" is the
> only believable result.
>
> Using a higher confidence threshold (e.g., -c 98) results in "no
> difference" throughout, as expected.  I feel like 90% isn't a tight
> enough confidence interval for a lot of what we do, but I'm unsure how
> to determine what confidence level we should use.  We could
> experimentally determine it by running a test some number of times and
> finding the interval that detects no change in some random partitioning
> of the test results.  Ugh.

(sorry, statistics rant below, can't help myself)

AFAIK the standard in statistics is to use a 95% confidence interval.
Unless you have 'statistician' in your job title [or someone with that
job title has indicated otherwise], that's what you should probably
use. Using anything lower than that is a way of saying "This
scientific study isn't turning out the way I wanted, I'm going to have
to take matters into my own hands".

Of course note that if you do run the same experiment 20 times, you
should expect one of those 20 times to yield a confidence interval
that does not include the true mean. And in general I'd be very
suspicious of results where the change is near the confidence interval
boundary.

And lastly, all this statistics stuff assumes that you're evaluating
the same normal distribution repeatedly. This isn't exactly true, but
it's true enough. However you can try to get more accurate by
experimentally determining a fudge factor on the CI width. You could
run (literal) no-op experiments lots of times and fudge the output of
the CI width calculation until it matches up with empirical results,
e.g. if you run the same experiment 100x and use a 95% CI, fudge the
outcome until you end up with 5 significant results and 95
insignificant ones. Ideally such a fudge factor should not be too
different from 1, or else you have a very non-normal distribution, and
fudge factors ain't gonna help you. Note that any computed fudge
factors could not be shared among machine groups that weren't used to
determine them, so I'm not seriously recommending this approach, but
thought I'd mention it.

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

Re: [Mesa-dev] [PATCH 5/6] mesa/formats: add some formats from GL3.3

2015-08-31 Thread Brian Paul


On 08/25/2015 07:14 PM, Dave Airlie wrote:

From: Dave Airlie 

GL3.3 added GL_ARB_texture_rgb10_a2ui, which specifies
a lot more things than just rgb10/a2ui.

While playing with ogl conform one of the tests must
attempted all valid formats for GL3.3 and hits the
unreachable here.

This adds the first chunk of formats that hit the
assert.

Signed-off-by: Dave Airlie 


Hi Dave,

I stumbled across this area when working on a new GL_ARB_copy_image 
test, but it's really a GL_EXT_texture_integer issue.  So I wrote a new 
piglit test (see my recent review request) that exercises glTexImage2D 
and glGetTexImage with the GL_EXT_texture_integer formats.  It passes 
with NVIDIA but hits an assertion in Mesa:


ext_texture_integer-texformats: main/glformats.c:2895: 
_mesa_format_from_format_and_type: Assertion `!"Unsupported format"' failed.


The issue is, when calling glTexImage2D(intFormat=GL_RGBA8UI, 
format=GL_RGBA_INTEGER, type=GL_UNSIGNED_INT_8_8_8_8) the texstore code 
tries to find a Mesa format which exactly matches GL_RGBA_INTEGER + 
GL_UNSIGNED_INT_8_8_8_8 and fails.


It looks like your patch _should_ fix this.

Dave, can you check my new piglit test against your patch?  I've run out 
of time to check it myself today.  If it passes, I'll take a closer look 
at your Mesa patch.  I think you're still waiting on a review of it.


-Brian

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

Re: [Mesa-dev] [PATCH 5/6] mesa/formats: add some formats from GL3.3

2015-08-31 Thread Dave Airlie

On 1 September 2015 at 09:34, Brian Paul  wrote:
> On 08/25/2015 07:14 PM, Dave Airlie wrote:
>>
>> From: Dave Airlie 
>>
>> GL3.3 added GL_ARB_texture_rgb10_a2ui, which specifies
>> a lot more things than just rgb10/a2ui.
>>
>> While playing with ogl conform one of the tests must
>> attempted all valid formats for GL3.3 and hits the
>> unreachable here.
>>
>> This adds the first chunk of formats that hit the
>> assert.
>>
>> Signed-off-by: Dave Airlie 
>
>
> Hi Dave,
>
> I stumbled across this area when working on a new GL_ARB_copy_image test,
> but it's really a GL_EXT_texture_integer issue.  So I wrote a new piglit
> test (see my recent review request) that exercises glTexImage2D and
> glGetTexImage with the GL_EXT_texture_integer formats.  It passes with
> NVIDIA but hits an assertion in Mesa:
>
> ext_texture_integer-texformats: main/glformats.c:2895:
> _mesa_format_from_format_and_type: Assertion `!"Unsupported format"' failed.
>
> The issue is, when calling glTexImage2D(intFormat=GL_RGBA8UI,
> format=GL_RGBA_INTEGER, type=GL_UNSIGNED_INT_8_8_8_8) the texstore code
> tries to find a Mesa format which exactly matches GL_RGBA_INTEGER +
> GL_UNSIGNED_INT_8_8_8_8 and fails.
>
> It looks like your patch _should_ fix this.
>
> Dave, can you check my new piglit test against your patch?  I've run out of
> time to check it myself today.  If it passes, I'll take a closer look at
> your Mesa patch.  I think you're still waiting on a review of it.

Hi Brian,

This patch won't fix that, the second one will, but I'll try giving it
a run today.

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

[Mesa-dev] [PATCH] i965: enable ASTC for Cherryview

2015-08-31 Thread Nanley Chery

From: Nanley Chery 

Add modifications necessary to get ASTC functional on Cherryview.

Cc: Chad Versace 
Signed-off-by: Nanley Chery 
---
 src/mesa/drivers/dri/i965/brw_defines.h|  1 +
 src/mesa/drivers/dri/i965/brw_tex_layout.c | 55 +++---
 src/mesa/drivers/dri/i965/gen8_surface_state.c |  6 +++
 src/mesa/drivers/dri/i965/intel_extensions.c   |  4 +-
 4 files changed, 51 insertions(+), 15 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_defines.h 
b/src/mesa/drivers/dri/i965/brw_defines.h
index 07fe198..4f3092f 100644
--- a/src/mesa/drivers/dri/i965/brw_defines.h
+++ b/src/mesa/drivers/dri/i965/brw_defines.h
@@ -537,6 +537,7 @@
 #define BRW_SURFACEFORMAT_ASTC_LDR_2D_12x10_FLT160x27E
 #define BRW_SURFACEFORMAT_ASTC_LDR_2D_12x12_FLT160x27F
 
+#define BRW_SURFACE_FORMAT_IS_ASTC(format)   ((format) & 0x200)
 #define BRW_SURFACE_FORMAT_SHIFT   18
 #define BRW_SURFACE_FORMAT_MASKINTEL_MASK(26, 18)
 
diff --git a/src/mesa/drivers/dri/i965/brw_tex_layout.c 
b/src/mesa/drivers/dri/i965/brw_tex_layout.c
index 268b995..a08e0ab 100644
--- a/src/mesa/drivers/dri/i965/brw_tex_layout.c
+++ b/src/mesa/drivers/dri/i965/brw_tex_layout.c
@@ -34,6 +34,8 @@
 
 #include "intel_mipmap_tree.h"
 #include "brw_context.h"
+#include "brw_defines.h"
+#include "brw_state.h"
 #include "main/macros.h"
 #include "main/glformats.h"
 
@@ -302,8 +304,17 @@ gen9_miptree_layout_1d(struct intel_mipmap_tree *mt)
}
 }
 
+static inline bool
+is_astc_chv(const struct brw_context *brw,
+const struct intel_mipmap_tree *mt)
+{
+   return brw->is_cherryview &&
+  BRW_SURFACE_FORMAT_IS_ASTC(brw_format_for_mesa_format(mt->format));
+}
+
 static void
-brw_miptree_layout_2d(struct intel_mipmap_tree *mt)
+brw_miptree_layout_2d(const struct brw_context *brw,
+  struct intel_mipmap_tree *mt)
 {
unsigned x = 0;
unsigned y = 0;
@@ -335,6 +346,17 @@ brw_miptree_layout_2d(struct intel_mipmap_tree *mt)
  minify(mt->physical_width0, 2);
}
 
+   /* Cherryview requires that all miplevels get shifted over 3 blocks for
+* ASTC formats with block width of 5 and certain mip1 widths.
+*/
+   if (is_astc_chv(brw, mt) && bw == 5) {
+  unsigned int mip1_width_mod = minify(mt->physical_width0, 1) % 10;
+  if (mip1_width_mod && mip1_width_mod <= bw) {
+ x = 3;
+ mip1_width += x*bw;
+  }
+   }
+
if (mip1_width > mt->total_width) {
mt->total_width = mip1_width;
}
@@ -481,7 +503,7 @@ brw_miptree_layout_texture_array(struct brw_context *brw,
if (layout_1d)
   gen9_miptree_layout_1d(mt);
else
-  brw_miptree_layout_2d(mt);
+  brw_miptree_layout_2d(brw, mt);
 
if (layout_1d) {
   physical_qpitch = 1;
@@ -492,12 +514,18 @@ brw_miptree_layout_texture_array(struct brw_context *brw,
*/
   mt->qpitch = mt->total_width;
} else {
-  mt->qpitch = brw_miptree_get_vertical_slice_pitch(brw, mt, 0);
+
   /* Unlike previous generations the qpitch is a multiple of the
* compressed block size on Gen9 so physical_qpitch matches mt->qpitch.
*/
-  physical_qpitch = (mt->compressed && brw->gen < 9 ? mt->qpitch / 4 :
- mt->qpitch);
+  physical_qpitch = mt->qpitch = brw_miptree_get_vertical_slice_pitch(brw, 
mt, 0);
+
+  if (mt->compressed && brw->gen < 9) {
+ unsigned bh, bw;
+ _mesa_get_format_block_size(mt->format, &bw, &bh);
+ physical_qpitch /= bh;
+  }
+
}
 
for (unsigned level = mt->first_level; level <= mt->last_level; level++) {
@@ -705,7 +733,7 @@ intel_miptree_set_total_width_height(struct brw_context 
*brw,
  if (gen9_use_linear_1d_layout(brw, mt))
 gen9_miptree_layout_1d(mt);
  else
-brw_miptree_layout_2d(mt);
+brw_miptree_layout_2d(brw, mt);
  break;
   }
   break;
@@ -772,7 +800,10 @@ intel_miptree_set_alignment(struct brw_context *brw,
   if (brw->gen >= 9) {
  mt->align_w *= 4;
  mt->align_h *= 4;
+  } else if (is_astc_chv(brw, mt)) {
+ mt->align_h *= 4;
   }
+
} else if (mt->format == MESA_FORMAT_S_UINT8) {
   mt->align_w = 8;
   mt->align_h = brw->gen >= 7 ? 8 : 4;
@@ -803,14 +834,10 @@ brw_miptree_layout(struct brw_context *brw,
   return;
}
 
-   /* On Gen9+ the alignment values are expressed in multiples of the block
-* size
-*/
-   if (brw->gen >= 9) {
-  unsigned int i, j;
-  _mesa_get_format_block_size(mt->format, &i, &j);
-  mt->align_w /= i;
-  mt->align_h /= j;
+   /* On CHV and Gen9+ scale down the alignment to valid values for HW */
+   if (mt->compressed && (brw->gen >= 9 || is_astc_chv(brw, mt))) {
+ mt->align_w = 4;
+ mt->align_h = 4;
}
 
if ((layout_flags & MIPTREE_LAYOUT_FOR_BO) == 0)
diff --git a/src/mesa/drivers/

[Mesa-dev] [PATCH] nir/builder: Use nir_after_instr to advance the cursor

2015-08-31 Thread Jason Ekstrand

This *should* ensure that the cursor gets properly advanced in all cases.
We had a problem before where, if the cursor was created using
nir_after_cf_node on a non-block cf_node, that would call nir_before_block
on the block following the cf node.  Instructions would then get inserted
in backwards order at the top of the block which is not at all what you
would expect from nir_after_cf_node.  By just resetting to after_instr, we
avoid all these problems.
---
 src/glsl/nir/nir_builder.h | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/glsl/nir/nir_builder.h b/src/glsl/nir/nir_builder.h
index 3aa0efd..295a209 100644
--- a/src/glsl/nir/nir_builder.h
+++ b/src/glsl/nir/nir_builder.h
@@ -49,8 +49,7 @@ nir_builder_instr_insert(nir_builder *build, nir_instr *instr)
nir_instr_insert(build->cursor, instr);
 
/* Move the cursor forward. */
-   if (build->cursor.option == nir_cursor_after_instr)
-  build->cursor.instr = instr;
+   build->cursor = nir_after_instr(instr);
 }
 
 static inline void
-- 
2.5.0.400.gff86faf

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

Re: [Mesa-dev] [PATCH] i965: enable ASTC for Cherryview

2015-08-31 Thread Matt Turner

On Mon, Aug 31, 2015 at 4:45 PM, Nanley Chery  wrote:
> From: Nanley Chery 
>
> Add modifications necessary to get ASTC functional on Cherryview.
>
> Cc: Chad Versace 
> Signed-off-by: Nanley Chery 
> ---
>  src/mesa/drivers/dri/i965/brw_defines.h|  1 +
>  src/mesa/drivers/dri/i965/brw_tex_layout.c | 55 
> +++---
>  src/mesa/drivers/dri/i965/gen8_surface_state.c |  6 +++
>  src/mesa/drivers/dri/i965/intel_extensions.c   |  4 +-
>  4 files changed, 51 insertions(+), 15 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_defines.h 
> b/src/mesa/drivers/dri/i965/brw_defines.h
> index 07fe198..4f3092f 100644
> --- a/src/mesa/drivers/dri/i965/brw_defines.h
> +++ b/src/mesa/drivers/dri/i965/brw_defines.h
> @@ -537,6 +537,7 @@
>  #define BRW_SURFACEFORMAT_ASTC_LDR_2D_12x10_FLT160x27E
>  #define BRW_SURFACEFORMAT_ASTC_LDR_2D_12x12_FLT160x27F
>
> +#define BRW_SURFACE_FORMAT_IS_ASTC(format)   ((format) & 0x200)
>  #define BRW_SURFACE_FORMAT_SHIFT   18
>  #define BRW_SURFACE_FORMAT_MASKINTEL_MASK(26, 18)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_tex_layout.c 
> b/src/mesa/drivers/dri/i965/brw_tex_layout.c
> index 268b995..a08e0ab 100644
> --- a/src/mesa/drivers/dri/i965/brw_tex_layout.c
> +++ b/src/mesa/drivers/dri/i965/brw_tex_layout.c
> @@ -34,6 +34,8 @@
>
>  #include "intel_mipmap_tree.h"
>  #include "brw_context.h"
> +#include "brw_defines.h"
> +#include "brw_state.h"
>  #include "main/macros.h"
>  #include "main/glformats.h"
>
> @@ -302,8 +304,17 @@ gen9_miptree_layout_1d(struct intel_mipmap_tree *mt)
> }
>  }
>
> +static inline bool
> +is_astc_chv(const struct brw_context *brw,
> +const struct intel_mipmap_tree *mt)
> +{
> +   return brw->is_cherryview &&
> +  BRW_SURFACE_FORMAT_IS_ASTC(brw_format_for_mesa_format(mt->format));
> +}
> +
>  static void
> -brw_miptree_layout_2d(struct intel_mipmap_tree *mt)
> +brw_miptree_layout_2d(const struct brw_context *brw,
> +  struct intel_mipmap_tree *mt)
>  {
> unsigned x = 0;
> unsigned y = 0;
> @@ -335,6 +346,17 @@ brw_miptree_layout_2d(struct intel_mipmap_tree *mt)
>   minify(mt->physical_width0, 2);
> }
>
> +   /* Cherryview requires that all miplevels get shifted over 3 blocks 
> for
> +* ASTC formats with block width of 5 and certain mip1 widths.
> +*/
> +   if (is_astc_chv(brw, mt) && bw == 5) {
> +  unsigned int mip1_width_mod = minify(mt->physical_width0, 1) % 10;
> +  if (mip1_width_mod && mip1_width_mod <= bw) {
> + x = 3;
> + mip1_width += x*bw;
> +  }
> +   }
> +
> if (mip1_width > mt->total_width) {
> mt->total_width = mip1_width;
> }
> @@ -481,7 +503,7 @@ brw_miptree_layout_texture_array(struct brw_context *brw,
> if (layout_1d)
>gen9_miptree_layout_1d(mt);
> else
> -  brw_miptree_layout_2d(mt);
> +  brw_miptree_layout_2d(brw, mt);
>
> if (layout_1d) {
>physical_qpitch = 1;
> @@ -492,12 +514,18 @@ brw_miptree_layout_texture_array(struct brw_context 
> *brw,
> */
>mt->qpitch = mt->total_width;
> } else {
> -  mt->qpitch = brw_miptree_get_vertical_slice_pitch(brw, mt, 0);
> +
>/* Unlike previous generations the qpitch is a multiple of the
> * compressed block size on Gen9 so physical_qpitch matches mt->qpitch.
> */
> -  physical_qpitch = (mt->compressed && brw->gen < 9 ? mt->qpitch / 4 :
> - mt->qpitch);
> +  physical_qpitch = mt->qpitch = 
> brw_miptree_get_vertical_slice_pitch(brw, mt, 0);
> +
> +  if (mt->compressed && brw->gen < 9) {
> + unsigned bh, bw;
> + _mesa_get_format_block_size(mt->format, &bw, &bh);
> + physical_qpitch /= bh;
> +  }
> +
> }
>
> for (unsigned level = mt->first_level; level <= mt->last_level; level++) {
> @@ -705,7 +733,7 @@ intel_miptree_set_total_width_height(struct brw_context 
> *brw,
>   if (gen9_use_linear_1d_layout(brw, mt))
>  gen9_miptree_layout_1d(mt);
>   else
> -brw_miptree_layout_2d(mt);
> +brw_miptree_layout_2d(brw, mt);
>   break;
>}
>break;
> @@ -772,7 +800,10 @@ intel_miptree_set_alignment(struct brw_context *brw,
>if (brw->gen >= 9) {
>   mt->align_w *= 4;
>   mt->align_h *= 4;
> +  } else if (is_astc_chv(brw, mt)) {
> + mt->align_h *= 4;
>}
> +
> } else if (mt->format == MESA_FORMAT_S_UINT8) {
>mt->align_w = 8;
>mt->align_h = brw->gen >= 7 ? 8 : 4;
> @@ -803,14 +834,10 @@ brw_miptree_layout(struct brw_context *brw,
>return;
> }
>
> -   /* On Gen9+ the alignment values are expressed in multiples of the block
> -* size
> -*/
> -   if (brw->gen >= 9) {
> -  unsigned int i, j;
> -  _mesa_get_format_block_size(mt->format, &i, &j);
> -  mt->alig

Re: [Mesa-dev] [PATCH] i965: enable ASTC for Cherryview

2015-08-31 Thread Nanley Chery

On Mon, Aug 31, 2015 at 4:58 PM, Matt Turner  wrote:

> On Mon, Aug 31, 2015 at 4:45 PM, Nanley Chery 
> wrote:
> > From: Nanley Chery 
> >
> > Add modifications necessary to get ASTC functional on Cherryview.
> >
> > Cc: Chad Versace 
> > Signed-off-by: Nanley Chery 
> > ---
> >  src/mesa/drivers/dri/i965/brw_defines.h|  1 +
> >  src/mesa/drivers/dri/i965/brw_tex_layout.c | 55
> +++---
> >  src/mesa/drivers/dri/i965/gen8_surface_state.c |  6 +++
> >  src/mesa/drivers/dri/i965/intel_extensions.c   |  4 +-
> >  4 files changed, 51 insertions(+), 15 deletions(-)
> >
> > diff --git a/src/mesa/drivers/dri/i965/brw_defines.h
> b/src/mesa/drivers/dri/i965/brw_defines.h
> > index 07fe198..4f3092f 100644
> > --- a/src/mesa/drivers/dri/i965/brw_defines.h
> > +++ b/src/mesa/drivers/dri/i965/brw_defines.h
> > @@ -537,6 +537,7 @@
> >  #define BRW_SURFACEFORMAT_ASTC_LDR_2D_12x10_FLT160x27E
> >  #define BRW_SURFACEFORMAT_ASTC_LDR_2D_12x12_FLT160x27F
> >
> > +#define BRW_SURFACE_FORMAT_IS_ASTC(format)   ((format) & 0x200)
> >  #define BRW_SURFACE_FORMAT_SHIFT   18
> >  #define BRW_SURFACE_FORMAT_MASKINTEL_MASK(26, 18)
> >
> > diff --git a/src/mesa/drivers/dri/i965/brw_tex_layout.c
> b/src/mesa/drivers/dri/i965/brw_tex_layout.c
> > index 268b995..a08e0ab 100644
> > --- a/src/mesa/drivers/dri/i965/brw_tex_layout.c
> > +++ b/src/mesa/drivers/dri/i965/brw_tex_layout.c
> > @@ -34,6 +34,8 @@
> >
> >  #include "intel_mipmap_tree.h"
> >  #include "brw_context.h"
> > +#include "brw_defines.h"
> > +#include "brw_state.h"
> >  #include "main/macros.h"
> >  #include "main/glformats.h"
> >
> > @@ -302,8 +304,17 @@ gen9_miptree_layout_1d(struct intel_mipmap_tree *mt)
> > }
> >  }
> >
> > +static inline bool
> > +is_astc_chv(const struct brw_context *brw,
> > +const struct intel_mipmap_tree *mt)
> > +{
> > +   return brw->is_cherryview &&
> > +
> BRW_SURFACE_FORMAT_IS_ASTC(brw_format_for_mesa_format(mt->format));
> > +}
> > +
> >  static void
> > -brw_miptree_layout_2d(struct intel_mipmap_tree *mt)
> > +brw_miptree_layout_2d(const struct brw_context *brw,
> > +  struct intel_mipmap_tree *mt)
> >  {
> > unsigned x = 0;
> > unsigned y = 0;
> > @@ -335,6 +346,17 @@ brw_miptree_layout_2d(struct intel_mipmap_tree *mt)
> >   minify(mt->physical_width0, 2);
> > }
> >
> > +   /* Cherryview requires that all miplevels get shifted over 3
> blocks for
> > +* ASTC formats with block width of 5 and certain mip1 widths.
> > +*/
> > +   if (is_astc_chv(brw, mt) && bw == 5) {
> > +  unsigned int mip1_width_mod = minify(mt->physical_width0, 1)
> % 10;
> > +  if (mip1_width_mod && mip1_width_mod <= bw) {
> > + x = 3;
> > + mip1_width += x*bw;
> > +  }
> > +   }
> > +
> > if (mip1_width > mt->total_width) {
> > mt->total_width = mip1_width;
> > }
> > @@ -481,7 +503,7 @@ brw_miptree_layout_texture_array(struct brw_context
> *brw,
> > if (layout_1d)
> >gen9_miptree_layout_1d(mt);
> > else
> > -  brw_miptree_layout_2d(mt);
> > +  brw_miptree_layout_2d(brw, mt);
> >
> > if (layout_1d) {
> >physical_qpitch = 1;
> > @@ -492,12 +514,18 @@ brw_miptree_layout_texture_array(struct
> brw_context *brw,
> > */
> >mt->qpitch = mt->total_width;
> > } else {
> > -  mt->qpitch = brw_miptree_get_vertical_slice_pitch(brw, mt, 0);
> > +
> >/* Unlike previous generations the qpitch is a multiple of the
> > * compressed block size on Gen9 so physical_qpitch matches
> mt->qpitch.
> > */
> > -  physical_qpitch = (mt->compressed && brw->gen < 9 ? mt->qpitch /
> 4 :
> > - mt->qpitch);
> > +  physical_qpitch = mt->qpitch =
> brw_miptree_get_vertical_slice_pitch(brw, mt, 0);
> > +
> > +  if (mt->compressed && brw->gen < 9) {
> > + unsigned bh, bw;
> > + _mesa_get_format_block_size(mt->format, &bw, &bh);
> > + physical_qpitch /= bh;
> > +  }
> > +
> > }
> >
> > for (unsigned level = mt->first_level; level <= mt->last_level;
> level++) {
> > @@ -705,7 +733,7 @@ intel_miptree_set_total_width_height(struct
> brw_context *brw,
> >   if (gen9_use_linear_1d_layout(brw, mt))
> >  gen9_miptree_layout_1d(mt);
> >   else
> > -brw_miptree_layout_2d(mt);
> > +brw_miptree_layout_2d(brw, mt);
> >   break;
> >}
> >break;
> > @@ -772,7 +800,10 @@ intel_miptree_set_alignment(struct brw_context *brw,
> >if (brw->gen >= 9) {
> >   mt->align_w *= 4;
> >   mt->align_h *= 4;
> > +  } else if (is_astc_chv(brw, mt)) {
> > + mt->align_h *= 4;
> >}
> > +
> > } else if (mt->format == MESA_FORMAT_S_UINT8) {
> >mt->align_w = 8;
> >mt->align_h = brw->gen >= 7 ? 8 : 4;
> > @@ -803,14 +834,10

Re: [Mesa-dev] [PATCH] nir/builder: Use nir_after_instr to advance the cursor

2015-08-31 Thread Kenneth Graunke

On Monday, August 31, 2015 04:55:51 PM Jason Ekstrand wrote:
> This *should* ensure that the cursor gets properly advanced in all cases.
> We had a problem before where, if the cursor was created using
> nir_after_cf_node on a non-block cf_node, that would call nir_before_block
> on the block following the cf node.  Instructions would then get inserted
> in backwards order at the top of the block which is not at all what you
> would expect from nir_after_cf_node.  By just resetting to after_instr, we
> avoid all these problems.
> ---
>  src/glsl/nir/nir_builder.h | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/src/glsl/nir/nir_builder.h b/src/glsl/nir/nir_builder.h
> index 3aa0efd..295a209 100644
> --- a/src/glsl/nir/nir_builder.h
> +++ b/src/glsl/nir/nir_builder.h
> @@ -49,8 +49,7 @@ nir_builder_instr_insert(nir_builder *build, nir_instr 
> *instr)
> nir_instr_insert(build->cursor, instr);
>  
> /* Move the cursor forward. */
> -   if (build->cursor.option == nir_cursor_after_instr)
> -  build->cursor.instr = instr;
> +   build->cursor = nir_after_instr(instr);
>  }
>  
>  static inline void
> 

This seems like the right behavior for the builder to take.

Sorry for the breakage - I hadn't thought through how the
nir_{before,after}_cf_{node,list} functions translate to blocks.
Thanks for fixing it.

Reviewed-by: Kenneth Graunke 

You've regression tested this, I assume?



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: Don't check for draw-time errors that cannot occur in core profile

2015-08-31 Thread Ian Romanick

On 08/31/2015 04:21 PM, Ilia Mirkin wrote:
> On Mon, Aug 31, 2015 at 7:06 PM, Ian Romanick  wrote:
>> ping. :)
>>
>> On 08/10/2015 11:48 AM, Matt Turner wrote:
>>> On Mon, Aug 10, 2015 at 10:12 AM, Ian Romanick  wrote:
 From: Ian Romanick 

 On many CPU-limited applications, this is *the* hot path.  The idea is
 to generate per-API versions of brw_draw_prims that elide some checks.
 This patch removes render-mode and "is everything in VBOs" checks from
 core-profile contexts.

 On my IVB laptop (which may have experienced thermal throttling):

 Gl32Batch7: 3.70955% +/- 1.11344%
>>>
>>> I'm getting 3.18414% +/- 0.587956% (n=113) on my IVB, , which probably
>>> matches your numbers depending on your value of n.
>>>
 OglBatch7:  1.04398% +/- 0.772788%
>>>
>>> I'm getting 1.15377% +/- 1.05898% (n=34) on my IVB, which probably
>>> matches your numbers depending on your value of n.
>>
>> This is another thing that make me feel a little uncomfortable with the
>> way we've done performance measurements in the past.  If I run my test
>> before and after this patch for 121 iterations, which I have done, I can
>> cut the data at any point and oscillate between "no difference" or X%
>> +/- some-large-fraction-of-X%.  Since the before and after code for the
>> compatibility profile path should be identical, "no difference" is the
>> only believable result.
>>
>> Using a higher confidence threshold (e.g., -c 98) results in "no
>> difference" throughout, as expected.  I feel like 90% isn't a tight
>> enough confidence interval for a lot of what we do, but I'm unsure how
>> to determine what confidence level we should use.  We could
>> experimentally determine it by running a test some number of times and
>> finding the interval that detects no change in some random partitioning
>> of the test results.  Ugh.
> 
> (sorry, statistics rant below, can't help myself)
> 
> AFAIK the standard in statistics is to use a 95% confidence interval.

I had misremembered the default CI in ministat.  It does use 95%.  So,
s/90%/95%/g in my previous message. :)

> Unless you have 'statistician' in your job title [or someone with that
> job title has indicated otherwise], that's what you should probably
> use. Using anything lower than that is a way of saying "This
> scientific study isn't turning out the way I wanted, I'm going to have
> to take matters into my own hands".
> 
> Of course note that if you do run the same experiment 20 times, you
> should expect one of those 20 times to yield a confidence interval
> that does not include the true mean. And in general I'd be very
> suspicious of results where the change is near the confidence interval
> boundary.
> 
> And lastly, all this statistics stuff assumes that you're evaluating
> the same normal distribution repeatedly. This isn't exactly true, but
> it's true enough. However you can try to get more accurate by
> experimentally determining a fudge factor on the CI width. You could
> run (literal) no-op experiments lots of times and fudge the output of
> the CI width calculation until it matches up with empirical results,
> e.g. if you run the same experiment 100x and use a 95% CI, fudge the
> outcome until you end up with 5 significant results and 95
> insignificant ones. Ideally such a fudge factor should not be too
> different from 1, or else you have a very non-normal distribution, and
> fudge factors ain't gonna help you. Note that any computed fudge
> factors could not be shared among machine groups that weren't used to
> determine them, so I'm not seriously recommending this approach, but
> thought I'd mention it.
> 
>   -ilia
> 

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

Re: [Mesa-dev] [PATCH] i965: enable ASTC for Cherryview

2015-08-31 Thread Matt Turner

On Mon, Aug 31, 2015 at 5:02 PM, Nanley Chery  wrote:
> On Mon, Aug 31, 2015 at 4:58 PM, Matt Turner  wrote:
>> (what's this patch against? I don't have this in my tree)
>
>
> This is against mesa master.

It's not -- for instance, current intel_extensions.c does not contain
the string "astc".
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965: enable ASTC for Cherryview

2015-08-31 Thread Nanley Chery

On Mon, Aug 31, 2015 at 5:16 PM, Matt Turner  wrote:

> On Mon, Aug 31, 2015 at 5:02 PM, Nanley Chery 
> wrote:
> > On Mon, Aug 31, 2015 at 4:58 PM, Matt Turner  wrote:
> >> (what's this patch against? I don't have this in my tree)
> >
> >
> > This is against mesa master.
>
> It's not -- for instance, current intel_extensions.c does not contain
> the string "astc".
>

Sorry about that. It was against the Skylake enabling patch (which is now
upstream).
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] nir/builder: Use nir_after_instr to advance the cursor

2015-08-31 Thread Jason Ekstrand

On Mon, Aug 31, 2015 at 5:04 PM, Kenneth Graunke  wrote:
> On Monday, August 31, 2015 04:55:51 PM Jason Ekstrand wrote:
>> This *should* ensure that the cursor gets properly advanced in all cases.
>> We had a problem before where, if the cursor was created using
>> nir_after_cf_node on a non-block cf_node, that would call nir_before_block
>> on the block following the cf node.  Instructions would then get inserted
>> in backwards order at the top of the block which is not at all what you
>> would expect from nir_after_cf_node.  By just resetting to after_instr, we
>> avoid all these problems.
>> ---
>>  src/glsl/nir/nir_builder.h | 3 +--
>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/src/glsl/nir/nir_builder.h b/src/glsl/nir/nir_builder.h
>> index 3aa0efd..295a209 100644
>> --- a/src/glsl/nir/nir_builder.h
>> +++ b/src/glsl/nir/nir_builder.h
>> @@ -49,8 +49,7 @@ nir_builder_instr_insert(nir_builder *build, nir_instr 
>> *instr)
>> nir_instr_insert(build->cursor, instr);
>>
>> /* Move the cursor forward. */
>> -   if (build->cursor.option == nir_cursor_after_instr)
>> -  build->cursor.instr = instr;
>> +   build->cursor = nir_after_instr(instr);
>>  }
>>
>>  static inline void
>>
>
> This seems like the right behavior for the builder to take.
>
> Sorry for the breakage - I hadn't thought through how the
> nir_{before,after}_cf_{node,list} functions translate to blocks.
> Thanks for fixing it.
>
> Reviewed-by: Kenneth Graunke 

Thanks!

> You've regression tested this, I assume?

Just did.  Passes jenkins just fine.
--Jason
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] r600g: fix calculation for gpr allocation

2015-08-31 Thread Dave Airlie

From: Dave Airlie 

I've been chasing a geom shader hang on rv635 since I wrote
r600 geom code, and finally I hacked some values from fglrx
in and I could run texelfetch without failures.

This is totally my fault as well, maths fail 101.

This makes geom shaders on r600 not fail heavily.

Cc: "10.6" "11.0" 
Signed-off-by: Dave Airlie 
---
 src/gallium/drivers/r600/r600_state.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/r600/r600_state.c 
b/src/gallium/drivers/r600/r600_state.c
index dcbddf3..680051f 100644
--- a/src/gallium/drivers/r600/r600_state.c
+++ b/src/gallium/drivers/r600/r600_state.c
@@ -2051,7 +2051,7 @@ bool r600_adjust_gprs(struct r600_context *rctx)
/* always privilege vs stage so that at worst we have 
the
 * pixel stage producing wrong output (not the vertex
 * stage) */
-   new_num_ps_gprs = max_gprs - ((new_num_vs_gprs - 
new_num_es_gprs - new_num_gs_gprs) + def_num_clause_temp_gprs * 2);
+   new_num_ps_gprs = max_gprs - ((new_num_vs_gprs + 
new_num_es_gprs + new_num_gs_gprs) + def_num_clause_temp_gprs * 2);
new_num_vs_gprs = num_vs_gprs;
new_num_gs_gprs = num_gs_gprs;
new_num_es_gprs = num_es_gprs;
-- 
2.1.0

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

Re: [Mesa-dev] [PATCH] r600g: fix calculation for gpr allocation

2015-08-31 Thread Edward O'Callaghan

Reviewed-by: Edward O'Callaghan 

-- 
  Edward O'Callaghan
  edward.ocallag...@koparo.com

On Tue, Sep 1, 2015, at 12:34 PM, Dave Airlie wrote:
> From: Dave Airlie 
> 
> I've been chasing a geom shader hang on rv635 since I wrote
> r600 geom code, and finally I hacked some values from fglrx
> in and I could run texelfetch without failures.
> 
> This is totally my fault as well, maths fail 101.
> 
> This makes geom shaders on r600 not fail heavily.
> 
> Cc: "10.6" "11.0" 
> Signed-off-by: Dave Airlie 
> ---
>  src/gallium/drivers/r600/r600_state.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/gallium/drivers/r600/r600_state.c
> b/src/gallium/drivers/r600/r600_state.c
> index dcbddf3..680051f 100644
> --- a/src/gallium/drivers/r600/r600_state.c
> +++ b/src/gallium/drivers/r600/r600_state.c
> @@ -2051,7 +2051,7 @@ bool r600_adjust_gprs(struct r600_context *rctx)
>   /* always privilege vs stage so that at worst we have 
> the
>* pixel stage producing wrong output (not the vertex
>* stage) */
> -   new_num_ps_gprs = max_gprs - ((new_num_vs_gprs -
> new_num_es_gprs - new_num_gs_gprs) + def_num_clause_temp_gprs * 2);
> +   new_num_ps_gprs = max_gprs - ((new_num_vs_gprs +
> new_num_es_gprs + new_num_gs_gprs) + def_num_clause_temp_gprs * 2);
>   new_num_vs_gprs = num_vs_gprs;
>   new_num_gs_gprs = num_gs_gprs;
>   new_num_es_gprs = num_es_gprs;
> -- 
> 2.1.0
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] r600g: fix calculation for gpr allocation

2015-08-31 Thread Alex Deucher

On Mon, Aug 31, 2015 at 10:34 PM, Dave Airlie  wrote:
> From: Dave Airlie 
>
> I've been chasing a geom shader hang on rv635 since I wrote
> r600 geom code, and finally I hacked some values from fglrx
> in and I could run texelfetch without failures.
>
> This is totally my fault as well, maths fail 101.
>
> This makes geom shaders on r600 not fail heavily.
>
> Cc: "10.6" "11.0" 
> Signed-off-by: Dave Airlie 

Reviewed-by: Alex Deucher 

> ---
>  src/gallium/drivers/r600/r600_state.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/r600/r600_state.c 
> b/src/gallium/drivers/r600/r600_state.c
> index dcbddf3..680051f 100644
> --- a/src/gallium/drivers/r600/r600_state.c
> +++ b/src/gallium/drivers/r600/r600_state.c
> @@ -2051,7 +2051,7 @@ bool r600_adjust_gprs(struct r600_context *rctx)
> /* always privilege vs stage so that at worst we have 
> the
>  * pixel stage producing wrong output (not the vertex
>  * stage) */
> -   new_num_ps_gprs = max_gprs - ((new_num_vs_gprs - 
> new_num_es_gprs - new_num_gs_gprs) + def_num_clause_temp_gprs * 2);
> +   new_num_ps_gprs = max_gprs - ((new_num_vs_gprs + 
> new_num_es_gprs + new_num_gs_gprs) + def_num_clause_temp_gprs * 2);
> new_num_vs_gprs = num_vs_gprs;
> new_num_gs_gprs = num_gs_gprs;
> new_num_es_gprs = num_es_gprs;
> --
> 2.1.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/2] mesa: Don't allow wrong type setters for matrix uniforms

2015-08-31 Thread Ian Romanick

From: Ian Romanick 

Previously we would allow glUniformMatrix4fv on a dmat4 and
glUniformMatrix4dv on a mat4.  Both are illegal.  That later also
overwrites the storage for the mat4 and causes bad things to happen.

Should fix the (new) arb_gpu_shader_fp64-wrong-type-setter piglit test.

Signed-off-by: Ian Romanick 
Cc: Dave Airlie 
Cc: "10.6 11.0 "
---
 src/mesa/main/uniform_query.cpp | 25 +
 1 file changed, 25 insertions(+)

diff --git a/src/mesa/main/uniform_query.cpp b/src/mesa/main/uniform_query.cpp
index 7e3a4a5..4a0c8ed 100644
--- a/src/mesa/main/uniform_query.cpp
+++ b/src/mesa/main/uniform_query.cpp
@@ -919,6 +919,31 @@ _mesa_uniform_matrix(struct gl_context *ctx, struct 
gl_shader_program *shProg,
   }
}
 
+   /* Section 2.11.7 (Uniform Variables) of the OpenGL 4.2 Core Profile spec
+* says:
+*
+* "If any of the following conditions occur, an INVALID_OPERATION
+* error is generated by the Uniform* commands, and no uniform values
+* are changed:
+*
+* ...
+*
+* - if the uniform declared in the shader is not of type boolean and
+*   the type indicated in the name of the Uniform* command used does
+*   not match the type of the uniform"
+*
+* There are no Boolean matrix types, so we do not need to allow
+* GLSL_TYPE_BOOL here (as _mesa_uniform does).
+*/
+   if (uni->type->base_type != basicType) {
+  _mesa_error(ctx, GL_INVALID_OPERATION,
+  "glUniformMatrix%ux%u(\"%s\"@%d is %s, not %s)",
+  cols, rows, uni->name, location,
+  glsl_type_name(uni->type->base_type),
+  glsl_type_name(basicType));
+  return;
+   }
+
if (unlikely(ctx->_Shader->Flags & GLSL_UNIFORMS)) {
   log_uniform(values, uni->type->base_type, components, vectors, count,
  bool(transpose), shProg, location, uni);
-- 
2.1.0

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

[Mesa-dev] [PATCH 1/2] mesa: Pass the type to _mesa_uniform_matrix as a glsl_base_type

2015-08-31 Thread Ian Romanick

From: Ian Romanick 

This matches _mesa_uniform, and it enables the bug fix in the next
patch.

Signed-off-by: Ian Romanick 
Cc: Dave Airlie 
Cc: "10.6 11.0 "
---
 src/mesa/main/uniform_query.cpp | 10 +++---
 src/mesa/main/uniforms.c| 72 -
 src/mesa/main/uniforms.h|  2 +-
 3 files changed, 42 insertions(+), 42 deletions(-)

diff --git a/src/mesa/main/uniform_query.cpp b/src/mesa/main/uniform_query.cpp
index 1026618..7e3a4a5 100644
--- a/src/mesa/main/uniform_query.cpp
+++ b/src/mesa/main/uniform_query.cpp
@@ -873,7 +873,7 @@ _mesa_uniform_matrix(struct gl_context *ctx, struct 
gl_shader_program *shProg,
 GLuint cols, GLuint rows,
  GLint location, GLsizei count,
  GLboolean transpose,
- const GLvoid *values, GLenum type)
+ const GLvoid *values, enum glsl_base_type basicType)
 {
unsigned offset;
unsigned vectors;
@@ -892,8 +892,8 @@ _mesa_uniform_matrix(struct gl_context *ctx, struct 
gl_shader_program *shProg,
   return;
}
 
-   assert(type == GL_FLOAT || type == GL_DOUBLE);
-   size_mul = type == GL_DOUBLE ? 2 : 1;
+   assert(basicType == GLSL_TYPE_FLOAT || type == GLSL_TYPE_DOUBLE);
+   size_mul = basicType == GLSL_TYPE_DOUBLE ? 2 : 1;
 
assert(!uni->type->is_sampler());
vectors = uni->type->matrix_columns;
@@ -948,7 +948,7 @@ _mesa_uniform_matrix(struct gl_context *ctx, struct 
gl_shader_program *shProg,
if (!transpose) {
   memcpy(&uni->storage[elements * offset], values,
 sizeof(uni->storage[0]) * elements * count * size_mul);
-   } else if (type == GL_FLOAT) {
+   } else if (basicType == GLSL_TYPE_FLOAT) {
   /* Copy and transpose the matrix.
*/
   const float *src = (const float *)values;
@@ -965,7 +965,7 @@ _mesa_uniform_matrix(struct gl_context *ctx, struct 
gl_shader_program *shProg,
 src += elements;
   }
} else {
-  assert(type == GL_DOUBLE);
+  assert(basicType == GLSL_TYPE_DOUBLE);
   const double *src = (const double *)values;
   double *dst = (double *)&uni->storage[elements * offset].f;
 
diff --git a/src/mesa/main/uniforms.c b/src/mesa/main/uniforms.c
index 10819e2..973b877 100644
--- a/src/mesa/main/uniforms.c
+++ b/src/mesa/main/uniforms.c
@@ -553,7 +553,7 @@ _mesa_UniformMatrix2fv(GLint location, GLsizei count, 
GLboolean transpose,
 {
GET_CURRENT_CONTEXT(ctx);
_mesa_uniform_matrix(ctx, ctx->_Shader->ActiveProgram,
-   2, 2, location, count, transpose, value, GL_FLOAT);
+   2, 2, location, count, transpose, value, 
GLSL_TYPE_FLOAT);
 }
 
 void GLAPIENTRY
@@ -562,7 +562,7 @@ _mesa_UniformMatrix3fv(GLint location, GLsizei count, 
GLboolean transpose,
 {
GET_CURRENT_CONTEXT(ctx);
_mesa_uniform_matrix(ctx, ctx->_Shader->ActiveProgram,
-   3, 3, location, count, transpose, value, GL_FLOAT);
+   3, 3, location, count, transpose, value, 
GLSL_TYPE_FLOAT);
 }
 
 void GLAPIENTRY
@@ -571,7 +571,7 @@ _mesa_UniformMatrix4fv(GLint location, GLsizei count, 
GLboolean transpose,
 {
GET_CURRENT_CONTEXT(ctx);
_mesa_uniform_matrix(ctx, ctx->_Shader->ActiveProgram,
-   4, 4, location, count, transpose, value, GL_FLOAT);
+   4, 4, location, count, transpose, value, 
GLSL_TYPE_FLOAT);
 }
 
 /** Same as above with direct state access **/
@@ -683,7 +683,7 @@ _mesa_ProgramUniformMatrix2fv(GLuint program, GLint 
location, GLsizei count,
struct gl_shader_program *shProg =
   _mesa_lookup_shader_program_err(ctx, program,
 "glProgramUniformMatrix2fv");
-   _mesa_uniform_matrix(ctx, shProg, 2, 2, location, count, transpose, value, 
GL_FLOAT);
+   _mesa_uniform_matrix(ctx, shProg, 2, 2, location, count, transpose, value, 
GLSL_TYPE_FLOAT);
 }
 
 void GLAPIENTRY
@@ -694,7 +694,7 @@ _mesa_ProgramUniformMatrix3fv(GLuint program, GLint 
location, GLsizei count,
struct gl_shader_program *shProg =
   _mesa_lookup_shader_program_err(ctx, program,
 "glProgramUniformMatrix3fv");
-   _mesa_uniform_matrix(ctx, shProg, 3, 3, location, count, transpose, value, 
GL_FLOAT);
+   _mesa_uniform_matrix(ctx, shProg, 3, 3, location, count, transpose, value, 
GLSL_TYPE_FLOAT);
 }
 
 void GLAPIENTRY
@@ -705,7 +705,7 @@ _mesa_ProgramUniformMatrix4fv(GLuint program, GLint 
location, GLsizei count,
struct gl_shader_program *shProg =
   _mesa_lookup_shader_program_err(ctx, program,
 "glProgramUniformMatrix4fv");
-   _mesa_uniform_matrix(ctx, shProg, 4, 4, location, count, transpose, value, 
GL_FLOAT);
+   _mesa_uniform_matrix(ctx, shProg, 4, 4, location, count, transpose, value, 
GLSL_TYPE_FLOAT);
 }
 
 
@@ -718,7 +718,7 @@ _mesa_UniformMatrix2x3fv(GLint location, GLsizei count, 
GLboolean transpose,
 {
GET_CURRENT_CONTEXT(ctx);
_mesa_uniform_matrix(ctx, ctx->_Shader->ActiveProgram,
-

Re: [Mesa-dev] [PATCH 1/2] mesa: Pass the type to _mesa_uniform_matrix as a glsl_base_type

2015-08-31 Thread Timothy Arceri

On Mon, 2015-08-31 at 20:56 -0700, Ian Romanick wrote:
> From: Ian Romanick 
> 
> This matches _mesa_uniform, and it enables the bug fix in the next
> patch.
> 
> Signed-off-by: Ian Romanick 


Both are: Reviewed-by: Timothy Arceri 

> Cc: Dave Airlie 
> Cc: "10.6 11.0 "
> ---
>  src/mesa/main/uniform_query.cpp | 10 +++---
>  src/mesa/main/uniforms.c| 72 --
> ---
>  src/mesa/main/uniforms.h|  2 +-
>  3 files changed, 42 insertions(+), 42 deletions(-)
> 
> diff --git a/src/mesa/main/uniform_query.cpp 
> b/src/mesa/main/uniform_query.cpp
> index 1026618..7e3a4a5 100644
> --- a/src/mesa/main/uniform_query.cpp
> +++ b/src/mesa/main/uniform_query.cpp
> @@ -873,7 +873,7 @@ _mesa_uniform_matrix(struct gl_context *ctx, struct 
> gl_shader_program *shProg,
>GLuint cols, GLuint rows,
>   GLint location, GLsizei count,
>   GLboolean transpose,
> - const GLvoid *values, GLenum type)
> + const GLvoid *values, enum glsl_base_type basicType)
>  {
> unsigned offset;
> unsigned vectors;
> @@ -892,8 +892,8 @@ _mesa_uniform_matrix(struct gl_context *ctx, struct 
> gl_shader_program *shProg,
>return;
> }
>  
> -   assert(type == GL_FLOAT || type == GL_DOUBLE);
> -   size_mul = type == GL_DOUBLE ? 2 : 1;
> +   assert(basicType == GLSL_TYPE_FLOAT || type == GLSL_TYPE_DOUBLE);
> +   size_mul = basicType == GLSL_TYPE_DOUBLE ? 2 : 1;
>  
> assert(!uni->type->is_sampler());
> vectors = uni->type->matrix_columns;
> @@ -948,7 +948,7 @@ _mesa_uniform_matrix(struct gl_context *ctx, struct 
> gl_shader_program *shProg,
> if (!transpose) {
>memcpy(&uni->storage[elements * offset], values,
>sizeof(uni->storage[0]) * elements * count * size_mul);
> -   } else if (type == GL_FLOAT) {
> +   } else if (basicType == GLSL_TYPE_FLOAT) {
>/* Copy and transpose the matrix.
> */
>const float *src = (const float *)values;
> @@ -965,7 +965,7 @@ _mesa_uniform_matrix(struct gl_context *ctx, struct 
> gl_shader_program *shProg,
>src += elements;
>}
> } else {
> -  assert(type == GL_DOUBLE);
> +  assert(basicType == GLSL_TYPE_DOUBLE);
>const double *src = (const double *)values;
>double *dst = (double *)&uni->storage[elements * offset].f;
>  
> diff --git a/src/mesa/main/uniforms.c b/src/mesa/main/uniforms.c
> index 10819e2..973b877 100644
> --- a/src/mesa/main/uniforms.c
> +++ b/src/mesa/main/uniforms.c
> @@ -553,7 +553,7 @@ _mesa_UniformMatrix2fv(GLint location, GLsizei count, 
> GLboolean transpose,
>  {
> GET_CURRENT_CONTEXT(ctx);
> _mesa_uniform_matrix(ctx, ctx->_Shader->ActiveProgram,
> - 2, 2, location, count, transpose, value, GL_FLOAT);
> + 2, 2, location, count, transpose, value, 
> GLSL_TYPE_FLOAT);
>  }
>  
>  void GLAPIENTRY
> @@ -562,7 +562,7 @@ _mesa_UniformMatrix3fv(GLint location, GLsizei count, 
> GLboolean transpose,
>  {
> GET_CURRENT_CONTEXT(ctx);
> _mesa_uniform_matrix(ctx, ctx->_Shader->ActiveProgram,
> - 3, 3, location, count, transpose, value, GL_FLOAT);
> + 3, 3, location, count, transpose, value, 
> GLSL_TYPE_FLOAT);
>  }
>  
>  void GLAPIENTRY
> @@ -571,7 +571,7 @@ _mesa_UniformMatrix4fv(GLint location, GLsizei count, 
> GLboolean transpose,
>  {
> GET_CURRENT_CONTEXT(ctx);
> _mesa_uniform_matrix(ctx, ctx->_Shader->ActiveProgram,
> - 4, 4, location, count, transpose, value, GL_FLOAT);
> + 4, 4, location, count, transpose, value, 
> GLSL_TYPE_FLOAT);
>  }
>  
>  /** Same as above with direct state access **/
> @@ -683,7 +683,7 @@ _mesa_ProgramUniformMatrix2fv(GLuint program, GLint 
> location, GLsizei count,
> struct gl_shader_program *shProg =
>_mesa_lookup_shader_program_err(ctx, program,
>  "glProgramUniformMatrix2fv");
> -   _mesa_uniform_matrix(ctx, shProg, 2, 2, location, count, transpose, 
> value, GL_FLOAT);
> +   _mesa_uniform_matrix(ctx, shProg, 2, 2, location, count, transpose, 
> value, GLSL_TYPE_FLOAT);
>  }
>  
>  void GLAPIENTRY
> @@ -694,7 +694,7 @@ _mesa_ProgramUniformMatrix3fv(GLuint program, GLint 
> location, GLsizei count,
> struct gl_shader_program *shProg =
>_mesa_lookup_shader_program_err(ctx, program,
>  "glProgramUniformMatrix3fv");
> -   _mesa_uniform_matrix(ctx, shProg, 3, 3, location, count, transpose, 
> value, GL_FLOAT);
> +   _mesa_uniform_matrix(ctx, shProg, 3, 3, location, count, transpose, 
> value, GLSL_TYPE_FLOAT);
>  }
>  
>  void GLAPIENTRY
> @@ -705,7 +705,7 @@ _mesa_ProgramUniformMatrix4fv(GLuint program, GLint 
> location, GLsizei count,
> struct gl_shader_program *shProg =
>_mesa_lookup_shader_program_err(ctx, program,
>  "glProgramUniformMatrix4fv");
> -   _mesa_uniform_matrix(ctx, shProg, 4, 4, location,

[Mesa-dev] [PATCH 1/2] mesa: fix SwapBytes handling in numerous places

2015-08-31 Thread Dave Airlie

From: Dave Airlie 

In a number of places the SwapBytes handling
didn't handle cases with GL_(UN)PACK_ALIGNMENT
set and 7 byte width cases aligned to 8 bytes.

This adds a common routine to swap bytes a 2D
image and uses this code in the:
texture store
texture getting
readpixels
and swrast drawpixels.

Signed-off-by: Dave Airlie 
---
 src/mesa/main/image.c   | 43 ---
 src/mesa/main/image.h   | 20 +++-
 src/mesa/main/readpix.c | 11 ++-
 src/mesa/main/texgetimage.c | 14 +++---
 src/mesa/main/texstore.c| 28 +---
 src/mesa/swrast/s_drawpix.c | 14 +++---
 6 files changed, 76 insertions(+), 54 deletions(-)

diff --git a/src/mesa/main/image.c b/src/mesa/main/image.c
index 711a190..770d89c 100644
--- a/src/mesa/main/image.c
+++ b/src/mesa/main/image.c
@@ -49,7 +49,7 @@
  * \param src the array with the source data we want to byte-swap.
  * \param n number of words.
  */
-void
+static void
 _mesa_swap2_copy( GLushort *dst, GLushort *src, GLuint n )
 {
GLuint i;
@@ -58,7 +58,11 @@ _mesa_swap2_copy( GLushort *dst, GLushort *src, GLuint n )
}
 }
 
-
+void
+_mesa_swap2(GLushort *p, GLuint n)
+{
+   _mesa_swap2_copy(p, p, n);
+}
 
 /*
  * Flip the order of the 4 bytes in each word in the given array (src) and
@@ -69,7 +73,7 @@ _mesa_swap2_copy( GLushort *dst, GLushort *src, GLuint n )
  * \param src the array with the source data we want to byte-swap.
  * \param n number of words.
  */
-void
+static void
 _mesa_swap4_copy( GLuint *dst, GLuint *src, GLuint n )
 {
GLuint i, a, b;
@@ -83,6 +87,11 @@ _mesa_swap4_copy( GLuint *dst, GLuint *src, GLuint n )
}
 }
 
+void
+_mesa_swap4(GLuint *p, GLuint n)
+{
+   _mesa_swap4_copy(p, p, n);
+}
 
 /**
  * Return the byte offset of a specific pixel in an image (1D, 2D or 3D).
@@ -958,3 +967,31 @@ _mesa_clip_blit(struct gl_context *ctx,
 
return GL_TRUE;
 }
+
+
+void
+_mesa_swap_bytes_2d_image(GLenum format, GLenum type,
+  const struct gl_pixelstore_attrib *packing,
+  GLsizei width, GLsizei height,
+  GLvoid *dst, const GLvoid *src)
+{
+   GLint swapSize = _mesa_sizeof_packed_type(type);
+   if (swapSize == 2 || swapSize == 4) {
+  int swapsPerPixel = _mesa_bytes_per_pixel(format, type) / swapSize;
+  int stride = _mesa_image_row_stride(packing, width, format, type);
+  int row;
+  const uint8_t *dstrow;
+  const uint8_t *srcrow;
+  assert(_mesa_bytes_per_pixel(format, type) % swapSize == 0);
+  dstrow = dst;
+  srcrow = src ? src : dst;
+  for (row = 0; row < height; row++) {
+ if (swapSize == 2)
+_mesa_swap2_copy((GLushort *) dstrow, (GLushort *)srcrow, width * 
swapsPerPixel);
+ else if (swapSize == 4)
+_mesa_swap4_copy((GLuint *) dstrow, (GLuint *)srcrow, width * 
swapsPerPixel);
+ dstrow += stride;
+ srcrow += stride;
+  }
+   }
+}
diff --git a/src/mesa/main/image.h b/src/mesa/main/image.h
index 501586b..b5075be 100644
--- a/src/mesa/main/image.h
+++ b/src/mesa/main/image.h
@@ -35,22 +35,11 @@ struct gl_pixelstore_attrib;
 struct gl_framebuffer;
 
 extern void
-_mesa_swap2_copy(GLushort *dst, GLushort *src, GLuint n);
+_mesa_swap2(GLushort *p, GLuint n);
 
 extern void
-_mesa_swap4_copy(GLuint *dst, GLuint *src, GLuint n);
+_mesa_swap4(GLuint *p, GLuint n);
 
-static inline void
-_mesa_swap2(GLushort *p, GLuint n)
-{
-   _mesa_swap2_copy(p, p, n);
-}
-
-static inline void
-_mesa_swap4(GLuint *p, GLuint n)
-{
-   _mesa_swap4_copy(p, p, n);
-}
 
 extern GLintptr
 _mesa_image_offset( GLuint dimensions,
@@ -146,5 +135,10 @@ _mesa_clip_blit(struct gl_context *ctx,
 GLint *srcX0, GLint *srcY0, GLint *srcX1, GLint *srcY1,
 GLint *dstX0, GLint *dstY0, GLint *dstX1, GLint *dstY1);
 
+void
+_mesa_swap_bytes_2d_image(GLenum format, GLenum type,
+  const struct gl_pixelstore_attrib *packing,
+  GLsizei width, GLsizei height,
+  GLvoid *dst, const GLvoid *src);
 
 #endif
diff --git a/src/mesa/main/readpix.c b/src/mesa/main/readpix.c
index 1277944..0ef07b5 100644
--- a/src/mesa/main/readpix.c
+++ b/src/mesa/main/readpix.c
@@ -613,15 +613,8 @@ read_rgba_pixels( struct gl_context *ctx,
 done_swap:
/* Handle byte swapping if required */
if (packing->SwapBytes) {
-  GLint swapSize = _mesa_sizeof_packed_type(type);
-  if (swapSize == 2 || swapSize == 4) {
- int swapsPerPixel = _mesa_bytes_per_pixel(format, type) / swapSize;
- assert(_mesa_bytes_per_pixel(format, type) % swapSize == 0);
- if (swapSize == 2)
-_mesa_swap2((GLushort *) dst, width * height * swapsPerPixel);
- else if (swapSize == 4)
-_mesa_swap4((GLuint *) dst, width * height * swapsPerPixel);
-  }
+  _mesa_swap_bytes_2d_image(format, type, packing,
+

[Mesa-dev] [PATCH 2/2] mesa: handle SwapBytes in compressed texture get code.

2015-08-31 Thread Dave Airlie

This case just wasn't handled, so add support for it.

Signed-off-by: Dave Airlie 
---
 src/mesa/main/texgetimage.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/src/mesa/main/texgetimage.c b/src/mesa/main/texgetimage.c
index 0c23687..52ed1ef 100644
--- a/src/mesa/main/texgetimage.c
+++ b/src/mesa/main/texgetimage.c
@@ -361,6 +361,13 @@ get_tex_rgba_compressed(struct gl_context *ctx, GLuint 
dimensions,
tempSlice, RGBA32_FLOAT, srcStride,
width, height,
needsRebase ? rebaseSwizzle : NULL);
+
+  /* Handle byte swapping if required */
+  if (ctx->Pack.SwapBytes) {
+ _mesa_swap_bytes_2d_image(format, type, &ctx->Pack,
+   width, height, dest, NULL);
+  }
+
   tempSlice += 4 * width * height;
}
 
-- 
2.4.3

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

Re: [Mesa-dev] [PATCH 1/6] mesa: fix SwapBytes handling in texstore.

2015-08-31 Thread Dave Airlie

On 28 August 2015 at 09:16, Brian Paul  wrote:
> Some of the commit messages, like this one, seem to line-wrapped shorter
> than necessary.
>
> For patches 1-4, the changes look OK, AFAICT.  Though, it seems there's some
> very similar byte-swap code duplicated in several places.  Would it be
> possible to write a function which does byte swapping for whole 2D images?

Thanks,

Seems like a more sensible idea, I've reposted as two patches, looks a
fair bit saner.

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

[Mesa-dev] [Bug 91826] Mesa 11.0.0-rc2 - state_trackers/clover does not build on FreeBSD

2015-08-31 Thread bugzilla-daemon

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

--- Comment #1 from Albert Freeman  ---
I believe the fix for this is in mesa master. Here is the patch:
https://patchwork.freedesktop.org/patch/56716/

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

Re: [Mesa-dev] [PATCH] meta: Compute correct buffer size with SkipRows/SkipPixels

2015-08-31 Thread Jason Ekstrand

On Aug 31, 2015 6:48 AM, "Chris Wilson"  wrote:
>
> From: Jason Ekstrand 
>
> If the user is specifying a subregion of a buffer using SKIP_ROWS and
> SKIP_PIXELS, we must compute the buffer size carefully as the end of the
> last row may be much shorter than stride*image_height*depth. The current
> code tries to memcpy from beyond the end of the user data, for example
> causing:
>
> ==28136== Invalid read of size 8
> ==28136==at 0x4C2D94E: memcpy@@GLIBC_2.14 (vg_replace_strmem.c:915)
> ==28136==by 0xB4ADFE3: brw_bo_write (brw_batch.c:1856)
> ==28136==by 0xB5B3531: brw_buffer_data (intel_buffer_objects.c:208)
> ==28136==by 0xB0F6275: _mesa_buffer_data (bufferobj.c:1600)
> ==28136==by 0xB0F6346: _mesa_BufferData (bufferobj.c:1631)
> ==28136==by 0xB37A1EE: create_texture_for_pbo
(meta_tex_subimage.c:103)
> ==28136==by 0xB37A467: _mesa_meta_pbo_TexSubImage
(meta_tex_subimage.c:176)
> ==28136==by 0xB5C8D61: intelTexSubImage (intel_tex_subimage.c:195)
> ==28136==by 0xB254AB4: _mesa_texture_sub_image (teximage.c:3654)
> ==28136==by 0xB254C9F: texsubimage (teximage.c:3712)
> ==28136==by 0xB2550E9: _mesa_TexSubImage2D (teximage.c:3853)
> ==28136==by 0x401CA0: UploadTexSubImage2D (teximage.c:171)
> ==28136==  Address 0xd8bfbe0 is 0 bytes after a block of size 1,024
alloc'd
> ==28136==at 0x4C28C20: malloc (vg_replace_malloc.c:296)
> ==28136==by 0x402014: PerfDraw (teximage.c:270)
> ==28136==by 0x402648: Draw (glmain.c:182)
> ==28136==by 0x8385E63: ??? (in
/usr/lib/x86_64-linux-gnu/libglut.so.3.9.0)
> ==28136==by 0x83896C8: fgEnumWindows (in
/usr/lib/x86_64-linux-gnu/libglut.so.3.9.0)
> ==28136==by 0x838641C: glutMainLoopEvent (in
/usr/lib/x86_64-linux-gnu/libglut.so.3.9.0)
> ==28136==by 0x8386C1C: glutMainLoop (in
/usr/lib/x86_64-linux-gnu/libglut.so.3.9.0)
> ==28136==by 0x4019C1: main (glmain.c:262)
> ==28136==
> ==28136== Invalid read of size 8
> ==28136==at 0x4C2D940: memcpy@@GLIBC_2.14 (vg_replace_strmem.c:915)
> ==28136==by 0xB4ADFE3: brw_bo_write (brw_batch.c:1856)
> ==28136==by 0xB5B3531: brw_buffer_data (intel_buffer_objects.c:208)
> ==28136==by 0xB0F6275: _mesa_buffer_data (bufferobj.c:1600)
> ==28136==by 0xB0F6346: _mesa_BufferData (bufferobj.c:1631)
> ==28136==by 0xB37A1EE: create_texture_for_pbo
(meta_tex_subimage.c:103)
> ==28136==by 0xB37A467: _mesa_meta_pbo_TexSubImage
(meta_tex_subimage.c:176)
> ==28136==by 0xB5C8D61: intelTexSubImage (intel_tex_subimage.c:195)
> ==28136==by 0xB254AB4: _mesa_texture_sub_image (teximage.c:3654)
> ==28136==by 0xB254C9F: texsubimage (teximage.c:3712)
> ==28136==by 0xB2550E9: _mesa_TexSubImage2D (teximage.c:3853)
> ==28136==by 0x401CA0: UploadTexSubImage2D (teximage.c:171)
> ==28136==  Address 0xd8bfbe8 is 8 bytes after a block of size 1,024
alloc'd
> ==28136==at 0x4C28C20: malloc (vg_replace_malloc.c:296)
> ==28136==by 0x402014: PerfDraw (teximage.c:270)
> ==28136==by 0x402648: Draw (glmain.c:182)
> ==28136==by 0x8385E63: ??? (in
/usr/lib/x86_64-linux-gnu/libglut.so.3.9.0)
> ==28136==by 0x83896C8: fgEnumWindows (in
/usr/lib/x86_64-linux-gnu/libglut.so.3.9.0)
> ==28136==by 0x838641C: glutMainLoopEvent (in
/usr/lib/x86_64-linux-gnu/libglut.so.3.9.0)
> ==28136==by 0x8386C1C: glutMainLoop (in
/usr/lib/x86_64-linux-gnu/libglut.so.3.9.0)
> ==28136==by 0x4019C1: main (glmain.c:262)
> ==28136==
>
> Fixes: 7f396189f073d626c5f7a2c232dac92b65f5a23f

How can this fix a SHA? What repo is this SHA in?

> Cc: Jason Ekstrand 
> Cc: Neil Roberts 
> ---
>  src/mesa/drivers/common/meta_tex_subimage.c | 35
+
>  1 file changed, 21 insertions(+), 14 deletions(-)
>
> diff --git a/src/mesa/drivers/common/meta_tex_subimage.c
b/src/mesa/drivers/common/meta_tex_subimage.c
> index 16d8f5d..e2351c6 100644
> --- a/src/mesa/drivers/common/meta_tex_subimage.c
> +++ b/src/mesa/drivers/common/meta_tex_subimage.c
> @@ -46,8 +46,9 @@
>  #include "varray.h"
>
>  static struct gl_texture_image *
> -create_texture_for_pbo(struct gl_context *ctx, bool create_pbo,
> -   GLenum pbo_target, int width, int height,
> +create_texture_for_pbo(struct gl_context *ctx,
> +   bool create_pbo, GLenum pbo_target,
> +   int dims, int width, int height, int depth,
> GLenum format, GLenum type, const void *pixels,
> const struct gl_pixelstore_attrib *packing,
> GLuint *tmp_pbo, GLuint *tmp_tex)
> @@ -73,8 +74,12 @@ create_texture_for_pbo(struct gl_context *ctx, bool
create_pbo,
>return NULL;
>
> /* Account for SKIP_PIXELS, SKIP_ROWS, ALIGNMENT, and SKIP_IMAGES */
> -   pixels = _mesa_image_address3d(packing, pixels,
> -  width, height, format, type, 0, 0, 0);
> +   uint32_t first_pixel = _mesa_image_offset(dims, packing, width,
height,
> +

[Mesa-dev] [Bug 91826] Mesa 11.0.0-rc2 - state_trackers/clover does not build on FreeBSD

2015-08-31 Thread bugzilla-daemon

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

--- Comment #2 from Albert Freeman  ---
Ignore my last comment, it is wrong, I got very confused.

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

Re: [Mesa-dev] [PATCH] i965: Don't check for draw-time errors that cannot occur in core profile

2015-08-31 Thread Eirik Byrkjeflot Anonsen

Ian Romanick  writes:

> ping. :)
>
> On 08/10/2015 11:48 AM, Matt Turner wrote:
>> On Mon, Aug 10, 2015 at 10:12 AM, Ian Romanick  wrote:
>>> From: Ian Romanick 
>>>
>>> On many CPU-limited applications, this is *the* hot path.  The idea is
>>> to generate per-API versions of brw_draw_prims that elide some checks.
>>> This patch removes render-mode and "is everything in VBOs" checks from
>>> core-profile contexts.
>>>
>>> On my IVB laptop (which may have experienced thermal throttling):
>>>
>>> Gl32Batch7: 3.70955% +/- 1.11344%
>> 
>> I'm getting 3.18414% +/- 0.587956% (n=113) on my IVB, , which probably
>> matches your numbers depending on your value of n.
>> 
>>> OglBatch7:  1.04398% +/- 0.772788%
>> 
>> I'm getting 1.15377% +/- 1.05898% (n=34) on my IVB, which probably
>> matches your numbers depending on your value of n.
>
> This is another thing that make me feel a little uncomfortable with the
> way we've done performance measurements in the past.  If I run my test
> before and after this patch for 121 iterations, which I have done, I can
> cut the data at any point and oscillate between "no difference" or X%
> +/- some-large-fraction-of-X%.  Since the before and after code for the
> compatibility profile path should be identical, "no difference" is the
> only believable result.

That's pretty much expected, I believe. In essence, you are running 121
tests, each with a 95% confidence interval and so should expect
somewhere around 5 "significant difference" results. That's not entirely
true of course, since these are not 121 *independent* tests, but the
basic problem remains.

You need to decide up front how many iterations you will run before
looking at the result. And you will still sometimes get the "wrong"
result. That's statistics for you.

Now, as Ilia said, this depends on the distribution to be normal, which
it is emphatically not. But figuring out what effect that has on your
results will take a proper statistician, which I am not :)

Of course, an obvious improvement would be to always run the test twice
and if any of those gives you a close-to-no-difference result, run it
another time. If both (or all three) runs give you very similar results,
you would have much better confidence in your result.

In this case you would want to run both/all tests with the same number
of iterations to get comparable numbers. But if those tests give
close-to-no-difference result, it would also be possible to run another
test with more iterations, which should tighten up the confidence
interval (and thus give a more certain result).

> Using a higher confidence threshold (e.g., -c 98) results in "no
> difference" throughout, as expected.  I feel like 90% isn't a tight
> enough confidence interval for a lot of what we do, but I'm unsure how
> to determine what confidence level we should use.  We could
> experimentally determine it by running a test some number of times and
> finding the interval that detects no change in some random partitioning
> of the test results.  Ugh.

But that only attacks half the problem. You also want differences to be
flagged when there really is one. So you would also have to work out
which level of actual, real improvements you are happy about discarding
as "no difference".

Another "obvious" way to improve the results would be to use a better
analysis of the data than what is currently done. But that brings me
back to the "I'm not a statistician" bit.

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

Re: [Mesa-dev] [PATCH] i965: Don't check for draw-time errors that cannot occur in core profile

2015-08-31 Thread Ilia Mirkin

On Tue, Sep 1, 2015 at 1:48 AM, Eirik Byrkjeflot Anonsen
 wrote:
> Ian Romanick  writes:
>
>> ping. :)
>>
>> On 08/10/2015 11:48 AM, Matt Turner wrote:
>>> On Mon, Aug 10, 2015 at 10:12 AM, Ian Romanick  wrote:
 From: Ian Romanick 

 On many CPU-limited applications, this is *the* hot path.  The idea is
 to generate per-API versions of brw_draw_prims that elide some checks.
 This patch removes render-mode and "is everything in VBOs" checks from
 core-profile contexts.

 On my IVB laptop (which may have experienced thermal throttling):

 Gl32Batch7: 3.70955% +/- 1.11344%
>>>
>>> I'm getting 3.18414% +/- 0.587956% (n=113) on my IVB, , which probably
>>> matches your numbers depending on your value of n.
>>>
 OglBatch7:  1.04398% +/- 0.772788%
>>>
>>> I'm getting 1.15377% +/- 1.05898% (n=34) on my IVB, which probably
>>> matches your numbers depending on your value of n.
>>
>> This is another thing that make me feel a little uncomfortable with the
>> way we've done performance measurements in the past.  If I run my test
>> before and after this patch for 121 iterations, which I have done, I can
>> cut the data at any point and oscillate between "no difference" or X%
>> +/- some-large-fraction-of-X%.  Since the before and after code for the
>> compatibility profile path should be identical, "no difference" is the
>> only believable result.
>
> That's pretty much expected, I believe. In essence, you are running 121
> tests, each with a 95% confidence interval and so should expect
> somewhere around 5 "significant difference" results. That's not entirely
> true of course, since these are not 121 *independent* tests, but the
> basic problem remains.

(more stats rants follow)

While my job title has never been 'statistician', I've been around a
bunch of them. Just want to correct this... let's forget about these
tests, but instead think about coin flips (of a potentially unfair
coin). What you're doing is flipping the coin 100 times, and then
looking at the number of times it came up heads and tails. From that
you're inferring the mean of the distribution. Obviously the more
times you do the flip, the more sure you can be of your result. The
"suredness", is expressed as a confidence interval. A 95% CI means
that for 95% such experiments (i.e. "flip a coin 100 times to
determine its true heads:tails ratio"), the *true* mean of the
distribution will lie within the confidence interval (and conversely,
for 5% of such experiments, the true mean will be outside of the
interval). Note how this is _not_ "the mean has a 95% chance of lying
in the interval" or anything like that. One of these runs of 121
iterations is a single "experiment".

Bringing this back to what you guys are doing, which is measuring some
metric (say, time), which is hardly binomial, but one might hope that
the amount of time that a particular run takes on a particular machine
at a particular commit is normal. Given that, after 100 runs, you can
estimate that the "true" mean runtime is within a CI. You're then
comparing 2 CI's to determine the % change between the two
distributions, and trying to ascertain whether they are different and
by how much.

Now, no (finite) amount of experimentation will bring you a CI of 0.
So setting out to *measure* the impact of a change is meaningless
unless you have some precise form of measurement (e.g. lines of code).
All you can do is ask the question "is the change > X". And for any
such X, you can compute the number of runs that you'd need in order to
get a CI bound that is "that tight". You could work this out
mathematically, and it depends on some of the absolute values in
question, but empirically it seems like for 50 runs, you get a CI
width of ~1%. If you're trying to demonstrate changes that are less
than 1%, or demonstrate that the change is no more than 1%, then this
is fine. If you want to demonstrate that the change is no more than
some smaller change, well, these things go like N^2, i.e. if it's 50
runs for 1%, it's 200 runs for 0.5%, etc.

This is all still subject to the normal distribution assumption as I
mentioned earlier. You could do some empirical tests and figure out
what the "not-a-normal-distribution" factor is for you, might be as
high as 1.5.

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

[Mesa-dev] [PATCH 2/3] texcompress_s3tc: fix stride checks

2015-08-31 Thread Dave Airlie

From: Dave Airlie 

The fastpath currently checks the stride != width, but
if you have a RowLength of 7, and Alignment of 4, then
that shuoldn't match.

align the rowlength to the pack alignment before comparing.

This fixes compressed cases in CTS packed_pixels_pixelstore
test when SKIP_PIXELS is enabled, which causes row length
to get set.

Signed-off-by: Dave Airlie 
---
 src/mesa/main/texcompress_s3tc.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/mesa/main/texcompress_s3tc.c b/src/mesa/main/texcompress_s3tc.c
index 7ce3cb8..6cfe06a 100644
--- a/src/mesa/main/texcompress_s3tc.c
+++ b/src/mesa/main/texcompress_s3tc.c
@@ -130,7 +130,7 @@ _mesa_texstore_rgb_dxt1(TEXSTORE_PARAMS)
if (srcFormat != GL_RGB ||
srcType != GL_UNSIGNED_BYTE ||
ctx->_ImageTransferState ||
-   srcPacking->RowLength != srcWidth ||
+   ALIGN(srcPacking->RowLength, srcPacking->Alignment) != srcWidth ||
srcPacking->SwapBytes) {
   /* convert image to RGB/GLubyte */
   GLubyte *tempImageSlices[1];
@@ -187,7 +187,7 @@ _mesa_texstore_rgba_dxt1(TEXSTORE_PARAMS)
if (srcFormat != GL_RGBA ||
srcType != GL_UNSIGNED_BYTE ||
ctx->_ImageTransferState ||
-   srcPacking->RowLength != srcWidth ||
+   ALIGN(srcPacking->RowLength, srcPacking->Alignment) != srcWidth ||
srcPacking->SwapBytes) {
   /* convert image to RGBA/GLubyte */
   GLubyte *tempImageSlices[1];
@@ -244,7 +244,7 @@ _mesa_texstore_rgba_dxt3(TEXSTORE_PARAMS)
if (srcFormat != GL_RGBA ||
srcType != GL_UNSIGNED_BYTE ||
ctx->_ImageTransferState ||
-   srcPacking->RowLength != srcWidth ||
+   ALIGN(srcPacking->RowLength, srcPacking->Alignment) != srcWidth ||
srcPacking->SwapBytes) {
   /* convert image to RGBA/GLubyte */
   GLubyte *tempImageSlices[1];
@@ -300,7 +300,7 @@ _mesa_texstore_rgba_dxt5(TEXSTORE_PARAMS)
if (srcFormat != GL_RGBA ||
srcType != GL_UNSIGNED_BYTE ||
ctx->_ImageTransferState ||
-   srcPacking->RowLength != srcWidth ||
+   ALIGN(srcPacking->RowLength, srcPacking->Alignment) != srcWidth ||
srcPacking->SwapBytes) {
   /* convert image to RGBA/GLubyte */
   GLubyte *tempImageSlices[1];
-- 
2.4.3

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

[Mesa-dev] [PATCH 1/3] st/readpixels: fix accel path for skipimages.

2015-08-31 Thread Dave Airlie

From: Dave Airlie 

We don't need to use the 3d image address here as that will
include SKIP_IMAGES, and we are only blitting a single
2D anyways, so just use the 2D path.

This fixes some memory overruns under CTS
 packed_pixels.packed_pixels_pixelstore when PACK_SKIP_IMAGES
is used.

Signed-off-by: Dave Airlie 
---
 src/mesa/state_tracker/st_cb_readpixels.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/mesa/state_tracker/st_cb_readpixels.c 
b/src/mesa/state_tracker/st_cb_readpixels.c
index 6ff6cf6..bb36e69 100644
--- a/src/mesa/state_tracker/st_cb_readpixels.c
+++ b/src/mesa/state_tracker/st_cb_readpixels.c
@@ -238,9 +238,9 @@ st_readpixels(struct gl_context *ctx, GLint x, GLint y,
   GLuint row;
 
   for (row = 0; row < (unsigned) height; row++) {
- GLvoid *dest = _mesa_image_address3d(pack, pixels,
+ GLvoid *dest = _mesa_image_address2d(pack, pixels,
   width, height, format,
-  type, 0, row, 0);
+  type, row, 0);
  memcpy(dest, map, bytesPerRow);
  map += tex_xfer->stride;
   }
-- 
2.4.3

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

[Mesa-dev] [PATCH 3/3] mesa/readpixels: check strides are equal before skipping conversion

2015-08-31 Thread Dave Airlie

From: Dave Airlie 

The CTS packed_pixels test checks that readpixels doesn't write
into the space between rows, however we fail that here unless
we check the format and stride match.

This fixes all the core mesa problems with CTS packed_pixels
tests.

Signed-off-by: Dave Airlie 
---
 src/mesa/main/readpix.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/mesa/main/readpix.c b/src/mesa/main/readpix.c
index 0ef07b5..c57fbac 100644
--- a/src/mesa/main/readpix.c
+++ b/src/mesa/main/readpix.c
@@ -523,7 +523,8 @@ read_rgba_pixels( struct gl_context *ctx,
* convert to, then we can convert directly into the dst buffer and avoid
* the final conversion/copy from the rgba buffer to the dst buffer.
*/
-  if (dst_format == rgba_format) {
+  if (dst_format == rgba_format &&
+  dst_stride == rgba_stride) {
  need_convert = false;
  rgba = dst;
   } else {
-- 
2.4.3

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

[Mesa-dev] [Bug 91826] Mesa 11.0.0-rc2 - state_trackers/clover does not build on FreeBSD

2015-08-31 Thread bugzilla-daemon

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

--- Comment #3 from Albert Freeman  ---
Well changing typename to enum seems to fix the problem:

diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp
b/src/gallium/state_trackers/clover/llvm/invocation.cpp
index 7c23a27..d74b50d 100644
--- a/src/gallium/state_trackers/clover/llvm/invocation.cpp
+++ b/src/gallium/state_trackers/clover/llvm/invocation.cpp
@@ -465,7 +465,7 @@ namespace {
 const bool is_write_only = access_qual == "write_only";
 const bool is_read_only = access_qual == "read_only";

-typename module::argument::type marg_type;
+enum module::argument::type marg_type;
 if (is_image2d && is_read_only) {
marg_type = module::argument::image2d_rd;
 } else if (is_image2d && is_write_only) {

Results in clang compilation warnings that are the equivalent of the gcc ones.

Of course someone familiar with the code should review this (especially since I
only learned what typename meant within the last few hours (correction: I still
don't really know)).

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

[Mesa-dev] [Bug 91826] Mesa 11.0.0-rc2 - state_trackers/clover does not build on FreeBSD

2015-08-31 Thread bugzilla-daemon

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

--- Comment #4 from Albert Freeman  ---
You should probably report this to the clang developers too.

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

63 matches

Mail list logo