[Mesa-dev] [PATCH] scons: add code to generate format_fallback.c file

[Brian Paul]

Fixes broken SCons build since a1983223d8839a0c9
---
 src/mesa/SConscript | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/src/mesa/SConscript b/src/mesa/SConscript
index fa4efe1..b63e15a 100644
--- a/src/mesa/SConscript
+++ b/src/mesa/SConscript
@@ -79,6 +79,13 @@ format_unpack = env.CodeGenerate(
   command = python_cmd + ' $SCRIPT ' + ' $SOURCE > $TARGET'
 )
 
+format_fallback = env.CodeGenerate(
+  target = 'main/format_fallback.c',
+  script = 'main/format_fallback.py',
+  source = 'main/formats.csv',
+  command = python_cmd + ' $SCRIPT ' + ' $SOURCE ' + ' $TARGET'
+)
+
 #
 # Assembly sources
 #
-- 
1.9.1

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

Re: [Mesa-dev] [PATCH 42/42] mesa: add KHR_no_error support for glClear()

[Timothy Arceri]

41-42:

Reviewed-by: Timothy Arceri 

On 27/06/17 21:20, Samuel Pitoiset wrote:

Signed-off-by: Samuel Pitoiset 
---
  src/mapi/glapi/gen/gl_API.xml | 2 +-
  src/mesa/main/clear.c | 8 
  src/mesa/main/clear.h | 2 ++
  3 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/src/mapi/glapi/gen/gl_API.xml b/src/mapi/glapi/gen/gl_API.xml
index 64078c44166..85083a428da 100644
--- a/src/mapi/glapi/gen/gl_API.xml
+++ b/src/mapi/glapi/gen/gl_API.xml
@@ -2291,7 +2291,7 @@
  
  
  
-

+
  
  
  
diff --git a/src/mesa/main/clear.c b/src/mesa/main/clear.c
index 1b07a756ee4..3adbe381854 100644
--- a/src/mesa/main/clear.c
+++ b/src/mesa/main/clear.c
@@ -224,6 +224,14 @@ clear(struct gl_context *ctx, GLbitfield mask, bool 
no_error)
  
  
  void GLAPIENTRY

