Re: [Mesa-dev] [PATCH 2/3] driconf: Correct and update Spanish translations

[Eric Anholt]

Alex Henrie  writes:

> ---
>  src/mesa/drivers/dri/common/xmlpool/es.po | 65 
> ---
>  1 file changed, 33 insertions(+), 32 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/common/xmlpool/es.po 
> b/src/mesa/drivers/dri/common/xmlpool/es.po
> index e5b4d1a..4f47e73 100644
> --- a/src/mesa/drivers/dri/common/xmlpool/es.po
> +++ b/src/mesa/drivers/dri/common/xmlpool/es.po

>  #: t_options.h:85
>  msgid "Force GLSL extension default behavior to 'warn'"
> -msgstr ""
> +msgstr "Forzar comportamiento por defecto de la extensión GLSL a 'warn'"

This series looks reasonable to me, and hopefully we can get some acks
From the other Spanish speakers and get these patches in.

That said, while it's not my primary language, this translation reads
strangely to me: This option makes all GLSL extensions (such as
GL_ARB_explicit_attrib_location or GL_ARB_uniform_buffer_object) have the
"warn" behavior, not just one GLSL extension.

(GLSL by default doesn't expose all the extensions that are available,
since new keywords in extensions might break old code that happeed to
use the keywords for unrelated purposes.  Instead, you have to opt in to
the extensions you've probed for and decided to use by saying
'#extension GL_ARB_whatever : enable'.  Nvidia's drivers expose
everything anyway, so this option gets us compatibility with those
shaders by treating them as if they'd said '#extension GL_ARB_whatever :
warn', which at least lets them compile and run)



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

Re: [Mesa-dev] [PATCH 2/3] driconf: Correct and update Spanish translations

[Bruno Jimenez]

On Tue, 2014-01-14 at 22:07 -0700, Alex Henrie wrote:
> 2014/1/14 Bruno Jimenez :
> > I think I prefer without "la", but if you prefer with, it's also ok.
> 
> I also prefer to omit the "la".
> 
> > To me, it sounds better "renderizado". As usual, RAE doesn't say
> > anything, and wikipedia has an entry titled "renderización" (and
> > "renderizado" redirected to it too), but the first word of the article
> > is "renderizado". Still, both are ok, so I don't really mind which one.
> 
> I'm going to go with "renderización". I think it must be a regional 
> difference.

Lot's of regional differences an different preferences in Spanish, but
it is perfectly understandable.

> 
> Let me know if you find any other errors.

I don't think there are any more, at least that I can't understand
without context.

> 
> -Alex

Hope it helps!
Bruno

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

Re: [Mesa-dev] [PATCH 2/3] driconf: Correct and update Spanish translations

[Bruno Jimenez]

On Wed, 2014-01-15 at 01:14 -0800, Eric Anholt wrote:
> Alex Henrie  writes:
> 
> > ---
> >  src/mesa/drivers/dri/common/xmlpool/es.po | 65 
> > ---
> >  1 file changed, 33 insertions(+), 32 deletions(-)
> >
> > diff --git a/src/mesa/drivers/dri/common/xmlpool/es.po 
> > b/src/mesa/drivers/dri/common/xmlpool/es.po
> > index e5b4d1a..4f47e73 100644
> > --- a/src/mesa/drivers/dri/common/xmlpool/es.po
> > +++ b/src/mesa/drivers/dri/common/xmlpool/es.po
> 
> >  #: t_options.h:85
> >  msgid "Force GLSL extension default behavior to 'warn'"
> > -msgstr ""
> > +msgstr "Forzar comportamiento por defecto de la extensión GLSL a 'warn'"
> 
> This series looks reasonable to me, and hopefully we can get some acks
> From the other Spanish speakers and get these patches in.
> 
> That said, while it's not my primary language, this translation reads
> strangely to me: This option makes all GLSL extensions (such as
> GL_ARB_explicit_attrib_location or GL_ARB_uniform_buffer_object) have the
> "warn" behavior, not just one GLSL extension.
> 
> (GLSL by default doesn't expose all the extensions that are available,
> since new keywords in extensions might break old code that happeed to
> use the keywords for unrelated purposes.  Instead, you have to opt in to
> the extensions you've probed for and decided to use by saying
> '#extension GL_ARB_whatever : enable'.  Nvidia's drivers expose
> everything anyway, so this option gets us compatibility with those
> shaders by treating them as if they'd said '#extension GL_ARB_whatever :
> warn', which at least lets them compile and run)

This is the kind of things I was refering when I said that
I lack the context for a better translation.

But with this new information, I think a better translation
would be:
"Forzar que el comportamiento por defecto de las extensiones
GLSL sea 'warn'"

I think the confusion comes that in the original message it says
"extension" in singular. And because of that we
translated it as "la extensión GLSL".

Hope it helps!
Bruno

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


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

Re: [Mesa-dev] [PATCH v2] nouveau: add framebuffer validation callback

[Francisco Jerez]

Ilia Mirkin  writes:

> Fixes assertions when trying to attach textures to fbs with formats not
> supported by the render engines.
>
> See https://bugs.freedesktop.org/show_bug.cgi?id=73459
>
> Signed-off-by: Ilia Mirkin 
> ---
>
> Francisco, thanks for the review. Is this more like what you had in mind?
> Interesting that nv10/nv20 support different-bitness color/depth -- that
> requirement came back for nv30/nv40.
>

Looks good to me,

Reviewed-by: Francisco Jerez 

Thanks.

>  src/mesa/drivers/dri/nouveau/nouveau_context.c |  1 +
>  src/mesa/drivers/dri/nouveau/nouveau_fbo.c | 52 
> ++
>  2 files changed, 53 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/nouveau/nouveau_context.c 
> b/src/mesa/drivers/dri/nouveau/nouveau_context.c
> index 181c9d0..ec474d4 100644
> --- a/src/mesa/drivers/dri/nouveau/nouveau_context.c
> +++ b/src/mesa/drivers/dri/nouveau/nouveau_context.c
> @@ -187,6 +187,7 @@ nouveau_context_init(struct gl_context *ctx, struct 
> nouveau_screen *screen,
>   ctx->Extensions.EXT_framebuffer_blit = true;
>   ctx->Extensions.EXT_texture_filter_anisotropic = true;
>   ctx->Extensions.NV_texture_env_combine4 = true;
> + ctx->Const.MaxColorAttachments = 1;
>  
>   return GL_TRUE;
>  }
> diff --git a/src/mesa/drivers/dri/nouveau/nouveau_fbo.c 
> b/src/mesa/drivers/dri/nouveau/nouveau_fbo.c
> index 25543e4..427eb00 100644
> --- a/src/mesa/drivers/dri/nouveau/nouveau_fbo.c
> +++ b/src/mesa/drivers/dri/nouveau/nouveau_fbo.c
> @@ -268,6 +268,57 @@ nouveau_finish_render_texture(struct gl_context *ctx,
>   texture_dirty(rb->TexImage->TexObject);
>  }
>  
> +static int
> +validate_format_bpp(gl_format format)
> +{
> + switch (format) {
> + case MESA_FORMAT_XRGB:
> + case MESA_FORMAT_ARGB:
> + case MESA_FORMAT_Z24_S8:
> + return 32;
> + case MESA_FORMAT_RGB565:
> + case MESA_FORMAT_Z16:
> + return 16;
> + default:
> + return 0;
> + }
> +}
> +
> +static void
> +nouveau_check_framebuffer_complete(struct gl_context *ctx,
> +struct gl_framebuffer *fb)
> +{
> + const struct nouveau_driver *drv = context_drv(ctx);
> + struct gl_renderbuffer_attachment *color =
> + &fb->Attachment[BUFFER_COLOR0];
> + struct gl_renderbuffer_attachment *depth =
> + &fb->Attachment[BUFFER_DEPTH];
> + int color_bpp = 0, zeta_bpp;
> +
> + if (color->Type == GL_TEXTURE) {
> + color_bpp = validate_format_bpp(
> + color->Renderbuffer->TexImage->TexFormat);
> + if (!color_bpp)
> + goto err;
> + }
> +
> + if (depth->Type == GL_TEXTURE) {
> + zeta_bpp = validate_format_bpp(
> + depth->Renderbuffer->TexImage->TexFormat);
> + if (!zeta_bpp)
> + goto err;
> + /* NV04/NV05 requires same bpp-ness for color/zeta */
> + if (context_chipset(ctx) < 0x10 &&
> + color_bpp && color_bpp != zeta_bpp)
> + goto err;
> + }
> +
> + return;
> +err:
> + fb->_Status = GL_FRAMEBUFFER_UNSUPPORTED_EXT;
> + return;
> +}
> +
>  void
>  nouveau_fbo_functions_init(struct dd_function_table *functions)
>  {
> @@ -279,4 +330,5 @@ nouveau_fbo_functions_init(struct dd_function_table 
> *functions)
>   functions->FramebufferRenderbuffer = nouveau_framebuffer_renderbuffer;
>   functions->RenderTexture = nouveau_render_texture;
>   functions->FinishRenderTexture = nouveau_finish_render_texture;
> + functions->ValidateFramebuffer = nouveau_check_framebuffer_complete;
>  }
> -- 
> 1.8.3.2


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

Re: [Mesa-dev] [PATCH] mesa: Add COMPRESSED_RGBA_S3TC_DXT1_EXT to COMPRESSED_TEXTURE_FORMATS for GLES

[Marek Olšák]

Reviewed-by: Marek Olšák 

Marek

On Tue, Jan 14, 2014 at 11:19 PM, Ian Romanick  wrote:
> From: Ian Romanick 
>
> The ES and desktop GL specs diverge here.  Yay!
>
> In desktop OpenGL, the driver can perform online compression of
> uncompressed texture data.  GL_NUM_COMPRESSED_TEXTURE_FORMATS and
> GL_COMPRESSED_TEXTURE_FORMATS give the application a list of formats
> that it could ask the driver to compress with some expectation of
> quality.  The GL_ARB_texture_compression spec calls this "suitable for
> general-purpose usage."  As noted above, this means
> GL_COMPRESSED_RGBA_S3TC_DXT1_EXT is not included in the list.
>
> In OpenGL ES, the driver never performs compression.
> GL_NUM_COMPRESSED_TEXTURE_FORMATS and GL_COMPRESSED_TEXTURE_FORMATS give
> the application a list of formats that the driver can receive from the
> application.  It is the *complete* list of formats.  The
> GL_EXT_texture_compression_s3tc spec says:
>
> "New State for OpenGL ES 2.0.25 and 3.0.2 Specifications
>
> The queries for NUM_COMPRESSED_TEXTURE_FORMATS and
> COMPRESSED_TEXTURE_FORMATS include COMPRESSED_RGB_S3TC_DXT1_EXT,
> COMPRESSED_RGBA_S3TC_DXT1_EXT, COMPRESSED_RGBA_S3TC_DXT3_EXT,
> and COMPRESSED_RGBA_S3TC_DXT5_EXT."
>
> Note that the addition is only to the OpenGL ES specification!
>
> Signed-off-by: Ian Romanick 
> See-also: 
> http://lists.freedesktop.org/archives/mesa-dev/2013-October/047439.html
> Cc: Marek Olšák 
> Cc: Brian Paul 
> Cc: "10.0" 
> ---
>  src/mesa/main/texcompress.c | 37 +
>  1 file changed, 37 insertions(+)
>
> diff --git a/src/mesa/main/texcompress.c b/src/mesa/main/texcompress.c
> index e71d0c4..47ad306 100644
> --- a/src/mesa/main/texcompress.c
> +++ b/src/mesa/main/texcompress.c
> @@ -263,6 +263,43 @@ _mesa_get_compressed_formats(struct gl_context *ctx, 
> GLint *formats)
>else {
>   n += 3;
>}
> +
> +  /* The ES and desktop GL specs diverge here.
> +   *
> +   * In desktop OpenGL, the driver can perform online compression of
> +   * uncompressed texture data.  GL_NUM_COMPRESSED_TEXTURE_FORMATS and
> +   * GL_COMPRESSED_TEXTURE_FORMATS give the application a list of
> +   * formats that it could ask the driver to compress with some
> +   * expectation of quality.  The GL_ARB_texture_compression spec
> +   * calls this "suitable for general-purpose usage."  As noted
> +   * above, this means GL_COMPRESSED_RGBA_S3TC_DXT1_EXT is not
> +   * included in the list.
> +   *
> +   * In OpenGL ES, the driver never performs compression.
> +   * GL_NUM_COMPRESSED_TEXTURE_FORMATS and
> +   * GL_COMPRESSED_TEXTURE_FORMATS give the application a list of
> +   * formats that the driver can receive from the application.  It
> +   * is the *complete* list of formats.  The
> +   * GL_EXT_texture_compression_s3tc spec says:
> +   *
> +   * "New State for OpenGL ES 2.0.25 and 3.0.2 Specifications
> +   *
> +   * The queries for NUM_COMPRESSED_TEXTURE_FORMATS and
> +   * COMPRESSED_TEXTURE_FORMATS include
> +   * COMPRESSED_RGB_S3TC_DXT1_EXT,
> +   * COMPRESSED_RGBA_S3TC_DXT1_EXT,
> +   * COMPRESSED_RGBA_S3TC_DXT3_EXT, and
> +   * COMPRESSED_RGBA_S3TC_DXT5_EXT."
> +   *
> +   * Note that the addition is only to the OpenGL ES specification!
> +   */
> +  if (_mesa_is_gles(ctx)) {
> + if (formats) {
> +formats[n++] = GL_COMPRESSED_RGBA_S3TC_DXT1_EXT;
> + } else {
> +n += 1;
> + }
> +  }
> }
>
> /* The GL_OES_compressed_ETC1_RGB8_texture spec says:
> --
> 1.8.1.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [wip 8/9] glsl: functions to serialize gl_shader and gl_shader_program

[Tapani]

On 01/14/2014 07:53 PM, Paul Berry wrote:
On 2 January 2014 03:58, Tapani Pälli > wrote:


diff --git a/src/glsl/shader_cache.cpp b/src/glsl/shader_cache.cpp
new file mode 100644
+/**
+ * It is currently unknown if we need these to be available.
+ * There can be calls in mesa/main (like glGetAttachedShaders)
that use
+ * the Shaders list.
+ */
+const bool STORE_UNLINKED_SHADERS = false;


I think it really exaggerates our level of uncertainty to say that it 
is "currently unknown" whether we need unlinked shaders to be 
available.  Speaking for myself at least, I'm quite convinced that we 
don't.  AFAICT,


8<

Thanks for the explanation. I've been holding this until now as I was 
not sure if these can be left out but now I cam convinced. I will cut 
them out.


So if the user creates a program and calls glProgramBinaryOES() 
followed by glGetAttachedShaders(), they will see no shaders, since 
the pre-link state is still in its initial configuration of having no 
shaders attached.


IMHO, trying to plan for the contingency case where we're wrong about 
this is just going to lead to confusion and make the code hard to 
maintain.  I think we should drop this const, and remove the code that 
would have been executed if STORE_UNLINKED_SHADERS were true.  In the 
unlikely event that it turns out we were wrong about this (or Khronos


I'll do this, I was basically worried if all the errors cases will be 
handled properly as there will be a lot of uninitialized pointers and 
such out there. But these can be found out and the correct thing to do 
is to make sure everything's checked in the shaderapi correctly.




+   blob.write(&shader->Geom, sizeof(shader->Geom));


It seems a little strange to see geometry-shader-specific information 
being dumped into the binary, since OES_get_program_binary is a GLES 
extension, and GLES doesn't support geometry shaders.  I assume you 
are doing this because you also want this code to work for 
ARB_get_program_binary?  If so it would be nice to have a comment 
explaining that.


I will add it, the plan is to get both desktop GL and the OES extension 
supported.




+static void
+serialize_uniform_storage(gl_uniform_storage *uni, memory_writer
&blob)


I don't think this is right.  The ARB_get_program_binary spec says:

8. How does ProgramBinary interact with uniform values, including
   shader-specified defaults?

RESOLVED: All uniforms specified in the binary are reset to their 
shader-
specified defaults, or to zero if they aren't specified, when the 
program

binary is loaded. The spec language has been updated to specify this
behavior.

The OES_get_program_binary spec doesn't mention uniforms at all, but I 
believe this is not intended to indicate a behavioural 
difference--it's just a consequence of the fact that 
ARB_get_program_binary was written later, so they had a chance to 
clarify things.  In fact, issue #7 in ARB_get_program_binary 
specifically says:


7. How does this spec differ from the OES_get_program_binary and why?

...

There are other areas where language was clarified, but this is 
meant to

be consistent with the intent of the original specification and not to
alter previously established behavior.

So I believe we shouldn't be serializing uniform values.


For me this seemed much easier way to serialize than recreate it though. 
Would it be enough if I reset the default values in place?



+
+
+static void
+read_hash_table(struct string_to_uint_map *hash, memory_map *map)
+{
+   uint32_t size = map->read_uint32_t();
+
+   for (unsigned i = 0; i < size; i++) {


Security issue: we need to bail out of this loop if we try to read 
beyond the end of the binary.  Otherwise a bogus size could cause us 
to read from garbage memory for a very long time.


ok, will fix


+   read_hash_table(prog->UniformHash, &map);
+
+   map.read(&prog->Geom, sizeof(prog->Geom));
+   map.read(&prog->Vert, sizeof(prog->Vert));
+
+   /* just zero for now */
+   prog->LinkedTransformFeedback.Outputs = NULL;
+   prog->LinkedTransformFeedback.Varyings = NULL;
+   prog->LinkedTransformFeedback.NumVarying = 0;
+   prog->LinkedTransformFeedback.NumOutputs = 0;


Did you forget to finish writing this code?  We need to serialize this 
stuff, since it's part of post-link state.


This part is work in progress, I need to get myself more familiar how 
transform feedback API works and what is required.



+#else
+   prog->Shaders = NULL;
+   prog->NumShaders = 0;


This is not correct.  Shader objects are part of pre-link state.  That 
means that glProgramBinaryOES() should ignore them and leave them 
unchanged.  It shouldn't throw out any attached shaders.




You are right, this is done here only because these are not initialized 
properly and when deleting resources we would fai

Re: [Mesa-dev] [PATCH RFC 1/1] clover: Don't crash on NULL global buffer objects.

[Francisco Jerez]

Jan Vesely  writes:

> Specs say it's legal.
> Fixes clones.xml gegl test.
>
> ---
> Hi,
>
> this patch is an attempt to support NULL buffer objects in clover.
> It adds NULL handling to few places, and it's enough to get 'clones'
> gegl test running.
>
> The specs say: "If the argument is a buffer object, the arg_value
> pointer can be NULL or point to a NULL value in which case a NULL
> value will be used as the value for the argument declared as a
> pointer to __global or __constant memory in the kernel."
>
> I was considering using a special buffer instance to represent
> NULL buffers but this seems more straightforward. Using 'pobj'
> should take care of the latter part of the spec requirement too.
>
> BZ: https://bugs.freedesktop.org/show_bug.cgi?id=73571#c2
> ignore the first two comments I forgot I was testing some
> additional patches.
>
> Tom, I'm not sure I understand your comment. Does it mean that at
> the moment it's possible that kernels receive NULL pointers
> that point to valid buffers?
>
> regards,
> Jan
>
>  src/gallium/drivers/r600/evergreen_compute.c  | 9 ++---
>  src/gallium/state_trackers/clover/core/kernel.cpp | 4 ++--
>  2 files changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/src/gallium/drivers/r600/evergreen_compute.c 
> b/src/gallium/drivers/r600/evergreen_compute.c
> index a2db69b..f14b7c5 100644
> --- a/src/gallium/drivers/r600/evergreen_compute.c
> +++ b/src/gallium/drivers/r600/evergreen_compute.c
> @@ -655,10 +655,13 @@ static void evergreen_set_global_binding(
>  
>   for (int i = 0; i < n; i++)
>   {
> - assert(resources[i]->target == PIPE_BUFFER);
> - assert(resources[i]->bind & PIPE_BIND_GLOBAL);
> + if (resources[i]) {
> + assert(resources[i]->target == PIPE_BUFFER);
> + assert(resources[i]->bind & PIPE_BIND_GLOBAL);
>  
> - *(handles[i]) = buffers[i]->chunk->start_in_dw * 4;
> + *(handles[i]) = buffers[i]->chunk->start_in_dw * 4;
> + } else
> + *(handles[i]) = NULL;
>   }
>  
>   evergreen_set_rat(ctx->cs_shader_state.shader, 0, pool->bo, 0, 
> pool->size_in_dw * 4);

Can you split the r600 changes into a separate patch?

> diff --git a/src/gallium/state_trackers/clover/core/kernel.cpp 
> b/src/gallium/state_trackers/clover/core/kernel.cpp
> index ac57c71..412eac4 100644
> --- a/src/gallium/state_trackers/clover/core/kernel.cpp
> +++ b/src/gallium/state_trackers/clover/core/kernel.cpp
> @@ -331,7 +331,7 @@ kernel::global_argument::set(size_t size, const void 
> *value) {
> if (size != sizeof(cl_mem))
>throw error(CL_INVALID_ARG_SIZE);
>  
> -   buf = &obj(*(cl_mem *)value);
> +   buf = pobj(value ? *(cl_mem *)value : NULL);
> _set = true;
>  }
>  
> @@ -340,7 +340,7 @@ kernel::global_argument::bind(exec_context &ctx,
>const module::argument &marg) {
> align(ctx.input, marg.target_align);
> ctx.g_handles.push_back(allocate(ctx.input, marg.target_size));
> -   ctx.g_buffers.push_back(buf->resource(*ctx.q).pipe);
> +   ctx.g_buffers.push_back(buf ? buf->resource(*ctx.q).pipe: NULL);
>  }
>  

Another possibility would be to write NULL to the input buffer here and
not push the handle/buffer pair at all.  That way drivers won't have to
deal with this special case.

You probably need to fix constant buffer arguments too.

Thanks.

>  void
> -- 
> 1.8.4.2


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

Re: [Mesa-dev] [PATCH 2/3] nv50: add more RGB10A2 formats

[Ilia Mirkin]

On Wed, Dec 25, 2013 at 11:53 AM, Christoph Bumiller
 wrote:
> ---
>  src/gallium/drivers/nouveau/nv50/nv50_formats.c | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/src/gallium/drivers/nouveau/nv50/nv50_formats.c 
> b/src/gallium/drivers/nouveau/nv50/nv50_formats.c
> index 0a7e812..b301890 100644
> --- a/src/gallium/drivers/nouveau/nv50/nv50_formats.c
> +++ b/src/gallium/drivers/nouveau/nv50/nv50_formats.c
> @@ -202,6 +202,8 @@ const struct nv50_format 
> nv50_format_table[PIPE_FORMAT_COUNT] =
> TBV, 1),
> C4A(R10G10B10A2_SNORM, NONE, C0, C1, C2, C3, SNORM, 10_10_10_2, TV, 0),
> C4A(B10G10R10A2_SNORM, NONE, C2, C1, C0, C3, SNORM, 10_10_10_2, TV, 1),
> +   C4A(R10G10B10A2_UINT, RGB10_A2_UINT, C0, C1, C2, C3, UINT, 10_10_10_2, 
> TRV, 0),
> +   C4A(B10G10R10A2_UINT, RGB10_A2_UINT, C2, C1, C0, C3, UINT, 10_10_10_2, 
> TV, 0),
>
> F3B(R11G11B10_FLOAT, R11G11B10_FLOAT, C0, C1, C2, xx, FLOAT, 11_11_10, 
> IB),
>
> @@ -394,6 +396,11 @@ const struct nv50_format 
> nv50_format_table[PIPE_FORMAT_COUNT] =
> F1A(R16_SSCALED, NONE, C0, xx, xx, xx, SSCALED, 16, V),
> F1A(R16_USCALED, NONE, C0, xx, xx, xx, USCALED, 16, V),
>
> +   C4A(R10G10B10A2_USCALED, NONE, C0, C1, C2, C3, USCALED, 10_10_10_2, V, 0),
> +   C4A(R10G10B10A2_SSCALED, NONE, C0, C1, C2, C3, SSCALED, 10_10_10_2, V, 0),
> +   C4A(B10G10R10A2_USCALED, NONE, C0, C1, C2, C3, USCALED, 10_10_10_2, V, 1),
> +   C4A(B10G10R10A2_SSCALED, NONE, C0, C1, C2, C3, SSCALED, 10_10_10_2, V, 1),
> +
> C4A(R8G8B8A8_SSCALED, NONE, C0, C1, C2, C3, SSCALED, 8_8_8_8, V, 0),
> C4A(R8G8B8A8_USCALED, NONE, C0, C1, C2, C3, USCALED, 8_8_8_8, V, 0),
> F3A(R8G8B8_UNORM, NONE, C0, C1, C2, xx, UNORM, 8_8_8, V),

FWIW I ran piglit on this (with your other patches that cause the
RGB10A2 extensions to actually be turned on), and I saw this failure:

$ bin/draw-vertices-2101010 -auto
Int vertices - 2/10/10/10
Unsigned Int vertices - 2/10/10/10
Int Color - 2/10/10/10
Probe color at (45,5)
  Expected: 1.00 0.00 0.00 0.333000
  Observed: 1.00 0.00 0.00 0.00
Unsigned Int Color - 2/10/10/10
Int BGRA Color - 2/10/10/10
Probe color at (85,5)
  Expected: 0.00 0.00 1.00 0.333000
  Observed: 0.00 0.00 1.00 0.00
Unsigned Int BGRA Color - 2/10/10/10
Int 2/10/10/10 - test ABI
Unsigned 2/10/10/10 - test ABI

There were also ARB_texture_rgb10_a2ui failures with texwrap
bordercolor's, but there are lots of other such failures with integer
formats, so I assume that's all part of the same thing. For reference:

$ bin/texwrap GL_ARB_texture_rgb10_a2ui bordercolor -fbo -auto
Testing GL_ARB_texture_rgb10_a2ui.
Testing the border color only.
Testing GL_RGB10_A2UI, border color only
Fail with NEAREST and CLAMP_TO_BORDER at (95,36) @ 0,0
  Expected: 25 229 127 170
  Observed: 0 0 0 0
Fail with NEAREST and MIRROR_CLAMP_TO_BORDER_EXT at (273,36) @ 0,0
  Expected: 25 229 127 170
  Observed: 0 0 0 0

$ bin/texwrap GL_ARB_texture_rgb10_a2ui bordercolor swizzled -fbo -auto
Testing GL_ARB_texture_rgb10_a2ui.
Testing the border color only.
Using texture swizzling.
Testing GL_RGB10_A2UI, swizzled, border color only
Fail with NEAREST and CLAMP_TO_BORDER at (95,36) @ 0,0
  Expected: 127 25 229 170
  Observed: 0 0 0 0
Fail with NEAREST and MIRROR_CLAMP_TO_BORDER_EXT at (273,36) @ 0,0
  Expected: 127 25 229 170
  Observed: 0 0 0 0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] st/mesa: use signed temporary variable to store _ColorDrawBufferIndexes

[Emil Velikov]

The temporary variable used to store _ColorDrawBufferIndexes must be
signed (GLint), otherwise the following conditional will be incorrectly
evaluated. Leading to crashes in the driver/mesa or accessing/writing
to arbitrary memory location. The bug dates back to 2009.

Cc: 10.0 9.2 9.1 
Signed-off-by: Emil Velikov 
---

Rather old bug, spotted after Marek's recent patches covering the
area. Curious if there is any particular reason why we do not
enable more compiler warning messages.

How do people feel on the subject of enabling more (all even) compiler
warnings on gcc compatible compilers ?

Just for laughs I'll set -Wall locally to see how many warning
messages gcc will produce. At least some of those would be usefull.

Cheers,
Emil
---
 src/mesa/state_tracker/st_cb_clear.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/state_tracker/st_cb_clear.c 
b/src/mesa/state_tracker/st_cb_clear.c
index 87dccee..79124b3 100644
--- a/src/mesa/state_tracker/st_cb_clear.c
+++ b/src/mesa/state_tracker/st_cb_clear.c
@@ -444,7 +444,7 @@ st_Clear(struct gl_context *ctx, GLbitfield mask)
 
if (mask & BUFFER_BITS_COLOR) {
   for (i = 0; i < ctx->DrawBuffer->_NumColorDrawBuffers; i++) {
- GLuint b = ctx->DrawBuffer->_ColorDrawBufferIndexes[i];
+ GLint b = ctx->DrawBuffer->_ColorDrawBufferIndexes[i];
 
  if (b >= 0 && mask & (1 << b)) {
 struct gl_renderbuffer *rb
-- 
1.8.5.2

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

Re: [Mesa-dev] [PATCH] st/mesa: use signed temporary variable to store _ColorDrawBufferIndexes

[Emil Velikov]

On 15/01/14 11:49, Emil Velikov wrote:
> The temporary variable used to store _ColorDrawBufferIndexes must be
> signed (GLint), otherwise the following conditional will be incorrectly
> evaluated. Leading to crashes in the driver/mesa or accessing/writing
> to arbitrary memory location. The bug dates back to 2009.
> 
> Cc: 10.0 9.2 9.1 
> Signed-off-by: Emil Velikov 
> ---
> 
> Rather old bug, spotted after Marek's recent patches covering the
> area. Curious if there is any particular reason why we do not
> enable more compiler warning messages.
> 
> How do people feel on the subject of enabling more (all even) compiler
> warnings on gcc compatible compilers ?
> 
Actually Wall is already set, so I'll give -Wextra -Wconversion a try.
Most places in mesa already have explicit casts, which should not be
affected by the additional compiler flags.

~
Emil

> Just for laughs I'll set -Wall locally to see how many warning
> messages gcc will produce. At least some of those would be usefull.
> 
> Cheers,
> Emil
> ---
>  src/mesa/state_tracker/st_cb_clear.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/mesa/state_tracker/st_cb_clear.c 
> b/src/mesa/state_tracker/st_cb_clear.c
> index 87dccee..79124b3 100644
> --- a/src/mesa/state_tracker/st_cb_clear.c
> +++ b/src/mesa/state_tracker/st_cb_clear.c
> @@ -444,7 +444,7 @@ st_Clear(struct gl_context *ctx, GLbitfield mask)
>  
> if (mask & BUFFER_BITS_COLOR) {
>for (i = 0; i < ctx->DrawBuffer->_NumColorDrawBuffers; i++) {
> - GLuint b = ctx->DrawBuffer->_ColorDrawBufferIndexes[i];
> + GLint b = ctx->DrawBuffer->_ColorDrawBufferIndexes[i];
>  
>   if (b >= 0 && mask & (1 << b)) {
>  struct gl_renderbuffer *rb
> 

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

Re: [Mesa-dev] [PATCH] st/mesa: use signed temporary variable to store _ColorDrawBufferIndexes

[Marek Olšák]

On Wed, Jan 15, 2014 at 12:49 PM, Emil Velikov  wrote:
> The temporary variable used to store _ColorDrawBufferIndexes must be
> signed (GLint), otherwise the following conditional will be incorrectly
> evaluated. Leading to crashes in the driver/mesa or accessing/writing
> to arbitrary memory location. The bug dates back to 2009.
>
> Cc: 10.0 9.2 9.1 
> Signed-off-by: Emil Velikov 
> ---
>
> Rather old bug, spotted after Marek's recent patches covering the
> area. Curious if there is any particular reason why we do not
> enable more compiler warning messages.
>
> How do people feel on the subject of enabling more (all even) compiler
> warnings on gcc compatible compilers ?

Some warnings tend to be annoying and not useful. For the patch:

Reviewed-by: Marek Olšák 

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

[Mesa-dev] RFC: ARB_arrays_of_arrays work in progress

[Timothy Arceri]

First of all sorry for my first post being a reply to Ians 10.1 release
plan. 

Secondly I've rebased my work on current master and reimplemented my
work using the approach I mention in my last email. The changes are half
the size and now some basic execution tests are passing. The new branch
is here: https://github.com/tarceri/Mesa_arrays_of_arrays/tree/wip8

However I'm having an issue where if I'm running the tests using a
command like 
./piglit-run.py -t ARB_arrays_of_arrays/compiler* tests/all.tests
results/array_of_array

Some of the tests crash with this error: 
glslparsertest: brw_eu_emit.c:305: brw_set_src0: Assertion `reg.nr <
128' failed.

But when I run them directly using glslparsertest they don't crash.
Anyone know why this would be happening? I looked at the assert but it
didn't really make any sense to me.

In case it helps I'm using the build options ./autogen.sh
--prefix=/opt/xorg --enable-texture-float --with-dri-drivers="i965"
--with-llvm-shared-libs --disable-dri3 --with-gallium-drivers=""
on Fedora 19

Thanks,
Tim 



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

Re: [Mesa-dev] [PATCH] st/mesa: use signed temporary variable to store _ColorDrawBufferIndexes

[Emil Velikov]

On 15/01/14 12:11, Marek Olšák wrote:
> On Wed, Jan 15, 2014 at 12:49 PM, Emil Velikov  
> wrote:
>> The temporary variable used to store _ColorDrawBufferIndexes must be
>> signed (GLint), otherwise the following conditional will be incorrectly
>> evaluated. Leading to crashes in the driver/mesa or accessing/writing
>> to arbitrary memory location. The bug dates back to 2009.
>>
>> Cc: 10.0 9.2 9.1 
>> Signed-off-by: Emil Velikov 
>> ---
>>
>> Rather old bug, spotted after Marek's recent patches covering the
>> area. Curious if there is any particular reason why we do not
>> enable more compiler warning messages.
>>
>> How do people feel on the subject of enabling more (all even) compiler
>> warnings on gcc compatible compilers ?
> 
> Some warnings tend to be annoying and not useful. For the patch:
> 
Indeed, especially if there are thousands of them.
-Wall -Wextra -Wconversion produces ~ 31k warnings :)

Although -Wtype-limits sounds very interesting.

Thanks for the review Marek

Emil

> Reviewed-by: Marek Olšák 
> 
> Marek
> 

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

Re: [Mesa-dev] gallium endianness and hw drivers

[Erik Faye-Lund]

On Wed, Jan 15, 2014 at 7:07 AM, Michel Dänzer  wrote:
> On Die, 2014-01-14 at 00:22 +0100, Marek Olšák wrote:
>> I think the format conversion functions should look like:
>>
>> #ifdef BIG_ENDIAN
>>case PIPE_FORMAT_A8B8G8R8_UNORM:
>>   return hw_format_for_R8G8B8A8_UNORM;
>> ...
>> #else
>>case PIPE_FORMAT_R8G8B8A8_UNORM:
>>   return hw_format_for_R8G8B8A8_UNORM;
>> #endif
>>
>> which can be simplified to:
>>
>>case PIPE_FORMAT_RGBA_UNORM:
>>   return hw_format_for_R8G8B8A8_UNORM;
>>
>> So that the GPU can see the same formats, but they are different for the CPU.
>>
>> What do you think?
>
> That might be an option, but PIPE_FORMAT_R8G8B8A8_UNORM is useful on big
> endian hosts as well, e.g. it matches GL_RGBA / GL_UNSIGNED_BYTE
> exactly.

Well, there's the added complication that GL_RGBA / GL_UNSIGNED_BYTE
can be specified with an unaligned pointer on architectures that does
not support unaligned reads (e.g ARM), and packed formats cannot. And
then there's GL_RGB / GL_UNSIGNED_BYTE which further messes the
treat-array-formats-as-if-they-were-packed strategy.

> I think one issue here is that we're trying to use a single format
> attribute for several purposes (API visible representation, GPU/driver
> internal representation).

Indeed, and if we stopped doing that, the issues above should be solvable.

I've actually been involved in the successful shipping of an OpenGL ES
2.0 implementation written for little-endian machines, on a big-endian
machine. But we had the benefit of being able to make
hardware-modifications, which made this a whole lot easier. IIRC, we
just made the texture-fetches and pixel-writes use native endianess.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] xwayland: device isn't even open that explains why drmGetCap fails and it advertises no Prime capabilities

[Igor Gnatenko]

Since d9769c193765ac303ad4d4760e57ff368df1f663 DRI_PRIME=1 works
isn't correctly.

1. $ xrandr --listproviders
   Providers: number : 2
   Provider 0: id: 0x7b cap: 0x0 crtcs: 2 outputs: 4 associated
providers: 0 name:Intel
   Provider 1: id: 0x55 cap: 0xf, Source Output, Sink Output, Source
Offload, Sink Offload crtcs: 6 outputs: 0 associated providers: 0
name:radeon

2. $ xrandr --setprovideroffloadsink 0x55 0x7b
   X Error of failed request:  BadValue (integer parameter out of range
for operation)
 Major opcode of failed request:  139 (RANDR)
 Minor opcode of failed request:  34 ()
 Value in failed request:  0x7b
 Serial number of failed request:  16
 Current serial number in output stream:  17

Reported-and-tested-by: Kirill Rusinov 
Signed-off-by: Igor Gnatenko 
Signed-off-by: Axel Davy 
Reference: https://bugzilla.redhat.com/show_bug.cgi?id=1033903
---
 src/uxa/intel_driver.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/src/uxa/intel_driver.c b/src/uxa/intel_driver.c
index 1c38075..c5d85c8 100644
--- a/src/uxa/intel_driver.c
+++ b/src/uxa/intel_driver.c
@@ -549,6 +549,12 @@ static Bool I830PreInit(ScrnInfoPtr scrn, int flags)
 
intel->PciInfo = xf86GetPciInfoForEntity(intel->pEnt->index);
 
+   if (!xorgWayland && (!intel_open_drm_master(scrn))) {
+   xf86DrvMsg(scrn->scrnIndex, X_ERROR,
+  "Failed to become DRM master.\n");
+   return FALSE;
+   }
+
scrn->monitor = scrn->confScreen->monitor;
scrn->progClock = TRUE;
scrn->rgbBits = 8;
@@ -604,14 +610,13 @@ static Bool I830PreInit(ScrnInfoPtr scrn, int flags)
}
 
intel->drmSubFD = xwl_screen_get_drm_fd(intel->xwl_screen);
+
+   if (!intel->xwl_screen && !intel_open_drm_master(scrn))
+   xf86DrvMsg(scrn->scrnIndex, X_ERROR,
+  "Failed to become DRM master.\n");
}
 #endif
 
-   if (!intel->xwl_screen && !intel_open_drm_master(scrn))
-   xf86DrvMsg(scrn->scrnIndex, X_ERROR,
-  "Failed to become DRM master.\n");
-
-
if (!intel_init_bufmgr(intel)) {
PreInitCleanup(scrn);
return FALSE;
-- 
1.8.4.2

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

[Mesa-dev] [PATCH] opencl: use versioned .so in mesa.icd

[Igor Gnatenko]

We must have versioned library in mesa.icd, because ICD loader would
fail if the mesa-devel package wasn't installed.

Reported-by: Fabian Deutsch 
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=73512
Signed-off-by: Igor Gnatenko 
---
 configure.ac   | 3 +++
 src/gallium/targets/opencl/Makefile.am | 2 +-
 src/gallium/targets/opencl/mesa.icd| 1 -
 src/gallium/targets/opencl/mesa.icd.in | 1 +
 4 files changed, 5 insertions(+), 2 deletions(-)
 delete mode 100644 src/gallium/targets/opencl/mesa.icd
 create mode 100644 src/gallium/targets/opencl/mesa.icd.in

diff --git a/configure.ac b/configure.ac
index 4da6c51..c195b1b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -25,6 +25,8 @@ m4_ifdef([AM_PROG_AR], [AM_PROG_AR])
 dnl Set internal versions
 OSMESA_VERSION=8
 AC_SUBST([OSMESA_VERSION])
+OPENCL_VERSION=1
+AC_SUBST([OPENCL_VERSION])
 
 dnl Versions for external dependencies
 LIBDRM_REQUIRED=2.4.24
@@ -2023,6 +2025,7 @@ AC_CONFIG_FILES([Makefile
src/gallium/targets/egl-static/Makefile
src/gallium/targets/gbm/Makefile
src/gallium/targets/opencl/Makefile
+   src/gallium/targets/opencl/mesa.icd
src/gallium/targets/osmesa/Makefile
src/gallium/targets/osmesa/osmesa.pc
src/gallium/targets/pipe-loader/Makefile
diff --git a/src/gallium/targets/opencl/Makefile.am 
b/src/gallium/targets/opencl/Makefile.am
index 653302c..3b257ca 100644
--- a/src/gallium/targets/opencl/Makefile.am
+++ b/src/gallium/targets/opencl/Makefile.am
@@ -4,7 +4,7 @@ lib_LTLIBRARIES = lib@OPENCL_LIBNAME@.la
 
 lib@OPENCL_LIBNAME@_la_LDFLAGS = \
$(LLVM_LDFLAGS) \
-   -version-number 1:0
+   -version-number @OPENCL_VERSION@:0
 
 lib@OPENCL_LIBNAME@_la_LIBADD = \
$(top_builddir)/src/gallium/auxiliary/pipe-loader/libpipe_loader.la \
diff --git a/src/gallium/targets/opencl/mesa.icd 
b/src/gallium/targets/opencl/mesa.icd
deleted file mode 100644
index 6a6a870..000
--- a/src/gallium/targets/opencl/mesa.icd
+++ /dev/null
@@ -1 +0,0 @@
-libMesaOpenCL.so
diff --git a/src/gallium/targets/opencl/mesa.icd.in 
b/src/gallium/targets/opencl/mesa.icd.in
new file mode 100644
index 000..1b77b4e
--- /dev/null
+++ b/src/gallium/targets/opencl/mesa.icd.in
@@ -0,0 +1 @@
+lib@OPENCL_LIBNAME@.so.@OPENCL_VERSION@
-- 
1.8.4.2

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

Re: [Mesa-dev] gallium endianness and hw drivers

[Marek Olšák]

On Wed, Jan 15, 2014 at 7:07 AM, Michel Dänzer  wrote:
> On Die, 2014-01-14 at 00:22 +0100, Marek Olšák wrote:
>> I think the format conversion functions should look like:
>>
>> #ifdef BIG_ENDIAN
>>case PIPE_FORMAT_A8B8G8R8_UNORM:
>>   return hw_format_for_R8G8B8A8_UNORM;
>> ...
>> #else
>>case PIPE_FORMAT_R8G8B8A8_UNORM:
>>   return hw_format_for_R8G8B8A8_UNORM;
>> #endif
>>
>> which can be simplified to:
>>
>>case PIPE_FORMAT_RGBA_UNORM:
>>   return hw_format_for_R8G8B8A8_UNORM;
>>
>> So that the GPU can see the same formats, but they are different for the CPU.
>>
>> What do you think?
>
> That might be an option, but PIPE_FORMAT_R8G8B8A8_UNORM is useful on big
> endian hosts as well, e.g. it matches GL_RGBA / GL_UNSIGNED_BYTE
> exactly.

I wouldn't worry about such optimizations when we don't even have
proper big endian support. I'd rather stick to the simplest solution
for the old hardware.

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

[Mesa-dev] [RFC] freedreno: add tgsi lowering pass

[Rob Clark]

From: Rob Clark 

So, as I found myself needing to lower a few more TGSI instructions,
and noticing yet again that I would have to do the same lowering as
various other gallium drivers already do,  I decided that maybe it
makes sense to do this instead generically in a way that could maybe
help other drivers too.

This currently lowers the following instructions:

   DST, XPD, SCS, LRP, FRC, POW, LIT, EXP, LOG

translating these into equivalent simpler TGSI instructions.  There
are probably more that could be lowered.  These are just common
instructions, and/or ones I ran across in some piglit tests, which
I needed to lower.  I might add the various DP permutations as well,
which would let me get rid of even more lower-directly-to-native
code in fd3_compiler.

I was sort of wondering about sticking this in aux/util or aux/tgsi,
and somehow making it configurable which instructions to lower, since
it seems that it could be useful to other drivers?

---
 src/gallium/drivers/freedreno/Makefile.sources |1 +
 src/gallium/drivers/freedreno/a3xx/fd3_program.c   |7 +-
 src/gallium/drivers/freedreno/freedreno_lowering.c | 1037 
 src/gallium/drivers/freedreno/freedreno_lowering.h |   36 +
 4 files changed, 1079 insertions(+), 2 deletions(-)
 create mode 100644 src/gallium/drivers/freedreno/freedreno_lowering.c
 create mode 100644 src/gallium/drivers/freedreno/freedreno_lowering.h

diff --git a/src/gallium/drivers/freedreno/Makefile.sources 
b/src/gallium/drivers/freedreno/Makefile.sources
index 092b09f..3dcec9d 100644
--- a/src/gallium/drivers/freedreno/Makefile.sources
+++ b/src/gallium/drivers/freedreno/Makefile.sources
@@ -1,5 +1,6 @@
 C_SOURCES := \
freedreno_util.c \
+   freedreno_lowering.c \
freedreno_query.c \
freedreno_fence.c \
freedreno_resource.c \
diff --git a/src/gallium/drivers/freedreno/a3xx/fd3_program.c 
b/src/gallium/drivers/freedreno/a3xx/fd3_program.c
index 0886c49..ad76b66 100644
--- a/src/gallium/drivers/freedreno/a3xx/fd3_program.c
+++ b/src/gallium/drivers/freedreno/a3xx/fd3_program.c
@@ -34,6 +34,8 @@
 #include "tgsi/tgsi_dump.h"
 #include "tgsi/tgsi_parse.h"
 
+#include "freedreno_lowering.h"
+
 #include "fd3_program.h"
 #include "fd3_compiler.h"
 #include "fd3_emit.h"
@@ -87,6 +89,7 @@ create_shader(struct pipe_context *pctx, const struct 
pipe_shader_state *cso,
enum shader_t type)
 {
struct fd3_shader_stateobj *so = CALLOC_STRUCT(fd3_shader_stateobj);
+   const struct tgsi_token *tokens = fd_transform_lowering(cso->tokens);
int ret;
 
if (!so)
@@ -96,13 +99,13 @@ create_shader(struct pipe_context *pctx, const struct 
pipe_shader_state *cso,
 
if (fd_mesa_debug & FD_DBG_DISASM) {
DBG("dump tgsi: type=%d", so->type);
-   tgsi_dump(cso->tokens, 0);
+   tgsi_dump(tokens, 0);
}
 
if ((type == SHADER_FRAGMENT) && (fd_mesa_debug & FD_DBG_FRAGHALF))
so->half_precision = true;
 
-   ret = fd3_compile_shader(so, cso->tokens);
+   ret = fd3_compile_shader(so, tokens);
if (ret) {
debug_error("compile failed!");
goto fail;
diff --git a/src/gallium/drivers/freedreno/freedreno_lowering.c 
b/src/gallium/drivers/freedreno/freedreno_lowering.c
new file mode 100644
index 000..354969f
--- /dev/null
+++ b/src/gallium/drivers/freedreno/freedreno_lowering.c
@@ -0,0 +1,1037 @@
+/* -*- mode: C; c-file-style: "k&r"; tab-width 4; indent-tabs-mode: t; -*- */
+
+/*
+ * Copyright (C) 2014 Rob Clark 
+ *
+ * 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.
+ *
+ * Authors:
+ *Rob Clark 
+ */
+
+#include "tgsi/tgsi_transform.h"
+#include "tgsi/tgsi_scan.h"
+#include "tgsi/tgsi_dump.h"
+
+#include "util/u_debug.h"
+#include "util/u_math.h"
+
+#include "freedreno_lowering.h"
+
+struct fd_lowering_context {
+   struct tg

Re: [Mesa-dev] EXTERNAL: Re: OpenCL Clang/Clover Offline Compilation issue

[Dorrington, Albert]

Hi Francisco,

I implemented the patch on my system and rebuilt my two programs. 

Reran my "online compile with save" program to generate a new 'compiled kernel' 
and then reran the "load compiled kernel" program; and it worked without 
errors, executing the kernel properly.
So, it looks like the Mesa implementation of clCreateProgramWithBinary() now 
functions, for the LLVM IR generated code, which is great!

I have re-read the Khronos OpenCL spec for clGetProgramInfo() and 
clCreateProgramWithBinary() to clarify my understanding.
It looks like clGetProgramInfo() can return either IR, a device specific 
binary, or both; while clCreateProgramWithBinary() can accept IR and/or a 
device specific binary.

For our purposes, we were expecting the device specific binary, not the IR, so 
that we would not need to compile, or run LLVM on our target environment.

Looks like I need to spend some more time understanding the code and 
architecture :)

-Al

-Original Message-
From: Francisco Jerez [mailto:curroje...@riseup.net] 
Sent: Tuesday, January 14, 2014 4:18 PM

Hi Albert, can you give the attached patch a try?  It fixes a couple of issues 
I've found in the clCreateProgramWithBinary path.  Let me know if it helps.

Thanks.


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

Re: [Mesa-dev] [PATCH] mesa: rename MESA format names to have the same names as PIPE formats

[Kenneth Graunke]

On 01/14/2014 08:15 AM, Brian Paul wrote:
> On 01/14/2014 05:49 AM, Marek Olšák wrote:
>> On Sat, Jan 11, 2014 at 4:19 AM, Mark Mueller 
>> wrote:
>>> The predominant feedback on this adventure has been to make the
>>> MESA_FORMATs
>>> match the PIPE, or gallium formats but every journey I've made down that
>>> path has been fraught with peril. There are some cases where
>>> PIPE_FORMATs
>>> are even more confusing then MESA_FORMATs*. Either there is something
>>> that I
>>> am missing, or there are things about the PIPE_FORMATS that people
>>> aren't
>>> aware of, so let me pull out some specific references.
>>>
>>> The first problem is that in PIPE_FORMATS there is no distinction
>>> between
>>> array and packed formats, and this has proven to be a big cause for
>>> format
>>> ambiguity that some are wanting to see addressed. One proposed
>>> solution is
>>> to represent array formats like (hypothetically): R8G8B8A8; and packed
>>> formats as RGBA_ (or vice versa) in the MESA_FORMATs and
>>> subsequently
>>> modifying the PIPE_FORMATs to suit. But that makes RGBA_1010102 kinda
>>> messy
>>> (though it could be RGBA_aaa2). So then how to handle this:
>>>
>>> So how about a poll! Isn't that the rage these days?
>>>
>>>
>>> Please vote on:
>>>
>>>
>>> 1) Should MESA_FORMAT names clearly distinguish between array and packed
>>> formats, yes or no?
>>
>> Yes.
> 
> Agreed.
> 
> 
>>
>>> 2) What is your preference for array format naming convention:
>>>
>>>  a) RGBA_UNORM
>>>
>>>  b) R8G8B8A8_UNORM
>>>
>>>  c) RGBA_UNORM8
>>
>> B or C. C is cleaner, B is used by gallium. I'll leave that decision
>> to you.
> 
> I prefer C there.
> 
> 
>>
>>> 3) What is your preference for packed format naming convention:
>>>
>>> a) RGBA5551_UNORM
>>>
>>> b) R5G5B5A1_UNORM
>>
>> if the final answer to (2) is C, then B. Otherwise A. B is more
>> readable for formats like Z24S8 as opposed to ZS248.
> 
> I prefer B.
> 
> 
>>
>>> 4) What is your preference for naming packed formats with 10 or more
>>> bits:
>>>
>>> a) RGBA1010102_UNORM
>>>
>>> b) R10G10B10A2_UNORM
>>>
>>> c) RGBAaaa2_UNORM
>>>
>>> d) Croque-monsieur
>>
>> Same as (3).
> 
> B again.
> 
> 
> -Brian

I agree with Brian and Michel.

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

Re: [Mesa-dev] EXTERNAL: Re: OpenCL Clang/Clover Offline Compilation issue

[Francisco Jerez]

"Dorrington, Albert"  writes:

> Hi Francisco,
>
> I implemented the patch on my system and rebuilt my two programs. 
>
> Reran my "online compile with save" program to generate a new 'compiled 
> kernel' and then reran the "load compiled kernel" program; and it worked 
> without errors, executing the kernel properly.
> So, it looks like the Mesa implementation of clCreateProgramWithBinary() now 
> functions, for the LLVM IR generated code, which is great!
>

That's awesome, I'll merge it to master shortly.

> I have re-read the Khronos OpenCL spec for clGetProgramInfo() and 
> clCreateProgramWithBinary() to clarify my understanding.
> It looks like clGetProgramInfo() can return either IR, a device specific 
> binary, or both; while clCreateProgramWithBinary() can accept IR and/or a 
> device specific binary.
>

Yeah, well, it's up to the implementation how device-specific the
binaries are.  On r600 they're roughly half-way through the compilation
process.  If that's not satisfactory to you, you could try to get clang
to generate binaries directly in the clover format (or even better, get
clover to understand ELF object files instead of the non-standard format
we use now for serializing module objects) and get rid of the two-stage
compilation process.  That way clover will have access to the actual GPU
binaries.

> For our purposes, we were expecting the device specific binary, not the IR, 
> so that we would not need to compile, or run LLVM on our target environment.
>
Is it that much overhead?  AFAIK a compliant OpenCL implementation has
to include a compiler anyway, unless you're trying to do embedded
profile.  Is that what you have in mind?

> Looks like I need to spend some more time understanding the code and 
> architecture :)

Thanks.
>
> -Al
>
> -Original Message-
> From: Francisco Jerez [mailto:curroje...@riseup.net] 
> Sent: Tuesday, January 14, 2014 4:18 PM
>
> Hi Albert, can you give the attached patch a try?  It fixes a couple of 
> issues I've found in the clCreateProgramWithBinary path.  Let me know if it 
> helps.
>
> Thanks.


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

Re: [Mesa-dev] [PATCH 5/5] i965: Enable AOS optimizations for the geometry shader.

[Kenneth Graunke]

On 01/08/2014 12:43 PM, Matt Turner wrote:
> ---
>  src/mesa/drivers/dri/i965/brw_context.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
> b/src/mesa/drivers/dri/i965/brw_context.c
> index da34e3d..3da328a 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.c
> +++ b/src/mesa/drivers/dri/i965/brw_context.c
> @@ -479,6 +479,7 @@ brw_initialize_context_constants(struct brw_context *brw)
> }
>  
> ctx->ShaderCompilerOptions[MESA_SHADER_VERTEX].OptimizeForAOS = true;
> +   ctx->ShaderCompilerOptions[MESA_SHADER_GEOMETRY].OptimizeForAOS = true;
>  }
>  
>  /**
> 

Patches 2 and 5 are:
Reviewed-by: Kenneth Graunke 

I sadly haven't had time to review the patches of substance (3 and 4)
yet.  Ian's review is probably sufficient though, so you don't need to
wait for me or anything.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [wip 0/9] GL_OES_get_program_binary extension

[Kenneth Graunke]

On 01/02/2014 03:58 AM, Tapani Pälli wrote:
> Hi;
> 
> Here's another take on the get_program_binary extension. I've rewritten big 
> chunks of it based on Paul's review and comments earlier. Here's a brief list 
> out of my head of things changed:
> 
> - uses mesa compilation time as verification method for cache, not git sha
> - much smaller serialization code size, now as part of IR classes
> - smaller binary blob size
> - does not dump separate 'prototypes block' for functions but instead
>  deserialization iterates over the whole blob for functions first
> - hashtables written faster than previously (iterated only once)
> - no 'unique_id' for ir_variables but using the address as identifier
> - patch set broken down to more individual patches/changes
> 
> Mesa branch with these patches applied on top:
> http://cgit.freedesktop.org/~tpalli/mesa/log/?h=oes_get_program_binary
> 
> I have plans for the addition of driver backend data but I was hoping this to 
> be as a separate addition on top. Basically I extend gl_shader_program struct 
> and offer API for drivers to dump their binary data there, some proto here:
> 
> http://cgit.freedesktop.org/~tpalli/mesa/log/?h=driver_interface
> (in order to work more data needed like the keys but this is just test)
> 
> I have also 'automatic' cache implementation here that can be used to verify 
> the cache functionality with any application (without extension):
> http://cgit.freedesktop.org/~tpalli/mesa/log/?h=new_serialization
> 
> Any comments appreciated;
> 
> Tapani Pälli (9):
>   glsl: memory_writer helper class for data serialization
>   glsl: serialize methods for IR instructions
>   glsl: memory_map helper class for data deserialization
>   glsl: add MESA_SHADER_CACHE_MAGIC string for shader binary cache
>   glsl: export populate_symbol_table function
>   glsl: ir_deserializer class for the binary shader cache
>   mesa: iterate method for string_to_uint_map
>   glsl: functions to serialize gl_shader and gl_shader_program
>   mesa: OES_get_program_binary extension functionality

Skimming through Paul's review comments...it sounds like there are a lot
of cases where your code has not handled invalid data gracefully.
That's not a critique of you or your code - there are a million cases to
consider, and it's really easy to miss one.

But, it sounds like there might be a lot of value in fuzz-testing this
extension (i.e. providing random data, or data with some structure but
invalid in specific places...).  We should probably be as mean as
possible in our testing up front to avoid security issues later.

--Ken

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

Re: [Mesa-dev] [wip 9/9] mesa: OES_get_program_binary extension functionality

[Paul Berry]

On 2 January 2014 03:58, Tapani Pälli  wrote:

> Signed-off-by: Tapani Pälli 
> ---
>  src/mesa/main/shaderapi.c | 44
> ++--
>  1 file changed, 38 insertions(+), 6 deletions(-)
>
> diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
> index 57511e8..c07b226 100644
> --- a/src/mesa/main/shaderapi.c
> +++ b/src/mesa/main/shaderapi.c
> @@ -57,6 +57,7 @@
>  #include "../glsl/ir.h"
>  #include "../glsl/ir_uniform.h"
>  #include "../glsl/program.h"
> +#include "../glsl/shader_cache.h"
>
>  /** Define this to enable shader substitution (see below) */
>  #define SHADER_SUBST 0
> @@ -1632,8 +1633,26 @@ _mesa_GetProgramBinary(GLuint program, GLsizei
> bufSize, GLsizei *length,
> if (length != NULL)
>*length = 0;
>
> -   (void) binaryFormat;
> -   (void) binary;
> +   size_t size = 0;
> +   char *data = mesa_program_serialize(shProg, &size);
> +
> +   /* we have more data that can fit to user given buffer */
> +   if (size > bufSize) {
> +  _mesa_error(ctx, GL_INVALID_OPERATION, __FUNCTION__);
> +  if (data)
> + free(data);
>

Why would we ever expect mesa_program_serialize to set size to a nonzero
value but return NULL?  It seems like this could only happen if there's a
bug, in which case this really ought to be

assert(data !=NULL);

Also, it's safe to call free() on a NULL pointer.  According to the C
standard, freeing a NULL pointer does nothing.


> +  return;
> +   }
> +
> +   if (data) {
>

Similarly, this if-statement is unnecessary.


> +  memcpy(binary, data, size);
> +  free(data);
> +   }
> +
> +   if (length != NULL)
> +  *length = size;
> +
> +   *binaryFormat = 0;
>  }
>
>  void GLAPIENTRY
> @@ -1647,10 +1666,23 @@ _mesa_ProgramBinary(GLuint program, GLenum
> binaryFormat,
> if (!shProg)
>return;
>
> -   (void) binaryFormat;
> -   (void) binary;
> -   (void) length;
> -   _mesa_error(ctx, GL_INVALID_OPERATION, __FUNCTION__);
> +   if (length <= 0)
> +  return;
>

In the case of an invalid length, we need to make sure to set the program's
LinkStatus to false.  Also, the information log needs to be cleared, in
accordance with this text from OES_get_program_binary:

If ProgramBinaryOES failed, any information about a previous link or
load of
that program object is lost.  Thus, a failed load does not restore the
old
state of .



> +
> +   /* free possible existing data and initialize structure */
> +   _mesa_free_shader_program_data(ctx, shProg);
> +   _mesa_init_shader_program(ctx, shProg);
> +
> +   /* fill structure from a binary blob */
> +   if (mesa_program_deserialize(shProg, binary, length)) {
> +  _mesa_error(ctx, GL_INVALID_VALUE, "glProgramBinary(binary
> incompatible)");
>

This seems wrong to me.  From the OES_get_program_binary spec:

...  and  must be
those returned by a previous call to GetProgramBinaryOES, and 
must
be the length of the program binary as returned by GetProgramBinaryOES
or
GetProgramiv with  PROGRAM_BINARY_LENGTH_OES.  The program binary
will fail to load if these conditions are not met.

...

A program object's program binary is replaced by calls to LinkProgram or
ProgramBinaryOES.  Either command sets the program object's LINK_STATUS
to
TRUE or FALSE, as queried with GetProgramiv, to reflect success or
failure.
Either command also updates its information log, queried with
GetProgramInfoLog, to provide details about warnings or errors.

I believe this means that if deserialization fails, it should not be a GL
error.  It should simply be treated as a link failure.


> +  return;
> +   }
> +
> +   /* driver specific link, optimizations and what not */
> +   ctx->Driver.LinkShader(ctx, shProg);
>

Now I'm confused.  I thought a major part of the purpose of this extension
was that it would store the post-link program, so that not only does
glProgramBinary() avoid the runtime penalty of parsing and compiling, it
also avoids the runtime penalty of link-time optimizations.  Calling
ctx->Driver.LinkShader seems like it defeats that purpose.  It seems like
what we ought to be doing is store the data that ctx->Driver.LinkShader
*produces* in the binary blob, so that once it's loaded there's no further
linking necessary.  If there is a small amount of driver-specific hook
necessary, that should be placed in a new ctx->Driver function rather than
incurring the overhead of another link.


> +
> +   _mesa_ValidateProgram(program);
>

I don't think this is correct.  ValidateProgram() doesn't mean "check that
the program is well-formed".  It means "check whether the program can
execute given the current GL state".  A lot of GL apps compile all their
shaders during startup, long before they've established the correct GL
state for running those programs.  It's reasonable to assume that apps
using this extension will make their calls to glProgramBinary() during
startup as well.  So calling ValidateProgram() from gl

Re: [Mesa-dev] [wip 0/9] GL_OES_get_program_binary extension

[Paul Berry]

On 2 January 2014 03:58, Tapani Pälli  wrote:

> Hi;
>
> Here's another take on the get_program_binary extension. I've rewritten big
> chunks of it based on Paul's review and comments earlier. Here's a brief
> list
> out of my head of things changed:
>
> - uses mesa compilation time as verification method for cache, not git sha
> - much smaller serialization code size, now as part of IR classes
> - smaller binary blob size
> - does not dump separate 'prototypes block' for functions but instead
>  deserialization iterates over the whole blob for functions first
> - hashtables written faster than previously (iterated only once)
> - no 'unique_id' for ir_variables but using the address as identifier
> - patch set broken down to more individual patches/changes
>
> Mesa branch with these patches applied on top:
> http://cgit.freedesktop.org/~tpalli/mesa/log/?h=oes_get_program_binary
>
> I have plans for the addition of driver backend data but I was hoping this
> to
> be as a separate addition on top. Basically I extend gl_shader_program
> struct
> and offer API for drivers to dump their binary data there, some proto here:
>
> http://cgit.freedesktop.org/~tpalli/mesa/log/?h=driver_interface
> (in order to work more data needed like the keys but this is just test)
>
> I have also 'automatic' cache implementation here that can be used to
> verify
> the cache functionality with any application (without extension):
> http://cgit.freedesktop.org/~tpalli/mesa/log/?h=new_serialization
>
> Any comments appreciated;
>
> Tapani Pälli (9):
>   glsl: memory_writer helper class for data serialization
>   glsl: serialize methods for IR instructions
>   glsl: memory_map helper class for data deserialization
>   glsl: add MESA_SHADER_CACHE_MAGIC string for shader binary cache
>   glsl: export populate_symbol_table function
>   glsl: ir_deserializer class for the binary shader cache
>   mesa: iterate method for string_to_uint_map
>   glsl: functions to serialize gl_shader and gl_shader_program
>   mesa: OES_get_program_binary extension functionality
>

I sent comments on all patches but 4, 5, and 7.  Those patches are:

Reviewed-by: Paul Berry 

I see that you've already responded to some of my comments.  I'm on a
business trip this week so I have limited time to answer email, but I'll
try to respond to your responses as soon as I can.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] EXTERNAL: Re: OpenCL Clang/Clover Offline Compilation issue

[Dorrington, Albert]

> -Original Message-
> From: Francisco Jerez [mailto:curroje...@riseup.net]
> Sent: Wednesday, January 15, 2014 10:35 AM
> 
> Yeah, well, it's up to the implementation how device-specific the binaries
> are.  On r600 they're roughly half-way through the compilation process.  If
> that's not satisfactory to you, you could try to get clang to generate 
> binaries
> directly in the clover format (or even better, get clover to understand ELF
> object files instead of the non-standard format we use now for serializing
> module objects) and get rid of the two-stage compilation process.  That way
> clover will have access to the actual GPU binaries.

I think getting Clover to understand the ELF format would be useful, and 
conform to the OpenCL spec.
Having it be able to output the ELF format from clGetProgramInfo() via the 
CL_PROGRAM_BINARIES would be something that would impact the Mesa drivers 
significantly; Since it would require moving the final binary generation from 
the drivers into the state tracker.

> >
> Is it that much overhead?  AFAIK a compliant OpenCL implementation has to
> include a compiler anyway, unless you're trying to do embedded profile.  Is
> that what you have in mind?
> 

We are targeting the embedded profile and since our target is also a real-time 
environment, there are concerns about how online compiles might affect the 
environment.

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

[Mesa-dev] [PATCH v2 RFC 1/1] clover: Don't crash on NULL global buffer objects.

[Jan Vesely]

Specs say "If the argument is a buffer object, the arg_value
pointer can be NULL or point to a NULL value in which case a NULL
value will be used as the value for the argument declared as a
pointer to __global or __constant memory in the kernel."

So don't crash when somebody does that.

v2: Insert NULL into input buffer instead of buffer handle pair
Fix constant_argument too
Drop r600 driver changes

Signed-off-by: Jan Vesely 
---
Hi Francisco,

I could not find much info about how ctx.input is supposed to be used.
It looks like it stores begin-end intervals of parameters so NULL, NULL
seemed appropriate.

Is this closer to what you had in mind? This patch fixes my issue
even without the r600 changes.

regards,
Jan

 src/gallium/state_trackers/clover/core/kernel.cpp | 34 +--
 1 file changed, 20 insertions(+), 14 deletions(-)

diff --git a/src/gallium/state_trackers/clover/core/kernel.cpp 
b/src/gallium/state_trackers/clover/core/kernel.cpp
index 58780d6..d4942b3 100644
--- a/src/gallium/state_trackers/clover/core/kernel.cpp
+++ b/src/gallium/state_trackers/clover/core/kernel.cpp
@@ -327,16 +327,19 @@ kernel::global_argument::set(size_t size, const void 
*value) {
if (size != sizeof(cl_mem))
   throw error(CL_INVALID_ARG_SIZE);
 
-   buf = &obj(*(cl_mem *)value);
+   buf = pobj(value ? *(cl_mem *)value : NULL);
_set = true;
 }
 
 void
 kernel::global_argument::bind(exec_context &ctx,
   const module::argument &marg) {
-   align(ctx.input, marg.target_align);
-   ctx.g_handles.push_back(allocate(ctx.input, marg.target_size));
-   ctx.g_buffers.push_back(buf->resource(*ctx.q).pipe);
+   if (buf) {
+  align(ctx.input, marg.target_align);
+  ctx.g_handles.push_back(allocate(ctx.input, marg.target_size));
+  ctx.g_buffers.push_back(buf->resource(*ctx.q).pipe);
+   } else
+  insert(ctx.input, {NULL, NULL});
 }
 
 void
@@ -379,22 +382,25 @@ kernel::constant_argument::set(size_t size, const void 
*value) {
if (size != sizeof(cl_mem))
   throw error(CL_INVALID_ARG_SIZE);
 
-   buf = &obj(*(cl_mem *)value);
+   buf = pobj(value ? *(cl_mem *)value : NULL);
_set = true;
 }
 
 void
 kernel::constant_argument::bind(exec_context &ctx,
 const module::argument &marg) {
-   auto v = bytes(ctx.resources.size() << 24);
-
-   extend(v, module::argument::zero_ext, marg.target_size);
-   byteswap(v, ctx.q->dev.endianness());
-   align(ctx.input, marg.target_align);
-   insert(ctx.input, v);
-
-   st = buf->resource(*ctx.q).bind_surface(*ctx.q, false);
-   ctx.resources.push_back(st);
+   if (buf) {
+  auto v = bytes(ctx.resources.size() << 24);
+
+  extend(v, module::argument::zero_ext, marg.target_size);
+  byteswap(v, ctx.q->dev.endianness());
+  align(ctx.input, marg.target_align);
+  insert(ctx.input, v);
+
+  st = buf->resource(*ctx.q).bind_surface(*ctx.q, false);
+  ctx.resources.push_back(st);
+   } else
+  insert(ctx.input, {NULL, NULL});
 }
 
 void
-- 
1.8.4.2

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

Re: [Mesa-dev] EXTERNAL: Re: OpenCL Clang/Clover Offline Compilation issue

[Francisco Jerez]

"Dorrington, Albert"  writes:

>> -Original Message-
>> From: Francisco Jerez [mailto:curroje...@riseup.net]
>> Sent: Wednesday, January 15, 2014 10:35 AM
>> 
>> Yeah, well, it's up to the implementation how device-specific the binaries
>> are.  On r600 they're roughly half-way through the compilation process.  If
>> that's not satisfactory to you, you could try to get clang to generate 
>> binaries
>> directly in the clover format (or even better, get clover to understand ELF
>> object files instead of the non-standard format we use now for serializing
>> module objects) and get rid of the two-stage compilation process.  That way
>> clover will have access to the actual GPU binaries.
>
> I think getting Clover to understand the ELF format would be useful, and 
> conform to the OpenCL spec.
> Having it be able to output the ELF format from clGetProgramInfo() via the 
> CL_PROGRAM_BINARIES would be something that would impact the Mesa drivers 
> significantly; Since it would require moving the final binary generation from 
> the drivers into the state tracker.
>

Maybe, but the state tracker should have enough information to do that
already (e.g. through the target description in
PIPE_COMPUTE_CAP_IR_TARGET), and it would be preferable to mixing
device-specific IR and hardware assembly depending on how the program
was specified.


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

Re: [Mesa-dev] [PATCH v2 RFC 1/1] clover: Don't crash on NULL global buffer objects.

[Francisco Jerez]

Jan Vesely  writes:

> Specs say "If the argument is a buffer object, the arg_value
> pointer can be NULL or point to a NULL value in which case a NULL
> value will be used as the value for the argument declared as a
> pointer to __global or __constant memory in the kernel."
>
> So don't crash when somebody does that.
>
> v2: Insert NULL into input buffer instead of buffer handle pair
> Fix constant_argument too
> Drop r600 driver changes
>
> Signed-off-by: Jan Vesely 
> ---
> Hi Francisco,
>
Hi Jan,

> I could not find much info about how ctx.input is supposed to be used.
> It looks like it stores begin-end intervals of parameters so NULL, NULL
> seemed appropriate.
>

It's just an array of bytes that is passed to the driver as input for
the kernel.  Some suggestions more below.

> Is this closer to what you had in mind? This patch fixes my issue
> even without the r600 changes.
>
> regards,
> Jan
>
>  src/gallium/state_trackers/clover/core/kernel.cpp | 34 
> +--
>  1 file changed, 20 insertions(+), 14 deletions(-)
>
> diff --git a/src/gallium/state_trackers/clover/core/kernel.cpp 
> b/src/gallium/state_trackers/clover/core/kernel.cpp
> index 58780d6..d4942b3 100644
> --- a/src/gallium/state_trackers/clover/core/kernel.cpp
> +++ b/src/gallium/state_trackers/clover/core/kernel.cpp
> @@ -327,16 +327,19 @@ kernel::global_argument::set(size_t size, const void 
> *value) {
> if (size != sizeof(cl_mem))
>throw error(CL_INVALID_ARG_SIZE);
>  
> -   buf = &obj(*(cl_mem *)value);
> +   buf = pobj(value ? *(cl_mem *)value : NULL);
> _set = true;
>  }
>  
>  void
>  kernel::global_argument::bind(exec_context &ctx,
>const module::argument &marg) {
> -   align(ctx.input, marg.target_align);

As null pointers have the same alignment restrictions as normal pointers,
you should keep this line here before the 'if (buf)' conditional.

> -   ctx.g_handles.push_back(allocate(ctx.input, marg.target_size));
> -   ctx.g_buffers.push_back(buf->resource(*ctx.q).pipe);
> +   if (buf) {
> +  align(ctx.input, marg.target_align);
> +  ctx.g_handles.push_back(allocate(ctx.input, marg.target_size));
> +  ctx.g_buffers.push_back(buf->resource(*ctx.q).pipe);
> +   } else

For consistency use braces around the else block of an if block that
uses braces.

> +  insert(ctx.input, {NULL, NULL});

I don't think this does what you want.  The easiest way to append zeroes
to the input buffer is:

|} else {
|   // Null global pointer.
|   allocate(ctx.input, marg.target_size);
|}

>  }
>  
>  void
> @@ -379,22 +382,25 @@ kernel::constant_argument::set(size_t size, const void 
> *value) {
> if (size != sizeof(cl_mem))
>throw error(CL_INVALID_ARG_SIZE);
>  
> -   buf = &obj(*(cl_mem *)value);
> +   buf = pobj(value ? *(cl_mem *)value : NULL);
> _set = true;
>  }
>  
>  void
>  kernel::constant_argument::bind(exec_context &ctx,
>  const module::argument &marg) {
> -   auto v = bytes(ctx.resources.size() << 24);
> -
> -   extend(v, module::argument::zero_ext, marg.target_size);
> -   byteswap(v, ctx.q->dev.endianness());
> -   align(ctx.input, marg.target_align);
> -   insert(ctx.input, v);
> -
> -   st = buf->resource(*ctx.q).bind_surface(*ctx.q, false);
> -   ctx.resources.push_back(st);
> +   if (buf) {
> +  auto v = bytes(ctx.resources.size() << 24);
> +
> +  extend(v, module::argument::zero_ext, marg.target_size);
> +  byteswap(v, ctx.q->dev.endianness());
> +  align(ctx.input, marg.target_align);

This align() call should be kept outside the conditional too.

> +  insert(ctx.input, v);
> +
> +  st = buf->resource(*ctx.q).bind_surface(*ctx.q, false);
> +  ctx.resources.push_back(st);
> +   } else
> +  insert(ctx.input, {NULL, NULL});

Same comment as before.

Thank you.

>  }
>  
>  void
> -- 
> 1.8.4.2


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

[Mesa-dev] [PATCH 2/3] driconf: Correct and update Spanish translations

[Alex Henrie]

---
 src/mesa/drivers/dri/common/xmlpool/es.po | 64 ---
 1 file changed, 33 insertions(+), 31 deletions(-)

diff --git a/src/mesa/drivers/dri/common/xmlpool/es.po 
b/src/mesa/drivers/dri/common/xmlpool/es.po
index e5b4d1a..4a6ab91 100644
--- a/src/mesa/drivers/dri/common/xmlpool/es.po
+++ b/src/mesa/drivers/dri/common/xmlpool/es.po
@@ -10,23 +10,23 @@ msgstr ""
 "Project-Id-Version: es\n"
 "Report-Msgid-Bugs-To: \n"
 "POT-Creation-Date: 2014-01-13 22:30-0700\n"
-"PO-Revision-Date: 2005-04-12 20:26+0200\n"
-"Last-Translator: David Rubio Miguélez \n"
+"PO-Revision-Date: 2014-01-15 10:34-0700\n"
+"Last-Translator: Alex Henrie \n"
 "Language-Team: Spanish \n"
 "Language: es\n"
 "MIME-Version: 1.0\n"
 "Content-Type: text/plain; charset=UTF-8\n"
 "Content-Transfer-Encoding: 8bit\n"
 "Plural-Forms: nplurals=2; plural=(n != 1);\n"
-"X-Generator: KBabel 1.10\n"
+"X-Generator: Poedit 1.5.4\n"
 
 #: t_options.h:56
 msgid "Debugging"
-msgstr "Depurando"
+msgstr "Depuración"
 
 #: t_options.h:60
 msgid "Disable 3D acceleration"
-msgstr "Desactivar aceleración 3D"
+msgstr "Deshabilitar aceleración 3D"
 
 #: t_options.h:65
 msgid "Show performance boxes"
@@ -34,36 +34,41 @@ msgstr "Mostrar cajas de rendimiento"
 
 #: t_options.h:70
 msgid "Enable flushing batchbuffer after each draw call"
-msgstr ""
+msgstr "Habilitar vaciado del batchbuffer después de cada llamada de dibujo"
 
 #: t_options.h:75
 msgid "Enable flushing GPU caches with each draw call"
-msgstr ""
+msgstr "Habilitar vaciado de los cachés GPU con cada llamada de dibujo"
 
 #: t_options.h:80
 msgid "Disable throttling on first batch after flush"
-msgstr ""
+msgstr "Deshabilitar regulación del primer lote después de vaciar"
 
 #: t_options.h:85
 msgid "Force GLSL extension default behavior to 'warn'"
 msgstr ""
+"Forzar que el comportamiento por defecto de las extensiones GLSL sea 'warn'"
 
 #: t_options.h:90
 msgid "Disable dual source blending"
-msgstr ""
+msgstr "Deshabilitar mezcla de fuente dual"
 
 #: t_options.h:95
 msgid "Disable backslash-based line continuations in GLSL source"
 msgstr ""
+"Deshabilitar continuaciones de línea basadas en barra inversa en el código "
+"GLSL"
 
 #: t_options.h:100
 msgid "Disable GL_ARB_shader_bit_encoding"
-msgstr ""
+msgstr "Deshabilitar GL_ARB_shader_bit_encoding"
 
 #: t_options.h:105
 msgid ""
 "Force a default GLSL version for shaders that lack an explicit #version line"
 msgstr ""
+"Forzar una versión de GLSL por defecto en los shaders a los cuales les falta "
+"una línea #version explícita"
 
 #: t_options.h:115
 msgid "Image Quality"
@@ -75,7 +80,7 @@ msgstr "Profundidad de color de textura"
 
 #: t_options.h:129
 msgid "Prefer frame buffer color depth"
-msgstr "Preferir profundidad de color del \"framebuffer\""
+msgstr "Preferir profundidad de color del framebuffer"
 
 #: t_options.h:130
 msgid "Prefer 32 bits per texel"
@@ -101,8 +106,8 @@ msgstr "Prohibir valores negativos de Nivel De Detalle 
(LOD) de texturas"
 msgid ""
 "Enable S3TC texture compression even if software support is not available"
 msgstr ""
-"Activar la compresión de texturas S3TC incluso si el soporte por software no "
-"está disponible"
+"Habilitar la compresión de texturas S3TC incluso si el soporte por software "
+"no está disponible"
 
 #: t_options.h:155
 msgid "Initial color reduction method"
@@ -150,31 +155,35 @@ msgstr "Búfer de profundidad en coma flotante"
 
 #: t_options.h:190
 msgid "A post-processing filter to cel-shade the output"
-msgstr ""
+msgstr "Un filtro de postprocesamiento para aplicar cel shading a la salida"
 
 #: t_options.h:195
 msgid "A post-processing filter to remove the red channel"
-msgstr ""
+msgstr "Un filtro de postprocesamiento para eliminar el canal rojo"
 
 #: t_options.h:200
 msgid "A post-processing filter to remove the green channel"
-msgstr ""
+msgstr "Un filtro de postprocesamiento para eliminar el canal verde"
 
 #: t_options.h:205
 msgid "A post-processing filter to remove the blue channel"
-msgstr ""
+msgstr "Un filtro de postprocesamiento para eliminar el canal azul"
 
 #: t_options.h:210
 msgid ""
 "Morphological anti-aliasing based on Jimenez\\' MLAA. 0 to disable, 8 for "
 "default quality"
 msgstr ""
+"Antialiasing morfológico basado en el MLAA de Jimenez. 0 para deshabilitar, "
+"8 para calidad por defecto"
 
 #: t_options.h:215
 msgid ""
 "Morphological anti-aliasing based on Jimenez\\' MLAA. 0 to disable, 8 for "
 "default quality. Color version, usable with 2d GL apps"
 msgstr ""
+"Antialiasing morfológico basado en el MLAA de Jimenez. 0 para deshabilitar, "
+"8 para calidad por defecto. Versión en color, usable con aplicaciones GL 2D"
 
 #: t_options.h:225
 msgid "Performance"
@@ -200,12 +209,12 @@ msgstr "Pasar por alto la tubería TCL"
 msgid ""
 "Bypass the TCL pipeline with state-based machine code generated on-the-fly"
 msgstr ""
-"Pasar por alto la tubería TCL con código máquina basado en estados generado "
+"Pasar por alto la tubería TCL con código m

[Mesa-dev] [PATCH 3/3] driconf: Add Catalan translations

[Alex Henrie]

See the instructions in Makefile.am under "Adding new translations".
---
 src/mesa/drivers/dri/common/xmlpool/Makefile.am |   2 +-
 src/mesa/drivers/dri/common/xmlpool/ca.po   | 303 
 2 files changed, 304 insertions(+), 1 deletion(-)
 create mode 100644 src/mesa/drivers/dri/common/xmlpool/ca.po

diff --git a/src/mesa/drivers/dri/common/xmlpool/Makefile.am 
b/src/mesa/drivers/dri/common/xmlpool/Makefile.am
index ad7887d..0908c82 100644
--- a/src/mesa/drivers/dri/common/xmlpool/Makefile.am
+++ b/src/mesa/drivers/dri/common/xmlpool/Makefile.am
@@ -41,7 +41,7 @@
 # - info gettext
 
 # The set of supported languages. Add languages as needed.
-POS=de.po es.po nl.po fr.po sv.po
+POS=ca.po de.po es.po nl.po fr.po sv.po
 
 #
 # Don't change anything below, unless you know what you're doing.
diff --git a/src/mesa/drivers/dri/common/xmlpool/ca.po 
b/src/mesa/drivers/dri/common/xmlpool/ca.po
new file mode 100644
index 000..6130d62
--- /dev/null
+++ b/src/mesa/drivers/dri/common/xmlpool/ca.po
@@ -0,0 +1,303 @@
+# Language  translations for Mesa package
+# Traduccions al català del paquet «Mesa».
+# Copyright (C) 2014 MESA'S COPYRIGHT HOLDER
+# This file is distributed under the same license as the Mesa package.
+# Alex Henrie , 2014.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: Mesa 10.1.0-devel\n"
+"Report-Msgid-Bugs-To: \n"
+"POT-Creation-Date: 2014-01-13 22:30-0700\n"
+"PO-Revision-Date: 2014-01-15 10:37-0700\n"
+"Last-Translator: Alex Henrie \n"
+"Language-Team: Catalan \n"
+"Language: ca\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+"X-Generator: Poedit 1.5.4\n"
+
+#: t_options.h:56
+msgid "Debugging"
+msgstr "Depuració"
+
+#: t_options.h:60
+msgid "Disable 3D acceleration"
+msgstr "Deshabilita l'acceleració 3D"
+
+#: t_options.h:65
+msgid "Show performance boxes"
+msgstr "Mostra les caixes de rendiment"
+
+#: t_options.h:70
+msgid "Enable flushing batchbuffer after each draw call"
+msgstr "Habilita el buidatge del batchbuffer després de cada trucada de dibuix"
+
+#: t_options.h:75
+msgid "Enable flushing GPU caches with each draw call"
+msgstr ""
+"Habilita el buidatge de les memòries cau de GPU amb cada trucada de dibuix"
+
+#: t_options.h:80
+msgid "Disable throttling on first batch after flush"
+msgstr "Deshabilita la regulació en el primer lot després de buidar"
+
+#: t_options.h:85
+msgid "Force GLSL extension default behavior to 'warn'"
+msgstr ""
+"Força que el comportament per defecte de les extensions GLSL sigui 'warn'"
+
+#: t_options.h:90
+msgid "Disable dual source blending"
+msgstr "Deshabilita la barreja de font dual"
+
+#: t_options.h:95
+msgid "Disable backslash-based line continuations in GLSL source"
+msgstr ""
+"Deshabilitar les continuacions de línia basades en barra invertida en la "
+"font GLSL"
+
+#: t_options.h:100
+msgid "Disable GL_ARB_shader_bit_encoding"
+msgstr "Deshabilita el GL_ARB_shader_bit_encoding"
+
+#: t_options.h:105
+msgid ""
+"Force a default GLSL version for shaders that lack an explicit #version line"
+msgstr ""
+"Força una versió GLSL per defecte en els shaders als quals falta una línia "
+"#version explícita"
+
+#: t_options.h:115
+msgid "Image Quality"
+msgstr "Qualitat d'Imatge"
+
+#: t_options.h:128
+msgid "Texture color depth"
+msgstr "Profunditat de color de textura"
+
+#: t_options.h:129
+msgid "Prefer frame buffer color depth"
+msgstr "Prefereix profunditat de color del framebuffer"
+
+#: t_options.h:130
+msgid "Prefer 32 bits per texel"
+msgstr "Prefereix 32 bits per texel"
+
+#: t_options.h:131
+msgid "Prefer 16 bits per texel"
+msgstr "Prefereix 16 bits per texel"
+
+#: t_options.h:132
+msgid "Force 16 bits per texel"
+msgstr "Força 16 bits per texel"
+
+#: t_options.h:138
+msgid "Initial maximum value for anisotropic texture filtering"
+msgstr "Valor màxim inicial per a la filtració de textura anisòtropa"
+
+#: t_options.h:143
+msgid "Forbid negative texture LOD bias"
+msgstr ""
+"Prohibeix una parcialitat negativa del Nivell de Detalle (LOD) de les "
+"textures"
+
+#: t_options.h:148
+msgid ""
+"Enable S3TC texture compression even if software support is not available"
+msgstr ""
+"Habilitar la compressió de textures S3TC encara que el suport de programari "
+"no estigui disponible"
+
+#: t_options.h:155
+msgid "Initial color reduction method"
+msgstr "Mètode inicial de reducció de color"
+
+#: t_options.h:156
+msgid "Round colors"
+msgstr "Colors arrodonits"
+
+#: t_options.h:157
+msgid "Dither colors"
+msgstr "Colors tramats"
+
+#: t_options.h:165
+msgid "Color rounding method"
+msgstr "Mètode d'arrodoniment de color"
+
+#: t_options.h:166
+msgid "Round color components downward"
+msgstr "Arrondeix els components de color a baix"
+
+#: t_options.h:167
+msgid "Round to nearest color"
+msgstr "Arrondeix al color més proper"
+
+#: t_options.h:176
+msgid "Color dithering method"
+msgstr "Mètode de tramat de color"
+
+#: t_options.h:177
+msgid "Horizontal error diffu

Re: [Mesa-dev] [PATCH 2/3] driconf: Correct and update Spanish translations

[Alex Henrie]

2014/1/15 Bruno Jimenez :
> But with this new information, I think a better translation
> would be:
> "Forzar que el comportamiento por defecto de las extensiones
> GLSL sea 'warn'"

Okay, I'm resubmitting with this change...

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

[Mesa-dev] [Bug 73672] New: Half Life 2 in Wine is broken since 4e549ddb

[bugzilla-daemon]

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

  Priority: medium
Bug ID: 73672
  Assignee: mesa-dev@lists.freedesktop.org
   Summary: Half Life 2 in Wine is broken since 4e549ddb
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: stefandoesin...@gmx.at
  Hardware: Other
Status: NEW
   Version: git
 Component: Mesa core
   Product: Mesa

Since a few revisions Half Life 2 running in Wine on r600g shows random
garbage. A regression test revealed this result:

4e549ddb500cf677b6fa16d9ebdfa67cc23da097 is the first bad commit
commit 4e549ddb500cf677b6fa16d9ebdfa67cc23da097
Author: Marek Olk 
Date:   Tue Jan 7 22:00:20 2014 +0100

st/mesa: use sRGB formats for MSAA resolving if destination is sRGB

Copied from the i965 driver, including the big comment.

Cc: 9.2 10.0 

:04 04 4ae7f003a4eff00a25b25a0965e8d23334d56eb4
41235f65612759b8cca64d68c381f4e6af6bb4ad M  src

I've only seen this on r600g, but presumably it affects all drivers. HL2 still
works on my r300g test machine, but I have MSAA disabled there for performance
reasons.

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

[Mesa-dev] [PATCH 1/2] mesa: Bump MAX_TEXTURE_IMAGE_UNITS to 32.

[Kenneth Graunke]

This allows drivers to optionally support more than 16 texture units.

Signed-off-by: Kenneth Graunke 
---
 src/mesa/main/config.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/main/config.h b/src/mesa/main/config.h
index ff9da77..9df4a6e 100644
--- a/src/mesa/main/config.h
+++ b/src/mesa/main/config.h
@@ -121,7 +121,7 @@
  * Max number of texture image units.  Also determines number of texture
  * samplers in shaders.
  */
-#define MAX_TEXTURE_IMAGE_UNITS 16
+#define MAX_TEXTURE_IMAGE_UNITS 32
 
 /**
  * Larger of MAX_TEXTURE_COORD_UNITS and MAX_TEXTURE_IMAGE_UNITS.
-- 
1.8.5.2

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

[Mesa-dev] [PATCH 2/2] i965: Bump BRW_MAX_TEX_UNIT to 32.

[Kenneth Graunke]

This causes us to advertise:
- GL_MAX_TEXTURE_IMAGE_UNITS = 32
- GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS = 32
- GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS = 96
instead of the old values of 16, 16, and 48.

Signed-off-by: Kenneth Graunke 
---
 src/mesa/drivers/dri/i965/brw_context.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

This is covered by Piglit's existing max-samplers test. (Thanks Marek!)

diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
b/src/mesa/drivers/dri/i965/brw_context.h
index 63dd4a0..5908659 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -650,7 +650,7 @@ struct brw_gs_prog_data
 };
 
 /** Number of texture sampler units */
-#define BRW_MAX_TEX_UNIT 16
+#define BRW_MAX_TEX_UNIT 32
 
 /** Max number of render targets in a shader */
 #define BRW_MAX_DRAW_BUFFERS 8
-- 
1.8.5.2

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

[Mesa-dev] [Bug 69874] Automake throws a lot of "[...] option 'subdir-objects' is disabled"

[bugzilla-daemon]

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

--- Comment #11 from David C. Rankin  ---
Correct. Sorry for the noise. While deprecated log ago, it is still needed for
distributions packaging the trinity desktop. The actual problem was obsolete
macros which autoupdate was able to handle. Thanks.

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

[Mesa-dev] [Bug 73672] Half Life 2 in Wine is broken since 4e549ddb

[bugzilla-daemon]

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

--- Comment #1 from Benjamin Bellec  ---
Created attachment 92174
  --> https://bugs.freedesktop.org/attachment.cgi?id=92174&action=edit
l4d2_with_msaa_bad

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

[Mesa-dev] [Bug 73672] Half Life 2 in Wine is broken since 4e549ddb

[bugzilla-daemon]

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

--- Comment #2 from Benjamin Bellec  ---
Created attachment 92175
  --> https://bugs.freedesktop.org/attachment.cgi?id=92175&action=edit
l4d2_without_mass_good

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

[Mesa-dev] [Bug 73672] Half Life 2 in Wine is broken since 4e549ddb

[bugzilla-daemon]

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

--- Comment #3 from Benjamin Bellec  ---
I confirm the bug, with the native version of:
- HL²
- HL² Episode Two
- Left 4 Dead 2
- Counter Strike: Source

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

[Mesa-dev] [Bug 73672] Half Life 2 in Wine is broken since 4e549ddb

[bugzilla-daemon]

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

--- Comment #4 from Benjamin Bellec  ---
Note that the corrupted screenshot is not really like what we see in reality.
On the screen all is red but we can see the HUD and the teamplayers nickname
tag.

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

[Mesa-dev] [PATCH] glsl: Add image type to the GLSL IR.

[Francisco Jerez]

v2: Reuse the glsl_sampler_dim enum for images.  Reuse the
glsl_type::sampler_* fields instead of creating new ones specific
to image types.  Reuse the same constructor as for samplers adding
a new 'base_type' argument.
---
Is this what you had in mind Paul?

Thanks.

 src/glsl/ast_to_hir.cpp|  1 +
 src/glsl/builtin_type_macros.h | 90 +-
 src/glsl/glsl_types.cpp| 17 -
 src/glsl/glsl_types.h  | 10 +--
 src/glsl/ir_clone.cpp  |  1 +
 src/glsl/link_uniform_initializers.cpp |  1 +
 src/mesa/drivers/dri/i965/brw_fs.cpp   |  1 +
 src/mesa/drivers/dri/i965/brw_fs_visitor.cpp   |  1 +
 src/mesa/drivers/dri/i965/brw_shader.cpp   |  2 +
 src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp |  1 +
 src/mesa/program/ir_to_mesa.cpp|  2 +
 src/mesa/state_tracker/st_glsl_to_tgsi.cpp |  1 +
 12 files changed, 76 insertions(+), 52 deletions(-)

diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index 4cc8eb1..00f6a51 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -948,6 +948,7 @@ do_comparison(void *mem_ctx, int operation, ir_rvalue *op0, 
ir_rvalue *op1)
case GLSL_TYPE_ERROR:
case GLSL_TYPE_VOID:
case GLSL_TYPE_SAMPLER:
+   case GLSL_TYPE_IMAGE:
case GLSL_TYPE_INTERFACE:
case GLSL_TYPE_ATOMIC_UINT:
   /* I assume a comparison of a struct containing a sampler just
diff --git a/src/glsl/builtin_type_macros.h b/src/glsl/builtin_type_macros.h
index 06b4dbd..04355a9 100644
--- a/src/glsl/builtin_type_macros.h
+++ b/src/glsl/builtin_type_macros.h
@@ -64,51 +64,51 @@ DECL_TYPE(mat3x4, GL_FLOAT_MAT3x4, GLSL_TYPE_FLOAT, 4, 3)
 DECL_TYPE(mat4x2, GL_FLOAT_MAT4x2, GLSL_TYPE_FLOAT, 2, 4)
 DECL_TYPE(mat4x3, GL_FLOAT_MAT4x3, GLSL_TYPE_FLOAT, 3, 4)
 
-DECL_TYPE(sampler1D, GL_SAMPLER_1D,   
GLSL_SAMPLER_DIM_1D,   0, 0, GLSL_TYPE_FLOAT)
-DECL_TYPE(sampler2D, GL_SAMPLER_2D,   
GLSL_SAMPLER_DIM_2D,   0, 0, GLSL_TYPE_FLOAT)
-DECL_TYPE(sampler3D, GL_SAMPLER_3D,   
GLSL_SAMPLER_DIM_3D,   0, 0, GLSL_TYPE_FLOAT)
-DECL_TYPE(samplerCube,   GL_SAMPLER_CUBE, 
GLSL_SAMPLER_DIM_CUBE, 0, 0, GLSL_TYPE_FLOAT)
-DECL_TYPE(sampler1DArray,GL_SAMPLER_1D_ARRAY, 
GLSL_SAMPLER_DIM_1D,   0, 1, GLSL_TYPE_FLOAT)
-DECL_TYPE(sampler2DArray,GL_SAMPLER_2D_ARRAY, 
GLSL_SAMPLER_DIM_2D,   0, 1, GLSL_TYPE_FLOAT)
-DECL_TYPE(samplerCubeArray,  GL_SAMPLER_CUBE_MAP_ARRAY,   
GLSL_SAMPLER_DIM_CUBE, 0, 1, GLSL_TYPE_FLOAT)
-DECL_TYPE(sampler2DRect, GL_SAMPLER_2D_RECT,  
GLSL_SAMPLER_DIM_RECT, 0, 0, GLSL_TYPE_FLOAT)
-DECL_TYPE(samplerBuffer, GL_SAMPLER_BUFFER,   
GLSL_SAMPLER_DIM_BUF,  0, 0, GLSL_TYPE_FLOAT)
-DECL_TYPE(sampler2DMS,   GL_SAMPLER_2D_MULTISAMPLE,   
GLSL_SAMPLER_DIM_MS,   0, 0, GLSL_TYPE_FLOAT)
-DECL_TYPE(sampler2DMSArray,  GL_SAMPLER_2D_MULTISAMPLE_ARRAY, 
GLSL_SAMPLER_DIM_MS,   0, 1, GLSL_TYPE_FLOAT)
-
-DECL_TYPE(isampler1D,GL_INT_SAMPLER_1D,   
GLSL_SAMPLER_DIM_1D,   0, 0, GLSL_TYPE_INT)
-DECL_TYPE(isampler2D,GL_INT_SAMPLER_2D,   
GLSL_SAMPLER_DIM_2D,   0, 0, GLSL_TYPE_INT)
-DECL_TYPE(isampler3D,GL_INT_SAMPLER_3D,   
GLSL_SAMPLER_DIM_3D,   0, 0, GLSL_TYPE_INT)
-DECL_TYPE(isamplerCube,  GL_INT_SAMPLER_CUBE, 
GLSL_SAMPLER_DIM_CUBE, 0, 0, GLSL_TYPE_INT)
-DECL_TYPE(isampler1DArray,   GL_INT_SAMPLER_1D_ARRAY, 
GLSL_SAMPLER_DIM_1D,   0, 1, GLSL_TYPE_INT)
-DECL_TYPE(isampler2DArray,   GL_INT_SAMPLER_2D_ARRAY, 
GLSL_SAMPLER_DIM_2D,   0, 1, GLSL_TYPE_INT)
-DECL_TYPE(isamplerCubeArray, GL_INT_SAMPLER_CUBE_MAP_ARRAY,   
GLSL_SAMPLER_DIM_CUBE, 0, 1, GLSL_TYPE_INT)
-DECL_TYPE(isampler2DRect,GL_INT_SAMPLER_2D_RECT,  
GLSL_SAMPLER_DIM_RECT, 0, 0, GLSL_TYPE_INT)
-DECL_TYPE(isamplerBuffer,GL_INT_SAMPLER_BUFFER,   
GLSL_SAMPLER_DIM_BUF,  0, 0, GLSL_TYPE_INT)
-DECL_TYPE(isampler2DMS,  GL_INT_SAMPLER_2D_MULTISAMPLE,   
GLSL_SAMPLER_DIM_MS,   0, 0, GLSL_TYPE_INT)
-DECL_TYPE(isampler2DMSArray, GL_INT_SAMPLER_2D_MULTISAMPLE_ARRAY, 
GLSL_SAMPLER_DIM_MS,   0, 1, GLSL_TYPE_INT)
-
-DECL_TYPE(usampler1D,GL_UNSIGNED_INT_SAMPLER_1D,   
GLSL_SAMPLER_DIM_1D,   0, 0, GLSL_TYPE_UINT)
-DECL_TYPE(usampler2D,GL_UNSIGNED_INT_SAMPLER_2D,   
GLSL_SAMPLER_DIM_2D,   0, 0, GLSL_TYPE_UINT)
-DECL_TYPE(usampler3D,GL_UNSIGNED_INT_SAMPLER_3D,   
GLSL_SAMPLER_DIM_3D,   0, 0, GLSL_TYPE_UINT)
-DECL_TYPE(usamplerCube,  GL_UNSIGNED_INT_SAMPLER_CUBE, 
GLSL_SAMPLER_DIM_CUBE, 0, 0, GLSL_TYPE_UINT)
-DECL_TYPE(usampler1DArray,   GL_UNSIGNED_INT_SAMPLER_1D_ARRAY, 
GLSL_SAMPLER_DIM_1D,   0, 1, GLSL_TYPE_UINT)
-DECL_TYPE(usampler2DArray,   GL_UNSIGNED_INT_SAMPL

Re: [Mesa-dev] [PATCH 00/19] nv50: add sampler2DMS/GP support to get OpenGL 3.2

[Ilia Mirkin]

On Mon, Jan 13, 2014 at 2:19 PM, Ilia Mirkin  wrote:
> OK, so there's a bunch of stuff in here. The geometry stuff is based on the
> work started by Bryan Cain and Christoph Bumiller.
>
> Patches 01-12: Add support for geometry shaders and fix related issues
> Patches 13-14: Make it possible for fb clears to operate on texture 
> attachments
>with an explicit layer set (as is allowed in gl 3.2).
> Patches 15-17: Make ARB_texture_multisample work
> Patch  18: Enable GLSL 1.50
> Patch  19: Turn on ARB_seamless_cube_map irrespective of HW support so 
> thatall nv50 cards can get OpenGL 3.2 and geometry shaders 
> (which
>are otherwise unsupported)
>
> There are still a few geometry-related piglits that fail -- specifically:
>   primitive-id-no-gs
>   gl-3.2-layered-rendering-gl-layer*

For those who care, these should now be fixed in my github repo as
well. I won't repost the full series, as these are just incremental
patches, but you can see them at:

https://github.com/imirkin/mesa/commit/5eb4ad1115d0c4cb9f06a5ebb19501c1afc433bd
https://github.com/imirkin/mesa/commit/fcd6a8661ba9ac19faf205a2025b001bb31146a8

The nv50-gs branch now also contains Christoph Bumiller's patches from
late December which effectively allow us to enable GL3.3.

>
> I need to trace the blob to figure out exactly how to configure the HW for
> those situations, but I suspect that the fixes will be fairly small and
> self-contained.
>
> Note that there are also a bunch of EXT_framebuffer_multisample tests that are
> failing, but that has nothing to do with these changes. There's something
> wrong with the blit_3d function, at the very least to do with depth/stencil,
> but also some color tests fail as well.
>
> These patches are available at https://github.com/imirkin/mesa.git nv50-gs
> or https://github.com/imirkin/mesa/commits/nv50-gs for those who prefer a
> web ui.
>
> Bryan Cain (2):
>   nv50/ir: delay calculation of indirect addresses
>   nv50: add support for geometry shaders
>
> Christoph Bumiller (1):
>   nv50/ir: fix PFETCH and add RDSV to get VSTRIDE for GPs
>
> Ilia Mirkin (16):
>   nv50: allow vert_count to be >255
>   nv50/ir: disallow predicates on emit/restart ops
>   nv50/ir: disallow shader input propagation for gp
>   nv50/ir: comment out code to allow input/immed loads
>   nv50/ir: add support for gl_PrimitiveIDIn
>   nv50: properly set the PRIMITIVE_ID enable flag when it is a gp input.
>   nv50: VP_RESULT_MAP_SIZE has to be positive
>   nv50: GP_REG_ALLOC_RESULT must be positive
>   nv50: allocate an extra code bo to avoid dmesg spam
>   nv50: don't forget to also clear additional layers
>   nvc0: don't forget to also clear additional layers
>   nv50: add comments about CB_AUX contents
>   nv50: copy nvc0's get_sample_position implementation
>   nv50: add support for textureFetch'ing MS textures,
> ARB_texture_multisample
>   nv50: report glsl 1.50 now that gp tests pass
>   nv50: enable seamless cube maps on all hw for OpenGL 3.2
>
>  src/gallium/drivers/nouveau/codegen/nv50_ir.h  |   9 ++
>  .../drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp  |  92 ++--
>  .../drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp  |  41 --
>  .../nouveau/codegen/nv50_ir_lowering_nv50.cpp  | 164 
> -
>  .../nouveau/codegen/nv50_ir_lowering_nvc0.cpp  |   7 +
>  .../drivers/nouveau/codegen/nv50_ir_print.cpp  |   1 +
>  .../nouveau/codegen/nv50_ir_target_nv50.cpp|  18 ++-
>  src/gallium/drivers/nouveau/nv50/nv50_context.c|  46 ++
>  src/gallium/drivers/nouveau/nv50/nv50_context.h|  17 +++
>  src/gallium/drivers/nouveau/nv50/nv50_program.c|  30 +++-
>  src/gallium/drivers/nouveau/nv50/nv50_program.h|   2 +-
>  src/gallium/drivers/nouveau/nv50/nv50_screen.c |  23 ++-
>  .../drivers/nouveau/nv50/nv50_shader_state.c   |   6 +
>  .../drivers/nouveau/nv50/nv50_state_validate.c |   2 +-
>  src/gallium/drivers/nouveau/nv50/nv50_surface.c|  25 ++--
>  src/gallium/drivers/nouveau/nv50/nv50_tex.c|  77 +-
>  src/gallium/drivers/nouveau/nvc0/nvc0_surface.c|  22 ++-
>  17 files changed, 526 insertions(+), 56 deletions(-)
>
> --
> 1.8.3.2
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [libdrm PATCH] intel: Create a new drm_intel_bo offset64 field.

[Eric Anholt]

Ben Widawsky  writes:

> On Mon, Jan 13, 2014 at 11:41:11PM -0800, Eric Anholt wrote:
>> Kenneth Graunke  writes:
>> 
>> > The existing 'offset' field is unfortunately typed as 'unsigned long',
>> > which is unfortunately only 4 bytes with a 32-bit userspace.
>> >
>> > Traditionally, the hardware has only supported 32-bit virtual addresses,
>> > so even though the kernel uses a __u64, the value would always fit.
>> >
>> > However, Broadwell supports 48-bit addressing.  So with a 64-bit kernel,
>> > the card virtual address may be too large to fit in the 'offset' field.
>> >
>> > Ideally, we would change the type of 'offset' to be a uint64_t---but
>> > this would break the libdrm ABI.  Instead, we create a new 'offset64'
>> > field to hold the full 64-bit value from the kernel, and store the
>> > 32-bit truncation in the existing 'offset' field, for compatibility.
>> >
>> > Cc: Eric Anholt 
>> > Cc: Daniel Vetter 
>> > Cc: Ben Widawsky 
>> > Signed-off-by: Kenneth Graunke 
>> > ---
>> >  intel/intel_bufmgr.h | 12 +---
>> >  intel/intel_bufmgr_gem.c | 16 ++--
>> >  2 files changed, 19 insertions(+), 9 deletions(-)
>> >
>> > I didn't update the bufmgr_fake stuff.  Do I need to...?
>> 
>> Nope.  Also, this was less patch than I was originally imagining it
>> would be.  Sweet.
>> 
>> Reviewed-by: Eric Anholt 
>> 
>> Maybe some day we'll do a symbol-versioned fork of the code without all
>> the compatibility insanity, and with other 4G limits fixed.  I don't
>> think we have any instances of sharing drm_intel_bos across build-system
>> boundaries.  Anyone want to correct me on that?
>
> libva?

Can you point to what part of libva?  I don't see drm_intel_bo or dri_bo
in headers that would be installed.


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

Re: [Mesa-dev] [Mesa PATCH 2/3] i965: Use the new drm_intel_bo offset64 field.

[Eric Anholt]

Kenneth Graunke  writes:

> libdrm 2.4.52 introduces a new 'uint64_t offset64' field, intended to
> replace the old 'unsigned long offset' field.  To preserve ABI, libdrm
> continues to store the presumed offset in both locations.
>
> On Broadwell, a 64-bit kernel may place BOs at "high" (> 4G) addresses.
> However, with a 32-bit userspace, the 'unsigned long offset' field will
> only be 32-bit, which is not large enough to hold this value.  We need
> to use a proper uint64_t (like the kernel does).
>
> Technically, a lot of this code doesn't affect Broadwell, so we could
> leave it using the old field.  But it makes sense to just switch to the
> new, properly typed field.

This series is:

Reviewed-by: Eric Anholt 

I was concerned about brw_program_reloc returning uint32_t still, except
that on gen5+ it's always just returning the incoming prog_offset from
the state base address.



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

Re: [Mesa-dev] [PATCH 2/2] i965: Bump BRW_MAX_TEX_UNIT to 32.

[Chris Forbes]

Does this actually work for >16?

Sampler messages' descriptor only has 4 bits for the sampler index, so
it seems you'd silently lose the top bit and get the wrong sampler
parameters.

On Thu, Jan 16, 2014 at 8:08 AM, Kenneth Graunke  wrote:
> This causes us to advertise:
> - GL_MAX_TEXTURE_IMAGE_UNITS = 32
> - GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS = 32
> - GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS = 96
> instead of the old values of 16, 16, and 48.
>
> Signed-off-by: Kenneth Graunke 
> ---
>  src/mesa/drivers/dri/i965/brw_context.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> This is covered by Piglit's existing max-samplers test. (Thanks Marek!)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
> b/src/mesa/drivers/dri/i965/brw_context.h
> index 63dd4a0..5908659 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.h
> +++ b/src/mesa/drivers/dri/i965/brw_context.h
> @@ -650,7 +650,7 @@ struct brw_gs_prog_data
>  };
>
>  /** Number of texture sampler units */
> -#define BRW_MAX_TEX_UNIT 16
> +#define BRW_MAX_TEX_UNIT 32
>
>  /** Max number of render targets in a shader */
>  #define BRW_MAX_DRAW_BUFFERS 8
> --
> 1.8.5.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] RFC: ARB_arrays_of_arrays work in progress

[Chris Forbes]

That assert means that you've not told the backend the size of some
object correctly, and the register allocator has placed it so its true
extent hangs off the end of the available registers.

To fix it you'll need to adjust the code generation for array accesses
in i965 -- probably quite a bit.

On Thu, Jan 16, 2014 at 1:14 AM, Timothy Arceri  wrote:
> First of all sorry for my first post being a reply to Ians 10.1 release
> plan.
>
> Secondly I've rebased my work on current master and reimplemented my
> work using the approach I mention in my last email. The changes are half
> the size and now some basic execution tests are passing. The new branch
> is here: https://github.com/tarceri/Mesa_arrays_of_arrays/tree/wip8
>
> However I'm having an issue where if I'm running the tests using a
> command like
> ./piglit-run.py -t ARB_arrays_of_arrays/compiler* tests/all.tests
> results/array_of_array
>
> Some of the tests crash with this error:
> glslparsertest: brw_eu_emit.c:305: brw_set_src0: Assertion `reg.nr <
> 128' failed.
>
> But when I run them directly using glslparsertest they don't crash.
> Anyone know why this would be happening? I looked at the assert but it
> didn't really make any sense to me.
>
> In case it helps I'm using the build options ./autogen.sh
> --prefix=/opt/xorg --enable-texture-float --with-dri-drivers="i965"
> --with-llvm-shared-libs --disable-dri3 --with-gallium-drivers=""
> on Fedora 19
>
> Thanks,
> Tim
>
>
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 73672] Half Life 2 in Wine is broken since 4e549ddb

[bugzilla-daemon]

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

--- Comment #5 from Stefan Dösinger  ---
Yeah, it looks pretty much the same way in Wine.

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

Re: [Mesa-dev] [PATCH 10/23] i965/fs: Remove fs_reg::sechalf.

[Francisco Jerez]

Paul Berry  writes:

> On 2 December 2013 11:31, Francisco Jerez  wrote:
>
>> +/**
>> + * Get either of the 8-component halves of a 16-component register.
>> + */
>> +static inline fs_reg
>> +half(const fs_reg ®, unsigned idx)
>> +{
>> +   assert(idx == 0 || (reg.file != HW_REG && reg.file != IMM));
>> +   return byte_offset(reg, 8 * idx * reg.stride * type_sz(reg.type));
>> +}
>> +
>>
>
> I'd like to see a comment explaining that it's safe to call this function
> on a register with 32 bits per component, since brw_reg.h's byte_offset()
> handles byte offsets greater than 32 by incrementing the register number.
>
I've added a comment on the allowed range of fs_reg::subreg_offset here
[1].  Do you think that's clear enough?

Thanks.

> Also, for sanity's sake, it would be nice for this function to include the
> assertion:
>
>assert(idx < 2);
>
> With those changes, this patch is:
>
> Reviewed-by: Paul Berry 

[1] 
http://cgit.freedesktop.org/~currojerez/mesa/commit/?h=image-load-store&id=14ec9dfd42fec1ee5e5e7f48f98a36fe620cf4e6


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

Re: [Mesa-dev] [PATCH 13/23] i965/fs: Take into account reg_offset consistently for MRF regs.

[Francisco Jerez]

Paul Berry  writes:

> On 2 December 2013 11:31, Francisco Jerez  wrote:
>
>> Until now it was only being taken into account in the VEC4 back-end
>> but not in the FS back-end.  Do it in both cases.
>> ---
>>  src/mesa/drivers/dri/i965/brw_fs.h |  2 +-
>>  src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 10 ++
>>  src/mesa/drivers/dri/i965/brw_shader.h |  7 ---
>>  3 files changed, 11 insertions(+), 8 deletions(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_fs.h
>> b/src/mesa/drivers/dri/i965/brw_fs.h
>> index 2c36d9f..f918f7e 100644
>> --- a/src/mesa/drivers/dri/i965/brw_fs.h
>> +++ b/src/mesa/drivers/dri/i965/brw_fs.h
>> @@ -615,4 +615,4 @@ bool brw_do_channel_expressions(struct exec_list
>> *instructions);
>>  bool brw_do_vector_splitting(struct exec_list *instructions);
>>  bool brw_fs_precompile(struct gl_context *ctx, struct gl_shader_program
>> *prog);
>>
>> -struct brw_reg brw_reg_from_fs_reg(fs_reg *reg);
>> +struct brw_reg brw_reg_from_fs_reg(fs_reg *reg, unsigned dispatch_width);
>> diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
>> b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
>> index 8d310a1..1de59eb 100644
>> --- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
>> +++ b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
>> @@ -981,8 +981,9 @@ static uint32_t brw_file_from_reg(fs_reg *reg)
>>  }
>>
>>  struct brw_reg
>> -brw_reg_from_fs_reg(fs_reg *reg)
>> +brw_reg_from_fs_reg(fs_reg *reg, unsigned dispatch_width)
>>  {
>> +   const int reg_size = 4 * dispatch_width;
>>
>
> What happens when reg.type is UW and dispatch_width is 16?  In that case,
> we would compute reg_size == 64, but the correct value seems like it's
> actually 32 in this case.
>
> Are we perhaps relying on reg.type being a 32-bit type?  If so, maybe we
> should add an assertion:
>
>assert(type_sz(reg.type) == 4);
>

Nope, "reg_size" is supposed to be the size in bytes of a ::reg_offset
unit, i.e. one hardware register in SIMD8 mode and two hardware
registers in SIMD16 mode as the comment at the definition of
::reg_offset explains.  The fixed factor of four is intentional and
correct no matter what the register type is.

Thanks.

> With that added, this patch is:
>
> Reviewed-by: Paul Berry 


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

Re: [Mesa-dev] [PATCH 2/2] i965: Bump BRW_MAX_TEX_UNIT to 32.

[Kenneth Graunke]

On 01/15/2014 12:56 PM, Chris Forbes wrote:
> Does this actually work for >16?
> 
> Sampler messages' descriptor only has 4 bits for the sampler index, so
> it seems you'd silently lose the top bit and get the wrong sampler
> parameters.

Oh, wow.  No...no, it can't possibly work then.  (Apparently that Piglit
test isn't sufficient...I just glanced at it...)

It looks like the Intel Windows driver has bumped this to 32 on Haswell
(but not earlier).  I'm guessing that they use the "Sampler State
Pointer" field in the message /header/, instead of the "Sampler Index"
field in the message /descriptor/.  On Haswell, that changed to be
relative to Dynamic State Base Address instead of General State Base
Address.  Which probably helps.

Still, that's probably going to be kind of miserable.  I'll have to look
into what they're doing.

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

Re: [Mesa-dev] [Mesa PATCH 2/3] i965: Use the new drm_intel_bo offset64 field.

[Kenneth Graunke]

On 01/15/2014 12:47 PM, Eric Anholt wrote:
> Kenneth Graunke  writes:
> 
>> libdrm 2.4.52 introduces a new 'uint64_t offset64' field, intended to
>> replace the old 'unsigned long offset' field.  To preserve ABI, libdrm
>> continues to store the presumed offset in both locations.
>>
>> On Broadwell, a 64-bit kernel may place BOs at "high" (> 4G) addresses.
>> However, with a 32-bit userspace, the 'unsigned long offset' field will
>> only be 32-bit, which is not large enough to hold this value.  We need
>> to use a proper uint64_t (like the kernel does).
>>
>> Technically, a lot of this code doesn't affect Broadwell, so we could
>> leave it using the old field.  But it makes sense to just switch to the
>> new, properly typed field.
> 
> This series is:
> 
> Reviewed-by: Eric Anholt 
> 
> I was concerned about brw_program_reloc returning uint32_t still, except
> that on gen5+ it's always just returning the incoming prog_offset from
> the state base address.

>From our conversation on IRC, it sounded like you had some ideas for
creating a newer/better libdrm API for doing relocations, which would
replace this.  Did you give up on that?

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

Re: [Mesa-dev] RFC: ARB_arrays_of_arrays work in progress

[Timothy Arceri]

Thanks Chirs,

Yes that sounds right. I managed to get a core dump and it seems to be
an issue during linking with uniforms. Still trying to understand all
the code but the code in do_vs_prog() looks like a good starting point.

On Thu, 2014-01-16 at 10:00 +1300, Chris Forbes wrote:
> That assert means that you've not told the backend the size of some
> object correctly, and the register allocator has placed it so its true
> extent hangs off the end of the available registers.
> 
> To fix it you'll need to adjust the code generation for array accesses
> in i965 -- probably quite a bit.
> 
> On Thu, Jan 16, 2014 at 1:14 AM, Timothy Arceri  wrote:
> > First of all sorry for my first post being a reply to Ians 10.1 release
> > plan.
> >
> > Secondly I've rebased my work on current master and reimplemented my
> > work using the approach I mention in my last email. The changes are half
> > the size and now some basic execution tests are passing. The new branch
> > is here: https://github.com/tarceri/Mesa_arrays_of_arrays/tree/wip8
> >
> > However I'm having an issue where if I'm running the tests using a
> > command like
> > ./piglit-run.py -t ARB_arrays_of_arrays/compiler* tests/all.tests
> > results/array_of_array
> >
> > Some of the tests crash with this error:
> > glslparsertest: brw_eu_emit.c:305: brw_set_src0: Assertion `reg.nr <
> > 128' failed.
> >
> > But when I run them directly using glslparsertest they don't crash.
> > Anyone know why this would be happening? I looked at the assert but it
> > didn't really make any sense to me.
> >
> > In case it helps I'm using the build options ./autogen.sh
> > --prefix=/opt/xorg --enable-texture-float --with-dri-drivers="i965"
> > --with-llvm-shared-libs --disable-dri3 --with-gallium-drivers=""
> > on Fedora 19
> >
> > Thanks,
> > Tim
> >
> >
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

[Mesa-dev] [PATCH] llvmpipe: fix possible constant buffer overflow

[Zack Rusin]

It's possible to bind a smaller buffer as a constant buffer, than
what the shader actually uses/requires. This could cause nasty
crashes. This patch adds the architecture to pass the maximum
allowable constant buffer index to the jit to let it make
sure that the constant buffer indices are always within bounds.
The behavior follows the d3d10 spec, which says the overflow
should always return all zeros, and overflow is only defined
as access beyond the size of the currently bound buffer. Accesses
beyond the declared shader constant register size are not
considered an overflow and expected to return garbage but consistent
garbage (we follow the behavior which some wlk tests expect which
is to return the actual values from the bound buffer).

Signed-off-by: Zack Rusin 
---
 src/gallium/auxiliary/draw/draw_llvm.c | 42 ++
 src/gallium/auxiliary/draw/draw_llvm.h | 32 +---
 .../draw/draw_pt_fetch_shade_pipeline_llvm.c   |  6 ++
 src/gallium/auxiliary/gallivm/lp_bld_tgsi.h|  2 +
 src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c| 89 ++
 src/gallium/drivers/llvmpipe/lp_jit.c  |  7 +-
 src/gallium/drivers/llvmpipe/lp_jit.h  |  5 ++
 src/gallium/drivers/llvmpipe/lp_setup.c|  7 +-
 src/gallium/drivers/llvmpipe/lp_state_fs.c |  5 +-
 9 files changed, 152 insertions(+), 43 deletions(-)

diff --git a/src/gallium/auxiliary/draw/draw_llvm.c 
b/src/gallium/auxiliary/draw/draw_llvm.c
index 331039a..0bbb680 100644
--- a/src/gallium/auxiliary/draw/draw_llvm.c
+++ b/src/gallium/auxiliary/draw/draw_llvm.c
@@ -242,17 +242,20 @@ create_jit_context_type(struct gallivm_state *gallivm,
 {
LLVMTargetDataRef target = gallivm->target;
LLVMTypeRef float_type = LLVMFloatTypeInContext(gallivm->context);
+   LLVMTypeRef int_type = LLVMInt32TypeInContext(gallivm->context);
LLVMTypeRef elem_types[DRAW_JIT_CTX_NUM_FIELDS];
LLVMTypeRef context_type;
 
elem_types[0] = LLVMArrayType(LLVMPointerType(float_type, 0), /* 
vs_constants */
  LP_MAX_TGSI_CONST_BUFFERS);
-   elem_types[1] = LLVMPointerType(LLVMArrayType(LLVMArrayType(float_type, 4),
+   elem_types[1] = LLVMArrayType(int_type, /* num_vs_constants */
+ LP_MAX_TGSI_CONST_BUFFERS);
+   elem_types[2] = LLVMPointerType(LLVMArrayType(LLVMArrayType(float_type, 4),
  DRAW_TOTAL_CLIP_PLANES), 0);
-   elem_types[2] = LLVMPointerType(float_type, 0); /* viewport */
-   elem_types[3] = LLVMArrayType(texture_type,
+   elem_types[3] = LLVMPointerType(float_type, 0); /* viewport */
+   elem_types[4] = LLVMArrayType(texture_type,
  PIPE_MAX_SHADER_SAMPLER_VIEWS); /* textures */
-   elem_types[4] = LLVMArrayType(sampler_type,
+   elem_types[5] = LLVMArrayType(sampler_type,
  PIPE_MAX_SAMPLERS); /* samplers */
context_type = LLVMStructTypeInContext(gallivm->context, elem_types,
   Elements(elem_types), 0);
@@ -264,6 +267,8 @@ create_jit_context_type(struct gallivm_state *gallivm,
 
LP_CHECK_MEMBER_OFFSET(struct draw_jit_context, vs_constants,
   target, context_type, DRAW_JIT_CTX_CONSTANTS);
+   LP_CHECK_MEMBER_OFFSET(struct draw_jit_context, num_vs_constants,
+  target, context_type, DRAW_JIT_CTX_NUM_CONSTANTS);
LP_CHECK_MEMBER_OFFSET(struct draw_jit_context, planes,
   target, context_type, DRAW_JIT_CTX_PLANES);
LP_CHECK_MEMBER_OFFSET(struct draw_jit_context, viewport,
@@ -298,20 +303,22 @@ create_gs_jit_context_type(struct gallivm_state *gallivm,
 
elem_types[0] = LLVMArrayType(LLVMPointerType(float_type, 0), /* constants 
*/
  LP_MAX_TGSI_CONST_BUFFERS);
-   elem_types[1] = LLVMPointerType(LLVMArrayType(LLVMArrayType(float_type, 4),
+   elem_types[1] = LLVMArrayType(int_type, /* num_constants */
+ LP_MAX_TGSI_CONST_BUFFERS);
+   elem_types[2] = LLVMPointerType(LLVMArrayType(LLVMArrayType(float_type, 4),
  DRAW_TOTAL_CLIP_PLANES), 0);
-   elem_types[2] = LLVMPointerType(float_type, 0); /* viewport */
+   elem_types[3] = LLVMPointerType(float_type, 0); /* viewport */
 
-   elem_types[3] = LLVMArrayType(texture_type,
+   elem_types[4] = LLVMArrayType(texture_type,
  PIPE_MAX_SHADER_SAMPLER_VIEWS); /* textures */
-   elem_types[4] = LLVMArrayType(sampler_type,
+   elem_types[5] = LLVMArrayType(sampler_type,
  PIPE_MAX_SAMPLERS); /* samplers */

-   elem_types[5] = LLVMPointerType(LLVMPointerType(int_type, 0), 0);
-   elem_types[6] = LLVMPointerType(LLVMVectorType(int_type,
-  vector_length), 0);
+   elem_types[6] = LLVMPointerType(LLVMPointerType(int

[Mesa-dev] [PATCH 1/2] softpipe: handle NULL color buffer pointers

[Brian Paul]

Fixes regression from 9baa45f78b8ca7d66280e36009b6a685055d7cd6
---
 src/gallium/drivers/softpipe/sp_quad_blend.c |  189 +-
 1 file changed, 96 insertions(+), 93 deletions(-)

diff --git a/src/gallium/drivers/softpipe/sp_quad_blend.c 
b/src/gallium/drivers/softpipe/sp_quad_blend.c
index d122586..00a9be6 100644
--- a/src/gallium/drivers/softpipe/sp_quad_blend.c
+++ b/src/gallium/drivers/softpipe/sp_quad_blend.c
@@ -927,93 +927,94 @@ blend_fallback(struct quad_stage *qs,
 
write_all = softpipe->fs_variant->info.color0_writes_all_cbufs;
 
-   for (cbuf = 0; cbuf < softpipe->framebuffer.nr_cbufs; cbuf++) 
-   {
-  /* which blend/mask state index to use: */
-  const uint blend_buf = blend->independent_blend_enable ? cbuf : 0;
-  float dest[4][TGSI_QUAD_SIZE];
-  struct softpipe_cached_tile *tile
- = sp_get_cached_tile(softpipe->cbuf_cache[cbuf],
-  quads[0]->input.x0, 
-  quads[0]->input.y0);
-  const boolean clamp = bqs->clamp[cbuf];
-  const float *blend_color;
-  const boolean dual_source_blend = util_blend_state_is_dual(blend, cbuf);
-  uint q, i, j;
-
-  if (clamp)
- blend_color = softpipe->blend_color_clamped.color;
-  else
- blend_color = softpipe->blend_color.color;
-
-  for (q = 0; q < nr; q++) {
- struct quad_header *quad = quads[q];
- float (*quadColor)[4];
- float (*quadColor2)[4] = NULL;
- float temp_quad_color[TGSI_QUAD_SIZE][4];
- const int itx = (quad->input.x0 & (TILE_SIZE-1));
- const int ity = (quad->input.y0 & (TILE_SIZE-1));
-
- if (write_all) {
-for (j = 0; j < TGSI_QUAD_SIZE; j++) {
-   for (i = 0; i < 4; i++) {
-  temp_quad_color[i][j] = quad->output.color[0][i][j];
+   for (cbuf = 0; cbuf < softpipe->framebuffer.nr_cbufs; cbuf++) {
+  if (softpipe->framebuffer.cbufs[cbuf]) {
+ /* which blend/mask state index to use: */
+ const uint blend_buf = blend->independent_blend_enable ? cbuf : 0;
+ float dest[4][TGSI_QUAD_SIZE];
+ struct softpipe_cached_tile *tile
+= sp_get_cached_tile(softpipe->cbuf_cache[cbuf],
+ quads[0]->input.x0, 
+ quads[0]->input.y0);
+ const boolean clamp = bqs->clamp[cbuf];
+ const float *blend_color;
+ const boolean dual_source_blend = util_blend_state_is_dual(blend, 
cbuf);
+ uint q, i, j;
+
+ if (clamp)
+blend_color = softpipe->blend_color_clamped.color;
+ else
+blend_color = softpipe->blend_color.color;
+
+ for (q = 0; q < nr; q++) {
+struct quad_header *quad = quads[q];
+float (*quadColor)[4];
+float (*quadColor2)[4] = NULL;
+float temp_quad_color[TGSI_QUAD_SIZE][4];
+const int itx = (quad->input.x0 & (TILE_SIZE-1));
+const int ity = (quad->input.y0 & (TILE_SIZE-1));
+
+if (write_all) {
+   for (j = 0; j < TGSI_QUAD_SIZE; j++) {
+  for (i = 0; i < 4; i++) {
+ temp_quad_color[i][j] = quad->output.color[0][i][j];
+  }
}
+   quadColor = temp_quad_color;
+} else {
+   quadColor = quad->output.color[cbuf];
+   if (dual_source_blend)
+  quadColor2 = quad->output.color[cbuf + 1];
 }
-quadColor = temp_quad_color;
- } else {
-quadColor = quad->output.color[cbuf];
-   if (dual_source_blend)
-  quadColor2 = quad->output.color[cbuf + 1];
- }
 
- /* If fixed-point dest color buffer, need to clamp the incoming
-  * fragment colors now.
-  */
- if (clamp || softpipe->rasterizer->clamp_fragment_color) {
-clamp_colors(quadColor);
- }
+/* If fixed-point dest color buffer, need to clamp the incoming
+ * fragment colors now.
+ */
+if (clamp || softpipe->rasterizer->clamp_fragment_color) {
+   clamp_colors(quadColor);
+}
 
- /* get/swizzle dest colors
-  */
- for (j = 0; j < TGSI_QUAD_SIZE; j++) {
-int x = itx + (j & 1);
-int y = ity + (j >> 1);
-for (i = 0; i < 4; i++) {
-   dest[i][j] = tile->data.color[y][x][i];
+/* get/swizzle dest colors
+ */
+for (j = 0; j < TGSI_QUAD_SIZE; j++) {
+   int x = itx + (j & 1);
+   int y = ity + (j >> 1);
+   for (i = 0; i < 4; i++) {
+  dest[i][j] = tile->data.color[y][x][i];
+   }
 }
- }
 
 
- if (blend->logicop_enable) {
-if (bqs->format_type[cbuf] != UTIL_FORMAT_TYPE_FLOAT) {
-   l

[Mesa-dev] [PATCH 2/2] llvmpipe: handle NULL color buffer pointers

[Brian Paul]

Fixes regression from 9baa45f78b8ca7d66280e36009b6a685055d7cd6
---
 src/gallium/drivers/llvmpipe/lp_rast.c  |   44 +---
 src/gallium/drivers/llvmpipe/lp_rast_priv.h |   11 +-
 src/gallium/drivers/llvmpipe/lp_scene.c |6 +-
 src/gallium/drivers/llvmpipe/lp_setup.c |2 +-
 src/gallium/drivers/llvmpipe/lp_state_fs.c  |  152 +++
 5 files changed, 126 insertions(+), 89 deletions(-)

diff --git a/src/gallium/drivers/llvmpipe/lp_rast.c 
b/src/gallium/drivers/llvmpipe/lp_rast.c
index 6feec94..3e25ff0 100644
--- a/src/gallium/drivers/llvmpipe/lp_rast.c
+++ b/src/gallium/drivers/llvmpipe/lp_rast.c
@@ -124,7 +124,8 @@ lp_rast_clear_color(struct lp_rasterizer_task *task,
   unsigned i;
   union util_color uc;
 
-  if (util_format_is_pure_integer(scene->fb.cbufs[0]->format)) {
+  if (scene->fb.cbufs[0] &&
+  util_format_is_pure_integer(scene->fb.cbufs[0]->format)) {
  /*
   * We expect int/uint clear values here, though some APIs
   * might disagree (but in any case util_pack_color()
@@ -174,20 +175,22 @@ lp_rast_clear_color(struct lp_rasterizer_task *task,
 clear_color[3]);
 
  for (i = 0; i < scene->fb.nr_cbufs; i++) {
-util_pack_color(arg.clear_color.f,
-scene->fb.cbufs[i]->format, &uc);
-
-util_fill_box(scene->cbufs[i].map,
-  scene->fb.cbufs[i]->format,
-  scene->cbufs[i].stride,
-  scene->cbufs[i].layer_stride,
-  task->x,
-  task->y,
-  0,
-  task->width,
-  task->height,
-  scene->fb_max_layer + 1,
-  &uc);
+if (scene->fb.cbufs[i]) {
+   util_pack_color(arg.clear_color.f,
+   scene->fb.cbufs[i]->format, &uc);
+
+   util_fill_box(scene->cbufs[i].map,
+ scene->fb.cbufs[i]->format,
+ scene->cbufs[i].stride,
+ scene->cbufs[i].layer_stride,
+ task->x,
+ task->y,
+ 0,
+ task->width,
+ task->height,
+ scene->fb_max_layer + 1,
+ &uc);
+}
  }
   }
}
@@ -444,8 +447,15 @@ lp_rast_shade_quads_mask(struct lp_rasterizer_task *task,
 
/* color buffer */
for (i = 0; i < scene->fb.nr_cbufs; i++) {
-  stride[i] = scene->cbufs[i].stride;
-  color[i] = lp_rast_get_unswizzled_color_block_pointer(task, i, x, y, 
inputs->layer);
+  if (scene->fb.cbufs[i]) {
+ stride[i] = scene->cbufs[i].stride;
+ color[i] = lp_rast_get_unswizzled_color_block_pointer(task, i, x, y,
+   inputs->layer);
+  }
+  else {
+ stride[i] = 0;
+ color[i] = NULL;
+  }
}
 
/* depth buffer */
diff --git a/src/gallium/drivers/llvmpipe/lp_rast_priv.h 
b/src/gallium/drivers/llvmpipe/lp_rast_priv.h
index bc361b6..063a70e 100644
--- a/src/gallium/drivers/llvmpipe/lp_rast_priv.h
+++ b/src/gallium/drivers/llvmpipe/lp_rast_priv.h
@@ -293,8 +293,15 @@ lp_rast_shade_quads_all( struct lp_rasterizer_task *task,
 
/* color buffer */
for (i = 0; i < scene->fb.nr_cbufs; i++) {
-  stride[i] = scene->cbufs[i].stride;
-  color[i] = lp_rast_get_unswizzled_color_block_pointer(task, i, x, y, 
inputs->layer);
+  if (scene->fb.cbufs[i]) {
+ stride[i] = scene->cbufs[i].stride;
+ color[i] = lp_rast_get_unswizzled_color_block_pointer(task, i, x, y,
+   inputs->layer);
+  }
+  else {
+ stride[i] = 0;
+ color[i] = NULL;
+  }
}
 
if (scene->zsbuf.map) {
diff --git a/src/gallium/drivers/llvmpipe/lp_scene.c 
b/src/gallium/drivers/llvmpipe/lp_scene.c
index 0296b79..134ab86 100644
--- a/src/gallium/drivers/llvmpipe/lp_scene.c
+++ b/src/gallium/drivers/llvmpipe/lp_scene.c
@@ -156,6 +156,10 @@ lp_scene_begin_rasterization(struct lp_scene *scene)
 
for (i = 0; i < scene->fb.nr_cbufs; i++) {
   struct pipe_surface *cbuf = scene->fb.cbufs[i];
+
+  if (!cbuf)
+ continue;
+
   if (llvmpipe_resource_is_texture(cbuf->texture)) {
  scene->cbufs[i].stride = llvmpipe_resource_stride(cbuf->texture,
cbuf->u.tex.level);
@@ -521,7 +525,7 @@ void lp_scene_begin_binning( struct lp_scene *scene,
 */
for (i = 0; i < scene->fb.nr_cbufs; i++) {
   struct pipe_surface *cbuf = scene->fb.cbufs[i];
-  if (llvmpipe_resource_is_texture(cbuf->texture)) {
+  if (cbuf && llvmpipe_resource

Re: [Mesa-dev] [PATCH 2/2] llvmpipe: handle NULL color buffer pointers

[Roland Scheidegger]

Looks good overall, just some minor quibbles inline.

Roland

Am 16.01.2014 03:15, schrieb Brian Paul:
> Fixes regression from 9baa45f78b8ca7d66280e36009b6a685055d7cd6
> ---
>  src/gallium/drivers/llvmpipe/lp_rast.c  |   44 +---
>  src/gallium/drivers/llvmpipe/lp_rast_priv.h |   11 +-
>  src/gallium/drivers/llvmpipe/lp_scene.c |6 +-
>  src/gallium/drivers/llvmpipe/lp_setup.c |2 +-
>  src/gallium/drivers/llvmpipe/lp_state_fs.c  |  152 
> +++
>  5 files changed, 126 insertions(+), 89 deletions(-)
> 
> diff --git a/src/gallium/drivers/llvmpipe/lp_rast.c 
> b/src/gallium/drivers/llvmpipe/lp_rast.c
> index 6feec94..3e25ff0 100644
> --- a/src/gallium/drivers/llvmpipe/lp_rast.c
> +++ b/src/gallium/drivers/llvmpipe/lp_rast.c
> @@ -124,7 +124,8 @@ lp_rast_clear_color(struct lp_rasterizer_task *task,
>unsigned i;
>union util_color uc;
>  
> -  if (util_format_is_pure_integer(scene->fb.cbufs[0]->format)) {
> +  if (scene->fb.cbufs[0] &&
> +  util_format_is_pure_integer(scene->fb.cbufs[0]->format)) {
This isn't quite correct, since if the first fb is NULL but the second
is a pure int you'd end up in the non pure int code path below. Maybe
would be easier if just iterating over all fbs in the outermost loop and
doing that decision per fb (this only worked because mixed int/fixed fbs
weren't allowed, but it should be quite ok deciding that per fb anyway).

>   /*
>* We expect int/uint clear values here, though some APIs
>* might disagree (but in any case util_pack_color()
> @@ -174,20 +175,22 @@ lp_rast_clear_color(struct lp_rasterizer_task *task,
>  clear_color[3]);
>  
>   for (i = 0; i < scene->fb.nr_cbufs; i++) {
> -util_pack_color(arg.clear_color.f,
> -scene->fb.cbufs[i]->format, &uc);
> -
> -util_fill_box(scene->cbufs[i].map,
> -  scene->fb.cbufs[i]->format,
> -  scene->cbufs[i].stride,
> -  scene->cbufs[i].layer_stride,
> -  task->x,
> -  task->y,
> -  0,
> -  task->width,
> -  task->height,
> -  scene->fb_max_layer + 1,
> -  &uc);
> +if (scene->fb.cbufs[i]) {
> +   util_pack_color(arg.clear_color.f,
> +   scene->fb.cbufs[i]->format, &uc);
> +
> +   util_fill_box(scene->cbufs[i].map,
> + scene->fb.cbufs[i]->format,
> + scene->cbufs[i].stride,
> + scene->cbufs[i].layer_stride,
> + task->x,
> + task->y,
> + 0,
> + task->width,
> + task->height,
> + scene->fb_max_layer + 1,
> + &uc);
> +}
>   }
>}
> }
> @@ -444,8 +447,15 @@ lp_rast_shade_quads_mask(struct lp_rasterizer_task *task,
>  
> /* color buffer */
> for (i = 0; i < scene->fb.nr_cbufs; i++) {
> -  stride[i] = scene->cbufs[i].stride;
> -  color[i] = lp_rast_get_unswizzled_color_block_pointer(task, i, x, y, 
> inputs->layer);
> +  if (scene->fb.cbufs[i]) {
> + stride[i] = scene->cbufs[i].stride;
> + color[i] = lp_rast_get_unswizzled_color_block_pointer(task, i, x, y,
> +   
> inputs->layer);
> +  }
> +  else {
> + stride[i] = 0;
> + color[i] = NULL;
> +  }
> }
>  
> /* depth buffer */
> diff --git a/src/gallium/drivers/llvmpipe/lp_rast_priv.h 
> b/src/gallium/drivers/llvmpipe/lp_rast_priv.h
> index bc361b6..063a70e 100644
> --- a/src/gallium/drivers/llvmpipe/lp_rast_priv.h
> +++ b/src/gallium/drivers/llvmpipe/lp_rast_priv.h
> @@ -293,8 +293,15 @@ lp_rast_shade_quads_all( struct lp_rasterizer_task *task,
>  
> /* color buffer */
> for (i = 0; i < scene->fb.nr_cbufs; i++) {
> -  stride[i] = scene->cbufs[i].stride;
> -  color[i] = lp_rast_get_unswizzled_color_block_pointer(task, i, x, y, 
> inputs->layer);
> +  if (scene->fb.cbufs[i]) {
> + stride[i] = scene->cbufs[i].stride;
> + color[i] = lp_rast_get_unswizzled_color_block_pointer(task, i, x, y,
> +   
> inputs->layer);
> +  }
> +  else {
> + stride[i] = 0;
> + color[i] = NULL;
> +  }
> }
>  
> if (scene->zsbuf.map) {
> diff --git a/src/gallium/drivers/llvmpipe/lp_scene.c 
> b/src/gallium/drivers/llvmpipe/lp_scene.c
> index 0296b79..134ab86 100644
> --- a/src/gallium/drivers/llvmpipe/lp_scene.c
> +++ b/src/gallium/drivers/llvmpipe/lp_scene.c
> @@ -156,6 +156,10

Re: [Mesa-dev] [PATCH 1/2] softpipe: handle NULL color buffer pointers

[Roland Scheidegger]

Am 16.01.2014 03:15, schrieb Brian Paul:
> Fixes regression from 9baa45f78b8ca7d66280e36009b6a685055d7cd6
> ---
>  src/gallium/drivers/softpipe/sp_quad_blend.c |  189 
> +-
>  1 file changed, 96 insertions(+), 93 deletions(-)
> 
> diff --git a/src/gallium/drivers/softpipe/sp_quad_blend.c 
> b/src/gallium/drivers/softpipe/sp_quad_blend.c
> index d122586..00a9be6 100644
> --- a/src/gallium/drivers/softpipe/sp_quad_blend.c
> +++ b/src/gallium/drivers/softpipe/sp_quad_blend.c
> @@ -927,93 +927,94 @@ blend_fallback(struct quad_stage *qs,
>  
> write_all = softpipe->fs_variant->info.color0_writes_all_cbufs;
>  
> -   for (cbuf = 0; cbuf < softpipe->framebuffer.nr_cbufs; cbuf++) 
> -   {
> -  /* which blend/mask state index to use: */
> -  const uint blend_buf = blend->independent_blend_enable ? cbuf : 0;
> -  float dest[4][TGSI_QUAD_SIZE];
> -  struct softpipe_cached_tile *tile
> - = sp_get_cached_tile(softpipe->cbuf_cache[cbuf],
> -  quads[0]->input.x0, 
> -  quads[0]->input.y0);
> -  const boolean clamp = bqs->clamp[cbuf];
> -  const float *blend_color;
> -  const boolean dual_source_blend = util_blend_state_is_dual(blend, 
> cbuf);
> -  uint q, i, j;
> -
> -  if (clamp)
> - blend_color = softpipe->blend_color_clamped.color;
> -  else
> - blend_color = softpipe->blend_color.color;
> -
> -  for (q = 0; q < nr; q++) {
> - struct quad_header *quad = quads[q];
> - float (*quadColor)[4];
> - float (*quadColor2)[4] = NULL;
> - float temp_quad_color[TGSI_QUAD_SIZE][4];
> - const int itx = (quad->input.x0 & (TILE_SIZE-1));
> - const int ity = (quad->input.y0 & (TILE_SIZE-1));
> -
> - if (write_all) {
> -for (j = 0; j < TGSI_QUAD_SIZE; j++) {
> -   for (i = 0; i < 4; i++) {
> -  temp_quad_color[i][j] = quad->output.color[0][i][j];
> +   for (cbuf = 0; cbuf < softpipe->framebuffer.nr_cbufs; cbuf++) {
> +  if (softpipe->framebuffer.cbufs[cbuf]) {
> + /* which blend/mask state index to use: */
> + const uint blend_buf = blend->independent_blend_enable ? cbuf : 0;
> + float dest[4][TGSI_QUAD_SIZE];
> + struct softpipe_cached_tile *tile
> += sp_get_cached_tile(softpipe->cbuf_cache[cbuf],
> + quads[0]->input.x0, 
> + quads[0]->input.y0);
> + const boolean clamp = bqs->clamp[cbuf];
> + const float *blend_color;
> + const boolean dual_source_blend = util_blend_state_is_dual(blend, 
> cbuf);
> + uint q, i, j;
> +
> + if (clamp)
> +blend_color = softpipe->blend_color_clamped.color;
> + else
> +blend_color = softpipe->blend_color.color;
> +
> + for (q = 0; q < nr; q++) {
> +struct quad_header *quad = quads[q];
> +float (*quadColor)[4];
> +float (*quadColor2)[4] = NULL;
> +float temp_quad_color[TGSI_QUAD_SIZE][4];
> +const int itx = (quad->input.x0 & (TILE_SIZE-1));
> +const int ity = (quad->input.y0 & (TILE_SIZE-1));
> +
> +if (write_all) {
> +   for (j = 0; j < TGSI_QUAD_SIZE; j++) {
> +  for (i = 0; i < 4; i++) {
> + temp_quad_color[i][j] = quad->output.color[0][i][j];
> +  }
> }
> +   quadColor = temp_quad_color;
> +} else {
> +   quadColor = quad->output.color[cbuf];
> +   if (dual_source_blend)
> +  quadColor2 = quad->output.color[cbuf + 1];
>  }
> -quadColor = temp_quad_color;
> - } else {
> -quadColor = quad->output.color[cbuf];
> - if (dual_source_blend)
> -quadColor2 = quad->output.color[cbuf + 1];
> - }
>  
> - /* If fixed-point dest color buffer, need to clamp the incoming
> -  * fragment colors now.
> -  */
> - if (clamp || softpipe->rasterizer->clamp_fragment_color) {
> -clamp_colors(quadColor);
> - }
> +/* If fixed-point dest color buffer, need to clamp the incoming
> + * fragment colors now.
> + */
> +if (clamp || softpipe->rasterizer->clamp_fragment_color) {
> +   clamp_colors(quadColor);
> +}
>  
> - /* get/swizzle dest colors
> -  */
> - for (j = 0; j < TGSI_QUAD_SIZE; j++) {
> -int x = itx + (j & 1);
> -int y = ity + (j >> 1);
> -for (i = 0; i < 4; i++) {
> -   dest[i][j] = tile->data.color[y][x][i];
> +/* get/swizzle dest colors
> + */
> +for (j = 0; j < TGSI_QUAD_SIZE; j++) {
> +   int x = itx + (j & 1);
> +   int y = ity + (j >> 1)

Re: [Mesa-dev] [RFC] freedreno: add tgsi lowering pass

[Matt Turner]

On Wed, Jan 15, 2014 at 5:40 AM, Rob Clark  wrote:
> From: Rob Clark 
>
> So, as I found myself needing to lower a few more TGSI instructions,
> and noticing yet again that I would have to do the same lowering as
> various other gallium drivers already do,  I decided that maybe it
> makes sense to do this instead generically in a way that could maybe
> help other drivers too.
>
> This currently lowers the following instructions:
>
>DST, XPD, SCS, LRP, FRC, POW, LIT, EXP, LOG

I think we already have GLSL IR level lowering passes for lrp, pow,
exp, and log. Can't you use those?

> translating these into equivalent simpler TGSI instructions.  There
> are probably more that could be lowered.  These are just common
> instructions, and/or ones I ran across in some piglit tests, which
> I needed to lower.  I might add the various DP permutations as well,
> which would let me get rid of even more lower-directly-to-native
> code in fd3_compiler.
>
> I was sort of wondering about sticking this in aux/util or aux/tgsi,
> and somehow making it configurable which instructions to lower, since
> it seems that it could be useful to other drivers?
>
> ---
>  src/gallium/drivers/freedreno/Makefile.sources |1 +
>  src/gallium/drivers/freedreno/a3xx/fd3_program.c   |7 +-
>  src/gallium/drivers/freedreno/freedreno_lowering.c | 1037 
> 
>  src/gallium/drivers/freedreno/freedreno_lowering.h |   36 +
>  4 files changed, 1079 insertions(+), 2 deletions(-)
>  create mode 100644 src/gallium/drivers/freedreno/freedreno_lowering.c
>  create mode 100644 src/gallium/drivers/freedreno/freedreno_lowering.h
>
> diff --git a/src/gallium/drivers/freedreno/Makefile.sources 
> b/src/gallium/drivers/freedreno/Makefile.sources
> index 092b09f..3dcec9d 100644
> --- a/src/gallium/drivers/freedreno/Makefile.sources
> +++ b/src/gallium/drivers/freedreno/Makefile.sources
> @@ -1,5 +1,6 @@
>  C_SOURCES := \
> freedreno_util.c \
> +   freedreno_lowering.c \
> freedreno_query.c \
> freedreno_fence.c \
> freedreno_resource.c \
> diff --git a/src/gallium/drivers/freedreno/a3xx/fd3_program.c 
> b/src/gallium/drivers/freedreno/a3xx/fd3_program.c
> index 0886c49..ad76b66 100644
> --- a/src/gallium/drivers/freedreno/a3xx/fd3_program.c
> +++ b/src/gallium/drivers/freedreno/a3xx/fd3_program.c
> @@ -34,6 +34,8 @@
>  #include "tgsi/tgsi_dump.h"
>  #include "tgsi/tgsi_parse.h"
>
> +#include "freedreno_lowering.h"
> +
>  #include "fd3_program.h"
>  #include "fd3_compiler.h"
>  #include "fd3_emit.h"
> @@ -87,6 +89,7 @@ create_shader(struct pipe_context *pctx, const struct 
> pipe_shader_state *cso,
> enum shader_t type)
>  {
> struct fd3_shader_stateobj *so = CALLOC_STRUCT(fd3_shader_stateobj);
> +   const struct tgsi_token *tokens = fd_transform_lowering(cso->tokens);
> int ret;
>
> if (!so)
> @@ -96,13 +99,13 @@ create_shader(struct pipe_context *pctx, const struct 
> pipe_shader_state *cso,
>
> if (fd_mesa_debug & FD_DBG_DISASM) {
> DBG("dump tgsi: type=%d", so->type);
> -   tgsi_dump(cso->tokens, 0);
> +   tgsi_dump(tokens, 0);
> }
>
> if ((type == SHADER_FRAGMENT) && (fd_mesa_debug & FD_DBG_FRAGHALF))
> so->half_precision = true;
>
> -   ret = fd3_compile_shader(so, cso->tokens);
> +   ret = fd3_compile_shader(so, tokens);
> if (ret) {
> debug_error("compile failed!");
> goto fail;
> diff --git a/src/gallium/drivers/freedreno/freedreno_lowering.c 
> b/src/gallium/drivers/freedreno/freedreno_lowering.c
> new file mode 100644
> index 000..354969f
> --- /dev/null
> +++ b/src/gallium/drivers/freedreno/freedreno_lowering.c
> @@ -0,0 +1,1037 @@
> +/* -*- mode: C; c-file-style: "k&r"; tab-width 4; indent-tabs-mode: t; -*- */
> +

Doesn't seem like what you want. I'd hope you didn't need a modeline at all.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] i965: Move binding table update packets to binding table setup time.

[Eric Anholt]

This keeps us from needing to reemit all the other stage state just
because a surface changed.

Improves unoptimized glamor x11perf -f8text by 1.10201% +/- 0.489869%
(n=296).
---
 src/mesa/drivers/dri/i965/brw_binding_tables.c | 51 --
 src/mesa/drivers/dri/i965/gen7_gs_state.c  |  7 
 src/mesa/drivers/dri/i965/gen7_vs_state.c  |  7 
 src/mesa/drivers/dri/i965/gen7_wm_state.c  |  7 
 4 files changed, 39 insertions(+), 33 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_binding_tables.c 
b/src/mesa/drivers/dri/i965/brw_binding_tables.c
index b39bd10..ca42472 100644
--- a/src/mesa/drivers/dri/i965/brw_binding_tables.c
+++ b/src/mesa/drivers/dri/i965/brw_binding_tables.c
@@ -50,7 +50,7 @@
  * This copies brw_stage_state::surf_offset[] into the indirect state section
  * of the batchbuffer (allocated by brw_state_batch()).
  */
-static void
+static bool
 brw_upload_binding_table(struct brw_context *brw,
  GLbitfield brw_new_binding_table,
  struct brw_stage_state *stage_state)
@@ -63,8 +63,9 @@ brw_upload_binding_table(struct brw_context *brw,
   if (stage_state->bind_bo_offset != 0) {
  brw->state.dirty.brw |= brw_new_binding_table;
  stage_state->bind_bo_offset = 0;
+ return true;
   }
-  return;
+  return false;
}
 
if (INTEL_DEBUG & DEBUG_SHADER_TIME) {
@@ -81,6 +82,7 @@ brw_upload_binding_table(struct brw_context *brw,
memcpy(bind, stage_state->surf_offset, prog_data->binding_table.size_bytes);
 
brw->state.dirty.brw |= brw_new_binding_table;
+   return true;
 }
 
 /**
@@ -92,15 +94,23 @@ brw_upload_binding_table(struct brw_context *brw,
 static void
 brw_vs_upload_binding_table(struct brw_context *brw)
 {
-   brw_upload_binding_table(brw, BRW_NEW_VS_BINDING_TABLE, &brw->vs.base);
+   if (brw_upload_binding_table(brw, BRW_NEW_VS_BINDING_TABLE, &brw->vs.base)) 
{
+  if (brw->gen >= 7) {
+ BEGIN_BATCH(2);
+ OUT_BATCH(_3DSTATE_BINDING_TABLE_POINTERS_VS << 16 | (2 - 2));
+ OUT_BATCH(brw->vs.base.bind_bo_offset);
+ ADVANCE_BATCH();
+  }
+   }
 }
 
 const struct brw_tracked_state brw_vs_binding_table = {
.dirty = {
   .mesa = 0,
-  .brw = BRW_NEW_BATCH |
- BRW_NEW_VS_CONSTBUF |
- BRW_NEW_SURFACES,
+  .brw = (BRW_NEW_BATCH |
+  BRW_NEW_STATE_BASE_ADDRESS |
+  BRW_NEW_VS_CONSTBUF |
+  BRW_NEW_SURFACES),
   .cache = CACHE_NEW_VS_PROG
},
.emit = brw_vs_upload_binding_table,
@@ -111,13 +121,22 @@ const struct brw_tracked_state brw_vs_binding_table = {
 static void
 brw_upload_wm_binding_table(struct brw_context *brw)
 {
-   brw_upload_binding_table(brw, BRW_NEW_PS_BINDING_TABLE, &brw->wm.base);
+   if (brw_upload_binding_table(brw, BRW_NEW_PS_BINDING_TABLE, &brw->wm.base)) 
{
+  if (brw->gen >= 7) {
+ BEGIN_BATCH(2);
+ OUT_BATCH(_3DSTATE_BINDING_TABLE_POINTERS_PS << 16 | (2 - 2));
+ OUT_BATCH(brw->wm.base.bind_bo_offset);
+ ADVANCE_BATCH();
+  }
+   }
 }
 
 const struct brw_tracked_state brw_wm_binding_table = {
.dirty = {
   .mesa = 0,
-  .brw = BRW_NEW_BATCH | BRW_NEW_SURFACES,
+  .brw = (BRW_NEW_BATCH |
+  BRW_NEW_STATE_BASE_ADDRESS |
+  BRW_NEW_SURFACES),
   .cache = CACHE_NEW_WM_PROG
},
.emit = brw_upload_wm_binding_table,
@@ -131,15 +150,23 @@ brw_gs_upload_binding_table(struct brw_context *brw)
if (brw->geometry_program == NULL)
   return;
 
-   brw_upload_binding_table(brw, BRW_NEW_GS_BINDING_TABLE, &brw->gs.base);
+   if (brw_upload_binding_table(brw, BRW_NEW_GS_BINDING_TABLE, &brw->gs.base)) 
{
+  if (brw->gen >= 7) {
+ BEGIN_BATCH(2);
+ OUT_BATCH(_3DSTATE_BINDING_TABLE_POINTERS_GS << 16 | (2 - 2));
+ OUT_BATCH(brw->gs.base.bind_bo_offset);
+ ADVANCE_BATCH();
+  }
+   }
 }
 
 const struct brw_tracked_state brw_gs_binding_table = {
.dirty = {
   .mesa = 0,
-  .brw = BRW_NEW_BATCH |
- BRW_NEW_GS_CONSTBUF |
- BRW_NEW_SURFACES,
+  .brw = (BRW_NEW_BATCH |
+  BRW_NEW_STATE_BASE_ADDRESS |
+  BRW_NEW_GS_CONSTBUF |
+  BRW_NEW_SURFACES),
   .cache = CACHE_NEW_GS_PROG
},
.emit = brw_gs_upload_binding_table,
diff --git a/src/mesa/drivers/dri/i965/gen7_gs_state.c 
b/src/mesa/drivers/dri/i965/gen7_gs_state.c
index d2ba354..92b872f 100644
--- a/src/mesa/drivers/dri/i965/gen7_gs_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_gs_state.c
@@ -66,12 +66,6 @@ upload_gs_state(struct brw_context *brw)
/* CACHE_NEW_GS_PROG */
const struct brw_vec4_prog_data *prog_data = &brw->gs.prog_data->base;
 
-   /* BRW_NEW_GS_BINDING_TABLE */
-   BEGIN_BATCH(2);
-   OUT_BATCH(_3DSTATE_BINDING_TABLE_POINTERS_GS << 16 | (2 - 2));
-   OUT_BATCH(stage_state->bind_bo_offset);
-   ADVANCE_BATCH();
-
/* CACHE_NEW_SAMPLER */
BEGI

[Mesa-dev] [Bug 73672] Half Life 2 in Wine is broken since 4e549ddb

[bugzilla-daemon]

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

Tapani Pälli  changed:

   What|Removed |Added

   Assignee|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop
   |org |.org
  Component|Mesa core   |Drivers/Gallium/r600

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

[Mesa-dev] [PATCH 0/9] glsl: Start implementing ARB_arrays_of_arrays

[Timothy Arceri]

This is a first pass at implementing the ARB_arrays_of_arrays extension in Mesa.
This series allows the Mesa front-end to parse and compile shaders that dont 
require linking of
arrays of arrays e.g. multi dimensional uniforms. I'm sending this extension in 
parts because my
time working on this is about to decrease and I'm not sure how long it will be 
before I finish the second half.
If this is not a good idea please let me know.

Patches 3-4 need to be squashed when commited but I've split them here to make 
reviewing easier.

Patch 5 is optional

Whats missing is linking and backend support that goes with it. This includes 
the linking checks the spec talks about for geometry shaders.
Also its possible that some small changes are also needed to support multi 
dimensional unsized geom shader arrays I havent yet written
the piglit tests for this.

No piglit regressions with these patches applied.

Timothy Arceri (9):
  Mesa: Add ARB_arrays_of_arrays
  glsl: add dimension_count to glsl_types
  glsl: Add arrays_of_arrays to yacc definition
  glsl: Add array specifier to ast code
  glsl: only call mark_max_array if we are assigning an  array
  glsl: Implement ARB_arrays_of_arrays support for  constructors
  glsl: Aggregate initializer support for arrays of array
  glsl: Allow arrays of arrays as input to vertex shader
  docs: Mark ARB_arrays_of_arrays as started

 docs/GL3.txt|   2 +-
 src/glsl/ast.h  |  64 +
 src/glsl/ast_array_index.cpp|  13 +++
 src/glsl/ast_function.cpp   |  69 --
 src/glsl/ast_to_hir.cpp | 204 +---
 src/glsl/ast_type.cpp   |   8 +-
 src/glsl/glsl_parser.yy | 183 ++-
 src/glsl/glsl_parser_extras.cpp |  97 ---
 src/glsl/glsl_parser_extras.h   |   2 +
 src/glsl/glsl_types.cpp |  15 ++-
 src/glsl/glsl_types.h   |  17 +++-
 src/mesa/main/extensions.c  |   1 +
 src/mesa/main/mtypes.h  |   1 +
 13 files changed, 464 insertions(+), 212 deletions(-)

-- 
1.8.3.1

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

[Mesa-dev] [PATCH 2/9] glsl: add dimension_count to glsl_types

[Timothy Arceri]

Signed-off-by: Timothy Arceri 
---
 src/glsl/glsl_types.cpp | 15 +++
 src/glsl/glsl_types.h   | 17 -
 2 files changed, 27 insertions(+), 5 deletions(-)

diff --git a/src/glsl/glsl_types.cpp b/src/glsl/glsl_types.cpp
index 12d4ac0..1c9add7 100644
--- a/src/glsl/glsl_types.cpp
+++ b/src/glsl/glsl_types.cpp
@@ -277,12 +277,13 @@ _mesa_glsl_release_types(void)
 }
 
 
-glsl_type::glsl_type(const glsl_type *array, unsigned length) :
+glsl_type::glsl_type(const glsl_type *array, unsigned length,
+ unsigned dimension_count) :
base_type(GLSL_TYPE_ARRAY),
sampler_dimensionality(0), sampler_shadow(0), sampler_array(0),
sampler_type(0), interface_packing(0),
vector_elements(0), matrix_columns(0),
-   name(NULL), length(length)
+   name(NULL), length(length), dimension_count(dimension_count)
 {
this->fields.array = array;
/* Inherit the gl type of the base. The GL type is used for
@@ -416,10 +417,16 @@ glsl_type::get_instance(unsigned base_type, unsigned 
rows, unsigned columns)
return error_type;
 }
 
-
 const glsl_type *
 glsl_type::get_array_instance(const glsl_type *base, unsigned array_size)
 {
+   return get_array_instance(base, array_size, 1);
+}
+
+const glsl_type *
+glsl_type::get_array_instance(const glsl_type *base, unsigned array_size,
+  unsigned dimension_count)
+{
 
if (array_types == NULL) {
   array_types = hash_table_ctor(64, hash_table_string_hash,
@@ -436,7 +443,7 @@ glsl_type::get_array_instance(const glsl_type *base, 
unsigned array_size)
 
const glsl_type *t = (glsl_type *) hash_table_find(array_types, key);
if (t == NULL) {
-  t = new glsl_type(base, array_size);
+  t = new glsl_type(base, array_size, dimension_count);
 
   hash_table_insert(array_types, (void *) t, ralloc_strdup(mem_ctx, key));
}
diff --git a/src/glsl/glsl_types.h b/src/glsl/glsl_types.h
index fb7c928..e047a16 100644
--- a/src/glsl/glsl_types.h
+++ b/src/glsl/glsl_types.h
@@ -146,6 +146,12 @@ struct glsl_type {
unsigned length;
 
/**
+* For \c GLSL_TYPE_ARRAY, this is how many dimensions the array
+* contains.
+*/
+   unsigned dimension_count;
+
+   /**
 * Subtype of composite data types.
 */
union {
@@ -223,6 +229,14 @@ struct glsl_type {
  unsigned elements);
 
/**
+* Get the instance of an array type include dimension count
+* for arrays of arrays
+*/
+   static const glsl_type *get_array_instance(const glsl_type *base,
+ unsigned elements,
+  unsigned dimension_count);
+
+   /**
 * Get the instance of a record type
 */
static const glsl_type *get_record_instance(const glsl_struct_field *fields,
@@ -571,7 +585,8 @@ private:
 enum glsl_interface_packing packing, const char *name);
 
/** Constructor for array types */
-   glsl_type(const glsl_type *array, unsigned length);
+   glsl_type(const glsl_type *array, unsigned length,
+ unsigned dimension_count);
 
/** Hash table containing the known array types. */
static struct hash_table *array_types;
-- 
1.8.3.1

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

[Mesa-dev] [PATCH 1/9] Mesa: Add ARB_arrays_of_arrays

[Timothy Arceri]

Signed-off-by: Timothy Arceri 
---
 src/mesa/main/extensions.c | 1 +
 src/mesa/main/mtypes.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
index 2e0ccc3..95eb7ca 100644
--- a/src/mesa/main/extensions.c
+++ b/src/mesa/main/extensions.c
@@ -80,6 +80,7 @@ static const struct extension extension_table[] = {
/* ARB Extensions */
{ "GL_ARB_ES2_compatibility",   o(ARB_ES2_compatibility),   
GL, 2009 },
{ "GL_ARB_ES3_compatibility",   o(ARB_ES3_compatibility),   
GL, 2012 },
+   { "GL_ARB_arrays_of_arrays",o(ARB_arrays_of_arrays),
GL, 2012 },
{ "GL_ARB_base_instance",   o(ARB_base_instance),   
GL, 2011 },
{ "GL_ARB_blend_func_extended", o(ARB_blend_func_extended), 
GL, 2009 },
{ "GL_ARB_clear_buffer_object", o(dummy_true),  
GL, 2012 },
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 33df682..eef67a8 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -3366,6 +3366,7 @@ struct gl_extensions
GLboolean ANGLE_texture_compression_dxt;
GLboolean ARB_ES2_compatibility;
GLboolean ARB_ES3_compatibility;
+   GLboolean ARB_arrays_of_arrays;
GLboolean ARB_base_instance;
GLboolean ARB_blend_func_extended;
GLboolean ARB_color_buffer_float;
-- 
1.8.3.1

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

[Mesa-dev] [PATCH 3/9] glsl: Add arrays_of_arrays to yacc definition

[Timothy Arceri]

Signed-off-by: Timothy Arceri 
---
 src/glsl/glsl_parser.yy | 153 +---
 1 file changed, 66 insertions(+), 87 deletions(-)

diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy
index 1c56d6f..6d63668 100644
--- a/src/glsl/glsl_parser.yy
+++ b/src/glsl/glsl_parser.yy
@@ -97,6 +97,7 @@ static bool match_layout_qualifier(const char *s1, const char 
*s2,
 
ast_node *node;
ast_type_specifier *type_specifier;
+   ast_array_specifier *array_specifier;
ast_fully_specified_type *fully_specified_type;
ast_function *function;
ast_parameter_declarator *parameter_declarator;
@@ -202,6 +203,7 @@ static bool match_layout_qualifier(const char *s1, const 
char *s2,
 %type  interface_qualifier
 %type  type_specifier
 %type  type_specifier_nonarray
+%type  array_specifier
 %type  basic_type_specifier_nonarray
 %type  fully_specified_type
 %type  function_prototype
@@ -880,7 +882,7 @@ parameter_declarator:
   $$->type->specifier = $1;
   $$->identifier = $2;
}
-   | type_specifier any_identifier '[' constant_expression ']'
+   | type_specifier any_identifier array_specifier
{
   void *ctx = state;
   $$ = new(ctx) ast_parameter_declarator();
@@ -890,7 +892,7 @@ parameter_declarator:
   $$->type->specifier = $1;
   $$->identifier = $2;
   $$->is_array = true;
-  $$->array_size = $4;
+  $$->array_specifier = $3;
}
;
 
@@ -983,53 +985,28 @@ init_declarator_list:
   $$->declarations.push_tail(&decl->link);
   state->symbols->add_variable(new(state) ir_variable(NULL, $3, 
ir_var_auto));
}
-   | init_declarator_list ',' any_identifier '[' ']'
+   | init_declarator_list ',' any_identifier array_specifier
{
   void *ctx = state;
-  ast_declaration *decl = new(ctx) ast_declaration($3, true, NULL, NULL);
+  ast_declaration *decl = new(ctx) ast_declaration($3, true, $4, NULL);
   decl->set_location(yylloc);
 
   $$ = $1;
   $$->declarations.push_tail(&decl->link);
   state->symbols->add_variable(new(state) ir_variable(NULL, $3, 
ir_var_auto));
}
-   | init_declarator_list ',' any_identifier '[' constant_expression ']'
+   | init_declarator_list ',' any_identifier array_specifier '=' initializer
{
   void *ctx = state;
-  ast_declaration *decl = new(ctx) ast_declaration($3, true, $5, NULL);
+  ast_declaration *decl = new(ctx) ast_declaration($3, true, $4, $6);
   decl->set_location(yylloc);
 
   $$ = $1;
   $$->declarations.push_tail(&decl->link);
   state->symbols->add_variable(new(state) ir_variable(NULL, $3, 
ir_var_auto));
-   }
-   | init_declarator_list ',' any_identifier '[' ']' '=' initializer
-   {
-  void *ctx = state;
-  ast_declaration *decl = new(ctx) ast_declaration($3, true, NULL, $7);
-  decl->set_location(yylloc);
-
-  $$ = $1;
-  $$->declarations.push_tail(&decl->link);
-  state->symbols->add_variable(new(state) ir_variable(NULL, $3, 
ir_var_auto));
-  if ($7->oper == ast_aggregate) {
- ast_aggregate_initializer *ai = (ast_aggregate_initializer *)$7;
- ast_type_specifier *type = new(ctx) 
ast_type_specifier($1->type->specifier, true, NULL);
- _mesa_ast_set_aggregate_type(type, ai, state);
-  }
-   }
-   | init_declarator_list ',' any_identifier '[' constant_expression ']' '=' 
initializer
-   {
-  void *ctx = state;
-  ast_declaration *decl = new(ctx) ast_declaration($3, true, $5, $8);
-  decl->set_location(yylloc);
-
-  $$ = $1;
-  $$->declarations.push_tail(&decl->link);
-  state->symbols->add_variable(new(state) ir_variable(NULL, $3, 
ir_var_auto));
-  if ($8->oper == ast_aggregate) {
- ast_aggregate_initializer *ai = (ast_aggregate_initializer *)$8;
- ast_type_specifier *type = new(ctx) 
ast_type_specifier($1->type->specifier, true, $5);
+  if ($6->oper == ast_aggregate) {
+ ast_aggregate_initializer *ai = (ast_aggregate_initializer *)$6;
+ ast_type_specifier *type = new(ctx) 
ast_type_specifier($1->type->specifier, true, $4);
  _mesa_ast_set_aggregate_type(type, ai, state);
   }
}
@@ -1067,49 +1044,26 @@ single_declaration:
   $$->set_location(yylloc);
   $$->declarations.push_tail(&decl->link);
}
-   | fully_specified_type any_identifier '[' ']'
+   | fully_specified_type any_identifier array_specifier
{
   void *ctx = state;
-  ast_declaration *decl = new(ctx) ast_declaration($2, true, NULL, NULL);
+  ast_declaration *decl = new(ctx) ast_declaration($2, true, $3, NULL);
 
   $$ = new(ctx) ast_declarator_list($1);
   $$->set_location(yylloc);
   $$->declarations.push_tail(&decl->link);
}
-   | fully_specified_type any_identifier '[' constant_expression ']'
+   | fully_specified_type any_identifier array_specifier '=' initializer
{
   void *ctx = state;
-  ast_declaration *decl = new(ctx) ast_declaration($2, true, $4, NULL);

[Mesa-dev] [PATCH 6/9] glsl: Implement ARB_arrays_of_arrays support for constructors

[Timothy Arceri]

Signed-off-by: Timothy Arceri 
---
 src/glsl/ast_function.cpp | 54 ---
 1 file changed, 46 insertions(+), 8 deletions(-)

diff --git a/src/glsl/ast_function.cpp b/src/glsl/ast_function.cpp
index 2d05d07..57aa45f 100644
--- a/src/glsl/ast_function.cpp
+++ b/src/glsl/ast_function.cpp
@@ -734,6 +734,7 @@ process_array_constructor(exec_list *instructions,
 *Section 4.1.10 "Implicit Conversions.""
 */
exec_list actual_parameters;
+
const unsigned parameter_count =
   process_parameters(instructions, &actual_parameters, parameters, state);
bool is_unsized_array = constructor_type->is_unsized_array();
@@ -752,8 +753,10 @@ process_array_constructor(exec_list *instructions,
 
if (is_unsized_array) {
   constructor_type =
-glsl_type::get_array_instance(constructor_type->element_type(),
-  parameter_count);
+ glsl_type::get_array_instance(constructor_type->element_type(),
+   parameter_count,
+   constructor_type->dimension_count);
+
   assert(constructor_type != NULL);
   assert(constructor_type->length == parameter_count);
}
@@ -782,14 +785,49 @@ process_array_constructor(exec_list *instructions,
 }
   }
 
-  if (result->type != constructor_type->element_type()) {
-_mesa_glsl_error(loc, state, "type error in array constructor: "
- "expected: %s, found %s",
- constructor_type->element_type()->name,
- result->type->name);
+  if (constructor_type->dimension_count == 1 &&
+  result->type != constructor_type->element_type()) {
+ _mesa_glsl_error(loc, state, "type error in array constructor: "
+  "expected: %s, found %s",
+  constructor_type->element_type()->name,
+  result->type->name);
  return ir_rvalue::error_value(ctx);
   }
 
+  /* compare arrays of arrays dimensions, element type, and sizes*/
+  if (result->type->is_array()) {
+
+ if (result->type->dimension_count != 
(constructor_type->dimension_count-1)) {
+ _mesa_glsl_error(loc, state, "type error in array constructor: "
+ "expected array with: %u dimension(s),"
+  " found %u dimension(s)",
+  constructor_type->dimension_count-1,
+  result->type->dimension_count);
+ return ir_rvalue::error_value(ctx);
+ }
+
+ const glsl_type *expected_type = constructor_type->element_type();
+ const glsl_type *result_type = result->type;
+ for (unsigned i=0; itype->dimension_count; i++) {
+if (result_type->length != expected_type->length) {
+   _mesa_glsl_error(loc, state, "type error in array constructor: "
+"expected array with size: %u,"
+" found size %u",
+expected_type->length,
+result_type->length);
+   return ir_rvalue::error_value(ctx);
+}
+expected_type = expected_type->element_type();
+result_type = result_type->element_type();
+ }
+
+ if (expected_type != result_type) {
+_mesa_glsl_error(loc, state, "type error in array constructor: "
+"expected: %s",
+ expected_type->name);
+ }
+  }
+
   /* Attempt to convert the parameter to a constant valued expression.
* After doing so, track whether or not all the parameters to the
* constructor are trivially constant valued expressions.
@@ -808,7 +846,7 @@ process_array_constructor(exec_list *instructions,
   return new(ctx) ir_constant(constructor_type, &actual_parameters);
 
ir_variable *var = new(ctx) ir_variable(constructor_type, "array_ctor",
-  ir_var_temporary);
+   ir_var_temporary);
instructions->push_tail(var);
 
int i = 0;
-- 
1.8.3.1

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

[Mesa-dev] [PATCH 5/9] glsl: only call mark_max_array if we are assigning an array

[Timothy Arceri]

Signed-off-by: Timothy Arceri 
---
 src/glsl/ast_to_hir.cpp | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index c0e3443..359a0b8 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -830,8 +830,10 @@ do_assignment(exec_list *instructions, struct 
_mesa_glsl_parse_state *state,
   rhs->type->array_size());
 d->type = var->type;
   }
-  mark_whole_array_access(rhs);
-  mark_whole_array_access(lhs);
+  if (lhs->type->is_array()) {
+ mark_whole_array_access(rhs);
+ mark_whole_array_access(lhs);
+  }
}
 
/* Most callers of do_assignment (assign, add_assign, pre_inc/dec,
-- 
1.8.3.1

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

[Mesa-dev] [PATCH 8/9] glsl: Allow arrays of arrays as input to vertex shader

[Timothy Arceri]

Signed-off-by: Timothy Arceri 
---
 src/glsl/ast_to_hir.cpp | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index 3054b9c..a83ef9c 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -3196,6 +3196,10 @@ ast_declarator_list::hir(exec_list *instructions,
   if (state->is_version(120, 300))
  break;
   /* FALLTHROUGH */
+case GLSL_TYPE_ARRAY:
+   if (state->ARB_arrays_of_arrays_enable)
+  break;
+   /* FALLTHROUGH */
default:
   _mesa_glsl_error(& loc, state,
"vertex shader input / attribute cannot have "
-- 
1.8.3.1

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

[Mesa-dev] [PATCH 9/9] docs: Mark ARB_arrays_of_arrays as started

[Timothy Arceri]

Signed-off-by: Timothy Arceri 
---
 docs/GL3.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/GL3.txt b/docs/GL3.txt
index 0672ec7..9f756e9 100644
--- a/docs/GL3.txt
+++ b/docs/GL3.txt
@@ -142,7 +142,7 @@ GL 4.2:
 GL 4.3:
 
   GLSL 4.3 not started
-  GL_ARB_arrays_of_arrays  not started
+  GL_ARB_arrays_of_arrays  started
   GL_ARB_ES3_compatibility DONE (i965)
   GL_ARB_clear_buffer_object   not started
   GL_ARB_compute_shadernot started
-- 
1.8.3.1

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

[Mesa-dev] [PATCH 4/9] glsl: Add array specifier to ast code

[Timothy Arceri]

Signed-off-by: Timothy Arceri 
---
 src/glsl/ast.h  |  45 +++
 src/glsl/ast_array_index.cpp|  13 +++
 src/glsl/ast_to_hir.cpp | 173 +++-
 src/glsl/ast_type.cpp   |   8 +-
 src/glsl/glsl_parser_extras.cpp |  30 +++
 src/glsl/glsl_parser_extras.h   |   2 +
 6 files changed, 179 insertions(+), 92 deletions(-)

diff --git a/src/glsl/ast.h b/src/glsl/ast.h
index 76911f0..bbae9cd 100644
--- a/src/glsl/ast.h
+++ b/src/glsl/ast.h
@@ -276,6 +276,21 @@ private:
bool cons;
 };
 
+class ast_array_specifier : public ast_node {
+public:
+   ast_array_specifier()
+  : ast_node()
+   {
+  dimension_count = 1;
+   }
+
+   virtual void print(void) const;
+
+   unsigned dimension_count;
+   bool is_unsized_array;
+   exec_list array_dimensions;
+};
+
 /**
  * C-style aggregate initialization class
  *
@@ -325,14 +340,15 @@ public:
 
 class ast_declaration : public ast_node {
 public:
-   ast_declaration(const char *identifier, bool is_array, ast_expression 
*array_size,
-  ast_expression *initializer);
+   ast_declaration(const char *identifier, bool is_array,
+   ast_array_specifier *array_specifier,
+   ast_expression *initializer);
virtual void print(void) const;
 
const char *identifier;

bool is_array;
-   ast_expression *array_size;
+   ast_array_specifier *array_specifier;
 
ast_expression *initializer;
 };
@@ -531,7 +547,6 @@ public:
 };
 
 
-
 class ast_type_specifier : public ast_node {
 public:
/**
@@ -542,9 +557,9 @@ public:
 * be modified. Zeros the inherited ast_node's fields.
 */
ast_type_specifier(const ast_type_specifier *that, bool is_array,
-  ast_expression *array_size)
+  ast_array_specifier *array_specifier)
   : ast_node(), type_name(that->type_name), structure(that->structure),
-is_array(is_array), array_size(array_size),
+is_array(is_array), array_specifier(array_specifier),
 default_precision(that->default_precision)
{
   /* empty */
@@ -553,7 +568,7 @@ public:
/** Construct a type specifier from a type name */
ast_type_specifier(const char *name) 
   : type_name(name), structure(NULL),
-   is_array(false), array_size(NULL),
+   is_array(false), array_specifier(NULL),
default_precision(ast_precision_none)
{
   /* empty */
@@ -562,7 +577,7 @@ public:
/** Construct a type specifier from a structure definition */
ast_type_specifier(ast_struct_specifier *s)
   : type_name(s->name), structure(s),
-   is_array(false), array_size(NULL),
+   is_array(false), array_specifier(NULL),
default_precision(ast_precision_none)
{
   /* empty */
@@ -580,7 +595,7 @@ public:
ast_struct_specifier *structure;
 
bool is_array;
-   ast_expression *array_size;
+   ast_array_specifier *array_specifier;
 
/** For precision statements, this is the given precision; otherwise none. 
*/
unsigned default_precision:2;
@@ -634,7 +649,7 @@ public:
   type(NULL),
   identifier(NULL),
   is_array(false),
-  array_size(NULL),
+  array_specifier(NULL),
   formal_parameter(false),
   is_void(false)
{
@@ -649,7 +664,7 @@ public:
ast_fully_specified_type *type;
const char *identifier;
bool is_array;
-   ast_expression *array_size;
+   ast_array_specifier *array_specifier;
 
static void parameters_to_hir(exec_list *ast_parameters,
 bool formal, exec_list *ir_parameters,
@@ -897,12 +912,12 @@ public:
ast_interface_block(ast_type_qualifier layout,
const char *instance_name,
bool is_array,
-   ast_expression *array_size)
+   ast_array_specifier *array_specifier)
: layout(layout), block_name(NULL), instance_name(instance_name),
- is_array(is_array), array_size(array_size)
+ is_array(is_array), array_specifier(array_specifier)
{
   if (!is_array)
- assert(array_size == NULL);
+ assert(array_specifier == NULL);
}
 
virtual ir_rvalue *hir(exec_list *instructions,
@@ -937,7 +952,7 @@ public:
 * If the block is not declared as an array or if the block instance array
 * is unsized, this field will be \c NULL.
 */
-   ast_expression *array_size;
+   ast_array_specifier *array_specifier;
 };
 
 
diff --git a/src/glsl/ast_array_index.cpp b/src/glsl/ast_array_index.cpp
index a5f2320..f3b060e 100644
--- a/src/glsl/ast_array_index.cpp
+++ b/src/glsl/ast_array_index.cpp
@@ -25,6 +25,19 @@
 #include "glsl_types.h"
 #include "ir.h"
 
+void
+ast_array_specifier::print(void) const
+{
+   if (this->is_unsized_array) {
+  printf("[ ] ");
+   }
+
+   foreach_list_typed (ast_node, array_dimension, link, 
&this->array_dimensions) {
+  printf("[ ");
+  array_dimension->print();
+  printf("] "

[Mesa-dev] [PATCH 7/9] glsl: Aggregate initializer support for arrays of array

[Timothy Arceri]

Signed-off-by: Timothy Arceri 
---
 src/glsl/ast.h  | 19 +++-
 src/glsl/ast_function.cpp   | 15 +++--
 src/glsl/ast_to_hir.cpp | 31 +++---
 src/glsl/glsl_parser.yy | 36 -
 src/glsl/glsl_parser_extras.cpp | 69 +++--
 5 files changed, 144 insertions(+), 26 deletions(-)

diff --git a/src/glsl/ast.h b/src/glsl/ast.h
index bbae9cd..3ec8b75 100644
--- a/src/glsl/ast.h
+++ b/src/glsl/ast.h
@@ -308,10 +308,16 @@ public:
   : ast_expression(ast_aggregate, NULL, NULL, NULL),
 constructor_type(NULL)
{
-  /* empty */
+  array_dimension = 1;
+  is_array = false;
}
 
ast_type_specifier *constructor_type;
+   unsigned array_dimension;
+
+   ast_array_specifier *array_specifier;
+   bool is_array;
+
virtual ir_rvalue *hir(exec_list *instructions,
   struct _mesa_glsl_parse_state *state);
 };
@@ -587,6 +593,11 @@ public:
 struct _mesa_glsl_parse_state *state)
   const;
 
+   const struct glsl_type *glsl_type(const char **name,
+ struct _mesa_glsl_parse_state *state,
+ bool skip_outer_dimension)
+  const;
+
virtual void print(void) const;
 
ir_rvalue *hir(exec_list *, struct _mesa_glsl_parse_state *);
@@ -1004,4 +1015,10 @@ extern void
 check_builtin_array_max_size(const char *name, unsigned size,
  YYLTYPE loc, struct _mesa_glsl_parse_state 
*state);
 
+extern const glsl_type *
+process_array_type_skip_dim(YYLTYPE *loc, const glsl_type *base,
+ast_array_specifier *array_specifier,
+   struct _mesa_glsl_parse_state *state,
+bool skip_first_dim);
+
 #endif /* AST_H */
diff --git a/src/glsl/ast_function.cpp b/src/glsl/ast_function.cpp
index 57aa45f..f60cd19 100644
--- a/src/glsl/ast_function.cpp
+++ b/src/glsl/ast_function.cpp
@@ -1731,8 +1731,19 @@ ast_aggregate_initializer::hir(exec_list *instructions,
   _mesa_glsl_error(&loc, state, "type of C-style initializer unknown");
   return ir_rvalue::error_value(ctx);
}
-   const glsl_type *const constructor_type =
-  this->constructor_type->glsl_type(&name, state);
+   const glsl_type *constructor_type =
+  this->constructor_type->glsl_type(&name, state,
+this->array_dimension > 1 && 
!this->is_array);
+
+   /* This only handles "vec4 foo[..]".  The earlier 
constructor_type->glsl_type(...)
+* call already handled the "vec4[..] foo" case.
+*/
+   if (this->is_array) {
+  constructor_type =
+ process_array_type_skip_dim(&loc, constructor_type,
+ this->array_specifier, state,
+ this->array_dimension > 1);
+   }
 
if (!state->ARB_shading_language_420pack_enable) {
   _mesa_glsl_error(&loc, state, "C-style initialization requires the "
diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index 359a0b8..3054b9c 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -1817,10 +1817,11 @@ process_array_size(exec_node *node,
return result;
 }
 
-static const glsl_type *
-process_array_type(YYLTYPE *loc, const glsl_type *base,
-   ast_array_specifier *array_specifier,
-   struct _mesa_glsl_parse_state *state)
+const glsl_type *
+process_array_type_skip_dim(YYLTYPE *loc, const glsl_type *base,
+ast_array_specifier *array_specifier,
+struct _mesa_glsl_parse_state *state,
+bool skip_first_dim)
 {
const glsl_type *array_type = NULL;
const glsl_type *element_type = base;
@@ -1871,6 +1872,8 @@ process_array_type(YYLTYPE *loc, const glsl_type *base,
 
   unsigned array_size;
   for (/* nothing */; !node->is_head_sentinel(); node = node->prev) {
+ if (skip_first_dim && node->prev->is_head_sentinel())
+break;
  array_size = process_array_size(node, state);
  array_type_temp = glsl_type::get_array_instance(array_type_temp,
  array_size,
@@ -1898,10 +1901,27 @@ process_array_type(YYLTYPE *loc, const glsl_type *base,
return array_type != NULL ? array_type : glsl_type::error_type;
 }
 
+static const glsl_type *
+process_array_type(YYLTYPE *loc, const glsl_type *base,
+   ast_array_specifier *array_specifier,
+   struct _mesa_glsl_parse_state *state)
+{
+   return process_array_type_skip_dim(loc, base, array_specifier,
+  state, false);
+}
+
 const glsl_type *
 ast_type_specifier::glsl_type(const char **name,
  struct _mesa_glsl_parse_state *state) const
 {
+   return this->glsl_type(name, state

Re: [Mesa-dev] [PATCH 09/16] i965/fs: Calculate interference better in register_coalesce.

[Jordan Justen]

On Thu, Dec 19, 2013 at 1:40 PM, Matt Turner  wrote:
> Previously we simply considered two registers whose live ranges
> overlapped to interfere. Cases such as
>
>set A --
>... |
>mov B, A  --|
>... | B | A
>use B --|
>... |
>use A --
>
> would be considered to interfere, even though B is an unmodified copy of
> A whose live range fit wholly inside that of A.
>
> If no writes to A or B occur between the mov B, A and the use of B then
> we can safely coalesce them.
>
> Instead of removing MOV instructions, we make them NOPs and remove them
> at once after the main pass is finished in order to avoid recomputing
> live intervals (which are needed to perform the previous step).
>
> total instructions in shared programs: 1543768 -> 1513077 (-1.99%)
> instructions in affected programs: 951563 -> 920872 (-3.23%)
> GAINED:46
> LOST:  22
> ---
>  src/mesa/drivers/dri/i965/brw_fs.cpp | 69 
> 
>  1 file changed, 62 insertions(+), 7 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp 
> b/src/mesa/drivers/dri/i965/brw_fs.cpp
> index e4ac0a5..ad56b87 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
> @@ -2273,7 +2273,7 @@ fs_visitor::register_coalesce()
> int last_use[MAX_SAMPLER_MESSAGE_SIZE];
> int next_ip = 0;
>
> -   foreach_list_safe(node, &this->instructions) {
> +   foreach_list(node, &this->instructions) {
>fs_inst *inst = (fs_inst *)node;
>
>int ip = next_ip;
> @@ -2299,8 +2299,39 @@ fs_visitor::register_coalesce()
>int var_to = live_intervals->var_from_reg(&inst->dst);
>
>if (live_intervals->vars_interfere(var_from, var_to) &&
> -  !inst->dst.equals(inst->src[0]))
> - continue;
> +  !inst->dst.equals(inst->src[0])) {
> +
> + if (live_intervals->end[var_to] > live_intervals->end[var_from])
> +continue;
> +
> + bool overwritten = false;
> + int scan_ip = -1;
> +
> + foreach_list(n, &this->instructions) {
> +   fs_inst *scan_inst = (fs_inst *)n;

Tab on this line?

Reviewed-by: Jordan Justen 

> +scan_ip++;
> +
> +if (scan_inst->is_control_flow()) {
> +   overwritten = true;
> +   break;
> +}
> +
> +if (scan_ip <= live_intervals->start[var_to])
> +   continue;
> +
> +if (scan_ip > live_intervals->end[var_to])
> +   break;
> +
> +if (scan_inst->dst.equals(inst->dst) ||
> +scan_inst->dst.equals(inst->src[0])) {
> +   overwritten = true;
> +   break;
> +}
> + }
> +
> + if (overwritten)
> +continue;
> +  }
>
>if (reg_from != inst->src[0].reg) {
>   reg_from = inst->src[0].reg;
> @@ -2342,9 +2373,18 @@ fs_visitor::register_coalesce()
>if (live_channels_remaining)
>   continue;
>
> +  bool removed = false;
>for (int i = 0; i < src_size; i++) {
> - if (mov[i])
> -mov[i]->remove();
> + if (mov[i]) {
> +removed = true;
> +
> +mov[i]->opcode = BRW_OPCODE_NOP;
> +mov[i]->conditional_mod = BRW_CONDITIONAL_NONE;
> +mov[i]->dst = reg_undef;
> +mov[i]->src[0] = reg_undef;
> +mov[i]->src[1] = reg_undef;
> +mov[i]->src[2] = reg_undef;
> + }
>}
>
>foreach_list(node, &this->instructions) {
> @@ -2366,11 +2406,26 @@ fs_visitor::register_coalesce()
>   scan_inst->src[j].reg_offset = reg_to_offset[i];
>}
> }
> -
> -   progress = true;
>  }
>   }
>}
> +
> +  if (removed) {
> + live_intervals->start[var_to] = MIN2(live_intervals->start[var_to],
> +  
> live_intervals->start[var_from]);
> + live_intervals->end[var_to] = MAX2(live_intervals->end[var_to],
> +live_intervals->end[var_from]);
> + reg_from = -1;
> +  }
> +   }
> +
> +   foreach_list_safe(node, &this->instructions) {
> +  fs_inst *inst = (fs_inst *)node;
> +
> +  if (inst->opcode == BRW_OPCODE_NOP) {
> + inst->remove();
> + progress = true;
> +  }
> }
>
> if (progress)
> --
> 1.8.3.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] gallium endianness and hw drivers

[Michel Dänzer]

On Mit, 2014-01-15 at 14:27 +0100, Marek Olšák wrote:
> On Wed, Jan 15, 2014 at 7:07 AM, Michel Dänzer  wrote:
> > On Die, 2014-01-14 at 00:22 +0100, Marek Olšák wrote:
> >> I think the format conversion functions should look like:
> >>
> >> #ifdef BIG_ENDIAN
> >>case PIPE_FORMAT_A8B8G8R8_UNORM:
> >>   return hw_format_for_R8G8B8A8_UNORM;
> >> ...
> >> #else
> >>case PIPE_FORMAT_R8G8B8A8_UNORM:
> >>   return hw_format_for_R8G8B8A8_UNORM;
> >> #endif
> >>
> >> which can be simplified to:
> >>
> >>case PIPE_FORMAT_RGBA_UNORM:
> >>   return hw_format_for_R8G8B8A8_UNORM;
> >>
> >> So that the GPU can see the same formats, but they are different for the 
> >> CPU.
> >>
> >> What do you think?
> >
> > That might be an option, but PIPE_FORMAT_R8G8B8A8_UNORM is useful on big
> > endian hosts as well, e.g. it matches GL_RGBA / GL_UNSIGNED_BYTE
> > exactly.
> 
> I wouldn't worry about such optimizations when we don't even have
> proper big endian support.

I'd consider it part of proper big endian support though.


> I'd rather stick to the simplest solution for the old hardware.

What do you mean by old hardware? Remember that SI and newer have
basically no hardware byteswapping facilities anymore, and PowerPC
machines with PCIe slots are still being produced and sold.


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

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