Re: [Mesa-dev] [PATCH 1/2] i965: Make the precompile ignore DEPTH_TEXTURE_MODE on Gen7.5+.
On 01/01/2015 10:51 PM, Kenneth Graunke wrote: > On Thursday, January 01, 2015 10:21:43 PM Ian Romanick wrote: >> On 12/31/2014 08:04 PM, Kenneth Graunke wrote: >>> Gen7.5+ platforms that support the "Shader Channel Select" feature leave >>> key->tex.swizzles[i] as SWIZZLE_NOOP except when GL_DEPTH_TEXTURE_MODE >>> is GL_ALPHA (which is really uncommon). So, the precompile should leave >>> them as SWIZZLE_NOOP (aka SWIZZLE_XYZW) as well. >>> >>> We didn't notice this because prog->ShadowSamplers is not set correctly. >>> The next patch will fix that problem. >> >> I had some patches related to this a long time ago, but I'm not sure >> what happened to them. My recollection is that, basically, nothing >> should use prog->ShadowSamplers. That was only used by the >> ARB_fragment_program assembler, and other paths (including ff fragment >> programs) don't set these fields. I just pushed the (ancient!) branch >> to my fd.o repo as r300-shadow-samplers. The two patches are from 2011. :( > > No, it's definitely set. > > link_uniforms.cpp sets shader->shadow_samplers, which ir_to_mesa copies > to prog->ShadowSamplers. I'm guessing we stopped copying that at some point. > > I don't see why we shouldn't use it... The commit message from one of those patches explains it: commit 6498addabe8fcb8a96064ecdd15b6438b66e1089 Author: Ian Romanick Date: Mon Nov 14 21:33:27 2011 -0800 r300g: Use rc_sub_instruction::TexShadow, not gl_program::ShadowSamplers gl_program::ShadowSamplers has two possible meanings. For ARB_fragment_program, it tells which texture units have been used with shadow comparisons (e.g., the SHADOW2D texture target). The flags are used by the assembler to generate errors when programs use the same texture unit for both shadow and non-shadow look-ups. For a GLSL program, it tells which *abstract* GLSL sampler uniforms were declared as a shadow sampler type (e.g., sampler1DShadow). In GLSL, sampler indices do *NOT* correspond to texture units (as they do in ARB_fragment_program). By calling glUniform1i, an application can bind texture unit 3 to sampler 7. At this point in code generation, we may want to know if texture unit 3 has shadow comparisons enabled or if sampler 7 was a shadow sampler. The old code determined if texture unit 3 has shadow comparisons enabled or if sampler 3 was a shadow sampler. This is clearly wrong. Signed-off-by: Ian Romanick Cc: Tom Stellard Cc: Marek Olšák Cc: Alex Deucher Long story short, from the next commit message, "The only places that really need this data are at fairly high levels in the GLSL compiler or the ARB_fragment_program assembler. Every place else really wants some other field." At the time I wrote that code, r300 was the only driver using gl_program::ShadowSamplers. It looks like i965 started using it about a year later. Either the meaning of that field has changed, my understanding of it is completely wrong, or we shouldn't use it either. > --Ken signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] i965: Make the precompile ignore DEPTH_TEXTURE_MODE on Gen7.5+.
On Thursday, January 01, 2015 10:21:43 PM Ian Romanick wrote: > On 12/31/2014 08:04 PM, Kenneth Graunke wrote: > > Gen7.5+ platforms that support the "Shader Channel Select" feature leave > > key->tex.swizzles[i] as SWIZZLE_NOOP except when GL_DEPTH_TEXTURE_MODE > > is GL_ALPHA (which is really uncommon). So, the precompile should leave > > them as SWIZZLE_NOOP (aka SWIZZLE_XYZW) as well. > > > > We didn't notice this because prog->ShadowSamplers is not set correctly. > > The next patch will fix that problem. > > I had some patches related to this a long time ago, but I'm not sure > what happened to them. My recollection is that, basically, nothing > should use prog->ShadowSamplers. That was only used by the > ARB_fragment_program assembler, and other paths (including ff fragment > programs) don't set these fields. I just pushed the (ancient!) branch > to my fd.o repo as r300-shadow-samplers. The two patches are from 2011. :( No, it's definitely set. link_uniforms.cpp sets shader->shadow_samplers, which ir_to_mesa copies to prog->ShadowSamplers. I'm guessing we stopped copying that at some point. I don't see why we shouldn't use it... --Ken signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] glsl: Add define for ARB_shader_precision
On 12/31/2014 12:43 PM, Micah Fedke wrote:
This patch does a little more than just add the define. If you change
the commit message to something like "mesa: Add ARB_shader_precision
infrastructure", you get
Reviewed-by: Ian Romanick
> ---
> src/glsl/glcpp/glcpp-parse.y| 3 +++
> src/glsl/glsl_parser_extras.cpp | 1 +
> src/glsl/glsl_parser_extras.h | 2 ++
> src/mesa/main/extensions.c | 1 +
> src/mesa/main/mtypes.h | 1 +
> 5 files changed, 8 insertions(+)
>
> diff --git a/src/glsl/glcpp/glcpp-parse.y b/src/glsl/glcpp/glcpp-parse.y
> index 9b1a4f4..c9cc68f 100644
> --- a/src/glsl/glcpp/glcpp-parse.y
> +++ b/src/glsl/glcpp/glcpp-parse.y
> @@ -2473,6 +2473,9 @@ _glcpp_parser_handle_version_declaration(glcpp_parser_t
> *parser, intmax_t versio
>
>if (extensions->ARB_derivative_control)
> add_builtin_define(parser, "GL_ARB_derivative_control", 1);
> +
> + if (extensions->ARB_shader_precision)
> + add_builtin_define(parser, "GL_ARB_shader_precision", 1);
> }
> }
>
> diff --git a/src/glsl/glsl_parser_extras.cpp b/src/glsl/glsl_parser_extras.cpp
> index 27e2eaf3..8555af6 100644
> --- a/src/glsl/glsl_parser_extras.cpp
> +++ b/src/glsl/glsl_parser_extras.cpp
> @@ -532,6 +532,7 @@ static const _mesa_glsl_extension
> _mesa_glsl_supported_extensions[] = {
> EXT(ARB_shader_atomic_counters, true, false,
> ARB_shader_atomic_counters),
> EXT(ARB_shader_bit_encoding,true, false,
> ARB_shader_bit_encoding),
> EXT(ARB_shader_image_load_store,true, false,
> ARB_shader_image_load_store),
> + EXT(ARB_shader_precision, true, false,
> ARB_shader_precision),
> EXT(ARB_shader_stencil_export, true, false,
> ARB_shader_stencil_export),
> EXT(ARB_shader_texture_lod, true, false,
> ARB_shader_texture_lod),
> EXT(ARB_shading_language_420pack, true, false,
> ARB_shading_language_420pack),
> diff --git a/src/glsl/glsl_parser_extras.h b/src/glsl/glsl_parser_extras.h
> index e04f7ce..0ca6053 100644
> --- a/src/glsl/glsl_parser_extras.h
> +++ b/src/glsl/glsl_parser_extras.h
> @@ -424,6 +424,8 @@ struct _mesa_glsl_parse_state {
> bool ARB_shader_bit_encoding_warn;
> bool ARB_shader_image_load_store_enable;
> bool ARB_shader_image_load_store_warn;
> + bool ARB_shader_precision_enable;
> + bool ARB_shader_precision_warn;
> bool ARB_shader_stencil_export_enable;
> bool ARB_shader_stencil_export_warn;
> bool ARB_shader_texture_lod_enable;
> diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
> index 0df04c2..95c7a37 100644
> --- a/src/mesa/main/extensions.c
> +++ b/src/mesa/main/extensions.c
> @@ -147,6 +147,7 @@ static const struct extension extension_table[] = {
> { "GL_ARB_shader_bit_encoding",
> o(ARB_shader_bit_encoding), GL, 2010 },
> { "GL_ARB_shader_image_load_store",
> o(ARB_shader_image_load_store), GL, 2011 },
> { "GL_ARB_shader_objects", o(dummy_true),
> GL, 2002 },
> + { "GL_ARB_shader_precision",o(ARB_shader_precision),
> GL, 2014 },
> { "GL_ARB_shader_stencil_export",
> o(ARB_shader_stencil_export), GL, 2009 },
> { "GL_ARB_shader_texture_lod",
> o(ARB_shader_texture_lod), GL, 2009 },
> { "GL_ARB_shading_language_100",o(dummy_true),
> GLL,2003 },
> diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
> index b95dfb9..4c83379 100644
> --- a/src/mesa/main/mtypes.h
> +++ b/src/mesa/main/mtypes.h
> @@ -3757,6 +3757,7 @@ struct gl_extensions
> GLboolean ARB_shader_atomic_counters;
> GLboolean ARB_shader_bit_encoding;
> GLboolean ARB_shader_image_load_store;
> + GLboolean ARB_shader_precision;
> GLboolean ARB_shader_stencil_export;
> GLboolean ARB_shader_texture_lod;
> GLboolean ARB_shading_language_packing;
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] glapi: Add (empty) glapi for ARB_shader_precision
If an extension doesn't add any enums or functions, I don't think we usually bother adding it, but meh. One nit below... On 12/31/2014 12:43 PM, Micah Fedke wrote: > --- > src/mapi/glapi/gen/gl_API.xml | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/src/mapi/glapi/gen/gl_API.xml b/src/mapi/glapi/gen/gl_API.xml > index e1b1246..d7d0627 100644 > --- a/src/mapi/glapi/gen/gl_API.xml > +++ b/src/mapi/glapi/gen/gl_API.xml > @@ -8247,7 +8247,11 @@ > > xmlns:xi="http://www.w3.org/2001/XInclude"/> > > - > + > + > + This should be at the same indentation as the opening . With that fixed, Reviewed-by: Ian Romanick > + > + > > xmlns:xi="http://www.w3.org/2001/XInclude"/> > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] i965: Make the precompile ignore DEPTH_TEXTURE_MODE on Gen7.5+.
On 12/31/2014 08:04 PM, Kenneth Graunke wrote:
> Gen7.5+ platforms that support the "Shader Channel Select" feature leave
> key->tex.swizzles[i] as SWIZZLE_NOOP except when GL_DEPTH_TEXTURE_MODE
> is GL_ALPHA (which is really uncommon). So, the precompile should leave
> them as SWIZZLE_NOOP (aka SWIZZLE_XYZW) as well.
>
> We didn't notice this because prog->ShadowSamplers is not set correctly.
> The next patch will fix that problem.
I had some patches related to this a long time ago, but I'm not sure
what happened to them. My recollection is that, basically, nothing
should use prog->ShadowSamplers. That was only used by the
ARB_fragment_program assembler, and other paths (including ff fragment
programs) don't set these fields. I just pushed the (ancient!) branch
to my fd.o repo as r300-shadow-samplers. The two patches are from 2011. :(
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87886
> Signed-off-by: Kenneth Graunke
> ---
> src/mesa/drivers/dri/i965/brw_fs.cpp | 3 ++-
> src/mesa/drivers/dri/i965/brw_vec4.cpp | 4 +++-
> 2 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
> b/src/mesa/drivers/dri/i965/brw_fs.cpp
> index 78c068f..fa1ca8c 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
> @@ -3912,9 +3912,10 @@ brw_fs_precompile(struct gl_context *ctx,
> BRW_FS_VARYING_INPUT_MASK) > 16)
>key.input_slots_valid = fp->Base.InputsRead | VARYING_BIT_POS;
>
> + const bool has_shader_channel_select = brw->is_haswell || brw->gen >= 8;
> unsigned sampler_count = _mesa_fls(fp->Base.SamplersUsed);
> for (unsigned i = 0; i < sampler_count; i++) {
> - if (fp->Base.ShadowSamplers & (1 << i)) {
> + if (!has_shader_channel_select && (fp->Base.ShadowSamplers & (1 <<
> i))) {
> /* Assume DEPTH_TEXTURE_MODE is the default: X, X, X, 1 */
> key.tex.swizzles[i] =
> MAKE_SWIZZLE4(SWIZZLE_X, SWIZZLE_X, SWIZZLE_X, SWIZZLE_ONE);
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp
> b/src/mesa/drivers/dri/i965/brw_vec4.cpp
> index f389392..b1a2a53 100644
> --- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
> @@ -1945,11 +1945,13 @@ brw_vue_setup_prog_key_for_precompile(struct
> gl_context *ctx,
>struct brw_vue_prog_key *key,
>GLuint id, struct gl_program *prog)
> {
> + struct brw_context *brw = brw_context(ctx);
> key->program_string_id = id;
>
> + const bool has_shader_channel_select = brw->is_haswell || brw->gen >= 8;
> unsigned sampler_count = _mesa_fls(prog->SamplersUsed);
> for (unsigned i = 0; i < sampler_count; i++) {
> - if (prog->ShadowSamplers & (1 << i)) {
> + if (!has_shader_channel_select && (prog->ShadowSamplers & (1 << i))) {
> /* Assume DEPTH_TEXTURE_MODE is the default: X, X, X, 1 */
> key->tex.swizzles[i] =
> MAKE_SWIZZLE4(SWIZZLE_X, SWIZZLE_X, SWIZZLE_X, SWIZZLE_ONE);
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] swrast: Build fix for darwin
Fixes regression from commit 64b1dc44495890cbc2c7c5509cb830264020998c
Signed-off-by: Jeremy Huddleston Sequoia
CC: Emil Velikov
CC: jon.tur...@dronecode.org.uk
CC: io...@macports.org
---
src/mesa/drivers/dri/swrast/swrast.c | 16
1 file changed, 16 insertions(+)
diff --git a/src/mesa/drivers/dri/swrast/swrast.c
b/src/mesa/drivers/dri/swrast/swrast.c
index d62fed3..0b7329a 100644
--- a/src/mesa/drivers/dri/swrast/swrast.c
+++ b/src/mesa/drivers/dri/swrast/swrast.c
@@ -59,6 +59,9 @@
#include "swrast_priv.h"
#include "swrast/s_context.h"
+#include
+#include
+
const __DRIextension **__driDriverGetExtensions_swrast(void);
const char * const swrast_vendor_string = "Mesa Project";
@@ -135,6 +138,16 @@ swrast_query_renderer_integer(__DRIscreen *psp, int param,
value[0] = 0;
return 0;
case __DRI2_RENDERER_VIDEO_MEMORY: {
+ /* This should probably share code with os_get_total_physical_memory()
+ * from src/gallium/auxiliary/os/os_misc.c
+ */
+#if defined(CTL_HW) && defined(HW_MEMSIZE)
+int mib[2] = { CTL_HW, HW_MEMSIZE };
+unsigned long system_memory_bytes;
+size_t len = sizeof(system_memory_bytes);
+if (sysctl(mib, 2, &system_memory_bytes, &len, NULL, 0) != 0)
+return -1;
+#elif defined(_SC_PHYS_PAGES) && defined(_SC_PAGE_SIZE)
/* XXX: Do we want to return the full amount of system memory ? */
const long system_memory_pages = sysconf(_SC_PHYS_PAGES);
const long system_page_size = sysconf(_SC_PAGE_SIZE);
@@ -144,6 +157,9 @@ swrast_query_renderer_integer(__DRIscreen *psp, int param,
const uint64_t system_memory_bytes = (uint64_t) system_memory_pages
* (uint64_t) system_page_size;
+#else
+#error "Unsupported platform"
+#endif
const unsigned system_memory_megabytes =
(unsigned) (system_memory_bytes / (1024 * 1024));
--
2.2.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] swrast: Build fix for darwin
This is certainly not the best solution to the problem, so I'm just sending
this patch to the list to get the discussion started on the best way to solve
this problem. Currently, any platform that does not support _SC_PHYS_PAGES and
_SC_PAGESIZE will fail to build swrast. _SC_PHYS_PAGES is not POSIX and thus
there are many platforms out there that don't support it (such as OS X).
We may want to put os_get_total_physical_memory() from
src/gallium/auxiliary/os/os_misc.c into a more common location, so it could be
used here.
However, as the existing comment indicates, maybe we don't even want to return
the full size of system memory for __DRI2_RENDERER_VIDEO_MEMORY.
> On Jan 1, 2015, at 20:10, Jeremy Huddleston Sequoia
> wrote:
>
> Fixes regression from commit 64b1dc44495890cbc2c7c5509cb830264020998c
>
> Signed-off-by: Jeremy Huddleston Sequoia
> CC: Emil Velikov
> CC: jon.tur...@dronecode.org.uk
> CC: io...@macports.org
> ---
> src/mesa/drivers/dri/swrast/swrast.c | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/swrast/swrast.c
> b/src/mesa/drivers/dri/swrast/swrast.c
> index d62fed3..0b7329a 100644
> --- a/src/mesa/drivers/dri/swrast/swrast.c
> +++ b/src/mesa/drivers/dri/swrast/swrast.c
> @@ -59,6 +59,9 @@
> #include "swrast_priv.h"
> #include "swrast/s_context.h"
>
> +#include
> +#include
> +
> const __DRIextension **__driDriverGetExtensions_swrast(void);
>
> const char * const swrast_vendor_string = "Mesa Project";
> @@ -135,6 +138,16 @@ swrast_query_renderer_integer(__DRIscreen *psp, int
> param,
> value[0] = 0;
> return 0;
>case __DRI2_RENDERER_VIDEO_MEMORY: {
> + /* This should probably share code with os_get_total_physical_memory()
> + * from src/gallium/auxiliary/os/os_misc.c
> + */
> +#if defined(CTL_HW) && defined(HW_MEMSIZE)
> +int mib[2] = { CTL_HW, HW_MEMSIZE };
> +unsigned long system_memory_bytes;
> +size_t len = sizeof(system_memory_bytes);
> +if (sysctl(mib, 2, &system_memory_bytes, &len, NULL, 0) != 0)
> +return -1;
> +#elif defined(_SC_PHYS_PAGES) && defined(_SC_PAGE_SIZE)
> /* XXX: Do we want to return the full amount of system memory ? */
> const long system_memory_pages = sysconf(_SC_PHYS_PAGES);
> const long system_page_size = sysconf(_SC_PAGE_SIZE);
> @@ -144,6 +157,9 @@ swrast_query_renderer_integer(__DRIscreen *psp, int param,
>
> const uint64_t system_memory_bytes = (uint64_t) system_memory_pages
> * (uint64_t) system_page_size;
> +#else
> +#error "Unsupported platform"
> +#endif
>
> const unsigned system_memory_megabytes =
> (unsigned) (system_memory_bytes / (1024 * 1024));
> --
> 2.2.1
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] main: Checking for cube completeness in TextureSubImage.
On 12/31/2014 05:26 PM, Laura Ekstrand wrote: > This is part of a potential solution to Khronos Bug 13223. Cube completeness > is a concept from glGenerateMipmap, but it seems reasonable to check for it in > TextureSubImage when target=GL_TEXTURE_CUBE_MAP. > --- > src/mesa/main/teximage.c | 42 +- > 1 file changed, 29 insertions(+), 13 deletions(-) My comments to patch 2/3 apply to this patch too. signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/3] main: Checking for cube completeness in GetTextureImage.
On 12/31/2014 05:26 PM, Laura Ekstrand wrote:
> This is part of a potential solution to Khronos Bug 13223. Cube completeness
> is a concept from glGenerateMipmap, but it seems reasonable to check for it in
> GetTextureImage when the target is GL_TEXTURE_CUBE_MAP.
> ---
> src/mesa/main/texgetimage.c | 41 +
> 1 file changed, 29 insertions(+), 12 deletions(-)
>
> diff --git a/src/mesa/main/texgetimage.c b/src/mesa/main/texgetimage.c
> index 5b4d294..060c68a 100644
> --- a/src/mesa/main/texgetimage.c
> +++ b/src/mesa/main/texgetimage.c
> @@ -1105,18 +1105,35 @@ _mesa_GetTextureImage( GLuint texture, GLint level,
> GLenum format,
> "glGetTextureImage(insufficient cube map storage)");
> return;
>}
> - for (i = 0; i < 6; ++i) { /* For each face. */
> - if (!texObj->Image[i][level]) {
> -/* Not enough image planes for a cube map. The spec does not say
> - * what should happen in this case because the user has always
> - * specified each cube face separately (using
> - * GL_TEXTURE_CUBE_MAP_POSITIVE_X+i) in previous GL versions.
> - * This is addressed in Khronos Bug 13223.
> - */
> -_mesa_error(ctx, GL_INVALID_OPERATION,
> -"glGetTextureImage(insufficient cube map storage)");
> -return;
> - }
> +
> + /*
> + * This is part of a potential solution to a bug in the spec. According
> + * to Section 8.17 Texture Completeness in the OpenGL 4.5 Core Profile
> + * spec (30.10.2014):
> + *"[A] cube map texture is cube complete if the
> + *following conditions all hold true: The [base level] texture
> + *images of each of the six cube map faces have identical,
> positive,
> + *and square dimensions. The [base level] images were each
> specified
> + *with the same internal format."
> + *
> + * It seems reasonable to check for cube completeness of an arbitrary
> + * level here so that the returned data has a consistent format and
> size
> + * and therefore fits in the user's buffer.
> + */
The above comment is very confusing, unless the reader has had a conversation
with
you about the topic ;). The comment alludes to a "bug in the spec" and "a
potential solution",
but the comment does not state what the bug is. The reader has to guess based
on the clues
you give. For the sake of the future devs, please directly describe the bug.
> + if (!_mesa_cube_level_complete(texObj, level)) {
> + /*
> + * Precedence for this error:
> + * In Section 8.14.4 Manual Mipmap Generation, the OpenGL 4.5 Core
> + * Profile spec (30.10.2014) says:
> + *"An INVALID_OPERATION error is generated by
> + *GenerateTextureMipmap if the effective target is
> + *TEXTURE_CUBE_MAP or TEXTURE_CUBE_MAP_ARRAY, and the texture
> + *object is not cube complete or cube array complete,
> + *respectively."
> + */
I suggest removing the comment above. I don't believe you need to provide
precedent
for emitting GL_INVALID_OPERATION here, since it is a catch-all generic error.
Just a suggestion.
> + _mesa_error(ctx, GL_INVALID_OPERATION,
> + "glGetTextureImage(cube map incomplete)");
> + return;
>}
signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] main: Added _mesa_cube_level_complete to check for the completeness of an arbitrary cube map level.
On 12/31/2014 05:26 PM, Laura Ekstrand wrote:
> +/**
> + * Check if the given cube map texture is "cube complete" as defined in
> + * the OpenGL specification.
> + */
> +GLboolean
> +_mesa_cube_complete(const struct gl_texture_object *texObj)
> +{
> + _mesa_cube_level_complete(texObj, texObj->BaseLevel);
You forgot to return here ^^^
> +}
This patch makes sense to me after our irc conversation.
With the return fixed,
Reviewed-by: Chad Versace
signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 87925] SIGSEGV libX11 src/ImUtil.c:733
https://bugs.freedesktop.org/show_bug.cgi?id=87925 Alan Coopersmith changed: What|Removed |Added CC||xorg-t...@lists.x.org Component|Lib/other |Mesa core Assignee|xorg-t...@lists.x.org |mesa-dev@lists.freedesktop. ||org Product|xorg|Mesa QA Contact|xorg-t...@lists.x.org | --- Comment #1 from Alan Coopersmith --- If mesa is passing an XImage with NULL data to Xlib, segfaults are expected. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 84023] GLSL compiler bug in uniform buffer load lowering or optimizations
https://bugs.freedesktop.org/show_bug.cgi?id=84023 Marek Olšák changed: What|Removed |Added Component|Drivers/Gallium/r600|Mesa core Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org Summary|multiple uniform buffers|GLSL compiler bug in |problem |uniform buffer load ||lowering or optimizations --- Comment #1 from Marek Olšák --- Piglit test: http://lists.freedesktop.org/archives/piglit/2015-January/013893.html -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/4] mesa: add support for GL_EXT_polygon_offset_clamp
On Thu, Jan 1, 2015 at 4:44 AM, Kenneth Graunke wrote:
> On Wednesday, December 31, 2014 02:38:12 AM Ilia Mirkin wrote:
>> Nothing enables the extension yet, but the values are now available.
>> The spec calls for it to only be exposed for GL 3.3+, which is core-only
>> in mesa. Restrict it as such so that drivers enabling the extension
>> don't end up accidentally exposing the function in compat contexts.
>>
>> Signed-off-by: Ilia Mirkin
>> ---
>> src/mesa/drivers/dri/nouveau/nouveau_state.c | 2 +-
>> src/mesa/drivers/dri/r200/r200_state.c | 2 +-
>> src/mesa/drivers/dri/radeon/radeon_state.c | 2 +-
>> src/mesa/main/dd.h | 2 +-
>> src/mesa/main/extensions.c | 1 +
>> src/mesa/main/get.c | 1 +
>> src/mesa/main/get_hash_params.py | 4
>> src/mesa/main/mtypes.h | 2 ++
>> src/mesa/main/polygon.c | 28
>> ++--
>> 9 files changed, 38 insertions(+), 6 deletions(-)
>>
>> diff --git a/src/mesa/drivers/dri/nouveau/nouveau_state.c
>> b/src/mesa/drivers/dri/nouveau/nouveau_state.c
>> index db4915f..3aad10e 100644
>> --- a/src/mesa/drivers/dri/nouveau/nouveau_state.c
>> +++ b/src/mesa/drivers/dri/nouveau/nouveau_state.c
>> @@ -319,7 +319,7 @@ nouveau_polygon_mode(struct gl_context *ctx, GLenum
>> face, GLenum mode)
>> }
>>
>> static void
>> -nouveau_polygon_offset(struct gl_context *ctx, GLfloat factor, GLfloat
>> units)
>> +nouveau_polygon_offset(struct gl_context *ctx, GLfloat factor, GLfloat
>> units, GLfloat clamp)
>> {
>> context_dirty(ctx, POLYGON_OFFSET);
>> }
>> diff --git a/src/mesa/drivers/dri/r200/r200_state.c
>> b/src/mesa/drivers/dri/r200/r200_state.c
>> index 2ad8439..930ead8 100644
>> --- a/src/mesa/drivers/dri/r200/r200_state.c
>> +++ b/src/mesa/drivers/dri/r200/r200_state.c
>> @@ -712,7 +712,7 @@ static void r200ColorMask( struct gl_context *ctx,
>> */
>>
>> static void r200PolygonOffset( struct gl_context *ctx,
>> -GLfloat factor, GLfloat units )
>> +GLfloat factor, GLfloat units, GLfloat clamp )
>> {
>> r200ContextPtr rmesa = R200_CONTEXT(ctx);
>> const GLfloat depthScale = 1.0F / ctx->DrawBuffer->_DepthMaxF;
>> diff --git a/src/mesa/drivers/dri/radeon/radeon_state.c
>> b/src/mesa/drivers/dri/radeon/radeon_state.c
>> index 0f4d84f..726b06d 100644
>> --- a/src/mesa/drivers/dri/radeon/radeon_state.c
>> +++ b/src/mesa/drivers/dri/radeon/radeon_state.c
>> @@ -520,7 +520,7 @@ static void radeonColorMask( struct gl_context *ctx,
>> */
>>
>> static void radeonPolygonOffset( struct gl_context *ctx,
>> - GLfloat factor, GLfloat units )
>> + GLfloat factor, GLfloat units, GLfloat clamp )
>> {
>> r100ContextPtr rmesa = R100_CONTEXT(ctx);
>> const GLfloat depthScale = 1.0F / ctx->DrawBuffer->_DepthMaxF;
>> diff --git a/src/mesa/main/dd.h b/src/mesa/main/dd.h
>> index 2f40915..6ba0959 100644
>> --- a/src/mesa/main/dd.h
>> +++ b/src/mesa/main/dd.h
>> @@ -563,7 +563,7 @@ struct dd_function_table {
>> /** Select a polygon rasterization mode */
>> void (*PolygonMode)(struct gl_context *ctx, GLenum face, GLenum mode);
>> /** Set the scale and units used to calculate depth values */
>> - void (*PolygonOffset)(struct gl_context *ctx, GLfloat factor, GLfloat
>> units);
>> + void (*PolygonOffset)(struct gl_context *ctx, GLfloat factor, GLfloat
>> units, GLfloat clamp);
>> /** Set the polygon stippling pattern */
>> void (*PolygonStipple)(struct gl_context *ctx, const GLubyte *mask );
>> /* Specifies the current buffer for reading */
>> diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
>> index 0df04c2..bffa6b2 100644
>> --- a/src/mesa/main/extensions.c
>> +++ b/src/mesa/main/extensions.c
>> @@ -231,6 +231,7 @@ static const struct extension extension_table[] = {
>> { "GL_EXT_pixel_buffer_object",
>> o(EXT_pixel_buffer_object), GL, 2004 },
>> { "GL_EXT_point_parameters",o(EXT_point_parameters),
>>GLL,1997 },
>> { "GL_EXT_polygon_offset", o(dummy_true),
>>GLL,1995 },
>> + { "GL_EXT_polygon_offset_clamp",
>> o(EXT_polygon_offset_clamp),GLC,2014 },
>> { "GL_EXT_provoking_vertex",o(EXT_provoking_vertex),
>>GL, 2009 },
>> { "GL_EXT_rescale_normal", o(dummy_true),
>>GLL,1997 },
>> { "GL_EXT_secondary_color", o(dummy_true),
>>GLL,1999 },
>> diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
>> index 6091efc..3f9d745 100644
>> --- a/src/mesa/main/ge
Re: [Mesa-dev] [PATCH 2/4] mesa: add support for GL_EXT_polygon_offset_clamp
On Wednesday, December 31, 2014 02:38:12 AM Ilia Mirkin wrote:
> Nothing enables the extension yet, but the values are now available.
> The spec calls for it to only be exposed for GL 3.3+, which is core-only
> in mesa. Restrict it as such so that drivers enabling the extension
> don't end up accidentally exposing the function in compat contexts.
>
> Signed-off-by: Ilia Mirkin
> ---
> src/mesa/drivers/dri/nouveau/nouveau_state.c | 2 +-
> src/mesa/drivers/dri/r200/r200_state.c | 2 +-
> src/mesa/drivers/dri/radeon/radeon_state.c | 2 +-
> src/mesa/main/dd.h | 2 +-
> src/mesa/main/extensions.c | 1 +
> src/mesa/main/get.c | 1 +
> src/mesa/main/get_hash_params.py | 4
> src/mesa/main/mtypes.h | 2 ++
> src/mesa/main/polygon.c | 28
> ++--
> 9 files changed, 38 insertions(+), 6 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/nouveau/nouveau_state.c
> b/src/mesa/drivers/dri/nouveau/nouveau_state.c
> index db4915f..3aad10e 100644
> --- a/src/mesa/drivers/dri/nouveau/nouveau_state.c
> +++ b/src/mesa/drivers/dri/nouveau/nouveau_state.c
> @@ -319,7 +319,7 @@ nouveau_polygon_mode(struct gl_context *ctx, GLenum face,
> GLenum mode)
> }
>
> static void
> -nouveau_polygon_offset(struct gl_context *ctx, GLfloat factor, GLfloat units)
> +nouveau_polygon_offset(struct gl_context *ctx, GLfloat factor, GLfloat
> units, GLfloat clamp)
> {
> context_dirty(ctx, POLYGON_OFFSET);
> }
> diff --git a/src/mesa/drivers/dri/r200/r200_state.c
> b/src/mesa/drivers/dri/r200/r200_state.c
> index 2ad8439..930ead8 100644
> --- a/src/mesa/drivers/dri/r200/r200_state.c
> +++ b/src/mesa/drivers/dri/r200/r200_state.c
> @@ -712,7 +712,7 @@ static void r200ColorMask( struct gl_context *ctx,
> */
>
> static void r200PolygonOffset( struct gl_context *ctx,
> -GLfloat factor, GLfloat units )
> +GLfloat factor, GLfloat units, GLfloat clamp )
> {
> r200ContextPtr rmesa = R200_CONTEXT(ctx);
> const GLfloat depthScale = 1.0F / ctx->DrawBuffer->_DepthMaxF;
> diff --git a/src/mesa/drivers/dri/radeon/radeon_state.c
> b/src/mesa/drivers/dri/radeon/radeon_state.c
> index 0f4d84f..726b06d 100644
> --- a/src/mesa/drivers/dri/radeon/radeon_state.c
> +++ b/src/mesa/drivers/dri/radeon/radeon_state.c
> @@ -520,7 +520,7 @@ static void radeonColorMask( struct gl_context *ctx,
> */
>
> static void radeonPolygonOffset( struct gl_context *ctx,
> - GLfloat factor, GLfloat units )
> + GLfloat factor, GLfloat units, GLfloat clamp )
> {
> r100ContextPtr rmesa = R100_CONTEXT(ctx);
> const GLfloat depthScale = 1.0F / ctx->DrawBuffer->_DepthMaxF;
> diff --git a/src/mesa/main/dd.h b/src/mesa/main/dd.h
> index 2f40915..6ba0959 100644
> --- a/src/mesa/main/dd.h
> +++ b/src/mesa/main/dd.h
> @@ -563,7 +563,7 @@ struct dd_function_table {
> /** Select a polygon rasterization mode */
> void (*PolygonMode)(struct gl_context *ctx, GLenum face, GLenum mode);
> /** Set the scale and units used to calculate depth values */
> - void (*PolygonOffset)(struct gl_context *ctx, GLfloat factor, GLfloat
> units);
> + void (*PolygonOffset)(struct gl_context *ctx, GLfloat factor, GLfloat
> units, GLfloat clamp);
> /** Set the polygon stippling pattern */
> void (*PolygonStipple)(struct gl_context *ctx, const GLubyte *mask );
> /* Specifies the current buffer for reading */
> diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
> index 0df04c2..bffa6b2 100644
> --- a/src/mesa/main/extensions.c
> +++ b/src/mesa/main/extensions.c
> @@ -231,6 +231,7 @@ static const struct extension extension_table[] = {
> { "GL_EXT_pixel_buffer_object",
> o(EXT_pixel_buffer_object), GL, 2004 },
> { "GL_EXT_point_parameters",o(EXT_point_parameters),
> GLL,1997 },
> { "GL_EXT_polygon_offset", o(dummy_true),
> GLL,1995 },
> + { "GL_EXT_polygon_offset_clamp",
> o(EXT_polygon_offset_clamp),GLC,2014 },
> { "GL_EXT_provoking_vertex",o(EXT_provoking_vertex),
> GL, 2009 },
> { "GL_EXT_rescale_normal", o(dummy_true),
> GLL,1997 },
> { "GL_EXT_secondary_color", o(dummy_true),
> GLL,1999 },
> diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
> index 6091efc..3f9d745 100644
> --- a/src/mesa/main/get.c
> +++ b/src/mesa/main/get.c
> @@ -392,6 +392,7 @@ EXTRA_EXT2(ARB_transform_feedback3, ARB_gpu_shader5);
> EXTRA_EXT(INTEL_performance_query);
> EXTR
[Mesa-dev] [Bug 87913] CPU cacheline size of 0 can be returned by CPUID leaf 0x80000006 in some virtual machines
https://bugs.freedesktop.org/show_bug.cgi?id=87913 --- Comment #4 from Leonid Shatz --- In virtual environments you would never know which is the safest method. It depends on the implementation and correctness of the hypervisor. I would just add the suggested fix and wait to see if any new related issues will be reported. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] i965: Fix BLORP sRGB MSAA overrides to cope with X vs. A formats.
Both of these are also
Reviewed-by: Chris Forbes
On Jan 1, 2015 7:48 PM, "Kenneth Graunke" wrote:
> The logic in brw_blorp_surface_info::set uses brw_format_for_mesa_format
> for source surfaces, and brw->render_target_format[] for destination
> surfaces. We should do the same in the sRGB MSAA overrides.
>
> Currently, this isn't a problem, since SRGB MSAA buffers are all RGBA.
> The next commit will introduce RGBX SRGB MSAA buffers, at which point
> we need to get the RGBX -> RGBA format overrides for rendering right.
>
> Signed-off-by: Kenneth Graunke
> ---
> src/mesa/drivers/dri/i965/brw_blorp_blit.cpp | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
> b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
> index a103af0..936feaf 100644
> --- a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
> @@ -1868,8 +1868,9 @@ brw_blorp_blit_params::brw_blorp_blit_params(struct
> brw_context *brw,
> _mesa_get_format_color_encoding(dst_mt->format) == GL_SRGB &&
> _mesa_get_srgb_format_linear(src_mt->format) ==
> _mesa_get_srgb_format_linear(dst_mt->format)) {
> - dst.brw_surfaceformat = brw_format_for_mesa_format(dst_mt->format);
> - src.brw_surfaceformat = dst.brw_surfaceformat;
> + assert(brw->format_supported_as_render_target[dst_mt->format]);
> + dst.brw_surfaceformat = brw->render_target_format[dst_mt->format];
> + src.brw_surfaceformat = brw_format_for_mesa_format(dst_mt->format);
> }
>
> /* When doing a multisample resolve of a GL_LUMINANCE32F or
> GL_INTENSITY32F
> --
> 2.2.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