+_mesa_Clear_no_error(GLbitfield mask)
+{
+   GET_CURRENT_CONTEXT(ctx);
+   clear(ctx, mask, true);
+}
+
+
+void GLAPIENTRY
  _mesa_Clear(GLbitfield mask)
  {
 GET_CURRENT_CONTEXT(ctx);
diff --git a/src/mesa/main/clear.h b/src/mesa/main/clear.h
index fb3bcdeefbf..6ae63ac257a 100644
--- a/src/mesa/main/clear.h
+++ b/src/mesa/main/clear.h
@@ -43,6 +43,8 @@ _mesa_ClearColorIiEXT(GLint r, GLint g, GLint b, GLint a);
  extern void GLAPIENTRY
  _mesa_ClearColorIuiEXT(GLuint r, GLuint g, GLuint b, GLuint a);
  
+void GLAPIENTRY

+_mesa_Clear_no_error(GLbitfield mask);
  
  extern void GLAPIENTRY

  _mesa_Clear( GLbitfield mask );


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

Re: [Mesa-dev] [PATCH 40/42] mesa: add KHR_no_error support for glBindAttribLocation()

[Timothy Arceri]

On 27/06/17 21:20, Samuel Pitoiset wrote:

Signed-off-by: Samuel Pitoiset 
---
  src/mapi/glapi/gen/gl_API.xml  |  2 +-
  src/mesa/main/shader_query.cpp | 11 +++
  src/mesa/main/shaderapi.h  |  3 +++
  3 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/src/mapi/glapi/gen/gl_API.xml b/src/mapi/glapi/gen/gl_API.xml
index d2810952501..64078c44166 100644
--- a/src/mapi/glapi/gen/gl_API.xml
+++ b/src/mapi/glapi/gen/gl_API.xml
@@ -5301,7 +5301,7 @@
  
  
  
-

+
  
  
  
diff --git a/src/mesa/main/shader_query.cpp b/src/mesa/main/shader_query.cpp
index 98441075551..117120c7568 100644
--- a/src/mesa/main/shader_query.cpp
+++ b/src/mesa/main/shader_query.cpp
@@ -79,6 +79,17 @@ bind_attrib_location(struct gl_shader_program *const shProg, 
GLuint index,
  }
  
  void GLAPIENTRY

+_mesa_BindAttribLocation_no_error(GLuint program, GLuint index,
+  const GLchar *name)
+{
+   GET_CURRENT_CONTEXT(ctx);


Unfortunately we must add:

   if (!name)
  return;

Because it's not an error to pass NULL;

With that 38-40 are:

Reviewed-by: Timothy Arceri 



+
+   struct gl_shader_program *const shProg =
+  _mesa_lookup_shader_program(ctx, program);
+   bind_attrib_location(shProg, index, name);
+}
+
+void GLAPIENTRY
  _mesa_BindAttribLocation(GLuint program, GLuint index,
   const GLchar *name)
  {
diff --git a/src/mesa/main/shaderapi.h b/src/mesa/main/shaderapi.h
index ccc38d9f75e..b2229f7ced6 100644
--- a/src/mesa/main/shaderapi.h
+++ b/src/mesa/main/shaderapi.h
@@ -143,6 +143,9 @@ extern void GLAPIENTRY
  _mesa_ValidateProgram(GLuint);
  
  
+void GLAPIENTRY

+_mesa_BindAttribLocation_no_error(GLuint program, GLuint, const GLchar *);
+
  extern void GLAPIENTRY
  _mesa_BindAttribLocation(GLuint program, GLuint, const GLchar *);
  


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

Re: [Mesa-dev] [PATCH 37/42] mesa: create read_buffer_err() and always inline read_buffer()

[Timothy Arceri]

On 27/06/17 21:20, Samuel Pitoiset wrote:

Signed-off-by: Samuel Pitoiset 
---
  src/mesa/main/buffers.c | 46 +-
  1 file changed, 29 insertions(+), 17 deletions(-)

diff --git a/src/mesa/main/buffers.c b/src/mesa/main/buffers.c
index d85974afe60..dfee7a4421e 100644
--- a/src/mesa/main/buffers.c
+++ b/src/mesa/main/buffers.c
@@ -738,11 +738,10 @@ _mesa_readbuffer(struct gl_context *ctx, struct 
gl_framebuffer *fb,
   * renderbuffer for reading pixels.
   * \param mode color buffer such as GL_FRONT, GL_BACK, etc.
   */
-static void
+static ALWAYS_INLINE void
  read_buffer(struct gl_context *ctx, struct gl_framebuffer *fb,
-GLenum buffer, const char *caller)
+GLenum buffer, const char *caller, bool no_error)
  {
-   GLbitfield supportedMask;
 gl_buffer_index srcBuffer;
  
 FLUSH_VERTICES(ctx, 0);

@@ -761,18 +760,23 @@ read_buffer(struct gl_context *ctx, struct gl_framebuffer 
*fb,
else
   srcBuffer = read_buffer_enum_to_index(ctx, buffer);


You should also change the code above this from:

  if (_mesa_is_gles3(ctx) && !is_legal_es3_readbuffer_enum(buffer))
 srcBuffer = BUFFER_NONE;
  else

to:

  if (!no_error && _mesa_is_gles3(ctx) &&
  !is_legal_es3_readbuffer_enum(buffer))
 srcBuffer = BUFFER_NONE;
  else

With that patches 26-37 are:

Reviewed-by: Timothy Arceri 

  
-  if (srcBuffer == BUFFER_NONE) {

- _mesa_error(ctx, GL_INVALID_ENUM,
- "%s(invalid buffer %s)", caller,
- _mesa_enum_to_string(buffer));
- return;
-  }
-  supportedMask = supported_buffer_bitmask(ctx, fb);
-  if (((1 << srcBuffer) & supportedMask) == 0) {
- _mesa_error(ctx, GL_INVALID_OPERATION,
- "%s(invalid buffer %s)", caller,
- _mesa_enum_to_string(buffer));
- return;
+  if (!no_error) {
+ GLbitfield supportedMask;
+
+ if (srcBuffer == BUFFER_NONE) {
+_mesa_error(ctx, GL_INVALID_ENUM,
+"%s(invalid buffer %s)", caller,
+_mesa_enum_to_string(buffer));
+return;
+ }
+
+ supportedMask = supported_buffer_bitmask(ctx, fb);
+ if (((1 << srcBuffer) & supportedMask) == 0) {
+_mesa_error(ctx, GL_INVALID_OPERATION,
+"%s(invalid buffer %s)", caller,
+_mesa_enum_to_string(buffer));
+return;
+ }
}
 }
  
@@ -788,11 +792,19 @@ read_buffer(struct gl_context *ctx, struct gl_framebuffer *fb,

  }
  
  
+static void

+read_buffer_err(struct gl_context *ctx, struct gl_framebuffer *fb,
+GLenum buffer, const char *caller)
+{
+   read_buffer(ctx, fb, buffer, caller, false);
+}
+
+
  void GLAPIENTRY
  _mesa_ReadBuffer(GLenum buffer)
  {
 GET_CURRENT_CONTEXT(ctx);
-   read_buffer(ctx, ctx->ReadBuffer, buffer, "glReadBuffer");
+   read_buffer_err(ctx, ctx->ReadBuffer, buffer, "glReadBuffer");
  }
  
  
@@ -811,5 +823,5 @@ _mesa_NamedFramebufferReadBuffer(GLuint framebuffer, GLenum src)

 else
fb = ctx->WinSysReadBuffer;
  
-   read_buffer(ctx, fb, src, "glNamedFramebufferReadBuffer");

+   read_buffer_err(ctx, fb, src, "glNamedFramebufferReadBuffer");
  }


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

Re: [Mesa-dev] [PATCH 01/12] genxml: Silence about a billion unused parameter warnings

[Dylan Baker]

Quoting Dylan Baker (2017-06-27 10:04:47)
> Quoting Ian Romanick (2017-06-26 16:22:34)
> > From: Ian Romanick 
> > 
> > v2: Use textwrap.dedent to make the source line a lot shorter.
> > Shortening (?) the line was requested by Jason.
> > 
> > Signed-off-by: Ian Romanick 
> > ---
> >  src/intel/genxml/gen_pack_header.py | 9 +++--
> >  1 file changed, 7 insertions(+), 2 deletions(-)
> > 
> > diff --git a/src/intel/genxml/gen_pack_header.py 
> > b/src/intel/genxml/gen_pack_header.py
> > index fefbc9a..a96a232 100644
> > --- a/src/intel/genxml/gen_pack_header.py
> > +++ b/src/intel/genxml/gen_pack_header.py
> > @@ -8,6 +8,7 @@ import xml.parsers.expat
> >  import re
> >  import sys
> >  import copy
> > +import textwrap
> >  
> >  license =  """/*
> >   * Copyright (C) 2016 Intel Corporation
> > @@ -578,8 +579,12 @@ class Parser(object):
> >  
> >  def emit_pack_function(self, name, group):
> >  name = self.gen_prefix(name)
> > -print("static inline void\n%s_pack(__gen_user_data *data, void * 
> > restrict dst,\n%sconst struct %s * restrict values)\n{" %
> > -  (name, ' ' * (len(name) + 6), name))
> > +print(textwrap.dedent("""\
> > +static inline void
> > +%s_pack(__attribute__((unused)) __gen_user_data *data,
> > +%s__attribute__((unused)) void * restrict dst,
> > +%s__attribute__((unused)) const struct %s * restrict values)
> > +{""") % (name, ' ' * (len(name) + 6), ' ' * (len(name) + 6), 
> > name))
> 
> There are a couple of things you could do here to simplify this a bit.
> One is that textwrap.dedent will remove the same number of spaces from every
> line (the shortest, so in this case the length removed will be equal to the
> number of spaces before "static"), so you don't need to do the + 6 to the
> len(name), you could just put those in the string. The second is that using
> str.format() will save duplicating the inputs:
> 
> print(textwrap.dedent("""\
> static inline void
> {0}_pack(__attribute__((unused)) __gen_user_data *data,
>   {1}__attribute__((unused)) void * restrict dst,
>   {1}__attribute__((unused)) const struct {0} * restrict values)
> {""").format(name, ' ' * (len(name

Oops, missed something. When you use str.format double braces make a literal
brace, so that last line should be '{{""").format(...)' if you decide to use the
format method.

> 
> Either way,
> Reviewed-by: Dylan Baker 
> 
> >  
> >  (dwords, length) = group.collect_dwords_and_length()
> >  if length:
> > -- 
> > 2.9.4
> > 
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

[Mesa-dev] [Bug 101614] OSMesa 17.1.3 simd16intrin build FAIL on Win/MinGW - 'expected initializer before _simd16_setzero_ps ...'

[bugzilla-daemon]

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

Bug ID: 101614
   Summary: OSMesa 17.1.3 simd16intrin build FAIL on Win/MinGW -
'expected initializer before _simd16_setzero_ps ...'
   Product: Mesa
   Version: 17.1
  Hardware: x86-64 (AMD64)
OS: other
Status: NEW
  Severity: blocker
  Priority: medium
 Component: Drivers/Gallium/swr
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: trevor.sa...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org

Please help ! My mesa build consistently fails at with the following log trace:

src/gallium/drivers/swr/rasterizer/common/simd16intrin.h:127:35: error:
expected initializer before '_simd16_setzero_ps'
SIMD16_EMU_AVX512_0(simd16scalar, _simd16_setzero_ps, _mm256_setzero_ps).
Builds on Linux and OSX are unaffected.

You can see a detailed install log output for Mesa 17.1.3 at
https://gist.github.com/trevorsandy/0f8f83a9f8963911d5a42f8723c772fb and the
same for 17.1.2 at
https://gist.github.com/trevorsandy/69d22f8a0ceeafe298baba9587cd37e9 

I have been chasing this issue for the past week without success. I've read the
content at Mesa3D.org and search across the mail archives. I've also followed
the documented dev env requirements.

The gist URLs above provide a detailed capture of the installation output -
based on this customized install script.
https://github.com/trevorsandy/osmesa-install/blob/master/osmesa-install.sh.
This script can be used to reproduce this behaviour.

Here is the options section of logged output for Mesa 17.1.3:

Mesa build options for platform MINGW64_NT-10.0:
- build date: 28/06/2017 01:15:39
- release, non-debug build
- non-mangled
- swr Gallium renderer
- reuse built source at rebuild
- build llvm: No (Note: using llvm version 4.0.0 already built successfully)
- mesa version: 17.1.3
- osmesa prefix: /opt/osmesa
- glu version: 9.0.0
- execute osmesa demo: No
- CC: gcc
- CXX: g++
- CFLAGS: -O3
- CXXFLAGS: -O3
- msys version: 2017.05-1
- mingw version: 2.28-1
- gcc version: 6.3.0-1
- cmake version: 3.8.1-3
- scons version: 2.5.1-1
- bison/yacc version: 3.0.4-1
- python2 version: 2.7.13-1
- python2-mako version: 1.0.6-2
- libxml2 version: 2.9.2-3
- silent logging
- log file: /home/Trevor/Projects/osmesa-install/osmesa-install_27.log
* extracting Mesa...
* applying patches...
* applying patch add_pi.patch...
(Stripping trailing CRs from patch; use --binary to disable.)
patching file src/compiler/glsl/builtin_functions.cpp
Hunk #1 succeeded at 84 with fuzz 2 (offset 22 lines).
* applying patch gallium-osmesa-threadsafe.patch...
(Stripping trailing CRs from patch; use --binary to disable.)
patching file src/gallium/state_trackers/osmesa/osmesa.c
Hunk #16 succeeded at 881 (offset -1 lines).
* applying patch install-GL-headers.patch...

...

** Mesa scons command line arguments...
** env 
** LLVM_CONFIG="/opt/llvm/bin/llvm-config.exe"
** LLVM="/opt/llvm"
** CFLAGS="-O3"
** CXXFLAGS="-O3 -std=c++11"
** LDFLAGS="-static -s"
** scons
** build="release"
** platform=windows
** toolchain=mingw
** machine="x86_64"
** texture_float=yes
** llvm="yes"
** swr="1"
** verbose=yes
** osmesa

...

Many thanks in advance.

Cheers,

-- 
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
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 25/42] mesa: prepare create_render_buffers() for KHR_no_error support

[Timothy Arceri]

On 27/06/17 21:20, Samuel Pitoiset wrote:

Signed-off-by: Samuel Pitoiset 
---
  src/mesa/main/fbobject.c | 30 --
  1 file changed, 20 insertions(+), 10 deletions(-)

diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index 74b38180900..d16fe6bd21a 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -1705,14 +1705,6 @@ create_render_buffers(struct gl_context *ctx, GLsizei n, 
GLuint *renderbuffers,
 GLuint first;
 GLint i;
  
-   if (n < 0) {

-  _mesa_error(ctx, GL_INVALID_VALUE, "%s(n<0)", func);
-  return;
-   }
-
-   if (!renderbuffers)
-  return;


Same again please leave this here. With that 24-25:

Reviewed-by: Timothy Arceri 


-
 _mesa_HashLockMutex(ctx->Shared->RenderBuffers);
  
 first = _mesa_HashFindFreeKeyBlock(ctx->Shared->RenderBuffers, n);

@@ -1734,11 +1726,29 @@ create_render_buffers(struct gl_context *ctx, GLsizei 
n, GLuint *renderbuffers,
  }
  
  
+static void

+create_render_buffers_err(struct gl_context *ctx, GLsizei n,
+  GLuint *renderbuffers, bool dsa)
+{
+   const char *func = dsa ? "glCreateRenderbuffers" : "glGenRenderbuffers";
+
+   if (n < 0) {
+  _mesa_error(ctx, GL_INVALID_VALUE, "%s(n<0)", func);
+  return;
+   }
+
+   if (!renderbuffers)
+  return;
+
+   create_render_buffers(ctx, n, renderbuffers, dsa);
+}
+
+
  void GLAPIENTRY
  _mesa_GenRenderbuffers(GLsizei n, GLuint *renderbuffers)
  {
 GET_CURRENT_CONTEXT(ctx);
-   create_render_buffers(ctx, n, renderbuffers, false);
+   create_render_buffers_err(ctx, n, renderbuffers, false);
  }
  
  
@@ -1746,7 +1756,7 @@ void GLAPIENTRY

  _mesa_CreateRenderbuffers(GLsizei n, GLuint *renderbuffers)
  {
 GET_CURRENT_CONTEXT(ctx);
-   create_render_buffers(ctx, n, renderbuffers, true);
+   create_render_buffers_err(ctx, n, renderbuffers, true);
  }
  
  


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

Re: [Mesa-dev] [PATCH 13/30] i965/miptree: Add an explicit format parameter to create_for_dri_image

[Jason Ekstrand]

On Tue, Jun 27, 2017 at 12:49 PM, Chad Versace 
wrote:

> On Fri 16 Jun 2017, Jason Ekstrand wrote:
> > ---
> >  src/mesa/drivers/dri/i965/intel_fbo.c | 3 ++-
> >  src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 7 ---
> >  src/mesa/drivers/dri/i965/intel_mipmap_tree.h | 3 ++-
> >  src/mesa/drivers/dri/i965/intel_tex_image.c   | 3 ++-
> >  4 files changed, 10 insertions(+), 6 deletions(-)
>
> I dislike this patch. A lot.
>
> The __DRIimage already has a 'format' member. Why is it necessary to
> override that format? More importantly, *when* is it necessary?
>
> In patch "i965: Use create_for_dri_image in intel_update_image_buffer",
> I see that you pass intel_rb_format(rb) down as the 'format' parameter.
> Is that the only place the override is needed? In that function, why do
> the image's format and the renderbuffer's format differ? When do they
> differ? When they do differ, is it illegal then to update the
> image's format to match? If we don't update the image's format in
> intel_update_image_buffer(), then does the invalidity of
> __DRIimage::format cause potential issues elsewhere?
>

I understand your concern.

Short answer to all of the above: sRGB.

The long answer is that the DRI formats do not specify a colorspace.  (To
be fair, they don't need to because all window system buffers are sRGB).
Depending on the selected visual, the renderbuffer format may be sRGB or
not.  In order for other i965 internals to work sanely, we need the miptree
format to match the renderbuffer format.  We need to somehow copy the
sRGBness.

Would you feel more comfortable with a boolean sRGB parameter?  That would
make the answers to the above questions much more obvious at the cost of
some code.


> [...]
>
> > diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > index 08c13fc..7b4d431 100644
> > --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > @@ -900,12 +900,13 @@ miptree_create_for_planar_image(struct
> brw_context *brw,
> >
> >  struct intel_mipmap_tree *
> >  intel_miptree_create_for_dri_image(struct brw_context *brw,
> > -   __DRIimage *image, GLenum target)
> > +   __DRIimage *image, GLenum target,
> > +   mesa_format format)
> >  {
> > if (image->planar_format && image->planar_format->nplanes > 0)
> >return miptree_create_for_planar_image(brw, image, target);
> >
> > -   if (!brw->ctx.TextureFormatSupported[image->format])
> > +   if (!brw->ctx.TextureFormatSupported[format])
> >return NULL;
>
> The 'format' parameter is ignored if the image has a planar format. That
> makes me suspicious. At a minimum, this needs
>
>   assert(!format == !image->planar_format)
>
> or an explanation of why the assertion is invalid.
>

I think if we do what I suggested above, this will become obvious.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 12/30] i965/miptree: Allocate mt earlier in update winsys

[Jason Ekstrand]

On Tue, Jun 27, 2017 at 12:19 PM, Chad Versace 
wrote:

> On Mon 26 Jun 2017, Pohjolainen, Topi wrote:
> > On Fri, Jun 16, 2017 at 03:41:34PM -0700, Jason Ekstrand wrote:
> > > From: Ben Widawsky 
> > >
> > > Allows us to continue utilizing common miptree creation using
> __DRIimage
> > > without creating a new DRIimage (for the intel_process_dri2_buffer()
> > > case).
> >
> > Just looking this patch locally I don't really understand this commit
> > message. I'll keep on reading if the answer is later in the series..
>
> I second Topi. I don't understand the commit message.
>

I took a very slightly modified version of what topi wrote.


> The code itself looks good, though.
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 27/30] i965/screen: Support import and export of surfaces with CCS

[Jason Ekstrand]

On Mon, Jun 26, 2017 at 12:50 PM, Pohjolainen, Topi <
topi.pohjolai...@gmail.com> wrote:

> On Fri, Jun 16, 2017 at 03:41:49PM -0700, Jason Ekstrand wrote:
> > ---
> >  src/mesa/drivers/dri/i965/intel_screen.c | 55
> +---
> >  1 file changed, 50 insertions(+), 5 deletions(-)
> >
> > diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
> b/src/mesa/drivers/dri/i965/intel_screen.c
> > index 94787ff..7d6adb7 100644
> > --- a/src/mesa/drivers/dri/i965/intel_screen.c
> > +++ b/src/mesa/drivers/dri/i965/intel_screen.c
> > @@ -671,7 +671,21 @@ intel_create_image_common(__DRIscreen *dri_screen,
> >return NULL;
> > }
> >
> > -   image->bo = brw_bo_alloc_tiled(screen->bufmgr, "image", surf.size,
> > +   struct isl_surf aux_surf;
> > +   if (mod_info->aux_usage == ISL_AUX_USAGE_CCS_E) {
> > +  ok = isl_surf_get_ccs_surf(>isl_dev, , _surf,
> 0);
> > +  assert(ok);
> > +  if (!ok) {
> > + free(image);
> > + return NULL;
> > +  }
> > +   } else {
> > +  assert(mod_info->aux_usage == ISL_AUX_USAGE_NONE);
> > +  aux_surf.size = 0;
> > +   }
> > +
> > +   image->bo = brw_bo_alloc_tiled(screen->bufmgr, "image",
> > +  surf.size + aux_surf.size,
> >isl_tiling_to_i915_tiling(mod_
> info->tiling),
> >surf.row_pitch, 0);
> > if (image->bo == NULL) {
> > @@ -683,6 +697,11 @@ intel_create_image_common(__DRIscreen *dri_screen,
> > image->pitch = surf.row_pitch;
> > image->modifier = modifier;
> >
> > +   if (aux_surf.size) {
> > +  image->aux_offset = surf.size;
> > +  image->aux_pitch = aux_surf.row_pitch;
> > +   }
> > +
> > return image;
> >  }
> >
> > @@ -896,18 +915,18 @@ intel_create_image_from_fds_common(__DRIscreen
> *dri_screen,
> > else
> >image->modifier = tiling_to_modifier(image->bo->tiling_mode);
> >
> > +   const struct isl_drm_modifier_info *mod_info =
> > +  isl_drm_modifier_get_info(image->modifier);
> > +
> > int size = 0;
> > +   struct isl_surf surf;
> > for (i = 0; i < f->nplanes; i++) {
> >index = f->planes[i].buffer_index;
> >image->offsets[index] = offsets[index];
> >image->strides[index] = strides[index];
> >
> > -  const struct isl_drm_modifier_info *mod_info =
> > - isl_drm_modifier_get_info(image->modifier);
> > -
> >mesa_format format = driImageFormatToGLFormat(f->
> planes[i].dri_format);
> >
> > -  struct isl_surf surf;
> >ok = isl_surf_init(>isl_dev, ,
> >   .dim = ISL_SURF_DIM_2D,
> >   .format = brw_isl_format_for_mesa_
> format(format),
> > @@ -933,6 +952,32 @@ intel_create_image_from_fds_common(__DRIscreen
> *dri_screen,
> >   size = end;
> > }
> >
> > +   if (mod_info->aux_usage == ISL_AUX_USAGE_CCS_E) {
> > +  /* Even though we initialize surf in the loop above, we know that
> > +   * anything with CCS_E will have exactly one plane so surf is
> properly
> > +   * initialized when we get here.
> > +   */
> > +  assert(f->nplanes == 1);
> > +
> > +  image->aux_offset = offsets[1];
> > +  image->aux_pitch = strides[1];
> > +
> > +  struct isl_surf aux_surf;
> > +  ok = isl_surf_get_ccs_surf(>isl_dev, , _surf,
> > + image->aux_pitch);
> > +  if (!ok) {
> > + brw_bo_unreference(image->bo);
> > + free(image);
> > + return NULL;
> > +  }
> > +
> > +  const int end = image->aux_offset + surf.size;
>
> Shouldn't we use 'aux_surf.size' instead of 'surf.size'?
>

Yes.  Fixed locally.


> > +  if (size < end)
> > + size = end;
> > +   } else {
> > +  assert(mod_info->aux_usage == ISL_AUX_USAGE_NONE);
> > +   }
> > +
> > /* Check that the requested image actually fits within the BO. 'size'
> >  * is already relative to the offsets, so we don't need to add that.
> */
> > if (image->bo->size == 0) {
> > --
> > 2.5.0.400.gff86faf
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] vulkan/util: Introduce format utilities

[Dave Airlie]

>
>
> Drive-by: Yes, I agree that this doesn't match Vulkan particularly well.
> It's a very X11 or drm_fourcc way of described formats and is nothing like
> anything else we have in mesa.  That doesn't mean it's strictly wrong, just
> that it's awkward to people who are used to some of the other mechanisms for
> describing formats.
>

For radv I mostly copied stuff from gallium, probably badly, but I'd
much prefer that
we tend towards one solution, and I'm not sure this is where I'd want
to go either.

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

Re: [Mesa-dev] [PATCH 1/2] vulkan/util: Introduce format utilities

[Jason Ekstrand]

On Tue, Jun 27, 2017 at 4:29 PM, Chad Versace 
wrote:

> On Fri 23 Jun 2017, alexandros.frant...@collabora.com wrote:
> > From: Alexandros Frantzis 
> >
> > Introduce utilities to describe, find and compare Vulkan formats based
> > on their color component masks, taking into account system endianness.
> > ---
> >  src/vulkan/Makefile.sources  |   2 +
> >  src/vulkan/util/vk_format_util.c | 173 ++
> +
> >  src/vulkan/util/vk_format_util.h | 100 ++
> >  3 files changed, 275 insertions(+)
> >  create mode 100644 src/vulkan/util/vk_format_util.c
> >  create mode 100644 src/vulkan/util/vk_format_util.h
> >
> > diff --git a/src/vulkan/Makefile.sources b/src/vulkan/Makefile.sources
> > index 2cf7218e92..f4f1f14d5a 100644
> > --- a/src/vulkan/Makefile.sources
> > +++ b/src/vulkan/Makefile.sources
> > @@ -17,6 +17,8 @@ VULKAN_WSI_X11_FILES := \
> >
> >  VULKAN_UTIL_FILES := \
> >   util/vk_alloc.h \
> > + util/vk_format_util.c \
> > + util/vk_format_util.h \
> >   util/vk_util.c \
> >   util/vk_util.h
> >
> > diff --git a/src/vulkan/util/vk_format_util.c
> b/src/vulkan/util/vk_format_util.c
> > new file mode 100644
> > index 00..aa6d403e84
> > --- /dev/null
> > +++ b/src/vulkan/util/vk_format_util.c
> > @@ -0,0 +1,173 @@
> > +/*
> > + * Copyright © 2017 Collabora Ltd.
> > + *
> > + * 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 (including the
> next
> > + * paragraph) shall be included in all copies or substantial portions
> of the
> > + * Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> EXPRESS OR
> > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> MERCHANTABILITY,
> > + * FITNESS FOR A PARTICULAR PURPOSE AND 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.
> > + */
> > +
> > +#include "vk_format_util.h"
> > +
> > +#include "util/u_vector.h"
> > +#include "util/u_math.h"
> > +
> > +#include 
> > +
> > +static inline uint32_t
> > +bswap24(uint32_t n)
> > +{
> > +   return (n & 0xff00) |
> > +  ((n >> 16) & 0x00ff) |
> > +  (n & 0xff00) |
> > +  ((n << 16) & 0x00ff);
> > +}
> > +
> > +static inline uint32_t
> > +bswap(uint32_t n, int bits)
> > +{
> > +   switch (bits)
> > +   {
>
> Mesa code-style puts the '{' on the same line as 'switch'.
>
> > +   case 8:
> > +  return n;
> > +   case 16:
> > +  return util_bswap16(n);
> > +   case 24:
> > +  return bswap24(n);
> > +   case 32:
> > +  return util_bswap32(n);
> > +   default:
> > +  assert(!"Invalid bswap bits");
> > +  return n;
>
> If someone passes an invalid param here, there's little point in
> continuing, even in release builds, because continuing will produce only
> undefined behavior. So let's optimize the release build by removing the
> default case, like this:
>
> bswap(...)
> {
> switch (bits) {
> case 8:
> ...
> case 16:
> ...
> case 32:
> ...
> }
>
> unreachable("invalid bswap bits");
> }
>
> > +   }
> > +}
> > +
> > +struct format_spec {
> > +   VkFormat format;
> > +   struct vk_format_util_spec spec;
> > +};
> > +
> > +#define VF(FMT, BPP, R, G, B, A, E, S) \
> > +   {VK_FORMAT_##FMT, {BPP, R, G, B, A, VK_FORMAT_UTIL_ENDIANNESS_##E,
> VK_FORMAT_UTIL_##S}}
> > +
> > +// SRGB formats are presented to the user before the UNORM ones.
>
> The comment should explain why the sRGB formats precede the others.
>
> Also, Mesa code-style uses /* comments, not // comments.
>
> > +static const struct format_spec format_specs[] = {
> > +   VF(R8_SRGB, 8, 0x00ff, 0x, 0x, 0x, BIG,
> SWAPPABLE),
> > +   VF(R8G8_SRGB, 16, 0xff00, 0x00ff, 0x, 0x,
> BIG, SWAPPABLE),
> > +   VF(R8G8B8_SRGB, 24, 0x00ff, 0xff00, 0x00ff, 0x,
> BIG, SWAPPABLE),
> > +   VF(B8G8R8_SRGB, 24, 0x00ff, 0xff00, 0x00ff, 0x,
> BIG, SWAPPABLE),
> > +   VF(R8G8B8A8_SRGB, 32, 0xff00, 0x00ff, 0xff00,
> 0x00ff, BIG, SWAPPABLE),
> > +   VF(B8G8R8A8_SRGB, 32, 0xff00, 0x00ff, 

[Mesa-dev] [AppVeyor] mesa master #4772 failed

[AppVeyor]

Build mesa 4772 failed


Commit 74db56b97a by Chad Versace on 5/30/2017 7:27 PM:

i965: Add a RGBX->RGBA fallback for glEGLImageTextureTarget2D()\n\nThis enables support for importing RGBX EGLImage textures on\nSkylake.\n\nChrome OS needs support for RGBX EGLImage textures because because\nthe Android framework produces HAL_PIXEL_FORMAT_RGBX winsys\nsurfaces, which the Chrome OS compositor consumes as dma_bufs.  On\nhardware for which RGBX is unsupported or disabled, normally core Mesa\nprovides the RGBX->RGBA fallback during glTexStorage.  But the DRIimage\ncode bypasses core Mesa, so we must do the fallback in i965.\n\nReviewed-by: Kenneth Graunke 


Configure your notification preferences

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

Re: [Mesa-dev] [PATCH 3/3] i965/dri: Support R8G8B8A8 and R8G8B8X8 configs

[Chad Versace]

Daniel, I have a question for you below.

On Tue 27 Jun 2017, Kenneth Graunke wrote:
> On Tuesday, June 27, 2017 11:00:48 AM PDT Chad Versace wrote:
> > The Android framework requires support for EGLConfigs with
> > HAL_PIXEL_FORMAT_RGBX_ and HAL_PIXEL_FORMAT_RGBA_.
> > 
> > Even though all RGBX formats are disabled on gen9 by
> > brw_surface_formats.c, the new configs work correctly on Broxton thanks
> > to _mesa_format_fallback_rgbx_to_rgba().
> > 
> > On GLX, this creates no new configs, and therefore breaks no existing
> > apps. See in-patch comments for explanation. I tested with glxinfo and
> > glxgears on Skylake.
> > 
> > On Wayland, this also creates no new configs, and therfore breaks no
> > existing apps. (I tested with mesa-demos' eglinfo and es2gears_wayland
> > on Skylake). The reason differs from GLX, though. In
> > dri2_wl_add_configs_for_visual(), the format table contains only
> > B8G8R8X8, B8G8R8A8, and B5G6B5; and dri2_add_config() correctly matches
> > EGLConfig to format by inspecting channel masks.
> > 
> > On Android, in Chrome OS, I tested this on a Broxton device. I confirmed
> > that the Google Play Store's EGLSurface used HAL_PIXEL_FORMAT_RGBA_,
> > and that an Asteroid game's EGLSurface used HAL_PIXEL_FORMAT_RGBX_.
> > Both apps worked well. (Disclaimer: I didn't test this patch on Android
> > with Mesa master. I backported this patch series to an older Android
> > branch).
> > ---
> >  src/mesa/drivers/dri/i965/intel_fbo.c| 23 +--
> >  src/mesa/drivers/dri/i965/intel_screen.c | 23 ++-
> >  2 files changed, 43 insertions(+), 3 deletions(-)
> > 

[snip]

> > diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
> > b/src/mesa/drivers/dri/i965/intel_screen.c
> > index 8621af26378..0e03c56cf88 100644
> > --- a/src/mesa/drivers/dri/i965/intel_screen.c
> > +++ b/src/mesa/drivers/dri/i965/intel_screen.c
> > @@ -1717,7 +1717,28 @@ intel_screen_make_configs(__DRIscreen *dri_screen)
> > static const mesa_format formats[] = {
> >MESA_FORMAT_B5G6R5_UNORM,
> >MESA_FORMAT_B8G8R8A8_UNORM,
> > -  MESA_FORMAT_B8G8R8X8_UNORM
> > +  MESA_FORMAT_B8G8R8X8_UNORM,
> > +
> > +  /* The 32-bit RGBA format must not precede the 32-bit BGRA format.
> > +   * Likewise for RGBX and BGRX.  Otherwise, the GLX client and the GLX
> > +   * server may disagree on which format the GLXFBConfig represents,
> > +   * resulting in swapped color channels.
> > +   *
> > +   * The problem, as of 2017-05-30:
> > +   * When matching a GLXFBConfig to a __DRIconfig, GLX ignores the 
> > channel
> > +   * order and chooses the first __DRIconfig with the expected channel
> > +   * sizes. Specifically, GLX compares the GLXFBConfig's and 
> > __DRIconfig's
> > +   * __DRI_ATTRIB_{CHANNEL}_SIZE but ignores 
> > __DRI_ATTRIB_{CHANNEL}_MASK.
> 
> The series is:
> Reviewed-by: Kenneth Graunke 

Thanks!

> But, I still think this should be fixed.  This seems fragile - we're
> essentially relying on a bug in the GLX code.

Yeah, I don't like it either. I was afraid to fix the GLX code
because I was afraid of accidentally breaking some unspecified behavior
that either the X server or GLX clients implicitly relied on. GLX is
full of historical mysteries like that.

> I suppose fixing it would cause GLX to begin exposing new RGBA visuals
> (in addition to BGRA).  I don't think we want to do that - I don't see much
> point outside of Android.  It's mostly harmless, except that changing the
> visuals ends up being absurdly painful for driver developers, since the X
> server and clients need to agree on lists.  That means you can't move across
> the change point without updating the Mesa your X server uses and restarting
> the X server.
> 
> If we do fix GLX, and want to avoid exposing visuals, I think we could
> easily add an #ifdef ANDROID.  Is there some reason to not go ahead and
> do that now?

For now, there's no reason to not #ifdef ANDROID the new config formats.
And I'll squash that into this patch if you ask.

But, I intentionally did not #ifdef ANDROID the new formats just in case
Wayland wanted to use them. Currently,
src/egl/drivers/dri/platform_wayland.c will not use them. But, I suspect
that Wayland would use them (but not require them) after Daniel Stone's
patches land, in series "EGL/Wayland modifiers, format cleanup".

^^^ Daniel, is that correct?

> Also...did we fix the visual ordering problem?  Earlier you mentioned that
> this patch wouldn't work for Android, because we needed to move the RGBA
> formats above the BGRA ones (but that wouldn't work for X).  But I think
> you said you had EGL patches which fixed that, and I'm pretty sure those
> landed.  So...we're good now?

It's all good now. Android visuals are in the correct order. See
commit 5e884353e64 egl/android: Change order of EGLConfig generation (v2).

> 
> > +   *
> > +   * EGL does not suffer from 

Re: [Mesa-dev] [PATCH 23/42] mesa: prepare create_program_pipelines() for KHR_no_error support

[Timothy Arceri]

On 27/06/17 21:20, Samuel Pitoiset wrote:

Signed-off-by: Samuel Pitoiset 
---
  src/mesa/main/pipelineobj.c | 33 +++--
  1 file changed, 19 insertions(+), 14 deletions(-)

diff --git a/src/mesa/main/pipelineobj.c b/src/mesa/main/pipelineobj.c
index 0f0d1dafffe..ca17fa3f06c 100644
--- a/src/mesa/main/pipelineobj.c
+++ b/src/mesa/main/pipelineobj.c
@@ -603,21 +603,10 @@ static void
  create_program_pipelines(struct gl_context *ctx, GLsizei n, GLuint *pipelines,
   bool dsa)
  {
-   const char *func;
+   const char *func = dsa ? "glCreateProgramPipelines" : 
"glGenProgramPipelines";
 GLuint first;
 GLint i;
  
-   func = dsa ? "glCreateProgramPipelines" : "glGenProgramPipelines";

-
-   if (n < 0) {
-  _mesa_error(ctx, GL_INVALID_VALUE, "%s (n < 0)", func);
-  return;
-   }
-
-   if (!pipelines) {
-  return;
-   }


again please leave. With that 22-23:

Reviewed-by: Timothy Arceri 


-
 first = _mesa_HashFindFreeKeyBlock(ctx->Pipeline.Objects, n);
  
 for (i = 0; i < n; i++) {

@@ -638,7 +627,23 @@ create_program_pipelines(struct gl_context *ctx, GLsizei 
n, GLuint *pipelines,
save_pipeline_object(ctx, obj);
pipelines[i] = first + i;
 }
+}
+
+static void
+create_program_pipelines_err(struct gl_context *ctx, GLsizei n,
+ GLuint *pipelines, bool dsa)
+{
+   const char *func = dsa ? "glCreateProgramPipelines" : 
"glGenProgramPipelines";
+
+   if (n < 0) {
+  _mesa_error(ctx, GL_INVALID_VALUE, "%s (n < 0)", func);
+  return;
+   }
+
+   if (!pipelines)
+  return;
  
+   create_program_pipelines(ctx, n, pipelines, dsa);

  }
  
  void GLAPIENTRY

@@ -649,7 +654,7 @@ _mesa_GenProgramPipelines(GLsizei n, GLuint *pipelines)
 if (MESA_VERBOSE & VERBOSE_API)
_mesa_debug(ctx, "glGenProgramPipelines(%d, %p)\n", n, pipelines);
  
-   create_program_pipelines(ctx, n, pipelines, false);

+   create_program_pipelines_err(ctx, n, pipelines, false);
  }
  
  void GLAPIENTRY

@@ -660,7 +665,7 @@ _mesa_CreateProgramPipelines(GLsizei n, GLuint *pipelines)
 if (MESA_VERBOSE & VERBOSE_API)
_mesa_debug(ctx, "glCreateProgramPipelines(%d, %p)\n", n, pipelines);
  
-   create_program_pipelines(ctx, n, pipelines, true);

+   create_program_pipelines_err(ctx, n, pipelines, true);
  }
  
  /**



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

Re: [Mesa-dev] [PATCH 21/42] mesa: prepare create_samplers() helper for KHR_no_error support

[Timothy Arceri]

On 27/06/17 21:20, Samuel Pitoiset wrote:

Signed-off-by: Samuel Pitoiset 
---
  src/mesa/main/samplerobj.c | 37 ++---
  1 file changed, 22 insertions(+), 15 deletions(-)

diff --git a/src/mesa/main/samplerobj.c b/src/mesa/main/samplerobj.c
index d3ed4da3932..2fbaab9a8dc 100644
--- a/src/mesa/main/samplerobj.c
+++ b/src/mesa/main/samplerobj.c
@@ -154,23 +154,11 @@ _mesa_new_sampler_object(struct gl_context *ctx, GLuint 
name)
  }
  
  static void

-create_samplers(struct gl_context *ctx, GLsizei count, GLuint *samplers,
-const char *caller)
+create_samplers(struct gl_context *ctx, GLsizei count, GLuint *samplers)
  {
 GLuint first;
 GLint i;
  
-   if (MESA_VERBOSE & VERBOSE_API)

-  _mesa_debug(ctx, "%s(%d)\n", caller, count);
-
-   if (count < 0) {
-  _mesa_error(ctx, GL_INVALID_VALUE, "%s(n<0)", caller);
-  return;
-   }
-
-   if (!samplers)
-  return;


Again please leave this here. With that 20-21:

Reviewed-by: Timothy Arceri 


-
 _mesa_HashLockMutex(ctx->Shared->SamplerObjects);
  
 first = _mesa_HashFindFreeKeyBlock(ctx->Shared->SamplerObjects, count);

@@ -186,18 +174,37 @@ create_samplers(struct gl_context *ctx, GLsizei count, 
GLuint *samplers,
 _mesa_HashUnlockMutex(ctx->Shared->SamplerObjects);
  }
  
+static void

+create_samplers_err(struct gl_context *ctx, GLsizei count, GLuint *samplers,
+const char *caller)
+{
+
+   if (MESA_VERBOSE & VERBOSE_API)
+  _mesa_debug(ctx, "%s(%d)\n", caller, count);
+
+   if (count < 0) {
+  _mesa_error(ctx, GL_INVALID_VALUE, "%s(n<0)", caller);
+  return;
+   }
+
+   if (!samplers)
+  return;
+
+   create_samplers(ctx, count, samplers);
+}
+
  void GLAPIENTRY
  _mesa_GenSamplers(GLsizei count, GLuint *samplers)
  {
 GET_CURRENT_CONTEXT(ctx);
-   create_samplers(ctx, count, samplers, "glGenSamplers");
+   create_samplers_err(ctx, count, samplers, "glGenSamplers");
  }
  
  void GLAPIENTRY

  _mesa_CreateSamplers(GLsizei count, GLuint *samplers)
  {
 GET_CURRENT_CONTEXT(ctx);
-   create_samplers(ctx, count, samplers, "glCreateSamplers");
+   create_samplers_err(ctx, count, samplers, "glCreateSamplers");
  }
  
  


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

Re: [Mesa-dev] [PATCH 0/2] vulkan/wsi/wayland: Improve surface format support

[Chad Versace]

On Fri 23 Jun 2017, alexandros.frant...@collabora.com wrote:
> From: Alexandros Frantzis 
> 
> Improve the surface format support in the Wayland Vulkan WSI, by
> automating the matching between wl_drm and Vulkan formats. The same
> mechanism can be used to improve format support in vulkan/wsi/x11
> (in a future patchset).

Thanks for attacking this problem, and attempting to fix the format
hacks in wsi_common_wayland.c.

I suspect that the two of us have significant differences in our
interpretation of VkFormat bit-layouts. I've responded to patch 1/1 with
a lot of comments and questions. Hopefully we can untangle our format
interpretations and we reach a common understanding.

> 
> Alexandros Frantzis (2):
>   vulkan/util: Introduce format utilities
>   vulkan/wsi/wayland: Use the format utilities to find compatible
> VkFormats
> 
>  src/vulkan/Makefile.sources |   2 +
>  src/vulkan/util/vk_format_util.c| 173 +++
>  src/vulkan/util/vk_format_util.h| 100 
>  src/vulkan/wsi/wsi_common_wayland.c | 178 
> ++--
>  4 files changed, 366 insertions(+), 87 deletions(-)
>  create mode 100644 src/vulkan/util/vk_format_util.c
>  create mode 100644 src/vulkan/util/vk_format_util.h
> 
> -- 
> 2.11.0
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 19/42] mesa: prepare create_textures() helper for KHR_no_error support

[Timothy Arceri]

On 27/06/17 21:20, Samuel Pitoiset wrote:

Signed-off-by: Samuel Pitoiset 
---
  src/mesa/main/texobj.c | 34 +-
  1 file changed, 21 insertions(+), 13 deletions(-)

diff --git a/src/mesa/main/texobj.c b/src/mesa/main/texobj.c
index 0fcf5839689..1b2bb50d1d3 100644
--- a/src/mesa/main/texobj.c
+++ b/src/mesa/main/texobj.c
@@ -1195,17 +1195,6 @@ create_textures(struct gl_context *ctx, GLenum target,
 GLuint first;
 GLint i;
  
-   if (MESA_VERBOSE & (VERBOSE_API|VERBOSE_TEXTURE))

-  _mesa_debug(ctx, "%s %d\n", caller, n);
-
-   if (n < 0) {
-  _mesa_error(ctx, GL_INVALID_VALUE, "%s(n < 0)", caller);
-  return;
-   }
-
-   if (!textures)
-  return;


Again this is not an error so we should not be skipping it. With this 
left here.


17-19:

Reviewed-by: Timothy Arceri 


-
 /*
  * This must be atomic (generation and allocation of texture IDs)
  */
@@ -1233,6 +1222,25 @@ create_textures(struct gl_context *ctx, GLenum target,
 _mesa_HashUnlockMutex(ctx->Shared->TexObjects);
  }
  
+

+static void
+create_textures_err(struct gl_context *ctx, GLenum target,
+GLsizei n, GLuint *textures, const char *caller)
+{
+   if (MESA_VERBOSE & (VERBOSE_API|VERBOSE_TEXTURE))
+  _mesa_debug(ctx, "%s %d\n", caller, n);
+
+   if (n < 0) {
+  _mesa_error(ctx, GL_INVALID_VALUE, "%s(n < 0)", caller);
+  return;
+   }
+
+   if (!textures)
+  return;
+
+   create_textures(ctx, target, n, textures, caller);
+}
+
  /*@}*/
  
  
@@ -1257,7 +1265,7 @@ void GLAPIENTRY

  _mesa_GenTextures(GLsizei n, GLuint *textures)
  {
 GET_CURRENT_CONTEXT(ctx);
-   create_textures(ctx, 0, n, textures, "glGenTextures");
+   create_textures_err(ctx, 0, n, textures, "glGenTextures");
  }
  
  /**

@@ -1290,7 +1298,7 @@ _mesa_CreateTextures(GLenum target, GLsizei n, GLuint 
*textures)
return;
 }
  
-   create_textures(ctx, target, n, textures, "glCreateTextures");

+   create_textures_err(ctx, target, n, textures, "glCreateTextures");
  }
  
  /**



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

Re: [Mesa-dev] [PATCH 1/2] vulkan/util: Introduce format utilities

[Chad Versace]

On Fri 23 Jun 2017, alexandros.frant...@collabora.com wrote:
> From: Alexandros Frantzis 
> 
> Introduce utilities to describe, find and compare Vulkan formats based
> on their color component masks, taking into account system endianness.
> ---
>  src/vulkan/Makefile.sources  |   2 +
>  src/vulkan/util/vk_format_util.c | 173 
> +++
>  src/vulkan/util/vk_format_util.h | 100 ++
>  3 files changed, 275 insertions(+)
>  create mode 100644 src/vulkan/util/vk_format_util.c
>  create mode 100644 src/vulkan/util/vk_format_util.h
> 
> diff --git a/src/vulkan/Makefile.sources b/src/vulkan/Makefile.sources
> index 2cf7218e92..f4f1f14d5a 100644
> --- a/src/vulkan/Makefile.sources
> +++ b/src/vulkan/Makefile.sources
> @@ -17,6 +17,8 @@ VULKAN_WSI_X11_FILES := \
>  
>  VULKAN_UTIL_FILES := \
>   util/vk_alloc.h \
> + util/vk_format_util.c \
> + util/vk_format_util.h \
>   util/vk_util.c \
>   util/vk_util.h
>  
> diff --git a/src/vulkan/util/vk_format_util.c 
> b/src/vulkan/util/vk_format_util.c
> new file mode 100644
> index 00..aa6d403e84
> --- /dev/null
> +++ b/src/vulkan/util/vk_format_util.c
> @@ -0,0 +1,173 @@
> +/*
> + * Copyright © 2017 Collabora Ltd.
> + *
> + * 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 (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND 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.
> + */
> +
> +#include "vk_format_util.h"
> +
> +#include "util/u_vector.h"
> +#include "util/u_math.h"
> +
> +#include 
> +
> +static inline uint32_t
> +bswap24(uint32_t n)
> +{
> +   return (n & 0xff00) |
> +  ((n >> 16) & 0x00ff) |
> +  (n & 0xff00) |
> +  ((n << 16) & 0x00ff);
> +}
> +
> +static inline uint32_t
> +bswap(uint32_t n, int bits)
> +{
> +   switch (bits)
> +   {

Mesa code-style puts the '{' on the same line as 'switch'.

> +   case 8:
> +  return n;
> +   case 16:
> +  return util_bswap16(n);
> +   case 24:
> +  return bswap24(n);
> +   case 32:
> +  return util_bswap32(n);
> +   default:
> +  assert(!"Invalid bswap bits");
> +  return n;

If someone passes an invalid param here, there's little point in
continuing, even in release builds, because continuing will produce only
undefined behavior. So let's optimize the release build by removing the
default case, like this:

bswap(...)
{
switch (bits) {
case 8:
...
case 16:
...
case 32:
...
}

unreachable("invalid bswap bits");
}

> +   }
> +}
> +
> +struct format_spec {
> +   VkFormat format;
> +   struct vk_format_util_spec spec;
> +};
> +
> +#define VF(FMT, BPP, R, G, B, A, E, S) \
> +   {VK_FORMAT_##FMT, {BPP, R, G, B, A, VK_FORMAT_UTIL_ENDIANNESS_##E, 
> VK_FORMAT_UTIL_##S}}
> +
> +// SRGB formats are presented to the user before the UNORM ones.

The comment should explain why the sRGB formats precede the others.

Also, Mesa code-style uses /* comments, not // comments.

> +static const struct format_spec format_specs[] = {
> +   VF(R8_SRGB, 8, 0x00ff, 0x, 0x, 0x, BIG, 
> SWAPPABLE),
> +   VF(R8G8_SRGB, 16, 0xff00, 0x00ff, 0x, 0x, BIG, 
> SWAPPABLE),
> +   VF(R8G8B8_SRGB, 24, 0x00ff, 0xff00, 0x00ff, 0x, BIG, 
> SWAPPABLE),
> +   VF(B8G8R8_SRGB, 24, 0x00ff, 0xff00, 0x00ff, 0x, BIG, 
> SWAPPABLE),
> +   VF(R8G8B8A8_SRGB, 32, 0xff00, 0x00ff, 0xff00, 0x00ff, 
> BIG, SWAPPABLE),
> +   VF(B8G8R8A8_SRGB, 32, 0xff00, 0x00ff, 0xff00, 0x00ff, 
> BIG, SWAPPABLE),
> +   VF(A8B8G8R8_SRGB_PACK32, 32, 0x00ff, 0xff00, 0x00ff, 
> 0xff00, NATIVE, SWAPPABLE),
> +
> +   VF(R8_UNORM, 8, 0x00ff, 0x, 0x, 0x, BIG, 
> SWAPPABLE),
> +   VF(R8G8_UNORM, 16, 0xff00, 0x00ff, 0x, 0x, BIG, 
> SWAPPABLE),
> +   

Re: [Mesa-dev] [PATCH 16/42] mesa: prepare create_buffers() helper for KHR_no_error support

[Timothy Arceri]

On 27/06/17 21:20, Samuel Pitoiset wrote:

Signed-off-by: Samuel Pitoiset 
---
  src/mesa/main/bufferobj.c | 45 ++---
  1 file changed, 26 insertions(+), 19 deletions(-)

diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
index 6e2979f6db9..e31fcc357da 100644
--- a/src/mesa/main/bufferobj.c
+++ b/src/mesa/main/bufferobj.c
@@ -1416,26 +1416,11 @@ _mesa_DeleteBuffers(GLsizei n, const GLuint *ids)
   * driver internals.
   */
  static void
-create_buffers(GLsizei n, GLuint *buffers, bool dsa)
+create_buffers(struct gl_context *ctx, GLsizei n, GLuint *buffers, bool dsa)
  {
-   GET_CURRENT_CONTEXT(ctx);
 GLuint first;
 struct gl_buffer_object *buf;
  
-   const char *func = dsa ? "glCreateBuffers" : "glGenBuffers";

-
-   if (MESA_VERBOSE & VERBOSE_API)
-  _mesa_debug(ctx, "%s(%d)\n", func, n);
-
-   if (n < 0) {
-  _mesa_error(ctx, GL_INVALID_VALUE, "%s(n %d < 0)", func, n);
-  return;
-   }
-
-   if (!buffers) {
-  return;
-   }


Passing NULL buffers is not an error so we should leave this here. It 
should just return on a no error path also.


With that:

Reviewed-by: Timothy Arceri 


-
 /*
  * This must be atomic (generation and allocation of buffer object IDs)
  */
@@ -1453,7 +1438,7 @@ create_buffers(GLsizei n, GLuint *buffers, bool dsa)
   assert(ctx->Driver.NewBufferObject);
   buf = ctx->Driver.NewBufferObject(ctx, buffers[i]);
   if (!buf) {
-_mesa_error(ctx, GL_OUT_OF_MEMORY, "%s", func);
+_mesa_error(ctx, GL_OUT_OF_MEMORY, "glCreateBuffers");
  _mesa_HashUnlockMutex(ctx->Shared->BufferObjects);
  return;
   }
@@ -1467,6 +1452,26 @@ create_buffers(GLsizei n, GLuint *buffers, bool dsa)
 _mesa_HashUnlockMutex(ctx->Shared->BufferObjects);
  }
  
+

+static void
+create_buffers_err(struct gl_context *ctx, GLsizei n, GLuint *buffers, bool 
dsa)
+{
+   const char *func = dsa ? "glCreateBuffers" : "glGenBuffers";
+
+   if (MESA_VERBOSE & VERBOSE_API)
+  _mesa_debug(ctx, "%s(%d)\n", func, n);
+
+   if (n < 0) {
+  _mesa_error(ctx, GL_INVALID_VALUE, "%s(n %d < 0)", func, n);
+  return;
+   }
+
+   if (!buffers)
+  return;
+
+   create_buffers(ctx, n, buffers, dsa);
+}
+
  /**
   * Generate a set of unique buffer object IDs and store them in \c buffers.
   *
@@ -1476,7 +1481,8 @@ create_buffers(GLsizei n, GLuint *buffers, bool dsa)
  void GLAPIENTRY
  _mesa_GenBuffers(GLsizei n, GLuint *buffers)
  {
-   create_buffers(n, buffers, false);
+   GET_CURRENT_CONTEXT(ctx);
+   create_buffers_err(ctx, n, buffers, false);
  }
  
  /**

@@ -1488,7 +1494,8 @@ _mesa_GenBuffers(GLsizei n, GLuint *buffers)
  void GLAPIENTRY
  _mesa_CreateBuffers(GLsizei n, GLuint *buffers)
  {
-   create_buffers(n, buffers, true);
+   GET_CURRENT_CONTEXT(ctx);
+   create_buffers_err(ctx, n, buffers, true);
  }
  
  


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

Re: [Mesa-dev] [PATCH 15/42] mesa: add KHR_no_error support for glBindTextureUnit()

[Timothy Arceri]

5-15:

Reviewed-by: Timothy Arceri 

On 27/06/17 21:20, Samuel Pitoiset wrote:

Signed-off-by: Samuel Pitoiset 
---
  src/mapi/glapi/gen/ARB_direct_state_access.xml | 2 +-
  src/mesa/main/texobj.c | 8 
  src/mesa/main/texobj.h | 3 +++
  3 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/src/mapi/glapi/gen/ARB_direct_state_access.xml 
b/src/mapi/glapi/gen/ARB_direct_state_access.xml
index c9031c1a1ac..860bbbd28ab 100644
--- a/src/mapi/glapi/gen/ARB_direct_state_access.xml
+++ b/src/mapi/glapi/gen/ARB_direct_state_access.xml
@@ -518,7 +518,7 @@

 
  
-   

+   


 
diff --git a/src/mesa/main/texobj.c b/src/mesa/main/texobj.c
index 5337f0513e4..30d3c961e6e 100644
--- a/src/mesa/main/texobj.c
+++ b/src/mesa/main/texobj.c
@@ -1741,6 +1741,14 @@ bind_texture_unit(struct gl_context *ctx, GLuint unit, 
GLuint texture,
  
  
  void GLAPIENTRY

+_mesa_BindTextureUnit_no_error(GLuint unit, GLuint texture)
+{
+   GET_CURRENT_CONTEXT(ctx);
+   bind_texture_unit(ctx, unit, texture, true);
+}
+
+
+void GLAPIENTRY
  _mesa_BindTextureUnit(GLuint unit, GLuint texture)
  {
 GET_CURRENT_CONTEXT(ctx);
diff --git a/src/mesa/main/texobj.h b/src/mesa/main/texobj.h
index 1c68bd8ec7d..a82c9722639 100644
--- a/src/mesa/main/texobj.h
+++ b/src/mesa/main/texobj.h
@@ -190,6 +190,9 @@ _mesa_DeleteTextures( GLsizei n, const GLuint *textures );
  extern void GLAPIENTRY
  _mesa_BindTexture( GLenum target, GLuint texture );
  
+void GLAPIENTRY

+_mesa_BindTextureUnit_no_error(GLuint unit, GLuint texture);
+
  extern void GLAPIENTRY
  _mesa_BindTextureUnit(GLuint unit, GLuint texture);
  


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

Re: [Mesa-dev] [PATCH 04/42] mesa: pass the 'caller' function to create_shader()

[Timothy Arceri]

On 27/06/17 21:20, Samuel Pitoiset wrote:

Signed-off-by: Samuel Pitoiset 
---
  src/mesa/main/shaderapi.c | 12 ++--
  1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
index 7318833e9b8..bb944191813 100644
--- a/src/mesa/main/shaderapi.c
+++ b/src/mesa/main/shaderapi.c
@@ -325,14 +325,14 @@ attach_shader(struct gl_context *ctx, GLuint program, 
GLuint shader)
  
  
  static GLuint

-create_shader(struct gl_context *ctx, GLenum type)
+create_shader(struct gl_context *ctx, GLenum type, const char *caller)
  {
 struct gl_shader *sh;
 GLuint name;
  
 if (!_mesa_validate_shader_target(ctx, type)) {

-  _mesa_error(ctx, GL_INVALID_ENUM, "CreateShader(%s)",
-  _mesa_enum_to_string(type));
+  _mesa_error(ctx, GL_INVALID_ENUM, "%s(%s)",
+  caller, _mesa_enum_to_string(type));
return 0;
 }
  
@@ -1396,7 +1396,7 @@ _mesa_CreateShader(GLenum type)

 GET_CURRENT_CONTEXT(ctx);
 if (MESA_VERBOSE & VERBOSE_API)
_mesa_debug(ctx, "glCreateShader %s\n", _mesa_enum_to_string(type));
-   return create_shader(ctx, type);
+   return create_shader(ctx, type, "glCreateShader");
  }
  
  
@@ -1404,7 +1404,7 @@ GLhandleARB GLAPIENTRY

  _mesa_CreateShaderObjectARB(GLenum type)
  {
 GET_CURRENT_CONTEXT(ctx);
-   return create_shader(ctx, type);
+   return create_shader(ctx, type, "glCreateShaderObjectARB");
  }
  
  
@@ -2270,7 +2270,7 @@ _mesa_CreateShaderProgramv(GLenum type, GLsizei count,

  {
 GET_CURRENT_CONTEXT(ctx);
  
-   const GLuint shader = create_shader(ctx, type);

+   const GLuint shader = create_shader(ctx, type, "glCreateShaderProgram");


glCreateShaderProgram -> glCreateShaderProgramv

With that:

Reviewed-by: Timothy Arceri 


 GLuint program = 0;
  
 /*



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

Re: [Mesa-dev] [PATCH 03/42] mesa: add KHR_no_error support for glAttachShader() and glAttachObjectARB()

[Timothy Arceri]

On 27/06/17 21:20, Samuel Pitoiset wrote:

Signed-off-by: Samuel Pitoiset 
---
  src/mapi/glapi/gen/gl_API.xml |  4 ++--
  src/mesa/main/shaderapi.c | 28 
  src/mesa/main/shaderapi.h |  7 ++-
  3 files changed, 36 insertions(+), 3 deletions(-)

diff --git a/src/mapi/glapi/gen/gl_API.xml b/src/mapi/glapi/gen/gl_API.xml
index d878a04ea09..94589464c5c 100644
--- a/src/mapi/glapi/gen/gl_API.xml
+++ b/src/mapi/glapi/gen/gl_API.xml
@@ -5295,7 +5295,7 @@
  
  
  
-

+
  
  
  
@@ -7709,7 +7709,7 @@
  
  
  
-

+
  
  
  
diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
index 457a18e4175..7318833e9b8 100644
--- a/src/mesa/main/shaderapi.c
+++ b/src/mesa/main/shaderapi.c
@@ -311,6 +311,19 @@ attach_shader_err(struct gl_context *ctx, GLuint program, 
GLuint shader,
  }
  
  
+static void

+attach_shader(struct gl_context *ctx, GLuint program, GLuint shader)
+{


I think I would rather this be:

   attach_shader_no_error() and

   add_shader() -> attach_shader()

What do you think? It might even make sense to make:

   attach_shader_no_error() -> lookup_and_attach_shader_no_error()
   attach_shader_err() -> lookup_and_attach_shader_err()

If you agree 1-3:

Reviewed-by: Timothy Arceri 


+   struct gl_shader_program *shProg;
+   struct gl_shader *sh;
+
+   shProg = _mesa_lookup_shader_program(ctx, program);
+   sh = _mesa_lookup_shader(ctx, shader);
+
+   add_shader(ctx, shProg, sh);
+}
+
+
  static GLuint
  create_shader(struct gl_context *ctx, GLenum type)
  {
@@ -1334,6 +1347,13 @@ validate_program(struct gl_context *ctx, GLuint program)
  }
  
  
+void GLAPIENTRY

+_mesa_AttachObjectARB_no_error(GLhandleARB program, GLhandleARB shader)
+{
+   GET_CURRENT_CONTEXT(ctx);
+   attach_shader(ctx, program, shader);
+}
+
  
  void GLAPIENTRY

  _mesa_AttachObjectARB(GLhandleARB program, GLhandleARB shader)
@@ -1344,6 +1364,14 @@ _mesa_AttachObjectARB(GLhandleARB program, GLhandleARB 
shader)
  
  
  void GLAPIENTRY

+_mesa_AttachShader_no_error(GLuint program, GLuint shader)
+{
+   GET_CURRENT_CONTEXT(ctx);
+   attach_shader(ctx, program, shader);
+}
+
+
+void GLAPIENTRY
  _mesa_AttachShader(GLuint program, GLuint shader)
  {
 GET_CURRENT_CONTEXT(ctx);
diff --git a/src/mesa/main/shaderapi.h b/src/mesa/main/shaderapi.h
index 0a28185177d..3f6c0ff0cba 100644
--- a/src/mesa/main/shaderapi.h
+++ b/src/mesa/main/shaderapi.h
@@ -73,6 +73,10 @@ _mesa_longest_attribute_name_length(struct gl_shader_program 
*shProg);
  extern void
  _mesa_shader_write_subroutine_indices(struct gl_context *ctx,
gl_shader_stage stage);
+
+void GLAPIENTRY
+_mesa_AttachObjectARB_no_error(GLhandleARB, GLhandleARB);
+
  extern void GLAPIENTRY
  _mesa_AttachObjectARB(GLhandleARB, GLhandleARB);
  
@@ -154,7 +158,8 @@ _mesa_GetActiveAttrib(GLuint, GLuint, GLsizei, GLsizei *, GLint *,

  extern GLint GLAPIENTRY
  _mesa_GetAttribLocation(GLuint, const GLchar *);
  
-

+void GLAPIENTRY
+_mesa_AttachShader_no_error(GLuint program, GLuint shader);
  
  extern void GLAPIENTRY

  _mesa_AttachShader(GLuint program, GLuint shader);


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

[Mesa-dev] [PATCH] intel/compiler: Don't use opt_sampler_eot() optimization on gen10+

[Anuj Phogat]

This optimization has been removed on gen10+.

Signed-off-by: Anuj Phogat 
---
 src/intel/compiler/brw_fs.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
index 43b6e34..a2a99b7 100644
--- a/src/intel/compiler/brw_fs.cpp
+++ b/src/intel/compiler/brw_fs.cpp
@@ -2444,7 +2444,7 @@ fs_visitor::opt_sampler_eot()
if (stage != MESA_SHADER_FRAGMENT)
   return false;
 
-   if (devinfo->gen < 9 && !devinfo->is_cherryview)
+   if (devinfo->gen != 9 && !devinfo->is_cherryview)
   return false;
 
/* FINISHME: It should be possible to implement this optimization when there
-- 
2.9.4

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

[Mesa-dev] [PATCH] swr: conditionally validate vertex buffer state

[Bruce Cherniak]

Vertex buffer state doesn't need to be validated on every call,
only on dirty _NEW_VERTEX or indexed draws.

Unconditional validation was introduced as part of patch 330d0607ed6,
"remove pipe_index_buffer and set_index_buffer", with the expectation
we'd optimize later.
---
 src/gallium/drivers/swr/swr_state.cpp | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/swr/swr_state.cpp 
b/src/gallium/drivers/swr/swr_state.cpp
index f65e642753..6dc06ed156 100644
--- a/src/gallium/drivers/swr/swr_state.cpp
+++ b/src/gallium/drivers/swr/swr_state.cpp
@@ -1212,12 +1212,13 @@ swr_update_derived(struct pipe_context *pipe,
   SwrSetViewports(ctx->swrContext, 1, vp, vpm);
}
 
-   /* Set vertex & index buffers */
-   /* (using draw info if called by swr_draw_vbo) */
-   /* TODO: This is always true, because the index buffer comes from
+   /* Set vertex & index buffers
+* (using draw info if called by swr_draw_vbo)
+* If indexed draw, revalidate since index buffer comes from
 * pipe_draw_info.
 */
-   if (1 || ctx->dirty & SWR_NEW_VERTEX) {
+   if (ctx->dirty & SWR_NEW_VERTEX ||
+  (p_draw_info && p_draw_info->index_size)) {
   uint32_t scratch_total;
   uint8_t *scratch = NULL;
 
-- 
2.11.0

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

Re: [Mesa-dev] [PATCH 1/3] mesa: GL_TEXTURE_BORDER_COLOR exists in OpenGL 1.0, so don't depend on GL_ARB_texture_border_clamp

[Ilia Mirkin]

On Tue, Jun 27, 2017 at 3:18 PM, Ian Romanick  wrote:
> On 06/27/2017 11:23 AM, Ilia Mirkin wrote:
>> On Tue, Jun 27, 2017 at 1:09 PM, Ian Romanick  wrote:
>>> From: Ian Romanick 
>>>
>>> On NV20 (and probably also on earlier NV GPUs that lack
>>> GL_ARB_texture_border_clamp) fixes the following piglit tests:
>>>
>>> gl-1.0-beginend-coverage gltexparameter[if]{v,}
>>> push-pop-texture-state
>>> texwrap 1d
>>> texwrap 1d proj
>>> texwrap 2d proj
>>> texwrap formats
>>>
>>> All told, 49 more tests pass on NV20 (10de:0201).
>>>
>>> No changes on Intel CI run or RV250 (1002:4c66).
>>>
>>> Signed-off-by: Ian Romanick 
>>
>> Contrary to my recollections, you appear to be quite right -
>> TEXTURE_BORDER_COLOR has always been there in [desktop] GL. I always
>> associated it with ARB_texture_border_clamp.
>
> Yeah... it's needed for GL_CLAMP.  All the piglit tests that use
> GL_CLAMP were failing on NV20 because they got a GL error. :)
>
>> Reviewed-by: Ilia Mirkin 
>
> For the series or just this patch?

Just for this patch. Thinking about 2/3, and it's probably unfair for
me to review 3/3 :)

>
>>> ---
>>>  src/mesa/main/texparam.c | 10 +-
>>>  1 file changed, 9 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/src/mesa/main/texparam.c b/src/mesa/main/texparam.c
>>> index 3c110de..857faf6 100644
>>> --- a/src/mesa/main/texparam.c
>>> +++ b/src/mesa/main/texparam.c
>>> @@ -736,8 +736,16 @@ set_tex_parameterf(struct gl_context *ctx,
>>>break;
>>>
>>> case GL_TEXTURE_BORDER_COLOR:
>>> +  /* Border color exists in desktop OpenGL since 1.0 for GL_CLAMP.  In
>>> +   * OpenGL ES 2.0+, it only exists in when 
>>> GL_OES_texture_border_clamp is
>>> +   * enabled.  It is never available in OpenGL ES 1.x.
>>> +   *
>>> +   * FIXME: Every driver that supports GLES2 has this extension.  Elide
>>> +   * the check?
>>> +   */
>>>if (ctx->API == API_OPENGLES ||
>>> -  !ctx->Extensions.ARB_texture_border_clamp)
>>> +  (ctx->API == API_OPENGLES2 &&
>>> +   !ctx->Extensions.ARB_texture_border_clamp))
>>>   goto invalid_pname;
>>>
>>>if (!_mesa_target_allows_setting_sampler_parameters(texObj->Target))
>>> --
>>> 2.9.4
>>>
>>> ___
>>> mesa-dev mailing list
>>> mesa-dev@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 18/30] intel/isl: Add basic modifier introspection

[Chad Versace]

On Fri 16 Jun 2017, Jason Ekstrand wrote:
> ---
>  src/intel/Makefile.am  |  1 +
>  src/intel/Makefile.sources |  1 +
>  src/intel/isl/isl.h| 22 +
>  src/intel/isl/isl_drm.c| 59 
> ++
>  4 files changed, 83 insertions(+)
>  create mode 100644 src/intel/isl/isl_drm.c

> +const struct isl_drm_modifier_info * ATTRIBUTE_CONST
> +isl_drm_modifier_get_info(uint64_t modofier);

Typo in 'modoifier'.

Other than that, this patch is
Reviewed-by: Chad Versace 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 17/30] i965: Add an isl_device to intel_screen

[Chad Versace]

On Fri 16 Jun 2017, Jason Ekstrand wrote:
> ---
>  src/mesa/drivers/dri/i965/brw_context.c  | 2 +-
>  src/mesa/drivers/dri/i965/intel_screen.c | 3 +++
>  src/mesa/drivers/dri/i965/intel_screen.h | 4 
>  3 files changed, 8 insertions(+), 1 deletion(-)

Patch 17 is
Reviewed-by: Chad Versace 

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

Re: [Mesa-dev] [PATCH 13/30] i965/miptree: Add an explicit format parameter to create_for_dri_image

[Chad Versace]

On Fri 16 Jun 2017, Jason Ekstrand wrote:
> ---
>  src/mesa/drivers/dri/i965/intel_fbo.c | 3 ++-
>  src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 7 ---
>  src/mesa/drivers/dri/i965/intel_mipmap_tree.h | 3 ++-
>  src/mesa/drivers/dri/i965/intel_tex_image.c   | 3 ++-
>  4 files changed, 10 insertions(+), 6 deletions(-)

I dislike this patch. A lot.

The __DRIimage already has a 'format' member. Why is it necessary to
override that format? More importantly, *when* is it necessary?

In patch "i965: Use create_for_dri_image in intel_update_image_buffer",
I see that you pass intel_rb_format(rb) down as the 'format' parameter.
Is that the only place the override is needed? In that function, why do
the image's format and the renderbuffer's format differ? When do they
differ? When they do differ, is it illegal then to update the
image's format to match? If we don't update the image's format in
intel_update_image_buffer(), then does the invalidity of
__DRIimage::format cause potential issues elsewhere?

[...]

> diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
> b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> index 08c13fc..7b4d431 100644
> --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> @@ -900,12 +900,13 @@ miptree_create_for_planar_image(struct brw_context *brw,
>  
>  struct intel_mipmap_tree *
>  intel_miptree_create_for_dri_image(struct brw_context *brw,
> -   __DRIimage *image, GLenum target)
> +   __DRIimage *image, GLenum target,
> +   mesa_format format)
>  {
> if (image->planar_format && image->planar_format->nplanes > 0)
>return miptree_create_for_planar_image(brw, image, target);
>  
> -   if (!brw->ctx.TextureFormatSupported[image->format])
> +   if (!brw->ctx.TextureFormatSupported[format])
>return NULL;

The 'format' parameter is ignored if the image has a planar format. That
makes me suspicious. At a minimum, this needs

  assert(!format == !image->planar_format)

or an explanation of why the assertion is invalid.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/3] i965/dri: Support R8G8B8A8 and R8G8B8X8 configs

[Kenneth Graunke]

On Tuesday, June 27, 2017 11:00:48 AM PDT Chad Versace wrote:
> The Android framework requires support for EGLConfigs with
> HAL_PIXEL_FORMAT_RGBX_ and HAL_PIXEL_FORMAT_RGBA_.
> 
> Even though all RGBX formats are disabled on gen9 by
> brw_surface_formats.c, the new configs work correctly on Broxton thanks
> to _mesa_format_fallback_rgbx_to_rgba().
> 
> On GLX, this creates no new configs, and therefore breaks no existing
> apps. See in-patch comments for explanation. I tested with glxinfo and
> glxgears on Skylake.
> 
> On Wayland, this also creates no new configs, and therfore breaks no
> existing apps. (I tested with mesa-demos' eglinfo and es2gears_wayland
> on Skylake). The reason differs from GLX, though. In
> dri2_wl_add_configs_for_visual(), the format table contains only
> B8G8R8X8, B8G8R8A8, and B5G6B5; and dri2_add_config() correctly matches
> EGLConfig to format by inspecting channel masks.
> 
> On Android, in Chrome OS, I tested this on a Broxton device. I confirmed
> that the Google Play Store's EGLSurface used HAL_PIXEL_FORMAT_RGBA_,
> and that an Asteroid game's EGLSurface used HAL_PIXEL_FORMAT_RGBX_.
> Both apps worked well. (Disclaimer: I didn't test this patch on Android
> with Mesa master. I backported this patch series to an older Android
> branch).
> ---
>  src/mesa/drivers/dri/i965/intel_fbo.c| 23 +--
>  src/mesa/drivers/dri/i965/intel_screen.c | 23 ++-
>  2 files changed, 43 insertions(+), 3 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/intel_fbo.c 
> b/src/mesa/drivers/dri/i965/intel_fbo.c
> index caf182ca8b7..b59fc1fc7d0 100644
> --- a/src/mesa/drivers/dri/i965/intel_fbo.c
> +++ b/src/mesa/drivers/dri/i965/intel_fbo.c
> @@ -450,10 +450,29 @@ intel_create_winsys_renderbuffer(struct intel_screen 
> *screen,
>  
> _mesa_init_renderbuffer(rb, 0);
> rb->ClassID = INTEL_RB_CLASS;
> +   rb->NumSamples = num_samples;
> +
> +   /* The base format and internal format must be derived from the 
> user-visible
> +* format (that is, the gl_config's format), even if we internally use
> +* choose a different format for the renderbuffer. Otherwise, rendering 
> may
> +* use incorrect channel write masks.
> +*/
> rb->_BaseFormat = _mesa_get_format_base_format(format);
> -   rb->Format = format;
> rb->InternalFormat = rb->_BaseFormat;
> -   rb->NumSamples = num_samples;
> +
> +   rb->Format = format;
> +   if (!screen->mesa_format_supports_render[rb->Format]) {
> +  /* The glRenderbufferStorage paths in core Mesa detect if the driver
> +   * does not support the user-requested format, and then searches for
> +   * a falback format. The DRI code bypasses core Mesa, though. So we do
> +   * the fallbacks here.
> +   *
> +   * We must support MESA_FORMAT_R8G8B8X8 on Android because the Android
> +   * framework requires HAL_PIXEL_FORMAT_RGBX winsys surfaces.
> +   */
> +  rb->Format = _mesa_format_fallback_rgbx_to_rgba(rb->Format);
> +  assert(screen->mesa_format_supports_render[rb->Format]);
> +   }
>  
> /* intel-specific methods */
> rb->Delete = intel_delete_renderbuffer;
> diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
> b/src/mesa/drivers/dri/i965/intel_screen.c
> index 8621af26378..0e03c56cf88 100644
> --- a/src/mesa/drivers/dri/i965/intel_screen.c
> +++ b/src/mesa/drivers/dri/i965/intel_screen.c
> @@ -1717,7 +1717,28 @@ intel_screen_make_configs(__DRIscreen *dri_screen)
> static const mesa_format formats[] = {
>MESA_FORMAT_B5G6R5_UNORM,
>MESA_FORMAT_B8G8R8A8_UNORM,
> -  MESA_FORMAT_B8G8R8X8_UNORM
> +  MESA_FORMAT_B8G8R8X8_UNORM,
> +
> +  /* The 32-bit RGBA format must not precede the 32-bit BGRA format.
> +   * Likewise for RGBX and BGRX.  Otherwise, the GLX client and the GLX
> +   * server may disagree on which format the GLXFBConfig represents,
> +   * resulting in swapped color channels.
> +   *
> +   * The problem, as of 2017-05-30:
> +   * When matching a GLXFBConfig to a __DRIconfig, GLX ignores the 
> channel
> +   * order and chooses the first __DRIconfig with the expected channel
> +   * sizes. Specifically, GLX compares the GLXFBConfig's and 
> __DRIconfig's
> +   * __DRI_ATTRIB_{CHANNEL}_SIZE but ignores __DRI_ATTRIB_{CHANNEL}_MASK.

The series is:
Reviewed-by: Kenneth Graunke 

But, I still think this should be fixed.  This seems fragile - we're
essentially relying on a bug in the GLX code.

I suppose fixing it would cause GLX to begin exposing new RGBA visuals
(in addition to BGRA).  I don't think we want to do that - I don't see much
point outside of Android.  It's mostly harmless, except that changing the
visuals ends up being absurdly painful for driver developers, since the X
server and clients need to agree on lists.  That means you can't move across
the change point without updating the Mesa your X server uses and restarting

Re: [Mesa-dev] [PATCH v2] mesa: Add _mesa_format_fallback_rgba_to_rgbx()

[Chad Versace]

On Tue 20 Jun 2017, Jason Ekstrand wrote:
> From: Chad Versace 
> 
> The new function takes a mesa_format and, if the format is an alpha
> format with a non-alpha variant, returns the non-alpha format.
> Otherwise, it returns the original format.
> 
> Example:
>   input -> output
> 
>   // Fallback exists
>   MESA_FORMAT_R8G8B8X8_UNORM -> MESA_FORMAT_R8G8B8A8_UNORM
>   MESA_FORMAT_RGBX_UNORM16 -> MESA_FORMAT_RGBA_UNORM16
> 
>   // No fallback
>   MESA_FORMAT_R8G8B8A8_UNORM -> MESA_FORMAT_R8G8B8A8_UNORM
>   MESA_FORMAT_Z_FLOAT32 -> MESA_FORMAT_Z_FLOAT32
> 
> i965 will use this for EGLImages and DRIimages.
> 
> v2 (Jason Ekstrand):
>  - Use mako
>  - Rework to be easier to read
>  - Write directly to the output file
> ---

Today, I sent this in v2 of my i965-r8g8b8x8 patch series.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 12/30] i965/miptree: Allocate mt earlier in update winsys

[Chad Versace]

On Mon 26 Jun 2017, Pohjolainen, Topi wrote:
> On Fri, Jun 16, 2017 at 03:41:34PM -0700, Jason Ekstrand wrote:
> > From: Ben Widawsky 
> > 
> > Allows us to continue utilizing common miptree creation using __DRIimage
> > without creating a new DRIimage (for the intel_process_dri2_buffer()
> > case).
> 
> Just looking this patch locally I don't really understand this commit
> message. I'll keep on reading if the answer is later in the series..

I second Topi. I don't understand the commit message.

The code itself looks good, though.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] mesa: GL_TEXTURE_BORDER_COLOR exists in OpenGL 1.0, so don't depend on GL_ARB_texture_border_clamp

[Ian Romanick]

On 06/27/2017 11:23 AM, Ilia Mirkin wrote:
> On Tue, Jun 27, 2017 at 1:09 PM, Ian Romanick  wrote:
>> From: Ian Romanick 
>>
>> On NV20 (and probably also on earlier NV GPUs that lack
>> GL_ARB_texture_border_clamp) fixes the following piglit tests:
>>
>> gl-1.0-beginend-coverage gltexparameter[if]{v,}
>> push-pop-texture-state
>> texwrap 1d
>> texwrap 1d proj
>> texwrap 2d proj
>> texwrap formats
>>
>> All told, 49 more tests pass on NV20 (10de:0201).
>>
>> No changes on Intel CI run or RV250 (1002:4c66).
>>
>> Signed-off-by: Ian Romanick 
> 
> Contrary to my recollections, you appear to be quite right -
> TEXTURE_BORDER_COLOR has always been there in [desktop] GL. I always
> associated it with ARB_texture_border_clamp.

Yeah... it's needed for GL_CLAMP.  All the piglit tests that use
GL_CLAMP were failing on NV20 because they got a GL error. :)

> Reviewed-by: Ilia Mirkin 

For the series or just this patch?

>> ---
>>  src/mesa/main/texparam.c | 10 +-
>>  1 file changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/mesa/main/texparam.c b/src/mesa/main/texparam.c
>> index 3c110de..857faf6 100644
>> --- a/src/mesa/main/texparam.c
>> +++ b/src/mesa/main/texparam.c
>> @@ -736,8 +736,16 @@ set_tex_parameterf(struct gl_context *ctx,
>>break;
>>
>> case GL_TEXTURE_BORDER_COLOR:
>> +  /* Border color exists in desktop OpenGL since 1.0 for GL_CLAMP.  In
>> +   * OpenGL ES 2.0+, it only exists in when GL_OES_texture_border_clamp 
>> is
>> +   * enabled.  It is never available in OpenGL ES 1.x.
>> +   *
>> +   * FIXME: Every driver that supports GLES2 has this extension.  Elide
>> +   * the check?
>> +   */
>>if (ctx->API == API_OPENGLES ||
>> -  !ctx->Extensions.ARB_texture_border_clamp)
>> +  (ctx->API == API_OPENGLES2 &&
>> +   !ctx->Extensions.ARB_texture_border_clamp))
>>   goto invalid_pname;
>>
>>if (!_mesa_target_allows_setting_sampler_parameters(texObj->Target))
>> --
>> 2.9.4
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 

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

Re: [Mesa-dev] [RFT PATCH 2/2] nv20: enable ARB_texture_border_clamp support

[Ian Romanick]

On 06/27/2017 11:16 AM, Roland Scheidegger wrote:
> Am 27.06.2017 um 20:10 schrieb Ian Romanick:
>> On 06/27/2017 11:00 AM, Ilia Mirkin wrote:
>>> On Tue, Jun 27, 2017 at 1:11 PM, Ian Romanick  wrote:
 On 06/27/2017 02:59 AM, Timothy Arceri wrote:
> Just curious. Can this extension be added to NV04 and NV10? As those are
> the only drivers that don't currently support it.
>
> I have cards I could test those with, but don't have an NV20.

 I just sent out an updated series that I tested on NV20.  Thanks for
 reminding me. :)

 I *think* NV10 can do this, but the implementation would be... painful.
 NV10 (and on) supports texture borders... that extra one pixel of pixels
 on each side that's outside the usual [0,1]x[0,1] sampling range.  I
 believe this extension could be supported by creating every texture with
 a border and filling the border with the GL border color.
>>>
>>> That's right, they support the border inside the texture. I think that
>>> was killed in mesa though, and I have no interest in reinstating it :)
>>
>> We wouldn't have to.  It would just be internal to the way the driver
>> stores the texture on the hardware... kind of like how core Mesa doesn't
>> know anything about tiling formats, etc.  Either way, I'd want to be
>> 100% sure it would work before messing with it.  Someone with reverse
>> engineering skills would have to see if the blob does it that way first.
> 
> I don't think that would be practical either way, unless the border
> pixels are stored separately somewhere - surely you don't want to
> relayout the texture if you switch wrap mode?

I think you'd just always store it with the border, and you'd have to
update those texels each time border color changes... which would also
be lame. :(

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

Re: [Mesa-dev] [PATCH 1/3] mesa: GL_TEXTURE_BORDER_COLOR exists in OpenGL 1.0, so don't depend on GL_ARB_texture_border_clamp

[Ilia Mirkin]

On Tue, Jun 27, 2017 at 1:09 PM, Ian Romanick  wrote:
> From: Ian Romanick 
>
> On NV20 (and probably also on earlier NV GPUs that lack
> GL_ARB_texture_border_clamp) fixes the following piglit tests:
>
> gl-1.0-beginend-coverage gltexparameter[if]{v,}
> push-pop-texture-state
> texwrap 1d
> texwrap 1d proj
> texwrap 2d proj
> texwrap formats
>
> All told, 49 more tests pass on NV20 (10de:0201).
>
> No changes on Intel CI run or RV250 (1002:4c66).
>
> Signed-off-by: Ian Romanick 

Contrary to my recollections, you appear to be quite right -
TEXTURE_BORDER_COLOR has always been there in [desktop] GL. I always
associated it with ARB_texture_border_clamp.

Reviewed-by: Ilia Mirkin 

> ---
>  src/mesa/main/texparam.c | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/main/texparam.c b/src/mesa/main/texparam.c
> index 3c110de..857faf6 100644
> --- a/src/mesa/main/texparam.c
> +++ b/src/mesa/main/texparam.c
> @@ -736,8 +736,16 @@ set_tex_parameterf(struct gl_context *ctx,
>break;
>
> case GL_TEXTURE_BORDER_COLOR:
> +  /* Border color exists in desktop OpenGL since 1.0 for GL_CLAMP.  In
> +   * OpenGL ES 2.0+, it only exists in when GL_OES_texture_border_clamp 
> is
> +   * enabled.  It is never available in OpenGL ES 1.x.
> +   *
> +   * FIXME: Every driver that supports GLES2 has this extension.  Elide
> +   * the check?
> +   */
>if (ctx->API == API_OPENGLES ||
> -  !ctx->Extensions.ARB_texture_border_clamp)
> +  (ctx->API == API_OPENGLES2 &&
> +   !ctx->Extensions.ARB_texture_border_clamp))
>   goto invalid_pname;
>
>if (!_mesa_target_allows_setting_sampler_parameters(texObj->Target))
> --
> 2.9.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 00/30] i965: Add support for I915_FORMAT_MOD_Y_TILED_CCS

[Pohjolainen, Topi]

On Wed, Jun 21, 2017 at 05:51:00PM -0700, Jason Ekstrand wrote:
> On Fri, Jun 16, 2017 at 3:41 PM, Jason Ekstrand 
> wrote:
> 
> > This series is a rework of Ben's series to enable the CCS format modifier.
> > It started as an attempt to rebase his original patches on top of my
> > resolve reworks inside the miptree code.  However, as I started to dive
> > deeper, I found a number of subtle issues:
> >
> >  1) Thanks to the terrible set of INTEL_AUX_DISABLE_* flags that we use to
> > choose what aux buffers to use, we were set up to never use CCS_E for
> > any external buffers.  Even when Y-tiled on gen9, the most they would
> > ever get was CCS_D.
> >
> >  2) Whether to do a full or partial resolve or not was based on is_scanout
> > and not on the actual modifier.  If we use I915_FORMAT_MOD_Y_TILED (not
> > the CCS modifier) and choose to use CCS_E with it, it would only get
> > partial resolves and not full resolves.  Of course, this wasn't
> > actually a problem thanks to problem 1 above.
> >
> >  3) If a user ever imported an image with I915_FORMAT_MOD_Y_TILED_CCS
> > through EGL or GBM and did glClear on it, they would get a fast clear
> > with no way to force a resolve before handing it off to the other
> > process.  Since the other process doesn't know the clear color, this
> > means that any blocks in the clear state in the surface will get
> > whatever random clear color process B thinks it has.
> >
> >  4) There were three different places where we computed the pitch of the
> > CCS and they all did so differently.  When we go to create the image,
> > we would allocate the CCS with the same pitch as the main surface.  We
> > would then calculate the CCS pitch with ISL when we created
> > mt->mcs_buf.
> > Finally, we had a different mechanism to compute the pitch when we pass
> > it back to the user.  Fortunately, the first only caused us to over-
> > allocate and I think the last two were equivalent (at least for the
> > simple case) so nothing exploded.
> >
> >  5) Thanks again to our confusing aux enable/disable, we haven't been doing
> > multisample fast-clears since cec30a666930ddb8476a9452a89364a24979ff62
> > around a year ago.
> >
> > This series takes a bit more round-about approach to enabling the CCS
> > modifier that should fix these issues:
> >
> >  * Patches 1-5 do a bit of refactoring and then rework the way we choose
> >the type of aux compression to use.  They move us away from the crazy
> >enable/disable system to a simple choice system.  This fixes (1) and (5)
> >above.
> >
> >  * Patches 6-15 refactor things so that we have only one path for going
> >from a __DRIimage to an intel_mipmap_tree.  This was rather painful
> >because we have to be careful to take into account the differences
> >between window system images regular images.
> >
> >  * Patches 16-22 rework image creation and import to use ISL to do their
> >surface layout calculations.  Previously, all of the surface layout
> >calculations were simply hand-rolled here.  In the particular case of
> >images, the hand-rolling was fairly safe because they were only ever
> >simple 2D non-array images.  However, with the addition of CCS, things
> >were going to get a bit tricky.
> >
> >  * Patches 23-30 add support for I915_FORMAT_MOD_Y_TILED.

Suggestion to revise the commit message in patch 12.

Typo in the subject in patch 19.

In 25 there is a question about incoming aux data - it looks that were are
taking it as containing meaningful data in some cases.

Question in patch 27.

Typo in patch 28.

Given we have those sorted, patches 12-29 are:

Reviewed-by: Topi Pohjolainen 

> >
> > I've tested this series on our Jenkins system which runs piglit as well as
> > the OpenGL and OpenGL ES test suites.  Both piglit and the OpenGL ES suite
> > have some number of EGL tests which I hope have tested some of this.  I've
> > also tested with kmscube and have verified that I get basically the same
> > bandwidth numbers as Ben got on his original series, so I think CCS is
> > working properly.
> >
> > This series can be found here:
> >
> > https://cgit.freedesktop.org/~jekstrand/mesa/log/?h=review/i965-ccs-mod
> >
> 
> I've rebased on top of Topi's ISL reworks and force-pushed that branch.
> You can see the result of the rebase there.
> 
> 
> > Cc: Ben Widawsky 
> > Cc: Daniel Stone 
> > Cc: Varad Gautam 
> > Cc: Chad Versace 
> > Cc: Topi Pohjolainen 
> >
> > Ben Widawsky (6):
> >   i965/miptree: Add a return for updating of winsys
> >   i965/miptree: Allocate mt earlier in update winsys
> >   i965: Support images with aux buffers
> >   i965/miptree: Allocate mcs_buf for an image's CCS
> >   i965: Pretend that CCS modified images are two 

Re: [Mesa-dev] [PATCH 19/30] intel/isl: Add a helper to convert tilings fro ISL to i915

[Pohjolainen, Topi]

In the subject: s/fro/from/

On Fri, Jun 16, 2017 at 03:41:41PM -0700, Jason Ekstrand wrote:
> ---
>  src/intel/isl/isl.h |  3 +++
>  src/intel/isl/isl_drm.c | 23 +++
>  2 files changed, 26 insertions(+)
> 
> diff --git a/src/intel/isl/isl.h b/src/intel/isl/isl.h
> index eb05b54..dc3eada 100644
> --- a/src/intel/isl/isl.h
> +++ b/src/intel/isl/isl.h
> @@ -1513,6 +1513,9 @@ isl_tiling_is_std_y(enum isl_tiling tiling)
> return (1u << tiling) & ISL_TILING_STD_Y_MASK;
>  }
>  
> +uint32_t
> +isl_tiling_to_i915_tiling(enum isl_tiling tiling);
> +
>  const struct isl_drm_modifier_info * ATTRIBUTE_CONST
>  isl_drm_modifier_get_info(uint64_t modofier);
>  
> diff --git a/src/intel/isl/isl_drm.c b/src/intel/isl/isl_drm.c
> index 8fccc40..1dc3da2 100644
> --- a/src/intel/isl/isl_drm.c
> +++ b/src/intel/isl/isl_drm.c
> @@ -25,10 +25,33 @@
>  #include 
>  
>  #include 
> +#include 
>  
>  #include "isl.h"
>  #include "common/gen_device_info.h"
>  
> +uint32_t
> +isl_tiling_to_i915_tiling(enum isl_tiling tiling)
> +{
> +   switch (tiling) {
> +   case ISL_TILING_LINEAR:
> +  return I915_TILING_NONE;
> +
> +   case ISL_TILING_X:
> +  return I915_TILING_X;
> +
> +   case ISL_TILING_Y0:
> +  return I915_TILING_Y;
> +
> +   case ISL_TILING_W:
> +   case ISL_TILING_Yf:
> +   case ISL_TILING_Ys:
> +   case ISL_TILING_HIZ:
> +   case ISL_TILING_CCS:
> +  return I915_TILING_NONE;
> +   }
> +}
> +
>  struct isl_drm_modifier_info modifier_info[] = {
> {
>.modifier = DRM_FORMAT_MOD_NONE,
> -- 
> 2.5.0.400.gff86faf
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFT PATCH 2/2] nv20: enable ARB_texture_border_clamp support

[Roland Scheidegger]

Am 27.06.2017 um 20:10 schrieb Ian Romanick:
> On 06/27/2017 11:00 AM, Ilia Mirkin wrote:
>> On Tue, Jun 27, 2017 at 1:11 PM, Ian Romanick  wrote:
>>> On 06/27/2017 02:59 AM, Timothy Arceri wrote:
 Just curious. Can this extension be added to NV04 and NV10? As those are
 the only drivers that don't currently support it.

 I have cards I could test those with, but don't have an NV20.
>>>
>>> I just sent out an updated series that I tested on NV20.  Thanks for
>>> reminding me. :)
>>>
>>> I *think* NV10 can do this, but the implementation would be... painful.
>>> NV10 (and on) supports texture borders... that extra one pixel of pixels
>>> on each side that's outside the usual [0,1]x[0,1] sampling range.  I
>>> believe this extension could be supported by creating every texture with
>>> a border and filling the border with the GL border color.
>>
>> That's right, they support the border inside the texture. I think that
>> was killed in mesa though, and I have no interest in reinstating it :)
> 
> We wouldn't have to.  It would just be internal to the way the driver
> stores the texture on the hardware... kind of like how core Mesa doesn't
> know anything about tiling formats, etc.  Either way, I'd want to be
> 100% sure it would work before messing with it.  Someone with reverse
> engineering skills would have to see if the blob does it that way first.
> 

I don't think that would be practical either way, unless the border
pixels are stored separately somewhere - surely you don't want to
relayout the texture if you switch wrap mode?

Roland

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

Re: [Mesa-dev] [RFT PATCH 2/2] nv20: enable ARB_texture_border_clamp support

[Ilia Mirkin]

On Tue, Jun 27, 2017 at 2:10 PM, Ian Romanick  wrote:
> On 06/27/2017 11:00 AM, Ilia Mirkin wrote:
>> On Tue, Jun 27, 2017 at 1:11 PM, Ian Romanick  wrote:
>>> On 06/27/2017 02:59 AM, Timothy Arceri wrote:
 Just curious. Can this extension be added to NV04 and NV10? As those are
 the only drivers that don't currently support it.

 I have cards I could test those with, but don't have an NV20.
>>>
>>> I just sent out an updated series that I tested on NV20.  Thanks for
>>> reminding me. :)
>>>
>>> I *think* NV10 can do this, but the implementation would be... painful.
>>> NV10 (and on) supports texture borders... that extra one pixel of pixels
>>> on each side that's outside the usual [0,1]x[0,1] sampling range.  I
>>> believe this extension could be supported by creating every texture with
>>> a border and filling the border with the GL border color.
>>
>> That's right, they support the border inside the texture. I think that
>> was killed in mesa though, and I have no interest in reinstating it :)
>
> We wouldn't have to.  It would just be internal to the way the driver
> stores the texture on the hardware... kind of like how core Mesa doesn't
> know anything about tiling formats, etc.  Either way, I'd want to be
> 100% sure it would work before messing with it.  Someone with reverse
> engineering skills would have to see if the blob does it that way first.

