[Mesa-dev] [PATCH V2 0/8] ARB_texture_storage_multisample support
This series adds support for the ARB_texture_storage_multisample extension. Only minor changes from V1: * Added missing error cases in TexStorage*Multisample. Thanks Eric for pointing out that this was a bit lacking. * Dropped spurious special case for TEXTURE_MAX_LEVELS. This wasn't in the spec at all, not sure where it came from. -- Chris ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH V2 1/8] mesa: extract _mesa_is_legal_tex_storage_format helper
This is about to be used in teximagemultisample() when immutable=true.
Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
src/mesa/main/texstorage.c | 37 -
src/mesa/main/texstorage.h | 3 +++
2 files changed, 23 insertions(+), 17 deletions(-)
diff --git a/src/mesa/main/texstorage.c b/src/mesa/main/texstorage.c
index 675fd74..6309b57 100644
--- a/src/mesa/main/texstorage.c
+++ b/src/mesa/main/texstorage.c
@@ -202,20 +202,9 @@ clear_texture_fields(struct gl_context *ctx,
}
-/**
- * Do error checking for calls to glTexStorage1/2/3D().
- * If an error is found, record it with _mesa_error(), unless the target
- * is a proxy texture.
- * \return GL_TRUE if any error, GL_FALSE otherwise.
- */
-static GLboolean
-tex_storage_error_check(struct gl_context *ctx, GLuint dims, GLenum target,
-GLsizei levels, GLenum internalformat,
-GLsizei width, GLsizei height, GLsizei depth)
+GLboolean
+_mesa_is_legal_tex_storage_format(struct gl_context *ctx, GLenum
internalformat)
{
- struct gl_texture_object *texObj;
- GLboolean legalFormat;
-
/* check internal format - note that only sized formats are allowed */
switch (internalformat) {
case GL_ALPHA:
@@ -250,13 +239,27 @@ tex_storage_error_check(struct gl_context *ctx, GLuint
dims, GLenum target,
case GL_LUMINANCE_INTEGER_EXT:
case GL_LUMINANCE_ALPHA_INTEGER_EXT:
/* these unsized formats are illegal */
- legalFormat = GL_FALSE;
- break;
+ return GL_FALSE;
default:
- legalFormat = _mesa_base_tex_format(ctx, internalformat) 0;
+ return _mesa_base_tex_format(ctx, internalformat) 0;
}
+}
+
+
+/**
+ * Do error checking for calls to glTexStorage1/2/3D().
+ * If an error is found, record it with _mesa_error(), unless the target
+ * is a proxy texture.
+ * \return GL_TRUE if any error, GL_FALSE otherwise.
+ */
+static GLboolean
+tex_storage_error_check(struct gl_context *ctx, GLuint dims, GLenum target,
+GLsizei levels, GLenum internalformat,
+GLsizei width, GLsizei height, GLsizei depth)
+{
+ struct gl_texture_object *texObj;
- if (!legalFormat) {
+ if (!_mesa_is_legal_tex_storage_format(ctx, internalformat)) {
_mesa_error(ctx, GL_INVALID_ENUM,
glTexStorage%uD(internalformat = %s), dims,
_mesa_lookup_enum_by_nr(internalformat));
diff --git a/src/mesa/main/texstorage.h b/src/mesa/main/texstorage.h
index 99382df..9f172e1 100644
--- a/src/mesa/main/texstorage.h
+++ b/src/mesa/main/texstorage.h
@@ -57,5 +57,8 @@ _mesa_TextureStorage3DEXT(GLuint texture, GLenum target,
GLsizei levels,
GLenum internalformat,
GLsizei width, GLsizei height, GLsizei depth);
+extern GLboolean
+_mesa_is_legal_tex_storage_format(struct gl_context *ctx, GLenum
internalformat);
+
#endif /* TEXSTORAGE_H */
--
1.8.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH V2 2/8] mesa: add support for immutable textures to teximagemultisample()
The new entrypoints will come later, but this adds the actual logic for
supporting immutable multisample textures:
- The immutability flag is set as desired.
- Attempting to modify an immutable multisample texture produces
INVALID_OPERATION.
Note: The extension spec does not mention adding this behavior to
TexImage*Multisample, but it seems like the reasonable thing to do.
V2: - Cover missing error cases (unsized formats; texture object zero)
Signed-off-by: Chris Forbes chr...@ijw.co.nz
[V1] Reviewed-by: Eric Anholt e...@anholt.net
---
src/mesa/main/teximage.c | 31 ---
1 file changed, 28 insertions(+), 3 deletions(-)
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index bc755ae..d7de69b 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -47,6 +47,7 @@
#include teximage.h
#include texobj.h
#include texstate.h
+#include texstorage.h
#include mtypes.h
#include glformats.h
@@ -4194,7 +4195,8 @@ check_multisample_target(GLuint dims, GLenum target)
static void
teximagemultisample(GLuint dims, GLenum target, GLsizei samples,
GLint internalformat, GLsizei width, GLsizei height,
-GLsizei depth, GLboolean fixedsamplelocations)
+GLsizei depth, GLboolean fixedsamplelocations,
+GLboolean immutable)
{
struct gl_texture_object *texObj;
struct gl_texture_image *texImage;
@@ -4219,6 +4221,13 @@ teximagemultisample(GLuint dims, GLenum target, GLsizei
samples,
* refer GL3.1 spec 4.4.4
*/
+ if (immutable !_mesa_is_legal_tex_storage_format(ctx, internalformat)) {
+ _mesa_error(ctx, GL_INVALID_ENUM,
+%s(internalformat=%s not legal for immutable-format),
+func, _mesa_lookup_enum_by_nr(internalformat));
+ return;
+ }
+
if (!is_renderable_texture_format(ctx, internalformat)) {
_mesa_error(ctx, GL_INVALID_OPERATION,
glTexImage%uDMultisample(internalformat=%s),
@@ -4235,6 +4244,14 @@ teximagemultisample(GLuint dims, GLenum target, GLsizei
samples,
}
texObj = _mesa_get_current_tex_object(ctx, target);
+
+ if (immutable (!texObj || (texObj-Name == 0))) {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+%s(texture object 0),
+func);
+ return;
+ }
+
texImage = _mesa_get_tex_image(ctx, texObj, 0, 0);
if (texImage == NULL) {
@@ -4278,6 +4295,13 @@ teximagemultisample(GLuint dims, GLenum target, GLsizei
samples,
return;
}
+ /* Check if texObj-Immutable is set */
+ if (texObj-Immutable) {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
glTexImage%uDMultisample(immutable),
+ dims);
+ return;
+ }
+
ctx-Driver.FreeTextureImageBuffer(ctx, texImage);
_mesa_init_teximage_fields(ctx, texImage,
@@ -4299,6 +4323,7 @@ teximagemultisample(GLuint dims, GLenum target, GLsizei
samples,
}
}
+ texObj-Immutable = immutable;
_mesa_update_fbo_texture(ctx, texObj, 0, 0);
}
}
@@ -4309,7 +4334,7 @@ _mesa_TexImage2DMultisample(GLenum target, GLsizei
samples,
GLsizei height, GLboolean fixedsamplelocations)
{
teximagemultisample(2, target, samples, internalformat,
- width, height, 1, fixedsamplelocations);
+ width, height, 1, fixedsamplelocations, GL_FALSE);
}
void GLAPIENTRY
@@ -4319,5 +4344,5 @@ _mesa_TexImage3DMultisample(GLenum target, GLsizei
samples,
GLboolean fixedsamplelocations)
{
teximagemultisample(3, target, samples, internalformat,
- width, height, depth, fixedsamplelocations);
+ width, height, depth, fixedsamplelocations, GL_FALSE);
}
--
1.8.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH V2 3/8] glapi: add definition of ARB_texture_storage_multisample
Adds XML for the extension, dispatch_sanity enabling, and the two new
entrypoints. These are both implemented by calling the shared
teximagemultisample() with immutable=GL_TRUE.
Signed-off-by: Chris Forbes chr...@ijw.co.nz
Reviewed-by: Eric Anholt e...@anholt.net
---
.../glapi/gen/ARB_texture_storage_multisample.xml | 31 ++
src/mapi/glapi/gen/gl_API.xml | 4 +++
src/mesa/main/tests/dispatch_sanity.cpp| 4 +--
src/mesa/main/teximage.c | 20 ++
src/mesa/main/teximage.h | 11
5 files changed, 68 insertions(+), 2 deletions(-)
create mode 100644 src/mapi/glapi/gen/ARB_texture_storage_multisample.xml
diff --git a/src/mapi/glapi/gen/ARB_texture_storage_multisample.xml
b/src/mapi/glapi/gen/ARB_texture_storage_multisample.xml
new file mode 100644
index 000..ebd8965
--- /dev/null
+++ b/src/mapi/glapi/gen/ARB_texture_storage_multisample.xml
@@ -0,0 +1,31 @@
+?xml version=1.0?
+!DOCTYPE OpenGLAPI SYSTEM gl_API.dtd
+
+!-- Note: no GLX protocol info yet. --
+
+OpenGLAPI
+
+category name=GL_ARB_texture_storage_multisample number=141
+
+ function name=TexStorage2DMultisample offset=assign
+ param name=target type=GLenum/
+ param name=samples type=GLsizei/
+ param name=internalformat type=GLint/
+ param name=width type=GLsizei/
+ param name=height type=GLsizei/
+ param name=fixedsamplelocations type=GLboolean/
+ /function
+
+ function name=TexStorage3DMultisample offset=assign
+ param name=target type=GLenum/
+ param name=samples type=GLsizei/
+ param name=internalformat type=GLint/
+ param name=width type=GLsizei/
+ param name=height type=GLsizei/
+ param name=depth type=GLsizei/
+ param name=fixedsamplelocations type=GLboolean/
+ /function
+
+/category
+
+/OpenGLAPI
diff --git a/src/mapi/glapi/gen/gl_API.xml b/src/mapi/glapi/gen/gl_API.xml
index 75957dc..df95924 100644
--- a/src/mapi/glapi/gen/gl_API.xml
+++ b/src/mapi/glapi/gen/gl_API.xml
@@ -8321,6 +8321,10 @@
xi:include href=ARB_texture_buffer_range.xml
xmlns:xi=http://www.w3.org/2001/XInclude/
+!-- 140. GL_ARB_texture_query_levels --
+
+xi:include href=ARB_texture_storage_multisample.xml
xmlns:xi=http://www.w3.org/2001/XInclude/
+
!-- Non-ARB extensions sorted by extension number. --
category name=GL_EXT_blend_color number=2
diff --git a/src/mesa/main/tests/dispatch_sanity.cpp
b/src/mesa/main/tests/dispatch_sanity.cpp
index 3431ded..ffd83fe 100644
--- a/src/mesa/main/tests/dispatch_sanity.cpp
+++ b/src/mesa/main/tests/dispatch_sanity.cpp
@@ -895,8 +895,8 @@ const struct function gl_core_functions_possible[] = {
// { glShaderStorageBlockBinding, 43, -1 }, // XXX: Add to xml
{ glTexBufferRange, 43, -1 },
// { glTextureBufferRangeEXT, 43, -1 }, // XXX: Add to xml
-// { glTexStorage2DMultisample, 43, -1 }, // XXX: Add to xml
-// { glTexStorage3DMultisample, 43, -1 }, // XXX: Add to xml
+ { glTexStorage2DMultisample, 43, -1 },
+ { glTexStorage3DMultisample, 43, -1 },
// { glTextureStorage2DMultisampleEXT, 43, -1 }, // XXX: Add to xml
// { glTextureStorage3DMultisampleEXT, 43, -1 }, // XXX: Add to xml
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index d7de69b..68e42a7 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -4346,3 +4346,23 @@ _mesa_TexImage3DMultisample(GLenum target, GLsizei
samples,
teximagemultisample(3, target, samples, internalformat,
width, height, depth, fixedsamplelocations, GL_FALSE);
}
+
+
+void GLAPIENTRY
+_mesa_TexStorage2DMultisample(GLenum target, GLsizei samples,
+ GLint internalformat, GLsizei width,
+ GLsizei height, GLboolean fixedsamplelocations)
+{
+ teximagemultisample(2, target, samples, internalformat,
+ width, height, 1, fixedsamplelocations, GL_TRUE);
+}
+
+void GLAPIENTRY
+_mesa_TexStorage3DMultisample(GLenum target, GLsizei samples,
+ GLint internalformat, GLsizei width,
+ GLsizei height, GLsizei depth,
+ GLboolean fixedsamplelocations)
+{
+ teximagemultisample(3, target, samples, internalformat,
+ width, height, depth, fixedsamplelocations, GL_TRUE);
+}
diff --git a/src/mesa/main/teximage.h b/src/mesa/main/teximage.h
index 744c47a..cedd933 100644
--- a/src/mesa/main/teximage.h
+++ b/src/mesa/main/teximage.h
@@ -305,6 +305,17 @@ _mesa_TexImage3DMultisample(GLenum target, GLsizei samples,
GLsizei height, GLsizei depth,
GLboolean fixedsamplelocations);
+extern void GLAPIENTRY
+_mesa_TexStorage2DMultisample(GLenum target, GLsizei samples,
+ GLint internalformat, GLsizei width,
+ GLsizei height, GLboolean
[Mesa-dev] [PATCH V2 4/8] mesa: add enable bit for ARB_texture_storage_multisample
Signed-off-by: Chris Forbes chr...@ijw.co.nz
Reviewed-by: Eric Anholt e...@anholt.net
---
src/mesa/main/extensions.c | 1 +
src/mesa/main/mtypes.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
index e90a296..004fc8e 100644
--- a/src/mesa/main/extensions.c
+++ b/src/mesa/main/extensions.c
@@ -148,6 +148,7 @@ static const struct extension extension_table[] = {
{ GL_ARB_texture_rgb10_a2ui, o(ARB_texture_rgb10_a2ui),
GL, 2009 },
{ GL_ARB_texture_rg, o(ARB_texture_rg),
GL, 2008 },
{ GL_ARB_texture_storage, o(ARB_texture_storage),
GL, 2011 },
+ { GL_ARB_texture_storage_multisample,
o(ARB_texture_storage_multisample), GL, 2012 },
{ GL_ARB_texture_swizzle, o(EXT_texture_swizzle),
GL, 2008 },
{ GL_ARB_timer_query, o(ARB_timer_query),
GL, 2010 },
{ GL_ARB_transform_feedback2, o(ARB_transform_feedback2),
GL, 2010 },
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index a0e7e28..bba9af0 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -3005,6 +3005,7 @@ struct gl_extensions
GLboolean ARB_texture_rg;
GLboolean ARB_texture_rgb10_a2ui;
GLboolean ARB_texture_storage;
+ GLboolean ARB_texture_storage_multisample;
GLboolean ARB_timer_query;
GLboolean ARB_transform_feedback2;
GLboolean ARB_transform_feedback3;
--
1.8.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH V2 5/8] mesa: improve reported function name in Tex*Multisample
Now that there are 4 variants, just pass the function name into
teximagemultisample rather than reconstructing it.
Signed-off-by: Chris Forbes chr...@ijw.co.nz
Reviewed-by: Eric Anholt e...@anholt.net
---
src/mesa/main/teximage.c | 30 ++
1 file changed, 14 insertions(+), 16 deletions(-)
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 68e42a7..ccdb95a 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -4196,7 +4196,7 @@ static void
teximagemultisample(GLuint dims, GLenum target, GLsizei samples,
GLint internalformat, GLsizei width, GLsizei height,
GLsizei depth, GLboolean fixedsamplelocations,
-GLboolean immutable)
+GLboolean immutable, const char *func)
{
struct gl_texture_object *texObj;
struct gl_texture_image *texImage;
@@ -4208,12 +4208,12 @@ teximagemultisample(GLuint dims, GLenum target, GLsizei
samples,
if (!(ctx-Extensions.ARB_texture_multisample
_mesa_is_desktop_gl(ctx))) {
- _mesa_error(ctx, GL_INVALID_OPERATION, glTexImage%uDMultisample, dims);
+ _mesa_error(ctx, GL_INVALID_OPERATION, %s(unsupported), func);
return;
}
if (!check_multisample_target(dims, target)) {
- _mesa_error(ctx, GL_INVALID_ENUM, glTexImage%uDMultisample(target),
dims);
+ _mesa_error(ctx, GL_INVALID_ENUM, %s(target), func);
return;
}
@@ -4230,16 +4230,15 @@ teximagemultisample(GLuint dims, GLenum target, GLsizei
samples,
if (!is_renderable_texture_format(ctx, internalformat)) {
_mesa_error(ctx, GL_INVALID_OPERATION,
-glTexImage%uDMultisample(internalformat=%s),
-dims,
-_mesa_lookup_enum_by_nr(internalformat));
+%s(internalformat=%s),
+func, _mesa_lookup_enum_by_nr(internalformat));
return;
}
sample_count_error = _mesa_check_sample_count(ctx, target,
internalformat, samples);
if (sample_count_error != GL_NO_ERROR) {
- _mesa_error(ctx, sample_count_error,
glTexImage%uDMultisample(samples), dims);
+ _mesa_error(ctx, sample_count_error, %s(samples), func);
return;
}
@@ -4255,7 +4254,7 @@ teximagemultisample(GLuint dims, GLenum target, GLsizei
samples,
texImage = _mesa_get_tex_image(ctx, texObj, 0, 0);
if (texImage == NULL) {
- _mesa_error(ctx, GL_OUT_OF_MEMORY, glTexImage%uDMultisample(), dims);
+ _mesa_error(ctx, GL_OUT_OF_MEMORY, %s(), func);
return;
}
@@ -4285,20 +4284,19 @@ teximagemultisample(GLuint dims, GLenum target, GLsizei
samples,
else {
if (!dimensionsOK) {
_mesa_error(ctx, GL_INVALID_VALUE,
- glTexImage%uDMultisample(invalid width or height), dims);
+ %s(invalid width or height), func);
return;
}
if (!sizeOK) {
_mesa_error(ctx, GL_OUT_OF_MEMORY,
- glTexImage%uDMultisample(texture too large), dims);
+ %s(texture too large), func);
return;
}
/* Check if texObj-Immutable is set */
if (texObj-Immutable) {
- _mesa_error(ctx, GL_INVALID_OPERATION,
glTexImage%uDMultisample(immutable),
- dims);
+ _mesa_error(ctx, GL_INVALID_OPERATION, %s(immutable), func);
return;
}
@@ -4334,7 +4332,7 @@ _mesa_TexImage2DMultisample(GLenum target, GLsizei
samples,
GLsizei height, GLboolean fixedsamplelocations)
{
teximagemultisample(2, target, samples, internalformat,
- width, height, 1, fixedsamplelocations, GL_FALSE);
+ width, height, 1, fixedsamplelocations, GL_FALSE,
glTexImage2DMultisample);
}
void GLAPIENTRY
@@ -4344,7 +4342,7 @@ _mesa_TexImage3DMultisample(GLenum target, GLsizei
samples,
GLboolean fixedsamplelocations)
{
teximagemultisample(3, target, samples, internalformat,
- width, height, depth, fixedsamplelocations, GL_FALSE);
+ width, height, depth, fixedsamplelocations, GL_FALSE,
glTexImage3DMultisample);
}
@@ -4354,7 +4352,7 @@ _mesa_TexStorage2DMultisample(GLenum target, GLsizei
samples,
GLsizei height, GLboolean fixedsamplelocations)
{
teximagemultisample(2, target, samples, internalformat,
- width, height, 1, fixedsamplelocations, GL_TRUE);
+ width, height, 1, fixedsamplelocations, GL_TRUE,
glTexStorage2DMultisample);
}
void GLAPIENTRY
@@ -4364,5 +4362,5 @@ _mesa_TexStorage3DMultisample(GLenum target, GLsizei
samples,
GLboolean fixedsamplelocations)
{
teximagemultisample(3, target, samples, internalformat,
- width, height, depth, fixedsamplelocations, GL_TRUE);
+ width, height, depth, fixedsamplelocations, GL_TRUE,
glTexStorage3DMultisample);
}
--
1.8.2
___
mesa-dev
[Mesa-dev] [PATCH V2 6/8] mesa: allow multisample texture targets in [Get]TexParameter*
ARB_texture_storage_multisample allows texture parameters to be
queried for TEXTURE_2D_MULTISAMPLE and TEXTURE_2D_MULTISAMPLE_ARRAY
targets.
Some parameters may also be set, with the following exceptions:
- TEXTURE_BASE_LEVEL may not be set to a nonzero value; generates
INVALID_OPERATION
- any state which appears in the `per-sampler` state table may not
be set; generates INVALID_OPERATION
V2: Don't introduce bogus handling of TEXTURE_MAX_LEVEL
Signed-off-by: Chris Forbes chr...@ijw.co.nz
Reviewed-by: Eric Anholt e...@anholt.net
---
src/mesa/main/texparam.c | 88 +++-
1 file changed, 87 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/texparam.c b/src/mesa/main/texparam.c
index bd2f751..898eabd 100644
--- a/src/mesa/main/texparam.c
+++ b/src/mesa/main/texparam.c
@@ -175,6 +175,16 @@ get_texobj(struct gl_context *ctx, GLenum target,
GLboolean get)
return texUnit-CurrentTex[TEXTURE_CUBE_ARRAY_INDEX];
}
break;
+ case GL_TEXTURE_2D_MULTISAMPLE:
+ if (ctx-Extensions.ARB_texture_storage_multisample) {
+ return texUnit-CurrentTex[TEXTURE_2D_MULTISAMPLE_INDEX];
+ }
+ break;
+ case GL_TEXTURE_2D_MULTISAMPLE_ARRAY:
+ if (ctx-Extensions.ARB_texture_storage_multisample) {
+ return texUnit-CurrentTex[TEXTURE_2D_MULTISAMPLE_ARRAY_INDEX];
+ }
+ break;
default:
;
}
@@ -250,6 +260,20 @@ incomplete(struct gl_context *ctx, struct
gl_texture_object *texObj)
}
+static GLboolean
+target_allows_setting_sampler_parameters(GLenum target)
+{
+ switch (target) {
+ case GL_TEXTURE_2D_MULTISAMPLE:
+ case GL_TEXTURE_2D_MULTISAMPLE_ARRAY:
+ return GL_FALSE;
+
+ default:
+ return GL_TRUE;
+ }
+}
+
+
/**
* Set an integer-valued texture parameter
* \return GL_TRUE if legal AND the value changed, GL_FALSE otherwise
@@ -261,6 +285,9 @@ set_tex_parameteri(struct gl_context *ctx,
{
switch (pname) {
case GL_TEXTURE_MIN_FILTER:
+ if (!target_allows_setting_sampler_parameters(texObj-Target))
+ goto invalid_operation;
+
if (texObj-Sampler.MinFilter == params[0])
return GL_FALSE;
switch (params[0]) {
@@ -286,6 +313,9 @@ set_tex_parameteri(struct gl_context *ctx,
return GL_FALSE;
case GL_TEXTURE_MAG_FILTER:
+ if (!target_allows_setting_sampler_parameters(texObj-Target))
+ goto invalid_operation;
+
if (texObj-Sampler.MagFilter == params[0])
return GL_FALSE;
switch (params[0]) {
@@ -300,6 +330,9 @@ set_tex_parameteri(struct gl_context *ctx,
return GL_FALSE;
case GL_TEXTURE_WRAP_S:
+ if (!target_allows_setting_sampler_parameters(texObj-Target))
+ goto invalid_operation;
+
if (texObj-Sampler.WrapS == params[0])
return GL_FALSE;
if (validate_texture_wrap_mode(ctx, texObj-Target, params[0])) {
@@ -310,6 +343,9 @@ set_tex_parameteri(struct gl_context *ctx,
return GL_FALSE;
case GL_TEXTURE_WRAP_T:
+ if (!target_allows_setting_sampler_parameters(texObj-Target))
+ goto invalid_operation;
+
if (texObj-Sampler.WrapT == params[0])
return GL_FALSE;
if (validate_texture_wrap_mode(ctx, texObj-Target, params[0])) {
@@ -320,6 +356,9 @@ set_tex_parameteri(struct gl_context *ctx,
return GL_FALSE;
case GL_TEXTURE_WRAP_R:
+ if (!target_allows_setting_sampler_parameters(texObj-Target))
+ goto invalid_operation;
+
if (texObj-Sampler.WrapR == params[0])
return GL_FALSE;
if (validate_texture_wrap_mode(ctx, texObj-Target, params[0])) {
@@ -335,6 +374,11 @@ set_tex_parameteri(struct gl_context *ctx,
if (texObj-BaseLevel == params[0])
return GL_FALSE;
+
+ if ((texObj-Target == GL_TEXTURE_2D_MULTISAMPLE ||
+ texObj-Target == GL_TEXTURE_2D_MULTISAMPLE_ARRAY) params[0] !=
0)
+ goto invalid_operation;
+
if (params[0] 0 ||
(texObj-Target == GL_TEXTURE_RECTANGLE_ARB params[0] != 0)) {
_mesa_error(ctx, GL_INVALID_VALUE,
@@ -348,6 +392,7 @@ set_tex_parameteri(struct gl_context *ctx,
case GL_TEXTURE_MAX_LEVEL:
if (texObj-MaxLevel == params[0])
return GL_FALSE;
+
if (params[0] 0 || texObj-Target == GL_TEXTURE_RECTANGLE_ARB) {
_mesa_error(ctx, GL_INVALID_VALUE,
glTexParameter(param=%d), params[0]);
@@ -373,6 +418,10 @@ set_tex_parameteri(struct gl_context *ctx,
case GL_TEXTURE_COMPARE_MODE_ARB:
if ((_mesa_is_desktop_gl(ctx) ctx-Extensions.ARB_shadow)
|| _mesa_is_gles3(ctx)) {
+
+ if (!target_allows_setting_sampler_parameters(texObj-Target))
+goto invalid_operation;
+
if (texObj-Sampler.CompareMode == params[0])
return GL_FALSE;
if (params[0] == GL_NONE ||
@@ -388,6 +437,10 @@ set_tex_parameteri(struct gl_context *ctx,
case GL_TEXTURE_COMPARE_FUNC_ARB:
[Mesa-dev] [PATCH V2 7/8] i965: enable ARB_texture_storage_multisample on Gen6+
This can be enabled everywhere that ARB_texture_multisample is supported -- ARB_texture_storage is supported on everything. Signed-off-by: Chris Forbes chr...@ijw.co.nz Reviewed-by: Eric Anholt e...@anholt.net --- src/mesa/drivers/dri/intel/intel_extensions.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/mesa/drivers/dri/intel/intel_extensions.c b/src/mesa/drivers/dri/intel/intel_extensions.c index 332fdd8..edac4d7 100755 --- a/src/mesa/drivers/dri/intel/intel_extensions.c +++ b/src/mesa/drivers/dri/intel/intel_extensions.c @@ -108,6 +108,7 @@ intelInitExtensions(struct gl_context *ctx) ctx-Extensions.OES_depth_texture_cube_map = true; ctx-Extensions.ARB_shading_language_packing = true; ctx-Extensions.ARB_texture_multisample = true; + ctx-Extensions.ARB_texture_storage_multisample = true; } if (intel-gen = 5) -- 1.8.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH V2 8/8] docs: mark ARB_texture_storage_multisample done
Signed-off-by: Chris Forbes chr...@ijw.co.nz Reviewed-by: Eric Anholt e...@anholt.net --- docs/GL3.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/GL3.txt b/docs/GL3.txt index 640dec2..898d921 100644 --- a/docs/GL3.txt +++ b/docs/GL3.txt @@ -151,7 +151,7 @@ ARB_shader_storage_buffer_object not started ARB_stencil_texturingnot started ARB_texture_buffer_range DONE (nv50, nvc0) ARB_texture_query_levels not started -ARB_texture_storage_multisample not started +ARB_texture_storage_multisample DONE (i965) ARB_texture_view not started ARB_vertex_attrib_bindingnot started -- 1.8.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] mesa : ARB_texture_gather implementation - WIP[PATCH1/1] but need advice !
I've got this working now (in the simplest cases) on Ivybridge. If anyone is curious, the (messy) git trees are at http://github.com/chrisforbes/mesa.git arb_texture_gather http://github.com/chrisforbes/piglit.git texture_gather Nowhere near ready for review, but it's a start. Remaining things for the Intel side: - texture swizzle interaction - VS support - offset support -- it looks like we have to use gather4_po if the offset is incoherent within the thread. maybe we don't even try, and just use it all the time. - figure out if we can actually do this on Gen6 at all. And non-intel: - resurrect the Gallium bits (I know almost nothing about Gallium, but I guess I'm about to learn) - lots more tests -- Chris On Mon, Mar 25, 2013 at 10:33 AM, Maxence Le Doré maxence.led...@gmail.com wrote: You are right. Better asking. I would like to help you on the piglit side but i'm almost sure I won't be really efficient for it at this time. But certainly for other features in the coming weeks/months. Le 24/03/2013 22:29, Chris Forbes a écrit : Hi OK, thanks. Just thought I'd ask :) -- Chris On Mon, Mar 25, 2013 at 10:23 AM, Maxence Le Doré maxence.led...@gmail.com wrote: Hi, Haven't written any test. And I won't have the time for, as I consider writing some for over features. Le 24/03/2013 10:14, Chris Forbes a écrit : Hi Did you have any piglit tests to go with these? I've got a reasonable set working now, but the more the better. -- Chris On Wed, Mar 20, 2013 at 11:55 AM, Chris Forbes chr...@ijw.co.nz wrote: Hi Thanks for the updated patches -- that makes my work a lot easier. I'll have something for the mailing list soon. -- Chris On Wed, Mar 20, 2013 at 11:48 AM, Maxence Le Doré maxence.led...@gmail.com wrote: Pick it ! But start from the patch set joined to this mail ! It includes all suggstions made by Kenneth and are rebased for today master branch. Just keep in mind that the exec_tg4 function ( from tgsi_exec.c) is almost a copy-cut from another texture exec function and that it won't produce correct texture gathering results. I have not been able to enough understand the design of the sampling units of the softpipe driver to achieve its support for TG4. Missing code area are just marked /* XXX ... */. Really hope you'll sucess at it :) 2013/3/19 Chris Forbes chr...@ijw.co.nz Hi Maxence, Do you mind if I pick up this patch and finish it off? I'll do the i965 side too while I'm at it. -- Chris On Tue, Nov 13, 2012 at 6:03 PM, Maxence Le Doré maxence.led...@gmail.com wrote: Here is a patch against master branch that takes a good way to implement ARB_texture_gather over softpipe but I have the regret to announce that I can't find what i'm doing wrong at a point : At compilation time, more precisely glsl code compilation, a file builtin_function.cpp is generated by python scripts, feed .glsl/.frag/.vert./.ir files. I've done created the file that declares the texture gather builtin functions and modified the python scripts that generated IR for texture functions. But the buitin compiler complains about wrong prototypes and leads to the production of a invalid builtin_function.cpp file. It's a little more irritating when I have the feeling to have exactly done as Dave Airlied has done to implement ARB_texture_cube_map_array builtins GLSL func few days ago. But that's wrong and I can figure out. It sounds silly even to myself. I'm pretty sure it's a lack of attention from me but i'm really blocked. Some help are really welcome. I'm working heavly on over features but texture gather support should be done before, this is why I try to implement it. The code ? From a17be83a8cbad91f1567c464a1a391fd345c8f93 Mon Sep 17 00:00:00 2001 From: Maxence Le Dore maxence.led...@gmail.com Date: Sat, 20 Oct 2012 02:31:41 +0200 Subject: [PATCH] texture_gather --- src/gallium/auxiliary/tgsi/tgsi_exec.c | 74 +- src/gallium/drivers/llvmpipe/lp_screen.c |3 ++ src/gallium/drivers/softpipe/sp_screen.c |6 +++ src/gallium/drivers/softpipe/sp_tex_sample.c |8 +++ src/gallium/include/pipe/p_defines.h |5 +- src/glsl/builtins/tools/generate_builtins.py |1 + src/glsl/builtins/tools/texture_builtins.py | 14 - src/glsl/glcpp/glcpp-parse.y |3 ++ src/glsl/glsl_parser_extras.cpp |1 + src/glsl/glsl_parser_extras.h|2 + src/glsl/ir.cpp |2 +- src/glsl/ir.h|4 +- src/glsl/ir_clone.cpp|1 + src/glsl/ir_hv_accept.cpp|1 + src/glsl/ir_print_visitor.cpp|3 +- src/glsl/ir_rvalue_visitor.cpp |1 + src/glsl/opt_tree_grafting.cpp |1 + src/glsl/standalone_scaffolding.cpp
Re: [Mesa-dev] [PATCH] r600g: fix range handling for tgsi input/output declarations
Am 28.03.2013 20:34, schrieb Vadim Girlin:
On 03/28/2013 01:01 PM, � wrote:
Am 27.03.2013 20:37, schrieb Vadim Girlin:
Signed-off-by: Vadim Girlin vadimgir...@gmail.com
---
src/gallium/drivers/r600/r600_shader.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_shader.c
b/src/gallium/drivers/r600/r600_shader.c
index 29facf7..d4c9c03 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -874,12 +874,12 @@ static int select_twoside_color(struct
r600_shader_ctx *ctx, int front, int back
static int tgsi_declaration(struct r600_shader_ctx *ctx)
{
struct tgsi_full_declaration *d =
ctx-parse.FullToken.FullDeclaration;
-unsigned i;
-int r;
+int r, i, j, count = d-Range.Last - d-Range.First + 1;
switch (d-Declaration.File) {
case TGSI_FILE_INPUT:
-i = ctx-shader-ninput++;
+i = ctx-shader-ninput;
+ctx-shader-ninput += count;
ctx-shader-input[i].name = d-Semantic.Name;
ctx-shader-input[i].sid = d-Semantic.Index;
ctx-shader-input[i].interpolate = d-Interp.Interpolate;
@@ -903,9 +903,15 @@ static int tgsi_declaration(struct
r600_shader_ctx *ctx)
return r;
}
}
+for (j = 1; j count; ++j) {
+memcpy(ctx-shader-input[i + j], ctx-shader-input[i],
+ sizeof(struct r600_shader_io));
Instead of memcpy, shouldn't an assignment do the trick here as well?
Yes, assignment should work fine, I just used to use memcpy in such
cases for some reason. I'll replace memcpy with assignment.
Also I think second part (outputs handling) can be dropped for now -
currently we only need to handle the inputs (for HUD shaders), and
later when array declarations for inputs/outputs will be implemented
in TGSI probably we'll need to update the parser in r600g anyway - I'm
just not sure yet how the semantic indices should be handled for
input/output arrays.
Yeah, the uncertainly about semantic IDs was one of the reasons I didn't
wanted to do Input/Output arrays in the initial array implementation.
When those changes are the only one then v2 of the patch is:
Reviewed-by: Christian König christian.koe...@amd.com
Christian.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] draw/so: Fix bogus assert
- Original Message -
We do support so with multiple primitives.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/draw/draw_so_emit_tmp.h |1 -
1 file changed, 1 deletion(-)
diff --git a/src/gallium/auxiliary/draw/draw_so_emit_tmp.h
b/src/gallium/auxiliary/draw/draw_so_emit_tmp.h
index ec31c3f..4611cd0 100644
--- a/src/gallium/auxiliary/draw/draw_so_emit_tmp.h
+++ b/src/gallium/auxiliary/draw/draw_so_emit_tmp.h
@@ -12,7 +12,6 @@
const boolean quads_flatshade_last = FALSE;\
const boolean last_vertex_last = TRUE; \
do { \
- debug_assert(input_prims-primitive_count == 1);\
switch (prim) { \
case PIPE_PRIM_LINES_ADJACENCY: \
case PIPE_PRIM_LINE_STRIP_ADJACENCY:\
--
1.7.10.4
Reviewed-by: Jose Fonseca jfons...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallivm: cleanup the gs interface
Thanks for the cleanup.
Reviewed-by: Jose Fonseca jfons...@vmware.com
Jose
- Original Message -
Instead of void pointers use a base interface.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/draw/draw_llvm.c | 77
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi.h | 25
src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c | 31 -
3 files changed, 83 insertions(+), 50 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_llvm.c
b/src/gallium/auxiliary/draw/draw_llvm.c
index 3ce48d8..efbcb04 100644
--- a/src/gallium/auxiliary/draw/draw_llvm.c
+++ b/src/gallium/auxiliary/draw/draw_llvm.c
@@ -64,6 +64,13 @@ draw_llvm_generate(struct draw_llvm *llvm, struct
draw_llvm_variant *var,
boolean elts);
+struct draw_gs_llvm_iface {
+ struct lp_build_tgsi_gs_iface base;
+
+ struct draw_gs_llvm_variant *variant;
+ LLVMValueRef input;
+};
+
/**
* Create LLVM type for struct draw_jit_texture
*/
@@ -1237,14 +1244,39 @@ clipmask_booli32(struct gallivm_state *gallivm,
return ret;
}
+static LLVMValueRef
+draw_gs_llvm_fetch_input(const struct lp_build_tgsi_gs_iface *gs_iface,
+ struct lp_build_tgsi_context * bld_base,
+ LLVMValueRef vertex_index,
+ LLVMValueRef attrib_index,
+ LLVMValueRef swizzle_index)
+{
+ const struct draw_gs_llvm_iface *gs =
+ (const struct draw_gs_llvm_iface *)gs_iface;
+ struct gallivm_state *gallivm = bld_base-base.gallivm;
+ LLVMBuilderRef builder = gallivm-builder;
+ LLVMValueRef indices[3];
+ LLVMValueRef res;
+
+ indices[0] = vertex_index;
+ indices[1] = attrib_index;
+ indices[2] = swizzle_index;
+
+ res = LLVMBuildGEP(builder, gs-input, indices, 3, );
+ res = LLVMBuildLoad(builder, res, );
+
+ return res;
+}
+
static void
-draw_gs_llvm_emit_vertex(struct lp_build_tgsi_context * bld_base,
+draw_gs_llvm_emit_vertex(const struct lp_build_tgsi_gs_iface *gs_base,
+ struct lp_build_tgsi_context * bld_base,
LLVMValueRef (*outputs)[4],
- LLVMValueRef emitted_vertices_vec,
- void *user_data)
+ LLVMValueRef emitted_vertices_vec)
{
- struct draw_gs_llvm_variant *variant =
- (struct draw_gs_llvm_variant *)user_data;
+ const struct draw_gs_llvm_iface *gs_iface =
+ (const struct draw_gs_llvm_iface *)gs_base;
+ struct draw_gs_llvm_variant *variant = gs_iface-variant;
struct gallivm_state *gallivm = variant-gallivm;
LLVMBuilderRef builder = gallivm-builder;
struct lp_type gs_type = bld_base-base.type;
@@ -1272,13 +1304,14 @@ draw_gs_llvm_emit_vertex(struct lp_build_tgsi_context
* bld_base,
}
static void
-draw_gs_llvm_end_primitive(struct lp_build_tgsi_context * bld_base,
+draw_gs_llvm_end_primitive(const struct lp_build_tgsi_gs_iface *gs_base,
+ struct lp_build_tgsi_context * bld_base,
LLVMValueRef verts_per_prim_vec,
- LLVMValueRef emitted_prims_vec,
- void *user_data)
+ LLVMValueRef emitted_prims_vec)
{
- struct draw_gs_llvm_variant *variant =
- (struct draw_gs_llvm_variant *)user_data;
+ const struct draw_gs_llvm_iface *gs_iface =
+ (const struct draw_gs_llvm_iface *)gs_base;
+ struct draw_gs_llvm_variant *variant = gs_iface-variant;
struct gallivm_state *gallivm = variant-gallivm;
LLVMBuilderRef builder = gallivm-builder;
LLVMValueRef prim_lengts_ptr =
@@ -1301,13 +1334,14 @@ draw_gs_llvm_end_primitive(struct
lp_build_tgsi_context * bld_base,
}
static void
-draw_gs_llvm_epilogue(struct lp_build_tgsi_context * bld_base,
+draw_gs_llvm_epilogue(const struct lp_build_tgsi_gs_iface *gs_base,
+ struct lp_build_tgsi_context * bld_base,
LLVMValueRef total_emitted_vertices_vec,
- LLVMValueRef emitted_prims_vec,
- void *user_data)
+ LLVMValueRef emitted_prims_vec)
{
- struct draw_gs_llvm_variant *variant =
- (struct draw_gs_llvm_variant *)user_data;
+ const struct draw_gs_llvm_iface *gs_iface =
+ (const struct draw_gs_llvm_iface *)gs_base;
+ struct draw_gs_llvm_variant *variant = gs_iface-variant;
struct gallivm_state *gallivm = variant-gallivm;
LLVMBuilderRef builder = gallivm-builder;
LLVMValueRef emitted_verts_ptr =
@@ -1867,7 +1901,7 @@ draw_gs_llvm_generate(struct draw_llvm *llvm,
struct lp_bld_tgsi_system_values system_values;
struct lp_type gs_type;
unsigned i;
- struct lp_build_tgsi_gs_iface gs_iface;
+ struct draw_gs_llvm_iface gs_iface;
const struct tgsi_token *tokens =
Re: [Mesa-dev] [PATCH] docs: add a new page documenting known application issues
Looks good to me Brian. Just a couple of comments. - Original Message - Let's try to update this when we find other broken applications... docs/ is growing a lot of stuff, with disparate target audiences. Maybe we could establish some sort of directory hierachary there: docs/apps/index.html docs/apps/viewperf.html docs/relnotes/1.2.3.4.5.html docs/specs/ docs/devel/ So that target readers can more easily find stuff that's most relevant for them. --- docs/application-issues.html | 83 ++ docs/contents.html | 1 + 2 files changed, 84 insertions(+), 0 deletions(-) create mode 100644 docs/application-issues.html diff --git a/docs/application-issues.html b/docs/application-issues.html new file mode 100644 index 000..6db0865 --- /dev/null +++ b/docs/application-issues.html @@ -0,0 +1,83 @@ +!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN http://www.w3.org/TR/html4/loose.dtd; +html lang=en +head + meta http-equiv=content-type content=text/html; charset=utf-8 + titleApplication Issues/title + link rel=stylesheet type=text/css href=mesa.css +/head +body + +div class=header + h1The Mesa 3D Graphics Library/h1 +/div + +iframe src=contents.html/iframe +div class=content + +h1Application Issues/h1 + +p +This page documents known issues with some OpenGL applications. +/p + + +h2Topogun/h2 + +p +a href=http://www.topogun.com/;Topogun/a for Linux (version 2, at least) +creates a GLX visual without requesting a depth buffer. +This causes bad rendering if the OpenGL driver happens to choose a visual +without a depth buffer. +/p + +p +Mesa 9.1.2 and later (will) support a DRI configuration option to work around +this issue. +Using the a href=http://dri.freedesktop.org/wiki/DriConf;driconf/a tool, +set the Create all visuals with a depth buffer option before running Topogun. +Then, all GLX visuals will be created with a depth buffer. +/p + BTW, do users need to manually configure this, or will it be automatically set based on process name? Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r600g: fix range handling for tgsi input/output declarations
On 29.03.2013 10:56, Christian König wrote:
Am 28.03.2013 20:34, schrieb Vadim Girlin:
On 03/28/2013 01:01 PM, � wrote:
Am 27.03.2013 20:37, schrieb Vadim Girlin:
Signed-off-by: Vadim Girlin vadimgir...@gmail.com
---
src/gallium/drivers/r600/r600_shader.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_shader.c
b/src/gallium/drivers/r600/r600_shader.c
index 29facf7..d4c9c03 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -874,12 +874,12 @@ static int select_twoside_color(struct
r600_shader_ctx *ctx, int front, int back
static int tgsi_declaration(struct r600_shader_ctx *ctx)
{
struct tgsi_full_declaration *d =
ctx-parse.FullToken.FullDeclaration;
-unsigned i;
-int r;
+int r, i, j, count = d-Range.Last - d-Range.First + 1;
switch (d-Declaration.File) {
case TGSI_FILE_INPUT:
-i = ctx-shader-ninput++;
+i = ctx-shader-ninput;
+ctx-shader-ninput += count;
ctx-shader-input[i].name = d-Semantic.Name;
ctx-shader-input[i].sid = d-Semantic.Index;
ctx-shader-input[i].interpolate = d-Interp.Interpolate;
@@ -903,9 +903,15 @@ static int tgsi_declaration(struct
r600_shader_ctx *ctx)
return r;
}
}
+for (j = 1; j count; ++j) {
+memcpy(ctx-shader-input[i + j],
ctx-shader-input[i],
+ sizeof(struct r600_shader_io));
Instead of memcpy, shouldn't an assignment do the trick here as well?
Yes, assignment should work fine, I just used to use memcpy in such
cases for some reason. I'll replace memcpy with assignment.
Also I think second part (outputs handling) can be dropped for now -
currently we only need to handle the inputs (for HUD shaders), and
later when array declarations for inputs/outputs will be implemented
in TGSI probably we'll need to update the parser in r600g anyway -
I'm just not sure yet how the semantic indices should be handled for
input/output arrays.
The semantic indices are sequential, obviously. It gets more complex
with scalar arrays, but you don't have to worry about that in r600
because I'd probably add a cap for those.
Example: If you declare an out float a[8] layout(location = k) in GLSL
(as per ARB_separate_shader_objects), the 8 values are counted as
consuming 8 consecutive vec4 slots (here the user is responsible for
packing, nice !).
The location will be communicated via the semantic index. You'd get DCL
OUT[n..n+7] GENERIC[k] (or k+some_constant_offset because of st/mesa's
allocation policy).
If the consuming shader declares in float b[4] layout(location = k+4),
you'd get DCL IN[m..m+3] GENERIC[k+4], and this has to link with the
upper 4 components out the a[8] output.
Yeah, the uncertainly about semantic IDs was one of the reasons I
didn't wanted to do Input/Output arrays in the initial array
implementation.
When those changes are the only one then v2 of the patch is:
Reviewed-by: Christian König christian.koe...@amd.com
Christian.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/6] radeon/llvm: remove uneeded inclusion
Hi This include is also in src/gallium/state_trackers/clover/llvm/invocation.cpp diff -Naur a/src/gallium/state_trackers/clover/llvm/invocation.cpp b/src/gallium/state_trackers/clover/llvm/invocation.cpp --- a/src/gallium/state_trackers/clover/llvm/invocation.cpp 2013-03-29 11:15:52.851581526 + +++ b/src/gallium/state_trackers/clover/llvm/invocation.cpp2013-03-29 11:32:41.580559478 + @@ -37,7 +37,6 @@ #include llvm/IR/DerivedTypes.h #include llvm/IR/LLVMContext.h #include llvm/IR/Module.h -#include llvm/Support/IRReader.h #endif #include llvm/PassManager.h #include llvm/Support/TargetSelect.h Cheers Mike On 26 March 2013 12:11, Christian König deathsim...@vodafone.de wrote: Am 26.03.2013 12:53, schrieb Michel Dänzer: On Die, 2013-03-26 at 11:56 +0100, Christian König wrote: From: Christian König christian.koe...@amd.com The include isn't needed and the file has moved with LLVM master. Signed-off-by: Christian König christian.koe...@amd.com Reviewed-by: Michel Dänzer michel.daen...@amd.com The rest of the series seems unchanged, so my review of it stands. How about the LLVM changes? I know we could improve WQM now that it is in the backend, but I would rather like to let it stay like this for another round (as good or as bad as it is) and try to get this patchset committed first. Christian. __**_ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/**mailman/listinfo/mesa-devhttp://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gallium: add PIPE_CAP_QUERY_PIPELINE_STATISTICS
--- src/gallium/docs/source/screen.rst |2 ++ src/gallium/drivers/freedreno/freedreno_screen.c |1 + src/gallium/drivers/i915/i915_screen.c |1 + src/gallium/drivers/llvmpipe/lp_screen.c |2 ++ src/gallium/drivers/nv30/nv30_screen.c |1 + src/gallium/drivers/nv50/nv50_screen.c |2 ++ src/gallium/drivers/nvc0/nvc0_screen.c |1 + src/gallium/drivers/r300/r300_screen.c |1 + src/gallium/drivers/r600/r600_pipe.c |1 + src/gallium/drivers/radeonsi/radeonsi_pipe.c |1 + src/gallium/drivers/softpipe/sp_screen.c |2 ++ src/gallium/include/pipe/p_defines.h |3 ++- 12 files changed, 17 insertions(+), 1 deletions(-) diff --git a/src/gallium/docs/source/screen.rst b/src/gallium/docs/source/screen.rst index 8c7e86e..c1a3c0b 100644 --- a/src/gallium/docs/source/screen.rst +++ b/src/gallium/docs/source/screen.rst @@ -149,6 +149,8 @@ The integer capabilities: to use a blit to implement a texture transfer which needs format conversions and swizzling in state trackers. Generally, all hardware drivers with dedicated memory should return 1 and all software rasterizers should return 0. +* ``PIPE_CAP_QUERY_PIPELINE_STATISTICS``: Whether PIPE_QUERY_PIPELINE_STATISTICS + is supported. .. _pipe_capf: diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c b/src/gallium/drivers/freedreno/freedreno_screen.c index 79eef5e..283d07f 100644 --- a/src/gallium/drivers/freedreno/freedreno_screen.c +++ b/src/gallium/drivers/freedreno/freedreno_screen.c @@ -199,6 +199,7 @@ fd_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) case PIPE_CAP_VERTEX_COLOR_CLAMPED: case PIPE_CAP_USER_VERTEX_BUFFERS: case PIPE_CAP_USER_INDEX_BUFFERS: + case PIPE_CAP_QUERY_PIPELINE_STATISTICS: return 0; /* Stream output. */ diff --git a/src/gallium/drivers/i915/i915_screen.c b/src/gallium/drivers/i915/i915_screen.c index 13aa91c..54b2154 100644 --- a/src/gallium/drivers/i915/i915_screen.c +++ b/src/gallium/drivers/i915/i915_screen.c @@ -210,6 +210,7 @@ i915_get_param(struct pipe_screen *screen, enum pipe_cap cap) case PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION: case PIPE_CAP_START_INSTANCE: case PIPE_CAP_QUERY_TIMESTAMP: + case PIPE_CAP_QUERY_PIPELINE_STATISTICS: case PIPE_CAP_TEXTURE_MULTISAMPLE: case PIPE_CAP_MIN_MAP_BUFFER_ALIGNMENT: return 0; diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c b/src/gallium/drivers/llvmpipe/lp_screen.c index e8c6ab1..6700887 100644 --- a/src/gallium/drivers/llvmpipe/lp_screen.c +++ b/src/gallium/drivers/llvmpipe/lp_screen.c @@ -130,6 +130,8 @@ llvmpipe_get_param(struct pipe_screen *screen, enum pipe_cap param) return 0; case PIPE_CAP_QUERY_TIMESTAMP: return 1; + case PIPE_CAP_QUERY_PIPELINE_STATISTICS: + return 0; case PIPE_CAP_TEXTURE_MIRROR_CLAMP: return 1; case PIPE_CAP_TEXTURE_SHADOW_MAP: diff --git a/src/gallium/drivers/nv30/nv30_screen.c b/src/gallium/drivers/nv30/nv30_screen.c index 4084869..e33710e 100644 --- a/src/gallium/drivers/nv30/nv30_screen.c +++ b/src/gallium/drivers/nv30/nv30_screen.c @@ -122,6 +122,7 @@ nv30_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) case PIPE_CAP_MIN_MAP_BUFFER_ALIGNMENT: case PIPE_CAP_TEXTURE_BUFFER_OBJECTS: case PIPE_CAP_TEXTURE_BUFFER_OFFSET_ALIGNMENT: + case PIPE_CAP_QUERY_PIPELINE_STATISTICS: return 0; case PIPE_CAP_VERTEX_BUFFER_OFFSET_4BYTE_ALIGNED_ONLY: case PIPE_CAP_VERTEX_BUFFER_STRIDE_4BYTE_ALIGNED_ONLY: diff --git a/src/gallium/drivers/nv50/nv50_screen.c b/src/gallium/drivers/nv50/nv50_screen.c index 0a20ae3..53eeeb6 100644 --- a/src/gallium/drivers/nv50/nv50_screen.c +++ b/src/gallium/drivers/nv50/nv50_screen.c @@ -189,6 +189,8 @@ nv50_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) return 0; case PIPE_CAP_PREFER_BLIT_BASED_TEXTURE_TRANSFER: return 1; + case PIPE_CAP_QUERY_PIPELINE_STATISTICS: + return 0; default: NOUVEAU_ERR(unknown PIPE_CAP %d\n, param); return 0; diff --git a/src/gallium/drivers/nvc0/nvc0_screen.c b/src/gallium/drivers/nvc0/nvc0_screen.c index 5b9385a..3a32539 100644 --- a/src/gallium/drivers/nvc0/nvc0_screen.c +++ b/src/gallium/drivers/nvc0/nvc0_screen.c @@ -136,6 +136,7 @@ nvc0_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) case PIPE_CAP_QUERY_TIME_ELAPSED: case PIPE_CAP_OCCLUSION_QUERY: case PIPE_CAP_STREAM_OUTPUT_PAUSE_RESUME: + case PIPE_CAP_QUERY_PIPELINE_STATISTICS: return 1; case PIPE_CAP_MAX_STREAM_OUTPUT_BUFFERS: return 4; diff --git a/src/gallium/drivers/r300/r300_screen.c b/src/gallium/drivers/r300/r300_screen.c index bd16c3b..3175b3b 100644 --- a/src/gallium/drivers/r300/r300_screen.c +++ b/src/gallium/drivers/r300/r300_screen.c @@ -135,6
Re: [Mesa-dev] [PATCH 1/6] radeon/llvm: remove uneeded inclusion
Sorry that patch doesn't fix the build diff -Naur a/src/gallium/state_trackers/clover/llvm/invocation.cpp b/src/gallium/state_trackers/clover/llvm/invocation.cpp --- a/src/gallium/state_trackers/clover/llvm/invocation.cpp 2013-03-29 12:14:25.514504748 + +++ b/src/gallium/state_trackers/clover/llvm/invocation.cpp 2013-03-29 12:13:03.978506530 + @@ -37,7 +37,8 @@ #include llvm/IR/DerivedTypes.h #include llvm/IR/LLVMContext.h #include llvm/IR/Module.h -#include llvm/Support/IRReader.h +#include llvm/Support/SourceMgr.h +#include llvm/IRReader/IRReader.h #endif #include llvm/PassManager.h #include llvm/Support/TargetSelect.h This one does however On 29 March 2013 11:40, Mike Lothian m...@fireburn.co.uk wrote: Hi This include is also in src/gallium/state_trackers/clover/llvm/invocation.cpp diff -Naur a/src/gallium/state_trackers/clover/llvm/invocation.cpp b/src/gallium/state_trackers/clover/llvm/invocation.cpp --- a/src/gallium/state_trackers/clover/llvm/invocation.cpp 2013-03-29 11:15:52.851581526 + +++ b/src/gallium/state_trackers/clover/llvm/invocation.cpp2013-03-29 11:32:41.580559478 + @@ -37,7 +37,6 @@ #include llvm/IR/DerivedTypes.h #include llvm/IR/LLVMContext.h #include llvm/IR/Module.h -#include llvm/Support/IRReader.h #endif #include llvm/PassManager.h #include llvm/Support/TargetSelect.h Cheers Mike On 26 March 2013 12:11, Christian König deathsim...@vodafone.de wrote: Am 26.03.2013 12:53, schrieb Michel Dänzer: On Die, 2013-03-26 at 11:56 +0100, Christian König wrote: From: Christian König christian.koe...@amd.com The include isn't needed and the file has moved with LLVM master. Signed-off-by: Christian König christian.koe...@amd.com Reviewed-by: Michel Dänzer michel.daen...@amd.com The rest of the series seems unchanged, so my review of it stands. How about the LLVM changes? I know we could improve WQM now that it is in the backend, but I would rather like to let it stay like this for another round (as good or as bad as it is) and try to get this patchset committed first. Christian. __**_ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/**mailman/listinfo/mesa-devhttp://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gallium/hud: add support for PIPE_QUERY_PIPELINE_STATISTICS
Also, renamed pixels-rendered to samples-passed because the
occlusion counter increments even if colour and depth writes are
disabled, or (on some implementations) for killed that passed the
depth test when early_fragment_tests has been set for the PS.
---
src/gallium/auxiliary/hud/hud_context.c | 45 +++--
src/gallium/auxiliary/hud/hud_cpu.c |6 ++-
src/gallium/auxiliary/hud/hud_driver_query.c |8 +++--
src/gallium/auxiliary/hud/hud_private.h |1 +
4 files changed, 51 insertions(+), 9 deletions(-)
diff --git a/src/gallium/auxiliary/hud/hud_context.c
b/src/gallium/auxiliary/hud/hud_context.c
index 60355ca..cfb58a8 100644
--- a/src/gallium/auxiliary/hud/hud_context.c
+++ b/src/gallium/auxiliary/hud/hud_context.c
@@ -90,6 +90,10 @@ struct hud_context {
unsigned max_num_vertices;
unsigned num_vertices;
} text, bg, whitelines;
+
+ struct {
+ boolean query_pipeline_statistics;
+ } cap;
};
@@ -716,15 +720,45 @@ hud_parse_env_var(struct hud_context *hud, const char
*env)
else if (sscanf(name, cpu%u%s, i, s) == 1) {
hud_cpu_graph_install(pane, i);
}
- else if (strcmp(name, pixels-rendered) == 0
+ else if (strcmp(name, samples-passed) == 0
has_occlusion_query(hud-pipe-screen)) {
- hud_pipe_query_install(pane, hud-pipe, pixels-rendered,
-PIPE_QUERY_OCCLUSION_COUNTER, 0, FALSE);
+ hud_pipe_query_install(pane, hud-pipe, samples-passed,
+PIPE_QUERY_OCCLUSION_COUNTER, 0, 0, FALSE);
}
else if (strcmp(name, primitives-generated) == 0
has_streamout(hud-pipe-screen)) {
hud_pipe_query_install(pane, hud-pipe, primitives-generated,
-PIPE_QUERY_PRIMITIVES_GENERATED, 0, FALSE);
+PIPE_QUERY_PRIMITIVES_GENERATED, 0, 0, FALSE);
+ }
+ else if (strncmp(name, pipeline-statistics-, 20) == 0) {
+ if (hud-cap.query_pipeline_statistics) {
+static const char *pipeline_statistics_names[] =
+{
+ ia_vertices,
+ ia_primitives,
+ vs_invocations,
+ gs_invocations,
+ gs_primitives,
+ c_invocationd,
+ c_primitives,
+ ps_invocations,
+ hs_invocations,
+ ds_invocations,
+ cs_invocations
+};
+for (i = 0; i Elements(pipeline_statistics_names); ++i)
+ if (strcmp(name[20], pipeline_statistics_names[i]) == 0)
+ break;
+if (i Elements(pipeline_statistics_names))
+ hud_pipe_query_install(pane, hud-pipe, name[20],
+ PIPE_QUERY_PIPELINE_STATISTICS, i,
+ 0, FALSE);
+else
+ fprintf(stderr, gallium_hud: invalid pipeline-statistics-*\n);
+ } else {
+fprintf(stderr, gallium_hud: PIPE_QUERY_PIPELINE_STATISTICS
+not supported by the driver\n);
+ }
}
else {
if (!hud_driver_query_install(pane, hud-pipe, name)){
@@ -963,6 +997,9 @@ hud_create(struct pipe_context *pipe, struct cso_context
*cso)
LIST_INITHEAD(hud-pane_list);
+ hud-cap.query_pipeline_statistics =
+ pipe-screen-get_param(pipe-screen,
PIPE_CAP_QUERY_PIPELINE_STATISTICS);
+
hud_parse_env_var(hud, env);
return hud;
}
diff --git a/src/gallium/auxiliary/hud/hud_cpu.c
b/src/gallium/auxiliary/hud/hud_cpu.c
index dfd9f68..ce98115 100644
--- a/src/gallium/auxiliary/hud/hud_cpu.c
+++ b/src/gallium/auxiliary/hud/hud_cpu.c
@@ -32,6 +32,7 @@
#include os/os_time.h
#include util/u_memory.h
#include stdio.h
+#include inttypes.h
static boolean
get_cpu_stats(unsigned cpu_index, uint64_t *busy_time, uint64_t *total_time)
@@ -55,8 +56,9 @@ get_cpu_stats(unsigned cpu_index, uint64_t *busy_time,
uint64_t *total_time)
int i, num;
num = sscanf(line,
- %s %llu %llu %llu %llu %llu %llu %llu %llu %llu
- %llu %llu %llu,
+ %s %PRIu64 %PRIu64 %PRIu64 %PRIu64 %PRIu64
+ %PRIu64 %PRIu64 %PRIu64 %PRIu64 %PRIu64
+ %PRIu64 %PRIu64,
cpuname, v[0], v[1], v[2], v[3], v[4], v[5],
v[6], v[7], v[8], v[9], v[10], v[11]);
if (num 5) {
diff --git a/src/gallium/auxiliary/hud/hud_driver_query.c
b/src/gallium/auxiliary/hud/hud_driver_query.c
index 798da50..413059c 100644
--- a/src/gallium/auxiliary/hud/hud_driver_query.c
+++ b/src/gallium/auxiliary/hud/hud_driver_query.c
@@ -42,6 +42,7 @@
struct query_info {
struct pipe_context *pipe;
unsigned query_type;
+ unsigned result_index; /* unit depends on query_type */
/* Ring of queries. If a query is busy, we use
[Mesa-dev] [PATCH] gallium/docs: fix definition of PIPE_QUERY_SO_STATISTICS
--- src/gallium/docs/source/context.rst |8 +--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/src/gallium/docs/source/context.rst b/src/gallium/docs/source/context.rst index 9e57930..2cc1848 100644 --- a/src/gallium/docs/source/context.rst +++ b/src/gallium/docs/source/context.rst @@ -335,15 +335,17 @@ The result is a 64-bit integer specifying the timer resolution in Hz, followed by a boolean value indicating whether the timer has incremented. ``PIPE_QUERY_PRIMITIVES_GENERATED`` returns a 64-bit integer indicating -the number of primitives processed by the pipeline. +the number of primitives processed by the pipeline (regardless of whether +stream output is active or not). ``PIPE_QUERY_PRIMITIVES_EMITTED`` returns a 64-bit integer indicating the number of primitives written to stream output buffers. ``PIPE_QUERY_SO_STATISTICS`` returns 2 64-bit integers corresponding to -the results of +the result of ``PIPE_QUERY_PRIMITIVES_EMITTED`` and -``PIPE_QUERY_PRIMITIVES_GENERATED``, in this order. +the number of primitives that would have been written to stream output buffers +if they had infinite space available (primitives_storage_needed), in this order. ``PIPE_QUERY_SO_OVERFLOW_PREDICATE`` returns a boolean value indicating whether the stream output targets have overflowed as a result of the -- 1.7.3.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] docs: add a new page documenting known application issues
On 03/29/2013 04:50 AM, Jose Fonseca wrote: Looks good to me Brian. Just a couple of comments. - Original Message - Let's try to update this when we find other broken applications... docs/ is growing a lot of stuff, with disparate target audiences. Maybe we could establish some sort of directory hierachary there: docs/apps/index.html docs/apps/viewperf.html docs/relnotes/1.2.3.4.5.html docs/specs/ docs/devel/ So that target readers can more easily find stuff that's most relevant for them. Yeah, we could do that, but it would also involve updating a bunch of links in the documents too. Someday. --- docs/application-issues.html | 83 ++ docs/contents.html |1 + 2 files changed, 84 insertions(+), 0 deletions(-) create mode 100644 docs/application-issues.html diff --git a/docs/application-issues.html b/docs/application-issues.html new file mode 100644 index 000..6db0865 --- /dev/null +++ b/docs/application-issues.html @@ -0,0 +1,83 @@ +!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN http://www.w3.org/TR/html4/loose.dtd; +html lang=en +head +meta http-equiv=content-type content=text/html; charset=utf-8 +titleApplication Issues/title +link rel=stylesheet type=text/css href=mesa.css +/head +body + +div class=header +h1The Mesa 3D Graphics Library/h1 +/div + +iframe src=contents.html/iframe +div class=content + +h1Application Issues/h1 + +p +This page documents known issues with some OpenGL applications. +/p + + +h2Topogun/h2 + +p +a href=http://www.topogun.com/;Topogun/a for Linux (version 2, at least) +creates a GLX visual without requesting a depth buffer. +This causes bad rendering if the OpenGL driver happens to choose a visual +without a depth buffer. +/p + +p +Mesa 9.1.2 and later (will) support a DRI configuration option to work around +this issue. +Using thea href=http://dri.freedesktop.org/wiki/DriConf;driconf/a tool, +set the Create all visuals with a depth buffer option before running Topogun. +Then, all GLX visuals will be created with a depth buffer. +/p + BTW, do users need to manually configure this, or will it be automatically set based on process name? Manually. Though the DRI conf tool can be used to set it per-application, I believe. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium: add PIPE_CAP_QUERY_PIPELINE_STATISTICS
Reviewed-by: Marek Olšák mar...@gmail.com Marek On Fri, Mar 29, 2013 at 1:05 PM, Christoph Bumiller e0425...@student.tuwien.ac.at wrote: --- src/gallium/docs/source/screen.rst |2 ++ src/gallium/drivers/freedreno/freedreno_screen.c |1 + src/gallium/drivers/i915/i915_screen.c |1 + src/gallium/drivers/llvmpipe/lp_screen.c |2 ++ src/gallium/drivers/nv30/nv30_screen.c |1 + src/gallium/drivers/nv50/nv50_screen.c |2 ++ src/gallium/drivers/nvc0/nvc0_screen.c |1 + src/gallium/drivers/r300/r300_screen.c |1 + src/gallium/drivers/r600/r600_pipe.c |1 + src/gallium/drivers/radeonsi/radeonsi_pipe.c |1 + src/gallium/drivers/softpipe/sp_screen.c |2 ++ src/gallium/include/pipe/p_defines.h |3 ++- 12 files changed, 17 insertions(+), 1 deletions(-) diff --git a/src/gallium/docs/source/screen.rst b/src/gallium/docs/source/screen.rst index 8c7e86e..c1a3c0b 100644 --- a/src/gallium/docs/source/screen.rst +++ b/src/gallium/docs/source/screen.rst @@ -149,6 +149,8 @@ The integer capabilities: to use a blit to implement a texture transfer which needs format conversions and swizzling in state trackers. Generally, all hardware drivers with dedicated memory should return 1 and all software rasterizers should return 0. +* ``PIPE_CAP_QUERY_PIPELINE_STATISTICS``: Whether PIPE_QUERY_PIPELINE_STATISTICS + is supported. .. _pipe_capf: diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c b/src/gallium/drivers/freedreno/freedreno_screen.c index 79eef5e..283d07f 100644 --- a/src/gallium/drivers/freedreno/freedreno_screen.c +++ b/src/gallium/drivers/freedreno/freedreno_screen.c @@ -199,6 +199,7 @@ fd_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) case PIPE_CAP_VERTEX_COLOR_CLAMPED: case PIPE_CAP_USER_VERTEX_BUFFERS: case PIPE_CAP_USER_INDEX_BUFFERS: + case PIPE_CAP_QUERY_PIPELINE_STATISTICS: return 0; /* Stream output. */ diff --git a/src/gallium/drivers/i915/i915_screen.c b/src/gallium/drivers/i915/i915_screen.c index 13aa91c..54b2154 100644 --- a/src/gallium/drivers/i915/i915_screen.c +++ b/src/gallium/drivers/i915/i915_screen.c @@ -210,6 +210,7 @@ i915_get_param(struct pipe_screen *screen, enum pipe_cap cap) case PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION: case PIPE_CAP_START_INSTANCE: case PIPE_CAP_QUERY_TIMESTAMP: + case PIPE_CAP_QUERY_PIPELINE_STATISTICS: case PIPE_CAP_TEXTURE_MULTISAMPLE: case PIPE_CAP_MIN_MAP_BUFFER_ALIGNMENT: return 0; diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c b/src/gallium/drivers/llvmpipe/lp_screen.c index e8c6ab1..6700887 100644 --- a/src/gallium/drivers/llvmpipe/lp_screen.c +++ b/src/gallium/drivers/llvmpipe/lp_screen.c @@ -130,6 +130,8 @@ llvmpipe_get_param(struct pipe_screen *screen, enum pipe_cap param) return 0; case PIPE_CAP_QUERY_TIMESTAMP: return 1; + case PIPE_CAP_QUERY_PIPELINE_STATISTICS: + return 0; case PIPE_CAP_TEXTURE_MIRROR_CLAMP: return 1; case PIPE_CAP_TEXTURE_SHADOW_MAP: diff --git a/src/gallium/drivers/nv30/nv30_screen.c b/src/gallium/drivers/nv30/nv30_screen.c index 4084869..e33710e 100644 --- a/src/gallium/drivers/nv30/nv30_screen.c +++ b/src/gallium/drivers/nv30/nv30_screen.c @@ -122,6 +122,7 @@ nv30_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) case PIPE_CAP_MIN_MAP_BUFFER_ALIGNMENT: case PIPE_CAP_TEXTURE_BUFFER_OBJECTS: case PIPE_CAP_TEXTURE_BUFFER_OFFSET_ALIGNMENT: + case PIPE_CAP_QUERY_PIPELINE_STATISTICS: return 0; case PIPE_CAP_VERTEX_BUFFER_OFFSET_4BYTE_ALIGNED_ONLY: case PIPE_CAP_VERTEX_BUFFER_STRIDE_4BYTE_ALIGNED_ONLY: diff --git a/src/gallium/drivers/nv50/nv50_screen.c b/src/gallium/drivers/nv50/nv50_screen.c index 0a20ae3..53eeeb6 100644 --- a/src/gallium/drivers/nv50/nv50_screen.c +++ b/src/gallium/drivers/nv50/nv50_screen.c @@ -189,6 +189,8 @@ nv50_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) return 0; case PIPE_CAP_PREFER_BLIT_BASED_TEXTURE_TRANSFER: return 1; + case PIPE_CAP_QUERY_PIPELINE_STATISTICS: + return 0; default: NOUVEAU_ERR(unknown PIPE_CAP %d\n, param); return 0; diff --git a/src/gallium/drivers/nvc0/nvc0_screen.c b/src/gallium/drivers/nvc0/nvc0_screen.c index 5b9385a..3a32539 100644 --- a/src/gallium/drivers/nvc0/nvc0_screen.c +++ b/src/gallium/drivers/nvc0/nvc0_screen.c @@ -136,6 +136,7 @@ nvc0_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) case PIPE_CAP_QUERY_TIME_ELAPSED: case PIPE_CAP_OCCLUSION_QUERY: case PIPE_CAP_STREAM_OUTPUT_PAUSE_RESUME: + case PIPE_CAP_QUERY_PIPELINE_STATISTICS: return 1; case PIPE_CAP_MAX_STREAM_OUTPUT_BUFFERS:
Re: [Mesa-dev] [PATCH] gallium/docs: fix definition of PIPE_QUERY_SO_STATISTICS
Reviewed-by: Marek Olšák mar...@gmail.com Marek On Fri, Mar 29, 2013 at 2:33 PM, Christoph Bumiller e0425...@student.tuwien.ac.at wrote: --- src/gallium/docs/source/context.rst |8 +--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/src/gallium/docs/source/context.rst b/src/gallium/docs/source/context.rst index 9e57930..2cc1848 100644 --- a/src/gallium/docs/source/context.rst +++ b/src/gallium/docs/source/context.rst @@ -335,15 +335,17 @@ The result is a 64-bit integer specifying the timer resolution in Hz, followed by a boolean value indicating whether the timer has incremented. ``PIPE_QUERY_PRIMITIVES_GENERATED`` returns a 64-bit integer indicating -the number of primitives processed by the pipeline. +the number of primitives processed by the pipeline (regardless of whether +stream output is active or not). ``PIPE_QUERY_PRIMITIVES_EMITTED`` returns a 64-bit integer indicating the number of primitives written to stream output buffers. ``PIPE_QUERY_SO_STATISTICS`` returns 2 64-bit integers corresponding to -the results of +the result of ``PIPE_QUERY_PRIMITIVES_EMITTED`` and -``PIPE_QUERY_PRIMITIVES_GENERATED``, in this order. +the number of primitives that would have been written to stream output buffers +if they had infinite space available (primitives_storage_needed), in this order. ``PIPE_QUERY_SO_OVERFLOW_PREDICATE`` returns a boolean value indicating whether the stream output targets have overflowed as a result of the -- 1.7.3.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH V2 0/8] ARB_texture_storage_multisample support
On 03/29/2013 02:30 AM, Chris Forbes wrote: This series adds support for the ARB_texture_storage_multisample extension. Only minor changes from V1: * Added missing error cases in TexStorage*Multisample. Thanks Eric for pointing out that this was a bit lacking. * Dropped spurious special case for TEXTURE_MAX_LEVELS. This wasn't in the spec at all, not sure where it came from. -- Chris The series LGTM. Reviewed-by: Brian Paul bri...@vmware.com BTW, It looks like we don't have a docs/relnotes-9.2.html file yet but that would be the place to mention this new feature... ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/5] mesa: refactor clamping controls, get rid of _ClampReadColor
On 03/28/2013 03:24 PM, Marek Olšák wrote:
---
src/mesa/main/blend.c | 28 +++-
src/mesa/main/blend.h |8
src/mesa/main/fbobject.c| 10 ++
src/mesa/main/framebuffer.c |1 +
src/mesa/main/mtypes.h |4 +++-
src/mesa/main/readpix.c |5 +++--
src/mesa/main/state.c | 29 +++--
7 files changed, 55 insertions(+), 30 deletions(-)
diff --git a/src/mesa/main/blend.c b/src/mesa/main/blend.c
index 309f1d5..876cbf2 100644
--- a/src/mesa/main/blend.c
+++ b/src/mesa/main/blend.c
@@ -782,7 +782,34 @@ _mesa_ClampColor(GLenum target, GLenum clamp)
}
}
+static GLboolean _mesa_get_clamp_color(const struct gl_framebuffer *fb,
+ GLenum clamp)
You don't need the _mesa_ prefix on static functions. And some
reformatting, so:
static GLboolean
get_clamp_color(const struct gl_framebuffer *fb, GLenum clamp)
+{
+ if (clamp == GL_TRUE || clamp == GL_FALSE)
+ return clamp;
+
+ ASSERT(clamp == GL_FIXED_ONLY);
+ if (!fb)
+ return GL_TRUE;
+ return fb-_AllColorBuffersFixedPoint;
+}
+
+GLboolean _mesa_get_clamp_fragment_color(const struct gl_context *ctx)
Minor formatting nit:
GLboolean
_mesa_get_clamp_fragment_color(const struct gl_context *ctx)
+{
+ return _mesa_get_clamp_color(ctx-DrawBuffer,
+ctx-Color.ClampFragmentColor);
+}
+
+GLboolean _mesa_get_clamp_vertex_color(const struct gl_context *ctx)
+{
+ return _mesa_get_clamp_color(ctx-DrawBuffer, ctx-Light.ClampVertexColor);
+}
+
+GLboolean _mesa_get_clamp_read_color(const struct gl_context *ctx)
+{
+ return _mesa_get_clamp_color(ctx-ReadBuffer, ctx-Color.ClampReadColor);
+}
Reviewed-by: Brian Paul bri...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/5] mesa: move updating clamp control derived state out of mesa_update_state_locked
On 03/28/2013 03:24 PM, Marek Olšák wrote:
It has 2 dependencies: glClampColor and the framebuffer, we might just as well
do the update where those two are changed.
---
src/mesa/main/blend.c | 28
src/mesa/main/blend.h |6 ++
src/mesa/main/framebuffer.c |4
src/mesa/main/state.c | 36
4 files changed, 38 insertions(+), 36 deletions(-)
diff --git a/src/mesa/main/blend.c b/src/mesa/main/blend.c
index c1b49b1..6cc2310 100644
--- a/src/mesa/main/blend.c
+++ b/src/mesa/main/blend.c
@@ -767,10 +767,12 @@ _mesa_ClampColor(GLenum target, GLenum clamp)
case GL_CLAMP_VERTEX_COLOR_ARB:
FLUSH_VERTICES(ctx, _NEW_LIGHT);
ctx-Light.ClampVertexColor = clamp;
+ _mesa_update_clamp_vertex_color(ctx);
break;
case GL_CLAMP_FRAGMENT_COLOR_ARB:
FLUSH_VERTICES(ctx, _NEW_FRAG_CLAMP);
ctx-Color.ClampFragmentColor = clamp;
+ _mesa_update_clamp_fragment_color(ctx);
break;
case GL_CLAMP_READ_COLOR_ARB:
FLUSH_VERTICES(ctx, _NEW_COLOR);
@@ -811,6 +813,32 @@ GLboolean _mesa_get_clamp_read_color(const struct
gl_context *ctx)
return _mesa_get_clamp_color(ctx-ReadBuffer, ctx-Color.ClampReadColor);
}
+/**
+ * Update the ctx-Color._ClampFragmentColor field
+ */
+void _mesa_update_clamp_fragment_color(struct gl_context *ctx)
void
_mesa_update_clamp_fragment_color(struct gl_context *ctx)
+{
+ struct gl_framebuffer *fb = ctx-DrawBuffer;
+
+ /* Don't clamp if:
+* - there is no colorbuffer
+* - all colorbuffers are unsigned normalized, so clamping has no effect
+* - there is an integer colorbuffer
+*/
+ if (!fb || !fb-_HasSNormOrFloatColorBuffer || fb-_IntegerColor)
+ ctx-Color._ClampFragmentColor = GL_FALSE;
+ else
+ ctx-Color._ClampFragmentColor = _mesa_get_clamp_fragment_color(ctx);
+}
+
+/**
+ * Update the ctx-Color._ClampVertexColor field
+ */
+void _mesa_update_clamp_vertex_color(struct gl_context *ctx)
void
_mesa_update_clamp_vertex_color(struct gl_context *ctx)
+{
+ ctx-Light._ClampVertexColor = _mesa_get_clamp_vertex_color(ctx);
+}
+
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/5] st/mesa: don't expose ARB_color_buffer_float without driver support in GL core
On 03/28/2013 03:24 PM, Marek Olšák wrote:
---
src/mesa/state_tracker/st_extensions.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/src/mesa/state_tracker/st_extensions.c
b/src/mesa/state_tracker/st_extensions.c
index 11db9d3..2d8b9ef 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -629,6 +629,7 @@ void st_init_extensions(struct st_context *st)
ctx-Const.PrimitiveRestartInSoftware = GL_TRUE;
}
+ /* ARB_color_buffer_float. */
if (screen-get_param(screen, PIPE_CAP_VERTEX_COLOR_UNCLAMPED)) {
ctx-Extensions.ARB_color_buffer_float = GL_TRUE;
@@ -639,6 +640,16 @@ void st_init_extensions(struct st_context *st)
if (!screen-get_param(screen, PIPE_CAP_FRAGMENT_COLOR_CLAMPED)) {
st-clamp_frag_color_in_shader = TRUE;
}
+
+ /* For drivers which cannot do color clamping, it's better to just
+ * disable ARB_color_buffer_float in the core profile, because
+ * the clamping is deprecated there anyway. */
+ if (ctx-API == API_OPENGL_CORE
+ (st-clamp_frag_color_in_shader || st-clamp_vert_color_in_shader)) {
+ st-clamp_vert_color_in_shader = GL_FALSE;
+ st-clamp_frag_color_in_shader = GL_FALSE;
+ ctx-Extensions.ARB_color_buffer_float = GL_FALSE;
+ }
}
I've read that comment and code several times but I still can't quite
parse it.
If we disable ARB_color_buffer_float, we'll never get version 3.0 (see
compute_version()) so there's no core profile.
I'm probably missing something, but could you elaborate on or clarify
the comments somehow?
Other than the formatting nits, the series looks good.
Reviewed-by: Brian Paul bri...@vmware.com
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] gallivm: consolidate code for float-to-half and float-to-packed conversion.
From: Roland Scheidegger srol...@vmware.com
This replaces the existing float-to-half implementation.
There are definitely a couple of differences - the old implementation
had unspecified(?) rounding behavior, and could at least in theory
construct Inf values out of NaNs. NaNs and Infs should now always be
properly propagated, and rounding behavior is now towards zero
(note this means too large but non-Infinity values get propagated to max
representable value, not Infinity).
The implementation will definitely not match util code, however (which
does nearest rounding, which also means too large values will get
propagated to Infinity).
Also fix a bogus round mask probably leading to rounding bugs...
v2: fix a logic bug in handling infs/nans.
---
src/gallium/auxiliary/gallivm/lp_bld_conv.c| 66 ++
src/gallium/auxiliary/gallivm/lp_bld_format.h |9 ++
.../auxiliary/gallivm/lp_bld_format_float.c| 135
3 files changed, 102 insertions(+), 108 deletions(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_conv.c
b/src/gallium/auxiliary/gallivm/lp_bld_conv.c
index 43c59f3..38a577c 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_conv.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_conv.c
@@ -176,7 +176,7 @@ lp_build_half_to_float(struct gallivm_state *gallivm,
struct lp_type i32_type = lp_type_int_vec(32, 32 * src_length);
LLVMTypeRef int_vec_type = lp_build_vec_type(gallivm, i32_type);
- /* Convert int16 vector to int32 vector by zero ext */
+ /* Convert int16 vector to int32 vector by zero ext (might generate bad
code) */
LLVMValueRef h = LLVMBuildZExt(builder, src, int_vec_type, );
return lp_build_smallfloat_to_float(gallivm, f32_type, h, 10, 5, 0, true);
}
@@ -184,16 +184,13 @@ lp_build_half_to_float(struct gallivm_state *gallivm,
/**
* Converts float32 to int16 half-float
- * Note this can be performed in 1 instruction if vcvtps2ph exists (sse5 i
think?)
+ * Note this can be performed in 1 instruction if vcvtps2ph exists (f16c/cvt16)
* [llvm.x86.vcvtps2ph / _mm_cvtps_ph]
*
* @param src value to convert
*
- * ref http://fgiesen.wordpress.com/2012/03/28/half-to-float-done-quic/
- * ref https://gist.github.com/2156668
- *
- * XXX: This is an approximation. It is faster but certain NaNs are converted
to
- * infinity, and rounding is not correct.
+ * Convert float32 to half floats, preserving Infs and NaNs,
+ * with rounding towards zero (trunc).
*/
LLVMValueRef
lp_build_float_to_half(struct gallivm_state *gallivm,
@@ -203,60 +200,13 @@ lp_build_float_to_half(struct gallivm_state *gallivm,
LLVMTypeRef f32_vec_type = LLVMTypeOf(src);
unsigned length = LLVMGetTypeKind(f32_vec_type) == LLVMVectorTypeKind
? LLVMGetVectorSize(f32_vec_type) : 1;
- struct lp_type f32_type = lp_type_float_vec(32, 32 * length);
- struct lp_type u32_type = lp_type_uint_vec(32, 32 * length);
+ struct lp_type i32_type = lp_type_int_vec(32, 32 * length);
struct lp_type i16_type = lp_type_int_vec(16, 16 * length);
- LLVMTypeRef u32_vec_type = lp_build_vec_type(gallivm, u32_type);
- LLVMTypeRef i16_vec_type = lp_build_vec_type(gallivm, i16_type);
- struct lp_build_context f32_bld;
- struct lp_build_context u32_bld;
LLVMValueRef result;
- lp_build_context_init(f32_bld, gallivm, f32_type);
- lp_build_context_init(u32_bld, gallivm, u32_type);
-
- {
- /* Constants */
- LLVMValueRef u32_f32inf= lp_build_const_int_vec(gallivm, u32_type,
0xff 23);
- LLVMValueRef u32_expinf= lp_build_const_int_vec(gallivm, u32_type,
0xe0 23);
- LLVMValueRef f32_f16max= lp_build_const_vec(gallivm, f32_type,
65536.0); // 0x8f 23
- LLVMValueRef f32_magic = lp_build_const_vec(gallivm, f32_type,
1.92592994e-34); // 0x0f 23
-
- /* Cast from float32 to int32 */
- LLVMValueRef f = LLVMBuildBitCast(builder, src,
u32_vec_type, );
-
- /* Remove sign */
- LLVMValueRef srcabs = lp_build_abs(f32_bld, src);
- LLVMValueRef fabs = LLVMBuildBitCast(builder, srcabs,
u32_vec_type, );
-
- /* Magic conversion */
- LLVMValueRef clamped = lp_build_min(f32_bld, f32_f16max, srcabs);
- LLVMValueRef scaled= LLVMBuildBitCast(builder,
-LLVMBuildFMul(builder,
- clamped,
- f32_magic,
- ),
-u32_vec_type,
-);
- /* Make sure Inf/NaN and unormalised survive */
- LLVMValueRef infnancase= LLVMBuildXor(builder, u32_expinf, fabs, );
- LLVMValueRef b_notnormal = lp_build_compare(gallivm, f32_type,
PIPE_FUNC_GEQUAL,
-
[Mesa-dev] [PATCH 2/2] gallivm: bring back optimized but incorrect float to smallfloat optimizations
From: Roland Scheidegger srol...@vmware.com
Conceptually the same as previously done in float_to_half.
Should cut down number of instructions from 14 to 10 or so, but
will promote some NaNs to Infs, so it's disabled.
It gets a bit tricky though handling all the cases correctly...
Passes basic tests either way (though there are no tests testing special
cases, but some manual tests injecting them seemed promising).
---
.../auxiliary/gallivm/lp_bld_format_float.c| 124 ++--
1 file changed, 86 insertions(+), 38 deletions(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_format_float.c
b/src/gallium/auxiliary/gallivm/lp_bld_format_float.c
index 161e392..61b6a60 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_format_float.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_format_float.c
@@ -79,13 +79,15 @@ lp_build_float_to_smallfloat(struct gallivm_state *gallivm,
{
LLVMBuilderRef builder = gallivm-builder;
LLVMValueRef i32_floatexpmask, i32_smallexpmask, magic, normal;
- LLVMValueRef rescale_src, tmp, i32_roundmask, small_max;
- LLVMValueRef is_nan, i32_qnanbit, src_abs, shift, infcheck_src, res;
- LLVMValueRef is_inf, is_nan_or_inf, nan_or_inf, mask;
+ LLVMValueRef rescale_src, i32_roundmask, small_max;
+ LLVMValueRef i32_qnanbit, shift, res;
+ LLVMValueRef is_nan_or_inf, nan_or_inf, mask, srci;
struct lp_type f32_type = lp_type_float_vec(32, 32 * i32_type.length);
struct lp_build_context f32_bld, i32_bld;
LLVMValueRef zero = lp_build_const_vec(gallivm, f32_type, 0.0f);
unsigned exponent_start = mantissa_start + mantissa_bits;
+ boolean always_preserve_nans = true;
+ boolean maybe_correct_denorm_rounding = true;
lp_build_context_init(f32_bld, gallivm, f32_type);
lp_build_context_init(i32_bld, gallivm, i32_type);
@@ -94,35 +96,41 @@ lp_build_float_to_smallfloat(struct gallivm_state *gallivm,
((1 exponent_bits) - 1) 23);
i32_floatexpmask = lp_build_const_int_vec(gallivm, i32_type, 0xff 23);
- src_abs = lp_build_abs(f32_bld, src);
- src_abs = LLVMBuildBitCast(builder, src_abs, i32_bld.vec_type, );
+ srci = LLVMBuildBitCast(builder, src, i32_bld.vec_type, );
if (has_sign) {
- rescale_src = src_abs;
- infcheck_src = src_abs;
- src = LLVMBuildBitCast(builder, src, i32_bld.vec_type, );
+ rescale_src = src;
}
else {
/* clamp to pos range (can still have sign bit if NaN or negative zero)
*/
- rescale_src = lp_build_max(f32_bld, src, zero);
- rescale_src = LLVMBuildBitCast(builder, rescale_src, i32_bld.vec_type,
);
- src = LLVMBuildBitCast(builder, src, i32_bld.vec_type, );
- infcheck_src = src;
+ rescale_src = lp_build_max(f32_bld, zero, src);
}
+ rescale_src = LLVMBuildBitCast(builder, rescale_src, i32_bld.vec_type, );
/* ordinary number */
- /* get rid of excess mantissa bits, and while here also potential sign bit
*/
- i32_roundmask = lp_build_const_int_vec(gallivm, i32_type,
- ~((1 (23 - mantissa_bits)) - 1)
- 0x7fff);
+ /*
+* get rid of excess mantissa bits and sign bit
+* This is only really needed for correct rounding of denorms I think
+* but only if we use the preserve NaN path does using
+* src_abs instead save us any instruction.
+*/
+ if (maybe_correct_denorm_rounding || !always_preserve_nans) {
+ i32_roundmask = lp_build_const_int_vec(gallivm, i32_type,
+ ~((1 (23 - mantissa_bits)) -
1)
+ 0x7fff);
+ rescale_src = LLVMBuildBitCast(builder, rescale_src, i32_bld.vec_type,
);
+ rescale_src = lp_build_and(i32_bld, rescale_src, i32_roundmask);
+ rescale_src = LLVMBuildBitCast(builder, rescale_src, f32_bld.vec_type,
);
+ }
+ else {
+ rescale_src = lp_build_abs(f32_bld, src);
+ }
- tmp = lp_build_and(i32_bld, rescale_src, i32_roundmask);
- tmp = LLVMBuildBitCast(builder, tmp, f32_bld.vec_type, );
/* bias exponent (and denormalize if necessary) */
magic = lp_build_const_int_vec(gallivm, i32_type,
((1 (exponent_bits - 1)) - 1) 23);
magic = LLVMBuildBitCast(builder, magic, f32_bld.vec_type, );
- normal = lp_build_mul(f32_bld, tmp, magic);
+ normal = lp_build_mul(f32_bld, rescale_src, magic);
/* clamp to max value - largest non-infinity number */
small_max = lp_build_const_int_vec(gallivm, i32_type,
@@ -141,19 +149,66 @@ lp_build_float_to_smallfloat(struct gallivm_state
*gallivm,
* (Cannot actually save the comparison since we need to distinguish
* Inf and NaN cases anyway, but it would be better for AVX.)
*/
- is_nan = lp_build_compare(gallivm, i32_type, PIPE_FUNC_GREATER,
- src_abs, i32_floatexpmask);
- is_inf = lp_build_compare(gallivm,
[Mesa-dev] [PATCH] i965: Fix an inconsistency the VUE map with gl_ClipVertex on gen4/5.
We are intentionally not allocating a slot for gl_ClipVertex. But by
leaving the bit set in the slots_valid, the fragment shader's computation
of where varyings are in urb entry coming out of the SF would be off by
one. Fixes rendering in Freespace 2 SCP.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=62830
Tested-by: Joaquín Ignacio Aramendía samsa...@gmail.com
NOTE: This is a candidate for the 9.1 branch.
---
NOTE: I haven't run this through piglit yet, since I'm out of town.
src/mesa/drivers/dri/i965/brw_vs.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vs.c
b/src/mesa/drivers/dri/i965/brw_vs.c
index e093dd1..6d2c0fd 100644
--- a/src/mesa/drivers/dri/i965/brw_vs.c
+++ b/src/mesa/drivers/dri/i965/brw_vs.c
@@ -63,6 +63,13 @@ brw_compute_vue_map(struct brw_context *brw, struct
brw_vs_compile *c,
{
const struct intel_context *intel = brw-intel;
struct brw_vue_map *vue_map = c-prog_data.vue_map;
+
+ /* Prior to Gen6, don't assign a slot for VARYING_SLOT_CLIP_VERTEX, since
+* it is unsupported.
+*/
+ if (intel-gen 6)
+ slots_valid = ~VARYING_BIT_CLIP_VERTEX;
+
vue_map-slots_valid = slots_valid;
int i;
@@ -152,15 +159,12 @@ brw_compute_vue_map(struct brw_context *brw, struct
brw_vs_compile *c,
* assign them contiguously. Don't reassign outputs that already have a
* slot.
*
-* Also, prior to Gen6, don't assign a slot for VARYING_SLOT_CLIP_VERTEX,
-* since it is unsupported. In Gen6 and above, VARYING_SLOT_CLIP_VERTEX may
-* be needed for transform feedback; since we don't want to have to
-* recompute the VUE map (and everything that depends on it) when transform
-* feedback is enabled or disabled, just go ahead and assign a slot for it.
+* We generally don't need to assign a slot for VARYING_SLOT_CLIP_VERTEX,
+* since it's encoded as the clip distances by emit_clip_distances().
+* However, it may be output by transform feedback, and we'd rather not
+* recompute state when TF changes, so we just always include it.
*/
for (int i = 0; i VARYING_SLOT_MAX; ++i) {
- if (intel-gen 6 i == VARYING_SLOT_CLIP_VERTEX)
- continue;
if ((slots_valid BITFIELD64_BIT(i))
vue_map-varying_to_slot[i] == -1) {
assign_vue_slot(vue_map, i);
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/5] st/mesa: don't expose ARB_color_buffer_float without driver support in GL core
On Fri, Mar 29, 2013 at 4:21 PM, Brian Paul bri...@vmware.com wrote:
On 03/28/2013 03:24 PM, Marek Olšák wrote:
---
src/mesa/state_tracker/st_**extensions.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/src/mesa/state_tracker/st_**extensions.c
b/src/mesa/state_tracker/st_**extensions.c
index 11db9d3..2d8b9ef 100644
--- a/src/mesa/state_tracker/st_**extensions.c
+++ b/src/mesa/state_tracker/st_**extensions.c
@@ -629,6 +629,7 @@ void st_init_extensions(struct st_context *st)
ctx-Const.**PrimitiveRestartInSoftware = GL_TRUE;
}
+ /* ARB_color_buffer_float. */
if (screen-get_param(screen, PIPE_CAP_VERTEX_COLOR_**UNCLAMPED)) {
ctx-Extensions.ARB_color_**buffer_float = GL_TRUE;
@@ -639,6 +640,16 @@ void st_init_extensions(struct st_context *st)
if (!screen-get_param(screen, PIPE_CAP_FRAGMENT_COLOR_**CLAMPED))
{
st-clamp_frag_color_in_shader = TRUE;
}
+
+ /* For drivers which cannot do color clamping, it's better to just
+ * disable ARB_color_buffer_float in the core profile, because
+ * the clamping is deprecated there anyway. */
+ if (ctx-API == API_OPENGL_CORE
+ (st-clamp_frag_color_in_**shader || st-clamp_vert_color_in_*
*shader)) {
+ st-clamp_vert_color_in_shader = GL_FALSE;
+ st-clamp_frag_color_in_shader = GL_FALSE;
+ ctx-Extensions.ARB_color_**buffer_float = GL_FALSE;
+ }
}
I've read that comment and code several times but I still can't quite
parse it.
If we disable ARB_color_buffer_float, we'll never get version 3.0 (see
compute_version()) so there's no core profile.
I'm probably missing something, but could you elaborate on or clarify the
comments somehow?
Yes. The last hunk of the 4th patch is:
diff --git a/src/mesa/main/version.c b/src/mesa/main/version.c
index 3d4af59..ecca446 100644
--- a/src/mesa/main/version.c
+++ b/src/mesa/main/version.c
@@ -233,7 +233,8 @@ compute_version(struct gl_context *ctx)
const GLboolean ver_3_0 = (ver_2_1
ctx-Const.GLSLVersion = 130
ctx-Const.MaxSamples = 4
- ctx-Extensions.ARB_color_buffer_float
+ (ctx-API == API_OPENGL_CORE ||
+ ctx-Extensions.ARB_color_buffer_float)
ctx-Extensions.ARB_depth_buffer_float
ctx-Extensions.ARB_half_float_pixel
ctx-Extensions.ARB_half_float_vertex
So basically, if the profile is core, ARB_color_buffer_float is not
required to get GL 3.0 and higher.
The subset of ARB_color_buffer_float which remained part of the core
profile is only the read color clamping, which is always supported by our
common ReadPixels code. The 4th patch makes necessary changes for
GL_CLAMP_READ_COLOR to be accepted without ARB_color_buffer_float in the
core profile.
Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Fix an inconsistency the VUE map with gl_ClipVertex on gen4/5.
On 29 March 2013 10:20, Eric Anholt e...@anholt.net wrote:
We are intentionally not allocating a slot for gl_ClipVertex. But by
leaving the bit set in the slots_valid, the fragment shader's computation
of where varyings are in urb entry coming out of the SF would be off by
one. Fixes rendering in Freespace 2 SCP.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=62830
Tested-by: Joaquín Ignacio Aramendía samsa...@gmail.com
NOTE: This is a candidate for the 9.1 branch.
---
NOTE: I haven't run this through piglit yet, since I'm out of town.
Assuming the piglit tests pass, this is:
Reviewed-by: Paul Berry stereotype...@gmail.com
src/mesa/drivers/dri/i965/brw_vs.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vs.c
b/src/mesa/drivers/dri/i965/brw_vs.c
index e093dd1..6d2c0fd 100644
--- a/src/mesa/drivers/dri/i965/brw_vs.c
+++ b/src/mesa/drivers/dri/i965/brw_vs.c
@@ -63,6 +63,13 @@ brw_compute_vue_map(struct brw_context *brw, struct
brw_vs_compile *c,
{
const struct intel_context *intel = brw-intel;
struct brw_vue_map *vue_map = c-prog_data.vue_map;
+
+ /* Prior to Gen6, don't assign a slot for VARYING_SLOT_CLIP_VERTEX,
since
+* it is unsupported.
+*/
+ if (intel-gen 6)
+ slots_valid = ~VARYING_BIT_CLIP_VERTEX;
+
vue_map-slots_valid = slots_valid;
int i;
@@ -152,15 +159,12 @@ brw_compute_vue_map(struct brw_context *brw, struct
brw_vs_compile *c,
* assign them contiguously. Don't reassign outputs that already have
a
* slot.
*
-* Also, prior to Gen6, don't assign a slot for
VARYING_SLOT_CLIP_VERTEX,
-* since it is unsupported. In Gen6 and above,
VARYING_SLOT_CLIP_VERTEX may
-* be needed for transform feedback; since we don't want to have to
-* recompute the VUE map (and everything that depends on it) when
transform
-* feedback is enabled or disabled, just go ahead and assign a slot
for it.
+* We generally don't need to assign a slot for
VARYING_SLOT_CLIP_VERTEX,
+* since it's encoded as the clip distances by emit_clip_distances().
+* However, it may be output by transform feedback, and we'd rather not
+* recompute state when TF changes, so we just always include it.
*/
for (int i = 0; i VARYING_SLOT_MAX; ++i) {
- if (intel-gen 6 i == VARYING_SLOT_CLIP_VERTEX)
- continue;
if ((slots_valid BITFIELD64_BIT(i))
vue_map-varying_to_slot[i] == -1) {
assign_vue_slot(vue_map, i);
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] intel: Remove a never-taken debug print path.
On 03/29/2013 10:40 AM, Eric Anholt wrote:
Alessandro Pignotti noted when I added this code in commit
0e723b135bfd59868c92c3ae243f1adaedaec3a5 that it's in the else block for
if (busy), so this debug print couldn't happen.
---
src/mesa/drivers/dri/intel/intel_buffer_objects.c |5 -
1 file changed, 5 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_buffer_objects.c
b/src/mesa/drivers/dri/intel/intel_buffer_objects.c
index ac265db..e270db8 100644
--- a/src/mesa/drivers/dri/intel/intel_buffer_objects.c
+++ b/src/mesa/drivers/dri/intel/intel_buffer_objects.c
@@ -227,11 +227,6 @@ intel_bufferobj_subdata(struct gl_context * ctx,
drm_intel_bo_unreference(temp_bo);
}
} else {
- if (unlikely(intel-perf_debug)) {
- if (drm_intel_bo_busy(intel_obj-buffer)) {
-perf_debug(Stalling on the GPU in glBufferSubData().\n);
- }
- }
drm_intel_bo_subdata(intel_obj-buffer, offset, size, data);
}
}
Yep, that should never happen.
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] docs: add a new page documenting known application issues
On 03/29/2013 07:30 AM, Brian Paul wrote: On 03/29/2013 04:50 AM, Jose Fonseca wrote: Looks good to me Brian. Just a couple of comments. - Original Message - Let's try to update this when we find other broken applications... docs/ is growing a lot of stuff, with disparate target audiences. Maybe we could establish some sort of directory hierachary there: docs/apps/index.html docs/apps/viewperf.html docs/relnotes/1.2.3.4.5.html docs/specs/ docs/devel/ So that target readers can more easily find stuff that's most relevant for them. Yeah, we could do that, but it would also involve updating a bunch of links in the documents too. Someday. --- docs/application-issues.html | 83 ++ docs/contents.html |1 + 2 files changed, 84 insertions(+), 0 deletions(-) create mode 100644 docs/application-issues.html diff --git a/docs/application-issues.html b/docs/application-issues.html new file mode 100644 index 000..6db0865 --- /dev/null +++ b/docs/application-issues.html @@ -0,0 +1,83 @@ +!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN http://www.w3.org/TR/html4/loose.dtd; +html lang=en +head +meta http-equiv=content-type content=text/html; charset=utf-8 +titleApplication Issues/title +link rel=stylesheet type=text/css href=mesa.css +/head +body + +div class=header +h1The Mesa 3D Graphics Library/h1 +/div + +iframe src=contents.html/iframe +div class=content + +h1Application Issues/h1 + +p +This page documents known issues with some OpenGL applications. +/p + + +h2Topogun/h2 + +p +a href=http://www.topogun.com/;Topogun/a for Linux (version 2, at least) +creates a GLX visual without requesting a depth buffer. +This causes bad rendering if the OpenGL driver happens to choose a visual +without a depth buffer. +/p + +p +Mesa 9.1.2 and later (will) support a DRI configuration option to work around +this issue. +Using thea href=http://dri.freedesktop.org/wiki/DriConf;driconf/a tool, +set the Create all visuals with a depth buffer option before running Topogun. +Then, all GLX visuals will be created with a depth buffer. +/p + BTW, do users need to manually configure this, or will it be automatically set based on process name? Manually. Though the DRI conf tool can be used to set it per-application, I believe. -Brian We actually ship a default drirc already in src/mesa/drivers/common/drirc, which we expect will get installed by distro packages. You might want to add the workaround for Topogun there so it happens automatically... --Ken ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Fix an inconsistency the VUE map with gl_ClipVertex on gen4/5.
On 03/29/2013 10:20 AM, Eric Anholt wrote: We are intentionally not allocating a slot for gl_ClipVertex. But by leaving the bit set in the slots_valid, the fragment shader's computation of where varyings are in urb entry coming out of the SF would be off by one. Fixes rendering in Freespace 2 SCP. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=62830 Tested-by: Joaquín Ignacio Aramendía samsa...@gmail.com NOTE: This is a candidate for the 9.1 branch. --- NOTE: I haven't run this through piglit yet, since I'm out of town. I ran this through Piglit on Ironlake. No regressions. Reviewed-and-tested-by: Kenneth Graunke kenn...@whitecape.org ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glsl: Fix array indexing when constant folding built-in functions.
Mesa constant-folds built-in functions by using a miniature GLSL
interpreter (see
ir_function_signature::constant_expression_evaluate_expression_list()).
This interpreter had a bug in its handling of array indexing, which
caused expressions like m[i][j] (where m is a matrix) to be handled
incorrectly. Specifically, it incorrectly treated j as indexing into
the whole matrix (rather than indexing just into the vector m[i]); as
a result the offset computed for m[i] was lost and m[i][j] was treated
as m[j][0].
Fixes piglit tests inverse-mat[234].{vert,frag}.
NOTE: This is a candidate for the 9.1 branch.
---
src/glsl/ir_constant_expression.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/glsl/ir_constant_expression.cpp
b/src/glsl/ir_constant_expression.cpp
index c2d0dc4..c09e56a 100644
--- a/src/glsl/ir_constant_expression.cpp
+++ b/src/glsl/ir_constant_expression.cpp
@@ -1398,7 +1398,7 @@ ir_dereference_array::constant_referenced(struct
hash_table *variable_context,
return;
}
- const glsl_type *vt = substore-type;
+ const glsl_type *vt = array-type;
if (vt-is_array()) {
store = substore-get_array_element(index);
offset = 0;
--
1.8.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/4] glsl: Replace constant-index vector array accesses with swizzles
On 27 March 2013 09:30, Ian Romanick i...@freedesktop.org wrote:
From: Ian Romanick ian.d.roman...@intel.com
Search and replace:
][0] - ].x
][1] - ].y
][2] - ].z
][3] - ].w
Fixes piglit tests inverse-mat[234].{vert,frag}. These tests call the
inverse function with constant parameters and expect proper constant
folding to happen. My suspicion is that this patch papers over some bug
in constant propagation involving array accesses.
Either way, all of these accesses eventually get lowered to swizzles.
This cuts out the middle man (saving a trivial amount of CPU).
NOTE: This is a candidate for the 9.1 branch.
I've tracked down the constant propagation bug that this patch papers over,
and I just sent out a bug fix (glsl: Fix array indexing when constant
folding built-in functions.)
Assuming my bug fix is correct, can we NAK this patch? I think it makes
the source code harder to read, and as you point out the benefit is just to
save a trivial amount of CPU.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
Cc: Eric Anholt e...@anholt.net
Cc: Paul Berry stereotype...@gmail.com
---
src/glsl/builtins/glsl/determinant.glsl | 62 +-
src/glsl/builtins/glsl/inverse.glsl | 112
2 files changed, 87 insertions(+), 87 deletions(-)
diff --git a/src/glsl/builtins/glsl/determinant.glsl
b/src/glsl/builtins/glsl/determinant.glsl
index 32695a8..78751a6 100644
--- a/src/glsl/builtins/glsl/determinant.glsl
+++ b/src/glsl/builtins/glsl/determinant.glsl
@@ -24,47 +24,47 @@
#version 120
float determinant(mat2 m)
{
- return m[0][0] * m[1][1] - m[1][0] * m[0][1];
+ return m[0].x * m[1].y - m[1].x * m[0].y;
}
float determinant(mat3 m)
{
- return (+ m[0][0] * (m[1][1] * m[2][2] - m[1][2] * m[2][1])
- - m[0][1] * (m[1][0] * m[2][2] - m[1][2] * m[2][0])
- + m[0][2] * (m[1][0] * m[2][1] - m[1][1] * m[2][0]));
+ return (+ m[0].x * (m[1].y * m[2].z - m[1].z * m[2].y)
+ - m[0].y * (m[1].x * m[2].z - m[1].z * m[2].x)
+ + m[0].z * (m[1].x * m[2].y - m[1].y * m[2].x));
}
float determinant(mat4 m)
{
- float SubFactor00 = m[2][2] * m[3][3] - m[3][2] * m[2][3];
- float SubFactor01 = m[2][1] * m[3][3] - m[3][1] * m[2][3];
- float SubFactor02 = m[2][1] * m[3][2] - m[3][1] * m[2][2];
- float SubFactor03 = m[2][0] * m[3][3] - m[3][0] * m[2][3];
- float SubFactor04 = m[2][0] * m[3][2] - m[3][0] * m[2][2];
- float SubFactor05 = m[2][0] * m[3][1] - m[3][0] * m[2][1];
- float SubFactor06 = m[1][2] * m[3][3] - m[3][2] * m[1][3];
- float SubFactor07 = m[1][1] * m[3][3] - m[3][1] * m[1][3];
- float SubFactor08 = m[1][1] * m[3][2] - m[3][1] * m[1][2];
- float SubFactor09 = m[1][0] * m[3][3] - m[3][0] * m[1][3];
- float SubFactor10 = m[1][0] * m[3][2] - m[3][0] * m[1][2];
- float SubFactor11 = m[1][1] * m[3][3] - m[3][1] * m[1][3];
- float SubFactor12 = m[1][0] * m[3][1] - m[3][0] * m[1][1];
- float SubFactor13 = m[1][2] * m[2][3] - m[2][2] * m[1][3];
- float SubFactor14 = m[1][1] * m[2][3] - m[2][1] * m[1][3];
- float SubFactor15 = m[1][1] * m[2][2] - m[2][1] * m[1][2];
- float SubFactor16 = m[1][0] * m[2][3] - m[2][0] * m[1][3];
- float SubFactor17 = m[1][0] * m[2][2] - m[2][0] * m[1][2];
- float SubFactor18 = m[1][0] * m[2][1] - m[2][0] * m[1][1];
+ float SubFactor00 = m[2].z * m[3].w - m[3].z * m[2].w;
+ float SubFactor01 = m[2].y * m[3].w - m[3].y * m[2].w;
+ float SubFactor02 = m[2].y * m[3].z - m[3].y * m[2].z;
+ float SubFactor03 = m[2].x * m[3].w - m[3].x * m[2].w;
+ float SubFactor04 = m[2].x * m[3].z - m[3].x * m[2].z;
+ float SubFactor05 = m[2].x * m[3].y - m[3].x * m[2].y;
+ float SubFactor06 = m[1].z * m[3].w - m[3].z * m[1].w;
+ float SubFactor07 = m[1].y * m[3].w - m[3].y * m[1].w;
+ float SubFactor08 = m[1].y * m[3].z - m[3].y * m[1].z;
+ float SubFactor09 = m[1].x * m[3].w - m[3].x * m[1].w;
+ float SubFactor10 = m[1].x * m[3].z - m[3].x * m[1].z;
+ float SubFactor11 = m[1].y * m[3].w - m[3].y * m[1].w;
+ float SubFactor12 = m[1].x * m[3].y - m[3].x * m[1].y;
+ float SubFactor13 = m[1].z * m[2].w - m[2].z * m[1].w;
+ float SubFactor14 = m[1].y * m[2].w - m[2].y * m[1].w;
+ float SubFactor15 = m[1].y * m[2].z - m[2].y * m[1].z;
+ float SubFactor16 = m[1].x * m[2].w - m[2].x * m[1].w;
+ float SubFactor17 = m[1].x * m[2].z - m[2].x * m[1].z;
+ float SubFactor18 = m[1].x * m[2].y - m[2].x * m[1].y;
vec4 adj_0;
- adj_0[0] = + (m[1][1] * SubFactor00 - m[1][2] * SubFactor01 + m[1][3]
* SubFactor02);
- adj_0[1] = - (m[1][0] * SubFactor00 - m[1][2] * SubFactor03 + m[1][3]
* SubFactor04);
- adj_0[2] = + (m[1][0] * SubFactor01 - m[1][1] * SubFactor03 + m[1][3]
* SubFactor05);
- adj_0[3] = - (m[1][0] * SubFactor02 - m[1][1] * SubFactor04 + m[1][2]
* SubFactor05);
+ adj_0.x = + (m[1].y * SubFactor00 - m[1].z * SubFactor01 +
Re: [Mesa-dev] [PATCH V2] mesa: provide default implementation of QuerySamplesForFormat
A slightly modified version of this (drop the target parameter) should be a candidate for the 9.1 branch. On Fri, Mar 29, 2013 at 5:23 PM, Kenneth Graunke kenn...@whitecape.org wrote: On 03/28/2013 08:28 PM, Chris Forbes wrote: Previously at least i915 failed to provide an implementation, but exposed ARB_internalformat_query anyway, leading to crashes when QueryInternalformativ was called. Default implementation just returns 1 for everything, so is suitable for any driver which does not support multisampling. V2: - Move from intel to core mesa. Signed-off-by: Chris Forbes chr...@ijw.co.nz Reviewed-by: Kenneth Graunke kenn...@whitecape.org ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] draw/so: Fix bogus assert
We do support so with multiple primitives.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/draw/draw_so_emit_tmp.h |1 -
1 file changed, 1 deletion(-)
diff --git a/src/gallium/auxiliary/draw/draw_so_emit_tmp.h
b/src/gallium/auxiliary/draw/draw_so_emit_tmp.h
index ec31c3f..4611cd0 100644
--- a/src/gallium/auxiliary/draw/draw_so_emit_tmp.h
+++ b/src/gallium/auxiliary/draw/draw_so_emit_tmp.h
@@ -12,7 +12,6 @@
const boolean quads_flatshade_last = FALSE;\
const boolean last_vertex_last = TRUE; \
do { \
- debug_assert(input_prims-primitive_count == 1);\
switch (prim) { \
case PIPE_PRIM_LINES_ADJACENCY: \
case PIPE_PRIM_LINE_STRIP_ADJACENCY:\
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] draw: Implement support for primitive id
We were largely ignoring primitive id.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/draw/draw_gs.c| 20 +++-
src/gallium/auxiliary/draw/draw_gs.h|1 +
src/gallium/auxiliary/draw/draw_llvm.c | 15 +--
src/gallium/auxiliary/draw/draw_llvm.h |3 ++-
src/gallium/auxiliary/gallivm/lp_bld_tgsi.h |1 +
src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c |5 +
src/gallium/auxiliary/tgsi/tgsi_scan.c |2 ++
src/gallium/auxiliary/tgsi/tgsi_scan.h |1 +
8 files changed, 40 insertions(+), 8 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_gs.c
b/src/gallium/auxiliary/draw/draw_gs.c
index 378d158..cc2f2fa 100644
--- a/src/gallium/auxiliary/draw/draw_gs.c
+++ b/src/gallium/auxiliary/draw/draw_gs.c
@@ -237,10 +237,7 @@ llvm_fetch_gs_input(struct draw_geometry_shader *shader,
(const char *)input_ptr + (indices[i] * input_vertex_stride));
for (slot = 0, vs_slot = 0; slot shader-info.num_inputs; ++slot) {
if (shader-info.input_semantic_name[slot] == TGSI_SEMANTIC_PRIMID) {
-(*input_data)[i][slot][0][prim_idx] = (float)shader-in_prim_idx;
-(*input_data)[i][slot][1][prim_idx] = (float)shader-in_prim_idx;
-(*input_data)[i][slot][2][prim_idx] = (float)shader-in_prim_idx;
-(*input_data)[i][slot][3][prim_idx] = (float)shader-in_prim_idx;
+/* skip. we handle system values through gallivm */
} else {
vs_slot = draw_gs_get_input_index(
shader-info.input_semantic_name[slot],
@@ -343,7 +340,8 @@ llvm_gs_run(struct draw_geometry_shader *shader,
shader-jit_context, shader-gs_input-data,
(struct vertex_header*)input,
input_primitives,
- shader-draw-instance_id);
+ shader-draw-instance_id,
+ shader-llvm_prim_ids);
return ret;
}
@@ -381,6 +379,8 @@ static void gs_point(struct draw_geometry_shader *shader,
shader-fetch_inputs(shader, indices, 1,
shader-fetched_prim_count);
+ shader-llvm_prim_ids[shader-fetched_prim_count] =
+ shader-in_prim_idx;
++shader-in_prim_idx;
++shader-fetched_prim_count;
@@ -398,6 +398,8 @@ static void gs_line(struct draw_geometry_shader *shader,
shader-fetch_inputs(shader, indices, 2,
shader-fetched_prim_count);
+ shader-llvm_prim_ids[shader-fetched_prim_count] =
+ shader-in_prim_idx;
++shader-in_prim_idx;
++shader-fetched_prim_count;
@@ -417,6 +419,8 @@ static void gs_line_adj(struct draw_geometry_shader *shader,
shader-fetch_inputs(shader, indices, 4,
shader-fetched_prim_count);
+ shader-llvm_prim_ids[shader-fetched_prim_count] =
+ shader-in_prim_idx;
++shader-in_prim_idx;
++shader-fetched_prim_count;
@@ -435,6 +439,8 @@ static void gs_tri(struct draw_geometry_shader *shader,
shader-fetch_inputs(shader, indices, 3,
shader-fetched_prim_count);
+ shader-llvm_prim_ids[shader-fetched_prim_count] =
+ shader-in_prim_idx;
++shader-in_prim_idx;
++shader-fetched_prim_count;
@@ -457,6 +463,8 @@ static void gs_tri_adj(struct draw_geometry_shader *shader,
shader-fetch_inputs(shader, indices, 6,
shader-fetched_prim_count);
+ shader-llvm_prim_ids[shader-fetched_prim_count] =
+ shader-in_prim_idx;
++shader-in_prim_idx;
++shader-fetched_prim_count;
@@ -728,6 +736,7 @@ draw_create_geometry_shader(struct draw_context *draw,
gs-llvm_emitted_primitives = align_malloc(vector_size, vector_size);
gs-llvm_emitted_vertices = align_malloc(vector_size, vector_size);
+ gs-llvm_prim_ids = align_malloc(vector_size, vector_size);
gs-fetch_outputs = llvm_fetch_gs_outputs;
gs-fetch_inputs = llvm_fetch_gs_input;
@@ -796,6 +805,7 @@ void draw_delete_geometry_shader(struct draw_context *draw,
}
align_free(dgs-llvm_emitted_primitives);
align_free(dgs-llvm_emitted_vertices);
+ align_free(dgs-llvm_prim_ids);
align_free(dgs-gs_input);
}
diff --git a/src/gallium/auxiliary/draw/draw_gs.h
b/src/gallium/auxiliary/draw/draw_gs.h
index 9c82648..7c84139 100644
--- a/src/gallium/auxiliary/draw/draw_gs.h
+++ b/src/gallium/auxiliary/draw/draw_gs.h
@@ -95,6 +95,7 @@ struct draw_geometry_shader {
int **llvm_prim_lengths;
int *llvm_emitted_primitives;
int *llvm_emitted_vertices;
+ int *llvm_prim_ids;
#endif
void (*fetch_inputs)(struct draw_geometry_shader *shader,
diff --git a/src/gallium/auxiliary/draw/draw_llvm.c
b/src/gallium/auxiliary/draw/draw_llvm.c
index 4731c8c..d0199bb 100644
--- a/src/gallium/auxiliary/draw/draw_llvm.c
+++ b/src/gallium/auxiliary/draw/draw_llvm.c
@@ -1891,10 +1891,11 @@ draw_gs_llvm_generate(struct draw_llvm *llvm,
struct gallivm_state *gallivm = variant-gallivm;
[Mesa-dev] [PATCH 3/3] draw/so: maintain an exact number of written vertices
It's quite helpful during the rendering when we know
exactly the count of the vertices available in the
buffer.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/draw/draw_context.h|1 +
src/gallium/auxiliary/draw/draw_pt.c | 18 +++---
src/gallium/auxiliary/draw/draw_pt_so_emit.c |4 +++-
3 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_context.h
b/src/gallium/auxiliary/draw/draw_context.h
index 369f6c8..b333457 100644
--- a/src/gallium/auxiliary/draw/draw_context.h
+++ b/src/gallium/auxiliary/draw/draw_context.h
@@ -60,6 +60,7 @@ struct draw_so_target {
struct pipe_stream_output_target target;
void *mapping;
int internal_offset;
+ int emitted_vertices;
};
struct draw_context *draw_create( struct pipe_context *pipe );
diff --git a/src/gallium/auxiliary/draw/draw_pt.c
b/src/gallium/auxiliary/draw/draw_pt.c
index 50b9efa..7026dbf 100644
--- a/src/gallium/auxiliary/draw/draw_pt.c
+++ b/src/gallium/auxiliary/draw/draw_pt.c
@@ -468,10 +468,20 @@ draw_vbo(struct draw_context *draw,
assert(info-instance_count 0);
if (info-indexed)
assert(draw-pt.user.elts);
+
+ count = info-count;
+ if (count == 0) {
+ if (info-count_from_stream_output)
+ count = draw-pt.max_index + 1;
+ }
draw-pt.user.eltBias = info-index_bias;
draw-pt.user.min_index = info-min_index;
- draw-pt.user.max_index = info-max_index;
+ if (info-count_from_stream_output) {
+ draw-pt.user.max_index = count;
+ } else {
+ draw-pt.user.max_index = info-max_index;
+ }
draw-pt.user.eltSize = info-indexed ? draw-pt.user.eltSizeIB : 0;
if (0)
@@ -518,12 +528,6 @@ draw_vbo(struct draw_context *draw,
draw-pt.max_index = index_limit - 1;
- count = info-count;
- if (count == 0) {
- if (info-count_from_stream_output)
- count = draw-pt.max_index + 1;
- }
-
/*
* TODO: We could use draw-pt.max_index to further narrow
* the min_index/max_index hints given by the state tracker.
diff --git a/src/gallium/auxiliary/draw/draw_pt_so_emit.c
b/src/gallium/auxiliary/draw/draw_pt_so_emit.c
index 25584a9..ae071a6 100644
--- a/src/gallium/auxiliary/draw/draw_pt_so_emit.c
+++ b/src/gallium/auxiliary/draw/draw_pt_so_emit.c
@@ -174,8 +174,10 @@ static void so_emit_prim(struct pt_so_emit *so,
else
memcpy(buffer, input[idx][start_comp], num_comps * sizeof(float));
}
- for (ob = 0; ob draw-so.num_targets; ++ob)
+ for (ob = 0; ob draw-so.num_targets; ++ob) {
draw-so.targets[ob]-internal_offset += state-stride[ob] *
sizeof(float);
+ draw-so.targets[ob]-emitted_vertices += 1;
+ }
}
so-emitted_vertices += num_vertices;
++so-emitted_primitives;
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965/fs: Don't immediately schedule instructions that were just made available.
The original goal of pre-register allocation scheduling was to reduce
live ranges so we'd use fewer registers and hopefully fit into 16-wide.
In shader-db, this change causes us to lose 30 16-wide programs, but we
gain 29... so it's a toss-up. At least by choosing instructions in a
better order all programs should be slightly faster.
On Haswell GLB2.5 C24Z16_DXT1 1600x900 non-composited:
x before-
+ after-
+--+
|++|
| x x x + ++|
|x xx +|
| |__A_| |AM||
+--+
N Min MaxMedian AvgStddev
x 108794.6 8825.44 8812.44 8811.01 10.288483
+ 10 9110.87 9129.38 9124.95 9122.438 6.38743
Difference at 95.0% confidence
311.428 +/- 8.04582
3.53453% +/- 0.0913155%
(Student's t, pooled s = 8.56306)
Consider the trivial case of
uniform float a, b;
void main() { gl_FragColor = vec4(cross(a, b)); }
Before the patch we compile this to
mov.sat(8) m41F 0F
mul(8) g31F g2.40,1,0F g20,1,0F
mad.sat(8) m31F -g34,1,1F g2.34,1,1F.x g2.14,1,1F.x
mul(8) g31F g2.30,1,0F g2.20,1,0F
mad.sat(8) m21F -g34,1,1F g2.54,1,1F.x g24,1,1F.x
mul(8) g31F g2.50,1,0F g2.10,1,0F
mad.sat(8) m11F -g34,1,1F g2.44,1,1F.x g2.24,1,1F.x
sendc(8)nullm18,8,1F
where we stall on each mad.sat waiting for the mul to finish. The sendc
is issued cycle 66. After the patch it compiles to
mul(8) g31F g2.50,1,0F g2.10,1,0F
mul(8) g41F g2.30,1,0F g2.20,1,0F
mul(8) g51F g2.40,1,0F g20,1,0F
mov.sat(8) m41F 0F
mad.sat(8) m11F -g34,1,1F g2.44,1,1F.x g2.24,1,1F.x
mad.sat(8) m21F -g44,1,1F g2.54,1,1F.x g24,1,1F.x
mad.sat(8) m31F -g54,1,1F g2.34,1,1F.x g2.14,1,1F.x
sendc(8)nullm18,8,1F
By hiding much of the latency, the sendc instruction is issued by cycle
32.
---
.../dri/i965/brw_fs_schedule_instructions.cpp | 46 --
1 file changed, 7 insertions(+), 39 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_schedule_instructions.cpp
b/src/mesa/drivers/dri/i965/brw_fs_schedule_instructions.cpp
index 997341b..4aeb738 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_schedule_instructions.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_schedule_instructions.cpp
@@ -725,48 +725,16 @@ instruction_scheduler::schedule_instructions(fs_inst
*next_block_header)
schedule_node *chosen = NULL;
int chosen_time = 0;
- if (post_reg_alloc) {
- /* Of the instructions closest ready to execute or the closest to
- * being ready, choose the oldest one.
- */
- foreach_list(node, instructions) {
-schedule_node *n = (schedule_node *)node;
-
-if (!chosen || n-unblocked_time chosen_time) {
- chosen = n;
- chosen_time = n-unblocked_time;
-}
- }
- } else {
- /* Before register allocation, we don't care about the latencies of
- * instructions. All we care about is reducing live intervals of
- * variables so that we can avoid register spilling, or get 16-wide
- * shaders which naturally do a better job of hiding instruction
- * latency.
- *
- * To do so, schedule our instructions in a roughly LIFO/depth-first
- * order: when new instructions become available as a result of
- * scheduling something, choose those first so that our result
- * hopefully is consumed quickly.
- *
- * The exception is messages that generate more than one result
- * register (AKA texturing). In those cases, the LIFO search would
- * normally tend to choose them quickly (because scheduling the
- * previous message not only unblocked the children using its result,
- * but also the MRF setup for the next sampler message, which in turn
- * unblocks the next sampler message).
- */
- for (schedule_node *node = (schedule_node *)instructions.get_tail();
- node != instructions.get_head()-prev;
- node = (schedule_node *)node-prev) {
-schedule_node *n = (schedule_node *)node;
+ /* Of the instructions closest ready to execute or the closest to
+ * being ready, choose the oldest one.
+ */
+ foreach_list(node, instructions) {
+ schedule_node *n = (schedule_node *)node;
+ if (!chosen || n-unblocked_time chosen_time) {
chosen = n;
-if (chosen-inst-regs_written() = 1)
- break;
+
[Mesa-dev] [PATCH] drirc: set always_have_depth_buffer for Topogon
--- src/mesa/drivers/dri/common/drirc |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/src/mesa/drivers/dri/common/drirc b/src/mesa/drivers/dri/common/drirc index a13941f..556d1b5 100644 --- a/src/mesa/drivers/dri/common/drirc +++ b/src/mesa/drivers/dri/common/drirc @@ -25,5 +25,11 @@ application name=Savage 2 executable=savage2.bin option name=disable_glsl_line_continuations value=true / /application +application name=Topogun (32-bit) executable=topogun32 +option name=always_have_depth_buffer value=true / +/application +application name=Topogun (64-bit) executable=topogun64 +option name=always_have_depth_buffer value=true / +/application /device /driconf -- 1.7.3.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] docs: add a new page documenting known application issues
On 03/29/2013 12:49 PM, Kenneth Graunke wrote: On 03/29/2013 07:30 AM, Brian Paul wrote: On 03/29/2013 04:50 AM, Jose Fonseca wrote: BTW, do users need to manually configure this, or will it be automatically set based on process name? Manually. Though the DRI conf tool can be used to set it per-application, I believe. -Brian We actually ship a default drirc already in src/mesa/drivers/common/drirc, which we expect will get installed by distro packages. You might want to add the workaround for Topogun there so it happens automatically... Thanks, I wasn't aware of that. I've posted a patch. What do you think of my Intel patch for this option? Could you possibly test Topogon? -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 62919] New: piglit getteximage-targets S3TC 2D_ARRAY regression
https://bugs.freedesktop.org/show_bug.cgi?id=62919
Priority: medium
Bug ID: 62919
Keywords: regression
CC: mar...@gmail.com
Assignee: mesa-dev@lists.freedesktop.org
Summary: piglit getteximage-targets S3TC 2D_ARRAY regression
Severity: normal
Classification: Unclassified
OS: All
Reporter: v...@freedesktop.org
Hardware: Other
Status: NEW
Version: git
Component: Mesa core
Product: Mesa
mesa: c34bbe110d1e562b1594a9a4f2e83a2ab5630036 (master)
$ ./bin/getteximage-targets S3TC 2D_ARRAY -auto
Testing S3TC.
Testing GL_TEXTURE_2D_ARRAY
GetTexImage() returns incorrect data in byte 0 for layer 1
corresponding to (0,0), channel 0
expected: 8
got: 123
PIGLIT: {'result': 'fail' }
3e10ab6b22341c06a9352b1e029b923f4d8405b9 is the first bad commit
commit 3e10ab6b22341c06a9352b1e029b923f4d8405b9
Author: Marek Olšák mar...@gmail.com
Date: Thu Mar 14 17:18:43 2013 +0100
gallium,st/mesa: don't use blit-based transfers with software rasterizers
The blit-based paths for TexImage, GetTexImage, and ReadPixels aren't very
fast with software rasterizer. Now Gallium drivers have the ability to turn
them off.
Reviewed-by: Brian Paul bri...@vmware.com
Tested-by: Brian Paul bri...@vmware.com
:04 04 73beb3047ac1c1f7fd5dd78f8ff219aed4970165
7af39a7d024dd235ed553fc91f231682d90bcb85 Msrc
bisect run success
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] ACTIVE_UNIFORM_MAX_LENGTH should include 3 extra characters for arrays.
If the active uniform is an array, then the length of the uniform name should
include the three extra characters for the [0] suffix, which is required by
the GL 4.2 spec to be appended to the uniform name in glGetActiveUniform().
This avoids the situation where the output buffer does not have enough space
to hold the [0] suffix, resulting in an incomplete array specification like
foobar[0.
Change-Id: Icd58cd6a73c9de7bbe5659d757b8009021846019
Signed-off-by: Haixia Shi h...@chromium.org
Reviewed-by: Stéphane Marchesin marc...@chromium.org
---
src/mesa/main/shaderapi.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
index be69467..68767f4 100644
--- a/src/mesa/main/shaderapi.c
+++ b/src/mesa/main/shaderapi.c
@@ -519,8 +519,11 @@ get_programiv(struct gl_context *ctx, GLuint
program, GLenum pname, GLint *param
for (i = 0; i shProg-NumUserUniformStorage; i++) {
/* Add one for the terminating NUL character.
+ * However if the uniform is an array, then add three extra characters
+ * for the appended [0] suffix, in addition to the terminating NUL.
*/
-const GLint len = strlen(shProg-UniformStorage[i].name) + 1;
+const GLint len = strlen(shProg-UniformStorage[i].name) + 1 +
+((shProg-UniformStorage[i].array_elements != 0) ? 3 : 0);
if (len max_len)
max_len = len;
--
1.8.1.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 62920] New: [softpipe] getteximage-targets S3TC CUBE_ARRAY
https://bugs.freedesktop.org/show_bug.cgi?id=62920
Priority: medium
Bug ID: 62920
Keywords: regression
CC: mar...@gmail.com
Assignee: mesa-dev@lists.freedesktop.org
Summary: [softpipe] getteximage-targets S3TC CUBE_ARRAY
Severity: normal
Classification: Unclassified
OS: Linux (All)
Reporter: v...@freedesktop.org
Hardware: x86-64 (AMD64)
Status: NEW
Version: git
Component: Mesa core
Product: Mesa
mesa: c34bbe110d1e562b1594a9a4f2e83a2ab5630036 (master)
$ ./bin/getteximage-targets S3TC CUBE_ARRAY -auto
Testing S3TC.
Testing GL_TEXTURE_CUBE_MAP_ARRAY
GetTexImage() returns incorrect data in byte 0 for layer 1
corresponding to (0,0), channel 0
expected: 8
got: 123
PIGLIT: {'result': 'fail' }
3e10ab6b22341c06a9352b1e029b923f4d8405b9 is the first bad commit
commit 3e10ab6b22341c06a9352b1e029b923f4d8405b9
Author: Marek Olšák mar...@gmail.com
Date: Thu Mar 14 17:18:43 2013 +0100
gallium,st/mesa: don't use blit-based transfers with software rasterizers
The blit-based paths for TexImage, GetTexImage, and ReadPixels aren't very
fast with software rasterizer. Now Gallium drivers have the ability to turn
them off.
Reviewed-by: Brian Paul bri...@vmware.com
Tested-by: Brian Paul bri...@vmware.com
:04 04 73beb3047ac1c1f7fd5dd78f8ff219aed4970165
7af39a7d024dd235ed553fc91f231682d90bcb85 Msrc
bisect run success
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] r600g: Add a Cayman specific version of UMAD
I found an issue with the shader compiler for Cayman when I looked into why the ext_transform_feedback/order test case caused a GPU stall. It turned out the stall was an infinite loop that was the result of broken calculation in the shader function. The issue is that Cayman uses the tgsi_umad function for UMAD, but that does not work since it does not populate the y, z and w slots for UMUL that cayman requires. This patch implements a cayman_umad. There are some things I'm unsure of though. The UMUL for Cayman is compiled to, as far as I can tell, ALU_OP2_MULLO_INT and not ALU_OP2_MULLO_UINT. So I do not know if I should use the int or the uint version in cayman_umad. In the patch I used the uint one, because that seemed the most logical. The add part of UMAD I copied from tgsi_umad and that had a loop around the variable lasti, but the variable lasti is usally not used in cayman specific code. This is used in tgsi functions. int lasti = tgsi_last_instruction(inst-Dst[0].Register.WriteMask); But in cayman specific code this is used instead. int last_slot = (inst-Dst[0].Register.WriteMask 0x8) ? 4 : 3; It does not work to switch lasti with last_slot, since that makes the loop run too many times (in my test case lasti is 0 and last_slot is 3). So I just removed the loop, was that correct or should i resolve that in some other way? Martin Andersson (1): r600g: Add a Cayman specific version of UMAD src/gallium/drivers/r600/r600_shader.c | 47 +- 1 file changed, 46 insertions(+), 1 deletion(-) -- 1.8.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] r600g: Add a Cayman specific version of UMAD
The tgsi_umad function does not work for Cayman since it does not
populate the y, z and w slots for UMUL that Cayman requires.
---
src/gallium/drivers/r600/r600_shader.c | 47 +-
1 file changed, 46 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/r600_shader.c
b/src/gallium/drivers/r600/r600_shader.c
index 29facf7..aa23907 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -2111,6 +2111,51 @@ static int cayman_mul_int_instr(struct r600_shader_ctx
*ctx)
return 0;
}
+static int cayman_umad(struct r600_shader_ctx *ctx)
+{
+ struct tgsi_full_instruction *inst =
ctx-parse.FullToken.FullInstruction;
+ struct r600_bytecode_alu alu;
+ int i, j, k, r;
+ int last_slot = (inst-Dst[0].Register.WriteMask 0x8) ? 4 : 3;
+
+ for (k = 0; k last_slot; k++) {
+ if (!(inst-Dst[0].Register.WriteMask (1 k)))
+ continue;
+
+ for (i = 0 ; i 4; i++) {
+ memset(alu, 0, sizeof(struct r600_bytecode_alu));
+ alu.op = ALU_OP2_MULLO_UINT;
+ for (j = 0; j inst-Instruction.NumSrcRegs; j++) {
+ r600_bytecode_src(alu.src[j], ctx-src[j], k);
+ }
+ alu.dst.chan = i;
+ alu.dst.sel = ctx-temp_reg;
+ alu.dst.write = (i == k);
+ if (i == 3)
+ alu.last = 1;
+ r = r600_bytecode_add_alu(ctx-bc, alu);
+ if (r)
+ return r;
+ }
+ }
+
+ memset(alu, 0, sizeof(struct r600_bytecode_alu));
+ tgsi_dst(ctx, inst-Dst[0], 0, alu.dst);
+
+ alu.op = ALU_OP2_ADD_INT;
+
+ alu.src[0].sel = ctx-temp_reg;
+ alu.src[0].chan = 0;
+
+ r600_bytecode_src(alu.src[1], ctx-src[2], 0);
+ alu.last = 1;
+ r = r600_bytecode_add_alu(ctx-bc, alu);
+ if (r)
+ return r;
+
+ return 0;
+}
+
/*
* r600 - trunc to -PI..PI range
* r700 - normalize by dividing by 2PI
@@ -6356,7 +6401,7 @@ static struct r600_shader_tgsi_instruction
cm_shader_tgsi_instruction[] = {
{TGSI_OPCODE_U2F, 0, ALU_OP1_UINT_TO_FLT, tgsi_op2},
{TGSI_OPCODE_UADD, 0, ALU_OP2_ADD_INT, tgsi_op2},
{TGSI_OPCODE_UDIV, 0, ALU_OP0_NOP, tgsi_udiv},
- {TGSI_OPCODE_UMAD, 0, ALU_OP0_NOP, tgsi_umad},
+ {TGSI_OPCODE_UMAD, 0, ALU_OP0_NOP, cayman_umad},
{TGSI_OPCODE_UMAX, 0, ALU_OP2_MAX_UINT, tgsi_op2},
{TGSI_OPCODE_UMIN, 0, ALU_OP2_MIN_UINT, tgsi_op2},
{TGSI_OPCODE_UMOD, 0, ALU_OP0_NOP, tgsi_umod},
--
1.8.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 62919] piglit getteximage-targets S3TC 2D_ARRAY regression
https://bugs.freedesktop.org/show_bug.cgi?id=62919 --- Comment #1 from Marek Olšák mar...@gmail.com --- The commit turned off the decompression with a blit for software rasterizers, so we're hitting a code path we never used for years. I think this uncovers an existing old bug instead of introducing a new one. -- 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 62920] [softpipe] piglit getteximage-targets S3TC CUBE_ARRAY regression
https://bugs.freedesktop.org/show_bug.cgi?id=62920 Vinson Lee v...@freedesktop.org changed: What|Removed |Added Summary|[softpipe] |[softpipe] piglit |getteximage-targets S3TC|getteximage-targets S3TC |CUBE_ARRAY |CUBE_ARRAY regression -- 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 62921] New: [llvmpipe] piglit arb_color_buffer_float-drawpixels GL_RGBA16F regression
https://bugs.freedesktop.org/show_bug.cgi?id=62921
Priority: medium
Bug ID: 62921
Keywords: regression
CC: srol...@vmware.com
Assignee: mesa-dev@lists.freedesktop.org
Summary: [llvmpipe] piglit arb_color_buffer_float-drawpixels
GL_RGBA16F regression
Severity: normal
Classification: Unclassified
OS: Linux (All)
Reporter: v...@freedesktop.org
Hardware: x86-64 (AMD64)
Status: NEW
Version: git
Component: Mesa core
Product: Mesa
mesa: c34bbe110d1e562b1594a9a4f2e83a2ab5630036 (master)
$ ./bin/arb_color_buffer_float-drawpixels GL_RGBA16F -auto
Testing 16-bit floating-point FBO
glDrawPixels of fbo with fragment clamp TRUE (expecting clamping)
glDrawPixels of fbo with fragment clamp FIXED (expecting no clamping)
Probe at (0,1)
Expected: 0.50 1.125000 -156.00 390.00
Observed: 0.50 1.125000 156.00 390.00
glDrawPixels of fbo with fragment clamp FALSE (expecting no clamping)
Probe at (0,1)
Expected: 0.50 1.125000 -156.00 390.00
Observed: 0.50 1.125000 156.00 390.00
PIGLIT: {'result': 'fail' }
5f41e08cf39d585d600aa506cdcd2f5380c60ddd is the first bad commit
commit 5f41e08cf39d585d600aa506cdcd2f5380c60ddd
Author: Roland Scheidegger srol...@vmware.com
Date: Fri Mar 29 06:16:33 2013 +0100
gallivm: consolidate some half-to-float and r11g11b10-to-float code
Similar enough that we can try to use shared code.
v2: fix a stupid bug using wrong variable causing mayhem with Inf and NaNs.
Reviewed-by: Jose Fonseca jfons...@vmware.com
:04 04 85566eda1c3e30501aae05cd18e00a048eb185f8
896c63688122bfc9031bce85a0f806817d491559 Msrc
bisect run success
--
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 62922] New: [softpipe] piglit arb_seamless_cubemap regression
https://bugs.freedesktop.org/show_bug.cgi?id=62922
Priority: medium
Bug ID: 62922
Keywords: regression
CC: jfons...@vmware.com
Assignee: mesa-dev@lists.freedesktop.org
Summary: [softpipe] piglit arb_seamless_cubemap regression
Severity: normal
Classification: Unclassified
OS: Linux (All)
Reporter: v...@freedesktop.org
Hardware: x86-64 (AMD64)
Status: NEW
Version: git
Component: Other
Product: Mesa
mesa: c34bbe110d1e562b1594a9a4f2e83a2ab5630036 (master)
$ ./bin/arb_seamless_cubemap -auto
Probe at (80,20)
Expected: 0.50 0.00 0.50
Observed: 1.00 0.00 0.00
Probe at (110,20)
Expected: 0.50 0.00 0.50
Observed: 0.00 0.00 1.00
PIGLIT: {'result': 'fail' }
6a3d77e13dbae17000e35ce16023532200e68d09 is the first bad commit
commit 6a3d77e13dbae17000e35ce16023532200e68d09
Author: José Fonseca jfons...@vmware.com
Date: Thu Mar 14 11:44:21 2013 +
softpipe: Shrink context size.
- each softpipe_tex_tile_cache 50*64*64*4*4 = 3,276,800 bytes
- each softpipe_context has 3*32 softpipe_tex_tile_cache, i.e, each
softpipe
context is 314,572,800 bytes, i.e, 300MB
That is, in a 32bits process (around 3GB virtual memory max), we can
only fit 10 contexts.
This change is a short-term hack to shrink the context size. Longer
term we'll need to change how the texture cache works.
Reviewed-by: Brian Paul bri...@vmware.com
:04 04 64ff15d9847673c6545754f29cba7bcbdd4be457
727f8e3f8b282c58978ca3c4a9d637ebc4f7f21e Msrc
bisect run success
--
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
