Re: [Mesa-dev] [PATCH] glsl: Don't require matching centroid qualifiers
On Friday, March 25, 2016 2:15:51 PM PDT Jordan Justen wrote:
> Note: This patch appears to violate older OpenGL and OpenGLES specs.
>
> The OpenGLES GLSL 3.1 and OpenGL GLSL 4.3 specifications both remove
> the requirement for the output and input centroid qualifiers to match.
>
> The deqp
> dEQP-
GLES3.functional.shaders.linkage.varying.rules.differing_interpolation_2
> test wants the newer OpenGLES 3.1 specification behavior, even for
> OpenGLES 3.0. This patch simply removes the checking in all cases.
>
> The OpenGLES 3.0 conformance test suite doesn't appear to require the
> older ("must match") spec behavior.
>
> For reference, here are the relavent spec citations:
>
> The OpenGL 4.2 spec says: "the last active shader stage output
> variables and fragment shader input variables of the same name must
> match in type and qualification (other than out matching to in)"
>
> The OpenGL 4.3 spec says: "interpolation qualification (e.g., flat)
> and auxiliary qualification (e.g. centroid) may differ."
>
> The OpenGLES GLSL 3.00.4 specification says: "The output of the
> vertex shader and the input of the fragment shader form an
> interface. For this interface, vertex shader output variables and
> fragment shader input variables of the same name must match in type
> and qualification (other than precision and out matching to in)."
>
> The OpenGLES GLSL 3.10 Specification says: "interpolation
> qualification (e.g., flat) and auxiliary qualification (e.g.
> centroid) may differ"
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92743
> Bugzilla: https://cvs.khronos.org/bugzilla/show_bug.cgi?id=7819
> Signed-off-by: Jordan Justen
> Cc: Ian Romanick
> Cc: Kenneth Graunke
> ---
> I previously posted a patch that strictly matched the specs:
> https://lists.freedesktop.org/archives/mesa-dev/2016-March/110183.html
>
> src/compiler/glsl/link_varyings.cpp | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/src/compiler/glsl/link_varyings.cpp b/src/compiler/glsl/
link_varyings.cpp
> index 44fc8f6..6e413ba 100644
> --- a/src/compiler/glsl/link_varyings.cpp
> +++ b/src/compiler/glsl/link_varyings.cpp
> @@ -121,7 +121,16 @@ cross_validate_types_and_qualifiers(struct
gl_shader_program *prog,
>
> /* Check that all of the qualifiers match between stages.
> */
> - if (input->data.centroid != output->data.centroid) {
> +
> + /* According to the OpenGL and OpenGLES GLSL specs, the centroid
qualifier
> +* should match until OpenGL 4.3 and OpenGLES 3.1. The OpenGLES 3.0
> +* conformance test suite does not verify that the qualifiers must
match.
> +* The deqp test suite expects the opposite (OpenGLES 3.1) behavior for
> +* OpenGLES 3.0 drivers, so we relax the checking in all cases.
> +*/
> + if (false /* always skip the centroid check */ &&
> + prog->Version < (prog->IsES ? 310 : 430) &&
> + input->data.centroid != output->data.centroid) {
>linker_error(prog,
> "%s shader output `%s' %s centroid qualifier, "
> "but %s shader input %s centroid qualifier\n",
>
This seems reasonable, and I think is faithful to Ian's recommendation:
if there's no conformance test for the old behavior, treat the newly
relaxed behavior as the right thing to do.
Reviewed-by: Kenneth Graunke
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Request for opinions on merging ARB_enhanced_layouts component packing
Hi all, Patches for implementing all the pieces of ARB_enhanced_layouts (and therefore the remain pieces of OpenGL 4.4) are now on the list. However things are in limbo with component packing due to the complexity and issues with patch 24 [1]. During development I went from passing the packing information down to the backend to having a lowering pass in GLSL IR a couple of times before settling on the lowering pass. The lowering pass has the advantage of working on all drivers and avoiding complexity in the backend. It does however get a bit complicated when handling tessellation shaders. Currently it also has a couple of limitations. The tess packing pass doesn't currently handle packing of different array types (sizes) or arrays starting at different locations. This is allowed by the spec and works in other stages but I'm throwing an error for now when we come across these in tess, however this pass is still more compliant than the Nvidia blob which can't pack arrays in tess at all. My thinking is that eventually we might want to redo this to pass the packing information down to the backend rather than trying to shadow varyings in GLSL IR but for now I would like to see what others think about merging this as is and revisiting again later if need be. Patches 20-24 are the only unreviewed patches [2] and at this point I'd settle for an acked for the final patches. [1] https://patchwork.freedesktop.org/patch/75984/ [2] https://patchwork.freedesktop.org/series/3897/ ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965: Don't use CUBE wrap modes for integer formats.
There is no linear filtering for integer formats, so we should always
be using CLAMP_TO_EDGE mode.
Fixes 46 dEQP cases on Ivybridge.
This workaround doesn't appear to be necessary on later hardware, and
I haven't found any documentation mentioning errata in this area.
However, it seems harmless to apply generally, so we may as well.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_sampler_state.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_sampler_state.c
b/src/mesa/drivers/dri/i965/brw_sampler_state.c
index 7bd21f7..7e44cf5 100644
--- a/src/mesa/drivers/dri/i965/brw_sampler_state.c
+++ b/src/mesa/drivers/dri/i965/brw_sampler_state.c
@@ -463,7 +463,8 @@ brw_update_sampler_state(struct brw_context *brw,
/* Cube maps must use the same wrap mode for all three coordinate
* dimensions. Prior to Haswell, only CUBE and CLAMP are valid.
*/
- if (tex_cube_map_seamless || sampler->CubeMapSeamless) {
+ if ((tex_cube_map_seamless || sampler->CubeMapSeamless) &&
+ !is_integer_format) {
wrap_s = BRW_TEXCOORDMODE_CUBE;
wrap_t = BRW_TEXCOORDMODE_CUBE;
wrap_r = BRW_TEXCOORDMODE_CUBE;
--
2.7.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3] compiler/glsl: invalidate float suffixes for glsl 1.10
NOTE: someone with access will need to commit this patch after the
review process
v2: modify error message
v3: parse the float instead of returning an ERROR_TOK
Invalidates float suffixes for glsl 1.10
Fixes the following piglit tests:
tests/spec/glsl-1.10/compiler/literals/invalid-float-suffix-capital-f.vert
tests/spec/glsl-1.10/compiler/literals/invalid-float-suffix-f.vert`
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81585
Signed-off-by: Lars Hamre
Reviewed-by: Timothy Arceri
Reviewed-by: Kenneth Graunke
---
src/compiler/glsl/glsl_lexer.ll | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/compiler/glsl/glsl_lexer.ll b/src/compiler/glsl/glsl_lexer.ll
index 1f12265..6084d71 100644
--- a/src/compiler/glsl/glsl_lexer.ll
+++ b/src/compiler/glsl/glsl_lexer.ll
@@ -472,6 +472,13 @@ layout {
\.[0-9]+([eE][+-]?[0-9]+)?[fF]?|
[0-9]+\.([eE][+-]?[0-9]+)?[fF]?|
[0-9]+[eE][+-]?[0-9]+[fF]? {
+ struct _mesa_glsl_parse_state *state = yyextra;
+ char suffix = yytext[strlen(yytext) - 1];
+ if (!state->is_version(120, 0) &&
+ (suffix == 'f' || suffix == 'F')) {
+ _mesa_glsl_error(yylloc, state,
+"Float suffixes are invalid in
GLSL 1.10");
+ }
yylval->real = _mesa_strtof(yytext, NULL);
return FLOATCONSTANT;
}
--
2.5.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] compiler/glsl: invalidate float suffixes for glsl 1.10
That sounds good to me, I will submit a v3 with those edits.
On Mon, Mar 28, 2016 at 9:19 PM, Kenneth Graunke
wrote:
> On Monday, March 28, 2016 8:16:17 PM PDT Lars Hamre wrote:
> > NOTE: someone with access will need to commit this patch after the
> > review process
> >
> > Invalidates float suffixes for glsl 1.10
> >
> > Fixes the following piglit tests:
> >
> tests/spec/glsl-1.10/compiler/literals/invalid-float-suffix-capital-f.vert
> > tests/spec/glsl-1.10/compiler/literals/invalid-float-suffix-f.vert`
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81585
> >
> > Signed-off-by: Lars Hamre
> > Reviewed-by: Timothy Arceri
> >
> > ---
> > src/compiler/glsl/glsl_lexer.ll | 13 +++--
> > 1 file changed, 11 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/compiler/glsl/glsl_lexer.ll b/src/compiler/glsl/
> glsl_lexer.ll
> > index 1f12265..0980f4f 100644
> > --- a/src/compiler/glsl/glsl_lexer.ll
> > +++ b/src/compiler/glsl/glsl_lexer.ll
> > @@ -472,8 +472,17 @@ layout {
> > \.[0-9]+([eE][+-]?[0-9]+)?[fF]? |
> > [0-9]+\.([eE][+-]?[0-9]+)?[fF]? |
> > [0-9]+[eE][+-]?[0-9]+[fF]? {
> > - yylval->real = _mesa_strtof(yytext, NULL);
> > - return FLOATCONSTANT;
> > + struct _mesa_glsl_parse_state *state = yyextra;
> > + char suffix = yytext[strlen(yytext) - 1];
> > + if (!state->is_version(120, 0) &&
> > + (suffix == 'f' || suffix == 'F')) {
> > + _mesa_glsl_error(yylloc, state,
> > + "Float suffixes are
> invalid in GLSL
> 1.10");
> > + return ERROR_TOK;
> > + } else {
> > + yylval->real = _mesa_strtof(yytext, NULL);
> > + return FLOATCONSTANT;
> > + }
>
> Hi Lars,
>
> Good catch! Would it also work to do:
>
> if (!state->is_version(120, 0) &&
> (suffix == 'f' || suffix == 'F')) {
> _mesa_glsl_error(yylloc, state,
> "Float suffixes are invalid in
> GLSL 1.10");
> }
> yylval->real = _mesa_strtof(yytext, NULL);
> return FLOATCONSTANT;
>
> In other words, raise the error and fail the compile, but parse the
> float literal as intended. I think returning ERROR_TOK is likely to
> make the parser hit bison-generated "Expected , got OTHER TOKENS>" errors that are pretty cryptic. Parsing the number in
> the obvious manner would let the compile proceed normally, so we don't
> get cascading errors that might be confusing.
>
> That patch would get a:
> Reviewed-by: Kenneth Graunke
>
> > }
> >
> > [0-9]+\.[0-9]+([eE][+-]?[0-9]+)?(lf|LF) |
> > --
> > 2.5.5
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] tgsi: collect texture sampler target info in tgsi_scan_shader()
Texture sample instructions specify a sampler unit and texture target
such as "1D", "2D", "CUBE", etc. Sampler view declarations also specify
the sampler unit and texture target.
This patch checks that the texture instructions agree with the declarations
and collects the texture target type for each sampler unit.
---
src/gallium/auxiliary/tgsi/tgsi_scan.c | 33 +++--
src/gallium/auxiliary/tgsi/tgsi_scan.h | 1 +
2 files changed, 32 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_scan.c
b/src/gallium/auxiliary/tgsi/tgsi_scan.c
index d32c3a1..796101d 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_scan.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_scan.c
@@ -181,11 +181,28 @@ scan_instruction(struct tgsi_shader_info *info,
info->indirect_files_read |= (1 << src->Register.File);
}
- /* MSAA samplers */
+ /* Texture samplers */
if (src->Register.File == TGSI_FILE_SAMPLER) {
+ const unsigned index = src->Register.Index;
+ const unsigned target = fullinst->Texture.Texture;
+
assert(fullinst->Instruction.Texture);
- assert(src->Register.Index < Elements(info->is_msaa_sampler));
+ assert(index < Elements(info->is_msaa_sampler));
+ assert(index < PIPE_MAX_SAMPLERS);
+ assert(target < TGSI_TEXTURE_UNKNOWN);
+
+ /* check/save target */
+ if (info->sampler_targets[index] == TGSI_TEXTURE_UNKNOWN) {
+/* probably no sampler view declaration */
+info->sampler_targets[index] = target;
+ } else {
+/* Make sure the texture instruction's sampler/target info
+ * agrees with the sampler view declaration.
+ */
+assert(info->sampler_targets[index] == target);
+ }
+ /* MSAA samplers */
if (fullinst->Instruction.Texture &&
(fullinst->Texture.Texture == TGSI_TEXTURE_2D_MSAA ||
fullinst->Texture.Texture == TGSI_TEXTURE_2D_ARRAY_MSAA)) {
@@ -431,6 +448,16 @@ scan_declaration(struct tgsi_shader_info *info,
}
} else if (file == TGSI_FILE_SAMPLER) {
info->samplers_declared |= 1 << reg;
+ } else if (file == TGSI_FILE_SAMPLER_VIEW) {
+ unsigned target = fulldecl->SamplerView.Resource;
+ assert(target < TGSI_TEXTURE_UNKNOWN);
+ if (info->sampler_targets[reg] == TGSI_TEXTURE_UNKNOWN) {
+/* Save sampler target for this sampler index */
+info->sampler_targets[reg] = target;
+ } else {
+/* if previously declared, make sure targets agree */
+assert(info->sampler_targets[reg] == target);
+ }
} else if (file == TGSI_FILE_IMAGE) {
if (fulldecl->Image.Resource == TGSI_TEXTURE_BUFFER)
info->images_buffers |= 1 << reg;
@@ -493,6 +520,8 @@ tgsi_scan_shader(const struct tgsi_token *tokens,
for (i = 0; i < Elements(info->const_file_max); i++)
info->const_file_max[i] = -1;
info->properties[TGSI_PROPERTY_GS_INVOCATIONS] = 1;
+ for (i = 0; i < Elements(info->sampler_targets); i++)
+ info->sampler_targets[i] = TGSI_TEXTURE_UNKNOWN;
/**
** Setup to begin parsing input shader
diff --git a/src/gallium/auxiliary/tgsi/tgsi_scan.h
b/src/gallium/auxiliary/tgsi/tgsi_scan.h
index 76d8925..25855c8 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_scan.h
+++ b/src/gallium/auxiliary/tgsi/tgsi_scan.h
@@ -65,6 +65,7 @@ struct tgsi_shader_info
int file_max[TGSI_FILE_COUNT]; /**< highest index of declared registers */
int const_file_max[PIPE_MAX_CONSTANT_BUFFERS];
unsigned samplers_declared; /**< bitmask of declared samplers */
+ ubyte sampler_targets[PIPE_MAX_SAMPLERS]; /**< TGSI_TEXTURE_x values */
ubyte input_array_first[PIPE_MAX_SHADER_INPUTS];
ubyte input_array_last[PIPE_MAX_SHADER_INPUTS];
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] mesa: make _mesa_prepare_mipmap_level() static
No longer called from any other file.
---
src/mesa/main/mipmap.c | 16
src/mesa/main/mipmap.h | 7 ---
2 files changed, 8 insertions(+), 15 deletions(-)
diff --git a/src/mesa/main/mipmap.c b/src/mesa/main/mipmap.c
index cb9afde..5ff53f4 100644
--- a/src/mesa/main/mipmap.c
+++ b/src/mesa/main/mipmap.c
@@ -1810,11 +1810,11 @@ _mesa_next_mipmap_level_size(GLenum target, GLint
border,
* for mipmap generation. If not, (re) allocate it.
* \return GL_TRUE if successful, GL_FALSE if mipmap generation should stop
*/
-GLboolean
-_mesa_prepare_mipmap_level(struct gl_context *ctx,
- struct gl_texture_object *texObj, GLuint level,
- GLsizei width, GLsizei height, GLsizei depth,
- GLsizei border, GLenum intFormat, mesa_format
format)
+static GLboolean
+prepare_mipmap_level(struct gl_context *ctx,
+ struct gl_texture_object *texObj, GLuint level,
+ GLsizei width, GLsizei height, GLsizei depth,
+ GLsizei border, GLenum intFormat, mesa_format format)
{
const GLuint numFaces = _mesa_num_tex_faces(texObj->Target);
GLuint face;
@@ -1902,9 +1902,9 @@ _mesa_prepare_mipmap_levels(struct gl_context *ctx,
break;
}
- if (!_mesa_prepare_mipmap_level(ctx, texObj, level,
- newWidth, newHeight, newDepth,
- border, intFormat, texFormat)) {
+ if (!prepare_mipmap_level(ctx, texObj, level,
+newWidth, newHeight, newDepth,
+border, intFormat, texFormat)) {
break;
}
diff --git a/src/mesa/main/mipmap.h b/src/mesa/main/mipmap.h
index 33913e8..d11c7fa 100644
--- a/src/mesa/main/mipmap.h
+++ b/src/mesa/main/mipmap.h
@@ -40,13 +40,6 @@ _mesa_generate_mipmap_level(GLenum target,
GLubyte **dstData,
GLint dstRowStride);
-
-extern GLboolean
-_mesa_prepare_mipmap_level(struct gl_context *ctx,
- struct gl_texture_object *texObj, GLuint level,
- GLsizei width, GLsizei height, GLsizei depth,
- GLsizei border, GLenum intFormat, mesa_format
format);
-
void
_mesa_prepare_mipmap_levels(struct gl_context *ctx,
struct gl_texture_object *texObj,
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] meta: use _mesa_prepare_mipmap_levels()
The prepare_mipmap_level() wrapper for _mesa_prepare_mipmap_level() is
not needed. It only served to undo the GL_TEXTURE_1D_ARRAY height/depth
change was was made before the call to prepare_mipmap_level()
Said another way, regardless of how the meta code manipulates the height/
depth dims for GL_TEXTURE_1D_ARRAY, the gl_texture_image dimensions are
correctly set up by _mesa_prepare_mipmap_levels().
Tested by plugging _mesa_meta_GenerateMipmap() into the swrast driver
and testing with piglit.
---
src/mesa/drivers/common/meta_generate_mipmap.c | 26 ++
1 file changed, 2 insertions(+), 24 deletions(-)
diff --git a/src/mesa/drivers/common/meta_generate_mipmap.c
b/src/mesa/drivers/common/meta_generate_mipmap.c
index d4b7539..7b29702 100644
--- a/src/mesa/drivers/common/meta_generate_mipmap.c
+++ b/src/mesa/drivers/common/meta_generate_mipmap.c
@@ -137,21 +137,6 @@ _mesa_meta_glsl_generate_mipmap_cleanup(struct gl_context
*ctx,
_mesa_meta_blit_shader_table_cleanup(ctx, &mipmap->shaders);
}
-static GLboolean
-prepare_mipmap_level(struct gl_context *ctx,
- struct gl_texture_object *texObj, GLuint level,
- GLsizei width, GLsizei height, GLsizei depth,
- GLenum intFormat, mesa_format format)
-{
- if (texObj->Target == GL_TEXTURE_1D_ARRAY) {
- /* Work around Mesa expecting the number of array slices in "height". */
- height = depth;
- depth = 1;
- }
-
- return _mesa_prepare_mipmap_level(ctx, texObj, level, width, height, depth,
- 0, intFormat, format);
-}
/**
* Called via ctx->Driver.GenerateMipmap()
@@ -270,6 +255,8 @@ _mesa_meta_GenerateMipmap(struct gl_context *ctx, GLenum
target,
/* texture is already locked, unlock now */
_mesa_unlock_texture(ctx, texObj);
+ _mesa_prepare_mipmap_levels(ctx, texObj, baseLevel, maxLevel);
+
for (dstLevel = baseLevel + 1; dstLevel <= maxLevel; dstLevel++) {
const struct gl_texture_image *srcImage;
struct gl_texture_image *dstImage;
@@ -309,15 +296,6 @@ _mesa_meta_GenerateMipmap(struct gl_context *ctx, GLenum
target,
_mesa_texture_parameteriv(ctx, texObj, GL_TEXTURE_MAX_LEVEL,
(GLint *) &dstLevel, false);
- if (!prepare_mipmap_level(ctx, texObj, dstLevel,
-dstWidth, dstHeight, dstDepth,
-srcImage->InternalFormat,
-srcImage->TexFormat)) {
- /* All done. We either ran out of memory or we would go beyond the
- * last valid level of an immutable texture if we continued.
- */
- break;
- }
dstImage = _mesa_select_tex_image(texObj, faceTarget, dstLevel);
/* limit minification to src level */
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: new _mesa_prepare_mipmap_levels() function for mipmap generation
Simplifies the loops in generate_mipmap_uncompressed() and
generate_mipmap_compressed(). Will be used in the state tracker too.
Could probably be used in the meta code. If so, some additional
clean-ups can be done after that.
v2: use unsigned types instead of GLuint, per Ian
---
src/mesa/main/mipmap.c | 88 --
src/mesa/main/mipmap.h | 5 +++
2 files changed, 62 insertions(+), 31 deletions(-)
diff --git a/src/mesa/main/mipmap.c b/src/mesa/main/mipmap.c
index 5a02780..cb9afde 100644
--- a/src/mesa/main/mipmap.c
+++ b/src/mesa/main/mipmap.c
@@ -1872,6 +1872,49 @@ _mesa_prepare_mipmap_level(struct gl_context *ctx,
}
+/**
+ * Prepare all mipmap levels beyond 'baseLevel' for mipmap generation.
+ * When finished, all the gl_texture_image structures for the smaller
+ * mipmap levels will be consistent with the base level (in terms of
+ * dimensions, format, etc).
+ */
+void
+_mesa_prepare_mipmap_levels(struct gl_context *ctx,
+struct gl_texture_object *texObj,
+unsigned baseLevel, unsigned maxLevel)
+{
+ const struct gl_texture_image *baseImage =
+ _mesa_select_tex_image(texObj, texObj->Target, baseLevel);
+ const GLint border = 0;
+ GLint width = baseImage->Width;
+ GLint height = baseImage->Height;
+ GLint depth = baseImage->Depth;
+ const GLenum intFormat = baseImage->InternalFormat;
+ const mesa_format texFormat = baseImage->TexFormat;
+ GLint newWidth, newHeight, newDepth;
+
+ /* Prepare baseLevel + 1, baseLevel + 2, ... */
+ for (unsigned level = baseLevel + 1; level <= maxLevel; level++) {
+ if (!_mesa_next_mipmap_level_size(texObj->Target, border,
+width, height, depth,
+&newWidth, &newHeight, &newDepth)) {
+ /* all done */
+ break;
+ }
+
+ if (!_mesa_prepare_mipmap_level(ctx, texObj, level,
+ newWidth, newHeight, newDepth,
+ border, intFormat, texFormat)) {
+ break;
+ }
+
+ width = newWidth;
+ height = newHeight;
+ depth = newDepth;
+ }
+}
+
+
static void
generate_mipmap_uncompressed(struct gl_context *ctx, GLenum target,
struct gl_texture_object *texObj,
@@ -1892,7 +1935,6 @@ generate_mipmap_uncompressed(struct gl_context *ctx,
GLenum target,
GLint dstWidth, dstHeight, dstDepth;
GLint border;
GLint slice;
- GLboolean nextLevel;
GLubyte **srcMaps, **dstMaps;
GLboolean success = GL_TRUE;
@@ -1904,22 +1946,14 @@ generate_mipmap_uncompressed(struct gl_context *ctx,
GLenum target,
srcDepth = srcImage->Depth;
border = srcImage->Border;
- nextLevel = _mesa_next_mipmap_level_size(target, border,
- srcWidth, srcHeight, srcDepth,
- &dstWidth, &dstHeight, &dstDepth);
- if (!nextLevel)
- return;
-
- if (!_mesa_prepare_mipmap_level(ctx, texObj, level + 1,
- dstWidth, dstHeight, dstDepth,
- border, srcImage->InternalFormat,
- srcImage->TexFormat)) {
- return;
- }
-
/* get dest gl_texture_image */
dstImage = _mesa_select_tex_image(texObj, target, level + 1);
- assert(dstImage);
+ if (!dstImage) {
+ break;
+ }
+ dstWidth = dstImage->Width;
+ dstHeight = dstImage->Height;
+ dstDepth = dstImage->Depth;
if (target == GL_TEXTURE_1D_ARRAY) {
srcDepth = srcHeight;
@@ -2087,7 +2121,6 @@ generate_mipmap_compressed(struct gl_context *ctx, GLenum
target,
GLint srcWidth, srcHeight, srcDepth;
GLint dstWidth, dstHeight, dstDepth;
GLint border;
- GLboolean nextLevel;
GLuint temp_dst_row_stride, temp_dst_img_stride; /* in bytes */
GLint i;
@@ -2099,23 +2132,14 @@ generate_mipmap_compressed(struct gl_context *ctx,
GLenum target,
srcDepth = srcImage->Depth;
border = srcImage->Border;
- nextLevel = _mesa_next_mipmap_level_size(target, border,
- srcWidth, srcHeight, srcDepth,
- &dstWidth, &dstHeight, &dstDepth);
- if (!nextLevel)
-goto end;
-
- if (!_mesa_prepare_mipmap_level(ctx, texObj, level + 1,
- dstWidth, dstHeight, dstDepth,
- border, srcImage->InternalFormat,
- srcImage->TexFormat)) {
- /* all done */
- goto end;
- }
-
/* get dest gl_texture_image */
dstImage = _mesa_select_tex_image(texObj, target, level + 1);
- assert(dstImage);
+ if (!dstImage) {
+ break;
+ }
+ dstWidt
Re: [Mesa-dev] [PATCH 1/2] mesa: new _mesa_prepare_mipmap_levels() function for mipmap generation
On 03/28/2016 02:23 PM, Brian Paul wrote:
On 03/28/2016 12:39 PM, Ian Romanick wrote:
On 03/26/2016 10:21 AM, Brian Paul wrote:
Simplifies the loops in generate_mipmap_uncompressed() and
generate_mipmap_compressed(). Will be used in the state tracker too.
Could probably be used in the meta code. If so, some additional
clean-ups can be done after that.
I'm in favor of just about anything that can lead to clean ups in meta.
I have a couple comments below.
---
src/mesa/main/mipmap.c | 89
--
src/mesa/main/mipmap.h | 5 +++
2 files changed, 63 insertions(+), 31 deletions(-)
diff --git a/src/mesa/main/mipmap.c b/src/mesa/main/mipmap.c
index 5a02780..02d236d 100644
--- a/src/mesa/main/mipmap.c
+++ b/src/mesa/main/mipmap.c
@@ -1872,6 +1872,50 @@ _mesa_prepare_mipmap_level(struct gl_context
*ctx,
}
+/**
+ * Prepare all mipmap levels beyond 'baseLevel' for mipmap generation.
+ * When finished, all the gl_texture_image structures for the smaller
+ * mipmap levels will be consistent with the base level (in terms of
+ * dimensions, format, etc).
+ */
+void
+_mesa_prepare_mipmap_levels(struct gl_context *ctx,
+struct gl_texture_object *texObj,
+GLuint baseLevel, GLuint maxLevel)
Can these be plain unsigned?
Sure.
+{
+ const struct gl_texture_image *baseImage =
+ _mesa_select_tex_image(texObj, texObj->Target, baseLevel);
+ const GLint border = 0;
+ GLint width = baseImage->Width;
+ GLint height = baseImage->Height;
+ GLint depth = baseImage->Depth;
+ const GLenum intFormat = baseImage->InternalFormat;
+ const mesa_format texFormat = baseImage->TexFormat;
+ GLint newWidth, newHeight, newDepth;
+ GLuint level;
+
+ /* Prepare baseLevel + 1, baseLevel + 2, ... */
+ for (level = baseLevel + 1; level <= maxLevel; level++) {
Now that we can use more C99, I'm in favor of
for (unsigned level = baseLevel + 1; level <= maxLevel; level++) {
OK.
+ if (!_mesa_next_mipmap_level_size(texObj->Target, border,
+width, height, depth,
+&newWidth, &newHeight,
&newDepth)) {
Meta has some special handling for GL_TEXTURE_1D_ARRAY. I think that
needs to be done here too.
I'll take a look...
The special GL_TEXTURE_1D_ARRAY code in meta is orthogonal to what
_mesa_prepare_mipmap_levels() is doing. I've updated the meta code to
use _mesa_prepare_mipmap_levels() and will post a patch. See comments
there.
I also have a v2 of this patch with your above suggestions.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] compiler/glsl: invalidate float suffixes for glsl 1.10
On Monday, March 28, 2016 8:16:17 PM PDT Lars Hamre wrote:
> NOTE: someone with access will need to commit this patch after the
> review process
>
> Invalidates float suffixes for glsl 1.10
>
> Fixes the following piglit tests:
> tests/spec/glsl-1.10/compiler/literals/invalid-float-suffix-capital-f.vert
> tests/spec/glsl-1.10/compiler/literals/invalid-float-suffix-f.vert`
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81585
>
> Signed-off-by: Lars Hamre
> Reviewed-by: Timothy Arceri
>
> ---
> src/compiler/glsl/glsl_lexer.ll | 13 +++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/src/compiler/glsl/glsl_lexer.ll b/src/compiler/glsl/
glsl_lexer.ll
> index 1f12265..0980f4f 100644
> --- a/src/compiler/glsl/glsl_lexer.ll
> +++ b/src/compiler/glsl/glsl_lexer.ll
> @@ -472,8 +472,17 @@ layout {
> \.[0-9]+([eE][+-]?[0-9]+)?[fF]? |
> [0-9]+\.([eE][+-]?[0-9]+)?[fF]? |
> [0-9]+[eE][+-]?[0-9]+[fF]? {
> - yylval->real = _mesa_strtof(yytext, NULL);
> - return FLOATCONSTANT;
> + struct _mesa_glsl_parse_state *state = yyextra;
> + char suffix = yytext[strlen(yytext) - 1];
> + if (!state->is_version(120, 0) &&
> + (suffix == 'f' || suffix == 'F')) {
> + _mesa_glsl_error(yylloc, state,
> + "Float suffixes are invalid in
> GLSL
1.10");
> + return ERROR_TOK;
> + } else {
> + yylval->real = _mesa_strtof(yytext, NULL);
> + return FLOATCONSTANT;
> + }
Hi Lars,
Good catch! Would it also work to do:
if (!state->is_version(120, 0) &&
(suffix == 'f' || suffix == 'F')) {
_mesa_glsl_error(yylloc, state,
"Float suffixes are invalid in GLSL
1.10");
}
yylval->real = _mesa_strtof(yytext, NULL);
return FLOATCONSTANT;
In other words, raise the error and fail the compile, but parse the
float literal as intended. I think returning ERROR_TOK is likely to
make the parser hit bison-generated "Expected , got " errors that are pretty cryptic. Parsing the number in
the obvious manner would let the compile proceed normally, so we don't
get cascading errors that might be confusing.
That patch would get a:
Reviewed-by: Kenneth Graunke
> }
>
> [0-9]+\.[0-9]+([eE][+-]?[0-9]+)?(lf|LF) |
> --
> 2.5.5
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/mesa: enable OES_texture_buffer when all components available
OES_texture_buffer combines bits from a number of desktop extensions. When they're all available, turn it on. Signed-off-by: Ilia Mirkin --- src/mesa/state_tracker/st_extensions.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/src/mesa/state_tracker/st_extensions.c b/src/mesa/state_tracker/st_extensions.c index e26f13d..c0939c0 100644 --- a/src/mesa/state_tracker/st_extensions.c +++ b/src/mesa/state_tracker/st_extensions.c @@ -1033,6 +1033,12 @@ void st_init_extensions(struct pipe_screen *screen, PIPE_BIND_SAMPLER_VIEW); } + extensions->OES_texture_buffer = + extensions->ARB_texture_buffer_object && + extensions->ARB_texture_buffer_range && + extensions->ARB_texture_buffer_object_rgb32 && + extensions->ARB_shader_image_load_store; + /* Unpacking a varying in the fragment shader costs 1 texture indirection. * If the number of available texture indirections is very limited, then we * prefer to disable varying packing rather than run the risk of varying -- 2.7.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/4] mesa: add OES_texture_buffer and EXT_texture_buffer support
On Mon, Mar 28, 2016 at 3:04 PM, Ian Romanick wrote:
>> diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
>> index 9aec425..731b62e 100644
>> --- a/src/mesa/main/bufferobj.c
>> +++ b/src/mesa/main/bufferobj.c
>> @@ -148,8 +148,8 @@ get_buffer_target(struct gl_context *ctx, GLenum target)
>>}
>>break;
>> case GL_TEXTURE_BUFFER:
>> - if (ctx->API == API_OPENGL_CORE &&
>> - ctx->Extensions.ARB_texture_buffer_object) {
>> + if (_mesa_has_ARB_texture_buffer_object(ctx) ||
>> + _mesa_has_OES_texture_buffer(ctx)) {
>
> It looks like every place that uses one of these functions uses the
> other too. Maybe add _mesa_has_texture_buffer?
I think I'm going to skip this one -- we don't really have a lot of
such helpers. We have them for the various stages, presumably because
they're used all over the place, but not for these types of
extensions. I wouldn't oppose a policy change on that, and having more
such helpers, although I wouldn't push for it either :)
Thanks for looking through the series! Perhaps you can have another
pass at the multisample one too? :)
-ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2] compiler/glsl: invalidate float suffixes for glsl 1.10
NOTE: someone with access will need to commit this patch after the
review process
Invalidates float suffixes for glsl 1.10
Fixes the following piglit tests:
tests/spec/glsl-1.10/compiler/literals/invalid-float-suffix-capital-f.vert
tests/spec/glsl-1.10/compiler/literals/invalid-float-suffix-f.vert`
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81585
Signed-off-by: Lars Hamre
Reviewed-by: Timothy Arceri
---
src/compiler/glsl/glsl_lexer.ll | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/src/compiler/glsl/glsl_lexer.ll b/src/compiler/glsl/glsl_lexer.ll
index 1f12265..0980f4f 100644
--- a/src/compiler/glsl/glsl_lexer.ll
+++ b/src/compiler/glsl/glsl_lexer.ll
@@ -472,8 +472,17 @@ layout {
\.[0-9]+([eE][+-]?[0-9]+)?[fF]?|
[0-9]+\.([eE][+-]?[0-9]+)?[fF]?|
[0-9]+[eE][+-]?[0-9]+[fF]? {
- yylval->real = _mesa_strtof(yytext, NULL);
- return FLOATCONSTANT;
+ struct _mesa_glsl_parse_state *state = yyextra;
+ char suffix = yytext[strlen(yytext) - 1];
+ if (!state->is_version(120, 0) &&
+ (suffix == 'f' || suffix == 'F')) {
+ _mesa_glsl_error(yylloc, state,
+"Float suffixes are invalid in
GLSL 1.10");
+ return ERROR_TOK;
+ } else {
+ yylval->real = _mesa_strtof(yytext, NULL);
+ return FLOATCONSTANT;
+ }
}
[0-9]+\.[0-9]+([eE][+-]?[0-9]+)?(lf|LF)|
--
2.5.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] i965/peephole_ffma: Only match a mul+add if none of the ops are exact
---
src/mesa/drivers/dri/i965/brw_nir_opt_peephole_ffma.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_nir_opt_peephole_ffma.c
b/src/mesa/drivers/dri/i965/brw_nir_opt_peephole_ffma.c
index 6e8b1f9..22ff2e3 100644
--- a/src/mesa/drivers/dri/i965/brw_nir_opt_peephole_ffma.c
+++ b/src/mesa/drivers/dri/i965/brw_nir_opt_peephole_ffma.c
@@ -84,6 +84,17 @@ get_mul_for_src(nir_alu_src *src, int num_components,
return NULL;
nir_alu_instr *alu = nir_instr_as_alu(instr);
+
+ /* We want to bail if any of the other ALU operations involved is labled
+* exact. One reason for this is that, while the value that is changing is
+* actually the result of the add and not the multiply, the intention of
+* the user when they specify an exact multiply is that they want *that*
+* value and what they don't care about is the add. Another reason is that
+* SPIR-V explicitly requires this behaviour.
+*/
+ if (alu->exact)
+ return NULL;
+
switch (alu->op) {
case nir_op_imov:
case nir_op_fmov:
--
2.5.0.400.gff86faf
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] nir/search: Don't match inexact expressions with exact subexpressions
In the first pass of implementing exact handling, I made a mistake with
search-and-replace. In particular, we only reallly handled exact/inexact
on the root of the tree. Instead, we need to check every node in the tree
for an exact/inexact match. As an example of this, consider the following
GLSL code
precise float a = b + c;
if (a < 0) {
do_stuff();
}
In that case, only the add will be declared "exact" and an expression that
looks for "b + c < 0" will still match and replace it with "b < -c" which
may yield different results. The solution is to simply bail if any of the
values are exact when matching an inexact expression.
---
src/compiler/nir/nir_search.c | 23 ++-
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/src/compiler/nir/nir_search.c b/src/compiler/nir/nir_search.c
index 6e63063..b915101 100644
--- a/src/compiler/nir/nir_search.c
+++ b/src/compiler/nir/nir_search.c
@@ -28,6 +28,8 @@
#include "nir_search.h"
struct match_state {
+ bool inexact_match;
+ bool has_exact_alu;
unsigned variables_seen;
nir_alu_src variables[NIR_SEARCH_MAX_VARIABLES];
};
@@ -239,7 +241,10 @@ match_expression(const nir_search_expression *expr,
nir_alu_instr *instr,
return false;
assert(instr->dest.dest.is_ssa);
- if (expr->inexact && instr->exact)
+
+ state->inexact_match = expr->inexact || state->inexact_match;
+ state->has_exact_alu = instr->exact || state->has_exact_alu;
+ if (state->inexact_match && state->has_exact_alu)
return false;
assert(!instr->dest.saturate);
@@ -410,7 +415,7 @@ bitsize_tree_filter_down(bitsize_tree *tree, unsigned size)
static nir_alu_src
construct_value(const nir_search_value *value,
-unsigned num_components, bitsize_tree *bitsize, bool exact,
+unsigned num_components, bitsize_tree *bitsize,
struct match_state *state,
nir_instr *instr, void *mem_ctx)
{
@@ -424,10 +429,16 @@ construct_value(const nir_search_value *value,
nir_alu_instr *alu = nir_alu_instr_create(mem_ctx, expr->opcode);
nir_ssa_dest_init(&alu->instr, &alu->dest.dest, num_components,
bitsize->dest_size, NULL);
- alu->exact = exact;
alu->dest.write_mask = (1 << num_components) - 1;
alu->dest.saturate = false;
+ /* We have no way of knowing what values in a given search expression
+ * map to a particular replacement value. Therefore, if the
+ * expression we are replacing has any exact values, the entire
+ * replacement should be exact.
+ */
+ alu->exact = state->has_exact_alu;
+
for (unsigned i = 0; i < nir_op_infos[expr->opcode].num_inputs; i++) {
/* If the source is an explicitly sized source, then we need to reset
* the number of components to match.
@@ -436,7 +447,7 @@ construct_value(const nir_search_value *value,
num_components = nir_op_infos[alu->op].input_sizes[i];
alu->src[i] = construct_value(expr->srcs[i],
- num_components, bitsize->srcs[i], exact,
+ num_components, bitsize->srcs[i],
state, instr, mem_ctx);
}
@@ -546,6 +557,8 @@ nir_replace_instr(nir_alu_instr *instr, const
nir_search_expression *search,
assert(instr->dest.dest.is_ssa);
struct match_state state;
+ state.inexact_match = false;
+ state.has_exact_alu = false;
state.variables_seen = 0;
if (!match_expression(search, instr, instr->dest.dest.ssa.num_components,
@@ -569,7 +582,7 @@ nir_replace_instr(nir_alu_instr *instr, const
nir_search_expression *search,
mov->src[0] = construct_value(replace,
instr->dest.dest.ssa.num_components, tree,
- instr->exact, &state, &instr->instr, mem_ctx);
+ &state, &instr->instr, mem_ctx);
nir_instr_insert_before(&instr->instr, &mov->instr);
nir_ssa_def_rewrite_uses(&instr->dest.dest.ssa,
--
2.5.0.400.gff86faf
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] nir/search: Don't match inexact expressions with exact subexpressions
In the first pass of implementing exact handling, I made a mistake with
search-and-replace. In particular, we only reallly handled exact/inexact
on the root of the tree. Instead, we need to check every node in the tree
for an exact/inexact match. As an example of this, consider the following
GLSL code
precise float a = b + c;
if (a < 0) {
do_stuff();
}
In that case, only the add will be declared "exact" and an expression that
looks for "b + c < 0" will still match and replace it with "b < -c" which
may yield different results. The solution is to simply bail if any of the
values are exact when matching an inexact expression.
---
src/compiler/nir/nir_search.c | 23 ++-
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/src/compiler/nir/nir_search.c b/src/compiler/nir/nir_search.c
index 6e63063..b915101 100644
--- a/src/compiler/nir/nir_search.c
+++ b/src/compiler/nir/nir_search.c
@@ -28,6 +28,8 @@
#include "nir_search.h"
struct match_state {
+ bool inexact_match;
+ bool has_exact_alu;
unsigned variables_seen;
nir_alu_src variables[NIR_SEARCH_MAX_VARIABLES];
};
@@ -239,7 +241,10 @@ match_expression(const nir_search_expression *expr,
nir_alu_instr *instr,
return false;
assert(instr->dest.dest.is_ssa);
- if (expr->inexact && instr->exact)
+
+ state->inexact_match = expr->inexact || state->inexact_match;
+ state->has_exact_alu = instr->exact || state->has_exact_alu;
+ if (state->inexact_match && state->has_exact_alu)
return false;
assert(!instr->dest.saturate);
@@ -410,7 +415,7 @@ bitsize_tree_filter_down(bitsize_tree *tree, unsigned size)
static nir_alu_src
construct_value(const nir_search_value *value,
-unsigned num_components, bitsize_tree *bitsize, bool exact,
+unsigned num_components, bitsize_tree *bitsize,
struct match_state *state,
nir_instr *instr, void *mem_ctx)
{
@@ -424,10 +429,16 @@ construct_value(const nir_search_value *value,
nir_alu_instr *alu = nir_alu_instr_create(mem_ctx, expr->opcode);
nir_ssa_dest_init(&alu->instr, &alu->dest.dest, num_components,
bitsize->dest_size, NULL);
- alu->exact = exact;
alu->dest.write_mask = (1 << num_components) - 1;
alu->dest.saturate = false;
+ /* We have no way of knowing what values in a given search expression
+ * map to a particular replacement value. Therefore, if the
+ * expression we are replacing has any exact values, the entire
+ * replacement should be exact.
+ */
+ alu->exact = state->has_exact_alu;
+
for (unsigned i = 0; i < nir_op_infos[expr->opcode].num_inputs; i++) {
/* If the source is an explicitly sized source, then we need to reset
* the number of components to match.
@@ -436,7 +447,7 @@ construct_value(const nir_search_value *value,
num_components = nir_op_infos[alu->op].input_sizes[i];
alu->src[i] = construct_value(expr->srcs[i],
- num_components, bitsize->srcs[i], exact,
+ num_components, bitsize->srcs[i],
state, instr, mem_ctx);
}
@@ -546,6 +557,8 @@ nir_replace_instr(nir_alu_instr *instr, const
nir_search_expression *search,
assert(instr->dest.dest.is_ssa);
struct match_state state;
+ state.inexact_match = false;
+ state.has_exact_alu = false;
state.variables_seen = 0;
if (!match_expression(search, instr, instr->dest.dest.ssa.num_components,
@@ -569,7 +582,7 @@ nir_replace_instr(nir_alu_instr *instr, const
nir_search_expression *search,
mov->src[0] = construct_value(replace,
instr->dest.dest.ssa.num_components, tree,
- instr->exact, &state, &instr->instr, mem_ctx);
+ &state, &instr->instr, mem_ctx);
nir_instr_insert_before(&instr->instr, &mov->instr);
nir_ssa_def_rewrite_uses(&instr->dest.dest.ssa,
--
2.5.0.400.gff86faf
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] compiler/glsl: invalidate float suffixes for glsl 1.10
On Sat, 2016-03-26 at 10:03 -0400, Lars Hamre wrote:
> Invalidates float suffixes for glsl 1.10
>
> Fixes the following piglit tests:
> tests/spec/glsl-1.10/compiler/literals/invalid-float-suffix-capital-
> f.vert
> tests/spec/glsl-1.10/compiler/literals/invalid-float-suffix-f.vert`
>
> Signed-off-by: Lars Hamre
Please add the follow to the end of the commit message:
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81585
>
> ---
> src/compiler/glsl/glsl_lexer.ll | 13 +++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/src/compiler/glsl/glsl_lexer.ll
> b/src/compiler/glsl/glsl_lexer.ll
> index 1f12265..dc71009 100644
> --- a/src/compiler/glsl/glsl_lexer.ll
> +++ b/src/compiler/glsl/glsl_lexer.ll
> @@ -472,8 +472,17 @@ layout {
> \.[0-9]+([eE][+-]?[0-9]+)?[fF]? |
> [0-9]+\.([eE][+-]?[0-9]+)?[fF]? |
> [0-9]+[eE][+-]?[0-9]+[fF]? {
> - yylval->real = _mesa_strtof(yytext,
> NULL);
> - return FLOATCONSTANT;
> + struct _mesa_glsl_parse_state *state =
> yyextra;
> + char suffix = yytext[strlen(yytext) -
> 1];
> + if (!state->is_version(120, 0) &&
> + (suffix == 'f' || suffix == 'F')) {
> + _mesa_glsl_error(yylloc, state,
> + "Float suffixes are
> invalid");
Maybe change to "Float suffixes are invalid in GLSL 1.10" ?
Otherwise this seems ok.
Reviewed-by: Timothy Arceri
> + return ERROR_TOK;
> + } else {
> + yylval->real = _mesa_strtof(yytext,
> NULL);
> + return FLOATCONSTANT;
> + }
> }
>
> [0-9]+\.[0-9]+([eE][+-]?[0-9]+)?(lf|LF) |
> --
> 2.5.5
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 1/2] glsl: add is_lhs bool on ast_expression
On Mon, 2016-03-28 at 20:50 +0200, Alejandro Piñeiro wrote:
> Useful to know if a expression is the recipient of an assignment
> or not, that would be used to (for example) raise warnings of
> "use of uninitialized variable" without getting a false positive
> when assigning first a variable.
>
> By default the value is false, and it is assigned to true on
> the following cases:
> * The lhs assignments subexpression
> * At ast_array_index, on the array itself.
> * While handling the method on an array, to avoid the warning
> calling array.length
> * When computed the cached test expression at test_to_hir, to
> avoid a duplicate warning on the test expression of a switch.
>
> set_is_lhs setter is added, because in some cases (like
> ast_field_selection)
> the value need to be propagated on the expression tree. To avoid
> doing the
> propatagion if not needed, it skips if no
> primary_expression.identifier is
> available.
>
> v2: use a new bool on ast_expression, instead of a new parameter
> on ast_expression::hir (Timothy Arceri)
>
> v3: fix style and some typos on comments, initialize is_lhs default
> value
> on constructor, to avoid a c++11 feature (Ian Romanick)
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94129
Its hard to know if this will work correctly in all scenarios but I
don't see much point in holding it back any longer. It looks pretty
good to me at this point lets see if anyone spots any issues with it in
action.
With the couple of minor comments below addressed both patches are:
Reviewed-by: Timothy Arceri
> ---
> src/compiler/glsl/ast.h | 6 ++
> src/compiler/glsl/ast_function.cpp | 4
> src/compiler/glsl/ast_to_hir.cpp | 33
>
> src/compiler/glsl/glsl_parser_extras.cpp | 1 +
> 4 files changed, 44 insertions(+)
>
> diff --git a/src/compiler/glsl/ast.h b/src/compiler/glsl/ast.h
> index 727aa43..9f46340 100644
> --- a/src/compiler/glsl/ast.h
> +++ b/src/compiler/glsl/ast.h
> @@ -214,6 +214,7 @@ public:
> subexpressions[2] = NULL;
> primary_expression.identifier = identifier;
> this->non_lvalue_description = NULL;
> + this->is_lhs = false;
> }
>
> static const char *operator_string(enum ast_operators op);
> @@ -263,6 +264,11 @@ public:
> * This pointer may be \c NULL.
> */
> const char *non_lvalue_description;
> +
> + void set_is_lhs(bool new_value);
> +
> +private:
> + bool is_lhs;
> };
>
> class ast_expression_bin : public ast_expression {
> diff --git a/src/compiler/glsl/ast_function.cpp
> b/src/compiler/glsl/ast_function.cpp
> index 1a44020..db68d5d 100644
> --- a/src/compiler/glsl/ast_function.cpp
> +++ b/src/compiler/glsl/ast_function.cpp
> @@ -1727,6 +1727,10 @@
> ast_function_expression::handle_method(exec_list *instructions,
> const char *method;
> method = field->primary_expression.identifier;
>
> + /* This would prevent to raise "uninitialized variable" warnings
> when
> +* calling array.length.
> +*/
> + field->subexpressions[0]->set_is_lhs(true);
> op = field->subexpressions[0]->hir(instructions, state);
> if (strcmp(method, "length") == 0) {
> if (!this->expressions.is_empty()) {
> diff --git a/src/compiler/glsl/ast_to_hir.cpp
> b/src/compiler/glsl/ast_to_hir.cpp
> index 35def8e..eb45f29 100644
> --- a/src/compiler/glsl/ast_to_hir.cpp
> +++ b/src/compiler/glsl/ast_to_hir.cpp
> @@ -1248,6 +1248,24 @@ ast_expression::hir_no_rvalue(exec_list
> *instructions,
> do_hir(instructions, state, false);
> }
>
> +void
> +ast_expression::set_is_lhs(bool new_value)
> +{
> + /* is_lhs is tracked only to print "variable used uninitialized"
> warnings,
> +* if we lack a identifier we can just skip, so also skipping
> going through
> +* subexpressions (see below)
> +*/
I find the text "so also skipping going through subexpressions (see
below)" a little confusing I don't think it adds much value so I'd
suggest just removing it and replacing it with "it." i.e "we can just
skip it."
> + if (this->primary_expression.identifier == NULL)
> + return;
> +
> + this->is_lhs = new_value;
> +
> + /* We need to go through the subexpressions tree to cover cases
> like
> +* ast_field_selection */
^-- Put this on the next line
> + if (this->subexpressions[0] != NULL)
> + this->subexpressions[0]->set_is_lhs(new_value);
> +}
> +
> ir_rvalue *
> ast_expression::do_hir(exec_list *instructions,
> struct _mesa_glsl_parse_state *state,
> @@ -1323,6 +1341,7 @@ ast_expression::do_hir(exec_list *instructions,
> break;
>
> case ast_assign: {
> + this->subexpressions[0]->set_is_lhs(true);
> op[0] = this->subexpressions[0]->hir(instructions, state);
> op[1] = this->subexpressions[1]->hir(instructions, state);
>
> @@ -1592,6 +1611,7 @@ ast_expression::do_hir(exec_list *instructions,
Re: [Mesa-dev] [PATCH] i965: Set address rounding bits for GL_NEAREST filtering as well.
On Thursday, March 17, 2016 4:42:08 PM PDT Jordan Justen wrote:
> On 2016-03-17 01:04:27, Kenneth Graunke wrote:
> > Yuanhan Liu decided these were useful for linear filtering in
> > commit 76669381 (circa 2011). Prior to that, we never set them;
> > it seems he tried to preserve that behavior for nearest filtering.
> >
> > It turns out they're useful for nearest filtering, too: setting
> > these fixes the following dEQP-GLES3 tests:
> >
> > functional.fbo.blit.rect.nearest_consistency_mag
> > functional.fbo.blit.rect.nearest_consistency_mag_reverse_src_x
> > functional.fbo.blit.rect.nearest_consistency_mag_reverse_src_y
> > functional.fbo.blit.rect.nearest_consistency_mag_reverse_dst_x
> > functional.fbo.blit.rect.nearest_consistency_mag_reverse_dst_y
> > functional.fbo.blit.rect.nearest_consistency_mag_reverse_src_dst_x
> > functional.fbo.blit.rect.nearest_consistency_mag_reverse_src_dst_y
> > functional.fbo.blit.rect.nearest_consistency_min
> > functional.fbo.blit.rect.nearest_consistency_min_reverse_src_x
> > functional.fbo.blit.rect.nearest_consistency_min_reverse_src_y
> > functional.fbo.blit.rect.nearest_consistency_min_reverse_dst_x
> > functional.fbo.blit.rect.nearest_consistency_min_reverse_dst_y
> > functional.fbo.blit.rect.nearest_consistency_min_reverse_src_dst_x
> > functional.fbo.blit.rect.nearest_consistency_min_reverse_src_dst_y
> > functional.fbo.blit.rect.nearest_consistency_out_of_bounds_mag
> >
functional.fbo.blit.rect.nearest_consistency_out_of_bounds_mag_reverse_src_x
> >
functional.fbo.blit.rect.nearest_consistency_out_of_bounds_mag_reverse_src_y
> >
functional.fbo.blit.rect.nearest_consistency_out_of_bounds_mag_reverse_dst_x
> >
functional.fbo.blit.rect.nearest_consistency_out_of_bounds_mag_reverse_dst_y
> >
functional.fbo.blit.rect.nearest_consistency_out_of_bounds_mag_reverse_src_dst_x
> >
functional.fbo.blit.rect.nearest_consistency_out_of_bounds_mag_reverse_src_dst_y
> > functional.fbo.blit.rect.nearest_consistency_out_of_bounds_min
> >
functional.fbo.blit.rect.nearest_consistency_out_of_bounds_min_reverse_src_x
> >
functional.fbo.blit.rect.nearest_consistency_out_of_bounds_min_reverse_src_y
> >
functional.fbo.blit.rect.nearest_consistency_out_of_bounds_min_reverse_dst_x
> >
functional.fbo.blit.rect.nearest_consistency_out_of_bounds_min_reverse_dst_y
> >
functional.fbo.blit.rect.nearest_consistency_out_of_bounds_min_reverse_src_dst_x
> >
functional.fbo.blit.rect.nearest_consistency_out_of_bounds_min_reverse_src_dst_y
> >
> > Apparently, BLORP has always set these bits unconditionally.
> >
> > However, setting them unconditionally appears to regress tests using
> > texture projection, 3D samplers, integer formats, and vertex shaders,
> > all in combination, such as:
> >
> > functional.shaders.texture_functions.textureprojlod.isampler3d_vertex
> >
> > Setting them on Gen4-5 appears to regress Piglit's
> > tests/spec/arb_sampler_objects/framebufferblit.
> >
> > Honestly, it looks like the real problem here is a lack of precision.
> > I'm just hacking around problems here (as embarassing as it is).
> >
> > Signed-off-by: Kenneth Graunke
> > ---
> > src/mesa/drivers/dri/i965/brw_sampler_state.c | 9 ++---
> > 1 file changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/src/mesa/drivers/dri/i965/brw_sampler_state.c b/src/mesa/
drivers/dri/i965/brw_sampler_state.c
> > index c20a028..d53cb5d 100644
> > --- a/src/mesa/drivers/dri/i965/brw_sampler_state.c
> > +++ b/src/mesa/drivers/dri/i965/brw_sampler_state.c
> > @@ -436,14 +436,17 @@ brw_update_sampler_state(struct brw_context *brw,
> >}
> > }
> >
> > - /* Set address rounding bits if not using nearest filtering. */
> > + /* Set address rounding bits. The conditions are empirically
> > +* derived in order to pass test cases.
> > +*/
> > + bool round_nearest = brw->gen >= 6 && target != GL_TEXTURE_3D;
> > unsigned address_rounding = 0;
> > - if (min_filter != BRW_MAPFILTER_NEAREST) {
> > + if (min_filter != BRW_MAPFILTER_NEAREST || round_nearest) {
>
> How about folding the min_filter != BRW_MAPFILTER_NEAREST test into
> round_nearest?
>
> Reviewed-by: Jordan Justen
Can't do that - the != NEAREST checks use "min" then "mag".
> >address_rounding |= BRW_ADDRESS_ROUNDING_ENABLE_U_MIN |
> >BRW_ADDRESS_ROUNDING_ENABLE_V_MIN |
> >BRW_ADDRESS_ROUNDING_ENABLE_R_MIN;
> > }
> > - if (mag_filter != BRW_MAPFILTER_NEAREST) {
> > + if (mag_filter != BRW_MAPFILTER_NEAREST || round_nearest) {
> >address_rounding |= BRW_ADDRESS_ROUNDING_ENABLE_U_MAG |
> >BRW_ADDRESS_ROUNDING_ENABLE_V_MAG |
> >BRW_ADDRESS_ROUNDING_ENABLE_R_MAG;
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
signature.asc
Description: This is a digitally si
Re: [Mesa-dev] [PATCH 1/2] mesa: new _mesa_prepare_mipmap_levels() function for mipmap generation
On 03/28/2016 12:39 PM, Ian Romanick wrote:
On 03/26/2016 10:21 AM, Brian Paul wrote:
Simplifies the loops in generate_mipmap_uncompressed() and
generate_mipmap_compressed(). Will be used in the state tracker too.
Could probably be used in the meta code. If so, some additional
clean-ups can be done after that.
I'm in favor of just about anything that can lead to clean ups in meta.
I have a couple comments below.
---
src/mesa/main/mipmap.c | 89 --
src/mesa/main/mipmap.h | 5 +++
2 files changed, 63 insertions(+), 31 deletions(-)
diff --git a/src/mesa/main/mipmap.c b/src/mesa/main/mipmap.c
index 5a02780..02d236d 100644
--- a/src/mesa/main/mipmap.c
+++ b/src/mesa/main/mipmap.c
@@ -1872,6 +1872,50 @@ _mesa_prepare_mipmap_level(struct gl_context *ctx,
}
+/**
+ * Prepare all mipmap levels beyond 'baseLevel' for mipmap generation.
+ * When finished, all the gl_texture_image structures for the smaller
+ * mipmap levels will be consistent with the base level (in terms of
+ * dimensions, format, etc).
+ */
+void
+_mesa_prepare_mipmap_levels(struct gl_context *ctx,
+struct gl_texture_object *texObj,
+GLuint baseLevel, GLuint maxLevel)
Can these be plain unsigned?
Sure.
+{
+ const struct gl_texture_image *baseImage =
+ _mesa_select_tex_image(texObj, texObj->Target, baseLevel);
+ const GLint border = 0;
+ GLint width = baseImage->Width;
+ GLint height = baseImage->Height;
+ GLint depth = baseImage->Depth;
+ const GLenum intFormat = baseImage->InternalFormat;
+ const mesa_format texFormat = baseImage->TexFormat;
+ GLint newWidth, newHeight, newDepth;
+ GLuint level;
+
+ /* Prepare baseLevel + 1, baseLevel + 2, ... */
+ for (level = baseLevel + 1; level <= maxLevel; level++) {
Now that we can use more C99, I'm in favor of
for (unsigned level = baseLevel + 1; level <= maxLevel; level++) {
OK.
+ if (!_mesa_next_mipmap_level_size(texObj->Target, border,
+width, height, depth,
+&newWidth, &newHeight, &newDepth)) {
Meta has some special handling for GL_TEXTURE_1D_ARRAY. I think that
needs to be done here too.
I'll take a look...
Thanks.
-Brian
+ /* all done */
+ break;
+ }
+
+ if (!_mesa_prepare_mipmap_level(ctx, texObj, level,
+ newWidth, newHeight, newDepth,
+ border, intFormat, texFormat)) {
+ break;
+ }
+
+ width = newWidth;
+ height = newHeight;
+ depth = newDepth;
+ }
+}
+
+
static void
generate_mipmap_uncompressed(struct gl_context *ctx, GLenum target,
struct gl_texture_object *texObj,
@@ -1892,7 +1936,6 @@ generate_mipmap_uncompressed(struct gl_context *ctx,
GLenum target,
GLint dstWidth, dstHeight, dstDepth;
GLint border;
GLint slice;
- GLboolean nextLevel;
GLubyte **srcMaps, **dstMaps;
GLboolean success = GL_TRUE;
@@ -1904,22 +1947,14 @@ generate_mipmap_uncompressed(struct gl_context *ctx,
GLenum target,
srcDepth = srcImage->Depth;
border = srcImage->Border;
- nextLevel = _mesa_next_mipmap_level_size(target, border,
- srcWidth, srcHeight, srcDepth,
- &dstWidth, &dstHeight, &dstDepth);
- if (!nextLevel)
- return;
-
- if (!_mesa_prepare_mipmap_level(ctx, texObj, level + 1,
- dstWidth, dstHeight, dstDepth,
- border, srcImage->InternalFormat,
- srcImage->TexFormat)) {
- return;
- }
-
/* get dest gl_texture_image */
dstImage = _mesa_select_tex_image(texObj, target, level + 1);
- assert(dstImage);
+ if (!dstImage) {
+ break;
+ }
+ dstWidth = dstImage->Width;
+ dstHeight = dstImage->Height;
+ dstDepth = dstImage->Depth;
if (target == GL_TEXTURE_1D_ARRAY) {
srcDepth = srcHeight;
@@ -2087,7 +2122,6 @@ generate_mipmap_compressed(struct gl_context *ctx, GLenum
target,
GLint srcWidth, srcHeight, srcDepth;
GLint dstWidth, dstHeight, dstDepth;
GLint border;
- GLboolean nextLevel;
GLuint temp_dst_row_stride, temp_dst_img_stride; /* in bytes */
GLint i;
@@ -2099,23 +2133,14 @@ generate_mipmap_compressed(struct gl_context *ctx,
GLenum target,
srcDepth = srcImage->Depth;
border = srcImage->Border;
- nextLevel = _mesa_next_mipmap_level_size(target, border,
- srcWidth, srcHeight, srcDepth,
- &dstWidth, &dstHeight, &dstDepth);
- if (!nextLevel)
-goto end;
-
- if (!_mesa_prepare_mipmap_level(ct
Re: [Mesa-dev] [PATCH 3/4] glsl: add OES_texture_buffer and EXT_texture_buffer support
This patch is
Reviewed-by: Ian Romanick
On 02/27/2016 01:30 PM, Ilia Mirkin wrote:
> Expose the samplerBuffer/imageBuffer types, and allow the various
> functions to operate on them.
>
> Signed-off-by: Ilia Mirkin
> ---
> src/compiler/glsl/builtin_functions.cpp | 20 ++--
> src/compiler/glsl/builtin_types.cpp | 22 --
> src/compiler/glsl/glcpp/glcpp-parse.y| 4
> src/compiler/glsl/glsl_lexer.ll | 12 ++--
> src/compiler/glsl/glsl_parser_extras.cpp | 2 ++
> src/compiler/glsl/glsl_parser_extras.h | 4
> 6 files changed, 46 insertions(+), 18 deletions(-)
>
> diff --git a/src/compiler/glsl/builtin_functions.cpp
> b/src/compiler/glsl/builtin_functions.cpp
> index fb3a666..b4a3e32 100644
> --- a/src/compiler/glsl/builtin_functions.cpp
> +++ b/src/compiler/glsl/builtin_functions.cpp
> @@ -184,6 +184,14 @@ v110_lod(const _mesa_glsl_parse_state *state)
> }
>
> static bool
> +texture_buffer(const _mesa_glsl_parse_state *state)
> +{
> + return state->is_version(140, 320) ||
> + state->EXT_texture_buffer_enable ||
> + state->OES_texture_buffer_enable;
> +}
> +
> +static bool
> shader_texture_lod(const _mesa_glsl_parse_state *state)
> {
> return state->ARB_shader_texture_lod_enable;
> @@ -1585,9 +1593,9 @@ builtin_builder::create_builtins()
> _textureSize(v130, glsl_type::ivec2_type,
> glsl_type::usampler2DRect_type),
> _textureSize(v130, glsl_type::ivec2_type,
> glsl_type::sampler2DRectShadow_type),
>
> -_textureSize(v140, glsl_type::int_type,
> glsl_type::samplerBuffer_type),
> -_textureSize(v140, glsl_type::int_type,
> glsl_type::isamplerBuffer_type),
> -_textureSize(v140, glsl_type::int_type,
> glsl_type::usamplerBuffer_type),
> +_textureSize(texture_buffer, glsl_type::int_type,
> glsl_type::samplerBuffer_type),
> +_textureSize(texture_buffer, glsl_type::int_type,
> glsl_type::isamplerBuffer_type),
> +_textureSize(texture_buffer, glsl_type::int_type,
> glsl_type::usamplerBuffer_type),
> _textureSize(texture_multisample, glsl_type::ivec2_type,
> glsl_type::sampler2DMS_type),
> _textureSize(texture_multisample, glsl_type::ivec2_type,
> glsl_type::isampler2DMS_type),
> _textureSize(texture_multisample, glsl_type::ivec2_type,
> glsl_type::usampler2DMS_type),
> @@ -1859,9 +1867,9 @@ builtin_builder::create_builtins()
> _texelFetch(v130, glsl_type::ivec4_type,
> glsl_type::isampler2DArray_type, glsl_type::ivec3_type),
> _texelFetch(v130, glsl_type::uvec4_type,
> glsl_type::usampler2DArray_type, glsl_type::ivec3_type),
>
> -_texelFetch(v140, glsl_type::vec4_type,
> glsl_type::samplerBuffer_type, glsl_type::int_type),
> -_texelFetch(v140, glsl_type::ivec4_type,
> glsl_type::isamplerBuffer_type, glsl_type::int_type),
> -_texelFetch(v140, glsl_type::uvec4_type,
> glsl_type::usamplerBuffer_type, glsl_type::int_type),
> +_texelFetch(texture_buffer, glsl_type::vec4_type,
> glsl_type::samplerBuffer_type, glsl_type::int_type),
> +_texelFetch(texture_buffer, glsl_type::ivec4_type,
> glsl_type::isamplerBuffer_type, glsl_type::int_type),
> +_texelFetch(texture_buffer, glsl_type::uvec4_type,
> glsl_type::usamplerBuffer_type, glsl_type::int_type),
>
> _texelFetch(texture_multisample, glsl_type::vec4_type,
> glsl_type::sampler2DMS_type, glsl_type::ivec2_type),
> _texelFetch(texture_multisample, glsl_type::ivec4_type,
> glsl_type::isampler2DMS_type, glsl_type::ivec2_type),
> diff --git a/src/compiler/glsl/builtin_types.cpp
> b/src/compiler/glsl/builtin_types.cpp
> index ee24bd5..d250234 100644
> --- a/src/compiler/glsl/builtin_types.cpp
> +++ b/src/compiler/glsl/builtin_types.cpp
> @@ -179,7 +179,7 @@ static const struct builtin_type_versions {
> T(sampler2DArray, 130, 300)
> T(samplerCubeArray,400, 999)
> T(sampler2DRect, 140, 999)
> - T(samplerBuffer, 140, 999)
> + T(samplerBuffer, 140, 320)
> T(sampler2DMS, 150, 310)
> T(sampler2DMSArray,150, 999)
>
> @@ -191,7 +191,7 @@ static const struct builtin_type_versions {
> T(isampler2DArray, 130, 300)
> T(isamplerCubeArray, 400, 999)
> T(isampler2DRect, 140, 999)
> - T(isamplerBuffer, 140, 999)
> + T(isamplerBuffer, 140, 320)
> T(isampler2DMS,150, 310)
> T(isampler2DMSArray, 150, 999)
>
> @@ -203,7 +203,7 @@ static const struct builtin_type_versions {
> T(usampler2DArray, 130, 300)
> T(usampl
[Mesa-dev] [Bug 94731] New account request
https://bugs.freedesktop.org/show_bug.cgi?id=94731 Alex Deucher changed: What|Removed |Added Product|Mesa|freedesktop.org Assignee|mesa-dev@lists.freedesktop. |sitewranglers@lists.freedes |org |ktop.org Component|Other |New Accounts QA Contact|mesa-dev@lists.freedesktop. | |org | -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 94731] New account request
https://bugs.freedesktop.org/show_bug.cgi?id=94731 --- Comment #2 from Alex Deucher --- I approve giving Bas access to mesa. He has produced a lot of great patches for mesa. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] nir: Use double-precision pow() when bit_size is 64, powf() otherwise
On Mon, Mar 28, 2016 at 11:31 AM, Ian Romanick wrote:
> On 03/23/2016 08:09 PM, Jason Ekstrand wrote:
> > Is there a 64-bit pow in GLSL? If so, this is the right implementation.
>
> There isn't. But there also aren't double versions of sin or cos, and
> 9076c4e2 added those. However, it didn't add double versions of fexp2
> or flog2 (both of which are not supported in GLSL).
>
> Ugh... it also did not add double versions of frsq or fsqrt... which are
> supported in GLSL.
>
> So, there are some extra functions and some missing functions. My gut
> tells me we should just do all of them so that people don't have to
> think about which ones should / shouldn't be implemented.
>
That seems reasonable. Either that or flag those opcodes as only
supporting 32-bit types for now. I think I'd rather just implement them if
it's not too much work. You know someone's going to write a an fp64_pow
extension some day...
> Looking more closely... I think fabs, fnot, fsign, and fsat should have
> explicit double support as well... it seems the existing implementations
> of both of these will cause some small values to be incorrectly
> "flushed" to zero. What are the rules in C when you compare a double
> variable with a single constant?
>
> void foo(double d)
> {
> /* Does d get converted to single, or does 0.0f get converted to
> * double?
> */
> if (d == 0.0f)
> printf("zero\n");
> }
>
> > Reviewed-by: Jason Ekstrand > >
> >
> > On Mar 23, 2016 7:42 PM, "Ian Romanick" > > wrote:
> >
> > From: Ian Romanick > >
> >
> > Found (randomly) by inspection. Looking at the rest of the changes
> in
> > this file in commit 9076c4e2, I'm certain this is what was intended.
> >
> > Signed-off-by: Ian Romanick > >
> > Cc: Connor Abbott mailto:cwabbo...@gmail.com>>
> > Cc: mesa-sta...@lists.freedesktop.org
> >
> > ---
> > src/compiler/nir/nir_opcodes.py | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/src/compiler/nir/nir_opcodes.py
> > b/src/compiler/nir/nir_opcodes.py
> > index 553f924..ac59130 100644
> > --- a/src/compiler/nir/nir_opcodes.py
> > +++ b/src/compiler/nir/nir_opcodes.py
> > @@ -520,7 +520,7 @@ for (int i = 0; i < 32; i += 8) {
> > }
> > """)
> >
> > -binop("fpow", tfloat, "", "bit_size == 64 ? powf(src0, src1) :
> > pow(src0, src1)")
> > +binop("fpow", tfloat, "", "bit_size == 64 ? pow(src0, src1) :
> > powf(src0, src1)")
> >
> > binop_horiz("pack_half_2x16_split", 1, tuint32, 1, tfloat32, 1,
> > tfloat32,
> > "pack_half_1x16(src0.x) | (pack_half_1x16(src1.x) <<
> 16)")
> > --
> > 2.5.5
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org mesa-dev@lists.freedesktop.org>
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/4] mesa: add OES_texture_buffer and EXT_texture_buffer support
On Mon, Mar 28, 2016 at 3:07 PM, Ian Romanick wrote:
> On 02/27/2016 01:39 PM, Ilia Mirkin wrote:
>> On Sat, Feb 27, 2016 at 4:30 PM, Ilia Mirkin wrote:
>>> Allow ES 3.1 contexts to access the texture buffer functionality.
>>>
>>> Signed-off-by: Ilia Mirkin
>>> ---
>>> docs/GL3.txt| 2 +-
>>> src/mapi/glapi/gen/apiexec.py | 4 ++--
>>> src/mapi/glapi/gen/es_EXT.xml | 36 ++
>>> src/mesa/main/bufferobj.c | 4 ++--
>>> src/mesa/main/get.c | 4 ++--
>>> src/mesa/main/get_hash_params.py| 20 -
>>> src/mesa/main/tests/dispatch_sanity.cpp | 4
>>> src/mesa/main/teximage.c| 20 +++--
>>> src/mesa/main/texobj.c | 8 +++
>>> src/mesa/main/texparam.c| 39
>>> +
>>> 10 files changed, 94 insertions(+), 47 deletions(-)
>>>
>>> diff --git a/docs/GL3.txt b/docs/GL3.txt
>>> index b9d9713..2f81cba 100644
>>> --- a/docs/GL3.txt
>>> +++ b/docs/GL3.txt
>>> @@ -254,7 +254,7 @@ GLES3.2, GLSL ES 3.2
>>>GL_OES_shader_multisample_interpolation DONE (nvc0, r600,
>>> radeonsi)
>>>GL_OES_tessellation_shader not started (based
>>> on GL_ARB_tessellation_shader, which is done for some drivers)
>>>GL_OES_texture_border_clamp DONE (all drivers)
>>> - GL_OES_texture_buffernot started (based
>>> on GL_ARB_texture_buffer_object, GL_ARB_texture_buffer_range, and
>>> GL_ARB_texture_buffer_object_rgb32 that are all done)
>>> + GL_OES_texture_bufferDONE ()
>>>GL_OES_texture_cube_map_arraynot started (based
>>> on GL_ARB_texture_cube_map_array, which is done for all drivers)
>>>GL_OES_texture_stencil8 DONE (all drivers
>>> that support GL_ARB_texture_stencil8)
>>>GL_OES_texture_storage_multisample_2d_array DONE (all drivers
>>> that support GL_ARB_texture_multisample)
>>> diff --git a/src/mapi/glapi/gen/apiexec.py b/src/mapi/glapi/gen/apiexec.py
>>> index 2a80432..b4f4cf6 100644
>>> --- a/src/mapi/glapi/gen/apiexec.py
>>> +++ b/src/mapi/glapi/gen/apiexec.py
>>> @@ -68,7 +68,7 @@ class exec_info():
>>> functions = {
>>> # OpenGL 3.1 / GL_ARB_texture_buffer_object. Mesa only exposes this
>>> # extension with core profile.
>>> -"TexBuffer": exec_info(core=31),
>>> +"TexBuffer": exec_info(core=31, es2=31),
>>>
>>> # OpenGL 3.2 / GL_OES_geometry_shader.
>>> "FramebufferTexture": exec_info(core=32, es2=31),
>>> @@ -146,7 +146,7 @@ functions = {
>>>
>>> # OpenGL 4.3 / GL_ARB_texture_buffer_range. Mesa can expose the
>>> extension
>>> # with OpenGL 3.1.
>>> -"TexBufferRange": exec_info(core=31),
>>> +"TexBufferRange": exec_info(core=31, es2=31),
>>>
>>> # OpenGL 4.3 / GL_ARB_framebuffer_no_attachments. Mesa can expose the
>>> # extension with OpenGL 3.0.
>>> diff --git a/src/mapi/glapi/gen/es_EXT.xml b/src/mapi/glapi/gen/es_EXT.xml
>>> index 2b83a97..ee8e9e5 100644
>>> --- a/src/mapi/glapi/gen/es_EXT.xml
>>> +++ b/src/mapi/glapi/gen/es_EXT.xml
>>> @@ -853,6 +853,24 @@
>>>
>>>
>>>
>>> +
>>> +
>>> +
>>> +
>>> +
>>> +
>>> +
>>> +
>>> +
>>> +
>>> +
>>> +
>>> +
>>> +
>>> +
>>> +
>>> +
>>> +
>>>
>>>
>>> >> alias="DrawElementsBaseVertex"
>>> @@ -919,6 +937,24 @@
>>>
>>>
>>>
>>> +
>>> +
>>> +
>>> +
>>> +
>>> +
>>> +
>>> +
>>> +
>>> +
>>> +
>>> +
>>> +
>>> +
>>> +
>>> +
>>> +
>>> +
>>>
>>>
>>> >> alias="DrawElementsBaseVertex"
>>> diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
>>> index 9aec425..731b62e 100644
>>> --- a/src/mesa/main/bufferobj.c
>>> +++ b/src/mesa/main/bufferobj.c
>>> @@ -148,8 +148,8 @@ get_buffer_target(struct gl_context *ctx, GLenum target)
>>>}
>>>break;
>>> case GL_TEXTURE_BUFFER:
>>> - if (ctx->API == API_OPENGL_CORE &&
>>> - ctx->Extensions.ARB_texture_buffer_object) {
>>> + if (_mesa_has_ARB_texture_buffer_object(ctx) ||
>>> + _mesa_has_OES_texture_buffer(ctx)) {
>>> return &ctx->Texture.BufferObject;
>>>}
>>>break;
>>> diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
>>> index 1cbd692..6e04083 100644
>>> --- a/src/mesa/main/get.c
>>> +++ b/src/mesa/main/get.c
>>> @@ -1903,8 +1903,8 @@ tex_binding_to_index(const struct gl_context *ctx,
>>> GLenum binding)
>>> || _mesa_is_gles3(ctx)
>>> ? TEXTURE_2D_ARRAY_INDEX : -1;
>>> case GL_TEXTURE_BINDING_BUFFER:
>>> - return ctx->API == API_OPENGL_CORE &&
>>> - ctx->Extensions.ARB_texture_buffer_object ?
>>> + return (_mesa_has_ARB_texture_buffer_object(ctx)
[Mesa-dev] [Bug 91556] [Clover / OpenCL] struct and union arguments handled incorrectly, producing CL_INVALID_ARG_SIZE
https://bugs.freedesktop.org/show_bug.cgi?id=91556 --- Comment #13 from Vedran MiletiÄ --- (In reply to Pavan Yalamanchili from comment #12) > Is this patch going through into a future release? Structs are not handled correctly even with the patch applied. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gallium: enable intel jitevents profiling
LLVM when configured with "intel jitevents" enabled can inform
VTune about dynamic code, so individual shaders are attributed
profiling data and the resulting assembly can be examined.
---
src/gallium/auxiliary/gallivm/lp_bld_misc.cpp | 9 +
1 file changed, 9 insertions(+)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
index 30ef37c..f9bb92d 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
+++ b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
@@ -81,6 +81,11 @@
#include
#include
+#include
+#if LLVM_USE_INTEL_JITEVENTS
+#include
+#endif
+
// Workaround http://llvm.org/PR23628
#if HAVE_LLVM >= 0x0307
# pragma pop_macro("DEBUG")
@@ -625,6 +630,10 @@
lp_build_create_jit_compiler_for_module(LLVMExecutionEngineRef *OutJIT,
ExecutionEngine *JIT;
JIT = builder.create();
+#if LLVM_USE_INTEL_JITEVENTS
+ JITEventListener *JEL = JITEventListener::createIntelJITEventListener();
+ JIT->RegisterJITEventListener(JEL);
+#endif
if (JIT) {
*OutJIT = wrap(JIT);
return 0;
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa/st: Avoid a NULL-ptr dereference on possible missing callback
On 03/28/2016 04:06 AM, eocallag...@alterapraxis.com wrote: > Determinism is always better regardless of how you get there. A > null pointer deference `on purpose` is a really poor idea in C. > I am somewhat surprised you are asking if its really better to > rely on undefined behavior vs. an assert. I think the more important question is how this could get hit. Asserts do not exist in release builds. If the only way the assert could get hit is by a developer enabling an extension that they didn't actually implement, it's hard to get very excited about it. > I thought about using a if branch and just returning but I think > it is better to crash deterministically with a reason rather than > perhaps fail silently. Although I do see in other places a if branch > and a return was used in similar situations so I would be willing to > do the same if I must. That's only done in cases where it is valid for the driver to not provide a callback. > On 2016-03-28 16:08, Ilia Mirkin wrote: >> When would that happen? When a user force-enables >> ARB_query_buffer_object for a driver that's not ready for it? Is >> hitting a deterministic assert in that case any better than hitting a >> null deref? >> >> On Sun, Mar 27, 2016 at 11:52 PM, Edward O'Callaghan >> wrote: >>> Just because we miss a gallium driver callback don't dereference >>> invalid memory. >>> >>> Signed-off-by: Edward O'Callaghan >>> --- >>> src/mesa/state_tracker/st_cb_queryobj.c | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/src/mesa/state_tracker/st_cb_queryobj.c >>> b/src/mesa/state_tracker/st_cb_queryobj.c >>> index cdb9efc..e9abc38 100644 >>> --- a/src/mesa/state_tracker/st_cb_queryobj.c >>> +++ b/src/mesa/state_tracker/st_cb_queryobj.c >>> @@ -402,6 +402,7 @@ st_StoreQueryResult(struct gl_context *ctx, >>> struct gl_query_object *q, >>>index = 0; >>> } >>> >>> + assert(pipe->get_query_result_resource); >>> pipe->get_query_result_resource(pipe, stq->pq, wait, result_type, >>> index, >>> stObj->buffer, offset); >>> } >>> -- >>> 2.5.5 >>> >>> ___ >>> mesa-dev mailing list >>> mesa-dev@lists.freedesktop.org >>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 94731] New account request
https://bugs.freedesktop.org/show_bug.cgi?id=94731 --- Comment #1 from Bas Nieuwenhuizen --- Created attachment 122597 --> https://bugs.freedesktop.org/attachment.cgi?id=122597&action=edit SSH key -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 94731] New account request
https://bugs.freedesktop.org/show_bug.cgi?id=94731 Bug ID: 94731 Summary: New account request Product: Mesa Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Other Assignee: mesa-dev@lists.freedesktop.org Reporter: b...@basnieuwenhuizen.nl QA Contact: mesa-dev@lists.freedesktop.org Created attachment 122596 --> https://bugs.freedesktop.org/attachment.cgi?id=122596&action=edit GPG key I would like to request an account with commit access to Mesa. Real name: Bas Nieuwenhuizen Address: b...@basnieuwenhuizen.nl Preferred username: bnieuwenhuizen I could not connect to subkeys.pgp.net, but my key should be visible from pgp.mit.edu. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/4] mesa: add OES_texture_buffer and EXT_texture_buffer support
On 02/27/2016 01:39 PM, Ilia Mirkin wrote:
> On Sat, Feb 27, 2016 at 4:30 PM, Ilia Mirkin wrote:
>> Allow ES 3.1 contexts to access the texture buffer functionality.
>>
>> Signed-off-by: Ilia Mirkin
>> ---
>> docs/GL3.txt| 2 +-
>> src/mapi/glapi/gen/apiexec.py | 4 ++--
>> src/mapi/glapi/gen/es_EXT.xml | 36 ++
>> src/mesa/main/bufferobj.c | 4 ++--
>> src/mesa/main/get.c | 4 ++--
>> src/mesa/main/get_hash_params.py| 20 -
>> src/mesa/main/tests/dispatch_sanity.cpp | 4
>> src/mesa/main/teximage.c| 20 +++--
>> src/mesa/main/texobj.c | 8 +++
>> src/mesa/main/texparam.c| 39
>> +
>> 10 files changed, 94 insertions(+), 47 deletions(-)
>>
>> diff --git a/docs/GL3.txt b/docs/GL3.txt
>> index b9d9713..2f81cba 100644
>> --- a/docs/GL3.txt
>> +++ b/docs/GL3.txt
>> @@ -254,7 +254,7 @@ GLES3.2, GLSL ES 3.2
>>GL_OES_shader_multisample_interpolation DONE (nvc0, r600,
>> radeonsi)
>>GL_OES_tessellation_shader not started (based
>> on GL_ARB_tessellation_shader, which is done for some drivers)
>>GL_OES_texture_border_clamp DONE (all drivers)
>> - GL_OES_texture_buffernot started (based
>> on GL_ARB_texture_buffer_object, GL_ARB_texture_buffer_range, and
>> GL_ARB_texture_buffer_object_rgb32 that are all done)
>> + GL_OES_texture_bufferDONE ()
>>GL_OES_texture_cube_map_arraynot started (based
>> on GL_ARB_texture_cube_map_array, which is done for all drivers)
>>GL_OES_texture_stencil8 DONE (all drivers
>> that support GL_ARB_texture_stencil8)
>>GL_OES_texture_storage_multisample_2d_array DONE (all drivers
>> that support GL_ARB_texture_multisample)
>> diff --git a/src/mapi/glapi/gen/apiexec.py b/src/mapi/glapi/gen/apiexec.py
>> index 2a80432..b4f4cf6 100644
>> --- a/src/mapi/glapi/gen/apiexec.py
>> +++ b/src/mapi/glapi/gen/apiexec.py
>> @@ -68,7 +68,7 @@ class exec_info():
>> functions = {
>> # OpenGL 3.1 / GL_ARB_texture_buffer_object. Mesa only exposes this
>> # extension with core profile.
>> -"TexBuffer": exec_info(core=31),
>> +"TexBuffer": exec_info(core=31, es2=31),
>>
>> # OpenGL 3.2 / GL_OES_geometry_shader.
>> "FramebufferTexture": exec_info(core=32, es2=31),
>> @@ -146,7 +146,7 @@ functions = {
>>
>> # OpenGL 4.3 / GL_ARB_texture_buffer_range. Mesa can expose the
>> extension
>> # with OpenGL 3.1.
>> -"TexBufferRange": exec_info(core=31),
>> +"TexBufferRange": exec_info(core=31, es2=31),
>>
>> # OpenGL 4.3 / GL_ARB_framebuffer_no_attachments. Mesa can expose the
>> # extension with OpenGL 3.0.
>> diff --git a/src/mapi/glapi/gen/es_EXT.xml b/src/mapi/glapi/gen/es_EXT.xml
>> index 2b83a97..ee8e9e5 100644
>> --- a/src/mapi/glapi/gen/es_EXT.xml
>> +++ b/src/mapi/glapi/gen/es_EXT.xml
>> @@ -853,6 +853,24 @@
>>
>>
>>
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>>
>>
>> > alias="DrawElementsBaseVertex"
>> @@ -919,6 +937,24 @@
>>
>>
>>
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>>
>>
>> > alias="DrawElementsBaseVertex"
>> diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
>> index 9aec425..731b62e 100644
>> --- a/src/mesa/main/bufferobj.c
>> +++ b/src/mesa/main/bufferobj.c
>> @@ -148,8 +148,8 @@ get_buffer_target(struct gl_context *ctx, GLenum target)
>>}
>>break;
>> case GL_TEXTURE_BUFFER:
>> - if (ctx->API == API_OPENGL_CORE &&
>> - ctx->Extensions.ARB_texture_buffer_object) {
>> + if (_mesa_has_ARB_texture_buffer_object(ctx) ||
>> + _mesa_has_OES_texture_buffer(ctx)) {
>> return &ctx->Texture.BufferObject;
>>}
>>break;
>> diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
>> index 1cbd692..6e04083 100644
>> --- a/src/mesa/main/get.c
>> +++ b/src/mesa/main/get.c
>> @@ -1903,8 +1903,8 @@ tex_binding_to_index(const struct gl_context *ctx,
>> GLenum binding)
>> || _mesa_is_gles3(ctx)
>> ? TEXTURE_2D_ARRAY_INDEX : -1;
>> case GL_TEXTURE_BINDING_BUFFER:
>> - return ctx->API == API_OPENGL_CORE &&
>> - ctx->Extensions.ARB_texture_buffer_object ?
>> + return (_mesa_has_ARB_texture_buffer_object(ctx) ||
>> + _mesa_has_OES_texture_buffer(ctx)) ?
>> TEXTURE_BUFFER_INDEX : -1;
>> case GL_TEXTURE_BINDING_CUBE_MAP_ARRAY:
>>return _mesa_is_desktop_gl(ctx) &&
>> ct
Re: [Mesa-dev] [PATCH] nir: Use double-precision pow() when bit_size is 64, powf() otherwise
On Mon, Mar 28, 2016 at 1:58 PM, Patrick Baggett
wrote:
>> What are the rules in C when you compare a double
>> variable with a single constant?
>>
>> void foo(double d)
>> {
>> /* Does d get converted to single, or does 0.0f get converted to
>> * double?
>> */
>> if (d == 0.0f)
>> printf("zero\n");
>> }
>
> The 0.0f is converted to a double. One site [1] has a likely looking
> reference. :) Sadly, I don't know how to check the C spec directly (I
> think that it is not free).
>
> [1] https://www.eskimo.com/~scs/cclass/int/sx4cb.html
Nevermind, the spec is available..found the link via Wikipedia.
6.3.1.8 Usual arithmetic conversions
1
Otherwise, if the corresponding real type of either operand is double,
the other operand is converted, without change of type domain, to a
type whose corresponding real type is double.
So yes, 100% sure that it is promoted to a double.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/4] mesa: add OES_texture_buffer and EXT_texture_buffer support
On 02/27/2016 01:30 PM, Ilia Mirkin wrote:
> Allow ES 3.1 contexts to access the texture buffer functionality.
I didn't review the get_texbuffer_format super closely, but the rest is
Reviewed-by: Ian Romanick
One other comment below that you can take or leave...
> Signed-off-by: Ilia Mirkin
> ---
> docs/GL3.txt| 2 +-
> src/mapi/glapi/gen/apiexec.py | 4 ++--
> src/mapi/glapi/gen/es_EXT.xml | 36 ++
> src/mesa/main/bufferobj.c | 4 ++--
> src/mesa/main/get.c | 4 ++--
> src/mesa/main/get_hash_params.py| 20 -
> src/mesa/main/tests/dispatch_sanity.cpp | 4
> src/mesa/main/teximage.c| 20 +++--
> src/mesa/main/texobj.c | 8 +++
> src/mesa/main/texparam.c| 39
> +
> 10 files changed, 94 insertions(+), 47 deletions(-)
>
> diff --git a/docs/GL3.txt b/docs/GL3.txt
> index b9d9713..2f81cba 100644
> --- a/docs/GL3.txt
> +++ b/docs/GL3.txt
> @@ -254,7 +254,7 @@ GLES3.2, GLSL ES 3.2
>GL_OES_shader_multisample_interpolation DONE (nvc0, r600,
> radeonsi)
>GL_OES_tessellation_shader not started (based on
> GL_ARB_tessellation_shader, which is done for some drivers)
>GL_OES_texture_border_clamp DONE (all drivers)
> - GL_OES_texture_buffernot started (based on
> GL_ARB_texture_buffer_object, GL_ARB_texture_buffer_range, and
> GL_ARB_texture_buffer_object_rgb32 that are all done)
> + GL_OES_texture_bufferDONE ()
>GL_OES_texture_cube_map_arraynot started (based on
> GL_ARB_texture_cube_map_array, which is done for all drivers)
>GL_OES_texture_stencil8 DONE (all drivers
> that support GL_ARB_texture_stencil8)
>GL_OES_texture_storage_multisample_2d_array DONE (all drivers
> that support GL_ARB_texture_multisample)
> diff --git a/src/mapi/glapi/gen/apiexec.py b/src/mapi/glapi/gen/apiexec.py
> index 2a80432..b4f4cf6 100644
> --- a/src/mapi/glapi/gen/apiexec.py
> +++ b/src/mapi/glapi/gen/apiexec.py
> @@ -68,7 +68,7 @@ class exec_info():
> functions = {
> # OpenGL 3.1 / GL_ARB_texture_buffer_object. Mesa only exposes this
> # extension with core profile.
> -"TexBuffer": exec_info(core=31),
> +"TexBuffer": exec_info(core=31, es2=31),
>
> # OpenGL 3.2 / GL_OES_geometry_shader.
> "FramebufferTexture": exec_info(core=32, es2=31),
> @@ -146,7 +146,7 @@ functions = {
>
> # OpenGL 4.3 / GL_ARB_texture_buffer_range. Mesa can expose the
> extension
> # with OpenGL 3.1.
> -"TexBufferRange": exec_info(core=31),
> +"TexBufferRange": exec_info(core=31, es2=31),
>
> # OpenGL 4.3 / GL_ARB_framebuffer_no_attachments. Mesa can expose the
> # extension with OpenGL 3.0.
> diff --git a/src/mapi/glapi/gen/es_EXT.xml b/src/mapi/glapi/gen/es_EXT.xml
> index 2b83a97..ee8e9e5 100644
> --- a/src/mapi/glapi/gen/es_EXT.xml
> +++ b/src/mapi/glapi/gen/es_EXT.xml
> @@ -853,6 +853,24 @@
>
>
>
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
>
>
> @@ -919,6 +937,24 @@
>
>
>
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
>
>
> diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
> index 9aec425..731b62e 100644
> --- a/src/mesa/main/bufferobj.c
> +++ b/src/mesa/main/bufferobj.c
> @@ -148,8 +148,8 @@ get_buffer_target(struct gl_context *ctx, GLenum target)
>}
>break;
> case GL_TEXTURE_BUFFER:
> - if (ctx->API == API_OPENGL_CORE &&
> - ctx->Extensions.ARB_texture_buffer_object) {
> + if (_mesa_has_ARB_texture_buffer_object(ctx) ||
> + _mesa_has_OES_texture_buffer(ctx)) {
It looks like every place that uses one of these functions uses the
other too. Maybe add _mesa_has_texture_buffer?
> return &ctx->Texture.BufferObject;
>}
>break;
> diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
> index 1cbd692..6e04083 100644
> --- a/src/mesa/main/get.c
> +++ b/src/mesa/main/get.c
> @@ -1903,8 +1903,8 @@ tex_binding_to_index(const struct gl_context *ctx,
> GLenum binding)
> || _mesa_is_gles3(ctx)
> ? TEXTURE_2D_ARRAY_INDEX : -1;
> case GL_TEXTURE_BINDING_BUFFER:
> - return ctx->API == API_OPENGL_CORE &&
> - ctx->Extensions.ARB_texture_buffer_object ?
> + return (_mesa_has_ARB_texture_buffer_object(ctx) ||
> + _mesa_has_OES_texture_buffer(ctx)) ?
> TEXTURE_BUFFER_INDEX : -1;
> case GL_TEXTURE_BINDING_CUBE_MAP_ARRAY:
>return _mesa_is_d
Re: [Mesa-dev] [PATCH] nir: Use double-precision pow() when bit_size is 64, powf() otherwise
> What are the rules in C when you compare a double
> variable with a single constant?
>
> void foo(double d)
> {
> /* Does d get converted to single, or does 0.0f get converted to
> * double?
> */
> if (d == 0.0f)
> printf("zero\n");
> }
The 0.0f is converted to a double. One site [1] has a likely looking
reference. :) Sadly, I don't know how to check the C spec directly (I
think that it is not free).
[1] https://www.eskimo.com/~scs/cclass/int/sx4cb.html
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/4] mesa: add OES_texture_buffer and EXT_texture_buffer extension to table
On 03/28/2016 11:53 AM, Ilia Mirkin wrote: > On Mon, Mar 28, 2016 at 2:48 PM, Ian Romanick wrote: >> On 02/27/2016 01:30 PM, Ilia Mirkin wrote: >>> Signed-off-by: Ilia Mirkin >>> --- >>> src/mesa/main/extensions_table.h | 2 ++ >>> src/mesa/main/mtypes.h | 1 + >>> 2 files changed, 3 insertions(+) >>> >>> diff --git a/src/mesa/main/extensions_table.h >>> b/src/mesa/main/extensions_table.h >>> index c139bb4..546948d 100644 >>> --- a/src/mesa/main/extensions_table.h >>> +++ b/src/mesa/main/extensions_table.h >>> @@ -230,6 +230,7 @@ EXT(EXT_texture , dummy_true >>> EXT(EXT_texture3D , dummy_true >>> , GLL, x , x , x , 1996) >>> EXT(EXT_texture_array , EXT_texture_array >>> , GLL, GLC, x , x , 2006) >>> EXT(EXT_texture_border_clamp, ARB_texture_border_clamp >>> , x , x , x , ES2, 2014) >>> +EXT(EXT_texture_buffer , OES_texture_buffer >>> , x , x , x , 31, 2014) >>> EXT(EXT_texture_compression_dxt1, >>> ANGLE_texture_compression_dxt , GLL, GLC, ES1, ES2, 2004) >>> EXT(EXT_texture_compression_latc, EXT_texture_compression_latc >>> , GLL, x , x , x , 2006) >>> EXT(EXT_texture_compression_rgtc, ARB_texture_compression_rgtc >>> , GLL, GLC, x , x , 2004) >>> @@ -346,6 +347,7 @@ EXT(OES_stencil_wrap, dummy_true >>> EXT(OES_surfaceless_context , dummy_true >>> , x , x , ES1, ES2, 2012) >>> EXT(OES_texture_3D , dummy_true >>> , x , x , x , ES2, 2005) >>> EXT(OES_texture_border_clamp, ARB_texture_border_clamp >>> , x , x , x , ES2, 2014) >>> +EXT(OES_texture_buffer , OES_texture_buffer >>> , x , x , x , 31, 2014) >>> EXT(OES_texture_cube_map, ARB_texture_cube_map >>> , x , x , ES1, x , 2007) >>> EXT(OES_texture_env_crossbar, ARB_texture_env_crossbar >>> , x , x , ES1, x , 2005) >>> EXT(OES_texture_float , OES_texture_float >>> , x , x , x , ES2, 2005) >>> diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h >>> index ba1ce24..edfcb09 100644 >>> --- a/src/mesa/main/mtypes.h >>> +++ b/src/mesa/main/mtypes.h >>> @@ -3905,6 +3905,7 @@ struct gl_extensions >>> GLboolean OES_copy_image; >>> GLboolean OES_sample_variables; >>> GLboolean OES_standard_derivatives; >>> + GLboolean OES_texture_buffer; >> >> The new bit is added because... OES_texture_buffer is a combination of >> GL_ARB_texture_buffer_object, GL_ARB_texture_buffer_range, and >> GL_ARB_texture_buffer_object_rgb32? Could you mention that in the >> commit message (if it's not too late)? > > Will do. With that change, Reviewed-by: Ian Romanick >> Also... is there any hardware that supports only a subset of those >> extensions? I'd be tempted to just have one flag for all of them. > > ... and ARB_shader_image_load_store, since it actually depends on ES > 3.1, it also includes imageBuffer support. > > nv50 doesn't support GL_ARB_texture_buffer_object_rgb32 but it does > support the other exts (except images... maybe enough for ES 3.1, but > def not enough for core -- ES 3.1 only requires them in compute > shaders... but even if that support is added, it still wouldn't > support ARB_tbo_rgb32). Then it makes sense to keep all the flags. Dang. > I was thinking of dropping an enable into st/mesa along the lines of > > OES_texture_buffer = ARB_texture_buffer_object_rgb32 && > ARB_shader_image_load_store. > >> >>> /* vendor extensions */ >>> GLboolean AMD_performance_monitor; >>> GLboolean AMD_pinned_memory; >>> ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/4] mesa: add OES_texture_buffer and EXT_texture_buffer extension to table
On Mon, Mar 28, 2016 at 2:48 PM, Ian Romanick wrote: > On 02/27/2016 01:30 PM, Ilia Mirkin wrote: >> Signed-off-by: Ilia Mirkin >> --- >> src/mesa/main/extensions_table.h | 2 ++ >> src/mesa/main/mtypes.h | 1 + >> 2 files changed, 3 insertions(+) >> >> diff --git a/src/mesa/main/extensions_table.h >> b/src/mesa/main/extensions_table.h >> index c139bb4..546948d 100644 >> --- a/src/mesa/main/extensions_table.h >> +++ b/src/mesa/main/extensions_table.h >> @@ -230,6 +230,7 @@ EXT(EXT_texture , dummy_true >> EXT(EXT_texture3D , dummy_true >> , GLL, x , x , x , 1996) >> EXT(EXT_texture_array , EXT_texture_array >> , GLL, GLC, x , x , 2006) >> EXT(EXT_texture_border_clamp, ARB_texture_border_clamp >> , x , x , x , ES2, 2014) >> +EXT(EXT_texture_buffer , OES_texture_buffer >> , x , x , x , 31, 2014) >> EXT(EXT_texture_compression_dxt1, ANGLE_texture_compression_dxt >> , GLL, GLC, ES1, ES2, 2004) >> EXT(EXT_texture_compression_latc, EXT_texture_compression_latc >> , GLL, x , x , x , 2006) >> EXT(EXT_texture_compression_rgtc, ARB_texture_compression_rgtc >> , GLL, GLC, x , x , 2004) >> @@ -346,6 +347,7 @@ EXT(OES_stencil_wrap, dummy_true >> EXT(OES_surfaceless_context , dummy_true >> , x , x , ES1, ES2, 2012) >> EXT(OES_texture_3D , dummy_true >> , x , x , x , ES2, 2005) >> EXT(OES_texture_border_clamp, ARB_texture_border_clamp >> , x , x , x , ES2, 2014) >> +EXT(OES_texture_buffer , OES_texture_buffer >> , x , x , x , 31, 2014) >> EXT(OES_texture_cube_map, ARB_texture_cube_map >> , x , x , ES1, x , 2007) >> EXT(OES_texture_env_crossbar, ARB_texture_env_crossbar >> , x , x , ES1, x , 2005) >> EXT(OES_texture_float , OES_texture_float >> , x , x , x , ES2, 2005) >> diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h >> index ba1ce24..edfcb09 100644 >> --- a/src/mesa/main/mtypes.h >> +++ b/src/mesa/main/mtypes.h >> @@ -3905,6 +3905,7 @@ struct gl_extensions >> GLboolean OES_copy_image; >> GLboolean OES_sample_variables; >> GLboolean OES_standard_derivatives; >> + GLboolean OES_texture_buffer; > > The new bit is added because... OES_texture_buffer is a combination of > GL_ARB_texture_buffer_object, GL_ARB_texture_buffer_range, and > GL_ARB_texture_buffer_object_rgb32? Could you mention that in the > commit message (if it's not too late)? Will do. > > Also... is there any hardware that supports only a subset of those > extensions? I'd be tempted to just have one flag for all of them. ... and ARB_shader_image_load_store, since it actually depends on ES 3.1, it also includes imageBuffer support. nv50 doesn't support GL_ARB_texture_buffer_object_rgb32 but it does support the other exts (except images... maybe enough for ES 3.1, but def not enough for core -- ES 3.1 only requires them in compute shaders... but even if that support is added, it still wouldn't support ARB_tbo_rgb32). I was thinking of dropping an enable into st/mesa along the lines of OES_texture_buffer = ARB_texture_buffer_object_rgb32 && ARB_shader_image_load_store. > >> /* vendor extensions */ >> GLboolean AMD_performance_monitor; >> GLboolean AMD_pinned_memory; >> > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/1] vc4: Remove unused include from vc4_nir_lower_txf_ms.c
Rhys Kidd writes: > On Saturday, March 19, 2016, Rhys Kidd wrote: > >> Found with grep and inspection. Test compiled on RPi hw. >> Assists any future effort to remove TGSI as an intermediate stage. >> >> Signed-off-by: Rhys Kidd > >> --- >> src/gallium/drivers/vc4/vc4_nir_lower_txf_ms.c | 1 - >> 1 file changed, 1 deletion(-) >> >> diff --git a/src/gallium/drivers/vc4/vc4_nir_lower_txf_ms.c >> b/src/gallium/drivers/vc4/vc4_nir_lower_txf_ms.c >> index f6ba5b8..590e577 100644 >> --- a/src/gallium/drivers/vc4/vc4_nir_lower_txf_ms.c >> +++ b/src/gallium/drivers/vc4/vc4_nir_lower_txf_ms.c >> @@ -23,7 +23,6 @@ >> >> #include "vc4_qir.h" >> #include "kernel/vc4_packet.h" >> -#include "tgsi/tgsi_info.h" >> #include "compiler/nir/nir_builder.h" >> >> /** @file vc4_nir_lower_txf_ms.c >> -- >> 2.5.0 >> >> > Humble ping? Applied. Thanks! signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 2/2] glsl: raise warning when using uninitialized variables
v2:
* Take into account out varyings too (Timothy Arceri)
* Fix style (Timothy Arceri)
* Use a new ast_expression variable, instead of an
ast_expression::hir new parameter (Timothy Arceri)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94129
---
src/compiler/glsl/ast_to_hir.cpp | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/compiler/glsl/ast_to_hir.cpp b/src/compiler/glsl/ast_to_hir.cpp
index eb45f29..e38ab10 100644
--- a/src/compiler/glsl/ast_to_hir.cpp
+++ b/src/compiler/glsl/ast_to_hir.cpp
@@ -1901,6 +1901,13 @@ ast_expression::do_hir(exec_list *instructions,
if (var != NULL) {
var->data.used = true;
result = new(ctx) ir_dereference_variable(var);
+
+ if ((var->data.mode == ir_var_auto || var->data.mode ==
ir_var_shader_out)
+ && !this->is_lhs
+ && result->variable_referenced()->data.assigned != true) {
+_mesa_glsl_warning(&loc, state, "`%s' used uninitialized",
+ this->primary_expression.identifier);
+ }
} else {
_mesa_glsl_error(& loc, state, "`%s' undeclared",
this->primary_expression.identifier);
--
2.5.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 1/2] glsl: add is_lhs bool on ast_expression
Useful to know if a expression is the recipient of an assignment
or not, that would be used to (for example) raise warnings of
"use of uninitialized variable" without getting a false positive
when assigning first a variable.
By default the value is false, and it is assigned to true on
the following cases:
* The lhs assignments subexpression
* At ast_array_index, on the array itself.
* While handling the method on an array, to avoid the warning
calling array.length
* When computed the cached test expression at test_to_hir, to
avoid a duplicate warning on the test expression of a switch.
set_is_lhs setter is added, because in some cases (like ast_field_selection)
the value need to be propagated on the expression tree. To avoid doing the
propatagion if not needed, it skips if no primary_expression.identifier is
available.
v2: use a new bool on ast_expression, instead of a new parameter
on ast_expression::hir (Timothy Arceri)
v3: fix style and some typos on comments, initialize is_lhs default value
on constructor, to avoid a c++11 feature (Ian Romanick)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94129
---
src/compiler/glsl/ast.h | 6 ++
src/compiler/glsl/ast_function.cpp | 4
src/compiler/glsl/ast_to_hir.cpp | 33
src/compiler/glsl/glsl_parser_extras.cpp | 1 +
4 files changed, 44 insertions(+)
diff --git a/src/compiler/glsl/ast.h b/src/compiler/glsl/ast.h
index 727aa43..9f46340 100644
--- a/src/compiler/glsl/ast.h
+++ b/src/compiler/glsl/ast.h
@@ -214,6 +214,7 @@ public:
subexpressions[2] = NULL;
primary_expression.identifier = identifier;
this->non_lvalue_description = NULL;
+ this->is_lhs = false;
}
static const char *operator_string(enum ast_operators op);
@@ -263,6 +264,11 @@ public:
* This pointer may be \c NULL.
*/
const char *non_lvalue_description;
+
+ void set_is_lhs(bool new_value);
+
+private:
+ bool is_lhs;
};
class ast_expression_bin : public ast_expression {
diff --git a/src/compiler/glsl/ast_function.cpp
b/src/compiler/glsl/ast_function.cpp
index 1a44020..db68d5d 100644
--- a/src/compiler/glsl/ast_function.cpp
+++ b/src/compiler/glsl/ast_function.cpp
@@ -1727,6 +1727,10 @@ ast_function_expression::handle_method(exec_list
*instructions,
const char *method;
method = field->primary_expression.identifier;
+ /* This would prevent to raise "uninitialized variable" warnings when
+* calling array.length.
+*/
+ field->subexpressions[0]->set_is_lhs(true);
op = field->subexpressions[0]->hir(instructions, state);
if (strcmp(method, "length") == 0) {
if (!this->expressions.is_empty()) {
diff --git a/src/compiler/glsl/ast_to_hir.cpp b/src/compiler/glsl/ast_to_hir.cpp
index 35def8e..eb45f29 100644
--- a/src/compiler/glsl/ast_to_hir.cpp
+++ b/src/compiler/glsl/ast_to_hir.cpp
@@ -1248,6 +1248,24 @@ ast_expression::hir_no_rvalue(exec_list *instructions,
do_hir(instructions, state, false);
}
+void
+ast_expression::set_is_lhs(bool new_value)
+{
+ /* is_lhs is tracked only to print "variable used uninitialized" warnings,
+* if we lack a identifier we can just skip, so also skipping going through
+* subexpressions (see below)
+*/
+ if (this->primary_expression.identifier == NULL)
+ return;
+
+ this->is_lhs = new_value;
+
+ /* We need to go through the subexpressions tree to cover cases like
+* ast_field_selection */
+ if (this->subexpressions[0] != NULL)
+ this->subexpressions[0]->set_is_lhs(new_value);
+}
+
ir_rvalue *
ast_expression::do_hir(exec_list *instructions,
struct _mesa_glsl_parse_state *state,
@@ -1323,6 +1341,7 @@ ast_expression::do_hir(exec_list *instructions,
break;
case ast_assign: {
+ this->subexpressions[0]->set_is_lhs(true);
op[0] = this->subexpressions[0]->hir(instructions, state);
op[1] = this->subexpressions[1]->hir(instructions, state);
@@ -1592,6 +1611,7 @@ ast_expression::do_hir(exec_list *instructions,
case ast_div_assign:
case ast_add_assign:
case ast_sub_assign: {
+ this->subexpressions[0]->set_is_lhs(true);
op[0] = this->subexpressions[0]->hir(instructions, state);
op[1] = this->subexpressions[1]->hir(instructions, state);
@@ -1618,6 +1638,7 @@ ast_expression::do_hir(exec_list *instructions,
}
case ast_mod_assign: {
+ this->subexpressions[0]->set_is_lhs(true);
op[0] = this->subexpressions[0]->hir(instructions, state);
op[1] = this->subexpressions[1]->hir(instructions, state);
@@ -1640,6 +1661,7 @@ ast_expression::do_hir(exec_list *instructions,
case ast_ls_assign:
case ast_rs_assign: {
+ this->subexpressions[0]->set_is_lhs(true);
op[0] = this->subexpressions[0]->hir(instructions, state);
op[1] = this->subexpressions[1]->hir(instructions, state);
type = shift_result_type(op[0]->type,
[Mesa-dev] [PATCH 0/2] glsl: add "use of uninitialized variable" warning
This is a re-send of some patches that I sent one month ago, because as they had a partial review and some new versions of those patches, I assume that it would be easier this way (correct me if I'm wrong). The original send can be found here: https://lists.freedesktop.org/archives/mesa-dev/2016-February/108667.html And here: https://patchwork.freedesktop.org/series/3851/ Alejandro Piñeiro (2): glsl: add is_lhs bool on ast_expression glsl: raise warning when using uninitialized variables src/compiler/glsl/ast.h | 6 + src/compiler/glsl/ast_function.cpp | 4 src/compiler/glsl/ast_to_hir.cpp | 40 src/compiler/glsl/glsl_parser_extras.cpp | 1 + 4 files changed, 51 insertions(+) -- 2.5.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/4] mesa: add OES_texture_buffer and EXT_texture_buffer extension to table
On 02/27/2016 01:30 PM, Ilia Mirkin wrote: > Signed-off-by: Ilia Mirkin > --- > src/mesa/main/extensions_table.h | 2 ++ > src/mesa/main/mtypes.h | 1 + > 2 files changed, 3 insertions(+) > > diff --git a/src/mesa/main/extensions_table.h > b/src/mesa/main/extensions_table.h > index c139bb4..546948d 100644 > --- a/src/mesa/main/extensions_table.h > +++ b/src/mesa/main/extensions_table.h > @@ -230,6 +230,7 @@ EXT(EXT_texture , dummy_true > EXT(EXT_texture3D , dummy_true > , GLL, x , x , x , 1996) > EXT(EXT_texture_array , EXT_texture_array > , GLL, GLC, x , x , 2006) > EXT(EXT_texture_border_clamp, ARB_texture_border_clamp > , x , x , x , ES2, 2014) > +EXT(EXT_texture_buffer , OES_texture_buffer > , x , x , x , 31, 2014) > EXT(EXT_texture_compression_dxt1, ANGLE_texture_compression_dxt > , GLL, GLC, ES1, ES2, 2004) > EXT(EXT_texture_compression_latc, EXT_texture_compression_latc > , GLL, x , x , x , 2006) > EXT(EXT_texture_compression_rgtc, ARB_texture_compression_rgtc > , GLL, GLC, x , x , 2004) > @@ -346,6 +347,7 @@ EXT(OES_stencil_wrap, dummy_true > EXT(OES_surfaceless_context , dummy_true > , x , x , ES1, ES2, 2012) > EXT(OES_texture_3D , dummy_true > , x , x , x , ES2, 2005) > EXT(OES_texture_border_clamp, ARB_texture_border_clamp > , x , x , x , ES2, 2014) > +EXT(OES_texture_buffer , OES_texture_buffer > , x , x , x , 31, 2014) > EXT(OES_texture_cube_map, ARB_texture_cube_map > , x , x , ES1, x , 2007) > EXT(OES_texture_env_crossbar, ARB_texture_env_crossbar > , x , x , ES1, x , 2005) > EXT(OES_texture_float , OES_texture_float > , x , x , x , ES2, 2005) > diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h > index ba1ce24..edfcb09 100644 > --- a/src/mesa/main/mtypes.h > +++ b/src/mesa/main/mtypes.h > @@ -3905,6 +3905,7 @@ struct gl_extensions > GLboolean OES_copy_image; > GLboolean OES_sample_variables; > GLboolean OES_standard_derivatives; > + GLboolean OES_texture_buffer; The new bit is added because... OES_texture_buffer is a combination of GL_ARB_texture_buffer_object, GL_ARB_texture_buffer_range, and GL_ARB_texture_buffer_object_rgb32? Could you mention that in the commit message (if it's not too late)? Also... is there any hardware that supports only a subset of those extensions? I'd be tempted to just have one flag for all of them. > /* vendor extensions */ > GLboolean AMD_performance_monitor; > GLboolean AMD_pinned_memory; > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] mesa: new _mesa_prepare_mipmap_levels() function for mipmap generation
On 03/26/2016 10:21 AM, Brian Paul wrote:
> Simplifies the loops in generate_mipmap_uncompressed() and
> generate_mipmap_compressed(). Will be used in the state tracker too.
> Could probably be used in the meta code. If so, some additional
> clean-ups can be done after that.
I'm in favor of just about anything that can lead to clean ups in meta.
I have a couple comments below.
> ---
> src/mesa/main/mipmap.c | 89
> --
> src/mesa/main/mipmap.h | 5 +++
> 2 files changed, 63 insertions(+), 31 deletions(-)
>
> diff --git a/src/mesa/main/mipmap.c b/src/mesa/main/mipmap.c
> index 5a02780..02d236d 100644
> --- a/src/mesa/main/mipmap.c
> +++ b/src/mesa/main/mipmap.c
> @@ -1872,6 +1872,50 @@ _mesa_prepare_mipmap_level(struct gl_context *ctx,
> }
>
>
> +/**
> + * Prepare all mipmap levels beyond 'baseLevel' for mipmap generation.
> + * When finished, all the gl_texture_image structures for the smaller
> + * mipmap levels will be consistent with the base level (in terms of
> + * dimensions, format, etc).
> + */
> +void
> +_mesa_prepare_mipmap_levels(struct gl_context *ctx,
> +struct gl_texture_object *texObj,
> +GLuint baseLevel, GLuint maxLevel)
Can these be plain unsigned?
> +{
> + const struct gl_texture_image *baseImage =
> + _mesa_select_tex_image(texObj, texObj->Target, baseLevel);
> + const GLint border = 0;
> + GLint width = baseImage->Width;
> + GLint height = baseImage->Height;
> + GLint depth = baseImage->Depth;
> + const GLenum intFormat = baseImage->InternalFormat;
> + const mesa_format texFormat = baseImage->TexFormat;
> + GLint newWidth, newHeight, newDepth;
> + GLuint level;
> +
> + /* Prepare baseLevel + 1, baseLevel + 2, ... */
> + for (level = baseLevel + 1; level <= maxLevel; level++) {
Now that we can use more C99, I'm in favor of
for (unsigned level = baseLevel + 1; level <= maxLevel; level++) {
> + if (!_mesa_next_mipmap_level_size(texObj->Target, border,
> +width, height, depth,
> +&newWidth, &newHeight, &newDepth)) {
Meta has some special handling for GL_TEXTURE_1D_ARRAY. I think that
needs to be done here too.
> + /* all done */
> + break;
> + }
> +
> + if (!_mesa_prepare_mipmap_level(ctx, texObj, level,
> + newWidth, newHeight, newDepth,
> + border, intFormat, texFormat)) {
> + break;
> + }
> +
> + width = newWidth;
> + height = newHeight;
> + depth = newDepth;
> + }
> +}
> +
> +
> static void
> generate_mipmap_uncompressed(struct gl_context *ctx, GLenum target,
>struct gl_texture_object *texObj,
> @@ -1892,7 +1936,6 @@ generate_mipmap_uncompressed(struct gl_context *ctx,
> GLenum target,
>GLint dstWidth, dstHeight, dstDepth;
>GLint border;
>GLint slice;
> - GLboolean nextLevel;
>GLubyte **srcMaps, **dstMaps;
>GLboolean success = GL_TRUE;
>
> @@ -1904,22 +1947,14 @@ generate_mipmap_uncompressed(struct gl_context *ctx,
> GLenum target,
>srcDepth = srcImage->Depth;
>border = srcImage->Border;
>
> - nextLevel = _mesa_next_mipmap_level_size(target, border,
> - srcWidth, srcHeight, srcDepth,
> - &dstWidth, &dstHeight, &dstDepth);
> - if (!nextLevel)
> - return;
> -
> - if (!_mesa_prepare_mipmap_level(ctx, texObj, level + 1,
> - dstWidth, dstHeight, dstDepth,
> - border, srcImage->InternalFormat,
> - srcImage->TexFormat)) {
> - return;
> - }
> -
>/* get dest gl_texture_image */
>dstImage = _mesa_select_tex_image(texObj, target, level + 1);
> - assert(dstImage);
> + if (!dstImage) {
> + break;
> + }
> + dstWidth = dstImage->Width;
> + dstHeight = dstImage->Height;
> + dstDepth = dstImage->Depth;
>
>if (target == GL_TEXTURE_1D_ARRAY) {
>srcDepth = srcHeight;
> @@ -2087,7 +2122,6 @@ generate_mipmap_compressed(struct gl_context *ctx,
> GLenum target,
>GLint srcWidth, srcHeight, srcDepth;
>GLint dstWidth, dstHeight, dstDepth;
>GLint border;
> - GLboolean nextLevel;
>GLuint temp_dst_row_stride, temp_dst_img_stride; /* in bytes */
>GLint i;
>
> @@ -2099,23 +2133,14 @@ generate_mipmap_compressed(struct gl_context *ctx,
> GLenum target,
>srcDepth = srcImage->Depth;
>border = srcImage->Border;
>
> - nextLevel = _mesa_next_mipmap_level_size(target, border,
> - srcWidth, srcHeight, srcDepth,
> - &dstWidth,
Re: [Mesa-dev] [PATCH] nir: Use double-precision pow() when bit_size is 64, powf() otherwise
On 03/23/2016 08:09 PM, Jason Ekstrand wrote:
> Is there a 64-bit pow in GLSL? If so, this is the right implementation.
There isn't. But there also aren't double versions of sin or cos, and
9076c4e2 added those. However, it didn't add double versions of fexp2
or flog2 (both of which are not supported in GLSL).
Ugh... it also did not add double versions of frsq or fsqrt... which are
supported in GLSL.
So, there are some extra functions and some missing functions. My gut
tells me we should just do all of them so that people don't have to
think about which ones should / shouldn't be implemented.
Looking more closely... I think fabs, fnot, fsign, and fsat should have
explicit double support as well... it seems the existing implementations
of both of these will cause some small values to be incorrectly
"flushed" to zero. What are the rules in C when you compare a double
variable with a single constant?
void foo(double d)
{
/* Does d get converted to single, or does 0.0f get converted to
* double?
*/
if (d == 0.0f)
printf("zero\n");
}
> Reviewed-by: Jason Ekstrand >
>
> On Mar 23, 2016 7:42 PM, "Ian Romanick" > wrote:
>
> From: Ian Romanick >
>
> Found (randomly) by inspection. Looking at the rest of the changes in
> this file in commit 9076c4e2, I'm certain this is what was intended.
>
> Signed-off-by: Ian Romanick >
> Cc: Connor Abbott mailto:cwabbo...@gmail.com>>
> Cc: mesa-sta...@lists.freedesktop.org
>
> ---
> src/compiler/nir/nir_opcodes.py | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/compiler/nir/nir_opcodes.py
> b/src/compiler/nir/nir_opcodes.py
> index 553f924..ac59130 100644
> --- a/src/compiler/nir/nir_opcodes.py
> +++ b/src/compiler/nir/nir_opcodes.py
> @@ -520,7 +520,7 @@ for (int i = 0; i < 32; i += 8) {
> }
> """)
>
> -binop("fpow", tfloat, "", "bit_size == 64 ? powf(src0, src1) :
> pow(src0, src1)")
> +binop("fpow", tfloat, "", "bit_size == 64 ? pow(src0, src1) :
> powf(src0, src1)")
>
> binop_horiz("pack_half_2x16_split", 1, tuint32, 1, tfloat32, 1,
> tfloat32,
> "pack_half_1x16(src0.x) | (pack_half_1x16(src1.x) << 16)")
> --
> 2.5.5
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC 2/4] gallium: Add fixed block size to pipe_compute_state
Only tangentially related, but just making sure you're aware of
GL_ARB_compute_variable_group_size - this allows the local size to be
specified at dispatch time rather than at shader compile time. I
believe your proposed scheme would allow this to be handled as well.
-ilia
On Thu, Mar 24, 2016 at 9:43 PM, Bas Nieuwenhuizen
wrote:
> This avoids shader variants for radeonsi, or if we go with
> shader variants, it lets us compile an initial variant.
>
> Signed-off-by: Bas Nieuwenhuizen
> ---
> src/gallium/drivers/trace/tr_dump_state.c | 4
> src/gallium/include/pipe/p_state.h| 6 ++
> src/gallium/tests/trivial/compute.c | 1 +
> src/mesa/state_tracker/st_program.c | 2 ++
> 4 files changed, 13 insertions(+)
>
> diff --git a/src/gallium/drivers/trace/tr_dump_state.c
> b/src/gallium/drivers/trace/tr_dump_state.c
> index 394cdaa..4f89af9 100644
> --- a/src/gallium/drivers/trace/tr_dump_state.c
> +++ b/src/gallium/drivers/trace/tr_dump_state.c
> @@ -333,6 +333,10 @@ void trace_dump_compute_state(const struct
> pipe_compute_state *state)
> trace_dump_member(uint, state, req_private_mem);
> trace_dump_member(uint, state, req_input_mem);
>
> + trace_dump_member_begin("fixed_block");
> + trace_dump_array(uint, state->fixed_block, Elements(state->fixed_block));
> + trace_dump_member_end();
> +
> trace_dump_struct_end();
> }
>
> diff --git a/src/gallium/include/pipe/p_state.h
> b/src/gallium/include/pipe/p_state.h
> index 8e7a10b..fff90e7 100644
> --- a/src/gallium/include/pipe/p_state.h
> +++ b/src/gallium/include/pipe/p_state.h
> @@ -732,6 +732,12 @@ struct pipe_compute_state
> unsigned req_local_mem; /**< Required size of the LOCAL resource. */
> unsigned req_private_mem; /**< Required size of the PRIVATE resource. */
> unsigned req_input_mem; /**< Required size of the INPUT resource. */
> +
> + /**
> +* Block layout if known, or all zeroes if the block layout is either not
> +* known yet or dynamic.
> +*/
> + unsigned fixed_block[3];
> };
>
> /**
> diff --git a/src/gallium/tests/trivial/compute.c
> b/src/gallium/tests/trivial/compute.c
> index 2ddfc42..af3e3aa 100644
> --- a/src/gallium/tests/trivial/compute.c
> +++ b/src/gallium/tests/trivial/compute.c
> @@ -149,6 +149,7 @@ static void init_prog(struct context *ctx, unsigned
> local_sz,
> .req_local_mem = local_sz,
> .req_private_mem = private_sz,
> .req_input_mem = input_sz
> +.fixed_block = {0}
> };
> char *psrc = preprocess_prog(ctx, src, defs);
> int ret;
> diff --git a/src/mesa/state_tracker/st_program.c
> b/src/mesa/state_tracker/st_program.c
> index 5e282d9..5777e76 100644
> --- a/src/mesa/state_tracker/st_program.c
> +++ b/src/mesa/state_tracker/st_program.c
> @@ -1440,6 +1440,8 @@ st_translate_compute_program(struct st_context *st,
> stcp->tgsi.req_local_mem = stcp->Base.SharedSize;
> stcp->tgsi.req_private_mem = 0;
> stcp->tgsi.req_input_mem = 0;
> + memcpy(stcp->tgsi.fixed_block, stcp->Base.LocalSize,
> + sizeof(stcp->Base.LocalSize));
>
> free_glsl_to_tgsi_visitor(stcp->glsl_to_tgsi);
> stcp->glsl_to_tgsi = NULL;
> --
> 2.7.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] st/mesa: simplify st_generate_mipmap()
One typo below otherwise: Reviewed-by: Sinclair Yeh
On Sat, Mar 26, 2016 at 11:21:19AM -0600, Brian Paul wrote:
> The whole st_generate_mipmap() function was overly complicated. Now
> we just call the new _mesa_prepare_mipmap_levels() function to prepare
> the texture mipmap memory, then call the generate function which fills
> in the texture images.
>
> This fixes a failed assertion in llvmpipe/softpipe which is hit with the
> new piglit generatemipmap-base-change test. Also fixes some device errors
> (format mismatches) with the VMware svga driver.
> ---
> src/mesa/state_tracker/st_gen_mipmap.c | 102
> -
> 1 file changed, 24 insertions(+), 78 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_gen_mipmap.c
> b/src/mesa/state_tracker/st_gen_mipmap.c
> index c4b3492..d854e20 100644
> --- a/src/mesa/state_tracker/st_gen_mipmap.c
> +++ b/src/mesa/state_tracker/st_gen_mipmap.c
> @@ -82,7 +82,6 @@ st_generate_mipmap(struct gl_context *ctx, GLenum target,
> const uint baseLevel = texObj->BaseLevel;
> enum pipe_format format;
> uint lastLevel, first_layer, last_layer;
> - uint dstLevel;
>
> if (!pt)
>return;
> @@ -103,42 +102,33 @@ st_generate_mipmap(struct gl_context *ctx, GLenum
> target,
> stObj->lastLevel = lastLevel;
>
> if (!texObj->Immutable) {
> - if (pt->last_level < lastLevel) {
> - /* The current gallium texture doesn't have space for all the
> - * mipmap levels we need to generate. So allocate a new texture.
> - */
> - struct pipe_resource *oldTex = stObj->pt;
> -
> - /* create new texture with space for more levels */
> - stObj->pt = st_texture_create(st,
> - oldTex->target,
> - oldTex->format,
> - lastLevel,
> - oldTex->width0,
> - oldTex->height0,
> - oldTex->depth0,
> - oldTex->array_size,
> - 0,
> - oldTex->bind);
> -
> - /* This will copy the old texture's base image into the new texture
> - * which we just allocated.
> - */
> - st_finalize_texture(ctx, st->pipe, texObj);
> -
> - /* release the old tex (will likely be freed too) */
> - pipe_resource_reference(&oldTex, NULL);
> - st_texture_release_all_sampler_views(st, stObj);
> - }
> - else {
> - /* Make sure that the base texture image data is present in the
> - * texture buffer.
> - */
> - st_finalize_texture(ctx, st->pipe, texObj);
> - }
> + const GLboolean genSave = texObj->GenerateMipmap;
> +
> + /* Temporarily set GenerateMipmap to true so that
> allocate_full_mipmap()
> + * makes the right decision about full mipmap allocation.
> + */
> + texObj->GenerateMipmap = GL_TRUE;
> +
> + _mesa_prepare_mipmap_levels(ctx, texObj, baseLevel, lastLevel);
> +
> + texObj->GenerateMipmap = genSave;
> +
> + /* At this point, memory for all the texture levels has been
> + * allocated. However, the base level image may be in one resource
> + * while the subsequent/smaller levels may be in another resource.
> + * Finalizing the texture will copy the base images from the former
> + * resource to the later.
latter.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 06/11] glapi: Fix whitespace droppings when printing the license header
Quoting Ian Romanick (2016-03-28 11:03:58)
> On 03/25/2016 05:33 PM, Dylan Baker wrote:
> > Quoting Dylan Baker (2016-03-25 16:01:00)
> >> Quoting Adam Jackson (2016-03-24 11:10:01)
> >>> Signed-off-by: Adam Jackson
> >>> ---
> >>> src/mapi/glapi/gen/gl_XML.py | 2 +-
> >>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/src/mapi/glapi/gen/gl_XML.py b/src/mapi/glapi/gen/gl_XML.py
> >>> index 2e7123e..e11f6fc 100644
> >>> --- a/src/mapi/glapi/gen/gl_XML.py
> >>> +++ b/src/mapi/glapi/gen/gl_XML.py
> >>> @@ -130,7 +130,7 @@ class gl_print_base(object):
> >>> % (self.name)
> >>> print ''
> >>> print '/*'
> >>> -print ' * ' + self.license.replace('\n', '\n * ')
> >>> +print (' * ' + self.license.replace('\n', '\n * ')).replace('
> >>> \n', '\n')
> >>
> >> That's a brainful to parse, what about to stupid, but obvious solution:
> >>
> >> for l in self.license.split('\n'):
> >> print ' * {0}'.format(l)
> >
> > Or, since mesa's python code seems to use C style formatters:
> > print ' * %s' % l
>
> Do those actually do the right thing? self.license is multiple lines of
> text. The old code prefixes each line after the first line with ' * '.
>
> I'm not sure how the dangling whitespace occurs in the first place. Is
> it in the original license text? Could we just trim it there?
I didn't test Ajax's solution, but mine does print what we really want.
It might make more sense to just put the comments in self.license.
>
> >>> print ' */'
> >>> print ''
> >>> if self.header_tag:
> >>> --
> >>> 2.5.0
> >>>
> >>> ___
> >>> mesa-dev mailing list
> >>> mesa-dev@lists.freedesktop.org
> >>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 03/11] glapi/glx: skip that which is marked for skipping
I am confused by this patch. Mesa drivers doesn't support
GL_NV_vertex_program, but the library still supports the protocol for it
for compatibility with other server implementations.
src/glx/glxextensions.c still tries to advertise support. I'm guess
that these aren't getting stuffed in the dispatch table, so something is
already broken.
On 03/24/2016 11:09 AM, Adam Jackson wrote:
> Signed-off-by: Adam Jackson
> ---
> src/glx/indirect_vertex_array.c | 39
> src/glx/indirect_vertex_program.c | 202
> --
> src/glx/tests/indirect_api.cpp| 2 -
> src/mapi/glapi/gen/glX_XML.py | 6 +-
> 4 files changed, 4 insertions(+), 245 deletions(-)
>
> diff --git a/src/glx/indirect_vertex_array.c b/src/glx/indirect_vertex_array.c
> index 2bf2ff1..1fb5137 100644
> --- a/src/glx/indirect_vertex_array.c
> +++ b/src/glx/indirect_vertex_array.c
> @@ -1691,45 +1691,6 @@ __indirect_glVertexAttribPointer(GLuint index, GLint
> size,
> }
>
>
> -/**
> - * I don't have 100% confidence that this is correct. The different rules
> - * about whether or not generic vertex attributes alias "classic" vertex
> - * attributes (i.e., attrib1 ?= primary color) between ARB_vertex_program,
> - * ARB_vertex_shader, and NV_vertex_program are a bit confusing. My
> - * feeling is that the client-side doesn't have to worry about it. The
> - * client just sends all the data to the server and lets the server deal
> - * with it.
> - */
> -void
> -__indirect_glVertexAttribPointerNV(GLuint index, GLint size,
> - GLenum type, GLsizei stride,
> - const GLvoid * pointer)
> -{
> - struct glx_context *gc = __glXGetCurrentContext();
> - GLboolean normalized = GL_FALSE;
> -
> -
> - switch (type) {
> - case GL_UNSIGNED_BYTE:
> - if (size != 4) {
> - __glXSetError(gc, GL_INVALID_VALUE);
> - return;
> - }
> - normalized = GL_TRUE;
> -
> - case GL_SHORT:
> - case GL_FLOAT:
> - case GL_DOUBLE:
> - __indirect_glVertexAttribPointer(index, size, type,
> - normalized, stride, pointer);
> - return;
> - default:
> - __glXSetError(gc, GL_INVALID_ENUM);
> - return;
> - }
> -}
> -
> -
> void
> __indirect_glClientActiveTexture(GLenum texture)
> {
> diff --git a/src/glx/indirect_vertex_program.c
> b/src/glx/indirect_vertex_program.c
> index 54a936d..e3f57c5 100644
> --- a/src/glx/indirect_vertex_program.c
> +++ b/src/glx/indirect_vertex_program.c
> @@ -35,33 +35,6 @@
> #endif
>
> static void
> -do_vertex_attrib_enable(GLuint index, GLboolean val)
> -{
> - struct glx_context *gc = __glXGetCurrentContext();
> - __GLXattribute *state = (__GLXattribute *) (gc->client_state_private);
> -
> - if (!__glXSetArrayEnable(state, GL_VERTEX_ATTRIB_ARRAY_POINTER_ARB,
> -index, val)) {
> - __glXSetError(gc, GL_INVALID_ENUM);
> - }
> -}
> -
> -
> -void
> -__indirect_glEnableVertexAttribArray(GLuint index)
> -{
> - do_vertex_attrib_enable(index, GL_TRUE);
> -}
> -
> -
> -void
> -__indirect_glDisableVertexAttribArray(GLuint index)
> -{
> - do_vertex_attrib_enable(index, GL_FALSE);
> -}
> -
> -
> -static void
> get_parameter(unsigned opcode, unsigned size, GLenum target, GLuint index,
>void *params)
> {
> @@ -116,178 +89,3 @@ __indirect_glGetProgramLocalParameterdvARB(GLenum
> target, GLuint index,
> {
> get_parameter(1306, 8, target, index, params);
> }
> -
> -
> -void
> -__indirect_glGetVertexAttribPointerv(GLuint index, GLenum pname,
> - GLvoid ** pointer)
> -{
> - struct glx_context *const gc = __glXGetCurrentContext();
> - __GLXattribute *state = (__GLXattribute *) (gc->client_state_private);
> -
> - if (pname != GL_VERTEX_ATTRIB_ARRAY_POINTER_ARB) {
> - __glXSetError(gc, GL_INVALID_ENUM);
> - }
> -
> - if (!__glXGetArrayPointer(state, GL_VERTEX_ATTRIB_ARRAY_POINTER_ARB,
> - index, pointer)) {
> - __glXSetError(gc, GL_INVALID_VALUE);
> - }
> -}
> -
> -
> -/**
> - * Get the selected attribute from the vertex array state vector.
> - *
> - * \returns
> - * On success \c GL_TRUE is returned. Otherwise, \c GL_FALSE is returned.
> - */
> -static GLboolean
> -get_attrib_array_data(__GLXattribute * state, GLuint index, GLenum cap,
> - GLintptr * data)
> -{
> - GLboolean retval = GL_FALSE;
> - const GLenum attrib = GL_VERTEX_ATTRIB_ARRAY_POINTER_ARB;
> -
> - switch (cap) {
> - case GL_VERTEX_ATTRIB_ARRAY_ENABLED_ARB:
> - retval = __glXGetArrayEnable(state, attrib, index, data);
> - break;
> -
> - case GL_VERTEX_ATTRIB_ARRAY_SIZE_ARB:
> - retval = __glXGetArraySize(state, attrib, index, data);
> - break;
> -
> - case GL_VERTEX_ATTRIB_ARRAY_STRIDE_ARB:
> - retval = __glXGetArrayStride(state, attrib, index, data);
> - break;
> -
Re: [Mesa-dev] [PATCH 07/11] glapi: Add the safe_{add, mul, pad} functions from xserver
On Mon, 2016-03-28 at 10:53 -0700, Ian Romanick wrote: > On 03/24/2016 11:10 AM, Adam Jackson wrote: > > +print 'if (a == 0 || b == 0) return 0;' > Is this check actually necessary? Yes because ... > > +print 'if (a > INT_MAX / b) return -1;' ... you don't want to divide by zero. - ajax ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 08/11] glapi: Harden GLX request size processing
On 03/24/2016 11:10 AM, Adam Jackson wrote:
> ---
> src/mapi/glapi/gen/glX_XML.py| 2 +-
> src/mapi/glapi/gen/glX_proto_recv.py | 2 --
> src/mapi/glapi/gen/glX_proto_send.py | 2 --
> src/mapi/glapi/gen/glX_proto_size.py | 24 +++-
> src/mapi/glapi/gen/gl_XML.py | 2 +-
> 5 files changed, 13 insertions(+), 19 deletions(-)
>
> diff --git a/src/mapi/glapi/gen/glX_XML.py b/src/mapi/glapi/gen/glX_XML.py
> index 166dbc1..3b833ee 100644
> --- a/src/mapi/glapi/gen/glX_XML.py
> +++ b/src/mapi/glapi/gen/glX_XML.py
> @@ -359,7 +359,7 @@ class glx_function(gl_XML.gl_function):
> # FIXME adds some extra diffs to the generated
> # FIXME code.
>
> -size_string = size_string + " + __GLX_PAD(%s)" %
> (p.size_string(1))
> +size_string = size_string + " + safe_pad(%s)" %
> (p.size_string(1))
>
> return size_string
>
> diff --git a/src/mapi/glapi/gen/glX_proto_recv.py
> b/src/mapi/glapi/gen/glX_proto_recv.py
> index 1cfa8c5..21b187c 100644
> --- a/src/mapi/glapi/gen/glX_proto_recv.py
> +++ b/src/mapi/glapi/gen/glX_proto_recv.py
> @@ -89,8 +89,6 @@ class
> PrintGlxDispatchFunctions(glX_proto_common.glx_print_proto):
> print '#include "indirect_util.h"'
> print '#include "singlesize.h"'
> print ''
> -print '#define __GLX_PAD(x) (((x) + 3) & ~3)'
I was going to suggest just changing the __GLX_PAD macro to use
safe_pad, but of course there are multiple definitions of __GLX_PAD. :(
> -print ''
> print 'typedef struct {'
> print '__GLX_PIXEL_3D_HDR;'
> print '} __GLXpixel3DHeader;'
> diff --git a/src/mapi/glapi/gen/glX_proto_send.py
> b/src/mapi/glapi/gen/glX_proto_send.py
> index 8b3d8d7..10abcff 100644
> --- a/src/mapi/glapi/gen/glX_proto_send.py
> +++ b/src/mapi/glapi/gen/glX_proto_send.py
> @@ -177,8 +177,6 @@ class
> PrintGlxProtoStubs(glX_proto_common.glx_print_proto):
> print '#include '
>
> print ''
> -print '#define __GLX_PAD(n) (((n) + 3) & ~3)'
> -print ''
> self.printFastcall()
> self.printNoinline()
> print ''
> diff --git a/src/mapi/glapi/gen/glX_proto_size.py
> b/src/mapi/glapi/gen/glX_proto_size.py
> index 75fc26f..828b726 100644
> --- a/src/mapi/glapi/gen/glX_proto_size.py
> +++ b/src/mapi/glapi/gen/glX_proto_size.py
> @@ -291,7 +291,7 @@ class glx_server_enum_function(glx_enum_function):
> print ''
> print 'compsize = __gl%s_size(%s);' % (f.name,
> string.join(f.count_parameter_list, ","))
> p = f.variable_length_parameter()
> -print 'return __GLX_PAD(%s);' % (p.size_string())
> +print 'return safe_pad(%s);' % (p.size_string())
>
> print '}'
> print ''
> @@ -428,7 +428,7 @@ class PrintGlxReqSize_h(PrintGlxReqSize_common):
def printBody(self, api):
> for func in api.functionIterateGlx():
> if not func.ignore and func.has_variable_size_request():
> -print 'extern PURE _X_HIDDEN int __glX%sReqSize(const GLbyte
> *pc, Bool swap);' % (func.name)
> +print 'extern PURE _X_HIDDEN int __glX%sReqSize(const GLbyte
> *pc, Bool swap, int reqlen);' % (func.name)
I don't see where reqlen is used. Did I miss something?
>
>
> class PrintGlxReqSize_c(PrintGlxReqSize_common):
> @@ -452,20 +452,18 @@ class PrintGlxReqSize_c(PrintGlxReqSize_common):
> print '#include "indirect_size.h"'
> print '#include "indirect_reqsize.h"'
> print ''
> -print '#define __GLX_PAD(x) (((x) + 3) & ~3)'
> -print ''
> print '#if defined(__CYGWIN__) || defined(__MINGW32__)'
> print '# undef HAVE_ALIAS'
> print '#endif'
> print '#ifdef HAVE_ALIAS'
> print '# define ALIAS2(from,to) \\'
> -print 'GLint __glX ## from ## ReqSize( const GLbyte * pc, Bool
> swap ) \\'
> +print 'GLint __glX ## from ## ReqSize( const GLbyte * pc, Bool
> swap, int reqlen ) \\'
Also, I'm in favor of fixing the spurious whitespace in this code. :)
> print '__attribute__ ((alias( # to )));'
> print '# define ALIAS(from,to) ALIAS2( from, __glX ## to ## ReqSize
> )'
> print '#else'
> print '# define ALIAS(from,to) \\'
> -print 'GLint __glX ## from ## ReqSize( const GLbyte * pc, Bool
> swap ) \\'
> -print '{ return __glX ## to ## ReqSize( pc, swap ); }'
> +print 'GLint __glX ## from ## ReqSize( const GLbyte * pc, Bool
> swap, int reqlen ) \\'
> +print '{ return __glX ## to ## ReqSize( pc, swap, reqlen ); }'
> print '#endif'
> print ''
> print ''
> @@ -547,7 +545,7 @@ class PrintGlxReqSize_c(PrintGlxReqSize_common):
>
> def common_func_print_just_header(self, f):
> print 'int'
> -print '__glX%sReqSize( const GLbyte *
Re: [Mesa-dev] [PATCH 06/11] glapi: Fix whitespace droppings when printing the license header
On 03/25/2016 05:33 PM, Dylan Baker wrote:
> Quoting Dylan Baker (2016-03-25 16:01:00)
>> Quoting Adam Jackson (2016-03-24 11:10:01)
>>> Signed-off-by: Adam Jackson
>>> ---
>>> src/mapi/glapi/gen/gl_XML.py | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/src/mapi/glapi/gen/gl_XML.py b/src/mapi/glapi/gen/gl_XML.py
>>> index 2e7123e..e11f6fc 100644
>>> --- a/src/mapi/glapi/gen/gl_XML.py
>>> +++ b/src/mapi/glapi/gen/gl_XML.py
>>> @@ -130,7 +130,7 @@ class gl_print_base(object):
>>> % (self.name)
>>> print ''
>>> print '/*'
>>> -print ' * ' + self.license.replace('\n', '\n * ')
>>> +print (' * ' + self.license.replace('\n', '\n * ')).replace(' \n',
>>> '\n')
>>
>> That's a brainful to parse, what about to stupid, but obvious solution:
>>
>> for l in self.license.split('\n'):
>> print ' * {0}'.format(l)
>
> Or, since mesa's python code seems to use C style formatters:
> print ' * %s' % l
Do those actually do the right thing? self.license is multiple lines of
text. The old code prefixes each line after the first line with ' * '.
I'm not sure how the dangling whitespace occurs in the first place. Is
it in the original license text? Could we just trim it there?
>>> print ' */'
>>> print ''
>>> if self.header_tag:
>>> --
>>> 2.5.0
>>>
>>> ___
>>> mesa-dev mailing list
>>> mesa-dev@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 11/11] glapi/glx: Mark the indirect swapped dispatch functions _X_COLD
Interesting... I had to look up what __attribute__('cold') did. Learn
something new every day...
This patch is
Reviewed-by: Ian Romanick
On 03/24/2016 11:10 AM, Adam Jackson wrote:
> A modest size savings:
>
>text data bss dec hex filename
> 264143 15608 232 279983 445af libglx.so.before
> 254303 15608 232 270143 41f3f libglx.so.after
>
> Signed-off-by: Adam Jackson
> ---
> src/mapi/glapi/gen/glX_proto_recv.py | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/src/mapi/glapi/gen/glX_proto_recv.py
> b/src/mapi/glapi/gen/glX_proto_recv.py
> index 7eb19df..9ef5206 100644
> --- a/src/mapi/glapi/gen/glX_proto_recv.py
> +++ b/src/mapi/glapi/gen/glX_proto_recv.py
> @@ -55,15 +55,15 @@ class PrintGlxDispatch_h(gl_XML.gl_print_base):
> if not func.ignore and not func.vectorequiv:
> if func.glx_rop:
> print 'extern _X_HIDDEN void __glXDisp_%s(GLbyte * pc);'
> % (func.name)
> -print 'extern _X_HIDDEN void __glXDispSwap_%s(GLbyte *
> pc);' % (func.name)
> +print 'extern _X_HIDDEN _X_COLD void
> __glXDispSwap_%s(GLbyte * pc);' % (func.name)
> elif func.glx_sop or func.glx_vendorpriv:
> print 'extern _X_HIDDEN int __glXDisp_%s(struct
> __GLXclientStateRec *, GLbyte *);' % (func.name)
> -print 'extern _X_HIDDEN int __glXDispSwap_%s(struct
> __GLXclientStateRec *, GLbyte *);' % (func.name)
> +print 'extern _X_HIDDEN _X_COLD int
> __glXDispSwap_%s(struct __GLXclientStateRec *, GLbyte *);' % (func.name)
>
> if func.glx_sop and func.glx_vendorpriv:
> n = func.glx_vendorpriv_names[0]
> print 'extern _X_HIDDEN int __glXDisp_%s(struct
> __GLXclientStateRec *, GLbyte *);' % (n)
> -print 'extern _X_HIDDEN int __glXDispSwap_%s(struct
> __GLXclientStateRec *, GLbyte *);' % (n)
> +print 'extern _X_HIDDEN _X_COLD int
> __glXDispSwap_%s(struct __GLXclientStateRec *, GLbyte *);' % (n)
>
> return
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 10/11] glapi/glx: Mark byteswap functions as _X_UNUSED
This patch is
Reviewed-by: Ian Romanick
On 03/24/2016 11:10 AM, Adam Jackson wrote:
> Squashes the one remaining warning in the xserver build.
>
> Signed-off-by: Adam Jackson
> ---
> src/mapi/glapi/gen/glX_proto_recv.py | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/mapi/glapi/gen/glX_proto_recv.py
> b/src/mapi/glapi/gen/glX_proto_recv.py
> index a138adb..7eb19df 100644
> --- a/src/mapi/glapi/gen/glX_proto_recv.py
> +++ b/src/mapi/glapi/gen/glX_proto_recv.py
> @@ -171,7 +171,7 @@ class
> PrintGlxDispatchFunctions(glX_proto_common.glx_print_proto):
> if t.glx_name not in already_done:
> real_name = self.real_types[t_size]
>
> -print 'static %s' % (t_name)
> +print 'static _X_UNUSED %s' % (t_name)
> print 'bswap_%s( const void * src )' % (t.glx_name)
I think this is also non-conventional whitespace. I'd be in favor of
fixing that too.
> print '{'
> print 'union { %s dst; %s ret; } x;' % (real_name,
> t_name)
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 09/11] glapi/glx: Sync some additional error checking from xserver
This patch is Reviewed-by: Ian Romanick On 03/24/2016 11:10 AM, Adam Jackson wrote: > Signed-off-by: Adam Jackson > --- > src/mapi/glapi/gen/glX_proto_recv.py | 4 > 1 file changed, 4 insertions(+) > > diff --git a/src/mapi/glapi/gen/glX_proto_recv.py > b/src/mapi/glapi/gen/glX_proto_recv.py > index 21b187c..a138adb 100644 > --- a/src/mapi/glapi/gen/glX_proto_recv.py > +++ b/src/mapi/glapi/gen/glX_proto_recv.py > @@ -435,6 +435,10 @@ class > PrintGlxDispatchFunctions(glX_proto_common.glx_print_proto): > print '%s %s = __glXGetAnswerBuffer(cl, %s%s, > answerBuffer, sizeof(answerBuffer), %u);' % (param.type_string(), param.name, > param.counter, size_scale, type_size) > answer_string = param.name > answer_count = param.counter > +print '' > +print 'if (%s == NULL) return BadAlloc;' % > (param.name) > +print '__glXClearErrorOccured();' > +print '' > elif c >= 1: > print '%s %s[%u];' % (answer_type, param.name, c) > answer_string = param.name > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 07/11] glapi: Add the safe_{add, mul, pad} functions from xserver
On 03/24/2016 11:10 AM, Adam Jackson wrote:
> We're about to update the generator scripts to use these, easier not to
> vary between client and server.
>
> Signed-off-by: Adam Jackson
> ---
> src/mapi/glapi/gen/glX_proto_send.py | 24
> 1 file changed, 24 insertions(+)
>
> diff --git a/src/mapi/glapi/gen/glX_proto_send.py
> b/src/mapi/glapi/gen/glX_proto_send.py
> index 2b33030..8b3d8d7 100644
> --- a/src/mapi/glapi/gen/glX_proto_send.py
> +++ b/src/mapi/glapi/gen/glX_proto_send.py
> @@ -174,6 +174,7 @@ class
> PrintGlxProtoStubs(glX_proto_common.glx_print_proto):
> print '#include '
> print '#include '
> print '#include '
> +print '#include '
>
> print ''
> print '#define __GLX_PAD(n) (((n) + 3) & ~3)'
> @@ -181,6 +182,29 @@ class
> PrintGlxProtoStubs(glX_proto_common.glx_print_proto):
> self.printFastcall()
> self.printNoinline()
> print ''
> +
> +print 'static _X_INLINE int safe_add(int a, int b)'
> +print '{'
> +print 'if (a < 0 || b < 0) return -1;'
> +print 'if (INT_MAX - a < b) return -1;'
> +print 'return a + b;'
> +print '}'
> +print 'static _X_INLINE int safe_mul(int a, int b)'
> +print '{'
> +print 'if (a < 0 || b < 0) return -1;'
> +print 'if (a == 0 || b == 0) return 0;'
Is this check actually necessary?
> +print 'if (a > INT_MAX / b) return -1;'
> +print 'return a * b;'
> +print '}'
> +print 'static _X_INLINE int safe_pad(int a)'
> +print '{'
> +print 'int ret;'
> +print 'if (a < 0) return -1;'
> +print 'if ((ret = safe_add(a, 3)) < 0) return -1;'
> +print 'return ret & (GLuint)~3;'
> +print '}'
> +print ''
> +
> print '#ifndef __GNUC__'
> print '# define __builtin_expect(x, y) x'
> print '#endif'
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 05/11] glapi/glx: Treat xserver generated targets as .PHONY
Come on! It's always fun to run a bunch of tests on the old code and wonder why nothing changed. This patch is Reviewed-by: Ian Romanick On 03/24/2016 11:10 AM, Adam Jackson wrote: > Meaning, always rebuild them when asked instead of bothering to look at > timestamps (and then wondering why nothing happened when you said make). > > Signed-off-by: Adam Jackson > --- > src/mapi/glapi/gen/Makefile.am | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/src/mapi/glapi/gen/Makefile.am b/src/mapi/glapi/gen/Makefile.am > index 1e34632..fff6805 100644 > --- a/src/mapi/glapi/gen/Makefile.am > +++ b/src/mapi/glapi/gen/Makefile.am > @@ -100,6 +100,8 @@ XORG_OUTPUTS = \ > $(XORG_GLX_DIR)/indirect_size_get.h \ > $(XORG_GLX_DIR)/indirect_table.c > > +.PHONY: $(XORG_OUTPUTS) > + > ## > > API_XML = \ > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 04/11] glapi/glx: Thunk non-ABI calls through GetProcAddress
This patch is
Reviewed-by: Ian Romanick
On 03/24/2016 11:09 AM, Adam Jackson wrote:
> Signed-off-by: Adam Jackson
> ---
> src/mapi/glapi/gen/glX_proto_recv.py | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/src/mapi/glapi/gen/glX_proto_recv.py
> b/src/mapi/glapi/gen/glX_proto_recv.py
> index 916da94..1cfa8c5 100644
> --- a/src/mapi/glapi/gen/glX_proto_recv.py
> +++ b/src/mapi/glapi/gen/glX_proto_recv.py
> @@ -117,6 +117,9 @@ class
> PrintGlxDispatchFunctions(glX_proto_common.glx_print_proto):
>
> return
>
> +def fptrType(self, name):
> + fptr = "pfngl" + name + "proc"
> + return fptr.upper()
>
> def printFunction(self, f, name):
> if (f.glx_sop or f.glx_vendorpriv) and (len(f.get_images()) != 0):
> @@ -134,6 +137,9 @@ class
> PrintGlxDispatchFunctions(glX_proto_common.glx_print_proto):
>
> print '{'
>
> +if not f.is_abi():
> +print '%s %s = __glGetProcAddress("gl%s");' %
> (self.fptrType(name), name, name)
> +
> if f.glx_rop or f.vectorequiv:
> self.printRenderFunction(f)
> elif f.glx_sop or f.glx_vendorpriv:
> @@ -218,6 +224,7 @@ class
> PrintGlxDispatchFunctions(glX_proto_common.glx_print_proto):
>
> def emit_function_call(self, f, retval_assign, indent):
> list = []
> +prefix = "gl" if f.is_abi() else ""
>
> for param in f.parameterIterator():
> if param.is_padding:
> @@ -230,8 +237,7 @@ class
> PrintGlxDispatchFunctions(glX_proto_common.glx_print_proto):
>
> list.append( '%s%s' % (indent, location) )
>
> -
> -print '%s%sgl%s(%s);' % (indent, retval_assign, f.name,
> string.join(list, ',\n'))
> +print '%s%s%s%s(%s);' % (indent, retval_assign, prefix, f.name,
> string.join(list, ',\n'))
>
>
> def common_func_print_just_start(self, f, indent):
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 02/11] glapi/glx: Emit direct GL calls instead of dispatch lookup
This patch is
Reviewed-by: Ian Romanick
On 03/24/2016 11:09 AM, Adam Jackson wrote:
> Signed-off-by: Adam Jackson
> ---
> src/mapi/glapi/gen/Makefile.am | 11 ---
> src/mapi/glapi/gen/glX_proto_recv.py | 33 ++---
> 2 files changed, 10 insertions(+), 34 deletions(-)
>
> diff --git a/src/mapi/glapi/gen/Makefile.am b/src/mapi/glapi/gen/Makefile.am
> index 0d5e408..1e34632 100644
> --- a/src/mapi/glapi/gen/Makefile.am
> +++ b/src/mapi/glapi/gen/Makefile.am
> @@ -89,18 +89,7 @@ EXTRA_DIST= \
> XORG_GLX_DIR = $(XORG_BASE)/glx
> XORG_GLAPI_DIR = $(XORG_BASE)/glx
>
> -XORG_GLAPI_OUTPUTS = \
> - $(XORG_GLAPI_DIR)/glprocs.h \
> - $(XORG_GLAPI_DIR)/glapitable.h \
> - $(XORG_GLAPI_DIR)/dispatch.h
> -
> -if HAVE_APPLEDRI
> -XORG_GLAPI_OUTPUTS += \
> - $(XORG_GLAPI_DIR)/glapi_gentable.c
> -endif
> -
> XORG_OUTPUTS = \
> - $(XORG_GLAPI_OUTPUTS) \
> $(XORG_GLX_DIR)/indirect_dispatch.c \
> $(XORG_GLX_DIR)/indirect_dispatch_swap.c \
> $(XORG_GLX_DIR)/indirect_dispatch.h \
> diff --git a/src/mapi/glapi/gen/glX_proto_recv.py
> b/src/mapi/glapi/gen/glX_proto_recv.py
> index 5d95f27..916da94 100644
> --- a/src/mapi/glapi/gen/glX_proto_recv.py
> +++ b/src/mapi/glapi/gen/glX_proto_recv.py
> @@ -80,21 +80,14 @@ class
> PrintGlxDispatchFunctions(glX_proto_common.glx_print_proto):
>
>
> def printRealHeader(self):
> -print '#include '
> -print '#include '
> -print '#include '
> -
> print '#include '
> +print '#include "glxserver.h"'
> print '#include "indirect_size.h"'
> print '#include "indirect_size_get.h"'
> print '#include "indirect_dispatch.h"'
> -print '#include "glxserver.h"'
> print '#include "glxbyteorder.h"'
> print '#include "indirect_util.h"'
> print '#include "singlesize.h"'
> -print '#include "glapi.h"'
> -print '#include "glapitable.h"'
> -print '#include "dispatch.h"'
> print ''
> print '#define __GLX_PAD(x) (((x) + 3) & ~3)'
> print ''
> @@ -238,13 +231,7 @@ class
> PrintGlxDispatchFunctions(glX_proto_common.glx_print_proto):
> list.append( '%s%s' % (indent, location) )
>
>
> -if len( list ):
> -print '%s%sCALL_%s( GET_DISPATCH(), (' % (indent,
> retval_assign, f.name)
> -print string.join( list, ",\n" )
> -print '%s) );' % (indent)
> -else:
> -print '%s%sCALL_%s( GET_DISPATCH(), () );' % (indent,
> retval_assign, f.name)
> -return
> +print '%s%sgl%s(%s);' % (indent, retval_assign, f.name,
> string.join(list, ',\n'))
>
>
> def common_func_print_just_start(self, f, indent):
> @@ -507,18 +494,18 @@ class
> PrintGlxDispatchFunctions(glX_proto_common.glx_print_proto):
> # the must NEVER be byte-swapped.
>
> if not (img.img_type == "GL_BITMAP" and img.img_format ==
> "GL_COLOR_INDEX"):
> -print 'CALL_PixelStorei( GET_DISPATCH(),
> (GL_UNPACK_SWAP_BYTES, hdr->swapBytes) );'
> +print 'glPixelStorei(GL_UNPACK_SWAP_BYTES,
> hdr->swapBytes);'
>
> -print 'CALL_PixelStorei( GET_DISPATCH(),
> (GL_UNPACK_LSB_FIRST,hdr->lsbFirst) );'
> +print 'glPixelStorei(GL_UNPACK_LSB_FIRST, hdr->lsbFirst);'
>
> -print 'CALL_PixelStorei( GET_DISPATCH(),
> (GL_UNPACK_ROW_LENGTH, (GLint) %shdr->rowLength%s) );' % (pre, post)
> +print 'glPixelStorei(GL_UNPACK_ROW_LENGTH, (GLint)
> %shdr->rowLength%s);' % (pre, post)
> if img.depth:
> -print 'CALL_PixelStorei( GET_DISPATCH(),
> (GL_UNPACK_IMAGE_HEIGHT, (GLint) %shdr->imageHeight%s) );' % (pre, post)
> -print 'CALL_PixelStorei( GET_DISPATCH(),
> (GL_UNPACK_SKIP_ROWS,(GLint) %shdr->skipRows%s) );' % (pre, post)
> +print 'glPixelStorei(GL_UNPACK_IMAGE_HEIGHT, (GLint)
> %shdr->imageHeight%s);' % (pre, post)
> +print 'glPixelStorei(GL_UNPACK_SKIP_ROWS, (GLint)
> %shdr->skipRows%s);' % (pre, post)
> if img.depth:
> -print 'CALL_PixelStorei( GET_DISPATCH(),
> (GL_UNPACK_SKIP_IMAGES, (GLint) %shdr->skipImages%s) );' % (pre, post)
> -print 'CALL_PixelStorei( GET_DISPATCH(),
> (GL_UNPACK_SKIP_PIXELS, (GLint) %shdr->skipPixels%s) );' % (pre, post)
> -print 'CALL_PixelStorei( GET_DISPATCH(),
> (GL_UNPACK_ALIGNMENT,(GLint) %shdr->alignment%s) );' % (pre, post)
> +print 'glPixelStorei(GL_UNPACK_SKIP_IMAGES, (GLint)
> %shdr->skipImages%s);' % (pre, post)
> +print 'glPixelStorei(GL_UNPACK_SKIP_PIXELS, (GLint)
> %shdr->skipPixels%s);' % (pre, post)
> +print 'glPixelStorei(GL_UNPACK_ALIGNMENT, (GLint)
> %shdr->alignment%s);' % (pre, post)
> print ''
>
Re: [Mesa-dev] [PATCH 1/4] mesa: properly return GetTexLevelParameter queries for buffer textures
On 03/28/2016 10:38 AM, Ilia Mirkin wrote:
On Mon, Mar 28, 2016 at 12:31 PM, Brian Paul wrote:
On 03/28/2016 10:20 AM, Ilia Mirkin wrote:
Thanks! On the off chance you're in the mood for reviewing the rest of
the series but it's lost in your inbox, you can find it here:
https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.freedesktop.org_series_3887_&d=BQIFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=T0t4QG7chq2ZwJo6wilkFznRSFy-8uDKartPGbomVj8&m=0xRgcNjzm9L4CxMt1DG9coPwumjYve81_bkYgcQA6-0&s=_fp9_BM7DpwjSOJAM3dQIDF02eQ7DCBbJxs8Yl8PsxE&e=
The later patches actually pipe through GL_EXT/OES_texture_buffer
support so that the dEQP tests can run on mesa. (All the current dEQP
tests are around AEP, so they like the EXT variants.)
Overall, the series looks OK to me. But I have a question.
GL_OES/EXT_texture_buffer is only for ES, right? In the GLSL code, don't we
have to check for that, in addition to the GLSL version? I'm looking at
your new texture_buffer() helper function in
src/compiler/glsl/builtin_functions.cpp
Reviewed-by: Brian Paul
Presumably you're referring to
static bool
+texture_buffer(const _mesa_glsl_parse_state *state)
+{
+ return state->is_version(140, 320) ||
+ state->EXT_texture_buffer_enable ||
+ state->OES_texture_buffer_enable;
+}
and the question is whether this shouldn't be more like
state->es_shader && state->EXT_foo_enable?
If so, I don't think so. Those exts are marked as ES-only in the
_mesa_glsl_supported_extensions (glsl_parser_extras.cpp), which means
that they should only be enable-able from an ES shader. So if you're
in a non-ES shader, those two enables should always be false (or else
we have larger problems).
Does that address your concern?
Yes, thanks.
-Brian
I guess there's a question here of what happens if you write a ESSL
1.0 shader and enable those exts (which require ESSL 3.10)... I think
it's supposed to fail, but mesa will be none the wiser and expose the
relevant functionality. The ext definitions in glsl_parser_extras
should probably have minimum GL/GLES versions, but those don't exist
right now. IMHO this isn't such a big deal.
-ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] mesa: properly return GetTexLevelParameter queries for buffer textures
On Mon, Mar 28, 2016 at 12:31 PM, Brian Paul wrote:
> On 03/28/2016 10:20 AM, Ilia Mirkin wrote:
>>
>> Thanks! On the off chance you're in the mood for reviewing the rest of
>> the series but it's lost in your inbox, you can find it here:
>>
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.freedesktop.org_series_3887_&d=BQIFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=T0t4QG7chq2ZwJo6wilkFznRSFy-8uDKartPGbomVj8&m=0xRgcNjzm9L4CxMt1DG9coPwumjYve81_bkYgcQA6-0&s=_fp9_BM7DpwjSOJAM3dQIDF02eQ7DCBbJxs8Yl8PsxE&e=
>>
>> The later patches actually pipe through GL_EXT/OES_texture_buffer
>> support so that the dEQP tests can run on mesa. (All the current dEQP
>> tests are around AEP, so they like the EXT variants.)
>
>
>
> Overall, the series looks OK to me. But I have a question.
> GL_OES/EXT_texture_buffer is only for ES, right? In the GLSL code, don't we
> have to check for that, in addition to the GLSL version? I'm looking at
> your new texture_buffer() helper function in
> src/compiler/glsl/builtin_functions.cpp
>
> Reviewed-by: Brian Paul
>
Presumably you're referring to
static bool
+texture_buffer(const _mesa_glsl_parse_state *state)
+{
+ return state->is_version(140, 320) ||
+ state->EXT_texture_buffer_enable ||
+ state->OES_texture_buffer_enable;
+}
and the question is whether this shouldn't be more like
state->es_shader && state->EXT_foo_enable?
If so, I don't think so. Those exts are marked as ES-only in the
_mesa_glsl_supported_extensions (glsl_parser_extras.cpp), which means
that they should only be enable-able from an ES shader. So if you're
in a non-ES shader, those two enables should always be false (or else
we have larger problems).
Does that address your concern?
I guess there's a question here of what happens if you write a ESSL
1.0 shader and enable those exts (which require ESSL 3.10)... I think
it's supposed to fail, but mesa will be none the wiser and expose the
relevant functionality. The ext definitions in glsl_parser_extras
should probably have minimum GL/GLES versions, but those don't exist
right now. IMHO this isn't such a big deal.
-ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [android-x86-devel] Re: gralloc_drm_pipe
On Fri, Mar 25, 2016 at 8:38 PM, Stéphane Marchesin wrote: > On Wed, Mar 23, 2016 at 5:22 PM, Rob Herring wrote: >> On Fri, Mar 4, 2016 at 12:07 PM, Rob Clark wrote: >>> On Fri, Mar 4, 2016 at 12:59 PM, Rob Clark wrote: So, I've been advocating that for android, gallium drivers use gralloc_drm_pipe, since with android it seems like you end up with both gralloc and libGL in the same process, and having both share the same pipe_screen avoids lots of headaches with multiple gem handles pointing to same underlying buffer. But the awkward thing is that gralloc_drm_pipe is using gallium APIs that aren't particularly intended to be used out-of-tree. Ie. not really stable APIs. At the time, the thing that made sense to me was to pull drm_gralloc into mesa. But at the time, there were no non-mesa users of drm_gralloc, which isn't really true anymore. Maybe what makes more sense now is to implement a gralloc state tracker, which exposes a stable API for drm_gralloc? It would mostly be a shim to expose gallium import/export/transfer APIs in a stable way, but would also be where the code that figures out which driver to use to create/get the pipe_screen. >>> >>> and actually, we might just be able to use XA state tracker for this.. >>> I think it exposes all the necessary import/export/etc stuff that >>> gralloc would need.. >> >> Rob and I discussed this a bit more F2F recently. An alternative we >> discussed would be using GBM instead. GBM seems more inline with >> gralloc needs. This would also have the advantage of working with >> minigbm as well for non-mesa cases. Any thoughts on GBM vs. XA? > > gbm as it is misses some bits, for example lock/unlock, and more fine > grained usage flags. I think this can be implemented on top within gralloc as it is today with drm_gralloc. However, I found a bigger mismatch is there are no explicit map/unmap calls in GBM. A writeable buffer will be a dumb buffer and is implicitly mapped. Maybe that is enough in reality? Rob ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa/st: Fix NULL access if no fragment shader is bound
This can happen when using glDispatchCompute while having only a
compute shader bound.
As far as I can see st_upload_constants is only called with
shader_type = PIPE_SHADER_FRAGMENT if st->fp is not null, and in other
calls the second part of the if condition does not get executed.
- Bas
On Mon, Mar 28, 2016 at 6:05 PM, Miklós Máté wrote:
> On 03/28/2016 05:01 PM, Bas Nieuwenhuizen wrote:
>>
>> Signed-off-by: Bas Nieuwenhuizen
>> ---
>> src/mesa/state_tracker/st_atom_constbuf.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/mesa/state_tracker/st_atom_constbuf.c
>> b/src/mesa/state_tracker/st_atom_constbuf.c
>> index 4d9b344..a980dbe 100644
>> --- a/src/mesa/state_tracker/st_atom_constbuf.c
>> +++ b/src/mesa/state_tracker/st_atom_constbuf.c
>> @@ -65,8 +65,8 @@ void st_upload_constants( struct st_context *st,
>> shader_type == PIPE_SHADER_COMPUTE);
>>/* update the ATI constants before rendering */
>> - struct ati_fragment_shader *ati_fs = st->fp->ati_fs;
>> - if (shader_type == PIPE_SHADER_FRAGMENT && ati_fs) {
>> + if (shader_type == PIPE_SHADER_FRAGMENT && st->fp->ati_fs) {
>> + struct ati_fragment_shader *ati_fs = st->fp->ati_fs;
>> unsigned c;
>> for (c = 0; c < MAX_NUM_FRAGMENT_CONSTANTS_ATI; c++) {
>
>
> Could you please provide a test program that demonstrates the NULL access?
> AFAIK st->fp is either a user-supplied
> shader or a shader that implements the fixed-function fragment operation,
> and I don't know how it could be NULL.
> BTW if st->fp is NULL, then this segfaults even after your change.
>
> MM
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] mesa: properly return GetTexLevelParameter queries for buffer textures
Reviewed-by: Brian Paul
On 03/27/2016 09:19 AM, Ilia Mirkin wrote:
1-month ping
dEQP has a number of tests both for texture buffers, as well as image
buffers. would be nice to have access to those.
-ilia
On Sat, Feb 27, 2016 at 4:29 PM, Ilia Mirkin wrote:
This fixes all failures with dEQP tests in this area. While
ARB_texture_buffer_object explicitly says that GetTexLevelParameter & co
should not be supported, GL 3.1 reverses this decision and allows all of
these queries there.
Conversely, there is no text that forbids the buffer-specific queries
from being used with non-buffer images.
Signed-off-by: Ilia Mirkin
---
src/mesa/main/texparam.c | 54 ++--
1 file changed, 52 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/texparam.c b/src/mesa/main/texparam.c
index 3b769f4..9d94636 100644
--- a/src/mesa/main/texparam.c
+++ b/src/mesa/main/texparam.c
@@ -1447,6 +1447,29 @@ get_tex_level_parameter_image(struct gl_context *ctx,
*params = img->FixedSampleLocations;
break;
+ /* There is never a buffer data store here, but these pnames still have
+ * to work.
+ */
+
+ /* GL_ARB_texture_buffer_object */
+ case GL_TEXTURE_BUFFER_DATA_STORE_BINDING:
+ if (!ctx->Extensions.ARB_texture_buffer_object)
+goto invalid_pname;
+ *params = 0;
+ break;
+
+ /* GL_ARB_texture_buffer_range */
+ case GL_TEXTURE_BUFFER_OFFSET:
+ if (!ctx->Extensions.ARB_texture_buffer_range)
+goto invalid_pname;
+ *params = 0;
+ break;
+ case GL_TEXTURE_BUFFER_SIZE:
+ if (!ctx->Extensions.ARB_texture_buffer_range)
+goto invalid_pname;
+ *params = 0;
+ break;
+
default:
goto invalid_pname;
}
@@ -1468,13 +1491,24 @@ get_tex_level_parameter_buffer(struct gl_context *ctx,
{
const struct gl_buffer_object *bo = texObj->BufferObject;
mesa_format texFormat = texObj->_BufferObjectFormat;
+ int bytes = MAX2(1, _mesa_get_format_bytes(texFormat));
GLenum internalFormat = texObj->BufferObjectFormat;
GLenum baseFormat = _mesa_get_format_base_format(texFormat);
const char *suffix = dsa ? "ture" : "";
if (!bo) {
/* undefined texture buffer object */
- *params = pname == GL_TEXTURE_COMPONENTS ? 1 : 0;
+ switch (pname) {
+ case GL_TEXTURE_FIXED_SAMPLE_LOCATIONS:
+ *params = GL_TRUE;
+ break;
+ case GL_TEXTURE_INTERNAL_FORMAT:
+ *params = internalFormat;
+ break;
+ default:
+ *params = 0;
+ break;
+ }
return;
}
@@ -1483,10 +1517,13 @@ get_tex_level_parameter_buffer(struct gl_context *ctx,
*params = bo->Name;
break;
case GL_TEXTURE_WIDTH:
- *params = bo->Size;
+ *params = ((texObj->BufferSize == -1) ? bo->Size : texObj->BufferSize)
+/ bytes;
break;
case GL_TEXTURE_HEIGHT:
case GL_TEXTURE_DEPTH:
+ *params = 1;
+ break;
case GL_TEXTURE_BORDER:
case GL_TEXTURE_SHARED_SIZE:
case GL_TEXTURE_COMPRESSED:
@@ -1536,6 +1573,19 @@ get_tex_level_parameter_buffer(struct gl_context *ctx,
*params = (texObj->BufferSize == -1) ? bo->Size : texObj->BufferSize;
break;
+ /* GL_ARB_texture_multisample */
+ case GL_TEXTURE_SAMPLES:
+ if (!ctx->Extensions.ARB_texture_multisample)
+goto invalid_pname;
+ *params = 0;
+ break;
+
+ case GL_TEXTURE_FIXED_SAMPLE_LOCATIONS:
+ if (!ctx->Extensions.ARB_texture_multisample)
+goto invalid_pname;
+ *params = GL_TRUE;
+ break;
+
/* GL_ARB_texture_compression */
case GL_TEXTURE_COMPRESSED_IMAGE_SIZE:
/* Always illegal for GL_TEXTURE_BUFFER */
--
2.4.10
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev&d=BQIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=T0t4QG7chq2ZwJo6wilkFznRSFy-8uDKartPGbomVj8&m=NBqjQGyb73UPGPIVz1-hfSm0zb9WfWbc0gjTvrJ8JVI&s=ZJrAJ2tGof3duwSP9XUKgHl1MOlcHSdbEvNLADuhvA0&e=
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa/st: Fix NULL access if no fragment shader is bound
On 03/28/2016 05:01 PM, Bas Nieuwenhuizen wrote:
Signed-off-by: Bas Nieuwenhuizen
---
src/mesa/state_tracker/st_atom_constbuf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/state_tracker/st_atom_constbuf.c
b/src/mesa/state_tracker/st_atom_constbuf.c
index 4d9b344..a980dbe 100644
--- a/src/mesa/state_tracker/st_atom_constbuf.c
+++ b/src/mesa/state_tracker/st_atom_constbuf.c
@@ -65,8 +65,8 @@ void st_upload_constants( struct st_context *st,
shader_type == PIPE_SHADER_COMPUTE);
/* update the ATI constants before rendering */
- struct ati_fragment_shader *ati_fs = st->fp->ati_fs;
- if (shader_type == PIPE_SHADER_FRAGMENT && ati_fs) {
+ if (shader_type == PIPE_SHADER_FRAGMENT && st->fp->ati_fs) {
+ struct ati_fragment_shader *ati_fs = st->fp->ati_fs;
unsigned c;
for (c = 0; c < MAX_NUM_FRAGMENT_CONSTANTS_ATI; c++) {
Could you please provide a test program that demonstrates the NULL
access? AFAIK st->fp is either a user-supplied
shader or a shader that implements the fixed-function fragment
operation, and I don't know how it could be NULL.
BTW if st->fp is NULL, then this segfaults even after your change.
MM
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa/st: Fix NULL access if no fragment shader is bound
Pushed, thanks.
Marek
On Mon, Mar 28, 2016 at 5:01 PM, Bas Nieuwenhuizen
wrote:
> Signed-off-by: Bas Nieuwenhuizen
> ---
> src/mesa/state_tracker/st_atom_constbuf.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_atom_constbuf.c
> b/src/mesa/state_tracker/st_atom_constbuf.c
> index 4d9b344..a980dbe 100644
> --- a/src/mesa/state_tracker/st_atom_constbuf.c
> +++ b/src/mesa/state_tracker/st_atom_constbuf.c
> @@ -65,8 +65,8 @@ void st_upload_constants( struct st_context *st,
>shader_type == PIPE_SHADER_COMPUTE);
>
> /* update the ATI constants before rendering */
> - struct ati_fragment_shader *ati_fs = st->fp->ati_fs;
> - if (shader_type == PIPE_SHADER_FRAGMENT && ati_fs) {
> + if (shader_type == PIPE_SHADER_FRAGMENT && st->fp->ati_fs) {
> + struct ati_fragment_shader *ati_fs = st->fp->ati_fs;
>unsigned c;
>
>for (c = 0; c < MAX_NUM_FRAGMENT_CONSTANTS_ATI; c++) {
> --
> 2.7.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa/st: Fix NULL access if no fragment shader is bound
Signed-off-by: Bas Nieuwenhuizen
---
src/mesa/state_tracker/st_atom_constbuf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/state_tracker/st_atom_constbuf.c
b/src/mesa/state_tracker/st_atom_constbuf.c
index 4d9b344..a980dbe 100644
--- a/src/mesa/state_tracker/st_atom_constbuf.c
+++ b/src/mesa/state_tracker/st_atom_constbuf.c
@@ -65,8 +65,8 @@ void st_upload_constants( struct st_context *st,
shader_type == PIPE_SHADER_COMPUTE);
/* update the ATI constants before rendering */
- struct ati_fragment_shader *ati_fs = st->fp->ati_fs;
- if (shader_type == PIPE_SHADER_FRAGMENT && ati_fs) {
+ if (shader_type == PIPE_SHADER_FRAGMENT && st->fp->ati_fs) {
+ struct ati_fragment_shader *ati_fs = st->fp->ati_fs;
unsigned c;
for (c = 0; c < MAX_NUM_FRAGMENT_CONSTANTS_ATI; c++) {
--
2.7.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: remove initialized field from uniform storage
On 03/26/2016 09:51 PM, Timothy Arceri wrote:
The only place this was used was in a gallium debug function that
had to be manually enabled.
I think used this years ago to debug something or other. I guess I can
re-apply it if I ever need it again.
Reviewed-by: Brian Paul
---
src/compiler/glsl/ir_uniform.h | 5
src/compiler/glsl/link_uniform_initializers.cpp | 4 ---
src/compiler/glsl/link_uniforms.cpp | 1 -
src/mesa/main/shaderapi.c | 3 +-
src/mesa/main/uniform_query.cpp | 4 ---
src/mesa/state_tracker/st_draw.c| 37 -
6 files changed, 1 insertion(+), 53 deletions(-)
diff --git a/src/compiler/glsl/ir_uniform.h b/src/compiler/glsl/ir_uniform.h
index 1854279..e72e7b4 100644
--- a/src/compiler/glsl/ir_uniform.h
+++ b/src/compiler/glsl/ir_uniform.h
@@ -105,11 +105,6 @@ struct gl_uniform_storage {
*/
unsigned array_elements;
- /**
-* Has this uniform ever been set?
-*/
- bool initialized;
-
struct gl_opaque_uniform_index opaque[MESA_SHADER_STAGES];
/**
diff --git a/src/compiler/glsl/link_uniform_initializers.cpp
b/src/compiler/glsl/link_uniform_initializers.cpp
index 7d280cc..870bc5b 100644
--- a/src/compiler/glsl/link_uniform_initializers.cpp
+++ b/src/compiler/glsl/link_uniform_initializers.cpp
@@ -162,8 +162,6 @@ set_opaque_binding(void *mem_ctx, gl_shader_program *prog,
}
}
}
-
- storage->initialized = true;
}
}
@@ -267,8 +265,6 @@ set_uniform_initializer(void *mem_ctx, gl_shader_program
*prog,
}
}
}
-
- storage->initialized = true;
}
}
diff --git a/src/compiler/glsl/link_uniforms.cpp
b/src/compiler/glsl/link_uniforms.cpp
index 09322c5..a16b34a 100644
--- a/src/compiler/glsl/link_uniforms.cpp
+++ b/src/compiler/glsl/link_uniforms.cpp
@@ -799,7 +799,6 @@ private:
this->uniforms[id].name = ralloc_strdup(this->uniforms, name);
this->uniforms[id].type = base_type;
- this->uniforms[id].initialized = 0;
this->uniforms[id].num_driver_storage = 0;
this->uniforms[id].driver_storage = NULL;
this->uniforms[id].atomic_buffer_index = -1;
diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
index 5b882d6..92302f6 100644
--- a/src/mesa/main/shaderapi.c
+++ b/src/mesa/main/shaderapi.c
@@ -2568,7 +2568,6 @@ _mesa_UniformSubroutinesuiv(GLenum shadertype, GLsizei
count,
memcpy(&uni->storage[0], &indices[i],
sizeof(GLuint) * uni_count);
- uni->initialized = true;
_mesa_propagate_uniforms_to_driver_storage(uni, 0, uni_count);
i += uni_count;
} while(i < count);
@@ -2742,7 +2741,7 @@ _mesa_shader_init_subroutine_defaults(struct gl_shader
*sh)
for (j = 0; j < uni_count; j++)
memcpy(&uni->storage[j], &val, sizeof(int));
- uni->initialized = true;
+
_mesa_propagate_uniforms_to_driver_storage(uni, 0, uni_count);
}
}
diff --git a/src/mesa/main/uniform_query.cpp b/src/mesa/main/uniform_query.cpp
index 2ced201..ab5c3cd 100644
--- a/src/mesa/main/uniform_query.cpp
+++ b/src/mesa/main/uniform_query.cpp
@@ -815,8 +815,6 @@ _mesa_uniform(struct gl_context *ctx, struct
gl_shader_program *shProg,
}
}
- uni->initialized = true;
-
_mesa_propagate_uniforms_to_driver_storage(uni, offset, count);
/* If the uniform is a sampler, do the extra magic necessary to propagate
@@ -1030,8 +1028,6 @@ _mesa_uniform_matrix(struct gl_context *ctx, struct
gl_shader_program *shProg,
}
}
- uni->initialized = true;
-
_mesa_propagate_uniforms_to_driver_storage(uni, offset, count);
}
diff --git a/src/mesa/state_tracker/st_draw.c b/src/mesa/state_tracker/st_draw.c
index fdd59a3..3db5749 100644
--- a/src/mesa/state_tracker/st_draw.c
+++ b/src/mesa/state_tracker/st_draw.c
@@ -127,35 +127,6 @@ setup_index_buffer(struct st_context *st,
/**
- * Prior to drawing, check that any uniforms referenced by the
- * current shader have been set. If a uniform has not been set,
- * issue a warning.
- */
-static void
-check_uniforms(struct gl_context *ctx)
-{
- struct gl_shader_program **shProg = ctx->_Shader->CurrentProgram;
- unsigned j;
-
- for (j = 0; j < 3; j++) {
- unsigned i;
-
- if (shProg[j] == NULL || !shProg[j]->LinkStatus)
-continue;
-
- for (i = 0; i < shProg[j]->NumUniformStorage; i++) {
- const struct gl_uniform_storage *u = &shProg[j]->UniformStorage[i];
- if (!u->initialized) {
-_mesa_warning(ctx,
- "Using shader with uninitialized uniform: %s",
- u->name);
- }
- }
- }
-}
-
-
-/**
* Translate OpenGL primtive type (GL_POINTS, GL_TRIANGLE_STRIP, etc) to
* the corresponding Gallium type.
*/
@@ -203,14 +174,6 @@ st_draw_vbo(struct gl_context *ctx,
/* Validate state. */
if (st
Re: [Mesa-dev] [PATCH] mesa/st: Avoid a NULL-ptr dereference on possible missing callback
Determinism is always better regardless of how you get there. A null pointer deference `on purpose` is a really poor idea in C. I am somewhat surprised you are asking if its really better to rely on undefined behavior vs. an assert. I thought about using a if branch and just returning but I think it is better to crash deterministically with a reason rather than perhaps fail silently. Although I do see in other places a if branch and a return was used in similar situations so I would be willing to do the same if I must. On 2016-03-28 16:08, Ilia Mirkin wrote: When would that happen? When a user force-enables ARB_query_buffer_object for a driver that's not ready for it? Is hitting a deterministic assert in that case any better than hitting a null deref? On Sun, Mar 27, 2016 at 11:52 PM, Edward O'Callaghan wrote: Just because we miss a gallium driver callback don't dereference invalid memory. Signed-off-by: Edward O'Callaghan --- src/mesa/state_tracker/st_cb_queryobj.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/mesa/state_tracker/st_cb_queryobj.c b/src/mesa/state_tracker/st_cb_queryobj.c index cdb9efc..e9abc38 100644 --- a/src/mesa/state_tracker/st_cb_queryobj.c +++ b/src/mesa/state_tracker/st_cb_queryobj.c @@ -402,6 +402,7 @@ st_StoreQueryResult(struct gl_context *ctx, struct gl_query_object *q, index = 0; } + assert(pipe->get_query_result_resource); pipe->get_query_result_resource(pipe, stq->pq, wait, result_type, index, stObj->buffer, offset); } -- 2.5.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] nvc0: use a different offset for buffers and surfaces
To not overwrite buffers and surfaces information, we need to use
a different offset in the driver constant buffer. Currently, OP_SUQ
is only supported for buffers but this will be slightly updated for
images support.
Signed-off-by: Samuel Pitoiset
---
.../drivers/nouveau/codegen/nv50_ir_driver.h | 1 +
.../nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 81 --
.../nouveau/codegen/nv50_ir_lowering_nvc0.h| 12 +++-
src/gallium/drivers/nouveau/nvc0/nvc0_program.c| 8 ++-
4 files changed, 74 insertions(+), 28 deletions(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h
b/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h
index 21523a2..54c53c9 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h
@@ -177,6 +177,7 @@ struct nv50_ir_prog_info
bool nv50styleSurfaces;/* generate gX[] access for raw buffers */
uint16_t texBindBase; /* base address for tex handles (nve4) */
uint16_t suInfoBase; /* base address for surface info (nve4) */
+ uint16_t bufInfoBase; /* base address for buffer info */
uint16_t sampleInfoBase; /* base address for sample positions */
uint8_t msInfoCBSlot; /* cX[] used for multisample info */
uint16_t msInfoBase; /* base address for multisample info */
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
index e8f8e30..d293330 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
@@ -1063,7 +1063,7 @@ bool
NVC0LoweringPass::handleSUQ(Instruction *suq)
{
suq->op = OP_MOV;
- suq->setSrc(0, loadResLength32(suq->getIndirect(0, 1),
+ suq->setSrc(0, loadBufLength32(suq->getIndirect(0, 1),
suq->getSrc(0)->reg.fileIndex * 16));
suq->setIndirect(0, 0, NULL);
suq->setIndirect(0, 1, NULL);
@@ -1180,7 +1180,7 @@ NVC0LoweringPass::handleATOM(Instruction *atom)
return true;
default:
assert(atom->src(0).getFile() == FILE_MEMORY_GLOBAL);
- base = loadResInfo64(ind, atom->getSrc(0)->reg.fileIndex * 16);
+ base = loadBufInfo64(ind, atom->getSrc(0)->reg.fileIndex * 16);
assert(base->reg.size == 8);
if (ptr)
base = bld.mkOp2v(OP_ADD, TYPE_U64, base, base, ptr);
@@ -1240,19 +1240,20 @@ NVC0LoweringPass::handleCasExch(Instruction *cas, bool
needCctl)
}
inline Value *
-NVC0LoweringPass::loadResInfo32(Value *ptr, uint32_t off)
+NVC0LoweringPass::loadResInfo32(Value *ptr, uint32_t off, uint16_t base)
{
uint8_t b = prog->driver->io.auxCBSlot;
- off += prog->driver->io.suInfoBase;
+ off += base;
+
return bld.
mkLoadv(TYPE_U32, bld.mkSymbol(FILE_MEMORY_CONST, b, TYPE_U32, off),
ptr);
}
inline Value *
-NVC0LoweringPass::loadResInfo64(Value *ptr, uint32_t off)
+NVC0LoweringPass::loadResInfo64(Value *ptr, uint32_t off, uint16_t base)
{
uint8_t b = prog->driver->io.auxCBSlot;
- off += prog->driver->io.suInfoBase;
+ off += base;
if (ptr)
ptr = bld.mkOp2v(OP_SHL, TYPE_U32, bld.getScratch(), ptr, bld.mkImm(4));
@@ -1262,10 +1263,10 @@ NVC0LoweringPass::loadResInfo64(Value *ptr, uint32_t
off)
}
inline Value *
-NVC0LoweringPass::loadResLength32(Value *ptr, uint32_t off)
+NVC0LoweringPass::loadResLength32(Value *ptr, uint32_t off, uint16_t base)
{
uint8_t b = prog->driver->io.auxCBSlot;
- off += prog->driver->io.suInfoBase;
+ off += base;
if (ptr)
ptr = bld.mkOp2v(OP_SHL, TYPE_U32, bld.getScratch(), ptr, bld.mkImm(4));
@@ -1275,6 +1276,42 @@ NVC0LoweringPass::loadResLength32(Value *ptr, uint32_t
off)
}
inline Value *
+NVC0LoweringPass::loadSuInfo32(Value *ptr, uint32_t off)
+{
+ return loadResInfo32(ptr, off, prog->driver->io.suInfoBase);
+}
+
+inline Value *
+NVC0LoweringPass::loadSuInfo64(Value *ptr, uint32_t off)
+{
+ return loadResInfo64(ptr, off, prog->driver->io.suInfoBase);
+}
+
+inline Value *
+NVC0LoweringPass::loadSuLength32(Value *ptr, uint32_t off)
+{
+ return loadResLength32(ptr, off, prog->driver->io.suInfoBase);
+}
+
+inline Value *
+NVC0LoweringPass::loadBufInfo32(Value *ptr, uint32_t off)
+{
+ return loadResInfo32(ptr, off, prog->driver->io.bufInfoBase);
+}
+
+inline Value *
+NVC0LoweringPass::loadBufInfo64(Value *ptr, uint32_t off)
+{
+ return loadResInfo64(ptr, off, prog->driver->io.bufInfoBase);
+}
+
+inline Value *
+NVC0LoweringPass::loadBufLength32(Value *ptr, uint32_t off)
+{
+ return loadResLength32(ptr, off, prog->driver->io.bufInfoBase);
+}
+
+inline Value *
NVC0LoweringPass::loadMsInfo32(Value *ptr, uint32_t off)
{
uint8_t b = prog->driver->io.msInfoCBSlot;
@@ -1354,8 +1391,8 @@ NVC0LoweringPass::adjustCoordinatesMS(TexInstruction *tex)
Value *tx = bld.getSSA(), *ty = bld.getSSA(), *ts = bld.getSSA();
-
[Mesa-dev] [PATCH] r600g: fix and optimize tgsi_cmp when using ABS and NEG modifier
From: Patrick Rudolph
Some apps set NEG and ABS on the source param to test for zero.
Use ALU_OP3_CNDE insted of ALU_OP3_CNDGE and unset both modifiers.
It also removes the need for a MOV instruction, as ABS isn't
supported on op3.
Tested on AMD CAYMAN and AMD RV770.
Signed-off-by: Patrick Rudolph
---
src/gallium/drivers/r600/r600_shader.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/r600_shader.c
b/src/gallium/drivers/r600/r600_shader.c
index 77658f5..e5e2e3f 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -7707,6 +7707,15 @@ static int tgsi_cmp(struct r600_shader_ctx *ctx)
int i, r, j;
int lasti = tgsi_last_instruction(inst->Dst[0].Register.WriteMask);
int temp_regs[3];
+ unsigned op;
+
+ if (ctx->src[0].abs && ctx->src[0].neg) {
+ op = ALU_OP3_CNDE;
+ ctx->src[0].abs = 0;
+ ctx->src[0].neg = 0;
+ } else {
+ op = ALU_OP3_CNDGE;
+ }
for (j = 0; j < inst->Instruction.NumSrcRegs; j++) {
temp_regs[j] = 0;
@@ -7719,7 +7728,7 @@ static int tgsi_cmp(struct r600_shader_ctx *ctx)
continue;
memset(&alu, 0, sizeof(struct r600_bytecode_alu));
- alu.op = ALU_OP3_CNDGE;
+ alu.op = op;
r = tgsi_make_src_for_op3(ctx, temp_regs[0], i, &alu.src[0],
&ctx->src[0]);
if (r)
return r;
--
2.5.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] r600g: fix and optimize tgsi_cmp when using ABS and NEG modifier
From: Patrick Rudolph
Some apps set NEG and ABS on the source param to test for zero.
Use ALU_OP3_CNDE insted of ALU_OP3_CNDGE and unset both modifiers.
It also removes the need for a MOV instruction, as ABS isn't
supported on op3.
Tested on AMD CAYMAN and AMD RV770.
Signed-off-by: Patrick Rudolph
---
src/gallium/drivers/r600/r600_shader.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/r600_shader.c
b/src/gallium/drivers/r600/r600_shader.c
index 77658f5..e5e2e3f 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -7707,6 +7707,15 @@ static int tgsi_cmp(struct r600_shader_ctx *ctx)
int i, r, j;
int lasti = tgsi_last_instruction(inst->Dst[0].Register.WriteMask);
int temp_regs[3];
+ unsigned op;
+
+ if (ctx->src[0].abs && ctx->src[0].neg) {
+ op = ALU_OP3_CNDE;
+ ctx->src[0].abs = 0;
+ ctx->src[0].neg = 0;
+ } else {
+ op = ALU_OP3_CNDGE;
+ }
for (j = 0; j < inst->Instruction.NumSrcRegs; j++) {
temp_regs[j] = 0;
@@ -7719,7 +7728,7 @@ static int tgsi_cmp(struct r600_shader_ctx *ctx)
continue;
memset(&alu, 0, sizeof(struct r600_bytecode_alu));
- alu.op = ALU_OP3_CNDGE;
+ alu.op = op;
r = tgsi_make_src_for_op3(ctx, temp_regs[0], i, &alu.src[0],
&ctx->src[0]);
if (r)
return r;
--
2.5.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] r600g: fix and optimize tgsi_cmp when using ABS and NEG modifier
From: Patrick Rudolph
Some apps set NEG and ABS on the source param to test for zero.
Use ALU_OP3_CNDE insted of ALU_OP3_CNDGE and unset both modifiers.
It also removes the need for a MOV instruction, as ABS isn't
supported on op3.
Tested on AMD CAYMAN and AMD RV770.
Signed-off-by: Patrick Rudolph
---
src/gallium/drivers/r600/r600_shader.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/r600_shader.c
b/src/gallium/drivers/r600/r600_shader.c
index 77658f5..e5e2e3f 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -7707,6 +7707,15 @@ static int tgsi_cmp(struct r600_shader_ctx *ctx)
int i, r, j;
int lasti = tgsi_last_instruction(inst->Dst[0].Register.WriteMask);
int temp_regs[3];
+ unsigned op;
+
+ if (ctx->src[0].abs && ctx->src[0].neg) {
+ op = ALU_OP3_CNDE;
+ ctx->src[0].abs = 0;
+ ctx->src[0].neg = 0;
+ } else {
+ op = ALU_OP3_CNDGE;
+ }
for (j = 0; j < inst->Instruction.NumSrcRegs; j++) {
temp_regs[j] = 0;
@@ -7719,7 +7728,7 @@ static int tgsi_cmp(struct r600_shader_ctx *ctx)
continue;
memset(&alu, 0, sizeof(struct r600_bytecode_alu));
- alu.op = ALU_OP3_CNDGE;
+ alu.op = op;
r = tgsi_make_src_for_op3(ctx, temp_regs[0], i, &alu.src[0],
&ctx->src[0]);
if (r)
return r;
--
2.5.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 94711] Patch for pb_reference to explicitly handle NULL src
https://bugs.freedesktop.org/show_bug.cgi?id=94711 Michel Dänzer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTABUG --- Comment #1 from Michel Dänzer --- This is not a bug but by design. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