Ah right. I meant the border=1 support was gone from mesa in
glTexImage, I believe.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 12/12] i965: Assert that blorp always handles color blits

[Ian Romanick]

On 06/27/2017 10:53 AM, Kenneth Graunke wrote:
> On Monday, June 26, 2017 4:22:45 PM PDT Ian Romanick wrote:
>> From: Ian Romanick 
>>
>> ---
>>  src/mesa/drivers/dri/i965/brw_blorp.c | 2 ++
>>  src/mesa/drivers/dri/i965/intel_fbo.c | 3 +++
>>  2 files changed, 5 insertions(+)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c 
>> b/src/mesa/drivers/dri/i965/brw_blorp.c
>> index 92d1d2a..9c9b859 100644
>> --- a/src/mesa/drivers/dri/i965/brw_blorp.c
>> +++ b/src/mesa/drivers/dri/i965/brw_blorp.c
>> @@ -707,6 +707,8 @@ brw_blorp_framebuffer(struct brw_context *brw,
>>}
>> }
>>  
>> +   /* try_blorp_blit should always be successful for color blits. */
>> +   assert(!(mask & GL_COLOR_BUFFER_BIT));
>> return mask;
>>  }
>>  
>> diff --git a/src/mesa/drivers/dri/i965/intel_fbo.c 
>> b/src/mesa/drivers/dri/i965/intel_fbo.c
>> index caf182c..f0f87bb 100644
>> --- a/src/mesa/drivers/dri/i965/intel_fbo.c
>> +++ b/src/mesa/drivers/dri/i965/intel_fbo.c
>> @@ -932,6 +932,9 @@ intel_blit_framebuffer(struct gl_context *ctx,
>> if (mask == 0x0)
>>return;
>>  
>> +   /* brw_blorp_framebuffer should always be successful for color blits. */
>> +   assert(!(mask & GL_COLOR_BUFFER_BIT));
>> +
>> mask = _mesa_meta_BlitFramebuffer(ctx, readFb, drawFb,
>>   srcX0, srcY0, srcX1, srcY1,
>>   dstX0, dstY0, dstX1, dstY1,
>>
> 
> Is that true?  I suppose scaling and filtering isn't a problem, because
> that will apply to the source formats, which should all be texturable.
> Format conversion ought to work as long as the destination is renderable.
> 
> If all non-renderable formats result in an incomplete FBO - which I imagine
> they do - then this ought to work.
> 
> I know Jason had code to support RGB9E5 and other non-renderable formats,
> with shader fixups.

I looked through the blorp code, and I didn't see any way for it to not
return success for a color blit.  The assertion also didn't trigger on
the CI, but that may just mean we have a testing hole.



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

Re: [Mesa-dev] [RFT PATCH 2/2] nv20: enable ARB_texture_border_clamp support

[Ian Romanick]

On 06/27/2017 11:00 AM, Ilia Mirkin wrote:
> On Tue, Jun 27, 2017 at 1:11 PM, Ian Romanick  wrote:
>> On 06/27/2017 02:59 AM, Timothy Arceri wrote:
>>> Just curious. Can this extension be added to NV04 and NV10? As those are
>>> the only drivers that don't currently support it.
>>>
>>> I have cards I could test those with, but don't have an NV20.
>>
>> I just sent out an updated series that I tested on NV20.  Thanks for
>> reminding me. :)
>>
>> I *think* NV10 can do this, but the implementation would be... painful.
>> NV10 (and on) supports texture borders... that extra one pixel of pixels
>> on each side that's outside the usual [0,1]x[0,1] sampling range.  I
>> believe this extension could be supported by creating every texture with
>> a border and filling the border with the GL border color.
> 
> That's right, they support the border inside the texture. I think that
> was killed in mesa though, and I have no interest in reinstating it :)

