[Mesa-dev] [PATCH 0/2] Make a llvmpipe context basically thread safe v2.
From: Mathias Fröhlich Hi Jose, This makes llvmpipe thread safe as mandated by the OpenGL standard. The changes replace the use of two global data structures with non global ones. The changes pass piglit as of today without regressions. The patchset now sticks to your initial suggestion and the review notes to the first patch version. Please review! Mathias Mathias Fröhlich (2): llvmpipe: Use two LLVMContexts per OpenGL context instead of a global one. llvmpipe: Make a llvmpipe OpenGL context thread safe. src/gallium/auxiliary/draw/draw_llvm.c| 15 +-- src/gallium/auxiliary/draw/draw_llvm.h| 2 ++ src/gallium/auxiliary/gallivm/lp_bld_init.c | 35 ++-- src/gallium/auxiliary/gallivm/lp_bld_init.h | 3 ++- src/gallium/auxiliary/gallivm/lp_bld_misc.cpp | 38 +-- src/gallium/auxiliary/gallivm/lp_bld_misc.h | 3 +++ src/gallium/drivers/llvmpipe/lp_context.c | 7 + src/gallium/drivers/llvmpipe/lp_context.h | 3 +++ src/gallium/drivers/llvmpipe/lp_state_fs.c| 2 +- src/gallium/drivers/llvmpipe/lp_state_setup.c | 2 +- src/gallium/drivers/llvmpipe/lp_test_arit.c | 2 +- src/gallium/drivers/llvmpipe/lp_test_blend.c | 2 +- src/gallium/drivers/llvmpipe/lp_test_conv.c | 2 +- src/gallium/drivers/llvmpipe/lp_test_format.c | 2 +- src/gallium/drivers/llvmpipe/lp_test_printf.c | 2 +- 15 files changed, 70 insertions(+), 50 deletions(-) -- 1.9.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] llvmpipe: Use two LLVMContexts per OpenGL context instead of a global one.
From: Mathias Fröhlich
This is one step to make llvmpipe thread safe as mandated by the OpenGL
standard. Using the global LLVMContext is obviously a problem for
that kind of use pattern. The patch introduces two LLVMContext
instances that are private to an OpenGL context and used for all
compiles. One is put into struct draw_llvm and the other
one into struct llvmpipe_context.
Signed-off-by: Mathias Froehlich
---
src/gallium/auxiliary/draw/draw_llvm.c| 15 --
src/gallium/auxiliary/draw/draw_llvm.h| 2 ++
src/gallium/auxiliary/gallivm/lp_bld_init.c | 28 +++
src/gallium/auxiliary/gallivm/lp_bld_init.h | 2 +-
src/gallium/drivers/llvmpipe/lp_context.c | 7 +++
src/gallium/drivers/llvmpipe/lp_context.h | 3 +++
src/gallium/drivers/llvmpipe/lp_state_fs.c| 2 +-
src/gallium/drivers/llvmpipe/lp_state_setup.c | 2 +-
src/gallium/drivers/llvmpipe/lp_test_arit.c | 2 +-
src/gallium/drivers/llvmpipe/lp_test_blend.c | 2 +-
src/gallium/drivers/llvmpipe/lp_test_conv.c | 2 +-
src/gallium/drivers/llvmpipe/lp_test_format.c | 2 +-
src/gallium/drivers/llvmpipe/lp_test_printf.c | 2 +-
13 files changed, 40 insertions(+), 31 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_llvm.c
b/src/gallium/auxiliary/draw/draw_llvm.c
index e8e837a..ae14fed 100644
--- a/src/gallium/auxiliary/draw/draw_llvm.c
+++ b/src/gallium/auxiliary/draw/draw_llvm.c
@@ -492,6 +492,10 @@ draw_llvm_create(struct draw_context *draw)
llvm->draw = draw;
+ llvm->context = LLVMContextCreate();
+ if (!llvm->context)
+ goto fail;
+
llvm->nr_variants = 0;
make_empty_list(&llvm->vs_variants_list);
@@ -499,6 +503,10 @@ draw_llvm_create(struct draw_context *draw)
make_empty_list(&llvm->gs_variants_list);
return llvm;
+
+fail:
+ draw_llvm_destroy(llvm);
+ return NULL;
}
@@ -508,6 +516,9 @@ draw_llvm_create(struct draw_context *draw)
void
draw_llvm_destroy(struct draw_llvm *llvm)
{
+ LLVMContextDispose(llvm->context);
+ llvm->context = NULL;
+
/* XXX free other draw_llvm data? */
FREE(llvm);
}
@@ -539,7 +550,7 @@ draw_llvm_create_variant(struct draw_llvm *llvm,
util_snprintf(module_name, sizeof(module_name), "draw_llvm_vs_variant%u",
variant->shader->variants_cached);
- variant->gallivm = gallivm_create(module_name);
+ variant->gallivm = gallivm_create(module_name, llvm->context);
create_jit_types(variant);
@@ -2194,7 +2205,7 @@ draw_gs_llvm_create_variant(struct draw_llvm *llvm,
util_snprintf(module_name, sizeof(module_name), "draw_llvm_gs_variant%u",
variant->shader->variants_cached);
- variant->gallivm = gallivm_create(module_name);
+ variant->gallivm = gallivm_create(module_name, llvm->context);
create_gs_jit_types(variant);
diff --git a/src/gallium/auxiliary/draw/draw_llvm.h
b/src/gallium/auxiliary/draw/draw_llvm.h
index ed97cf7..a4bd1ed 100644
--- a/src/gallium/auxiliary/draw/draw_llvm.h
+++ b/src/gallium/auxiliary/draw/draw_llvm.h
@@ -461,6 +461,8 @@ struct llvm_geometry_shader {
struct draw_llvm {
struct draw_context *draw;
+ LLVMContextRef context;
+
struct draw_jit_context jit_context;
struct draw_gs_jit_context gs_jit_context;
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_init.c
b/src/gallium/auxiliary/gallivm/lp_bld_init.c
index 8b8686d..dfc28b4 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_init.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_init.c
@@ -69,17 +69,6 @@
void LLVMLinkInMCJIT();
#endif
-/*
- * LLVM has several global caches which pointing/derived from objects
- * owned by the context, so if we freeing contexts causes
- * memory leaks and false cache hits when these objects are destroyed.
- *
- * TODO: For thread safety on multi-threaded OpenGL we should use one LLVM
- * context per thread, and put them in a pool when threads are destroyed.
- */
-#define USE_GLOBAL_CONTEXT 1
-
-
#ifdef DEBUG
unsigned gallivm_debug = 0;
@@ -193,8 +182,7 @@ gallivm_free_ir(struct gallivm_state *gallivm)
if (gallivm->builder)
LLVMDisposeBuilder(gallivm->builder);
- if (!USE_GLOBAL_CONTEXT && gallivm->context)
- LLVMContextDispose(gallivm->context);
+ /* The LLVMContext should be owned by the parent of gallivm. */
gallivm->engine = NULL;
gallivm->target = NULL;
@@ -285,18 +273,16 @@ fail:
* \return TRUE for success, FALSE for failure
*/
static boolean
-init_gallivm_state(struct gallivm_state *gallivm, const char *name)
+init_gallivm_state(struct gallivm_state *gallivm, const char *name,
+ LLVMContextRef context)
{
assert(!gallivm->context);
assert(!gallivm->module);
lp_build_init();
- if (USE_GLOBAL_CONTEXT) {
- gallivm->context = LLVMGetGlobalContext();
- } else {
- gallivm->context = LLVMContextCreate();
- }
+ gallivm->context = context;
+
if (!gallivm->context)
goto fail;
@@ -469,13 +455,13
[Mesa-dev] [PATCH 2/2] llvmpipe: Make a llvmpipe OpenGL context thread safe.
From: Mathias Fröhlich
This fixes the remaining problem with the recently introduced
global jit memory manager. This change again uses a memory manager
that is local to gallivm_state. This implementation still frees
the majority of the memory immediately after compilation.
Only the generated code is deferred until this code is no longer used.
This change and the previous one using private LLVMContext instances
I can now safely run several independent OpenGL contexts driven
by llvmpipe from different threads.
Signed-off-by: Mathias Froehlich
---
src/gallium/auxiliary/gallivm/lp_bld_init.c | 7 +
src/gallium/auxiliary/gallivm/lp_bld_init.h | 1 +
src/gallium/auxiliary/gallivm/lp_bld_misc.cpp | 38 +--
src/gallium/auxiliary/gallivm/lp_bld_misc.h | 3 +++
4 files changed, 30 insertions(+), 19 deletions(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_init.c
b/src/gallium/auxiliary/gallivm/lp_bld_init.c
index dfc28b4..a38979f 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_init.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_init.c
@@ -203,6 +203,8 @@ gallivm_free_code(struct gallivm_state *gallivm)
assert(!gallivm->engine);
lp_free_generated_code(gallivm->code);
gallivm->code = NULL;
+ LLVMDisposeMCJITMemoryManager(gallivm->memorymgr);
+ gallivm->memorymgr = NULL;
}
@@ -224,6 +226,7 @@ init_gallivm_engine(struct gallivm_state *gallivm)
ret = lp_build_create_jit_compiler_for_module(&gallivm->engine,
&gallivm->code,
gallivm->module,
+gallivm->memorymgr,
(unsigned) optlevel,
USE_MCJIT,
&error);
@@ -295,6 +298,10 @@ init_gallivm_state(struct gallivm_state *gallivm, const
char *name,
if (!gallivm->builder)
goto fail;
+ gallivm->memorymgr = lp_get_default_memory_manager();
+ if (!gallivm->memorymgr)
+ goto fail;
+
/* FIXME: MC-JIT only allows compiling one module at a time, and it must be
* complete when MC-JIT is created. So defer the MC-JIT engine creation for
* now.
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_init.h
b/src/gallium/auxiliary/gallivm/lp_bld_init.h
index 8f20158..cb78210 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_init.h
+++ b/src/gallium/auxiliary/gallivm/lp_bld_init.h
@@ -44,6 +44,7 @@ struct gallivm_state
LLVMPassManagerRef passmgr;
LLVMContextRef context;
LLVMBuilderRef builder;
+ LLVMMCJITMemoryManagerRef memorymgr;
struct lp_generated_code *code;
unsigned compiled;
};
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
index 55aa8b9..dc7206f 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
+++ b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
@@ -319,15 +319,15 @@ class DelegatingJITMemoryManager : public
llvm::JITMemoryManager {
*/
class ShaderMemoryManager : public DelegatingJITMemoryManager {
- static llvm::JITMemoryManager *TheMM;
- static unsigned NumUsers;
+ llvm::JITMemoryManager *TheMM;
struct GeneratedCode {
typedef std::vector Vec;
Vec FunctionBody, ExceptionTable;
+ llvm::JITMemoryManager *TheMM;
- GeneratedCode() {
- ++NumUsers;
+ GeneratedCode(llvm::JITMemoryManager *MM) {
+ TheMM = MM;
}
~GeneratedCode() {
@@ -344,27 +344,20 @@ class ShaderMemoryManager : public
DelegatingJITMemoryManager {
for ( i = ExceptionTable.begin(); i != ExceptionTable.end(); ++i )
TheMM->deallocateExceptionTable(*i);
#endif
- --NumUsers;
- if (NumUsers == 0) {
-delete TheMM;
-TheMM = 0;
- }
}
};
GeneratedCode *code;
llvm::JITMemoryManager *mgr() const {
- if (!TheMM) {
- TheMM = CreateDefaultMemManager();
- }
return TheMM;
}
public:
- ShaderMemoryManager() {
- code = new GeneratedCode;
+ ShaderMemoryManager(llvm::JITMemoryManager* MM) {
+ TheMM = MM;
+ code = new GeneratedCode(MM);
}
virtual ~ShaderMemoryManager() {
@@ -395,10 +388,6 @@ class ShaderMemoryManager : public
DelegatingJITMemoryManager {
}
};
-llvm::JITMemoryManager *ShaderMemoryManager::TheMM = 0;
-unsigned ShaderMemoryManager::NumUsers = 0;
-
-
/**
* Same as LLVMCreateJITCompilerForModule, but:
* - allows using MCJIT and enabling AVX feature where available.
@@ -414,6 +403,7 @@ LLVMBool
lp_build_create_jit_compiler_for_module(LLVMExecutionEngineRef *OutJIT,
lp_generated_code **OutCode,
LLVMModuleRef M,
+LLVMMCJITMemoryManagerRef
[Mesa-dev] [PATCH v3 2/3] glapi: add function pointers for KHR_debug for gles
Signed-off-by: Matthew Waters
---
src/mapi/glapi/gen/KHR_debug.xml| 73 +
src/mesa/main/extensions.c | 2 +-
src/mesa/main/tests/dispatch_sanity.cpp | 25 +++
3 files changed, 99 insertions(+), 1 deletion(-)
diff --git a/src/mapi/glapi/gen/KHR_debug.xml b/src/mapi/glapi/gen/KHR_debug.xml
index 48f7fa7..a5c826c 100644
--- a/src/mapi/glapi/gen/KHR_debug.xml
+++ b/src/mapi/glapi/gen/KHR_debug.xml
@@ -145,6 +145,79 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
index 553c01e..db0fc36 100644
--- a/src/mesa/main/extensions.c
+++ b/src/mesa/main/extensions.c
@@ -318,7 +318,7 @@ static const struct extension extension_table[] = {
{ "GL_OES_vertex_array_object", o(dummy_true),
ES1 | ES2, 2010 },
/* KHR extensions */
- { "GL_KHR_debug", o(dummy_true),
GL, 2012 },
+ { "GL_KHR_debug", o(dummy_true),
GL | ES1 | ES2, 2012 },
/* Vendor extensions */
{ "GL_3DFX_texture_compression_FXT1",
o(TDFX_texture_compression_FXT1), GL, 1999 },
diff --git a/src/mesa/main/tests/dispatch_sanity.cpp
b/src/mesa/main/tests/dispatch_sanity.cpp
index 04fa86b..51b8084 100644
--- a/src/mesa/main/tests/dispatch_sanity.cpp
+++ b/src/mesa/main/tests/dispatch_sanity.cpp
@@ -1146,6 +1146,19 @@ const struct function gles11_functions_possible[] = {
{ "glUnmapBufferOES", 11, -1 },
{ "glVertexPointer", 11, _gloffset_VertexPointer },
{ "glViewport", 11, _gloffset_Viewport },
+
+ /* GL_KHR_debug */
+ { "glPushDebugGroupKHR", 20, -1 },
+ { "glPopDebugGroupKHR", 20, -1 },
+ { "glDebugMessageCallbackKHR", 20, -1 },
+ { "glDebugMessageControlKHR", 20, -1 },
+ { "glDebugMessageInsertKHR", 20, -1 },
+ { "glGetDebugMessageLogKHR", 20, -1 },
+ { "glGetObjectLabelKHR", 20, -1 },
+ { "glGetObjectPtrLabelKHR", 20, -1 },
+ { "glObjectLabelKHR", 20, -1 },
+ { "glObjectPtrLabelKHR", 20, -1 },
+
{ NULL, 0, -1 }
};
@@ -1369,6 +1382,18 @@ const struct function gles2_functions_possible[] = {
{ "glEndPerfQueryINTEL", 20, -1 },
{ "glGetPerfQueryDataINTEL", 20, -1 },
+ /* GL_KHR_debug */
+ { "glPushDebugGroupKHR", 20, -1 },
+ { "glPopDebugGroupKHR", 20, -1 },
+ { "glDebugMessageCallbackKHR", 20, -1 },
+ { "glDebugMessageControlKHR", 20, -1 },
+ { "glDebugMessageInsertKHR", 20, -1 },
+ { "glGetDebugMessageLogKHR", 20, -1 },
+ { "glGetObjectLabelKHR", 20, -1 },
+ { "glGetObjectPtrLabelKHR", 20, -1 },
+ { "glObjectLabelKHR", 20, -1 },
+ { "glObjectPtrLabelKHR", 20, -1 },
+
{ NULL, 0, -1 }
};
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 1/3] egl: rework handling EGL_CONTEXT_FLAGS for ES debug contexts
As of version 15 of the EGL_KHR_create_context spec, debug contexts
are allowed for ES contexts. We should allow creation instead of
erroring.
Signed-off-by: Matthew Waters
---
src/egl/main/eglcontext.c | 51 ++
src/mesa/drivers/dri/common/dri_util.c | 17
2 files changed, 45 insertions(+), 23 deletions(-)
diff --git a/src/egl/main/eglcontext.c b/src/egl/main/eglcontext.c
index 514b91a..ab50fe7 100644
--- a/src/egl/main/eglcontext.c
+++ b/src/egl/main/eglcontext.c
@@ -121,12 +121,51 @@ _eglParseContextAttribList(_EGLContext *ctx, _EGLDisplay
*dpy,
/* The EGL_KHR_create_context spec says:
*
- * "Flags are only defined for OpenGL context creation, and
- * specifying a flags value other than zero for other types of
- * contexts, including OpenGL ES contexts, will generate an
- * error."
+ * "If the EGL_CONTEXT_OPENGL_DEBUG_BIT_KHR flag bit is set in
+ * EGL_CONTEXT_FLAGS_KHR, then a will be created.
+ * [...]
+ * In some cases a debug context may be identical to a non-debug
+ * context. This bit is supported for OpenGL and OpenGL ES
+ * contexts."
+ */
+ if (api != EGL_OPENGL_API && api != EGL_OPENGL_ES_API
+&& (val & EGL_CONTEXT_OPENGL_DEBUG_BIT_KHR)) {
+err = EGL_BAD_ATTRIBUTE;
+break;
+ }
+
+ /* The EGL_KHR_create_context spec says:
+ *
+ * "If the EGL_CONTEXT_OPENGL_FORWARD_COMPATIBLE_BIT_KHR flag bit
+ * is set in EGL_CONTEXT_FLAGS_KHR, then a
+ * context will be created. Forward-compatible contexts are
+ * defined only for OpenGL versions 3.0 and later. They must not
+ * support functionality marked as by that version of
+ * the API, while a non-forward-compatible context must support
+ * all functionality in that version, deprecated or not. This bit
+ * is supported for OpenGL contexts, and requesting a
+ * forward-compatible context for OpenGL versions less than 3.0
+ * will generate an error."
+ */
+ if ((val & EGL_CONTEXT_OPENGL_FORWARD_COMPATIBLE_BIT_KHR)
+&& (api != EGL_OPENGL_API || ctx->ClientMajorVersion < 3)) {
+err = EGL_BAD_ATTRIBUTE;
+break;
+ }
+
+ /* The EGL_KHR_create_context_spec says:
+ *
+ * "If the EGL_CONTEXT_OPENGL_ROBUST_ACCESS_BIT_KHR bit is set in
+ * EGL_CONTEXT_FLAGS_KHR, then a context supporting will be created. Robust buffer access is defined in the
+ * GL_ARB_robustness extension specification, and the resulting
+ * context must also support either the GL_ARB_robustness
+ * extension, or a version of OpenGL incorporating equivalent
+ * functionality. This bit is supported for OpenGL contexts.
*/
- if (api != EGL_OPENGL_API && val != 0) {
+ if ((val & EGL_CONTEXT_OPENGL_ROBUST_ACCESS_BIT_KHR)
+&& (api != EGL_OPENGL_API
+|| !dpy->Extensions.EXT_create_context_robustness)) {
err = EGL_BAD_ATTRIBUTE;
break;
}
@@ -194,7 +233,7 @@ _eglParseContextAttribList(_EGLContext *ctx, _EGLDisplay
*dpy,
break;
}
- ctx->Flags = EGL_CONTEXT_OPENGL_ROBUST_ACCESS_BIT_KHR;
+ ctx->Flags |= EGL_CONTEXT_OPENGL_ROBUST_ACCESS_BIT_KHR;
break;
default:
diff --git a/src/mesa/drivers/dri/common/dri_util.c
b/src/mesa/drivers/dri/common/dri_util.c
index 6c78928..7a953ba 100644
--- a/src/mesa/drivers/dri/common/dri_util.c
+++ b/src/mesa/drivers/dri/common/dri_util.c
@@ -376,23 +376,6 @@ driCreateContextAttribs(__DRIscreen *screen, int api,
return NULL;
}
-/* The EGL_KHR_create_context spec says:
- *
- * "Flags are only defined for OpenGL context creation, and specifying
- * a flags value other than zero for other types of contexts,
- * including OpenGL ES contexts, will generate an error."
- *
- * The GLX_EXT_create_context_es2_profile specification doesn't say
- * anything specific about this case. However, none of the known flags
- * have any meaning in an ES context, so this seems safe.
- */
-if (mesa_api != API_OPENGL_COMPAT
-&& mesa_api != API_OPENGL_CORE
-&& flags != 0) {
- *error = __DRI_CTX_ERROR_BAD_FLAG;
- return NULL;
-}
-
/* There are no forward-compatible contexts before OpenGL 3.0. The
* GLX_ARB_create_context spec says:
*
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 0/3] add KHR_debug for gles contexts
v3: - fix up the EGL_CONTEXT_OPENGL_ROBUST_ACCESS_BIT_KHR check v2: - replace &= with |= - remove offset="assign" from the api xml Matthew Waters (3): egl: rework handling EGL_CONTEXT_FLAGS for ES debug contexts glapi: add function pointers for KHR_debug for gles main/get: make KHR_debug enums available everywhere src/egl/main/eglcontext.c | 51 --- src/mapi/glapi/gen/KHR_debug.xml| 73 + src/mesa/drivers/dri/common/dri_util.c | 17 src/mesa/main/extensions.c | 2 +- src/mesa/main/get_hash_params.py| 24 +-- src/mesa/main/tests/dispatch_sanity.cpp | 25 +++ 6 files changed, 156 insertions(+), 36 deletions(-) -- 2.1.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 3/3] main/get: make KHR_debug enums available everywhere
Although GL_CONTEXT_FLAGS is not explicitly added by KHR_debug, it contains, "It is implementation defined how much debug output is generated if the context was created without the CONTEXT_DEBUG_BIT set. This is a new query bit added to the existing GL_CONTEXT_FLAGS state to specify whether the context was created with debug enabled." implying the GL_CONTEXT_FLAGS parameter is supported whenever KHR_debug is also supported. Signed-off-by: Matthew Waters --- src/mesa/main/get_hash_params.py | 24 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/src/mesa/main/get_hash_params.py b/src/mesa/main/get_hash_params.py index aace8a5..932944d 100644 --- a/src/mesa/main/get_hash_params.py +++ b/src/mesa/main/get_hash_params.py @@ -124,6 +124,18 @@ descriptor=[ # GL_EXT_texture_filter_anisotropic [ "MAX_TEXTURE_MAX_ANISOTROPY_EXT", "CONTEXT_FLOAT(Const.MaxTextureMaxAnisotropy), extra_EXT_texture_filter_anisotropic" ], + +# GL_KHR_debug (GL 4.3)/ GL_ARB_debug_output + [ "DEBUG_LOGGED_MESSAGES", "LOC_CUSTOM, TYPE_INT, 0, NO_EXTRA" ], + [ "DEBUG_NEXT_LOGGED_MESSAGE_LENGTH", "LOC_CUSTOM, TYPE_INT, 0, NO_EXTRA" ], + [ "MAX_DEBUG_LOGGED_MESSAGES", "CONST(MAX_DEBUG_LOGGED_MESSAGES), NO_EXTRA" ], + [ "MAX_DEBUG_MESSAGE_LENGTH", "CONST(MAX_DEBUG_MESSAGE_LENGTH), NO_EXTRA" ], + [ "MAX_LABEL_LENGTH", "CONST(MAX_LABEL_LENGTH), NO_EXTRA" ], + [ "MAX_DEBUG_GROUP_STACK_DEPTH", "CONST(MAX_DEBUG_GROUP_STACK_DEPTH), NO_EXTRA" ], + [ "DEBUG_GROUP_STACK_DEPTH", "LOC_CUSTOM, TYPE_INT, 0, NO_EXTRA" ], + +# GL 3.0 / KHR_debug + [ "CONTEXT_FLAGS", "CONTEXT_INT(Const.ContextFlags), NO_EXTRA" ], ]}, # Enums in OpenGL and GLES1 @@ -694,9 +706,6 @@ descriptor=[ # GL_ARB_sampler_objects / GL 3.3 [ "SAMPLER_BINDING", "LOC_CUSTOM, TYPE_INT, GL_SAMPLER_BINDING, NO_EXTRA" ], -# GL 3.0 - [ "CONTEXT_FLAGS", "CONTEXT_INT(Const.ContextFlags), extra_version_30" ], - # GL3.0 / GL_EXT_framebuffer_sRGB [ "FRAMEBUFFER_SRGB_EXT", "CONTEXT_BOOL(Color.sRGBEnabled), extra_EXT_framebuffer_sRGB" ], [ "FRAMEBUFFER_SRGB_CAPABLE_EXT", "BUFFER_INT(Visual.sRGBCapable), extra_EXT_framebuffer_sRGB_and_new_buffers" ], @@ -718,15 +727,6 @@ descriptor=[ # GL_ARB_robustness [ "RESET_NOTIFICATION_STRATEGY_ARB", "CONTEXT_ENUM(Const.ResetStrategy), NO_EXTRA" ], -# GL_KHR_debug (GL 4.3)/ GL_ARB_debug_output - [ "DEBUG_LOGGED_MESSAGES", "LOC_CUSTOM, TYPE_INT, 0, NO_EXTRA" ], - [ "DEBUG_NEXT_LOGGED_MESSAGE_LENGTH", "LOC_CUSTOM, TYPE_INT, 0, NO_EXTRA" ], - [ "MAX_DEBUG_LOGGED_MESSAGES", "CONST(MAX_DEBUG_LOGGED_MESSAGES), NO_EXTRA" ], - [ "MAX_DEBUG_MESSAGE_LENGTH", "CONST(MAX_DEBUG_MESSAGE_LENGTH), NO_EXTRA" ], - [ "MAX_LABEL_LENGTH", "CONST(MAX_LABEL_LENGTH), NO_EXTRA" ], - [ "MAX_DEBUG_GROUP_STACK_DEPTH", "CONST(MAX_DEBUG_GROUP_STACK_DEPTH), NO_EXTRA" ], - [ "DEBUG_GROUP_STACK_DEPTH", "LOC_CUSTOM, TYPE_INT, 0, NO_EXTRA" ], - [ "MAX_DUAL_SOURCE_DRAW_BUFFERS", "CONTEXT_INT(Const.MaxDualSourceDrawBuffers), extra_ARB_blend_func_extended" ], # GL_ARB_uniform_buffer_object -- 2.1.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC PATCH 00/16] A new IR for Mesa
If point-releases don't give enough control, lets have Mesa maintain its fork of LLVM, call it something completely different, like "mesa compiler toolchain", to make it clear to distribution packagers that this fork of LLVM has extra GPU goodness and, might not give the expected results for other uses, like compiling the linux kernel. We'd still merge from upstream LLVM whenever convenient, so it's not a permanent fork. Just something we control within Mesa community. So it's unnecessary to write our own compiler toolchain from scratch just to have control over the release/distribution aspects. This might be worth considering regardless whatever Intel decides to do regarding Mesa's IR,if the point releases aren't flexible enough for the needs of radeonsi etc. Jose From: mesa-dev on behalf of Marek Olšák Sent: 30 August 2014 12:07 To: Ian Romanick Cc: Greg Fischer; mesa-dev@lists.freedesktop.org Subject: Re: [Mesa-dev] [RFC PATCH 00/16] A new IR for Mesa On Thu, Aug 28, 2014 at 12:07 AM, Ian Romanick wrote: > On 08/27/2014 02:55 PM, Marek Olšák wrote: >> Our plan is to always require the latest released version of LLVM >> because of new features in our LLVM backend that the radeonsi driver >> depends on to advertise all GL features. Some new features listed for >> the radeonsi driver in Mesa release notes are only enabled if you have >> latest LLVM from git/svn. > > I think this underscores the fundamental problem have having such a > critical, core piece of project infrastructure being completely out of > the control of the project. For me, trying to ship a product on which > people rely, this is an absolute non-starter. > > At least with the other components on which Mesa relies (e.g., libdrm, > 2D drivers, etc.) it's largely the same group of people with the same > set of goals. With us doing LLVM point releases, we could squeeze new features into them if we need the features in Mesa *now*. I think this happened with geometry shaders for radeonsi and it's probably going to happen more often. So it's not so out of control. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=T2MjySDQbfDzKdCf7PXHtcdYIkvU8F56stl6QEh0LrE%3D%0A&s=adad408f93999ccb95f4a07c4d3a5e51736c240851b4ba7239b0a9380cda70d3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965/fs: Connect cfg properly in predicated break peephole.
If the ENDIF instruction was the only instruction in its block, we'd
leave the successors of the merged if+jump block in a bad state.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83080
---
.../drivers/dri/i965/brw_fs_peephole_predicated_break.cpp | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_peephole_predicated_break.cpp
b/src/mesa/drivers/dri/i965/brw_fs_peephole_predicated_break.cpp
index ab197ee..eb99681 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_peephole_predicated_break.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_peephole_predicated_break.cpp
@@ -87,13 +87,18 @@ fs_visitor::opt_peephole_predicated_break()
}
if_inst->remove(if_block);
+
+ bblock_t *later_block = endif_block;
+ if (endif_block->start_ip == endif_block->end_ip) {
+ later_block = (bblock_t *)endif_block->link.next;
+ }
endif_inst->remove(endif_block);
- if_block->children.make_empty();
- endif_block->parents.make_empty();
+ earlier_block->children.make_empty();
+ later_block->parents.make_empty();
- if_block->add_successor(cfg->mem_ctx, jump_block);
- jump_block->add_successor(cfg->mem_ctx, endif_block);
+ earlier_block->add_successor(cfg->mem_ctx, jump_block);
+ jump_block->add_successor(cfg->mem_ctx, later_block);
if (earlier_block->can_combine_with(jump_block)) {
earlier_block->combine_with(jump_block);
--
1.8.5.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/xvmc/tests: avoid non portable error.h functions
On 30/08/14 18:43, Jonathan Gray wrote:
> Signed-off-by: Jonathan Gray
Nice stuff, thanks! I'll add a line or two (commit message) and push it shortly.
-Emil
> ---
> src/gallium/state_trackers/xvmc/tests/test_blocks.c | 6 --
> src/gallium/state_trackers/xvmc/tests/test_context.c| 6 --
> src/gallium/state_trackers/xvmc/tests/test_rendering.c | 13 -
> src/gallium/state_trackers/xvmc/tests/test_subpicture.c | 4 ++--
> src/gallium/state_trackers/xvmc/tests/test_surface.c| 6 --
> 5 files changed, 22 insertions(+), 13 deletions(-)
>
> diff --git a/src/gallium/state_trackers/xvmc/tests/test_blocks.c
> b/src/gallium/state_trackers/xvmc/tests/test_blocks.c
> index 0baed19..a35838f 100644
> --- a/src/gallium/state_trackers/xvmc/tests/test_blocks.c
> +++ b/src/gallium/state_trackers/xvmc/tests/test_blocks.c
> @@ -26,7 +26,8 @@
> **/
>
> #include
> -#include
> +#include
> +#include
> #include "testlib.h"
>
> int main(int argc, char **argv)
> @@ -62,7 +63,8 @@ int main(int argc, char **argv)
> ))
> {
> XCloseDisplay(display);
> - error(1, 0, "Error, unable to find a good port.\n");
> + fprintf(stderr, "Error, unable to find a good port.\n");
> + exit(1);
> }
>
> if (is_overlay)
> diff --git a/src/gallium/state_trackers/xvmc/tests/test_context.c
> b/src/gallium/state_trackers/xvmc/tests/test_context.c
> index 1b9b040..344ac76 100644
> --- a/src/gallium/state_trackers/xvmc/tests/test_context.c
> +++ b/src/gallium/state_trackers/xvmc/tests/test_context.c
> @@ -26,7 +26,8 @@
> **/
>
> #include
> -#include
> +#include
> +#include
> #include "testlib.h"
>
> int main(int argc, char **argv)
> @@ -58,7 +59,8 @@ int main(int argc, char **argv)
> ))
> {
> XCloseDisplay(display);
> - error(1, 0, "Error, unable to find a good port.\n");
> + fprintf(stderr, "Error, unable to find a good port.\n");
> + exit(1);
> }
>
> if (is_overlay)
> diff --git a/src/gallium/state_trackers/xvmc/tests/test_rendering.c
> b/src/gallium/state_trackers/xvmc/tests/test_rendering.c
> index 5bfbea7..b3b3794 100644
> --- a/src/gallium/state_trackers/xvmc/tests/test_rendering.c
> +++ b/src/gallium/state_trackers/xvmc/tests/test_rendering.c
> @@ -28,7 +28,7 @@
> #include
> #include
> #include
> -#include
> +#include
> #include "testlib.h"
>
> #define BLOCK_WIDTH 8
> @@ -84,9 +84,9 @@ static void ParseArgs(int argc, char **argv, unsigned int
> *output_width, unsigne
> }
>
> if (fail)
> - error
> - (
> - 1, 0,
> + {
> + fprintf(
> + stderr,
> "Bad argument.\n"
> "\n"
> "Usage: %s [options]\n"
> @@ -96,6 +96,8 @@ static void ParseArgs(int argc, char **argv, unsigned int
> *output_width, unsigne
> "\t-p\tPrompt for quit\n",
> argv[0]
> );
> + exit(1);
> + }
> }
>
> static void Gradient(short *block, unsigned int start, unsigned int stop,
> int horizontal, unsigned int intra_unsigned)
> @@ -166,7 +168,8 @@ int main(int argc, char **argv)
> ))
> {
> XCloseDisplay(display);
> - error(1, 0, "Error, unable to find a good port.\n");
> + fprintf(stderr, "Error, unable to find a good port.\n");
> + exit(1);
> }
>
> if (is_overlay)
> diff --git a/src/gallium/state_trackers/xvmc/tests/test_subpicture.c
> b/src/gallium/state_trackers/xvmc/tests/test_subpicture.c
> index 8bd4d6d..ad9fbe3 100644
> --- a/src/gallium/state_trackers/xvmc/tests/test_subpicture.c
> +++ b/src/gallium/state_trackers/xvmc/tests/test_subpicture.c
> @@ -26,7 +26,6 @@
> **/
>
> #include
> -#include
> #include
> #include
> #include "testlib.h"
> @@ -87,7 +86,8 @@ int main(int argc, char **argv)
> ))
> {
> XCloseDisplay(display);
> - error(1, 0, "Error, unable to find a good port.\n");
> + fprintf(stderr, "Error, unable to find a good port.\n");
> + exit(1);
> }
>
> if (is_overlay)
> diff --git a/src/gallium/state_trackers/xvmc/tests/test_surface.c
> b/src/gallium/state_trackers/xvmc/tests/test_surface.c
> index 8145686..964ca82 100644
> --- a/src/gallium/state_trackers/xvmc/tests/test_surface.c
> +++ b/src/gallium/state_trackers/xvmc/tests/test_surface.c
> @@ -26,7 +26,8 @@
> **/
>
> #include
> -#include
> +#include
> +#include
> #include "testlib.h"
>
>
Re: [Mesa-dev] [Mesa-stable] [PATCH 2/2] nv50: zero out unbound samplers
On 31/08/14 01:13, Ilia Mirkin wrote:
> On Sat, Aug 30, 2014 at 8:09 PM, Emil Velikov
> wrote:
>> On 31/08/14 00:34, Ilia Mirkin wrote:
>>> On Sat, Aug 30, 2014 at 7:30 PM, Emil Velikov
>>> wrote:
On 30/08/14 23:02, Ilia Mirkin wrote:
> Samplers are only defined up to num_samplers, so set all samplers above
> nr to NULL so that we don't try to read them again later.
>
Would it be worth doing a similar thing with the unlocked samplers below
the
nr mark ? It seems to me that we might be leaking nv50->samplers[s][i], or
perhaps I'm missing something ?
>>>
>>> Can you elaborate? sampler_state_create/delete deal with allocation
>>> and deallocation. samplers starts out as NULL. I'm just making sure
>>> that a subsequent call with a larger number of samplers doesn't try to
>>> unlock potentially-deleted samplers.
>>>
>>
>>for (i = 0; i < nr; ++i) {
>> struct nv50_tsc_entry *old = nv50->samplers[s][i];
>>
>> nv50->samplers[s][i] = nv50_tsc_entry(hwcso[i]);
>> if (old)
>> nv50_screen_tsc_unlock(nv50->screen, old);
>>}
>>
>> In the above hunk we get the old/current tsc, drop in on the floor and assign
>> the new one in it's place. Does where does the ST keep track of the old one
>> in
>> order to nuke it via sampler_state_delete, or is it already deleted by the
>> time we get here ?
>
> It's the st's job to do this. It creates the samplers, and it deletes
> them. Binding is merely setting which samplers map to which slots.
>
It seemed to me that the driver was doing some of the "heavy lifting", so I
was a bit confused. Thanks for the clarification.
-Emil
> -ilia
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] i965/vec4: Reswizzle sources when necessary.
Despite the comment above the function claiming otherwise, the function
did not reswizzle sources, which would lead to bad code generation.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82932
---
src/mesa/drivers/dri/i965/brw_vec4.cpp | 32 +++-
src/mesa/drivers/dri/i965/brw_vec4.h | 4 ++--
2 files changed, 25 insertions(+), 11 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp
b/src/mesa/drivers/dri/i965/brw_vec4.cpp
index acf0b63..cbea437 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
@@ -933,9 +933,9 @@ vec4_visitor::opt_set_dependency_control()
}
bool
-vec4_instruction::can_reswizzle_dst(int dst_writemask,
-int swizzle,
-int swizzle_mask)
+vec4_instruction::can_reswizzle(int dst_writemask,
+int swizzle,
+int swizzle_mask)
{
/* If this instruction sets anything not referenced by swizzle, then we'd
* totally break it when we reswizzle.
@@ -977,9 +977,10 @@ vec4_instruction::can_reswizzle_dst(int dst_writemask,
* e.g. for swizzle=yywx, MUL a.xy b c -> MUL a.yy_x b.yy z.yy_x
*/
void
-vec4_instruction::reswizzle_dst(int dst_writemask, int swizzle)
+vec4_instruction::reswizzle(int dst_writemask, int swizzle)
{
int new_writemask = 0;
+ int new_swizzle[4] = { 0 };
switch (opcode) {
default:
@@ -996,6 +997,19 @@ vec4_instruction::reswizzle_dst(int dst_writemask, int
swizzle)
}
break;
}
+
+ for (int i = 0; i < 3; i++) {
+ if (src[i].file == BAD_FILE || src[i].file == IMM)
+continue;
+
+ for (int c = 0; c < 4; c++) {
+new_swizzle[c] = BRW_GET_SWZ(src[i].swizzle, BRW_GET_SWZ(swizzle,
c));
+ }
+
+ src[i].swizzle = BRW_SWIZZLE4(new_swizzle[0], new_swizzle[1],
+ new_swizzle[2], new_swizzle[3]);
+ }
+
/* fallthrough */
case BRW_OPCODE_DP4:
case BRW_OPCODE_DP3:
@@ -1102,9 +1116,9 @@ vec4_visitor::opt_register_coalesce()
}
/* If we can't handle the swizzle, bail. */
-if (!scan_inst->can_reswizzle_dst(inst->dst.writemask,
- inst->src[0].swizzle,
- swizzle_mask)) {
+if (!scan_inst->can_reswizzle(inst->dst.writemask,
+ inst->src[0].swizzle,
+ swizzle_mask)) {
break;
}
@@ -1190,8 +1204,8 @@ vec4_visitor::opt_register_coalesce()
if (scan_inst->dst.file == GRF &&
scan_inst->dst.reg == inst->src[0].reg &&
scan_inst->dst.reg_offset == inst->src[0].reg_offset) {
- scan_inst->reswizzle_dst(inst->dst.writemask,
-inst->src[0].swizzle);
+ scan_inst->reswizzle(inst->dst.writemask,
+inst->src[0].swizzle);
scan_inst->dst.file = inst->dst.file;
scan_inst->dst.reg = inst->dst.reg;
scan_inst->dst.reg_offset = inst->dst.reg_offset;
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.h
b/src/mesa/drivers/dri/i965/brw_vec4.h
index f8313c1..74d1241 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.h
+++ b/src/mesa/drivers/dri/i965/brw_vec4.h
@@ -220,8 +220,8 @@ public:
bool header_present;
bool is_send_from_grf();
- bool can_reswizzle_dst(int dst_writemask, int swizzle, int swizzle_mask);
- void reswizzle_dst(int dst_writemask, int swizzle);
+ bool can_reswizzle(int dst_writemask, int swizzle, int swizzle_mask);
+ void reswizzle(int dst_writemask, int swizzle);
bool can_do_source_mods(struct brw_context *brw);
bool reads_flag()
--
1.8.5.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] i965/vec4: Add ability to reswizzle arbitrary swizzles.
Before commit 04895f5c we would only reswizzle dot product instructions
(since they wrote the same value into all channels, and we didn't have
to think about anything else). That commit extended reswizzling to cases
when the swizzle was single valued -- i.e., writing the same result into
all channels.
But allowing reswizzling of arbitrary things is actually really easy and
is even less code. (Why didn't we do this in the first place?!)
total instructions in shared programs: 4266079 -> 4261000 (-0.12%)
instructions in affected programs: 351933 -> 346854 (-1.44%)
---
src/mesa/drivers/dri/i965/brw_vec4.cpp | 74 +-
1 file changed, 18 insertions(+), 56 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp
b/src/mesa/drivers/dri/i965/brw_vec4.cpp
index cbea437..536a4b6 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
@@ -943,30 +943,10 @@ vec4_instruction::can_reswizzle(int dst_writemask,
if (dst.writemask & ~swizzle_mask)
return false;
- switch (opcode) {
- default:
- if (!brw_is_single_value_swizzle(swizzle)) {
- /* Check if there happens to be no reswizzling required. */
- for (int c = 0; c < 4; c++) {
-int bit = 1 << BRW_GET_SWZ(swizzle, c);
-/* Skip components of the swizzle not used by the dst. */
-if (!(dst_writemask & (1 << c)))
- continue;
+ if (is_tex())
+ return false;
-/* We don't do the reswizzling yet, so just sanity check that we
- * don't have to.
- */
-if (bit != (1 << c))
- return false;
- }
- return true;
- }
- /* fallthrough */
- case BRW_OPCODE_DP4:
- case BRW_OPCODE_DP3:
- case BRW_OPCODE_DP2:
- return true;
- }
+ return true;
}
/**
@@ -982,22 +962,9 @@ vec4_instruction::reswizzle(int dst_writemask, int swizzle)
int new_writemask = 0;
int new_swizzle[4] = { 0 };
- switch (opcode) {
- default:
- if (!brw_is_single_value_swizzle(swizzle)) {
- for (int c = 0; c < 4; c++) {
-/* Skip components of the swizzle not used by the dst. */
-if (!(dst_writemask & (1 << c)))
- continue;
-
-/* We don't do the reswizzling yet, so just sanity check that we
- * don't have to.
- */
-assert((1 << BRW_GET_SWZ(swizzle, c)) == (1 << c));
- }
- break;
- }
-
+ /* Dot product instructions write a single result into all channels. */
+ if (opcode != BRW_OPCODE_DP4 && opcode != BRW_OPCODE_DPH &&
+ opcode != BRW_OPCODE_DP3 && opcode != BRW_OPCODE_DP2) {
for (int i = 0; i < 3; i++) {
if (src[i].file == BAD_FILE || src[i].file == IMM)
continue;
@@ -1009,25 +976,20 @@ vec4_instruction::reswizzle(int dst_writemask, int
swizzle)
src[i].swizzle = BRW_SWIZZLE4(new_swizzle[0], new_swizzle[1],
new_swizzle[2], new_swizzle[3]);
}
+ }
- /* fallthrough */
- case BRW_OPCODE_DP4:
- case BRW_OPCODE_DP3:
- case BRW_OPCODE_DP2:
- for (int c = 0; c < 4; c++) {
- int bit = 1 << BRW_GET_SWZ(swizzle, c);
- /* Skip components of the swizzle not used by the dst. */
- if (!(dst_writemask & (1 << c)))
-continue;
- /* If we were populating this component, then populate the
- * corresponding channel of the new dst.
- */
- if (dst.writemask & bit)
-new_writemask |= (1 << c);
- }
- dst.writemask = new_writemask;
- break;
+ for (int c = 0; c < 4; c++) {
+ int bit = 1 << BRW_GET_SWZ(swizzle, c);
+ /* Skip components of the swizzle not used by the dst. */
+ if (!(dst_writemask & (1 << c)))
+ continue;
+ /* If we were populating this component, then populate the
+ * corresponding channel of the new dst.
+ */
+ if (dst.writemask & bit)
+ new_writemask |= (1 << c);
}
+ dst.writemask = new_writemask;
}
/*
--
1.8.5.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] The long road to 'make dist' (gallium#2)
On 30/08/14 05:33, Matt Turner wrote: > On Fri, Aug 29, 2014 at 4:44 PM, Emil Velikov > wrote: >> Hello list, >> >> Another boring yet important series, if we are to have properly working >> solution to package a mesa release tarball via 'make dist'. >> >> This series covers a few state-tracker files missed out previously, >> picks up all the gallium tests, tools and drivers. > > Thanks for doing this. I don't think I've done anything worth a R-b, > but the series is > > Acked-by: Matt Turner > Thanks. > The only real question I have is about whether the Android build files > need to be in the tarballs. I have a very slight preference for not > doing it, more so if Adrian says we don't need them. > Don't think Adrian had the chance to try building mesa recently, let alone run it :'( The build is somewhat broken - should fix it soon (tm). I have a couple of guys from the Android-x86 project that tend to use tar-balls when possible, not to mention that I'm adding pretty much everything in. IMHO it comes a bit odd to explicitly opt-out of the Android one - it does not make the tarball that much bigger (either size or number of files). -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] r600g: Implement GL_ARB_sample_shading
Signed-off-by: Glenn Kennard
---
Tested on radeon 6670, all sample shading piglits pass, no
regressions, as well as unigine valley basic, tesseract with
MSAA enabled.
It would be great if one or more people could test this
on pre-evergreen hardware, and cayman, since I don't
have any such hardware to test with.
Added a comment on a pre-existing bug discovered while
implementing sample shading where driver const buffers
can alias user provided ones.
docs/GL3.txt | 4 +-
docs/relnotes/10.4.html | 62 ++
src/gallium/drivers/r600/evergreen_state.c | 104 ++---
src/gallium/drivers/r600/evergreend.h| 3 +
src/gallium/drivers/r600/r600_pipe.c | 2 +-
src/gallium/drivers/r600/r600_pipe.h | 9 +
src/gallium/drivers/r600/r600_shader.c | 305 +--
src/gallium/drivers/r600/r600_shader.h | 7 +-
src/gallium/drivers/r600/r600_state.c| 43 +++-
src/gallium/drivers/r600/r600d.h | 3 +
src/gallium/drivers/r600/sb/sb_bc_parser.cpp | 21 +-
11 files changed, 444 insertions(+), 119 deletions(-)
create mode 100644 docs/relnotes/10.4.html
diff --git a/docs/GL3.txt b/docs/GL3.txt
index 56c4994..5baacc1 100644
--- a/docs/GL3.txt
+++ b/docs/GL3.txt
@@ -104,13 +104,13 @@ GL 4.0, GLSL 4.00:
- Fused multiply-add DONE ()
- Packing/bitfield/conversion functions DONE (r600)
- Enhanced textureGather DONE (r600, radeonsi)
- - Geometry shader instancing DONE ()
+ - Geometry shader instancing DONE (r600)
- Geometry shader multiple streams DONE ()
- Enhanced per-sample shadingDONE (r600)
- Interpolation functionsDONE ()
- New overload resolution rules DONE
GL_ARB_gpu_shader_fp64 started (Dave)
- GL_ARB_sample_shadingDONE (i965, nv50, nvc0,
radeonsi)
+ GL_ARB_sample_shadingDONE (i965, nv50, nvc0,
r600, radeonsi)
GL_ARB_shader_subroutine not started
GL_ARB_tessellation_shader started (Chris, Ilia)
GL_ARB_texture_buffer_object_rgb32 DONE (i965, nvc0, r600,
radeonsi, llvmpipe, softpipe)
diff --git a/docs/relnotes/10.4.html b/docs/relnotes/10.4.html
new file mode 100644
index 000..d56275d
--- /dev/null
+++ b/docs/relnotes/10.4.html
@@ -0,0 +1,62 @@
+http://www.w3.org/TR/html4/loose.dtd";>
+
+
+
+ Mesa Release Notes
+
+
+
+
+
+ The Mesa 3D Graphics Library
+
+
+
+
+
+Mesa 10.4 Release Notes / TBD
+
+
+Mesa 10.4 is a new development release.
+People who are concerned with stability and reliability should stick
+with a previous release or wait for Mesa 10.4.1.
+
+
+Mesa 10.4 implements the OpenGL 3.3 API, but the version reported by
+glGetString(GL_VERSION) or glGetIntegerv(GL_MAJOR_VERSION) /
+glGetIntegerv(GL_MINOR_VERSION) depends on the particular driver being used.
+Some drivers don't support all the features required in OpenGL 3.3. OpenGL
+3.3 is only available if requested at context creation
+because compatibility contexts are not supported.
+
+
+
+MD5 checksums
+
+TBD.
+
+
+
+New features
+
+
+Note: some of the new features are only available with certain drivers.
+
+
+
+GL_ARB_sample_shading on r600
+
+
+
+Bug fixes
+
+TBD.
+
+Changes
+
+
+
+
+
+
+
diff --git a/src/gallium/drivers/r600/evergreen_state.c
b/src/gallium/drivers/r600/evergreen_state.c
index 9f0e82d..9531893 100644
--- a/src/gallium/drivers/r600/evergreen_state.c
+++ b/src/gallium/drivers/r600/evergreen_state.c
@@ -1398,7 +1398,7 @@ static void evergreen_set_framebuffer_state(struct
pipe_context *ctx,
/* MSAA. */
if (rctx->b.chip_class == EVERGREEN)
- rctx->framebuffer.atom.num_dw += 14; /* Evergreen */
+ rctx->framebuffer.atom.num_dw += 17; /* Evergreen */
else
rctx->framebuffer.atom.num_dw += 28; /* Cayman */
@@ -1418,8 +1418,36 @@ static void evergreen_set_framebuffer_state(struct
pipe_context *ctx,
}
rctx->framebuffer.atom.dirty = true;
+
+ /* set sample xy locations as array of fragment shader constants */
+ {
+ struct pipe_constant_buffer constbuf = {0};
+ float values[4*16] = {0.0f};
+ int i;
+ assert(rctx->framebuffer.nr_samples <= Elements(values)/4);
+ for (i = 0; i < rctx->framebuffer.nr_samples; i++) {
+ ctx->get_sample_position(ctx,
rctx->framebuffer.nr_samples, i, &values[4*i]);
+ }
+ constbuf.user_buffer = values;
+ constbuf.buffer_size = rctx->framebuffer.nr_samples * 4 * 4;
+ ctx->set_constant_buffer(ctx, PIPE_SHADER_FRAGMENT,
+
[Mesa-dev] Mesa 10.3 release candidate 2
Mesa 10.3 release candidate 2 is now available for testing. The current plan of record is to have an additional release candidate each Friday until the 10.3 release on Friday, September 12th. The tag in the GIT repository for Mesa 10.3-rc2 is 'mesa-10.3-rc2'. I have verified that the tag is in the correct place in the tree. Mesa 10.3 release candidate 2 is available for download at ftp://freedesktop.org/pub/mesa/10.3/ sha256sums: 079d12d4a3ca0f3f1958cab1466d07b2771296379be26bacaa6243396e521595 MesaLib-10.3.0-rc2.tar.gz 79e9472ac216f22ef7d06460786cf219940cf75b6bee3eaf3076614e8d20f256 MesaLib-10.3.0-rc2.tar.bz2 6288753b1d8248e5c27f99f17aa51af9daba9f7a08662a405d28dde3fece6c07 MesaLib-10.3.0-rc2.zip I have verified building from the .tar.bz2 file by doing the following on my Arch system: tar -xjf MesaLib-10.3.0-rc2.tar.bz2 cd Mesa-10.3.0-rc2 ./configure --enable-gallium-llvm make -j6 make install -Emil Changes since mesa-10.3-rc1: Alex Deucher (2): radeonsi: add new CIK pci ids radeonsi: add new SI pci ids Carl Worth (2): Makefile: Switch from md5sums to sha256sums glcpp: Don't use alternation in the lookahead for empty pragmas. Christian König (3): st/vdpau: fix vlVdpOutputSurfaceRender(Output|Bitmap)Surface vl/compositor: set the scissor before clearing the render target radeon/uvd: fix field handling on R6XX style UVD Emil Velikov (2): mesa: fix make tarballs Increment version to 10.3.0-rc2 Kenneth Graunke (2): i965: Disable try_emit_b2f_of_compare on Gen4-6. i965: Add 2x MSAA support to Broadwell fast clear code. Matt Turner (2): i965: Fix JIP/UIP calculations. i965/vec4: Update register coalescing test. signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC PATCH 00/16] A new IR for Mesa
On 28.08.2014 19:58, Henri Verbeet wrote: On 28 August 2014 05:21, Michel Dänzer wrote: Sure, it's not impossible, but is that really the kind of process you want users to go through when bisecting a regression? I appreciate your theoretical concern, but in practice, people don't seem to have trouble bisecting radeonsi regressions in general. I suspect you may be getting some selection bias there. As far as Wine users are concerned, we certainly seem to have more r600g users than radeonsi ones. That's hardly surprising, considering the respective periods of availability of the hardware and drivers. For Wine developers that comparison is even worse; as far as I'm aware none of the regular developers regularly develop on radeonsi. I've seen a couple more casual developers try, but I suspect they essentially gave up once they realized how much work would be required to make the Wine tests pass on radeonsi. What kind of work are you referring to? From a piglit perspective, radeonsi has been on par with r600g for a while, possibly even slightly better now. Please file bug reports for Wine test failures. Perhaps more concretely, I think the r600-sb backend works at least as well as the r600-llvm one, SB currently works better overall for graphics, which is why we decided to make it the default. and not for lack of effort put into the latter. Sounds like you're overestimating the effort put into the LLVM R600 backend for pre-SI graphics. -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] nvc0: don't make 1d staging textures linear
Experimentally, the sampler doesn't appear to like these, neither as
buffer nor as rect textures. So remove 1D from the list of texture types
to make linear when used for staging.
This fixes the OSD in mplayer for VDPAU.
Signed-off-by: Ilia Mirkin
Cc: "10.2 10.3"
---
src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c
index 2f3cba8..3baa752 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c
@@ -261,7 +261,6 @@ nvc0_miptree_create(struct pipe_screen *pscreen,
if (pt->usage == PIPE_USAGE_STAGING) {
switch (pt->target) {
- case PIPE_TEXTURE_1D:
case PIPE_TEXTURE_2D:
case PIPE_TEXTURE_RECT:
if (pt->last_level == 0 &&
--
1.8.5.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