We wouldn't have to.  It would just be internal to the way the driver
stores the texture on the hardware... kind of like how core Mesa doesn't
know anything about tiling formats, etc.  Either way, I'd want to be
100% sure it would work before messing with it.  Someone with reverse
engineering skills would have to see if the blob does it that way first.

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

[Mesa-dev] [PATCH 3/3] i965/dri: Support R8G8B8A8 and R8G8B8X8 configs

[Chad Versace]

The Android framework requires support for EGLConfigs with
HAL_PIXEL_FORMAT_RGBX_ and HAL_PIXEL_FORMAT_RGBA_.

Even though all RGBX formats are disabled on gen9 by
brw_surface_formats.c, the new configs work correctly on Broxton thanks
to _mesa_format_fallback_rgbx_to_rgba().

On GLX, this creates no new configs, and therefore breaks no existing
apps. See in-patch comments for explanation. I tested with glxinfo and
glxgears on Skylake.

On Wayland, this also creates no new configs, and therfore breaks no
existing apps. (I tested with mesa-demos' eglinfo and es2gears_wayland
on Skylake). The reason differs from GLX, though. In
dri2_wl_add_configs_for_visual(), the format table contains only
B8G8R8X8, B8G8R8A8, and B5G6B5; and dri2_add_config() correctly matches
EGLConfig to format by inspecting channel masks.

On Android, in Chrome OS, I tested this on a Broxton device. I confirmed
that the Google Play Store's EGLSurface used HAL_PIXEL_FORMAT_RGBA_,
and that an Asteroid game's EGLSurface used HAL_PIXEL_FORMAT_RGBX_.
Both apps worked well. (Disclaimer: I didn't test this patch on Android
with Mesa master. I backported this patch series to an older Android
branch).
---
 src/mesa/drivers/dri/i965/intel_fbo.c| 23 +--
 src/mesa/drivers/dri/i965/intel_screen.c | 23 ++-
 2 files changed, 43 insertions(+), 3 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_fbo.c 
b/src/mesa/drivers/dri/i965/intel_fbo.c
index caf182ca8b7..b59fc1fc7d0 100644
--- a/src/mesa/drivers/dri/i965/intel_fbo.c
+++ b/src/mesa/drivers/dri/i965/intel_fbo.c
@@ -450,10 +450,29 @@ intel_create_winsys_renderbuffer(struct intel_screen 
*screen,
 
_mesa_init_renderbuffer(rb, 0);
rb->ClassID = INTEL_RB_CLASS;
+   rb->NumSamples = num_samples;
+
+   /* The base format and internal format must be derived from the user-visible
+* format (that is, the gl_config's format), even if we internally use
+* choose a different format for the renderbuffer. Otherwise, rendering may
+* use incorrect channel write masks.
+*/
rb->_BaseFormat = _mesa_get_format_base_format(format);
-   rb->Format = format;
rb->InternalFormat = rb->_BaseFormat;
-   rb->NumSamples = num_samples;
+
+   rb->Format = format;
+   if (!screen->mesa_format_supports_render[rb->Format]) {
+  /* The glRenderbufferStorage paths in core Mesa detect if the driver
+   * does not support the user-requested format, and then searches for
+   * a falback format. The DRI code bypasses core Mesa, though. So we do
+   * the fallbacks here.
+   *
+   * We must support MESA_FORMAT_R8G8B8X8 on Android because the Android
+   * framework requires HAL_PIXEL_FORMAT_RGBX winsys surfaces.
+   */
+  rb->Format = _mesa_format_fallback_rgbx_to_rgba(rb->Format);
+  assert(screen->mesa_format_supports_render[rb->Format]);
+   }
 
/* intel-specific methods */
rb->Delete = intel_delete_renderbuffer;
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index 8621af26378..0e03c56cf88 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -1717,7 +1717,28 @@ intel_screen_make_configs(__DRIscreen *dri_screen)
static const mesa_format formats[] = {
   MESA_FORMAT_B5G6R5_UNORM,
   MESA_FORMAT_B8G8R8A8_UNORM,
-  MESA_FORMAT_B8G8R8X8_UNORM
+  MESA_FORMAT_B8G8R8X8_UNORM,
+
+  /* The 32-bit RGBA format must not precede the 32-bit BGRA format.
+   * Likewise for RGBX and BGRX.  Otherwise, the GLX client and the GLX
+   * server may disagree on which format the GLXFBConfig represents,
+   * resulting in swapped color channels.
+   *
+   * The problem, as of 2017-05-30:
+   * When matching a GLXFBConfig to a __DRIconfig, GLX ignores the channel
+   * order and chooses the first __DRIconfig with the expected channel
+   * sizes. Specifically, GLX compares the GLXFBConfig's and __DRIconfig's
+   * __DRI_ATTRIB_{CHANNEL}_SIZE but ignores __DRI_ATTRIB_{CHANNEL}_MASK.
+   *
+   * EGL does not suffer from this problem. It correctly compares the
+   * channel masks when matching EGLConfig to __DRIconfig.
+   */
+
+  /* Required by Android, for HAL_PIXEL_FORMAT_RGBA_. */
+  MESA_FORMAT_R8G8B8A8_UNORM,
+
+  /* Required by Android, for HAL_PIXEL_FORMAT_RGBX_. */
+  MESA_FORMAT_R8G8B8X8_UNORM,
};
 
/* GLX_SWAP_COPY_OML is not supported due to page flipping. */
-- 
2.13.0

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

[Mesa-dev] [PATCH v2 03/13] swr/rast: gen_backends.py removal of commented debug prints

[Tim Rowley]

---
 src/gallium/drivers/swr/rasterizer/codegen/gen_backends.py | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/src/gallium/drivers/swr/rasterizer/codegen/gen_backends.py 
b/src/gallium/drivers/swr/rasterizer/codegen/gen_backends.py
index 09f40fa..f65f764 100644
--- a/src/gallium/drivers/swr/rasterizer/codegen/gen_backends.py
+++ b/src/gallium/drivers/swr/rasterizer/codegen/gen_backends.py
@@ -87,7 +87,6 @@ def main(args=sys.argv[1:]):
 
 for fileNum in range(numFiles):
 filename = baseCppName % str(fileNum)
-#print('Generating', filename)
 MakoTemplateWriter.to_file(
 templateCpp,
 baseCppName % str(fileNum),
@@ -99,7 +98,7 @@ def main(args=sys.argv[1:]):
 if args.cmake:
 templateCmake = os.path.join(thisDir, 'templates', 'gen_backend.cmake')
 cmakeFile = os.path.join(args.outdir, backend.cmakeFileName)
-#print('Generating', cmakeFile)
+
 MakoTemplateWriter.to_file(
 templateCmake,
 cmakeFile,
@@ -108,8 +107,6 @@ def main(args=sys.argv[1:]):
 numFiles=numFiles,
 baseCppName='${RASTY_GEN_SRC_DIR}/backends/' + 
os.path.basename(baseCppName))
 
-#print("Generated %d template instantiations in %d files" % 
(len(output_list), numFiles))
-
 return 0
 
 if __name__ == '__main__':
-- 
2.7.4

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

[Mesa-dev] [PATCH v2 02/13] swr/rast: gen_backends.py quote cleanup

[Tim Rowley]

---
 .../drivers/swr/rasterizer/codegen/gen_backends.py   | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/src/gallium/drivers/swr/rasterizer/codegen/gen_backends.py 
b/src/gallium/drivers/swr/rasterizer/codegen/gen_backends.py
index d9e938a..09f40fa 100644
--- a/src/gallium/drivers/swr/rasterizer/codegen/gen_backends.py
+++ b/src/gallium/drivers/swr/rasterizer/codegen/gen_backends.py
@@ -1,7 +1,7 @@
 # Copyright (C) 2017 Intel Corporation.   All Rights Reserved.
 #
 # Permission is hereby granted, free of charge, to any person obtaining a
-# copy of this software and associated documentation files (the "Software"),
+# 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
@@ -11,7 +11,7 @@
 # paragraph) shall be included in all copies or substantial portions of the
 # Software.
 #
-# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# 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
@@ -31,12 +31,12 @@ from gen_common import ArgumentParser, MakoTemplateWriter
 
 def main(args=sys.argv[1:]):
 thisDir = os.path.dirname(os.path.realpath(__file__))
-parser = ArgumentParser("Generate files and initialization functions for 
all permutuations of BackendPixelRate.")
-parser.add_argument('--dim', help="gBackendPixelRateTable array 
dimensions", nargs='+', type=int, required=True)
-parser.add_argument('--outdir', help="output directory", nargs='?', 
type=str, default=thisDir)
-parser.add_argument('--split', help="how many lines of initialization per 
file [0=no split]", nargs='?', type=int, default='512')
-parser.add_argument('--cpp', help="Generate cpp file(s)", 
action='store_true', default=False)
-parser.add_argument('--cmake', help="Generate cmake file", 
action='store_true', default=False)
+parser = ArgumentParser('Generate files and initialization functions for 
all permutuations of BackendPixelRate.')
+parser.add_argument('--dim', help='gBackendPixelRateTable array 
dimensions', nargs='+', type=int, required=True)
+parser.add_argument('--outdir', help='output directory', nargs='?', 
type=str, default=thisDir)
+parser.add_argument('--split', help='how many lines of initialization per 
file [0=no split]', nargs='?', type=int, default='512')
+parser.add_argument('--cpp', help='Generate cpp file(s)', 
action='store_true', default=False)
+parser.add_argument('--cmake', help='Generate cmake file', 
action='store_true', default=False)
 
 args = parser.parse_args(args);
 
-- 
2.7.4

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

[Mesa-dev] [PATCH v2 05/13] swr/rast: Support dynamically sized vertex layout

[Tim Rowley]

Each shader stage state (VS, TS, GS, SO, BE/CLIP) now has a
vertexAttribOffset to specify the offset to the start of the
general attribute section of the incoming verts for that stage.
It is up to the driver to set this up correctly based on the
active stages. All the shader stages use this value instead of
VERTEX_ATTRIB_START_SLOT to offset to the incoming attributes.

Only the vertex shader stage supports dynamic layout output
currently. The other stages continue to expect the output to be
the fixed layout slots as before. Will be enabling GS next.
---
 src/gallium/drivers/swr/rasterizer/core/binner.cpp |  4 +--
 src/gallium/drivers/swr/rasterizer/core/clip.h | 40 ++
 .../drivers/swr/rasterizer/core/frontend.cpp   | 10 +++---
 src/gallium/drivers/swr/rasterizer/core/state.h| 12 +++
 src/gallium/drivers/swr/swr_shader.cpp |  2 ++
 src/gallium/drivers/swr/swr_state.cpp  |  2 ++
 6 files changed, 49 insertions(+), 21 deletions(-)

diff --git a/src/gallium/drivers/swr/rasterizer/core/binner.cpp 
b/src/gallium/drivers/swr/rasterizer/core/binner.cpp
index 036d8b1..19eef9b 100644
--- a/src/gallium/drivers/swr/rasterizer/core/binner.cpp
+++ b/src/gallium/drivers/swr/rasterizer/core/binner.cpp
@@ -80,12 +80,12 @@ INLINE void ProcessAttributes(
 if (IsSwizzledT::value)
 {
 SWR_ATTRIB_SWIZZLE attribSwizzle = backendState.swizzleMap[i];
-inputSlot = VERTEX_ATTRIB_START_SLOT + attribSwizzle.sourceAttrib;
+inputSlot = backendState.vertexAttribOffset + 
attribSwizzle.sourceAttrib;
 
 }
 else
 {
-inputSlot = VERTEX_ATTRIB_START_SLOT + i;
+inputSlot = backendState.vertexAttribOffset + i;
 }
 
 __m128 attrib[3];// triangle attribs (always 4 wide)
diff --git a/src/gallium/drivers/swr/rasterizer/core/clip.h 
b/src/gallium/drivers/swr/rasterizer/core/clip.h
index 12b52c5..4f940d9 100644
--- a/src/gallium/drivers/swr/rasterizer/core/clip.h
+++ b/src/gallium/drivers/swr/rasterizer/core/clip.h
@@ -489,7 +489,7 @@ public:
 // Compute absolute attrib slot in vertex array
 uint32_t mapSlot = backendState.swizzleEnable ? 
backendState.swizzleMap[slot].sourceAttrib : slot;
 maxSlot = std::max(maxSlot, mapSlot);
-uint32_t inputSlot = VERTEX_ATTRIB_START_SLOT + mapSlot;
+uint32_t inputSlot = backendState.vertexAttribOffset + mapSlot;
 
 pa.Assemble(inputSlot, tmpVector);
 
@@ -625,10 +625,10 @@ public:
 }
 
 // transpose attribs
-pBase = (uint8_t*)([0].attrib[VERTEX_ATTRIB_START_SLOT]) 
+ sizeof(float) * inputPrim;
+pBase = 
(uint8_t*)([0].attrib[backendState.vertexAttribOffset]) + 
sizeof(float) * inputPrim;
 for (uint32_t attrib = 0; attrib < numAttribs; ++attrib)
 {
-uint32_t attribSlot = VERTEX_ATTRIB_START_SLOT + attrib;
+uint32_t attribSlot = backendState.vertexAttribOffset + attrib;
 for (uint32_t c = 0; c < 4; ++c)
 {
 #if USE_SIMD16_FRONTEND
@@ -746,7 +746,7 @@ public:
 // Compute absolute attrib slot in vertex array
 uint32_t mapSlot = backendState.swizzleEnable ? 
backendState.swizzleMap[slot].sourceAttrib : slot;
 maxSlot = std::max(maxSlot, mapSlot);
-uint32_t inputSlot = VERTEX_ATTRIB_START_SLOT + mapSlot;
+uint32_t inputSlot = backendState.vertexAttribOffset + mapSlot;
 
 pa.Assemble_simd16(inputSlot, tmpVector);
 
@@ -877,10 +877,10 @@ public:
 }
 
 // transpose attribs
-pBase = (uint8_t*)([0].attrib[VERTEX_ATTRIB_START_SLOT]) 
+ sizeof(float) * inputPrim;
+pBase = 
(uint8_t*)([0].attrib[backendState.vertexAttribOffset]) + 
sizeof(float) * inputPrim;
 for (uint32_t attrib = 0; attrib < numAttribs; ++attrib)
 {
-uint32_t attribSlot = VERTEX_ATTRIB_START_SLOT + attrib;
+uint32_t attribSlot = backendState.vertexAttribOffset + attrib;
 for (uint32_t c = 0; c < 4; ++c)
 {
 simdscalar temp = 
_simd_mask_i32gather_ps(_simd_setzero_ps(), (const float *)pBase, vOffsets, 
vMask, 1);
@@ -1230,6 +1230,8 @@ private:
 uint32_t numInAttribs,  // number of attributes per vertex.
 float *pOutVerts)   // array of output positions. We'll 
write our new intersection point at i*4.
 {
+uint32_t vertexAttribOffset = 
this->state.backendState.vertexAttribOffset;
+
 // compute interpolation factor
 simdscalar t;
 switch (ClippingPlane)
@@ -1263,7 +1265,7 @@ private:
 // interpolate attributes and store
 for (uint32_t a = 0; a < numInAttribs; ++a)
 {
-uint32_t attribSlot = VERTEX_ATTRIB_START_SLOT + a;
+uint32_t 

[Mesa-dev] [PATCH v2 06/13] swr/rast: gen_backends.py remove extraneous semicolon

[Tim Rowley]

---
 src/gallium/drivers/swr/rasterizer/codegen/gen_backends.py | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/swr/rasterizer/codegen/gen_backends.py 
b/src/gallium/drivers/swr/rasterizer/codegen/gen_backends.py
index 3f0790c..2fc91d1 100644
--- a/src/gallium/drivers/swr/rasterizer/codegen/gen_backends.py
+++ b/src/gallium/drivers/swr/rasterizer/codegen/gen_backends.py
@@ -40,7 +40,8 @@ def main(args=sys.argv[1:]):
 parser.add_argument('--hpp', help='Generate hpp file', 
action='store_true', default=False)
 parser.add_argument('--cmake', help='Generate cmake file', 
action='store_true', default=False)
 
-args = parser.parse_args(args);
+args = parser.parse_args(args)
+
 
 class backendStrs :
 def __init__(self) :
-- 
2.7.4

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

[Mesa-dev] [PATCH v2 00/13] swr: update rasterizer

[Tim Rowley]

Highlights include splitting the heavily templated files into multiple
chunks to speed compile (2x for a large machine), and switching the
simd intrinsic usage from a macro-based header to a more c++ feeling
library.

No regressions on piglit or vtk tests, passes "make dist"/compile.

v2:
  * split changes to generators to seperate functionality/cleanups
  * add scons patch so that .inl files can be handled
  * add comments explaining makefile .INTERMEDIATE usage

Tim Rowley (13):
  swr/rast: generators will create target directories
  swr/rast: gen_backends.py quote cleanup
  swr/rast: gen_backends.py removal of commented debug prints
  swr/rast: Split backend.cpp to improve compile time
  swr/rast: Support dynamically sized vertex layout
  swr/rast: gen_backends.py remove extraneous semicolon
  swr/rast: Split rasterizer.cpp to improve compile time
  swr/rast: Fix unused variable warnings
  scons: allow .inl file extension
  swr/rast: Switch intrinsic usage to SIMDLib
  swr/rast: Fix missing setup of psContext.pColorBuffer
  swr/rast: move default split size from driver to rasterizer
  swr/rast: increase number of possible draws in flight

 scons/custom.py|2 +-
 src/gallium/drivers/swr/Makefile.am|   66 +-
 src/gallium/drivers/swr/Makefile.sources   |   19 +-
 src/gallium/drivers/swr/SConscript |   41 +-
 .../drivers/swr/rasterizer/codegen/gen_backends.py |   55 +-
 .../drivers/swr/rasterizer/codegen/gen_common.py   |7 +
 .../drivers/swr/rasterizer/codegen/knob_defs.py|4 +-
 .../rasterizer/codegen/templates/gen_backend.cpp   |1 +
 .../codegen/templates/gen_header_init.hpp  |   43 +
 .../codegen/templates/gen_rasterizer.cpp   |   42 +
 src/gallium/drivers/swr/rasterizer/common/intrin.h |  102 +-
 .../drivers/swr/rasterizer/common/simd16intrin.h   | 1223 ++---
 .../drivers/swr/rasterizer/common/simdintrin.h | 1257 +++---
 .../drivers/swr/rasterizer/common/simdlib.hpp  |  550 ++
 .../swr/rasterizer/common/simdlib_128_avx.inl  |  545 ++
 .../swr/rasterizer/common/simdlib_128_avx2.inl |   68 +
 .../swr/rasterizer/common/simdlib_128_avx512.inl   |  408 +
 .../swr/rasterizer/common/simdlib_256_avx.inl  |  757 +
 .../swr/rasterizer/common/simdlib_256_avx2.inl |  234 +++
 .../swr/rasterizer/common/simdlib_256_avx512.inl   |  409 +
 .../swr/rasterizer/common/simdlib_512_avx512.inl   |  682 
 .../rasterizer/common/simdlib_512_avx512_masks.inl |   27 +
 .../swr/rasterizer/common/simdlib_512_emu.inl  |  842 +
 .../rasterizer/common/simdlib_512_emu_masks.inl|   28 +
 .../swr/rasterizer/common/simdlib_interface.hpp|  428 +
 .../swr/rasterizer/common/simdlib_types.hpp|  377 +
 src/gallium/drivers/swr/rasterizer/core/api.cpp|8 +-
 .../drivers/swr/rasterizer/core/backend.cpp|  809 +
 src/gallium/drivers/swr/rasterizer/core/backend.h  | 1033 +--
 .../drivers/swr/rasterizer/core/backend_clear.cpp  |  281 +++
 .../drivers/swr/rasterizer/core/backend_impl.h | 1067 
 .../drivers/swr/rasterizer/core/backend_sample.cpp |  344 
 .../swr/rasterizer/core/backend_singlesample.cpp   |  320 
 src/gallium/drivers/swr/rasterizer/core/binner.cpp |  293 ++--
 src/gallium/drivers/swr/rasterizer/core/clip.cpp   |6 +-
 src/gallium/drivers/swr/rasterizer/core/clip.h |   50 +-
 src/gallium/drivers/swr/rasterizer/core/context.h  |2 +-
 .../swr/rasterizer/core/format_conversion.h|8 +-
 .../drivers/swr/rasterizer/core/format_types.h |   30 +-
 .../drivers/swr/rasterizer/core/format_utils.h |  268 +--
 .../drivers/swr/rasterizer/core/frontend.cpp   |   16 +-
 src/gallium/drivers/swr/rasterizer/core/frontend.h |4 +-
 .../drivers/swr/rasterizer/core/multisample.cpp|   48 -
 src/gallium/drivers/swr/rasterizer/core/pa.h   |   16 +-
 src/gallium/drivers/swr/rasterizer/core/pa_avx.cpp |  106 +-
 .../drivers/swr/rasterizer/core/rasterizer.cpp | 1788 +++-
 .../drivers/swr/rasterizer/core/rasterizer.h   |   31 +-
 .../drivers/swr/rasterizer/core/rasterizer_impl.h  | 1376 +++
 src/gallium/drivers/swr/rasterizer/core/state.h|   12 +
 .../drivers/swr/rasterizer/memory/StoreTile.h  |  156 +-
 src/gallium/drivers/swr/swr_screen.cpp |4 -
 src/gallium/drivers/swr/swr_shader.cpp |2 +
 src/gallium/drivers/swr/swr_state.cpp  |2 +
 53 files changed, 10145 insertions(+), 6152 deletions(-)
 create mode 100644 
src/gallium/drivers/swr/rasterizer/codegen/templates/gen_header_init.hpp
 create mode 100644 
src/gallium/drivers/swr/rasterizer/codegen/templates/gen_rasterizer.cpp
 create mode 100644 src/gallium/drivers/swr/rasterizer/common/simdlib.hpp
 create mode 100644 
src/gallium/drivers/swr/rasterizer/common/simdlib_128_avx.inl
 create mode 100644 

[Mesa-dev] [PATCH v2 11/13] swr/rast: Fix missing setup of psContext.pColorBuffer

[Tim Rowley]

Fixes render target read access from pixel shaders.
---
 .../drivers/swr/rasterizer/core/backend_sample.cpp| 15 +++
 .../drivers/swr/rasterizer/core/backend_singlesample.cpp  | 15 +++
 2 files changed, 14 insertions(+), 16 deletions(-)

diff --git a/src/gallium/drivers/swr/rasterizer/core/backend_sample.cpp 
b/src/gallium/drivers/swr/rasterizer/core/backend_sample.cpp
index 0f75ec2..2dca5d8 100644
--- a/src/gallium/drivers/swr/rasterizer/core/backend_sample.cpp
+++ b/src/gallium/drivers/swr/rasterizer/core/backend_sample.cpp
@@ -50,13 +50,13 @@ void BackendSampleRate(DRAW_CONTEXT *pDC, uint32_t 
workerId, uint32_t x, uint32_
 BarycentricCoeffs coeffs;
 SetupBarycentricCoeffs(, work);
 
-uint8_t *pColorBuffer[SWR_NUM_RENDERTARGETS], *pDepthBuffer, 
*pStencilBuffer;
-SetupRenderBuffers(pColorBuffer, , , 
state.psState.numRenderTargets, renderBuffers);
-
 SWR_PS_CONTEXT psContext;
 const SWR_MULTISAMPLE_POS& samplePos = state.rastState.samplePositions;
 SetupPixelShaderContext(, samplePos, work);
 
+uint8_t *pDepthBuffer, *pStencilBuffer;
+SetupRenderBuffers(psContext.pColorBuffer, , , 
state.psState.numRenderTargets, renderBuffers);
+
 AR_END(BESetup, 0);
 
 psContext.vY.UL = _simd_add_ps(vULOffsetsY, 
_simd_set1_ps(static_cast(y)));
@@ -75,7 +75,6 @@ void BackendSampleRate(DRAW_CONTEXT *pDC, uint32_t workerId, 
uint32_t x, uint32_
 {
 #if USE_8x2_TILE_BACKEND
 const bool useAlternateOffset = ((xx & SIMD_TILE_X_DIM) != 0);
-
 #endif
 if (T::InputCoverage != SWR_INPUT_COVERAGE_NONE)
 {
@@ -199,9 +198,9 @@ void BackendSampleRate(DRAW_CONTEXT *pDC, uint32_t 
workerId, uint32_t x, uint32_
 // output merger
 AR_BEGIN(BEOutputMerger, pDC->drawId);
 #if USE_8x2_TILE_BACKEND
-OutputMerger8x2(psContext, pColorBuffer, sample, 
, state.pfnBlendFunc, vCoverageMask, depthPassMask, 
state.psState.numRenderTargets, state.colorHottileEnable, useAlternateOffset);
+OutputMerger8x2(psContext, psContext.pColorBuffer, sample, 
, state.pfnBlendFunc, vCoverageMask, depthPassMask, 
state.psState.numRenderTargets, state.colorHottileEnable, useAlternateOffset);
 #else
-OutputMerger4x2(psContext, pColorBuffer, sample, 
, state.pfnBlendFunc, vCoverageMask, depthPassMask, 
state.psState.numRenderTargets);
+OutputMerger4x2(psContext, psContext.pColorBuffer, sample, 
, state.pfnBlendFunc, vCoverageMask, depthPassMask, 
state.psState.numRenderTargets);
 #endif
 
 // do final depth write after all pixel kills
@@ -230,13 +229,13 @@ void BackendSampleRate(DRAW_CONTEXT *pDC, uint32_t 
workerId, uint32_t x, uint32_
 {
 for (uint32_t rt = 0; rt < state.psState.numRenderTargets; 
++rt)
 {
-pColorBuffer[rt] += (2 * KNOB_SIMD_WIDTH * 
FormatTraits::bpp) / 8;
+psContext.pColorBuffer[rt] += (2 * KNOB_SIMD_WIDTH * 
FormatTraits::bpp) / 8;
 }
 }
 #else
 for (uint32_t rt = 0; rt < state.psState.numRenderTargets; ++rt)
 {
-pColorBuffer[rt] += (KNOB_SIMD_WIDTH * 
FormatTraits::bpp) / 8;
+psContext.pColorBuffer[rt] += (KNOB_SIMD_WIDTH * 
FormatTraits::bpp) / 8;
 }
 #endif
 pDepthBuffer += (KNOB_SIMD_WIDTH * 
FormatTraits::bpp) / 8;
diff --git a/src/gallium/drivers/swr/rasterizer/core/backend_singlesample.cpp 
b/src/gallium/drivers/swr/rasterizer/core/backend_singlesample.cpp
index 0eecc25..8ae2cf4 100644
--- a/src/gallium/drivers/swr/rasterizer/core/backend_singlesample.cpp
+++ b/src/gallium/drivers/swr/rasterizer/core/backend_singlesample.cpp
@@ -50,13 +50,13 @@ void BackendSingleSample(DRAW_CONTEXT *pDC, uint32_t 
workerId, uint32_t x, uint3
 BarycentricCoeffs coeffs;
 SetupBarycentricCoeffs(, work);
 
-uint8_t *pColorBuffer[SWR_NUM_RENDERTARGETS], *pDepthBuffer, 
*pStencilBuffer;
-SetupRenderBuffers(pColorBuffer, , , 
state.psState.numRenderTargets, renderBuffers);
-
 SWR_PS_CONTEXT psContext;
 const SWR_MULTISAMPLE_POS& samplePos = state.rastState.samplePositions;
 SetupPixelShaderContext(, samplePos, work);
 
+uint8_t *pDepthBuffer, *pStencilBuffer;
+SetupRenderBuffers(psContext.pColorBuffer, , , 
state.psState.numRenderTargets, renderBuffers);
+
 AR_END(BESetup, 1);
 
 psContext.vY.UL = _simd_add_ps(vULOffsetsY, 
_simd_set1_ps(static_cast(y)));
@@ -75,7 +75,6 @@ void BackendSingleSample(DRAW_CONTEXT *pDC, uint32_t 
workerId, uint32_t x, uint3
 {
 #if USE_8x2_TILE_BACKEND
 const bool useAlternateOffset = ((xx & SIMD_TILE_X_DIM) != 0);
-
 #endif
 simdmask coverageMask = work.coverageMask[0] & MASK;
 
@@ -184,9 +183,9 @@ void BackendSingleSample(DRAW_CONTEXT *pDC, uint32_t 
workerId, uint32_t x, uint3
 // 

[Mesa-dev] [PATCH v2 13/13] swr/rast: increase number of possible draws in flight

[Tim Rowley]

Increases performance of some large workloads on KNL by ~30%.
---
 src/gallium/drivers/swr/rasterizer/codegen/knob_defs.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/swr/rasterizer/codegen/knob_defs.py 
b/src/gallium/drivers/swr/rasterizer/codegen/knob_defs.py
index c8eb2a3..09e3124 100644
--- a/src/gallium/drivers/swr/rasterizer/codegen/knob_defs.py
+++ b/src/gallium/drivers/swr/rasterizer/codegen/knob_defs.py
@@ -130,7 +130,7 @@ KNOBS = [
 
 ['MAX_DRAWS_IN_FLIGHT', {
 'type'  : 'uint32_t',
-'default'   : '128',
+'default'   : '256',
 'desc'  : ['Maximum number of draws outstanding before API thread 
blocks.',
'This value MUST be evenly divisible into 2^32'],
 'category'  : 'perf',
-- 
2.7.4

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

[Mesa-dev] [PATCH v2 09/13] scons: allow .inl file extension

[Tim Rowley]

Intended for header files which are not meant to be included directly.
---
 scons/custom.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scons/custom.py b/scons/custom.py
index 544b15d..955247c 100644
--- a/scons/custom.py
+++ b/scons/custom.py
@@ -281,7 +281,7 @@ def parse_source_list(env, filename, names=None):
 # cause duplicate actions.
 f = f[len(cur_srcdir + '/'):]
 # do not include any headers
-if f.endswith(tuple(['.h','.hpp'])):
+if f.endswith(tuple(['.h','.hpp','.inl'])):
 continue
 srcs.append(f)
 
-- 
2.7.4

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

[Mesa-dev] [PATCH v2 08/13] swr/rast: Fix unused variable warnings

[Tim Rowley]

---
 src/gallium/drivers/swr/rasterizer/core/binner.cpp | 6 --
 1 file changed, 6 deletions(-)

diff --git a/src/gallium/drivers/swr/rasterizer/core/binner.cpp 
b/src/gallium/drivers/swr/rasterizer/core/binner.cpp
index 19eef9b..29d2f1c 100644
--- a/src/gallium/drivers/swr/rasterizer/core/binner.cpp
+++ b/src/gallium/drivers/swr/rasterizer/core/binner.cpp
@@ -443,7 +443,6 @@ void BinTriangles(
 const API_STATE& state = GetApiState(pDC);
 const SWR_RASTSTATE& rastState = state.rastState;
 const SWR_FRONTEND_STATE& feState = state.frontendState;
-const SWR_GS_STATE& gsState = state.gsState;
 MacroTileMgr *pTileMgr = pDC->pTileMgr;
 
 simdscalar vRecipW0 = _simd_set1_ps(1.0f);
@@ -886,7 +885,6 @@ void SIMDAPI BinTriangles_simd16(
 const API_STATE& state = GetApiState(pDC);
 const SWR_RASTSTATE& rastState = state.rastState;
 const SWR_FRONTEND_STATE& feState = state.frontendState;
-const SWR_GS_STATE& gsState = state.gsState;
 
 MacroTileMgr *pTileMgr = pDC->pTileMgr;
 
@@ -1393,7 +1391,6 @@ void BinPostSetupPoints(
 simdvector& primVerts = prim[0];
 
 const API_STATE& state = GetApiState(pDC);
-const SWR_GS_STATE& gsState = state.gsState;
 const SWR_RASTSTATE& rastState = state.rastState;
 const uint32_t *pViewportIndex = (uint32_t *)
 
@@ -1773,7 +1770,6 @@ void BinPostSetupPoints_simd16(
 simd16vector& primVerts = prim[0];
 
 const API_STATE& state = GetApiState(pDC);
-const SWR_GS_STATE& gsState = state.gsState;
 const SWR_RASTSTATE& rastState = state.rastState;
 const uint32_t *pViewportIndex = (uint32_t *)
 
@@ -2164,7 +2160,6 @@ void BinPostSetupLines(
 
 const API_STATE& state = GetApiState(pDC);
 const SWR_RASTSTATE& rastState = state.rastState;
-const SWR_GS_STATE& gsState = state.gsState;
 
 // Select attribute processor
 PFN_PROCESS_ATTRIBUTES pfnProcessAttribs = GetProcessAttributesFunc(2,
@@ -2367,7 +2362,6 @@ void BinPostSetupLines_simd16(
 
 const API_STATE& state = GetApiState(pDC);
 const SWR_RASTSTATE& rastState = state.rastState;
-const SWR_GS_STATE& gsState = state.gsState;
 
 // Select attribute processor
 PFN_PROCESS_ATTRIBUTES pfnProcessAttribs = GetProcessAttributesFunc(2,
-- 
2.7.4

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

[Mesa-dev] [PATCH v2 01/13] swr/rast: generators will create target directories

[Tim Rowley]

---
 src/gallium/drivers/swr/rasterizer/codegen/gen_common.py | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/src/gallium/drivers/swr/rasterizer/codegen/gen_common.py 
b/src/gallium/drivers/swr/rasterizer/codegen/gen_common.py
index 07b455a..7f53ec6 100644
--- a/src/gallium/drivers/swr/rasterizer/codegen/gen_common.py
+++ b/src/gallium/drivers/swr/rasterizer/codegen/gen_common.py
@@ -22,6 +22,7 @@
 # Python source
 from __future__ import print_function
 import os
+import errno
 import sys
 import argparse
 from mako.template import Template
@@ -62,6 +63,12 @@ class MakoTemplateWriter:
 '''
 Write template data to a file
 '''
+if not os.path.exists(os.path.dirname(output_filename)):
+try:
+os.makedirs(os.path.dirname(output_filename))
+except OSError as err:
+if err.errno != errno.EEXIST:
+raise
 with open(output_filename, 'w') as outfile:
 print(MakoTemplateWriter.to_string(template_filename, **kwargs), 
file=outfile)
 
-- 
2.7.4

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

[Mesa-dev] [PATCH v2 12/13] swr/rast: move default split size from driver to rasterizer

[Tim Rowley]

---
 src/gallium/drivers/swr/rasterizer/codegen/knob_defs.py | 2 +-
 src/gallium/drivers/swr/swr_screen.cpp  | 4 
 2 files changed, 1 insertion(+), 5 deletions(-)

diff --git a/src/gallium/drivers/swr/rasterizer/codegen/knob_defs.py 
b/src/gallium/drivers/swr/rasterizer/codegen/knob_defs.py
index 02436f2..c8eb2a3 100644
--- a/src/gallium/drivers/swr/rasterizer/codegen/knob_defs.py
+++ b/src/gallium/drivers/swr/rasterizer/codegen/knob_defs.py
@@ -138,7 +138,7 @@ KNOBS = [
 
 ['MAX_PRIMS_PER_DRAW', {
 'type'  : 'uint32_t',
-'default'   : '2040',
+'default'   : '49152',
 'desc'  : ['Maximum primitives in a single Draw().',
'Larger primitives are split into smaller Draw calls.',
'Should be a multiple of (3 * vectorWidth).'],
diff --git a/src/gallium/drivers/swr/swr_screen.cpp 
b/src/gallium/drivers/swr/swr_screen.cpp
index a80ec2a..b7f06c0 100644
--- a/src/gallium/drivers/swr/swr_screen.cpp
+++ b/src/gallium/drivers/swr/swr_screen.cpp
@@ -1065,10 +1065,6 @@ swr_create_screen_internal(struct sw_winsys *winsys)
if (!screen)
   return NULL;
 
-   if (!getenv("KNOB_MAX_PRIMS_PER_DRAW")) {
-  g_GlobalKnobs.MAX_PRIMS_PER_DRAW.Value(49152);
-   }
-
if (!lp_build_init()) {
   FREE(screen);
   return NULL;
-- 
2.7.4

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

[Mesa-dev] [PATCH 2/3] i965: Add a RGBX->RGBA fallback for glEGLImageTextureTarget2D()

[Chad Versace]

This enables support for importing RGBX EGLImage textures on
Skylake.

Chrome OS needs support for RGBX EGLImage textures because because
the Android framework produces HAL_PIXEL_FORMAT_RGBX winsys
surfaces, which the Chrome OS compositor consumes as dma_bufs.  On
hardware for which RGBX is unsupported or disabled, normally core Mesa
provides the RGBX->RGBA fallback during glTexStorage.  But the DRIimage
code bypasses core Mesa, so we must do the fallback in i965.
---
 src/mesa/drivers/dri/i965/intel_tex_image.c | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_tex_image.c 
b/src/mesa/drivers/dri/i965/intel_tex_image.c
index b1fe8dd584e..22be1149a9b 100644
--- a/src/mesa/drivers/dri/i965/intel_tex_image.c
+++ b/src/mesa/drivers/dri/i965/intel_tex_image.c
@@ -267,8 +267,22 @@ create_mt_for_dri_image(struct brw_context *brw,
struct gl_context *ctx = >ctx;
struct intel_mipmap_tree *mt;
uint32_t draw_x, draw_y;
+   mesa_format format = image->format;
+
+   if (!ctx->TextureFormatSupported[format]) {
+  /* The texture storage paths in core Mesa detect if the driver does not
+   * support the user-requested format, and then searches for a
+   * fallback format. The DRIimage code bypasses core Mesa, though. So we
+   * do the fallbacks here for important formats.
+   *
+   * We must support DRM_FOURCC_XBGR textures because the Android
+   * framework produces HAL_PIXEL_FORMAT_RGBX winsys surfaces, which
+   * the Chrome OS compositor consumes as dma_buf EGLImages.
+   */
+  format = _mesa_format_fallback_rgbx_to_rgba(format);
+   }
 
-   if (!ctx->TextureFormatSupported[image->format])
+   if (!ctx->TextureFormatSupported[format])
   return NULL;
 
/* Disable creation of the texture's aux buffers because the driver exposes
@@ -276,7 +290,7 @@ create_mt_for_dri_image(struct brw_context *brw,
 * buffer's content to the main buffer nor for invalidating the aux buffer's
 * content.
 */
-   mt = intel_miptree_create_for_bo(brw, image->bo, image->format,
+   mt = intel_miptree_create_for_bo(brw, image->bo, format,
 0, image->width, image->height, 1,
 image->pitch,
 MIPTREE_LAYOUT_DISABLE_AUX);
-- 
2.13.0

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

[Mesa-dev] [PATCH 1/3] mesa: Add _mesa_format_fallback_rgbx_to_rgba() [v2]

[Chad Versace]

The new function takes a mesa_format and, if the format is an alpha
format with a non-alpha variant, returns the non-alpha format.
Otherwise, it returns the original format.

Example:
  input -> output

  // Fallback exists
  MESA_FORMAT_R8G8B8X8_UNORM -> MESA_FORMAT_R8G8B8A8_UNORM
  MESA_FORMAT_RGBX_UNORM16 -> MESA_FORMAT_RGBA_UNORM16

  // No fallback
  MESA_FORMAT_R8G8B8A8_UNORM -> MESA_FORMAT_R8G8B8A8_UNORM
  MESA_FORMAT_Z_FLOAT32 -> MESA_FORMAT_Z_FLOAT32

i965 will use this for EGLImages and DRIimages.

v2 (Jason Ekstrand):
 - Use mako
 - Rework to be easier to read
 - Write directly to the output file
---
 src/mesa/Android.gen.mk  |  12 +
 src/mesa/Makefile.am |   7 +++
 src/mesa/Makefile.sources|   1 +
 src/mesa/main/.gitignore |   1 +
 src/mesa/main/format_fallback.py | 104 +++
 src/mesa/main/formats.h  |   6 +++
 6 files changed, 131 insertions(+)
 create mode 100644 src/mesa/main/format_fallback.py

diff --git a/src/mesa/Android.gen.mk b/src/mesa/Android.gen.mk
index 366a6b1036e..8d242600f54 100644
--- a/src/mesa/Android.gen.mk
+++ b/src/mesa/Android.gen.mk
@@ -34,6 +34,7 @@ sources := \
main/enums.c \
main/api_exec.c \
main/dispatch.h \
+   main/format_fallback.c \
main/format_pack.c \
main/format_unpack.c \
main/format_info.h \
@@ -123,6 +124,17 @@ $(intermediates)/main/get_hash.h: 
$(glapi)/gl_and_es_API.xml \
$(LOCAL_PATH)/main/get_hash_params.py $(GET_HASH_GEN)
$(call es-gen)
 
+FORMAT_FALLBACK := $(LOCAL_PATH)/main/format_fallback.py
+format_fallback_deps := \
+   $(LOCAL_PATH)/main/formats.csv \
+   $(LOCAL_PATH)/main/format_parser.py \
+   $(FORMAT_FALLBACK)
+
+$(intermediates)/main/format_fallback.c: PRIVATE_SCRIPT := $(MESA_PYTHON2) 
$(FORMAT_FALLBACK)
+$(intermediates)/main/format_fallback.c: PRIVATE_XML :=
+$(intermediates)/main/format_fallback.c: $(format_fallback_deps)
+   $(call es-gen, $<)
+
 FORMAT_INFO := $(LOCAL_PATH)/main/format_info.py
 format_info_deps := \
$(LOCAL_PATH)/main/formats.csv \
diff --git a/src/mesa/Makefile.am b/src/mesa/Makefile.am
index 53f311d2a97..97a9bbd8c25 100644
--- a/src/mesa/Makefile.am
+++ b/src/mesa/Makefile.am
@@ -37,6 +37,7 @@ include Makefile.sources
 
 EXTRA_DIST = \
drivers/SConscript \
+   main/format_fallback.py \
main/format_info.py \
main/format_pack.py \
main/format_parser.py \
@@ -54,6 +55,7 @@ EXTRA_DIST = \
 
 BUILT_SOURCES = \
main/get_hash.h \
+   main/format_fallback.c \
main/format_info.h \
main/format_pack.c \
main/format_unpack.c \
@@ -70,6 +72,11 @@ main/get_hash.h: ../mapi/glapi/gen/gl_and_es_API.xml 
main/get_hash_params.py \
$(PYTHON_GEN) $(srcdir)/main/get_hash_generator.py \
-f $(srcdir)/../mapi/glapi/gen/gl_and_es_API.xml > $@
 
+main/format_fallback.c: main/format_fallback.py \
+main/format_parser.py \
+   main/formats.csv
+   $(PYTHON_GEN) $(srcdir)/main/format_fallback.py 
$(srcdir)/main/formats.csv $@
+
 main/format_info.h: main/formats.csv \
 main/format_parser.py main/format_info.py
$(PYTHON_GEN) $(srcdir)/main/format_info.py $(srcdir)/main/formats.csv 
> $@
diff --git a/src/mesa/Makefile.sources b/src/mesa/Makefile.sources
index b80882fb8de..86fbf3974ed 100644
--- a/src/mesa/Makefile.sources
+++ b/src/mesa/Makefile.sources
@@ -94,6 +94,7 @@ MAIN_FILES = \
main/ffvertex_prog.h \
main/fog.c \
main/fog.h \
+   main/format_fallback.c \
main/format_info.h \
main/format_pack.h \
main/format_pack.c \
diff --git a/src/mesa/main/.gitignore b/src/mesa/main/.gitignore
index 836d8f104a8..8cc33cfee68 100644
--- a/src/mesa/main/.gitignore
+++ b/src/mesa/main/.gitignore
@@ -4,6 +4,7 @@ enums.c
 remap_helper.h
 get_hash.h
 get_hash.h.tmp
+format_fallback.c
 format_info.h
 format_info.c
 format_pack.c
diff --git a/src/mesa/main/format_fallback.py b/src/mesa/main/format_fallback.py
new file mode 100644
index 000..e3b9916f6ee
--- /dev/null
+++ b/src/mesa/main/format_fallback.py
@@ -0,0 +1,104 @@
+COPYRIGHT = """\
+/*
+ * Copyright 2017 Google
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY 

Re: [Mesa-dev] [PATCH 12/30] i965/miptree: Allocate mt earlier in update winsys

[Pohjolainen, Topi]

On Mon, Jun 26, 2017 at 09:36:34PM +0300, Pohjolainen, Topi wrote:
> On Fri, Jun 16, 2017 at 03:41:34PM -0700, Jason Ekstrand wrote:
> > From: Ben Widawsky 
> > 
> > Allows us to continue utilizing common miptree creation using __DRIimage
> > without creating a new DRIimage (for the intel_process_dri2_buffer()
> > case).
> 
> Just looking this patch locally I don't really understand this commit
> message. I'll keep on reading if the answer is later in the series..

Looking the rest of the series the message given here is still confusing.
Something of this sort I would understand:

Later patches require intel_update_image_buffer() to have control over the
miptree creation. Currently, however, intel_update_winsys_renderbuffer_miptree()
creates it based on the given buffer object. This patch moves the creation to
the caller side.

> 
> > 
> > This is a bit ugly, but I think it's the best one can do.
> > 
> > v2: This patch let's us remove the temporary no_aux variable since mt
> > allocation should work correctly now.
> > Unref the BO is miptree creation fails (Jason)
> > v3: Rebase (Daniel)
> > 
> > Cc: Jason Ekstrand 
> > Signed-off-by: Ben Widawsky 
> > Acked-by: Daniel Stone 
> > ---
> >  src/mesa/drivers/dri/i965/brw_context.c   | 37 
> > ---
> >  src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 16 ++--
> >  src/mesa/drivers/dri/i965/intel_mipmap_tree.h |  2 +-
> >  3 files changed, 37 insertions(+), 18 deletions(-)
> > 
> > diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
> > b/src/mesa/drivers/dri/i965/brw_context.c
> > index e963e13..f57045f 100644
> > --- a/src/mesa/drivers/dri/i965/brw_context.c
> > +++ b/src/mesa/drivers/dri/i965/brw_context.c
> > @@ -1611,10 +1611,26 @@ intel_process_dri2_buffer(struct brw_context *brw,
> >return;
> > }
> >  
> > -   if (!intel_update_winsys_renderbuffer_miptree(brw, rb, bo,
> > +   struct intel_mipmap_tree *mt =
> > +  intel_miptree_create_for_bo(brw,
> > +  bo,
> > +  intel_rb_format(rb),
> > +  0,
> > +  drawable->w,
> > +  drawable->h,
> > +  1,
> > +  buffer->pitch,
> > +  MIPTREE_LAYOUT_FOR_SCANOUT);
> > +   if (!mt) {
> > +  brw_bo_unreference(bo);
> > +  return;
> > +   }
> > +
> > +   if (!intel_update_winsys_renderbuffer_miptree(brw, rb, mt,
> >   drawable->w, drawable->h,
> >   buffer->pitch)) {
> >brw_bo_unreference(bo);
> > +  intel_miptree_release();
> >return;
> > }
> >  
> > @@ -1672,10 +1688,25 @@ intel_update_image_buffer(struct brw_context *intel,
> > if (last_mt && last_mt->bo == buffer->bo)
> >return;
> >  
> > -   if (!intel_update_winsys_renderbuffer_miptree(intel, rb, buffer->bo,
> > +   struct intel_mipmap_tree *mt =
> > +  intel_miptree_create_for_bo(intel,
> > +  buffer->bo,
> > +  intel_rb_format(rb),
> > +  0,
> > +  buffer->width,
> > +  buffer->height,
> > +  1,
> > +  buffer->pitch,
> > +  MIPTREE_LAYOUT_FOR_SCANOUT);
> > +   if (!mt)
> > +  return;
> > +
> > +   if (!intel_update_winsys_renderbuffer_miptree(intel, rb, mt,
> >   buffer->width, 
> > buffer->height,
> > - buffer->pitch))
> > + buffer->pitch)) {
> > +  intel_miptree_release();
> >return;
> > +   }
> >  
> > if (_mesa_is_front_buffer_drawing(fb) &&
> > buffer_type == __DRI_IMAGE_BUFFER_FRONT &&
> > diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
> > b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > index 893f13e..08c13fc 100644
> > --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > @@ -960,11 +960,10 @@ intel_miptree_create_for_dri_image(struct brw_context 
> > *brw,
> >  bool
> >  intel_update_winsys_renderbuffer_miptree(struct brw_context *intel,
> >   struct intel_renderbuffer *irb,
> > - struct brw_bo *bo,
> > + struct intel_mipmap_tree 
> > *singlesample_mt,
> >   uint32_t width, uint32_t height,
> >   uint32_t pitch)
> >  {
> > -   struct 

[Mesa-dev] [PATCH 0/3 v2] i965: Add RGBX, RGBA configs, even on gen9

[Chad Versace]

The Android framework requires support for EGLConfigs with
HAL_PIXEL_FORMAT_RGBX_ and HAL_PIXEL_FORMAT_RGBA_. This prevents
Chrome OS from updating its Android drivers, because earlier this year
Intel disabled all rgbx formats for gen >=9 in brw_surface_formats.c.
This patch series safely (hopefully?) fixes that problem.


v2:
  - Use Jason's rewrite of patch for _mesa_format_fallback_rgbx_to_rgba.
  - Rebase on master.

I previously discussed using ctx->dd.ChooseTextureFormat for the
rfbx->rgba fallback in glEGLImageTextureTarget2D(), but decided against
it after investigating it more closely. The problem is that
ctx->dd.ChooseTextureFormat is not aware of channel order, and so
may choose the wrong format.

Testing:
- I did all testing on Skylake.
- Confirmed glxgears have correct colors.
- Confirmed Amarok has correct colors.
- Tested with dEQP, master@7bff163e7f on Wayland and X11:

  > deqp-egl --deqp-case='dEQP-EGL.functional.image.modify.*'
  Test run totals:
Passed:24/37 (64.9%)
Failed:0/37 (0.0%)
Not supported: 13/37 (35.1%)
Warnings:  0/37 (0.0%)

This patch series lives on the tag

http://git.kiwitree.net/cgit/~chadv/mesa/tag/?h=chadv/review/i965-r8g8b8x8-config-v02

Chad Versace (3):
  mesa: Add _mesa_format_fallback_rgbx_to_rgba() [v2]
  i965: Add a RGBX->RGBA fallback for glEGLImageTextureTarget2D()
  i965/dri: Support R8G8B8A8 and R8G8B8X8 configs

 src/mesa/Android.gen.mk |  12 
 src/mesa/Makefile.am|   7 ++
 src/mesa/Makefile.sources   |   1 +
 src/mesa/drivers/dri/i965/intel_fbo.c   |  23 +-
 src/mesa/drivers/dri/i965/intel_screen.c|  23 +-
 src/mesa/drivers/dri/i965/intel_tex_image.c |  18 -
 src/mesa/main/.gitignore|   1 +
 src/mesa/main/format_fallback.py| 104 
 src/mesa/main/formats.h |   6 ++
 9 files changed, 190 insertions(+), 5 deletions(-)
 create mode 100644 src/mesa/main/format_fallback.py

--
2.13.0

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

Re: [Mesa-dev] [RFT PATCH 2/2] nv20: enable ARB_texture_border_clamp support

[Ilia Mirkin]

On Tue, Jun 27, 2017 at 1:11 PM, Ian Romanick  wrote:
> On 06/27/2017 02:59 AM, Timothy Arceri wrote:
>> Just curious. Can this extension be added to NV04 and NV10? As those are
>> the only drivers that don't currently support it.
>>
>> I have cards I could test those with, but don't have an NV20.
>
> I just sent out an updated series that I tested on NV20.  Thanks for
> reminding me. :)
>
> I *think* NV10 can do this, but the implementation would be... painful.
> NV10 (and on) supports texture borders... that extra one pixel of pixels
> on each side that's outside the usual [0,1]x[0,1] sampling range.  I
> believe this extension could be supported by creating every texture with
> a border and filling the border with the GL border color.

That's right, they support the border inside the texture. I think that
was killed in mesa though, and I have no interest in reinstating it :)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965: Fix anisotropic filtering for mag filter

[Kenneth Graunke]

On Tuesday, June 27, 2017 10:37:16 AM PDT Rafael Antognolli wrote:
> From: Eero Tamminen 
> 
> Commit f8d69beed49c64f883bb8ffb28d4960306baf575 moving sampler
> handling to genxml messed up change done by commit
> 6a7c5257cac23cd9767aa4bc8fdab68925b11157.
> 
> This broke rendering in SynMark CSDof and TexFilterAniso tests.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101607
> 
> Thanks to Kevin, who spotted the actual typo!
> ---
>  src/mesa/drivers/dri/i965/genX_state_upload.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/genX_state_upload.c 
> b/src/mesa/drivers/dri/i965/genX_state_upload.c
> index d65b468..06b9cd5 100644
> --- a/src/mesa/drivers/dri/i965/genX_state_upload.c
> +++ b/src/mesa/drivers/dri/i965/genX_state_upload.c
> @@ -4551,7 +4551,7 @@ genX(update_sampler_state)(struct brw_context *brw,
> if (sampler->MaxAnisotropy > 1.0f) {
>if (samp_st.MinModeFilter == MAPFILTER_LINEAR)
>   samp_st.MinModeFilter = MAPFILTER_ANISOTROPIC;
> -  if (samp_st.MinModeFilter == MAPFILTER_LINEAR)
> +  if (samp_st.MagModeFilter == MAPFILTER_LINEAR)
>   samp_st.MagModeFilter = MAPFILTER_ANISOTROPIC;
>  
>if (sampler->MaxAnisotropy > 2.0f) {
> 

Reviewed-by: Kenneth Graunke 


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

Re: [Mesa-dev] [PATCH 12/12] i965: Assert that blorp always handles color blits

[Kenneth Graunke]

On Monday, June 26, 2017 4:22:45 PM PDT Ian Romanick wrote:
> From: Ian Romanick 
> 
> ---
>  src/mesa/drivers/dri/i965/brw_blorp.c | 2 ++
>  src/mesa/drivers/dri/i965/intel_fbo.c | 3 +++
>  2 files changed, 5 insertions(+)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c 
> b/src/mesa/drivers/dri/i965/brw_blorp.c
> index 92d1d2a..9c9b859 100644
> --- a/src/mesa/drivers/dri/i965/brw_blorp.c
> +++ b/src/mesa/drivers/dri/i965/brw_blorp.c
> @@ -707,6 +707,8 @@ brw_blorp_framebuffer(struct brw_context *brw,
>}
> }
>  
> +   /* try_blorp_blit should always be successful for color blits. */
> +   assert(!(mask & GL_COLOR_BUFFER_BIT));
> return mask;
>  }
>  
> diff --git a/src/mesa/drivers/dri/i965/intel_fbo.c 
> b/src/mesa/drivers/dri/i965/intel_fbo.c
> index caf182c..f0f87bb 100644
> --- a/src/mesa/drivers/dri/i965/intel_fbo.c
> +++ b/src/mesa/drivers/dri/i965/intel_fbo.c
> @@ -932,6 +932,9 @@ intel_blit_framebuffer(struct gl_context *ctx,
> if (mask == 0x0)
>return;
>  
> +   /* brw_blorp_framebuffer should always be successful for color blits. */
> +   assert(!(mask & GL_COLOR_BUFFER_BIT));
> +
> mask = _mesa_meta_BlitFramebuffer(ctx, readFb, drawFb,
>   srcX0, srcY0, srcX1, srcY1,
>   dstX0, dstY0, dstX1, dstY1,
> 

Is that true?  I suppose scaling and filtering isn't a problem, because
that will apply to the source formats, which should all be texturable.
Format conversion ought to work as long as the destination is renderable.

If all non-renderable formats result in an incomplete FBO - which I imagine
they do - then this ought to work.

I know Jason had code to support RGB9E5 and other non-renderable formats,
with shader fixups.

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

Re: [Mesa-dev] [PATCH] i965: Fix anisotropic filtering for mag filter

[Ian Romanick]

Ouch.  The frustrating thing is that anisotropic filtering is so
underspecified (intentionally) that it's hard to write tests that will
detect these kinds of problems and also work across multiple vendors. :(

Reviewed-by: Ian Romanick 

On 06/27/2017 10:37 AM, Rafael Antognolli wrote:
> From: Eero Tamminen 
> 
> Commit f8d69beed49c64f883bb8ffb28d4960306baf575 moving sampler
> handling to genxml messed up change done by commit
> 6a7c5257cac23cd9767aa4bc8fdab68925b11157.
> 
> This broke rendering in SynMark CSDof and TexFilterAniso tests.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101607
> 
> Thanks to Kevin, who spotted the actual typo!
> ---
>  src/mesa/drivers/dri/i965/genX_state_upload.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/genX_state_upload.c 
> b/src/mesa/drivers/dri/i965/genX_state_upload.c
> index d65b468..06b9cd5 100644
> --- a/src/mesa/drivers/dri/i965/genX_state_upload.c
> +++ b/src/mesa/drivers/dri/i965/genX_state_upload.c
> @@ -4551,7 +4551,7 @@ genX(update_sampler_state)(struct brw_context *brw,
> if (sampler->MaxAnisotropy > 1.0f) {
>if (samp_st.MinModeFilter == MAPFILTER_LINEAR)
>   samp_st.MinModeFilter = MAPFILTER_ANISOTROPIC;
> -  if (samp_st.MinModeFilter == MAPFILTER_LINEAR)
> +  if (samp_st.MagModeFilter == MAPFILTER_LINEAR)
>   samp_st.MagModeFilter = MAPFILTER_ANISOTROPIC;
>  
>if (sampler->MaxAnisotropy > 2.0f) {
> 

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

Re: [Mesa-dev] [PATCH mesa] build systems: uniformize git_sha1.h generation

[Matt Turner]

Right  you are. Thanks.

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

[Mesa-dev] [PATCH] i965: Fix anisotropic filtering for mag filter

[Rafael Antognolli]

From: Eero Tamminen 

Commit f8d69beed49c64f883bb8ffb28d4960306baf575 moving sampler
handling to genxml messed up change done by commit
6a7c5257cac23cd9767aa4bc8fdab68925b11157.

This broke rendering in SynMark CSDof and TexFilterAniso tests.

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

Thanks to Kevin, who spotted the actual typo!
---
 src/mesa/drivers/dri/i965/genX_state_upload.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/genX_state_upload.c 
b/src/mesa/drivers/dri/i965/genX_state_upload.c
index d65b468..06b9cd5 100644
--- a/src/mesa/drivers/dri/i965/genX_state_upload.c
+++ b/src/mesa/drivers/dri/i965/genX_state_upload.c
@@ -4551,7 +4551,7 @@ genX(update_sampler_state)(struct brw_context *brw,
if (sampler->MaxAnisotropy > 1.0f) {
   if (samp_st.MinModeFilter == MAPFILTER_LINEAR)
  samp_st.MinModeFilter = MAPFILTER_ANISOTROPIC;
-  if (samp_st.MinModeFilter == MAPFILTER_LINEAR)
+  if (samp_st.MagModeFilter == MAPFILTER_LINEAR)
  samp_st.MagModeFilter = MAPFILTER_ANISOTROPIC;
 
   if (sampler->MaxAnisotropy > 2.0f) {
-- 
2.9.4

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

Re: [Mesa-dev] [PATCH mesa] build systems: uniformize git_sha1.h generation

[Eric Engestrom]

On 27 June 2017 18:11:14 BST, Matt Turner  wrote:
> On Tue, Jun 27, 2017 at 5:47 AM, Eric Engestrom
>  wrote:
> > Signed-off-by: Eric Engestrom 
> > ---
> > Note: Autotools and SCons are tested, but Android isn't.
> > ---
> >  git_sha1_gen.sh  | 13 +
> >  src/Makefile.am  | 13 +
> >  src/SConscript   | 28
> 
> >  src/mesa/Android.libmesa_git_sha1.mk |  7 +--
> >  4 files changed, 23 insertions(+), 38 deletions(-)
> >  create mode 100755 git_sha1_gen.sh
> >
> > diff --git a/git_sha1_gen.sh b/git_sha1_gen.sh
> > new file mode 100755
> > index 00..9630067be0
> > --- /dev/null
> > +++ b/git_sha1_gen.sh
> > @@ -0,0 +1,13 @@
> > +#!/usr/bin/env bash
> > +set -eu
> > +
> > +# run git from the sources directory
> > +cd "$(dirname "${BASH_SOURCE[0]}")"
> > +
> > +# don't print anything if git fails
> > +if ! git_sha1=$(git rev-parse --short=10 HEAD)
> > +then
> > +  exit
> > +fi
> > +
> > +printf '#define MESA_GIT_SHA1 "git-%s"\n' "$git_sha1"
> > diff --git a/src/Makefile.am b/src/Makefile.am
> > index df912c442a..e49b3bd9cf 100644
> > --- a/src/Makefile.am
> > +++ b/src/Makefile.am
> > @@ -21,18 +21,7 @@
> >
> >  .PHONY: git_sha1.h.tmp
> >  git_sha1.h.tmp:
> > -   @# Don't assume that $(top_srcdir)/.git is a directory. It
> may be
> > -   @# a gitlink file if $(top_srcdir) is a submodule checkout
> or a linked
> > -   @# worktree.
> > -   @# If we are building from a release tarball copy the
> bundled header.
> > -   @touch git_sha1.h.tmp
> > -   @if test -e $(top_srcdir)/.git; then \
> > -   if which git > /dev/null; then \
> > -   printf '#define MESA_GIT_SHA1 "git-%s"\n' \
> > -   `git --git-dir=$(top_srcdir)/.git rev-parse
> --short=10 HEAD` \
> > -   > git_sha1.h.tmp ; \
> > -   fi \
> > -   fi
> 
> The purpose of the .tmp file is to prevent unnecessary rebuilds (and
> relinks) when the SHA1 doesn't change.
> 
> It looks like you're removing that?

It's still there, you just snipped the quote one line too soon :)

> > + @bash $(top_srcdir)/git_sha1_gen.sh > $@
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] radeonsi: move instance divisors into a constant buffer

[Nicolai Hähnle]

On 27.06.2017 18:59, Marek Olšák wrote:

On Tue, Jun 27, 2017 at 6:50 PM, Nicolai Hähnle  wrote:

On 27.06.2017 17:07, Marek Olšák wrote:


On Tue, Jun 27, 2017 at 9:22 AM, Nicolai Hähnle 
wrote:


On 27.06.2017 02:14, Marek Olšák wrote:



From: Marek Olšák 

Shader key size: 107 -> 47




Nice improvement.



Divisors of 0 and 1 are encoded in the shader key. Greater instance
divisors
are loaded from a constant buffer.

The shader code doing the division is huge. Is it something we need to
worry about? Does any app use instance divisors >= 2?




This reminds me of a certain LLVM improvement that I still need to clear.

I doubt instance divisors >= 2 are used. As a data point, Vulkan doesn't
support it as a feature at all, IIRC.

Can we get an optimized monotholic shader variant built for shaders that
have to fetch? This should help if anybody ever triggers this, because



We can't get optimized variants if we want to keep the shader key
small. If I put all instance divisors into key.opt, it would defeat
the effect of this patch.



What I meant is an optimized variant that still loads the instance divisors
from the constant buffer, but compiles the prolog and main parts together.
That way, LLVM can potentially schedule some of the division code before
waiting for the loads of other attributes that are per-vertex. That should
only require a single bit in the key.opt part.


Like this?

diff --git a/src/gallium/drivers/radeonsi/si_state_shaders.c
b/src/gallium/drivers/radeonsi/si_state_shaders.c
index 63cc746..af3f2a9 100644
--- a/src/gallium/drivers/radeonsi/si_state_shaders.c
+++ b/src/gallium/drivers/radeonsi/si_state_shaders.c
@@ -1192,6 +1192,11 @@ static void si_shader_selector_key_vs(struct
si_context *sctx,
 prolog_key->instance_divisor_is_fetched =
 sctx->vertex_elements->instance_divisor_is_fetched;

+   /* Prefer a monolithic shader to allow scheduling divisions around
+* VBO loads. */
+   if (prolog_key->instance_divisor_is_fetched)
+   key->opt.prefer_mono = 1;
+
 unsigned count = MIN2(vs->info.num_inputs,
   sctx->vertex_elements->count);
 memcpy(key->mono.vs_fix_fetch, sctx->vertex_elements->fix_fetch, 
count);


Yes, that looks good. R-b with this as well, thanks!



Marek




--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 01/13] intel/blorp: Assert levels and layers are in range

[Nanley Chery]

On Thu, Jun 22, 2017 at 10:32:42AM -0700, Jason Ekstrand wrote:
> On Thu, Jun 22, 2017 at 10:02 AM, Nanley Chery 
> wrote:
> 
> > On Thu, Jun 22, 2017 at 09:59:44AM -0700, Nanley Chery wrote:
> > > On Thu, Jun 22, 2017 at 09:55:50AM -0700, Nanley Chery wrote:
> > > > On Wed, Jun 21, 2017 at 06:07:29PM -0700, Jason Ekstrand wrote:
> > > > > On Wed, Jun 21, 2017 at 5:15 PM, Nanley Chery 
> > wrote:
> > > > >
> > > > > > v2 (Jason Ekstrand):
> > > > > > - Update commit title
> > > > > > - Check aux level and layer as well
> > > > > >
> > > > > > Signed-off-by: Nanley Chery 
> > > > > > Reviewed-by: Iago Toral Quiroga  (v1)
> > > > > > ---
> > > > > >  src/intel/blorp/blorp.c   | 7 +++
> > > > > >  src/intel/blorp/blorp_clear.c | 4 
> > > > > >  2 files changed, 7 insertions(+), 4 deletions(-)
> > > > > >
> > > > > > diff --git a/src/intel/blorp/blorp.c b/src/intel/blorp/blorp.c
> > > > > > index 9c88658e8a..7e30e20a59 100644
> > > > > > --- a/src/intel/blorp/blorp.c
> > > > > > +++ b/src/intel/blorp/blorp.c
> > > > > > @@ -66,6 +66,8 @@ brw_blorp_surface_info_init(struct
> > blorp_context *blorp,
> > > > > >  unsigned int level, unsigned int
> > layer,
> > > > > >  enum isl_format format, bool
> > is_render_target)
> > > > > >  {
> > > > > > +   assert(level < surf->surf->levels);
> > > > > > +
> > > > > > info->enabled = true;
> > > > > >
> > > > > > if (format == ISL_FORMAT_UNSUPPORTED)
> > > > > > @@ -90,6 +92,9 @@ brw_blorp_surface_info_init(struct
> > blorp_context *blorp,
> > > > > > if (info->aux_usage != ISL_AUX_USAGE_NONE) {
> > > > > >info->aux_surf = *surf->aux_surf;
> > > > > >info->aux_addr = surf->aux_addr;
> > > > > > +  assert(level < info->aux_surf.levels);
> > > > > > +  assert(layer < MAX2(info->aux_surf.logical_level0_px.depth
> > >>
> > > > > > level,
> > > > > > +  info->aux_surf.logical_level0_
> > px.array_len));
> > > > > > }
> > > > > >
> > > > > > info->clear_color = surf->clear_color;
> > > > > > @@ -106,6 +111,8 @@ brw_blorp_surface_info_init(struct
> > blorp_context
> > > > > > *blorp,
> > > > > > info->view.array_len = MAX2(info->surf.logical_
> > level0_px.depth,
> > > > > > info->surf.logical_level0_px.
> > array_len);
> > > > > >
> > > > > > +   assert(layer < info->view.array_len);
> > > > > >
> > > > >
> > > > > Might be more straightforward to move this assert to the top and
> > make it
> > > > > look like the aux assert.  I don't care too much though.
> > > > >
> > > > >
> > > >
> > > > I agree. Could I apply your rb if I instead put this under the first
> > > > assert in the function?
> > > >
> > > >assert(layer < MAX2(info->surf.logical_level0_px.depth >> level,
> > > >info->surf.logical_level0_px.array_len));
> > > >
> > >
> > > Whoops, info->surf is not yet defined there. It should be:
> > >  assert(layer < MAX2(surf->surf.logical_level0_px.depth >> level,
> > >  surf->surf.logical_level0_px.array_len));
> >
> > ... and I forgot that surf->surf is a pointer. Sorry,
> >
> > surf->surf->logical[...]
> >
> 
> No worries.  Yes, you can put my RB on it with that assuming you get it to
> compile. :-)
> 
> --Jason
> 
> 

Got it working and pushed.

> > > > > > +
> > > > > > if (!is_render_target &&
> > > > > > (info->surf.dim == ISL_SURF_DIM_3D ||
> > > > > >  info->surf.msaa_layout == ISL_MSAA_LAYOUT_ARRAY)) {
> > > > > > diff --git a/src/intel/blorp/blorp_clear.c
> > b/src/intel/blorp/blorp_clear.c
> > > > > > index efacadfebe..369e18726f 100644
> > > > > > --- a/src/intel/blorp/blorp_clear.c
> > > > > > +++ b/src/intel/blorp/blorp_clear.c
> > > > > > @@ -707,10 +707,6 @@ blorp_ccs_resolve(struct blorp_batch *batch,
> > > > > > struct blorp_params params;
> > > > > > blorp_params_init();
> > > > > >
> > > > > > -   /* Layered and mipmapped fast clear is only available from Gen8
> > > > > > onwards. */
> > > > > > -   assert(ISL_DEV_GEN(batch->blorp->isl_dev) >= 8 ||
> > > > > > -  (level == 0 && layer == 0));
> > > > > > -
> > > > > > brw_blorp_surface_info_init(batch->blorp, , surf,
> > > > > > level, layer, format, true);
> > > > > >
> > > > > > --
> > > > > > 2.13.1
> > > > > >
> > > > > > ___
> > > > > > mesa-dev mailing list
> > > > > > mesa-dev@lists.freedesktop.org
> > > > > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> > > > > >
> >
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 01/12] genxml: Silence about a billion unused parameter warnings

[Ian Romanick]

On 06/27/2017 10:04 AM, Dylan Baker wrote:
> Quoting Ian Romanick (2017-06-26 16:22:34)
>> From: Ian Romanick 
>>
>> v2: Use textwrap.dedent to make the source line a lot shorter.
>> Shortening (?) the line was requested by Jason.
>>
>> Signed-off-by: Ian Romanick 
>> ---
>>  src/intel/genxml/gen_pack_header.py | 9 +++--
>>  1 file changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/intel/genxml/gen_pack_header.py 
>> b/src/intel/genxml/gen_pack_header.py
>> index fefbc9a..a96a232 100644
>> --- a/src/intel/genxml/gen_pack_header.py
>> +++ b/src/intel/genxml/gen_pack_header.py
>> @@ -8,6 +8,7 @@ import xml.parsers.expat
>>  import re
>>  import sys
>>  import copy
>> +import textwrap
>>  
>>  license =  """/*
>>   * Copyright (C) 2016 Intel Corporation
>> @@ -578,8 +579,12 @@ class Parser(object):
>>  
>>  def emit_pack_function(self, name, group):
>>  name = self.gen_prefix(name)
>> -print("static inline void\n%s_pack(__gen_user_data *data, void * 
>> restrict dst,\n%sconst struct %s * restrict values)\n{" %
>> -  (name, ' ' * (len(name) + 6), name))
>> +print(textwrap.dedent("""\
>> +static inline void
>> +%s_pack(__attribute__((unused)) __gen_user_data *data,
>> +%s__attribute__((unused)) void * restrict dst,
>> +%s__attribute__((unused)) const struct %s * restrict values)
>> +{""") % (name, ' ' * (len(name) + 6), ' ' * (len(name) + 6), 
>> name))
> 
> There are a couple of things you could do here to simplify this a bit.
> One is that textwrap.dedent will remove the same number of spaces from every
> line (the shortest, so in this case the length removed will be equal to the
> number of spaces before "static"), so you don't need to do the + 6 to the
> len(name), you could just put those in the string. The second is that using
> str.format() will save duplicating the inputs:
> 
> print(textwrap.dedent("""\
> static inline void
> {0}_pack(__attribute__((unused)) __gen_user_data *data,
>   {1}__attribute__((unused)) void * restrict dst,
>   {1}__attribute__((unused)) const struct {0} * restrict values)
> {""").format(name, ' ' * (len(name
> 
> Either way,
> Reviewed-by: Dylan Baker 

Right. #obvious. :) I'll make that change.

>>  
>>  (dwords, length) = group.collect_dwords_and_length()
>>  if length:
>> -- 
>> 2.9.4
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev



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

Re: [Mesa-dev] [PATCH shader-db] Drop Orbital Explorer shader.

[Chad Versace]

On Mon 26 Jun 2017, Eero Tamminen wrote:
> Hi,
> 
> On 22.06.2017 23:14, Chad Versace wrote:
> > On Thu 22 Jun 2017, Chad Versace wrote:
> > > On Thu 22 Jun 2017, Kenneth Graunke wrote:
> > > > The author eventually emailed me and said that he considers it a
> > > > "finished experiment" and said the rendering method (geometry shader
> > > > based approach) is inefficient, and he intends to fully rewrite it
> > > > someday.
> > > 
> > > A total tangent... The author and I had lunch last week, where he
> > > introduced me to a great mathy Android puzzle game. The game's puzzles
> > > require you to make geometric constructions with a straight-edge and
> > > compass in the minimum number of moves, à la Euclid.
> > > 
> > > Euclidea 
> > > 
> > 
> > Oh yeah, I almost forgot.
> > Reviewed-by: Chad Versace 
> > 
> > This geometry shader of doom doesn't belong in shader-db.
> 
> Should there be a separate repository for "doom" shaders, which can
> be used to occasionally test valid, but corner-case code?
> 
> With e.g. WebGL, drivers need to be robust against all kinds of weird
> shaders, so collecting odd ones somewhere might not be a bad idea.

I agree. It may be useful to maintain a repo of stress-test shaders.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFT PATCH 2/2] nv20: enable ARB_texture_border_clamp support

[Ian Romanick]

On 06/27/2017 02:59 AM, Timothy Arceri wrote:
> Just curious. Can this extension be added to NV04 and NV10? As those are
> the only drivers that don't currently support it.
> 
> I have cards I could test those with, but don't have an NV20.

I just sent out an updated series that I tested on NV20.  Thanks for
reminding me. :)

I *think* NV10 can do this, but the implementation would be... painful.
NV10 (and on) supports texture borders... that extra one pixel of pixels
on each side that's outside the usual [0,1]x[0,1] sampling range.  I
believe this extension could be supported by creating every texture with
a border and filling the border with the GL border color.

> On 09/09/16 10:56, Ilia Mirkin wrote:
> 
>> Signed-off-by: Ilia Mirkin 
>> ---
>>
>> This was tested on a NV25-on-NV34 situation. Should be tested on real
>> hardware
>> since my test environment relies on accurate emulation in the hw.
>>
>>   src/mesa/drivers/dri/nouveau/nv20_context.c   |  1 +
>>   src/mesa/drivers/dri/nouveau/nv20_state_tex.c | 29
>> ++-
>>   2 files changed, 29 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/mesa/drivers/dri/nouveau/nv20_context.c
>> b/src/mesa/drivers/dri/nouveau/nv20_context.c
>> index ec638c0..6940b4d 100644
>> --- a/src/mesa/drivers/dri/nouveau/nv20_context.c
>> +++ b/src/mesa/drivers/dri/nouveau/nv20_context.c
>> @@ -456,6 +456,7 @@ nv20_context_create(struct nouveau_screen *screen,
>> gl_api api,
>>   if (!nouveau_context_init(ctx, api, screen, visual, share_ctx))
>>   goto fail;
>>   +ctx->Extensions.ARB_texture_border_clamp = true;
>>   ctx->Extensions.ARB_texture_env_crossbar = true;
>>   ctx->Extensions.ARB_texture_env_combine = true;
>>   ctx->Extensions.ARB_texture_env_dot3 = true;
>> diff --git a/src/mesa/drivers/dri/nouveau/nv20_state_tex.c
>> b/src/mesa/drivers/dri/nouveau/nv20_state_tex.c
>> index b0a4c9f..ef1799a 100644
>> --- a/src/mesa/drivers/dri/nouveau/nv20_state_tex.c
>> +++ b/src/mesa/drivers/dri/nouveau/nv20_state_tex.c
>> @@ -165,7 +165,8 @@ nv20_emit_tex_obj(struct gl_context *ctx, int emit)
>>   struct nouveau_surface *s;
>>   struct gl_texture_image *ti;
>>   const struct gl_sampler_object *sa;
>> -uint32_t tx_format, tx_filter, tx_wrap, tx_enable;
>> +uint8_t r, g, b, a;
>> +uint32_t tx_format, tx_filter, tx_wrap, tx_bcolor, tx_enable;
>> PUSH_RESET(push, BUFCTX_TEX(i));
>>   @@ -201,6 +202,29 @@ nv20_emit_tex_obj(struct gl_context *ctx, int
>> emit)
>>   | nvgl_filter_mode(sa->MinFilter) << 16
>>   | 2 << 12;
>>   +r = FLOAT_TO_UBYTE(sa->BorderColor.f[0]);
>> +g = FLOAT_TO_UBYTE(sa->BorderColor.f[1]);
>> +b = FLOAT_TO_UBYTE(sa->BorderColor.f[2]);
>> +a = FLOAT_TO_UBYTE(sa->BorderColor.f[3]);
>> +switch (ti->_BaseFormat) {
>> +case GL_LUMINANCE:
>> +a = 0xff;
>> +/* fallthrough */
>> +case GL_LUMINANCE_ALPHA:
>> +g = b = r;
>> +break;
>> +case GL_RGB:
>> +a = 0xff;
>> +break;
>> +case GL_INTENSITY:
>> +g = b = a = r;
>> +break;
>> +case GL_ALPHA:
>> +r = g = b = 0;
>> +break;
>> +}
>> +tx_bcolor = b << 0 | g << 8 | r << 16 | a << 24;
>> +
>>   tx_enable = NV20_3D_TEX_ENABLE_ENABLE
>>   | log2i(sa->MaxAnisotropy) << 4;
>>   @@ -249,6 +273,9 @@ nv20_emit_tex_obj(struct gl_context *ctx, int emit)
>>   BEGIN_NV04(push, NV20_3D(TEX_FILTER(i)), 1);
>>   PUSH_DATA (push, tx_filter);
>>   +BEGIN_NV04(push, NV20_3D(TEX_BORDER_COLOR(i)), 1);
>> +PUSH_DATA (push, tx_bcolor);
>> +
>>   BEGIN_NV04(push, NV20_3D(TEX_ENABLE(i)), 1);
>>   PUSH_DATA (push, tx_enable);
>>   
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 

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

Re: [Mesa-dev] [PATCH mesa] build systems: uniformize git_sha1.h generation

[Matt Turner]

On Tue, Jun 27, 2017 at 5:47 AM, Eric Engestrom
 wrote:
> Signed-off-by: Eric Engestrom 
> ---
> Note: Autotools and SCons are tested, but Android isn't.
> ---
>  git_sha1_gen.sh  | 13 +
>  src/Makefile.am  | 13 +
>  src/SConscript   | 28 
>  src/mesa/Android.libmesa_git_sha1.mk |  7 +--
>  4 files changed, 23 insertions(+), 38 deletions(-)
>  create mode 100755 git_sha1_gen.sh
>
> diff --git a/git_sha1_gen.sh b/git_sha1_gen.sh
> new file mode 100755
> index 00..9630067be0
> --- /dev/null
> +++ b/git_sha1_gen.sh
> @@ -0,0 +1,13 @@
> +#!/usr/bin/env bash
> +set -eu
> +
> +# run git from the sources directory
> +cd "$(dirname "${BASH_SOURCE[0]}")"
> +
> +# don't print anything if git fails
> +if ! git_sha1=$(git rev-parse --short=10 HEAD)
> +then
> +  exit
> +fi
> +
> +printf '#define MESA_GIT_SHA1 "git-%s"\n' "$git_sha1"
> diff --git a/src/Makefile.am b/src/Makefile.am
> index df912c442a..e49b3bd9cf 100644
> --- a/src/Makefile.am
> +++ b/src/Makefile.am
> @@ -21,18 +21,7 @@
>
>  .PHONY: git_sha1.h.tmp
>  git_sha1.h.tmp:
> -   @# Don't assume that $(top_srcdir)/.git is a directory. It may be
> -   @# a gitlink file if $(top_srcdir) is a submodule checkout or a linked
> -   @# worktree.
> -   @# If we are building from a release tarball copy the bundled header.
> -   @touch git_sha1.h.tmp
> -   @if test -e $(top_srcdir)/.git; then \
> -   if which git > /dev/null; then \
> -   printf '#define MESA_GIT_SHA1 "git-%s"\n' \
> -   `git --git-dir=$(top_srcdir)/.git rev-parse 
> --short=10 HEAD` \
> -   > git_sha1.h.tmp ; \
> -   fi \
> -   fi

The purpose of the .tmp file is to prevent unnecessary rebuilds (and
relinks) when the SHA1 doesn't change.

It looks like you're removing that?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH mesa] Fix khrplatform.h not installed if EGL is disabled.

[Eric Engestrom]

On Tuesday, 2017-06-27 19:02:22 +0300, Andres Gomez wrote:
> Sound like a good inclusion for -stable (?)

It's extremely unlikely to break anything, so sure, go ahead :)

> 
> On Mon, 2017-06-12 at 12:00 +0100, Eric Engestrom wrote:
> > From: Eric Le Bihan 
> > 
> > KHR/khrplatform.h is required by the EGL, GLES and VG headers, but is
> > only installed if Mesa3d is compiled with EGL support.
> > 
> > This patch installs this header file unconditionally.
> > 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77240
> > Signed-off-by: Eric Le Bihan 
> > ---
> >  src/egl/Makefile.am  | 3 ---
> >  src/mapi/Makefile.am | 3 +++
> >  2 files changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/src/egl/Makefile.am b/src/egl/Makefile.am
> > index 14fd77f14a..81090387b5 100644
> > --- a/src/egl/Makefile.am
> > +++ b/src/egl/Makefile.am
> > @@ -163,9 +163,6 @@ pkgconfigdir = $(libdir)/pkgconfig
> >  
> >  pkgconfig_DATA = main/egl.pc
> >  
> > -khrdir = $(includedir)/KHR
> > -khr_HEADERS = $(top_srcdir)/include/KHR/khrplatform.h
> > -
> >  egldir = $(includedir)/EGL
> >  egl_HEADERS = \
> > $(top_srcdir)/include/EGL/eglext.h \
> > diff --git a/src/mapi/Makefile.am b/src/mapi/Makefile.am
> > index e5477364ce..9ff70a14fd 100644
> > --- a/src/mapi/Makefile.am
> > +++ b/src/mapi/Makefile.am
> > @@ -241,3 +241,6 @@ es2api/glapi_mapi_tmp.h: glapi/gen/gl_and_es_API.xml 
> > $(glapi_gen_mapi_deps)
> > $(srcdir)/glapi/gen/gl_and_es_API.xml > $@
> >  
> >  include $(top_srcdir)/install-lib-links.mk
> > +
> > +khrdir = $(includedir)/KHR
> > +khr_HEADERS = $(top_srcdir)/include/KHR/khrplatform.h
> -- 
> Br,
> 
> Andres
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/3] nv20: Fix GL_CLAMP

[Ian Romanick]

From: Ian Romanick 

v2: Force T and R wrap modes to GL_CLAMP_TO_EDGE for 1D textures.
This fixes a regression in tex1d-2dborder.  The test uses a 1D texture
but it provides S and T texture coordinates.  Since the T wrap mode
would (correctly) be set to GL_CLAMP, the texture would gradually
blend (incorrectly) with the border color.

I also tried setting NV20_3D_TEX_FORMAT_DIMS_1D instead of
NV20_3D_TEX_FORMAT_DIMS_2D for 1D textures, but that did not help.

It is possible that the same problem exists for 2D textures with the
R-wrap mode, but I don't think there are any piglit tests for that.

No test changes on NV20 (10de:0201).

Signed-off-by: Ian Romanick 
---
 src/mesa/drivers/dri/nouveau/nouveau_gldefs.h | 19 +++
 src/mesa/drivers/dri/nouveau/nv20_state_tex.c | 16 +---
 2 files changed, 32 insertions(+), 3 deletions(-)

diff --git a/src/mesa/drivers/dri/nouveau/nouveau_gldefs.h 
b/src/mesa/drivers/dri/nouveau/nouveau_gldefs.h
index 46ec14e..7df04c1 100644
--- a/src/mesa/drivers/dri/nouveau/nouveau_gldefs.h
+++ b/src/mesa/drivers/dri/nouveau/nouveau_gldefs.h
@@ -239,6 +239,25 @@ nvgl_wrap_mode(unsigned wrap)
 }
 
 static inline unsigned
+nvgl_wrap_mode_nv20(unsigned wrap)
+{
+   switch (wrap) {
+   case GL_REPEAT:
+   return 0x1;
+   case GL_MIRRORED_REPEAT:
+   return 0x2;
+   case GL_CLAMP:
+   return 0x5;
+   case GL_CLAMP_TO_EDGE:
+   return 0x3;
+   case GL_CLAMP_TO_BORDER:
+   return 0x4;
+   default:
+   unreachable("Bad GL texture wrap mode");
+   }
+}
+
+static inline unsigned
 nvgl_filter_mode(unsigned filter)
 {
switch (filter) {
diff --git a/src/mesa/drivers/dri/nouveau/nv20_state_tex.c 
b/src/mesa/drivers/dri/nouveau/nv20_state_tex.c
index b0a4c9f..7972069 100644
--- a/src/mesa/drivers/dri/nouveau/nv20_state_tex.c
+++ b/src/mesa/drivers/dri/nouveau/nv20_state_tex.c
@@ -193,9 +193,19 @@ nv20_emit_tex_obj(struct gl_context *ctx, int emit)
| NV20_3D_TEX_FORMAT_NO_BORDER
| 1 << 16;
 
-   tx_wrap = nvgl_wrap_mode(sa->WrapR) << 16
-   | nvgl_wrap_mode(sa->WrapT) << 8
-   | nvgl_wrap_mode(sa->WrapS) << 0;
+   switch (t->Target) {
+   case GL_TEXTURE_1D:
+   tx_wrap = NV20_3D_TEX_WRAP_R_CLAMP_TO_EDGE
+   | NV20_3D_TEX_WRAP_T_CLAMP_TO_EDGE
+   | nvgl_wrap_mode_nv20(sa->WrapS) << 0;
+   break;
+
+   default:
+   tx_wrap = nvgl_wrap_mode_nv20(sa->WrapR) << 16
+   | nvgl_wrap_mode_nv20(sa->WrapT) << 8
+   | nvgl_wrap_mode_nv20(sa->WrapS) << 0;
+   break;
+   }
 
tx_filter = nvgl_filter_mode(sa->MagFilter) << 24
| nvgl_filter_mode(sa->MinFilter) << 16
-- 
2.9.4

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

[Mesa-dev] [PATCH 3/3] nv20: Enable ARB_texture_border_clamp

[Ian Romanick]

From: Ilia Mirkin 

Fixes quite a few 'texwrap [12]d border color only' tests on NV20
(10de:0201).  All told, 40 more tests pass.

Signed-off-by: Ilia Mirkin 
---
 src/mesa/drivers/dri/nouveau/nv20_state_tex.c | 29 ++-
 1 file changed, 28 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/nouveau/nv20_state_tex.c 
b/src/mesa/drivers/dri/nouveau/nv20_state_tex.c
index 7972069..72df814 100644
--- a/src/mesa/drivers/dri/nouveau/nv20_state_tex.c
+++ b/src/mesa/drivers/dri/nouveau/nv20_state_tex.c
@@ -165,7 +165,8 @@ nv20_emit_tex_obj(struct gl_context *ctx, int emit)
struct nouveau_surface *s;
struct gl_texture_image *ti;
const struct gl_sampler_object *sa;
-   uint32_t tx_format, tx_filter, tx_wrap, tx_enable;
+   uint8_t r, g, b, a;
+   uint32_t tx_format, tx_filter, tx_wrap, tx_bcolor, tx_enable;
 
PUSH_RESET(push, BUFCTX_TEX(i));
 
@@ -211,6 +212,29 @@ nv20_emit_tex_obj(struct gl_context *ctx, int emit)
| nvgl_filter_mode(sa->MinFilter) << 16
| 2 << 12;
 
+   r = FLOAT_TO_UBYTE(sa->BorderColor.f[0]);
+   g = FLOAT_TO_UBYTE(sa->BorderColor.f[1]);
+   b = FLOAT_TO_UBYTE(sa->BorderColor.f[2]);
+   a = FLOAT_TO_UBYTE(sa->BorderColor.f[3]);
+   switch (ti->_BaseFormat) {
+   case GL_LUMINANCE:
+   a = 0xff;
+   /* fallthrough */
+   case GL_LUMINANCE_ALPHA:
+   g = b = r;
+   break;
+   case GL_RGB:
+   a = 0xff;
+   break;
+   case GL_INTENSITY:
+   g = b = a = r;
+   break;
+   case GL_ALPHA:
+   r = g = b = 0;
+   break;
+   }
+   tx_bcolor = b << 0 | g << 8 | r << 16 | a << 24;
+
tx_enable = NV20_3D_TEX_ENABLE_ENABLE
| log2i(sa->MaxAnisotropy) << 4;
 
@@ -259,6 +283,9 @@ nv20_emit_tex_obj(struct gl_context *ctx, int emit)
BEGIN_NV04(push, NV20_3D(TEX_FILTER(i)), 1);
PUSH_DATA (push, tx_filter);
 
+   BEGIN_NV04(push, NV20_3D(TEX_BORDER_COLOR(i)), 1);
+   PUSH_DATA (push, tx_bcolor);
+
BEGIN_NV04(push, NV20_3D(TEX_ENABLE(i)), 1);
PUSH_DATA (push, tx_enable);
 
-- 
2.9.4

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

[Mesa-dev] [PATCH 1/3] mesa: GL_TEXTURE_BORDER_COLOR exists in OpenGL 1.0, so don't depend on GL_ARB_texture_border_clamp

[Ian Romanick]

From: Ian Romanick 

On NV20 (and probably also on earlier NV GPUs that lack
GL_ARB_texture_border_clamp) fixes the following piglit tests:

gl-1.0-beginend-coverage gltexparameter[if]{v,}
push-pop-texture-state
texwrap 1d
texwrap 1d proj
texwrap 2d proj
texwrap formats

All told, 49 more tests pass on NV20 (10de:0201).

No changes on Intel CI run or RV250 (1002:4c66).

Signed-off-by: Ian Romanick 
---
 src/mesa/main/texparam.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/src/mesa/main/texparam.c b/src/mesa/main/texparam.c
index 3c110de..857faf6 100644
--- a/src/mesa/main/texparam.c
+++ b/src/mesa/main/texparam.c
@@ -736,8 +736,16 @@ set_tex_parameterf(struct gl_context *ctx,
   break;
 
case GL_TEXTURE_BORDER_COLOR:
+  /* Border color exists in desktop OpenGL since 1.0 for GL_CLAMP.  In
+   * OpenGL ES 2.0+, it only exists in when GL_OES_texture_border_clamp is
+   * enabled.  It is never available in OpenGL ES 1.x.
+   *
+   * FIXME: Every driver that supports GLES2 has this extension.  Elide
+   * the check?
+   */
   if (ctx->API == API_OPENGLES ||
-  !ctx->Extensions.ARB_texture_border_clamp)
+  (ctx->API == API_OPENGLES2 &&
+   !ctx->Extensions.ARB_texture_border_clamp))
  goto invalid_pname;
 
   if (!_mesa_target_allows_setting_sampler_parameters(texObj->Target))
-- 
2.9.4

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

Re: [Mesa-dev] [PATCH] winsys/radeon: only call pb_slabs_reclaim when slabs are actually used

[Marek Olšák]

Reviewed-by: Marek Olšák 

Marek

On Tue, Jun 27, 2017 at 6:19 PM, Nicolai Hähnle  wrote:
> From: Nicolai Hähnle 
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100242
> Fixes: fb827c055cb1 ("winsys/radeon: enable buffer allocation from slabs")
> Cc: mesa-sta...@lists.freedesktop.org
> ---
>  src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c 
> b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
> index 9bbf1b3..2700c6f 100644
> --- a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
> +++ b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
> @@ -1020,21 +1020,22 @@ no_slab:
>
>  bo = radeon_bo(pb_cache_reclaim_buffer(>bo_cache, size, alignment,
> usage, pb_cache_bucket));
>  if (bo)
>  return >base;
>
>  bo = radeon_create_bo(ws, size, alignment, usage, domain, flags,
>pb_cache_bucket);
>  if (!bo) {
>  /* Clear the cache and try again. */
> -pb_slabs_reclaim(>bo_slabs);
> +if (ws->info.has_virtual_memory)
> +pb_slabs_reclaim(>bo_slabs);
>  pb_cache_release_all_buffers(>bo_cache);
>  bo = radeon_create_bo(ws, size, alignment, usage, domain, flags,
>pb_cache_bucket);
>  if (!bo)
>  return NULL;
>  }
>
>  bo->u.real.use_reusable_pool = true;
>
>  mtx_lock(>bo_handles_mutex);
> --
> 2.9.3
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 01/12] genxml: Silence about a billion unused parameter warnings

[Dylan Baker]

Quoting Ian Romanick (2017-06-26 16:22:34)
> From: Ian Romanick 
> 
> v2: Use textwrap.dedent to make the source line a lot shorter.
> Shortening (?) the line was requested by Jason.
> 
> Signed-off-by: Ian Romanick 
> ---
>  src/intel/genxml/gen_pack_header.py | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/src/intel/genxml/gen_pack_header.py 
> b/src/intel/genxml/gen_pack_header.py
> index fefbc9a..a96a232 100644
> --- a/src/intel/genxml/gen_pack_header.py
> +++ b/src/intel/genxml/gen_pack_header.py
> @@ -8,6 +8,7 @@ import xml.parsers.expat
>  import re
>  import sys
>  import copy
> +import textwrap
>  
>  license =  """/*
>   * Copyright (C) 2016 Intel Corporation
> @@ -578,8 +579,12 @@ class Parser(object):
>  
>  def emit_pack_function(self, name, group):
>  name = self.gen_prefix(name)
> -print("static inline void\n%s_pack(__gen_user_data *data, void * 
> restrict dst,\n%sconst struct %s * restrict values)\n{" %
> -  (name, ' ' * (len(name) + 6), name))
> +print(textwrap.dedent("""\
> +static inline void
> +%s_pack(__attribute__((unused)) __gen_user_data *data,
> +%s__attribute__((unused)) void * restrict dst,
> +%s__attribute__((unused)) const struct %s * restrict values)
> +{""") % (name, ' ' * (len(name) + 6), ' ' * (len(name) + 6), 
> name))

There are a couple of things you could do here to simplify this a bit.
One is that textwrap.dedent will remove the same number of spaces from every
line (the shortest, so in this case the length removed will be equal to the
number of spaces before "static"), so you don't need to do the + 6 to the
len(name), you could just put those in the string. The second is that using
str.format() will save duplicating the inputs:

print(textwrap.dedent("""\
static inline void
{0}_pack(__attribute__((unused)) __gen_user_data *data,
  {1}__attribute__((unused)) void * restrict dst,
  {1}__attribute__((unused)) const struct {0} * restrict values)
{""").format(name, ' ' * (len(name

Either way,
Reviewed-by: Dylan Baker 

>  
>  (dwords, length) = group.collect_dwords_and_length()
>  if length:
> -- 
> 2.9.4
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

Re: [Mesa-dev] [PATCH 2/2] radeonsi: move instance divisors into a constant buffer

[Marek Olšák]

On Tue, Jun 27, 2017 at 6:50 PM, Nicolai Hähnle  wrote:
> On 27.06.2017 17:07, Marek Olšák wrote:
>>
>> On Tue, Jun 27, 2017 at 9:22 AM, Nicolai Hähnle 
>> wrote:
>>>
>>> On 27.06.2017 02:14, Marek Olšák wrote:


 From: Marek Olšák 

 Shader key size: 107 -> 47
>>>
>>>
>>>
>>> Nice improvement.
>>>
>>>
 Divisors of 0 and 1 are encoded in the shader key. Greater instance
 divisors
 are loaded from a constant buffer.

 The shader code doing the division is huge. Is it something we need to
 worry about? Does any app use instance divisors >= 2?
>>>
>>>
>>>
>>> This reminds me of a certain LLVM improvement that I still need to clear.
>>>
>>> I doubt instance divisors >= 2 are used. As a data point, Vulkan doesn't
>>> support it as a feature at all, IIRC.
>>>
>>> Can we get an optimized monotholic shader variant built for shaders that
>>> have to fetch? This should help if anybody ever triggers this, because
>>
>>
>> We can't get optimized variants if we want to keep the shader key
>> small. If I put all instance divisors into key.opt, it would defeat
>> the effect of this patch.
>
>
> What I meant is an optimized variant that still loads the instance divisors
> from the constant buffer, but compiles the prolog and main parts together.
> That way, LLVM can potentially schedule some of the division code before
> waiting for the loads of other attributes that are per-vertex. That should
> only require a single bit in the key.opt part.

Like this?

diff --git a/src/gallium/drivers/radeonsi/si_state_shaders.c
b/src/gallium/drivers/radeonsi/si_state_shaders.c
index 63cc746..af3f2a9 100644
--- a/src/gallium/drivers/radeonsi/si_state_shaders.c
+++ b/src/gallium/drivers/radeonsi/si_state_shaders.c
@@ -1192,6 +1192,11 @@ static void si_shader_selector_key_vs(struct
si_context *sctx,
prolog_key->instance_divisor_is_fetched =
sctx->vertex_elements->instance_divisor_is_fetched;

+   /* Prefer a monolithic shader to allow scheduling divisions around
+* VBO loads. */
+   if (prolog_key->instance_divisor_is_fetched)
+   key->opt.prefer_mono = 1;
+
unsigned count = MIN2(vs->info.num_inputs,
  sctx->vertex_elements->count);
memcpy(key->mono.vs_fix_fetch, sctx->vertex_elements->fix_fetch, count);

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

[Mesa-dev] [PATCH 2/2] radeonsi: set COMPUTE_DISPATCH_INITIATOR.ORDER_MODE = 1

[Marek Olšák]

From: Marek Olšák 

---
 src/gallium/drivers/radeonsi/si_compute.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeonsi/si_compute.c 
b/src/gallium/drivers/radeonsi/si_compute.c
index 91a6a40..fba02fa 100644
--- a/src/gallium/drivers/radeonsi/si_compute.c
+++ b/src/gallium/drivers/radeonsi/si_compute.c
@@ -713,21 +713,24 @@ static void si_emit_dispatch_packets(struct si_context 
*sctx,
radeon_set_sh_reg(cs, R_00B854_COMPUTE_RESOURCE_LIMITS,
  S_00B854_SIMD_DEST_CNTL(waves_per_threadgroup % 4 == 
0));
 
radeon_set_sh_reg_seq(cs, R_00B81C_COMPUTE_NUM_THREAD_X, 3);
radeon_emit(cs, S_00B81C_NUM_THREAD_FULL(info->block[0]));
radeon_emit(cs, S_00B820_NUM_THREAD_FULL(info->block[1]));
radeon_emit(cs, S_00B824_NUM_THREAD_FULL(info->block[2]));
 
unsigned dispatch_initiator =
S_00B800_COMPUTE_SHADER_EN(1) |
-   S_00B800_FORCE_START_AT_000(1);
+   S_00B800_FORCE_START_AT_000(1) |
+   /* If the KMD allows it (there is a KMD hw register for it),
+* allow launching waves out-of-order. (same as Vulkan) */
+   S_00B800_ORDER_MODE(sctx->b.chip_class >= CIK);
 
if (info->indirect) {
uint64_t base_va = r600_resource(info->indirect)->gpu_address;
 
radeon_add_to_buffer_list(>b, >b.gfx,
 (struct r600_resource *)info->indirect,
 RADEON_USAGE_READ, RADEON_PRIO_DRAW_INDIRECT);
 
radeon_emit(cs, PKT3(PKT3_SET_BASE, 2, 0) |
PKT3_SHADER_TYPE_S(1));
-- 
2.7.4

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

[Mesa-dev] [PATCH 1/2] radeonsi: use the DISPATCH packets to force COMPUTE_START_X/Y/Z = 0

[Marek Olšák]

From: Marek Olšák 

---
 src/gallium/drivers/radeonsi/si_compute.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_compute.c 
b/src/gallium/drivers/radeonsi/si_compute.c
index 65f3261..91a6a40 100644
--- a/src/gallium/drivers/radeonsi/si_compute.c
+++ b/src/gallium/drivers/radeonsi/si_compute.c
@@ -258,25 +258,20 @@ static void si_set_global_binding(
va = util_cpu_to_le64(va);
memcpy(handles[i], , sizeof(va));
}
 }
 
 static void si_initialize_compute(struct si_context *sctx)
 {
struct radeon_winsys_cs *cs = sctx->b.gfx.cs;
uint64_t bc_va;
 
-   radeon_set_sh_reg_seq(cs, R_00B810_COMPUTE_START_X, 3);
-   radeon_emit(cs, 0);
-   radeon_emit(cs, 0);
-   radeon_emit(cs, 0);
-
radeon_set_sh_reg_seq(cs, R_00B858_COMPUTE_STATIC_THREAD_MGMT_SE0, 2);
/* R_00B858_COMPUTE_STATIC_THREAD_MGMT_SE0 / SE1 */
radeon_emit(cs, S_00B858_SH0_CU_EN(0x) | 
S_00B858_SH1_CU_EN(0x));
radeon_emit(cs, S_00B85C_SH0_CU_EN(0x) | 
S_00B85C_SH1_CU_EN(0x));
 
if (sctx->b.chip_class >= CIK) {
/* Also set R_00B858_COMPUTE_STATIC_THREAD_MGMT_SE2 / SE3 */
radeon_set_sh_reg_seq(cs,
 R_00B864_COMPUTE_STATIC_THREAD_MGMT_SE2, 
2);
radeon_emit(cs, S_00B864_SH0_CU_EN(0x) |
@@ -716,44 +711,48 @@ static void si_emit_dispatch_packets(struct si_context 
*sctx,
DIV_ROUND_UP(info->block[0] * info->block[1] * info->block[2], 
64);
 
radeon_set_sh_reg(cs, R_00B854_COMPUTE_RESOURCE_LIMITS,
  S_00B854_SIMD_DEST_CNTL(waves_per_threadgroup % 4 == 
0));
 
radeon_set_sh_reg_seq(cs, R_00B81C_COMPUTE_NUM_THREAD_X, 3);
radeon_emit(cs, S_00B81C_NUM_THREAD_FULL(info->block[0]));
radeon_emit(cs, S_00B820_NUM_THREAD_FULL(info->block[1]));
radeon_emit(cs, S_00B824_NUM_THREAD_FULL(info->block[2]));
 
+   unsigned dispatch_initiator =
+   S_00B800_COMPUTE_SHADER_EN(1) |
+   S_00B800_FORCE_START_AT_000(1);
+
if (info->indirect) {
uint64_t base_va = r600_resource(info->indirect)->gpu_address;
 
radeon_add_to_buffer_list(>b, >b.gfx,
 (struct r600_resource *)info->indirect,
 RADEON_USAGE_READ, RADEON_PRIO_DRAW_INDIRECT);
 
radeon_emit(cs, PKT3(PKT3_SET_BASE, 2, 0) |
PKT3_SHADER_TYPE_S(1));
radeon_emit(cs, 1);
radeon_emit(cs, base_va);
radeon_emit(cs, base_va >> 32);
 
radeon_emit(cs, PKT3(PKT3_DISPATCH_INDIRECT, 1, 
render_cond_bit) |
PKT3_SHADER_TYPE_S(1));
radeon_emit(cs, info->indirect_offset);
-   radeon_emit(cs, 1);
+   radeon_emit(cs, dispatch_initiator);
} else {
radeon_emit(cs, PKT3(PKT3_DISPATCH_DIRECT, 3, render_cond_bit) |
PKT3_SHADER_TYPE_S(1));
radeon_emit(cs, info->grid[0]);
radeon_emit(cs, info->grid[1]);
radeon_emit(cs, info->grid[2]);
-   radeon_emit(cs, 1);
+   radeon_emit(cs, dispatch_initiator);
}
 }
 
 
 static void si_launch_grid(
struct pipe_context *ctx, const struct pipe_grid_info *info)
 {
struct si_context *sctx = (struct si_context*)ctx;
struct si_compute *program = sctx->cs_shader_state.program;
const amd_kernel_code_t *code_object =
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH 3/3] radeonsi: use #pragma pack to pack si_shader_key

[Nicolai Hähnle]

On 27.06.2017 17:02, Marek Olšák wrote:

On Tue, Jun 27, 2017 at 10:02 AM, Nicolai Hähnle  wrote:

On 27.06.2017 00:15, Marek Olšák wrote:


On Thu, Jun 22, 2017 at 9:19 AM, Nicolai Hähnle 
wrote:


On 20.06.2017 20:00, Marek Olšák wrote:



From: Marek Olšák 

sizeof(struct si_shader_key):
 Before reverting the 2 commits: 120 bytes
 After reverting the 2 commits: 128 bytes
 With #pragma pack: 107 bytes

I'm not sure if memcmp with a byte-aligned size is a good idea.




Does this have a measurable impact? The code is nicer to read with the
structure after the patches, but I'm not sure it's worth the risk of
getting
misaligned data somewhere.



It decreases the time spent in si_update_shaders by 6% when going from
128 bytes to 106 for the shader key.

What do you mean by the risk?



If we end up accidentally misaligning a member, that could cause a
performance hit. But those 6% improvement does seem worth it. I do think
Emil's suggestion of adding the attribute directly to the structures is a
good idea. With that, the patch is


I can't add the attributes inside the structures, because every
structure member would have to have the attribute, and that would be
too much noise in the code. There are MSVC and gcc attributes. gcc
supports both kinds. MSVC attributes are the global #pragmas. gcc
attributes are per-member or on structure types. If the attribute is
on a structure type, it only specifies alignment for the whole
structure, not individual members.


My bad, I thought there was an attribute that controls the packing of 
all members. If there isn't, just go ahead with the patch as-is.


Cheers,
Nicolai



Marek




--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] radeonsi: move instance divisors into a constant buffer

[Nicolai Hähnle]

On 27.06.2017 17:07, Marek Olšák wrote:

On Tue, Jun 27, 2017 at 9:22 AM, Nicolai Hähnle  wrote:

On 27.06.2017 02:14, Marek Olšák wrote:


From: Marek Olšák 

Shader key size: 107 -> 47



Nice improvement.



Divisors of 0 and 1 are encoded in the shader key. Greater instance
divisors
are loaded from a constant buffer.

The shader code doing the division is huge. Is it something we need to
worry about? Does any app use instance divisors >= 2?



This reminds me of a certain LLVM improvement that I still need to clear.

I doubt instance divisors >= 2 are used. As a data point, Vulkan doesn't
support it as a feature at all, IIRC.

Can we get an optimized monotholic shader variant built for shaders that
have to fetch? This should help if anybody ever triggers this, because


We can't get optimized variants if we want to keep the shader key
small. If I put all instance divisors into key.opt, it would defeat
the effect of this patch.


What I meant is an optimized variant that still loads the instance 
divisors from the constant buffer, but compiles the prolog and main 
parts together. That way, LLVM can potentially schedule some of the 
division code before waiting for the loads of other attributes that are 
per-vertex. That should only require a single bit in the key.opt part.


Cheers,
Nicolai




Marek




--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] winsys/radeon: only call pb_slabs_reclaim when slabs are actually used

[Samuel Pitoiset]

Good catch!

Reviewed-by: Samuel Pitoiset 

On 06/27/2017 06:19 PM, Nicolai Hähnle wrote:

From: Nicolai Hähnle 

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100242
Fixes: fb827c055cb1 ("winsys/radeon: enable buffer allocation from slabs")
Cc: mesa-sta...@lists.freedesktop.org
---
  src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c 
b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
index 9bbf1b3..2700c6f 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
@@ -1020,21 +1020,22 @@ no_slab:
  
  bo = radeon_bo(pb_cache_reclaim_buffer(>bo_cache, size, alignment,

 usage, pb_cache_bucket));
  if (bo)
  return >base;
  
  bo = radeon_create_bo(ws, size, alignment, usage, domain, flags,

pb_cache_bucket);
  if (!bo) {
  /* Clear the cache and try again. */
-pb_slabs_reclaim(>bo_slabs);
+if (ws->info.has_virtual_memory)
+pb_slabs_reclaim(>bo_slabs);
  pb_cache_release_all_buffers(>bo_cache);
  bo = radeon_create_bo(ws, size, alignment, usage, domain, flags,
pb_cache_bucket);
  if (!bo)
  return NULL;
  }
  
  bo->u.real.use_reusable_pool = true;
  
  mtx_lock(>bo_handles_mutex);



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

Re: [Mesa-dev] [PATCH 1/2] svga: clamp device line width to at least 1 to fix HWv8 line stippling

[Andres Gomez]

It looks like we could want these 2 into -stable (?)

On Thu, 2017-06-15 at 11:41 -0600, Brian Paul wrote:
> The line stipple fallback code for virtual HW version 8 didn't work.
> 
> With HW version 8, we were getting zero when querying the max line
> widths (AA and non-AA).  This means we were setting the draw module's
> wide line threshold to zero.  This caused the wide line stage to always
> get enabled.  That caused the line stipple module to fall because the
> wide line stage was clobbering the rasterization state with a state
> object setting the line stipple pattern to 0x.
> 
> Now the wide_lines variable in draw's validate_pipeline() will not
> be incorrectly set.
> 
> Also improve debug output.
> 
> See VMware bug 1895811.
> ---
>  src/gallium/drivers/svga/svga_screen.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/src/gallium/drivers/svga/svga_screen.c 
> b/src/gallium/drivers/svga/svga_screen.c
> index 202f54f..3aa9945 100644
> --- a/src/gallium/drivers/svga/svga_screen.c
> +++ b/src/gallium/drivers/svga/svga_screen.c
> @@ -1142,18 +1142,18 @@ svga_screen_create(struct svga_winsys_screen *sws)
>get_bool_cap(sws, SVGA3D_DEVCAP_LINE_STIPPLE, FALSE);
>  
> svgascreen->maxLineWidth =
> -  get_float_cap(sws, SVGA3D_DEVCAP_MAX_LINE_WIDTH, 1.0f);
> +  MAX2(1.0, get_float_cap(sws, SVGA3D_DEVCAP_MAX_LINE_WIDTH, 1.0f));
>  
> svgascreen->maxLineWidthAA =
> -  get_float_cap(sws, SVGA3D_DEVCAP_MAX_AA_LINE_WIDTH, 1.0f);
> +  MAX2(1.0, get_float_cap(sws, SVGA3D_DEVCAP_MAX_AA_LINE_WIDTH, 1.0f));
>  
> if (0) {
>debug_printf("svga: haveProvokingVertex %u\n",
> svgascreen->haveProvokingVertex);
>debug_printf("svga: haveLineStip %u  "
> -   "haveLineSmooth %u  maxLineWidth %f\n",
> +   "haveLineSmooth %u  maxLineWidth %.2f  maxLineWidthAA 
> %.2f\n",
> svgascreen->haveLineStipple, svgascreen->haveLineSmooth,
> -   svgascreen->maxLineWidth);
> +   svgascreen->maxLineWidth, svgascreen->maxLineWidthAA);
>debug_printf("svga: maxPointSize %g\n", svgascreen->maxPointSize);
>debug_printf("svga: msaa samples mask: 0x%x\n", 
> svgascreen->ms_samples);
> }
-- 
Br,

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

[Mesa-dev] [PATCH] winsys/radeon: only call pb_slabs_reclaim when slabs are actually used

[Nicolai Hähnle]

From: Nicolai Hähnle 

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100242
Fixes: fb827c055cb1 ("winsys/radeon: enable buffer allocation from slabs")
Cc: mesa-sta...@lists.freedesktop.org
---
 src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c 
b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
index 9bbf1b3..2700c6f 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
@@ -1020,21 +1020,22 @@ no_slab:
 
 bo = radeon_bo(pb_cache_reclaim_buffer(>bo_cache, size, alignment,
usage, pb_cache_bucket));
 if (bo)
 return >base;
 
 bo = radeon_create_bo(ws, size, alignment, usage, domain, flags,
   pb_cache_bucket);
 if (!bo) {
 /* Clear the cache and try again. */
-pb_slabs_reclaim(>bo_slabs);
+if (ws->info.has_virtual_memory)
+pb_slabs_reclaim(>bo_slabs);
 pb_cache_release_all_buffers(>bo_cache);
 bo = radeon_create_bo(ws, size, alignment, usage, domain, flags,
   pb_cache_bucket);
 if (!bo)
 return NULL;
 }
 
 bo->u.real.use_reusable_pool = true;
 
 mtx_lock(>bo_handles_mutex);
-- 
2.9.3

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

Re: [Mesa-dev] [PATCH mesa] Fix khrplatform.h not installed if EGL is disabled.

[Andres Gomez]

Sound like a good inclusion for -stable (?)

On Mon, 2017-06-12 at 12:00 +0100, Eric Engestrom wrote:
> From: Eric Le Bihan 
> 
> KHR/khrplatform.h is required by the EGL, GLES and VG headers, but is
> only installed if Mesa3d is compiled with EGL support.
> 
> This patch installs this header file unconditionally.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77240
> Signed-off-by: Eric Le Bihan 
> ---
>  src/egl/Makefile.am  | 3 ---
>  src/mapi/Makefile.am | 3 +++
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/src/egl/Makefile.am b/src/egl/Makefile.am
> index 14fd77f14a..81090387b5 100644
> --- a/src/egl/Makefile.am
> +++ b/src/egl/Makefile.am
> @@ -163,9 +163,6 @@ pkgconfigdir = $(libdir)/pkgconfig
>  
>  pkgconfig_DATA = main/egl.pc
>  
> -khrdir = $(includedir)/KHR
> -khr_HEADERS = $(top_srcdir)/include/KHR/khrplatform.h
> -
>  egldir = $(includedir)/EGL
>  egl_HEADERS = \
>   $(top_srcdir)/include/EGL/eglext.h \
> diff --git a/src/mapi/Makefile.am b/src/mapi/Makefile.am
> index e5477364ce..9ff70a14fd 100644
> --- a/src/mapi/Makefile.am
> +++ b/src/mapi/Makefile.am
> @@ -241,3 +241,6 @@ es2api/glapi_mapi_tmp.h: glapi/gen/gl_and_es_API.xml 
> $(glapi_gen_mapi_deps)
>   $(srcdir)/glapi/gen/gl_and_es_API.xml > $@
>  
>  include $(top_srcdir)/install-lib-links.mk
> +
> +khrdir = $(includedir)/KHR
> +khr_HEADERS = $(top_srcdir)/include/KHR/khrplatform.h
-- 
Br,

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

[Mesa-dev] [RFC PATCH 2/2] ac/nir: Don't treat each element as a vec4 in compute shared memory

[Alex Smith]

Currently every element in shared memory (including individual elements
of an array) are treated as a vec4. For example, the following:

shared uint array[1024];

gets treated as an array of 1024 vec4s with only the first component
ever used.

This can be highly wasteful of LDS space. We have a shader which only
really requires ~24KB of shared memory, but since scalars are being
padded to vec4, it actually ends up needing 96KB. This is more than
the hardware supports, and leads to an LLVM compilation failure.

Therefore, instead pack data in LDS according to the std430 layout.

Signed-off-by: Alex Smith 
---
RFC since I'm not sure whether this is the best approach to handle this,
and there may be something I've missed.

No regressions seen in Mad Max or Dawn of War 3, which both have a few
shaders which use shared memory. Also no regressions in the CTS
'dEQP-VK.compute.*' tests.

I've also checked over various test cases using arrays/structs/etc. in
shared memory, and as far as I can tell the generated LLVM/GCN code is
correct.
---
 src/amd/common/ac_nir_to_llvm.c | 55 ++---
 1 file changed, 29 insertions(+), 26 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 468ce4d..a48bb3b 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -397,7 +397,7 @@ static LLVMValueRef get_shared_memory_ptr(struct 
nir_to_llvm_context *ctx,
LLVMValueRef ptr;
int addr_space;
 
-   offset = LLVMConstInt(ctx->i32, idx * 16, false);
+   offset = LLVMConstInt(ctx->i32, idx, false);
 
ptr = ctx->shared_memory;
ptr = LLVMBuildGEP(ctx->builder, ptr, , 1, "");
@@ -2404,7 +2404,7 @@ static LLVMValueRef visit_load_ubo_buffer(struct 
nir_to_llvm_context *ctx,
 
 static void
 radv_get_deref_offset(struct nir_to_llvm_context *ctx, nir_deref_var *deref,
- bool vs_in, unsigned *vertex_index_out,
+ bool vs_in, bool compute_shared, unsigned 
*vertex_index_out,
  LLVMValueRef *vertex_index_ref,
  unsigned *const_out, LLVMValueRef *indir_out)
 {
@@ -2445,7 +2445,14 @@ radv_get_deref_offset(struct nir_to_llvm_context *ctx, 
nir_deref_var *deref,
if (tail->deref_type == nir_deref_type_array) {
nir_deref_array *deref_array = nir_deref_as_array(tail);
LLVMValueRef index, stride, local_offset;
-   unsigned size = glsl_count_attribute_slots(tail->type, 
vs_in);
+
+   /* For compute LDS, data is packed rather than treating
+* each individual element as a vec4. The returned
+* index is used to index into an i32 array so divide
+* by 4.
+*/
+   unsigned size = compute_shared ? 
glsl_get_std430_array_stride(tail->type, false) / 4
+  : 
glsl_count_attribute_slots(tail->type, vs_in);
 
const_offset += size * deref_array->base_offset;
if (deref_array->deref_array_type == 
nir_deref_array_type_direct)
@@ -2465,7 +2472,11 @@ radv_get_deref_offset(struct nir_to_llvm_context *ctx, 
nir_deref_var *deref,
 
for (unsigned i = 0; i < deref_struct->index; i++) {
const struct glsl_type *ft = 
glsl_get_struct_field(parent_type, i);
-   const_offset += glsl_count_attribute_slots(ft, 
vs_in);
+
+   /* Same as above. */
+   unsigned size = compute_shared ? 
glsl_get_std430_array_stride(ft, false) / 4
+  : 
glsl_count_attribute_slots(tail->type, vs_in);
+   const_offset += size;
}
} else
unreachable("unsupported deref type");
@@ -2641,7 +2652,7 @@ load_tcs_input(struct nir_to_llvm_context *ctx,
const bool is_compact = instr->variables[0]->var->data.compact;
param = 
shader_io_get_unique_index(instr->variables[0]->var->data.location);
radv_get_deref_offset(ctx, instr->variables[0],
- false, NULL, per_vertex ? _index : NULL,
+ false, false, NULL, per_vertex ? _index : 
NULL,
  _index, _index);
 
stride = unpack_param(ctx, ctx->tcs_in_layout, 13, 8);
@@ -2673,7 +2684,7 @@ load_tcs_output(struct nir_to_llvm_context *ctx,
const bool is_compact = instr->variables[0]->var->data.compact;
param = 
shader_io_get_unique_index(instr->variables[0]->var->data.location);
radv_get_deref_offset(ctx, instr->variables[0],
- false, NULL, per_vertex ? _index : 

[Mesa-dev] [RFC PATCH 1/2] nir: Add a C wrapper for glsl_type::std430_array_stride

[Alex Smith]

Signed-off-by: Alex Smith 
---
 src/compiler/nir_types.cpp | 7 +++
 src/compiler/nir_types.h   | 3 +++
 2 files changed, 10 insertions(+)

diff --git a/src/compiler/nir_types.cpp b/src/compiler/nir_types.cpp
index 25980b9..554130c 100644
--- a/src/compiler/nir_types.cpp
+++ b/src/compiler/nir_types.cpp
@@ -115,6 +115,13 @@ glsl_count_attribute_slots(const struct glsl_type *type,
return type->count_attribute_slots(is_vertex_input);
 }
 
+unsigned
+glsl_get_std430_array_stride(const struct glsl_type *type,
+ bool row_major)
+{
+   return type->std430_array_stride(row_major);
+}
+
 const char *
 glsl_get_struct_elem_name(const struct glsl_type *type, unsigned index)
 {
diff --git a/src/compiler/nir_types.h b/src/compiler/nir_types.h
index 0c52bb9..687bc0c 100644
--- a/src/compiler/nir_types.h
+++ b/src/compiler/nir_types.h
@@ -72,6 +72,9 @@ unsigned glsl_get_aoa_size(const struct glsl_type *type);
 unsigned glsl_count_attribute_slots(const struct glsl_type *type,
 bool is_vertex_input);
 
+unsigned glsl_get_std430_array_stride(const struct glsl_type *type,
+  bool row_major);
+
 const char *glsl_get_struct_elem_name(const struct glsl_type *type,
   unsigned index);
 
-- 
2.9.4

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

Re: [Mesa-dev] [PATCHv2] etnaviv: Add support for ETC2 texture compression

[Christian Gmeiner]

2017-06-27 17:39 GMT+02:00 Wladimir J. van der Laan :
> On Tue, Jun 27, 2017 at 05:31:52PM +0200, Wladimir J. van der Laan wrote:
>
>> > sure if we should advertise the broken formats (on gpus with HALTI0).
>
> FWIW, I did check on both GC2000 and GC3000, so HALTI0 should be ok.
>

Great - could you try piglit's oes_compressed_etc2_texture-miptree_gles3?

greets
--
Christian Gmeiner, MSc

https://www.youtube.com/user/AloryOFFICIAL
https://soundcloud.com/christian-gmeiner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Mesa-stable] [PATCH] nv50, nvc0: remove IDX from bufctx immediately, to avoid conflicts with clear

[Ilia Mirkin]

Indeed you are quite right. My apologies for the incorrect tag. My
internal timer said "it's been a while", but I didn't check if it was
in the last release.

On Tue, Jun 27, 2017 at 11:34 AM, Andres Gomez  wrote:
> Ilia, this patch tries to fix 61d8f3387d which, in turn, tried to fix
> 330d0607e.
>
> None of them did it for 17.1 so I suppose we should leave this out,
> then.
>
> Let me know if you think otherwise.
>
> On Sat, 2017-06-24 at 13:24 -0400, Ilia Mirkin wrote:
>> The idxbuf could linger, and when a clear happened, which also uses the
>> 3d bufctx, we could get an error trying to access it.
>>
>> This fixes spurious crashes/errors in CTS tests.
>>
>> Fixes: 61d8f3387d ("nv50,nvc0: clear index buffer bufctx bin 
>> unconditionally")
>> Signed-off-by: Ilia Mirkin 
>> Cc: mesa-sta...@lists.freedesktop.org
>> ---
>>  src/gallium/drivers/nouveau/nv50/nv50_vbo.c | 9 +
>>  src/gallium/drivers/nouveau/nvc0/nvc0_vbo.c | 9 +
>>  2 files changed, 10 insertions(+), 8 deletions(-)
>>
>> diff --git a/src/gallium/drivers/nouveau/nv50/nv50_vbo.c 
>> b/src/gallium/drivers/nouveau/nv50/nv50_vbo.c
>> index ac7d8267861..ed041121a26 100644
>> --- a/src/gallium/drivers/nouveau/nv50/nv50_vbo.c
>> +++ b/src/gallium/drivers/nouveau/nv50/nv50_vbo.c
>> @@ -770,7 +770,6 @@ nv50_draw_vbo(struct pipe_context *pipe, const struct 
>> pipe_draw_info *info)
>> bool tex_dirty = false;
>> int s;
>>
>> -   nouveau_bufctx_reset(nv50->bufctx_3d, NV50_BIND_3D_INDEX);
>> if (info->index_size && !info->has_user_indices)
>>BCTX_REFN(nv50->bufctx_3d, 3D_INDEX, 
>> nv04_resource(info->index.resource), RD);
>>
>> @@ -838,9 +837,7 @@ nv50_draw_vbo(struct pipe_context *pipe, const struct 
>> pipe_draw_info *info)
>>
>> if (nv50->vbo_fifo) {
>>nv50_push_vbo(nv50, info);
>> -  push->kick_notify = nv50_default_kick_notify;
>> -  nouveau_pushbuf_bufctx(push, NULL);
>> -  return;
>> +  goto cleanup;
>> }
>>
>> if (nv50->state.instance_base != info->start_instance) {
>> @@ -894,9 +891,13 @@ nv50_draw_vbo(struct pipe_context *pipe, const struct 
>> pipe_draw_info *info)
>> info->mode, info->start, info->count,
>> info->instance_count);
>> }
>> +
>> +cleanup:
>> push->kick_notify = nv50_default_kick_notify;
>>
>> nv50_release_user_vbufs(nv50);
>>
>> nouveau_pushbuf_bufctx(push, NULL);
>> +
>> +   nouveau_bufctx_reset(nv50->bufctx_3d, NV50_BIND_3D_INDEX);
>>  }
>> diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_vbo.c 
>> b/src/gallium/drivers/nouveau/nvc0/nvc0_vbo.c
>> index 2856b4c6096..a5671ca09ac 100644
>> --- a/src/gallium/drivers/nouveau/nvc0/nvc0_vbo.c
>> +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_vbo.c
>> @@ -921,7 +921,6 @@ nvc0_draw_vbo(struct pipe_context *pipe, const struct 
>> pipe_draw_info *info)
>> struct nvc0_screen *screen = nvc0->screen;
>> int s;
>>
>> -   nouveau_bufctx_reset(nvc0->bufctx_3d, NVC0_BIND_3D_IDX);
>> nouveau_bufctx_reset(nvc0->bufctx_3d, NVC0_BIND_3D_BINDLESS);
>>
>> /* NOTE: caller must ensure that (min_index + index_bias) is >= 0 */
>> @@ -1040,9 +1039,7 @@ nvc0_draw_vbo(struct pipe_context *pipe, const struct 
>> pipe_draw_info *info)
>>
>> if (nvc0->state.vbo_mode) {
>>nvc0_push_vbo(nvc0, info);
>> -  push->kick_notify = nvc0_default_kick_notify;
>> -  nouveau_pushbuf_bufctx(push, NULL);
>> -  return;
>> +  goto cleanup;
>> }
>>
>> /* space for base instance, flush, and prim restart */
>> @@ -1089,9 +1086,13 @@ nvc0_draw_vbo(struct pipe_context *pipe, const struct 
>> pipe_draw_info *info)
>> info->mode, info->start, info->count,
>> info->instance_count);
>> }
>> +
>> +cleanup:
>> push->kick_notify = nvc0_default_kick_notify;
>>
>> nvc0_release_user_vbufs(nvc0);
>>
>> nouveau_pushbuf_bufctx(push, NULL);
>> +
>> +   nouveau_bufctx_reset(nvc0->bufctx_3d, NVC0_BIND_3D_IDX);
>>  }
> --
> Br,
>
> Andres
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCHv2] etnaviv: Add support for ETC2 texture compression

[Wladimir J. van der Laan]

On Tue, Jun 27, 2017 at 05:31:52PM +0200, Wladimir J. van der Laan wrote:

> > sure if we should advertise the broken formats (on gpus with HALTI0).

FWIW, I did check on both GC2000 and GC3000, so HALTI0 should be ok.

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

Re: [Mesa-dev] [Mesa-stable] [PATCH] nv50, nvc0: remove IDX from bufctx immediately, to avoid conflicts with clear

[Andres Gomez]

Ilia, this patch tries to fix 61d8f3387d which, in turn, tried to fix
330d0607e.

None of them did it for 17.1 so I suppose we should leave this out,
then.

Let me know if you think otherwise.

On Sat, 2017-06-24 at 13:24 -0400, Ilia Mirkin wrote:
> The idxbuf could linger, and when a clear happened, which also uses the
> 3d bufctx, we could get an error trying to access it.
> 
> This fixes spurious crashes/errors in CTS tests.
> 
> Fixes: 61d8f3387d ("nv50,nvc0: clear index buffer bufctx bin unconditionally")
> Signed-off-by: Ilia Mirkin 
> Cc: mesa-sta...@lists.freedesktop.org
> ---
>  src/gallium/drivers/nouveau/nv50/nv50_vbo.c | 9 +
>  src/gallium/drivers/nouveau/nvc0/nvc0_vbo.c | 9 +
>  2 files changed, 10 insertions(+), 8 deletions(-)
> 
> diff --git a/src/gallium/drivers/nouveau/nv50/nv50_vbo.c 
> b/src/gallium/drivers/nouveau/nv50/nv50_vbo.c
> index ac7d8267861..ed041121a26 100644
> --- a/src/gallium/drivers/nouveau/nv50/nv50_vbo.c
> +++ b/src/gallium/drivers/nouveau/nv50/nv50_vbo.c
> @@ -770,7 +770,6 @@ nv50_draw_vbo(struct pipe_context *pipe, const struct 
> pipe_draw_info *info)
> bool tex_dirty = false;
> int s;
>  
> -   nouveau_bufctx_reset(nv50->bufctx_3d, NV50_BIND_3D_INDEX);
> if (info->index_size && !info->has_user_indices)
>BCTX_REFN(nv50->bufctx_3d, 3D_INDEX, 
> nv04_resource(info->index.resource), RD);
>  
> @@ -838,9 +837,7 @@ nv50_draw_vbo(struct pipe_context *pipe, const struct 
> pipe_draw_info *info)
>  
> if (nv50->vbo_fifo) {
>nv50_push_vbo(nv50, info);
> -  push->kick_notify = nv50_default_kick_notify;
> -  nouveau_pushbuf_bufctx(push, NULL);
> -  return;
> +  goto cleanup;
> }
>  
> if (nv50->state.instance_base != info->start_instance) {
> @@ -894,9 +891,13 @@ nv50_draw_vbo(struct pipe_context *pipe, const struct 
> pipe_draw_info *info)
> info->mode, info->start, info->count,
> info->instance_count);
> }
> +
> +cleanup:
> push->kick_notify = nv50_default_kick_notify;
>  
> nv50_release_user_vbufs(nv50);
>  
> nouveau_pushbuf_bufctx(push, NULL);
> +
> +   nouveau_bufctx_reset(nv50->bufctx_3d, NV50_BIND_3D_INDEX);
>  }
> diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_vbo.c 
> b/src/gallium/drivers/nouveau/nvc0/nvc0_vbo.c
> index 2856b4c6096..a5671ca09ac 100644
> --- a/src/gallium/drivers/nouveau/nvc0/nvc0_vbo.c
> +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_vbo.c
> @@ -921,7 +921,6 @@ nvc0_draw_vbo(struct pipe_context *pipe, const struct 
> pipe_draw_info *info)
> struct nvc0_screen *screen = nvc0->screen;
> int s;
>  
> -   nouveau_bufctx_reset(nvc0->bufctx_3d, NVC0_BIND_3D_IDX);
> nouveau_bufctx_reset(nvc0->bufctx_3d, NVC0_BIND_3D_BINDLESS);
>  
> /* NOTE: caller must ensure that (min_index + index_bias) is >= 0 */
> @@ -1040,9 +1039,7 @@ nvc0_draw_vbo(struct pipe_context *pipe, const struct 
> pipe_draw_info *info)
>  
> if (nvc0->state.vbo_mode) {
>nvc0_push_vbo(nvc0, info);
> -  push->kick_notify = nvc0_default_kick_notify;
> -  nouveau_pushbuf_bufctx(push, NULL);
> -  return;
> +  goto cleanup;
> }
>  
> /* space for base instance, flush, and prim restart */
> @@ -1089,9 +1086,13 @@ nvc0_draw_vbo(struct pipe_context *pipe, const struct 
> pipe_draw_info *info)
> info->mode, info->start, info->count,
> info->instance_count);
> }
> +
> +cleanup:
> push->kick_notify = nvc0_default_kick_notify;
>  
> nvc0_release_user_vbufs(nvc0);
>  
> nouveau_pushbuf_bufctx(push, NULL);
> +
> +   nouveau_bufctx_reset(nvc0->bufctx_3d, NVC0_BIND_3D_IDX);
>  }
-- 
Br,

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

Re: [Mesa-dev] [PATCHv2] etnaviv: Add support for ETC2 texture compression

[Wladimir J. van der Laan]

> I can confirm that 11 bit stuff works on the GC2000 . I used piglit's
> oes_compressed_etc2_texture-miptree_gles3 for verification.
> How have you tested these formats?

I rendered the example images from
https://github.com/Ericsson/ETCPACK/tree/master/testing/testvectors_correct/pkm,
which displayed fine, both the 11 and 8 bit variants.

Haven't checked pixel-for-pixel though.

Wladimir

> 
> For instance I get the following fails:
> debian@cubox:~/ac_mesa$
> /home/debian/piglit/bin/oes_compressed_etc2_texture-miptree_gles3 rgb8
> -auto -fbo
> Probe color at (16,0)
>   Left: 0.53 0.20 0.00 1.00
>   Right: 0.87 0.60 0.33 1.00
> PIGLIT: {"result": "fail" }
> debian@cubox:~/ac_mesa$
> /home/debian/piglit/bin/oes_compressed_etc2_texture-miptree_gles3
> rgb8-punchthrough-alpha1 -auto -fbo
> Probe color at (6,0)
>   Left: 0.73 0.40 0.00 1.00
>   Right: 0.13 0.07 0.00 1.00
> PIGLIT: {"result": "fail" }
> 
> With that fact I think we need to find out what is broken with the non
> 11 bit formats on GC2000 and if everything works on your platform. I
> am not
> sure if we should advertise the broken formats (on gpus with HALTI0).
> 
> greets
> --
> Christian Gmeiner, MSc
> 
> https://www.youtube.com/user/AloryOFFICIAL
> https://soundcloud.com/christian-gmeiner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCHv2] etnaviv: Add support for ETC2 texture compression

[Christian Gmeiner]

2017-06-27 14:54 GMT+02:00 Wladimir J. van der Laan :
> Add support for ETC2 compressed textures in the etnaviv driver.
>
> One step closer towards GL ES 3 support.
>
> For now, treat SRGB and RGB formats the same. It looks like these are
> distinguished using a different bit in sampler state, and not part of
> the format, but I have not yet been able to confirm this for sure.
> ---
>  src/gallium/drivers/etnaviv/etnaviv_format.c | 11 +++
>  1 file changed, 11 insertions(+)
>
> This is rebased to the new version of the extended texture patchset.
>
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_format.c 
> b/src/gallium/drivers/etnaviv/etnaviv_format.c
> index c7c032a..cb67060 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_format.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_format.c
> @@ -234,6 +234,17 @@ static struct etna_format formats[PIPE_FORMAT_COUNT] = {
> _T(DXT3_RGBA, DXT2_DXT3, SWIZ(X, Y, Z, W), NONE),
> _T(DXT5_RGBA, DXT4_DXT5, SWIZ(X, Y, Z, W), NONE),
>
> +   _T(ETC2_RGB8,   EXT_NONE | EXT_FORMAT,  
> SWIZ(X, Y, Z, W), NONE), /* Extd. format NONE doubles as ETC2_RGB8 */
> +   _T(ETC2_SRGB8,  EXT_NONE | EXT_FORMAT,  
> SWIZ(X, Y, Z, W), NONE),
> +   _T(ETC2_RGB8A1, EXT_RGB8_PUNCHTHROUGH_ALPHA1_ETC2 | EXT_FORMAT, 
> SWIZ(X, Y, Z, W), NONE),
> +   _T(ETC2_SRGB8A1,EXT_RGB8_PUNCHTHROUGH_ALPHA1_ETC2 | EXT_FORMAT, 
> SWIZ(X, Y, Z, W), NONE),
> +   _T(ETC2_RGBA8,  EXT_RGBA8_ETC2_EAC | EXT_FORMAT,
> SWIZ(X, Y, Z, W), NONE),
> +   _T(ETC2_SRGBA8, EXT_RGBA8_ETC2_EAC | EXT_FORMAT,
> SWIZ(X, Y, Z, W), NONE),
> +   _T(ETC2_R11_UNORM,  EXT_R11_EAC | EXT_FORMAT,   
> SWIZ(X, Y, Z, W), NONE),
> +   _T(ETC2_R11_SNORM,  EXT_SIGNED_R11_EAC | EXT_FORMAT,
> SWIZ(X, Y, Z, W), NONE),
> +   _T(ETC2_RG11_UNORM, EXT_RG11_EAC | EXT_FORMAT,  
> SWIZ(X, Y, Z, W), NONE),
> +   _T(ETC2_RG11_SNORM, EXT_SIGNED_RG11_EAC | EXT_FORMAT,   
> SWIZ(X, Y, Z, W), NONE),
> +

I can confirm that 11 bit stuff works on the GC2000 . I used piglit's
oes_compressed_etc2_texture-miptree_gles3 for verification.
How have you tested these formats?

For instance I get the following fails:
debian@cubox:~/ac_mesa$
/home/debian/piglit/bin/oes_compressed_etc2_texture-miptree_gles3 rgb8
-auto -fbo
Probe color at (16,0)
  Left: 0.53 0.20 0.00 1.00
  Right: 0.87 0.60 0.33 1.00
PIGLIT: {"result": "fail" }
debian@cubox:~/ac_mesa$
/home/debian/piglit/bin/oes_compressed_etc2_texture-miptree_gles3
rgb8-punchthrough-alpha1 -auto -fbo
Probe color at (6,0)
  Left: 0.73 0.40 0.00 1.00
  Right: 0.13 0.07 0.00 1.00
PIGLIT: {"result": "fail" }

With that fact I think we need to find out what is broken with the non
11 bit formats on GC2000 and if everything works on your platform. I
am not
sure if we should advertise the broken formats (on gpus with HALTI0).

greets
--
Christian Gmeiner, MSc

https://www.youtube.com/user/AloryOFFICIAL
https://soundcloud.com/christian-gmeiner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 11/11] etnaviv: advertise supported dmabuf modifiers

[Lucas Stach]

Am Dienstag, den 27.06.2017, 17:10 +0200 schrieb Wladimir J. van der
Laan:
> On Fri, Jun 23, 2017 at 05:50:28PM +0200, Lucas Stach wrote:
> > Simply advertise all supported modifiers, independent of the format.
> > Special formats, like compressed, which don't support all those modifiers
> > are already culled from the dmabuf format list, as we don't support
> > the render target binding for them.
> 
> The SPLIT formats are only supported on hardware with multiple pixel pipes.
> 
> Should this be checked, or is it harmless to advertize them unconditionally?

I _think_ it is harmless to advertise them.

Actually we support texturing from a SPLIT tiled surface just fine (by
resolving to a sampler compatible tiling), it's just a problem for
rendering. All use-cases I have seen so far have some sort of modifier
negotiation for the render buffers, so even if we advertise the SPLIT
formats as supported, they won't be chosen on single pipe hardware.

But now that I think thing about it, it should be fairly easy to not
advertise them in the first place by moving them to the end of the array
and breaking out of the loop early on single pipe hardware. I'll make
this change for the next revision.

Regards,
Lucas
> 
> Reviewed-by: Wladimir J. van der Laan
> 
> > Signed-off-by: Lucas Stach 
> > ---
> >  src/gallium/drivers/etnaviv/etnaviv_screen.c | 36 
> > 
> >  1 file changed, 36 insertions(+)
> > 
> > diff --git a/src/gallium/drivers/etnaviv/etnaviv_screen.c 
> > b/src/gallium/drivers/etnaviv/etnaviv_screen.c
> > index b70897b6e41f..571f0b3d42d8 100644
> > --- a/src/gallium/drivers/etnaviv/etnaviv_screen.c
> > +++ b/src/gallium/drivers/etnaviv/etnaviv_screen.c
> > @@ -45,6 +45,8 @@
> >  
> >  #include "state_tracker/drm_driver.h"
> >  
> > +#include 
> > +
> >  #define ETNA_DRM_VERSION(major, minor) ((major) << 16 | (minor))
> >  #define ETNA_DRM_VERSION_FENCE_FD  ETNA_DRM_VERSION(1, 1)
> >  
> > @@ -545,6 +547,39 @@ etna_screen_is_format_supported(struct pipe_screen 
> > *pscreen,
> > return usage == allowed;
> >  }
> >  
> > +const uint64_t supported_modifiers[] = {
> > +   DRM_FORMAT_MOD_LINEAR,
> > +   DRM_FORMAT_MOD_VIVANTE_SPLIT_TILED,
> > +   DRM_FORMAT_MOD_VIVANTE_SPLIT_SUPER_TILED,
> > +   DRM_FORMAT_MOD_VIVANTE_TILED,
> > +   DRM_FORMAT_MOD_VIVANTE_SUPER_TILED,
> > +};
> > +
> > +static void
> > +etna_screen_query_dmabuf_modifiers(struct pipe_screen *screen,
> > +   enum pipe_format format, int max,
> > +   uint64_t *modifiers,
> > +   unsigned int *external_only, int *count)
> > +{
> > +   int i;
> > +
> > +   if (!max) {
> > +  *count = ARRAY_SIZE(supported_modifiers);
> > +  return;
> > +   }
> > +
> > +   if (max > ARRAY_SIZE(supported_modifiers))
> > +  max = ARRAY_SIZE(supported_modifiers);
> > +
> > +   for (i = 0; i < max; i++) {
> > +  modifiers[i] = supported_modifiers[i];
> > +  if (external_only)
> > + external_only[i] = 0;
> > +   }
> > +
> > +   *count = i;
> > +}
> > +
> >  static boolean
> >  etna_get_specs(struct etna_screen *screen)
> >  {
> > @@ -839,6 +874,7 @@ etna_screen_create(struct etna_device *dev, struct 
> > etna_gpu *gpu,
> > pscreen->get_timestamp = etna_screen_get_timestamp;
> > pscreen->context_create = etna_context_create;
> > pscreen->is_format_supported = etna_screen_is_format_supported;
> > +   pscreen->query_dmabuf_modifiers = etna_screen_query_dmabuf_modifiers;
> >  
> > etna_fence_screen_init(pscreen);
> > etna_query_screen_init(pscreen);
> > -- 
> > 2.11.0
> > 
> > ___
> > etnaviv mailing list
> > etna...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/etnaviv


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

Re: [Mesa-dev] [PATCH 07/11] etnaviv: implement resource import with modifier

[Philipp Zabel]

On Fri, 2017-06-23 at 17:50 +0200, Lucas Stach wrote:
> This implements resource import with modifier, deriving the correct
> internal layout from the modifier and constructing a render compatible
> base resource if needed.
> 
> This removes the special cases for DDX and renderonly scanout allocated
> buffers, as the linear modifier is enough to trigger correct handling
> of those buffers.
> 
> Signed-off-by: Lucas Stach 
> ---
>  src/gallium/drivers/etnaviv/etnaviv_resource.c | 112 
> +
>  1 file changed, 78 insertions(+), 34 deletions(-)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c 
> b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> index 43f63f8908a0..f006d24a1bba 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> @@ -36,6 +36,29 @@
>  #include "util/u_inlines.h"
>  #include "util/u_memory.h"
>  
> +#include 
> +
> +#ifndef DRM_FORMAT_MOD_INVALID
> +#define DRM_FORMAT_MOD_INVALID ((1ULL<<56) - 1)
> +#endif
> +
> +static unsigned int modifier_to_layout(uint64_t modifier)

This could return a value of type enum etna_surface_layout.

> +{
> +   switch (modifier) {
> +   case DRM_FORMAT_MOD_VIVANTE_TILED:
> +  return ETNA_LAYOUT_TILED;
> +   case DRM_FORMAT_MOD_VIVANTE_SUPER_TILED:
> +  return ETNA_LAYOUT_SUPER_TILED;
> +   case DRM_FORMAT_MOD_VIVANTE_SPLIT_TILED:
> +  return ETNA_LAYOUT_MULTI_TILED;
> +   case DRM_FORMAT_MOD_VIVANTE_SPLIT_SUPER_TILED:
> +  return ETNA_LAYOUT_MULTI_SUPERTILED;
> +   case DRM_FORMAT_MOD_LINEAR:
> +   default:
> +  return ETNA_LAYOUT_LINEAR;
> +   }
> +}
> +
>  /* A tile is 4x4 pixels, having 'screen->specs.bits_per_tile' of tile status.
>   * So, in a buffer of N pixels, there are N / (4 * 4) tiles.
>   * We need N * screen->specs.bits_per_tile / (4 * 4) bits of tile status, or
> @@ -141,6 +164,7 @@ etna_resource_alloc(struct pipe_screen *pscreen, unsigned 
> layout,
>  const struct pipe_resource *templat)
>  {
> struct etna_screen *screen = etna_screen(pscreen);
> +   struct etna_resource *rsc;
> unsigned size;
>  
> DBG_F(ETNA_DBG_RESOURCE_MSGS,
> @@ -186,8 +210,36 @@ etna_resource_alloc(struct pipe_screen *pscreen, 
> unsigned layout,
>   paddingY = min_paddingY;
> }
>  
> -   struct etna_resource *rsc = CALLOC_STRUCT(etna_resource);
> +   if (templat->bind & PIPE_BIND_SCANOUT) {
> +  struct pipe_resource scanout_templat = *templat;
> +  struct renderonly_scanout *scanout;
> +  struct winsys_handle handle;
> +  unsigned padX, padY;
>  
> +  /* pad scanout buffer size to be compatible with the RS */
> +  padX = ETNA_RS_WIDTH_MASK + 1;
> +  padY = (ETNA_RS_HEIGHT_MASK + 1) * screen->specs.pixel_pipes;
> +  scanout_templat.width0 = align(scanout_templat.width0, padX);
> +  scanout_templat.height0 = align(scanout_templat.height0, padY);
> +
> +  scanout = renderonly_scanout_for_resource(_templat,
> +screen->ro, );
> +  if (!scanout)
> + return NULL;
> +
> +  rsc = etna_resource(pscreen->resource_from_handle(pscreen, templat,
> +,
> +
> PIPE_HANDLE_USAGE_WRITE));
> +  close(handle.handle);
> +  if (!rsc)
> + return NULL;
> +
> +  rsc->scanout = scanout;
> +
> +  return >base;
> +   }
> +
> +   rsc = CALLOC_STRUCT(etna_resource);
> if (!rsc)
>return NULL;
>  
> @@ -214,30 +266,6 @@ etna_resource_alloc(struct pipe_screen *pscreen, 
> unsigned layout,
> rsc->bo = bo;
> rsc->ts_bo = 0; /* TS is only created when first bound to surface */
>  
> -   if (templat->bind & PIPE_BIND_SCANOUT) {
> -  struct pipe_resource scanout_templat = *templat;
> -  struct winsys_handle handle;
> -  unsigned padX, padY;
> -
> -  /* pad scanout buffer size to be compatible with the RS */
> -  padX = ETNA_RS_WIDTH_MASK + 1;
> -  padY = (ETNA_RS_HEIGHT_MASK + 1) * screen->specs.pixel_pipes;
> -  scanout_templat.width0 = align(scanout_templat.width0, padX);
> -  scanout_templat.height0 = align(scanout_templat.height0, padY);
> -
> -  rsc->scanout = renderonly_scanout_for_resource(_templat,
> - screen->ro, );
> -  if (!rsc->scanout)
> - goto free_rsc;
> -
> -  rsc->external = pscreen->resource_from_handle(pscreen, >base,
> -,
> -PIPE_HANDLE_USAGE_WRITE);
> -  close(handle.handle);
> -  if (!rsc->external)
> - goto free_rsc;
> -   }
> -
> if (DBG_ENABLED(ETNA_DBG_ZERO)) {
>void *map = etna_bo_map(bo);
>memset(map, 0, size);
> @@ -370,14 +398,21 @@ etna_resource_from_handle(struct pipe_screen *pscreen,
>

Re: [Mesa-dev] [PATCH 11/11] etnaviv: advertise supported dmabuf modifiers

[Wladimir J. van der Laan]

On Fri, Jun 23, 2017 at 05:50:28PM +0200, Lucas Stach wrote:
> Simply advertise all supported modifiers, independent of the format.
> Special formats, like compressed, which don't support all those modifiers
> are already culled from the dmabuf format list, as we don't support
> the render target binding for them.

The SPLIT formats are only supported on hardware with multiple pixel pipes.

Should this be checked, or is it harmless to advertize them unconditionally?

Reviewed-by: Wladimir J. van der Laan

> Signed-off-by: Lucas Stach 
> ---
>  src/gallium/drivers/etnaviv/etnaviv_screen.c | 36 
> 
>  1 file changed, 36 insertions(+)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_screen.c 
> b/src/gallium/drivers/etnaviv/etnaviv_screen.c
> index b70897b6e41f..571f0b3d42d8 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_screen.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_screen.c
> @@ -45,6 +45,8 @@
>  
>  #include "state_tracker/drm_driver.h"
>  
> +#include 
> +
>  #define ETNA_DRM_VERSION(major, minor) ((major) << 16 | (minor))
>  #define ETNA_DRM_VERSION_FENCE_FD  ETNA_DRM_VERSION(1, 1)
>  
> @@ -545,6 +547,39 @@ etna_screen_is_format_supported(struct pipe_screen 
> *pscreen,
> return usage == allowed;
>  }
>  
> +const uint64_t supported_modifiers[] = {
> +   DRM_FORMAT_MOD_LINEAR,
> +   DRM_FORMAT_MOD_VIVANTE_SPLIT_TILED,
> +   DRM_FORMAT_MOD_VIVANTE_SPLIT_SUPER_TILED,
> +   DRM_FORMAT_MOD_VIVANTE_TILED,
> +   DRM_FORMAT_MOD_VIVANTE_SUPER_TILED,
> +};
> +
> +static void
> +etna_screen_query_dmabuf_modifiers(struct pipe_screen *screen,
> +   enum pipe_format format, int max,
> +   uint64_t *modifiers,
> +   unsigned int *external_only, int *count)
> +{
> +   int i;
> +
> +   if (!max) {
> +  *count = ARRAY_SIZE(supported_modifiers);
> +  return;
> +   }
> +
> +   if (max > ARRAY_SIZE(supported_modifiers))
> +  max = ARRAY_SIZE(supported_modifiers);
> +
> +   for (i = 0; i < max; i++) {
> +  modifiers[i] = supported_modifiers[i];
> +  if (external_only)
> + external_only[i] = 0;
> +   }
> +
> +   *count = i;
> +}
> +
>  static boolean
>  etna_get_specs(struct etna_screen *screen)
>  {
> @@ -839,6 +874,7 @@ etna_screen_create(struct etna_device *dev, struct 
> etna_gpu *gpu,
> pscreen->get_timestamp = etna_screen_get_timestamp;
> pscreen->context_create = etna_context_create;
> pscreen->is_format_supported = etna_screen_is_format_supported;
> +   pscreen->query_dmabuf_modifiers = etna_screen_query_dmabuf_modifiers;
>  
> etna_fence_screen_init(pscreen);
> etna_query_screen_init(pscreen);
> -- 
> 2.11.0
> 
> ___
> etnaviv mailing list
> etna...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/etnaviv
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] gallium: Reduce trace_dump_box_bytes size by box->x.

[Marek Olšák]

On Tue, Jun 27, 2017 at 8:57 AM, Michel Dänzer  wrote:
> On 27/06/17 04:10 AM, Marek Olšák wrote:
>> In my opinion, dumping resources isn't very useful. I think it would
>> be better to remove that completely.
>
> You'd have to remove the whole trace driver along with it, since its
> purpose is to generate a trace which can be replayed.

Really? I didn't know it supported replay. How do I replay a trace?
Does it work?

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

Re: [Mesa-dev] [PATCH 2/2] radeonsi: move instance divisors into a constant buffer

[Marek Olšák]

On Tue, Jun 27, 2017 at 9:22 AM, Nicolai Hähnle  wrote:
> On 27.06.2017 02:14, Marek Olšák wrote:
>>
>> From: Marek Olšák 
>>
>> Shader key size: 107 -> 47
>
>
> Nice improvement.
>
>
>> Divisors of 0 and 1 are encoded in the shader key. Greater instance
>> divisors
>> are loaded from a constant buffer.
>>
>> The shader code doing the division is huge. Is it something we need to
>> worry about? Does any app use instance divisors >= 2?
>
>
> This reminds me of a certain LLVM improvement that I still need to clear.
>
> I doubt instance divisors >= 2 are used. As a data point, Vulkan doesn't
> support it as a feature at all, IIRC.
>
> Can we get an optimized monotholic shader variant built for shaders that
> have to fetch? This should help if anybody ever triggers this, because

We can't get optimized variants if we want to keep the shader key
small. If I put all instance divisors into key.opt, it would defeat
the effect of this patch.

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

Re: [Mesa-dev] [PATCH 3/3] radeonsi: use #pragma pack to pack si_shader_key

[Marek Olšák]

On Tue, Jun 27, 2017 at 10:02 AM, Nicolai Hähnle  wrote:
> On 27.06.2017 00:15, Marek Olšák wrote:
>>
>> On Thu, Jun 22, 2017 at 9:19 AM, Nicolai Hähnle 
>> wrote:
>>>
>>> On 20.06.2017 20:00, Marek Olšák wrote:


 From: Marek Olšák 

 sizeof(struct si_shader_key):
 Before reverting the 2 commits: 120 bytes
 After reverting the 2 commits: 128 bytes
 With #pragma pack: 107 bytes

 I'm not sure if memcmp with a byte-aligned size is a good idea.
>>>
>>>
>>>
>>> Does this have a measurable impact? The code is nicer to read with the
>>> structure after the patches, but I'm not sure it's worth the risk of
>>> getting
>>> misaligned data somewhere.
>>
>>
>> It decreases the time spent in si_update_shaders by 6% when going from
>> 128 bytes to 106 for the shader key.
>>
>> What do you mean by the risk?
>
>
> If we end up accidentally misaligning a member, that could cause a
> performance hit. But those 6% improvement does seem worth it. I do think
> Emil's suggestion of adding the attribute directly to the structures is a
> good idea. With that, the patch is

I can't add the attributes inside the structures, because every
structure member would have to have the attribute, and that would be
too much noise in the code. There are MSVC and gcc attributes. gcc
supports both kinds. MSVC attributes are the global #pragmas. gcc
attributes are per-member or on structure types. If the attribute is
on a structure type, it only specifies alignment for the whole
structure, not individual members.

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

Re: [Mesa-dev] [PATCH 04/11] etnaviv: pad scanout buffer size to RS alignment

[Wladimir J. van der Laan]

On Fri, Jun 23, 2017 at 05:50:21PM +0200, Lucas Stach wrote:
> This fixes failures to import the scanout buffer with screen resolutions
> that don't satisfy teh RS alignment restrictions, like 1680x1050.

Thanks. I remember having this issue on OLPC, but never came up with a good
solution.

Reviewed-by: Wladimir J. van der Laan

> Signed-off-by: Lucas Stach 
> ---
>  src/gallium/drivers/etnaviv/etnaviv_resource.c | 13 +++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c 
> b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> index c6e7e98837b6..5cd20fafba49 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> @@ -215,9 +215,18 @@ etna_resource_alloc(struct pipe_screen *pscreen, 
> unsigned layout,
> rsc->ts_bo = 0; /* TS is only created when first bound to surface */
>  
> if (templat->bind & PIPE_BIND_SCANOUT) {
> +  struct pipe_resource scanout_templat = *templat;
>struct winsys_handle handle;
> -  rsc->scanout = renderonly_scanout_for_resource(>base, screen->ro,
> - );
> +  unsigned padX, padY;
> +
> +  /* pad scanout buffer size to be compatible with the RS */
> +  padX = ETNA_RS_WIDTH_MASK + 1;
> +  padY = (ETNA_RS_HEIGHT_MASK + 1) * screen->specs.pixel_pipes;
> +  scanout_templat.width0 = align(scanout_templat.width0, padX);
> +  scanout_templat.height0 = align(scanout_templat.height0, padY);
> +
> +  rsc->scanout = renderonly_scanout_for_resource(_templat,
> + screen->ro, );
>if (!rsc->scanout)
>   goto free_rsc;
>  
> -- 
> 2.11.0
> 
> ___
> etnaviv mailing list
> etna...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/etnaviv
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev